Kennt jemand einen IC der ein 3.3V PWM Signal mit ca. 500Hz in ein analoges Signal von 0-10V umsetzt? Der Ripple muss weniger als 30mV betragen. Ich hatte schon versucht einen OP mit Bandpassfilter zu simulieren. Leider war das Ergebnis nicht befriedigend.
Also ein OpAmp als Verstärker x 3 an passender Versorgungsspannung kann das, du musst die PWM halt ausreichend filtern. Bei 500Hz PWM sind das minutenlange Filter. Man könnte auch die PWM Zeitdauer mit 2us Auflösung per input capture erfassen und den Wert per 10 bit D/A ausgeben, das reagiert sofort.
Wieso IC? Wenn du das Signal nicht belasten brauchst: http://www.electronicdeveloper.de/LL_FilterPassiv.aspx (genauer: http://www.electronicdeveloper.de/FilterPassivTiefpassRC_1O.aspx). Ansonsten halt nen Transimpedanzwandler dahinter, z.B. LM358. MfG
@Christopher Gruber (chrisgr) >Kennt jemand einen IC der ein 3.3V PWM Signal mit ca. 500Hz in ein >analoges Signal von 0-10V umsetzt? Der Ripple muss weniger als 30mV >betragen. So etwas gibt es heute tatsächlich!! http://www.linear.com/product/LTC2644 http://www.linear.com/product/LTC2645
@ mawin. danke. Wie funktioniert die instant capture sache? Minutenlang filtern ist nicht drin, das muss innerhalb von 1ms laufen. @falk brunner Danke, gibts da noch alternativen? Das teil ist nicht leicht zu bekommen und relativ teuer.
@mawin Passfilter kommt aus folgenden gelben nicht in frage Keine Konvertierung von 3,3v auf 10v Viel zu hoher ripple ZU Langsam (muss ca. innerhalb 1ms laufen)
@Christopher Gruber (chrisgr) >Danke, gibts da noch alternativen? Keine Ahnung. > Das teil ist nicht leicht zu bekommen und relativ teuer. Dafür ist es eine fix und fertige Lösung. There is no such thing as free lunch.
500 Hz - und innerhalb einer mS reagieren - ich denke das ist dann doch zu viel verlangt.
Frank W. schrieb: > 500 Hz - und innerhalb einer mS reagieren - ich denke das ist dann doch > zu viel verlangt. Ja weil 500Hz eine Updaterate von 2ms sind.
Christopher G. schrieb: > Es sind genau 400hz und 4ms sind auch noch ausreichend. Wenn Du mit einem µC direkt die Periodendauer messen würdest, würde theoretisch eine Periode zum Messen ausreichen. Ich vermute aber, das ganze wird ziemlich störanfällig werden.
Moin, Christopher G. schrieb: > Kennt jemand einen IC der ein 3.3V PWM Signal mit ca. 500Hz in ein > analoges Signal von 0-10V umsetzt? Der Ripple muss weniger als 30mV > betragen. Christopher G. schrieb: > Es sind genau 400hz und 4ms sind auch noch ausreichend. Daraus kann man sich schon mal groessenordnungsmaessig die Anforderungen an einen Tiefpass berechnen. (Wieso denn Bandpass? Gibts noch hier geheime untere Grenzfrequenzen) 5V(da wird der Ripple im PWM am energiereichsten sein)/30mV -> Abstand 44.5dB 4ms -> 250Hz: Max. Durchlassfrequenz 400Hz: Min. Sperrfrequenz log²(400/250)=0.678 Oktaven 44.5db/0.678 Octaven = 65.5 db/Oct. (65.5dB/Oct) / (6dB/Oct) = 10.9 Also sollte das ein Butterworth-Tiefpass mit einer Ordnung >=11 hinbekommen. Das ist natuerlich in Analogtechnik arg unangenehm sowas zu realisieren (Bauteiltoleranzen). Nimmt man irgendwelche Welligkeiten in Durchlass- und Sperrbereich in Kauf, dann wird die minimale Filterordnung entsprechend sinken - aber schoen ist anders. Irgendwie koennt' man aber schon in die Naehe kommen. Das ist so, weil halt die Anforderungen arg - hm - streng sind. Und ich bezweifle, dass das dadurch besser wird, wenn man jede PWM einzeln ausmisst und dann via DAC versucht auszugeben. Es ist halt einfach Kappes, mit einer 400Hz PWM 250Hz Signale vernuenftig uebertragen zu wollen. Gruss WK
Dergute W. schrieb: > Es ist halt einfach > Kappes, mit einer 400Hz PWM 250Hz Signale vernuenftig uebertragen zu > wollen. Genau genommen ist es gar nicht möglich. Mit einer 400Hz PWM lassen sich maximal 400 unterschiedliche Zustände pro Sekunde übertragen - 2 für eine Periode, also 200Hz. Außerdem werden ihm normale Filter Überschwinger bereiten - Was für einen Bandbegrenzten Rechteck ja auch richtig, aber in diesem Fall wahrschenlich ungewünscht ist. Dergute W. schrieb: > Also sollte das ein Butterworth-Tiefpass mit einer Ordnung >=11 > hinbekommen. Die Signallaufzeit macht ihm dann seine 4ms aber wieder kaputt. Ich sehe da nur die Möglichkeit, das Signal digital aufzubereiten. Mit mindestens 200kHz samplen, Analogwert errechnen (Pulslänge/Periodendauer) und dann entweder eine hochfrequente PWM erzeugen und analog glätten oder über R2R / DAC ausgeben. Gruß Jobst
Christopher G. schrieb: > Wie funktioniert die instant capture sache? input capture ist eine Betriebsart des internen Timers im uC, der damit misst, wie lange ein Impuls von aussen dauert. Und dann noch die Pausenzeit messen und man hat das PWM Verhältnis. In Hardware, nicht Software. > Minutenlang filtern ist nicht drin, das muss innerhalb von 1ms laufen. > Es sind genau 400hz und 4ms sind auch noch ausreichend. Man kann nach 1 Periode des PWM Signals den D/A-Wandler setzen.
Für einen Frequenz-Spannungs-Wandler gibt es diese Lösung, wobei die schnellste Meßzeit 1 ms beträgt: http://mino-elektronik.de/fmeter/fm_software.htm#bsp10 Man muß die Frequenzmessung durch Pulsweitenmessung ersetzen bzw. ergänzen und die Ausgangsspannung noch verstärken, um die genannten Anforderungen zu erfüllen. Harald W. schrieb: > Wenn Du mit einem µC direkt die Periodendauer messen würdest, > würde theoretisch eine Periode zum Messen ausreichen. Ich > vermute aber, das ganze wird ziemlich störanfällig werden. Keine Angst, die Sache ist sehr stabil ;-)
@Jobst M. (jobstens-de) >Ich sehe da nur die Möglichkeit, das Signal digital aufzubereiten. >Mit mindestens 200kHz samplen, Analogwert errechnen >(Pulslänge/Periodendauer) und dann entweder eine hochfrequente PWM >erzeugen und analog glätten oder über R2R / DAC ausgeben. Genau DAS tun die ICs von Linear!!! Problem gelöst!
Merci für die vielen Posts. Die Auswertung über einen Arduino hatte ich versucht, aber das ging zu langsam. Ich werde vohl den LTC2645 bestellen und testen. Ich denke, dass ist die beste Lösung. Ist jemand an den Ergebnissen interessiert?
Harald W. schrieb: > Wenn Du mit einem µC direkt die Periodendauer messen würdest, > würde theoretisch eine Periode zum Messen ausreichen. Ich > vermute aber, das ganze wird ziemlich störanfällig werden. Nein, das klappt schon zuverlässig. Habe das schon einmal bei PICs verwendet (da heißt das "input capture"). Zwar nicht genau für das, aber es war eine duty-cycle-Messung. Die funktioniert tadellos. Wo man halt aufpassen muss, ist beim Umschalten des Tastverhältnisses bei der PWM. Das muss konsistent sein, also DC ändern nur zu Ende der Periode. Da ist natürlich ein Messfehler drauf, weil das Signal auf den Takt des µC einsyncrhonisiert werden muss. PS: Die Linear-Teile kann man übrigens auch hier kaufen: https://www.conrad.at/de/datenerfassungs-ic-digital-analog-wandler-dac-linear-technology-ltc2642cdd-14pbf-dfn-10-1254361.html Man spart mit solchen Lösungen einiges an Entwicklungs und Zeitaufwand. Bei kleinen Stückzahlen (<10k) muss man schon sehr genau rechenen, ob man das in Software oder diskret WIRKLICH billiger lösen kann.
Christopher G. schrieb: > Die Auswertung über einen Arduino hatte ich versucht, aber das ging zu > langsam. Das liegt aber nicht am Arduino (ATmega328?), sondern eindeutig am Programm. Selbst, wenn man nicht über ICP1 geht, sind INT0 und INT1 schnell genug, um Pulsdauer und Periode auf 1 µs genau zu erfassen. Für Input Capture mit Timer1 verwendet man am besten den Multiplexer vom ADC, oder alternativ ICP1 und AIN0/AIN1 als Eingänge.
Der uC ist der Atmel 328 mit folgendem Code für 6 Kanäle:
# define in1 4
# define in2 7
# define in3 8
# define in4 12
# define in5 2
# define in6 13
# define out1 3
# define out2 5
# define out3 6
# define out4 9
# define out5 10
# define out6 11
float ton_1 = 0;
float ton_2 = 0;
float ton_3 = 0;
float ton_4 = 0;
float ton_5 = 0;
float ton_6 = 0;
float toff_1 = 0;
float toff_2 = 0;
float toff_3 = 0;
float toff_4 = 0;
float toff_5 = 0;
float toff_6 = 0;
float value_1 = 0;
float value_2 = 0;
float value_3 = 0;
float value_4 = 0;
float value_5 = 0;
float value_6 = 0;
void setup() {
pinMode(in1, INPUT);
pinMode(in2, INPUT);
pinMode(in3, INPUT);
pinMode(in4, INPUT);
pinMode(in5, INPUT);
pinMode(in6, INPUT);
pinMode(out1, OUTPUT);
pinMode(out2, OUTPUT);
pinMode(out3, OUTPUT);
pinMode(out4, OUTPUT);
pinMode(out5, OUTPUT);
pinMode(out6, OUTPUT);
//Serial.begin(115200);
}
void loop() {
ton_1 = pulseIn(in1, HIGH);
toff_1 = pulseIn(in1, LOW);
value_1 = (ton_1)/(ton_1 + toff_1)*255;
analogWrite(out1, value_1);
//Serial.println(value_1);
//Serial.println(ton_1);
//Serial.println(toff_1);
ton_2 = pulseIn(in2, HIGH);
toff_2 = pulseIn(in2, LOW);
value_2 = ton_2 / (ton_2 + toff_2) * 255;
analogWrite(out2, value_2);
ton_3 = pulseIn(in3, HIGH);
toff_3 = pulseIn(in3, LOW);
value_3 = ton_3 / (ton_3 + toff_3) * 255;
analogWrite(out3, value_3);
ton_4 = pulseIn(in4, HIGH);
toff_4 = pulseIn(in4, LOW);
value_4 = ton_4 / (ton_4 + toff_4) * 255;
analogWrite(out4, value_4);
ton_5 = pulseIn(in5, HIGH);
toff_5 = pulseIn(in5, LOW);
value_5 = ton_5 / (ton_5 + toff_5) * 255;
analogWrite(out5, value_5);
ton_6 = pulseIn(in6, HIGH);
toff_6 = pulseIn(in6, LOW);
value_6 = ton_6 / (ton_6 + toff_6) * 255;
analogWrite(out6, value_6);
}
Chris G. schrieb: > Der uC ist der Atmel 328 mit folgendem Code für 6 Kanäle: Tja, so geht's halt nicht, und von 6 Kanälen hast du vorher auch nichts erzählt (Hardware gibt's halt nur begrenzt oft). Wie üblich Salamischeiben und float im Mikrocontroller.
Der Falk kennt RAH? -> ich bin begeistert. Heißt aber TANSTAAFL. ;) Chris - es fehlt noch eine Info: Was ist Deine geplante Stückzahl? Die Lösung von Falk ist fertig und funktionsfähig und erfordert keinerlei Programmieraufwand in Entwicklung und Fertigung. Ohne Bandbreiteneinschränkung wäre aus heutiger Sicht eine MCU mit eingebautem DAC die billigste Lösung für die Serie - unter 1€ bei Verwendung z.B. eines STM32F030. Eine LSI-Lösung mit analogen Filtern könnte, bei entsprechend träger Reaktion, kostenmäßig zwischen den beiden Varianten liegen.
Hab schon befürchtet, dass der code hier zerpflückt wird :D Also, 2 Kanäle sind ok. Float hab ich verwendet, da mit Nachkommawerten gerechnet wird.
Chris G. schrieb: > Hab schon befürchtet, dass der code hier zerpflückt wird :D > Also, 2 Kanäle sind ok. Float hab ich verwendet, da mit Nachkommawerten > gerechnet wird. Puh :-( Schau dir mal an, wie lange der arme ATMEGA braucht, um float-Berechnungen zu machen. Nimm integer. Man kann die Werte ein paar Zehnerpotenzen hochskalieren, dann kann man auch mit Integer "Kommastellen" rechnen. Beispiel: Statt eine Spannung in V zu skalieren, nimmt man mV. Oder µV. Weiß nicht wie das bei ATMEGA ist, aber von PIC24 weiß ich, dass dort int statt float um mindestens 2 Größenordnungen schneller ist. Integer ist bei geeigneter Skalierung gleich genau.
Chris G. schrieb: > Sückzahl unter 500 Ah. Na dann bist Du ja mit der MCU-Geschichte auf dem richtigen Weg. Übrigens kannst Du Dir Dein eigenes "ASIC" basteln, wenn Du die MCUs mit der getesteten Firmware vorprogrammiert kaufst. Wobei sich meist Platz für ein halbes Dutzend ISP-Pins findet.
@Marcus H. (Firma: www.harerod.de) (lungfish)
>Der Falk kennt RAH? -> ich bin begeistert. Heißt aber TANSTAAFL. ;)
????
Marcus H. schrieb: >> Sückzahl unter 500 > > Ah. Na dann bist Du ja mit der MCU-Geschichte auf dem richtigen Weg. > Übrigens kannst Du Dir Dein eigenes "ASIC" basteln, wenn Du die MCUs mit > der getesteten Firmware vorprogrammiert kaufst. Wobei sich meist Platz > für ein halbes Dutzend ISP-Pins findet. Falsch. Damit ist der LTC2642 die billigste Lösung. Allein die Entwicklungskosten für die Software werden den Kaufpreis für die Linear-IC überschreiten. 500Stück bekommt der Endkunde um 1780€. Rechnet man den Preis für den µC weg, darf man schon fast nix mehr entwickeln. Mehr als 10 Arbeitsstunden dürfen da nie reinfließen. Das klappt nicht. Zumindest dann nicht, wenn man noch Tests machen muss. Nein, bei so geringen Stückzahlen ist das fertige IC billiger. Der Preis ist von hier: http://www.digikey.com/product-search/en?lang=en&site=us&WT.z_cid=ref_findchips_standard&mpart=LTC2642CDD-12%23PBF Wenn man etwas schaut, dann wird man noch herunterkommen.
Chris G. schrieb: > Sückzahl unter 500 Dann bietet sich ein STM32F051 o.ä. an. Mit Timer2 (32 Bit) lassen sich direkt Pulsweite und Tastverhältnis per Hardware erfassen. Bei Bedarf und 16 Bit Timern auch mehrere Kanäle. Marcus H. schrieb: > Ohne Bandbreiteneinschränkung wäre aus heutiger Sicht eine MCU mit > eingebautem DAC die billigste Lösung für die Serie - unter 1€ bei > Verwendung z.B. eines STM32F030. So billig der x030 sein mag, einen DAC hat er nicht.
Gästchen schrieb: > Marcus H. schrieb: > Falsch. Die Gesamtkosten setzen sich aus Material und Arbeitszeit zusammen. Eine saubere Analoglösung will auch kalibriert und getestet werden. Bei den aktuell vorliegenden Informationen würde ich mich trauen, ein Angebot zu machen, bei dem die MCU-Lösung für 500 Stück nicht teurer ist. Das mag daran liegen, dass ich die betreffende MCU schonmal low-level gesehen habe und bestehendes Wissen wiederverwenden kann. Die MCU Lösung hat außerdem im Feld weitere Vorteile, namentlich die digitale Kalibrierbarkeit. Wobei ich nicht sicher bin, ob 500x 1 Kanal oder 500 x 6 Kanäle gewünscht sind. In letzterem Fall liegt die MCU-Lösung meilenweit vorne.
Gästchen schrieb: > Damit ist der LTC2642 die billigste Lösung. So billig er auch sein mag, allein mit einem DAC kommt man nicht weit :-(
Marcus H. schrieb: > Bei den aktuell vorliegenden Informationen würde ich mich trauen, ein > Angebot zu machen, bei dem die MCU-Lösung für 500 Stück nicht teurer > ist. Ich würde mich sogar trauen, ein Angebot zu machen, bei dem die µC Lösung billiger ist ;-)
Chris G. schrieb: > Hab schon befürchtet, dass der code hier zerpflückt wird :D Damit haben wir hier noch nicht mal angefangen... > Also, 2 Kanäle sind ok. Float hab ich verwendet, da mit Nachkommawerten > gerechnet wird. Man kann mit vielen rechnen, wenn hinterher bloss ganze Zahlen rauskommen, war es überflüssig. Das Problem bei Sofwtarelösungen sind die hohen Anforderungen: 500 Hz und 30mV=0.3%, macht ein sample aller 6 Kanäle zumindest alle 6 Mikrosekunden. Hier wäre eine Softwarelösung https://www.mikrocontroller.net/articles/High-Speed_capture_mit_ATmega_Timer die nicht ausreicht. Da auch bei 6 Kanälen innerhalb 2 Millisekunden nur 12 Flankenwechsel vorkommen, würde ich einen schnellen Timer-Interupt alle 6us einen Port in einem Array speichern, das lang genug ist, 256 Einträge könnten reichen und vom Hauptprogramm dieses Array nach Flankenwechseln durchsuchen lassen und die Arraypositionen der Flankewechsel notieren lassen.
@Marcus H. (Firma: www.harerod.de) (lungfish) >Die Gesamtkosten setzen sich aus Material und Arbeitszeit zusammen. Eben. >Bei den aktuell vorliegenden Informationen würde ich mich trauen, ein >Angebot zu machen, bei dem die MCU-Lösung für 500 Stück nicht teurer >ist. Na dann rechne DAS mal vor! >Das mag daran liegen, dass ich die betreffende MCU schonmal low-level >gesehen habe und bestehendes Wissen wiederverwenden kann. Das ist eine Grundvoraussetzung, wenn man gegen fertige Produkte antritt. >Die MCU Lösung hat außerdem im Feld weitere Vorteile, namentlich die >digitale Kalibrierbarkeit. Ist hier nicht nötig. >Wobei ich nicht sicher bin, ob 500x 1 Kanal oder 500 x 6 Kanäle >gewünscht sind. In letzterem Fall liegt die MCU-Lösung meilenweit vorne. Ja? Dann zeig mir mal den ultrabilligen uC mit 6 echten DACs.
m.n. schrieb: > Marcus H. schrieb: >> Bei den aktuell vorliegenden Informationen würde ich mich trauen, ein >> Angebot zu machen, bei dem die MCU-Lösung für 500 Stück nicht teurer >> ist. > > Ich würde mich sogar trauen, ein Angebot zu machen, bei dem die µC > Lösung billiger ist ;-) Wenn ich alleine den Overhead bedenke, den man bei meinem Arbeitgeber bräuchte, dann ist das IC SICHER billiger. Beispiele für Mehraufwand, verglichen mit dem IC: - Duchlauf der Firmware durch die QS (Hardware ist gleich) - Programmierung in der Produktion (ein zusätzlicher Arbeitsschritt) - Erstellung der Firmware (auch hier: Hardware gleich) - Kommunikationsschnittstelle dazu für Update - Preise für Entwicklungsumgebung & Co - Debugstecker und restliches Gelumpe, was ein µC halt so mehr braucht Natürlich kennen wir die Randbedingungen nicht. Wenn schon ein µC drauf ist, ist die Softwarelösung natülich gleich einen guten Schritt billiger, als wenn nicht. Oder wenn ähnlicher Code schon vorhanden ist. Aber ich tippe drauf, dass allein der Durchlauf durch die QS schon teurer wäre, als die 500 IC.
Bei 6 Kanälen würde ich das mit dem Pin-Change Isr des Atmega machen (Timing sehr anspruchsvoll, Beispiel siehe Mawin). Oder mit einem STM32F103, Timer im PWM-Input Mode. Funktioniert komplett ohne Isr. Wenn an den Ausgangssignalen nicht viel gebastelt werden soll, dann kommen die TLC7225 oder TLC7226 DACs infrage. Die liefern direkt 0 - 10V. Die Auflösung ist allerdings nur 8 Bit (ca 40mV / LSB). Der LTC2644 / LTC2645 ist aber auch eine sehr interessante Lösung. Viele Grüße, Stefan
Hi Gästchen, ich gebe Deine sehr schön ausformulierte Antwort mal so an Falk weiter. Wobei der das auch schon vorher gewusst hat. Der Haken ist, dass die QS-Punkte für jede Neuentwicklung zutreffen. Zum Controllerpreis: STM32F030F4 gehen für ca. 0,50USD über den Tisch. Daran eine schnelle PWM mit RC-Filter und die Ripple-Spec wird eingehalten. Hier macht dann eine MCU 6 Kanäle. Wahlweise STM32F051 für ~1USD. Der hat dann 2x 12bit DAC. @Falk: "Na dann rechne DAS mal vor!" Nein, hier im Forum nicht mehr als bereits getan. Grüße, marcus
Marcus H. schrieb: > Wahlweise STM32F051 für ~1USD. Der hat dann 2x 12bit DAC. Warum siehst Du denn nicht ins Datenblatt? Der hat genau 1 x DAC; fertig! Falls mehr Kanäle benötigt werden, kann ein µC in 2,5 ms diese locker per Analogschalter + Haltekondensator ansteuern. Nachfolgende OPVs für die 10 V Ausgangsspannung werden ja sowieso benötigt. Gästchen schrieb: > Beispiele für Mehraufwand, verglichen mit dem IC: Das ist ja eine lustige Liste. Am besten macht man garnichts mehr und läßt sich nur noch bedienen. Ich habe immer im Hinterkopf, was man anstellen muß, wenn es dieses eine schöne IC nicht mehr zu kaufen gibt.
Noch als Ergänzung, wie ich es mit einem STM32F051 anstellen würde: die vorhandene Schaltung für einen STM32F407 http://mino-elektronik.de/FM_407/fmeter_407.htm#a5 auf das Notwendigste reduzieren und das Programm noch anpassen, daß die Meßzeit auf >= 1 ms eingestellt und der Meßwert für das Tastverhältnis auf den DAC gegeben werden.
@ m.n. (Gast) >Warum siehst Du denn nicht ins Datenblatt? Der hat genau 1 x DAC; >fertig! >Falls mehr Kanäle benötigt werden, kann ein µC in 2,5 ms diese locker >per Analogschalter + Haltekondensator ansteuern. Ein schöne Bastelei . . . >Gästchen schrieb: >> Beispiele für Mehraufwand, verglichen mit dem IC: >Das ist ja eine lustige Liste. Am besten macht man garnichts mehr und >läßt sich nur noch bedienen. Quark. Man erfindet das Rad nicht 2x!!! Man benutzt möglichst vollintegrierte Lösungen und kümmert sich um die Stellen, wo es diese Komponenten noch nicht gibt! >Ich habe immer im Hinterkopf, was man anstellen muß, wenn es dieses eine >schöne IC nicht mehr zu kaufen gibt. Da kannst du gefühlt 90% aller ICs nicht benutzen, denn dann würdest du immer nur alles diskret und bestenfalls mit 74er IC bauen müssen. -> UNSINN!!!! Get real dude, this is 2016!
Na, biste beleidigt, weil ich Deine schönen ICs nicht hinreichend würdige? Bauteile mit LTC sind ja noch in Ordnung, aber solche mit MAX kommen mir auch als Muster nicht ins Haus.
m.n. schrieb: > Na, biste beleidigt, weil ich Deine schönen ICs nicht hinreichend > würdige? Je nach Projektvorgabe kann die LTC- oder die Microcontroller-Lösung die passendere sein. Ich schreibe bewusst nicht: die bessere. Seht es einfach als Brainstorming, am Schluss entscheidet eh der TS, welche Lösung für ihn passt. Vieel Grüße, Stefan
@ m.n. (Gast) >Na, biste beleidigt, weil ich Deine schönen ICs nicht hinreichend >würdige? Warum sollte ich das? Ob dir die ICs gefallen oder nicht ist mir vollkommen schnuppe. Mir geht nur das Gesülze auf den Keks, man könne doch alles vieeeel besser und billiger selber bauen. Das ist im Zeitalter der höchstintegrierten ICs schlicht falsch. In den meisten Fällen ist die Lösung mit dem spezialisierten IC deutlich besser. Oder baust du deine OPVs noch diskret auf?
Falk B. schrieb: > Mir geht nur das Gesülze auf den Keks, man könne > doch alles vieeeel besser und billiger selber bauen. Und mir geht das Gesülze auf den Keks, die Anforderungen und damit auch die Kosten immer höher zu schrauben, daß eine Realisierung nahezu unmöglich wird. Der TO wird doch sowieso das machen, was er versteht und kann, egal wie kompliziert oder simpel das dann ausfallen wird. Falk B. schrieb: > Oder > baust du deine OPVs noch diskret auf? Auf keinen Fall! Ich verwende grundsätzlich nur fertige Meßsysteme mit konfektionierten Kabeln und USB-Anschluß. Löten ist von unserer QS verboten.
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.