Norbert schrieb: >> while raw < 2**12: >> new_raw =raw << (16 - bits) | raw >> (2 * bits - 16) >> # print(raw, new_raw) >> raw= raw+1 >> file.write(str(new_raw) +"\n") # wird geändert: s.u. >> file.flush() >> >> Das dauert mehrere Minuten. > Ja sicher. Du weißt aber was die Zeile mit dem flush() bewirkt? vielleicht doch nicht? Verrätst Du es mir was da noch passiert? > Berichte doch bitte wie oft man das da oben laufen lassen kann, bevor > der Flash-Speicher getoastet ist und der Pi Pico weggeworfen werden > kann. Wofür wäre das hilfreich? Für mich war es ausreichend das oben eingefügte Programmstück einmal laufen zu lassen. Bitte verrate mir bitte auch, welche Einheit "sps" ist. Im SI-System fand ich sie leider nicht. > Das ist das Mikrocontroller Forum, nicht eine Kirchengruppe. Bei manchen Postings habe ich wahrgenommen, dass die gemachten Äußerungen sehr nahe denen einer Kirchengruppe sind. Bei Deinen war mir dieses Phänomen nicht aufgefallen. Bei anderen Autoren sind allerdings nebulös, orakelhaft, undurchsichtig, mysteriös, geheimnisvoll halbwegs passende Eigenschaften.
PC-Freak schrieb: > Den Schirm von den Kabel, die hier anscheinend als 'Antenne' wirken, ist > vieleicht auch noch nicht auf Masse gelegt. "anscheinend" ? Ich verstehe nicht, welchen Sinn es haben soll, diese Antennen mit meiner Schaltung zu verbinden. Vielleicht erklärt mir das jemand (und vielleicht auch ohne das Wort ratiometrisch zu benutzen). VG
Norbert schrieb: >> Diese Anforderungen haben z.B. mit der Anfälligkeit oder Unanfälligkeit >> einer Programmiersprache für Fehler der Programmierer zu tun. >> Ich weiß, dass ich jetzt einen Shit-storm ausgelöst haben könnte. > Nee, aber peinlich - richtig peinlich - sollte dir das schon sein. ;-) > Es ist ziemlich offensichtlich das du gerade die ersten Gehversuche mit > dieser Programmiersprache machst, da ist es durchaus empfehlenswert > seine Worte sorgfältig abzuwägen. Es war einmal eine Zeit (so ungefähr 1965 - 1985) als heftig überlegt wurde welche Anforderungen eine Programmiersprache erfüllen sollte. N. Wirths Pascal (Modula-2, Oberon), aber auch andere waren dann das Ergebnis. Ich durfte die Suche nach optimalen Entwürfen und Realisierungen miterleben. Heute muss ich leider feststellen, dass der "peak of intelligence" im Bereich der Programmierung überschritten ist. Was einst erarbeitet wurde ist in Vergessenheit geraten. Irgendwann wird es Menschen geben, die darüber nachdenken, was eine Entwicklung wie Python eigentlich ist und wie bessere Programmiersprachen designed sein sollten. Es gilt: Zehn Jahre wächst ein Kamel, dann wird es immer dümmer. Ich versuche mit dem zurecht zu kommen was verfügbar ist. Ggf. auch dann wenn ich es als Mist bezeichnen würde. Was sonst?
Manfred M. schrieb: > Verrätst Du es mir was da noch passiert? file.flush() schreibt den Puffer (im RAM) auf das Medium. In diesem Fall in den Flash Baustein. In der Schleife 4096 Mal, statt einmal zum Schluss. Vermutlich ist darum die Schleife auch so langsam wie von dir beobachtet. Der Flash Speicher hat nur eine begrenzte Menge an Schreibvorgängen garantiert, dann isser hin… > Bitte verrate mir bitte auch, welche Einheit "sps" ist. Im SI-System > fand ich sie leider nicht. Samples per second. Ja sorry, mach ich manchmal automatisch. ;-)
Norbert schrieb: > …oder, falls du die Ariane starten lassen möchtest - mit ADC & 0xFFF0 > ;-) Danke !!!
Manfred M. schrieb: > Es gilt: > Zehn Jahre wächst ein Kamel, dann wird es immer dümmer. Na das hoffe ich doch nicht. Habe hier immer einen Topf mit feuchter Blumenerde neben den Monitoren stehen, da kann ich mich schon mal an den Geruch gewöhnen. ;-)
Norbert schrieb: > Manfred M. schrieb: >> Verrätst Du es mir was da noch passiert? > file.flush() > schreibt den Puffer (im RAM) auf das Medium. In diesem Fall in den Flash > Baustein. OK, so weit weiß ich darüber bescheid. > In der Schleife 4096 Mal, statt einmal zum Schluss. Vermutlich ist darum > die Schleife auch so langsam wie von dir beobachtet. Ja, es kann so sein. Weiß auch gar nicht warum ich das Flushen so oft mache und hab es geändert. Erstaunlich fand ich, dass ich nur "file.flush" im Programm stehen hatte, statt "file.flush()". Das hat gar nichts bewirkt, auch keinen Hinweis des Compilers / Interpreters. So etwas sollte in einer Programmiersprache nicht vorkommen! In diesem Zusammenhang kommt bei mir diese Frage wieder hoch: Wie bekomme ich Dateien vom Pico auf meinen PC? Gehts's mit dem Thonny? Wie oder wie sonst? > Der Flash Speicher hat nur eine begrenzte Menge an Schreibvorgängen > garantiert, dann isser hin… Ist mir bekannt, aber nicht wie viele. Es werden ja seit längerem in PCs sehr gerne SSDs verwendet, was bei mir Bedenken auslöste (weil das OS paged). Ich habe in einem PC auch eine SSD, aber auch sehr viel Mainmemory (32 GB). Habe ich reingesteckt, damit wenige page-faults auftreten. Ist auch so. >> Bitte verrate mir bitte auch, welche Einheit "sps" ist. Im SI-System >> fand ich sie leider nicht. > Samples per second. Ja sorry, mach ich manchmal automatisch. ;-) Nich schlimm, ich frag halt nach wenn ich was nicht verstehe. p löste bei mir Denken an PicoSekunden aus. Da war ich also völlig daneben.
Manfred M. schrieb: > In diesem Zusammenhang kommt bei mir diese Frage wieder hoch: > Wie bekomme ich Dateien vom Pico auf meinen PC? Gehts's mit dem Thonny? ›pyboard.py --help‹ -f, --filesystem perform a filesystem action: cp local :device | cp :device local | cat path | ls [path] | rm path | mkdir path | rmdir path > Ist mir bekannt, aber nicht wie viele. Es werden ja seit längerem in > PCs sehr gerne SSDs verwendet, was bei mir Bedenken auslöste (weil das > OS paged). Ich habe in einem PC auch eine SSD, aber auch sehr viel > Mainmemory (32 GB). Habe ich reingesteckt, damit wenige page-faults > auftreten. Ist auch so. Gut - und ernst - gemeinter Rat, vergiss die Bedenken. Selbst ein für wildes swappen bekanntes käufliches Betriebssystem wird das Ding bei 32GiB RAM nicht plattmachen. Nicht während der übliche PC-Lebenszeit. 9 Power_On_Hours 0x0032 096 096 000: 17039 177 Wear_Leveling_Count 0x0013 099 099 000: 13 241 Total_LBAs_Written 0x0032 099 099 000: 9329056384 nach 17000 Stunden sind 13 von 1000, also 1,3% der Lebenskraft ausgesaugt. Bei 4,77*10^12 Bytes, also ungefähr 4 1/2 TiB geschrieben.
Manfred M. schrieb: >> Der Flash Speicher hat nur eine begrenzte Menge an Schreibvorgängen >> garantiert, dann isser hin… > > Ist mir bekannt, aber nicht wie viele. Es werden ja seit längerem in > PCs sehr gerne SSDs verwendet, was bei mir Bedenken auslöste Entscheidend ist, welches Dateisystem microPython verwendet. Der Flash-Chip kann wie eine Festplatte mit 4K-Sektoren und 3ms Zugriffszeit benutzt werden, es ist also alles möglich. Falls das Datenblatt stimmt, verwendet das originale Modul "Raspberry Pi Pico Rev3" einen Winbond W25Q16JVUXIQ. Dessen Datenblatt spezifiziert weder Schreibzyklen noch Datenerhalt. Der Werbetext sagt immerhin "mehr als 100'000 Zyklen, mindestens 20 Jahre". Das sind normale Werte für NOR-Flash. Die 20 Jahre gelten natürlich nur bei Zimmertemperatur und frischem Chip. Zum Vergleich: das Flash in den STM32 ist mit 10'000 Zyklen und danach noch 15 Jahren bei 85°C spezifiziert.
Manfred M. schrieb: > Ich verstehe nicht, welchen Sinn es haben soll, diese Antennen mit > meiner Schaltung zu verbinden. Du hast jetzt 'Antennen', die den 'Müll' in der Luft einfangen. Wenn Du diese auf Masse-Potential bringst, geht der 'Müll' aufs Ground. Und verbunden hast Du es ja schon von Anfang an, das ist ja das Problem. Und dann noch schön aufgerollt unter dem Steckbrett (laut Foto). Das ist wie ein Staubsauger. Aber wenn Du es nicht versuchen willst, dann musst Du Dich mit 'Schönrechnen' abquälen.
PC-Freak schrieb: > Manfred M. schrieb: >> Ich verstehe nicht, welchen Sinn es haben soll, diese Antennen mit >> meiner Schaltung zu verbinden. > > Du hast jetzt 'Antennen', die den 'Müll' in der Luft einfangen. Wenn Du > diese auf Masse-Potential bringst, geht der 'Müll' aufs Ground. Es ist nicht nötig mir zu schreiben als wär ich Grundschüler > Und verbunden hast Du es ja schon von Anfang an Ich wüsste nicht, dass ich diese Antennen oder Spulen irgendwohin verbunden hätte. Aber vielleicht verstehe ich Dich besser wenn Du mir mitteilst: Was meinst Du mit "von Anfang an". Welcher Anfang? Dem Anfang der Abschirmung? Oder von was??? Hier im Haus gibt es einen PE-Leiter, der zu einem Erdspieß führt; soll ich diesen benutzen, um die induzierten Spannungen abzuleiten? In meiner Schaltung will ich sie jedenfalls nicht haben. > das ist ja das Problem. > Und dann noch schön aufgerollt unter dem Steckbrett (laut Foto). Das ist > wie ein Staubsauger. Und sind faradaysche Käfige für die Leitungen zum Pt1000. Wenn ich das ganze Zeug noch in einen metellenem Geuse untergebracht habe, den pico mittels Batterie, die auch da drin ist mit Strom versorge, dann ist alles in einem faradayschen Käfig. Ich hoffe, das Du weißt was das ist. Es ist nicht nötig mir zu schreiben als wär ich Grundschüler oder in einer Kita. > > Aber wenn Du es nicht versuchen willst, dann musst Du Dich mit > 'Schönrechnen' abquälen.
mit "metellenem Geuse" meinte ich ein "metallenes Gehäuse"
So jetzt überlege ich, ob ich einen OpAmp einsetzen sollte. Meine Eingangsspannung zum ADC liegt bei 0,8 V und könnte /sollte m.E. also höher sein, um den Messbereich des ADC gut auszunutzen. Als Versorgungspannungen kämen die in Betracht, die am Pico vorhanden sind, also ca. 5 oder ca. 3,3 V. Momentan messe ich im Bereich des Pt1000 von 1000 bis 1200 Ohm Was nehme ich?
Manfred M. schrieb: >>> Bitte verrate mir bitte auch, welche Einheit "sps" ist. Im SI-System >>> fand ich sie leider nicht. >> Samples per second. Ja sorry, mach ich manchmal automatisch. ;-) > Nich schlimm, ich frag halt nach wenn ich was nicht verstehe. p löste > bei mir Denken an PicoSekunden aus. Da war ich also völlig daneben. Mach dir nichts draus. Auf Oszis findest du auch oft Sa/s. Das kann jeder machen, wie er möchte. Nur darf er sich dann nicht wundern, wenn andere das nicht verstehen.
Datenblätter: STM32F1: MSPS STM32F4: MSPS AT90:kSPS ATtiny:kSPS ATmega:kSPS rp2040:kS/s ESP32:ksps und Msps Macht wirklich jeder wie er will…
Norbert schrieb: > Macht wirklich jeder wie er will… Alleine schon in dem Zusammenhang ein großes "S" zu verwenden, das im SI gewöhnlich für die Einheit des elektrischen Leitwertes steht, halte ich für "kreativ". https://de.wikipedia.org/wiki/Internationales_Einheitensystem#Abgeleitete_SI-Einheiten_mit_besonderem_Namen
Manfred M. schrieb: > Es ist nicht nötig mir zu schreiben als wär ich Grundschüler oder in > einer Kita. Es erscheint aber auch mir so, als benähmst Du Dich manchmal(!) so. Abschirmgeflecht auf Leitungen ist eben kein Faradayscher Käfig, sondern nur eine zwar notwendige, aber nicht hinreichende Vorbedingung dazu. Und einfach zu behaupten, es sei ein Faradayscher Käfig ist Grundschülerniveau, nichts Anderes. Will man Fehler finden, so muß man in der Lage sein, auch die eigenen Gewißheiten immer und immer wieder in Frage zu stellen, Halsstarrigkeit hilft da nicht weiter (die ist für andere Sachen gut ;-). Deswegen mein Tipp: Einen Gang runterschalten (oder einen Schritt zurücktreten) und mit kühlem Kopf nochmal die Realitäten checken. Fakt ist, daß bei Temperaturmessungen plus/minus 2 Kelvin der ganz normale Grundzustand ist. Kaufe 10 billige Thermometer und lege sie nebeneinander, dann kommt genau das dabei raus (been there, done that). Will man besser sein, muß man Hirnschmalz investieren. Ein einzelner PT1000 reicht nicht aus, erst wenn alles Andere drumherum dieselbe Genauigkeitsklasse hat, erreicht auch das Endergebnis diese Genauigkeitsklasse. Und daß ein fliegender Aufbau eine einzige große Antenne für 50-Hertz-Brumm ist, ist so gewiß wie das Amen in der Kirche. Bisher ist dieser Thread in meiner Sammlung absoluter Spitzenreiter darin, wie man es nicht machen sollte. Als unerschrockener Optimist habe ich aber die Hoffnung, daß man den Trend noch wenden könnte, auch wenn Einige schon entsetzt die Flucht ergriffen haben. Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Außerdem würde ich gern schlauer werden und dazulernen, ob die erwähnten > Unregelmäßigkeiten nun am ADC oder an micropython liegen, da ich > ebenfalls einen RP2040 habe (und ihn wegen der PIOs schätze, billiger > als ein BeagleBone!) und auf micropython gut verzichten kann, auf den > ADC aber nur ungern. > Aber dazu muß ich wohl in den sauren Apfel beißen und tatsächlich alles > lesen. Was hier vom TO geschrieben wurde, kannste Du einfach in die Tonne kloppen. Seine Vorgehensweise muß man als eher destruktiv bezeichnen. Entweder versteht oder befolgt er die Antworten garnicht, beachtet nur die "Jubelperser" oder trollt mit Schwafelgeschichten aus der Vergangenheit. Nichts, um etwas dazuzulernen. Zum ADC gibt es nicht viel zu lesen, da sich das Datenblatt dazu ausschweigt. Ein geschickter Schachzug, da konkrete Datenblattangaben ja überprüfbar wären. So muß keine Spezifikation eingehalten werden. Bleibt folglich nur Ausprobieren. Der ADC bei meinem 2040 hat einen 0-Offset von 16. Das ist 8-Bit Niveau. Auch eine Mittwelwertbildung über noch so viele Zyklen wird es nicht schaffen, Offset-, Verstärkungs- oder Linearitätsfehler auszugleichen. Der ADC ist daher nur bedingt brauchbar. Im Vergleich mit einem AVR liefern dessen 10 Bit verlässlichere Ergebnisse. Wenn Du nahe 12 Bit Linearität/Genauigkeit brauchst, nimm einen externen ADC. Der günstige Preis relativiert sich dadurch natürlich.
m.n. schrieb: > Nichts, um etwas dazuzulernen. Ganz so schlimm ists auch nicht. Ich hab dem Thread entnommen, wie micropython mit einer mir vorher nicht geläufigen Methode von 12bit auf 16bit hochskaliert. Könnte vielleicht mal für Tests nützlich sein. Ein kleines bißchen mehr als Nichts, immerhin :-) Wirkungsgrad ist allerdings bisher unterirdisch. Wenn der Thread mir aber dazu nützt, ein Projektreinfall mit RP2040/ADC zu vermeiden, hat es sich wieder bezahlt gemacht. > Der ADC bei meinem 2040 hat einen 0-Offset von 16. Das ist 8-Bit Niveau. Da hab ich auch schon wieder was dazugelernt, danke. Gruß Klaus (der soundsovielte)
Klaus S. schrieb: > Der ADC bei meinem 2040 hat einen 0-Offset von 16. aus niedrigstem Bit = 1 macht der Algorithmus von Raspberry eine 16 durch shiften Zur Beseitigung s. 16.03.2022 23:41 und 23:54 > Das ist 8-Bit Niveau. Nein
So macht es der Pico: raw << (16 - bits) | raw >> (2 * bits - 16) mit bits=12
Manfred M. schrieb: > Ein > Grund dafür ist, dass es viele Anforderungen, die für das Design von > Programmiersprachen entstanden, nicht erfüllt. Nur eine: Jede Variable > muss deklariert werden. Nö einen Shitstorm löst Du damit nicht aus, Du zeigst nur das Du wirklich nicht viel Ahnung hast. Üblicherweise muß man in fast jeder Programmiersprache Variablen die zu benutzen gedenkt deklarieren. Und ja es gibt auch Ausnahmen wo das nicht so ist - auf die Schnelle fällt mir da JS ein. Langsam wird das Gezerre um das simple Auslesen eines ADC auch recht peinlich. Eigentlich bekommt das jeder Scriptkiddie mit Copy&Paste hin.
Zeno schrieb: > Manfred M. schrieb: >> Ein >> Grund dafür ist, dass es viele Anforderungen, die für das Design von >> Programmiersprachen entstanden, nicht erfüllt. Nur eine: Jede Variable >> muss deklariert werden. > Nö einen Shitstorm löst Du damit nicht aus, Du zeigst nur das Du > wirklich nicht viel Ahnung hast. So ist es! > Üblicherweise muß man in fast jeder > Programmiersprache Variablen die zu benutzen gedenkt deklarieren. Und ja > es gibt auch Ausnahmen wo das nicht so ist - auf die Schnelle fällt mir > da JS ein. > > Langsam wird das Gezerre um das simple Auslesen eines ADC auch recht > peinlich. Eigentlich bekommt das jeder Scriptkiddie mit Copy&Paste hin. Seit s. 16.03.2022 23:41 und 23:54 ist da alles klar. Was dann noch kam, war, bis auf wenige Ausnahmen, nur noch shit. Ich stimme Dir also voll zu!
Klaus S. schrieb: >> Der ADC bei meinem 2040 hat einen 0-Offset von 16. Das ist 8-Bit Niveau. > > Da hab ich auch schon wieder was dazugelernt, danke. Weil hier schon wieder geschwafelt wurde: der von mir genannte Offest von 16 bezieht sich auf die effektiven 12 Bit des ADC. Würde ich das per Python einlesen wäre der Wert ca. 256. Dabei habe ich noch Glück gehabt, daß der Offset positiv ist. Wäre er negativ gewesen, hätte ich gutgläubig gedacht: na, der hat ja einen sauberen 0-Punkt ;-) Klar, man kann das alles skalieren, aber andere Hersteller liefern bessere ADCs mit entsprechendem Datenblatt. Klaus S. schrieb: > Wenn der Thread mir > aber dazu nützt, ein Projektreinfall mit RP2040/ADC zu vermeiden, hat es > sich wieder bezahlt gemacht. Bislang habe ich nur ganz wenige Beiträge zum RP2040 gefunden, die Substanz haben. Ob das Teil nur Spielzeug ist oder doch zu etwas Nützlichem zu gebrauchen ist, kann ich noch nicht sagen. Aber das würde in diesem Beitrag zu weit abschweifen.
m.n. schrieb: > Zum ADC gibt es nicht viel zu lesen, da sich das Datenblatt dazu > ausschweigt. Ein geschickter Schachzug, da konkrete Datenblattangaben ja > überprüfbar wären. So muß keine Spezifikation eingehalten werden. In frühen Versionen des RP2040 Datenblatts war das ganz eindeutig so. Inzwischen steht zumindest etwas zum ADC und auch dessen "DNL error peaks" darin. Ich hoffe es gibt irgenwann mal eine verbesserte Hardware, bisher deutet aber nichts darauf hin. m.n. schrieb: > Im Vergleich mit einem AVR > liefern dessen 10 Bit verlässlichere Ergebnisse. Das ist wohl so, aber der ADC eines megaAVR ist mit "Up to 15 ksps at maximum resolution" auch deutlich langsamer als der ADC des RP2040 mit 500000 Samples pro Sekunde. Auf dem RP2040 kann man über 32 Samples mitteln und ist immer noch so schnell wie der megaAVR. Die höhere Geschwindigkeit bedingt natürlich auch eine kleinere Kapazität in der Samplingstufe, im RP2040 Datenblatt steht "The ADC input is capacitive, and when sampling, it places about 1pF across the input". Beim megaAVR kann der Kondensator in der Sample and Hold Stufe eine Menge der höherfrequenten Einstreuungen wegbügeln. Ein großer Teil des "Rauschens" beim Pico dürfte tatsächlich vorhandene Signale am Eingang des ADC sein, sei es aus der Umgebung oder auf dem Board selbst durch Schaltregler und Controller erzeugt.
Manfred M. schrieb: > So jetzt überlege ich, ob ich einen OpAmp einsetzen sollte. Eher nicht, denn damit verstärkst du alle Störungen und fügst das Rauschen des OP-Amp hinzu. Kann gut sein, dass es damit sogar schlechter wird als ohne.
Stefan schrieb: >> Im Vergleich mit einem AVR >> liefern dessen 10 Bit verlässlichere Ergebnisse. > Das ist wohl so, aber der ADC eines megaAVR ist mit "Up to 15 ksps at > maximum resolution" auch deutlich langsamer als der ADC des RP2040 mit > 500000 Samples pro Sekunde. Wer sagt denn, daß es unbedingt schnell sein muß? Beim AVR habe ich die Möglichkeit, die Sample-Zeit durch passenden Vorteiler zu verlangsamen, um damit die Quelle nicht zu sehr zu belasten. Beim 2040 rennt der ADC immer mit 500 kHz. Einzig die Auswahl vom internen Oszillator bremst ihn etwas aus. Schneller muß nicht immer besser sein. > Ich hoffe es gibt irgenwann mal eine verbesserte Hardware, > bisher deutet aber nichts darauf hin. Das bedeutet auch: wenn man die Leistungsgrenze erreicht hat, hängt man fest. Die Hardware ist schon speziell, sodaß ein Umstieg wieder bei Null beginnen kann. Wie gesagt, richtige Anwendungen mit dem 2040 habe ich noch nicht gesehen - insbesondere auch keine, die den 2. Kern nutzen. Die Beispielprogramme sind ja nett, hauen einen aber auch nicht vom Hocker. Schnell mit den Beinen zu wackeln, ist ja nicht alles im Leben. Dem TO nützen die speziellen Eigenschaften des RP2040 überhaupt nicht. Für seine Aufgabe hätte auch ein Arduino mit ATmega328 gereicht.
m.n. schrieb: > Wer sagt denn, daß es unbedingt schnell sein muß? > Beim AVR habe ich die Möglichkeit, die Sample-Zeit durch passenden > Vorteiler zu verlangsamen, um damit die Quelle nicht zu sehr zu > belasten. Beim 2040 rennt der ADC immer mit 500 kHz. Einzig die Auswahl > vom internen Oszillator bremst ihn etwas aus. Schneller muß nicht immer > besser sein. Der AVR hat einen Vorteiler ÷1, ÷2, ÷4, … ÷128. Der rp2040 ADC hat einen frei programmierbaren Vorteiler von 1…65535 in 1/256 Schritten. Das Register liegt bei: ADC_BASE + DIV 16bit Integer divider und 8bit Fractional divider Eigentlich ist das im Datenblatt nachzulesen…
Ich verstehe das RP2040 Datenblatt anders, Da steht "Pacing timer (16 integer bits, 8 fractional bits) for setting free-running sample rate" und "Setting DIV.INT to some positive value n will trigger the ADC once per n + 1 cycles, though the ADC ignores this if a conversion is currently in progress, so generally n will be >= 96. For example, setting DIV.INT to 47999 will run the ADC at 1 kS/s, if running from a 48 MHz clock" Pacing Timer würde ich nicht zu Vorteiler übersetzen. Die Zeit für eine Wandlung und damit auch die Sample-Zeit, in der der Eingangskondensator aufgeladen wird, wird damit nicht verändert sondern nur die Zeit bis zum Start der nächsten Abtastung. m.n. schrieb: > Wer sagt denn, daß es unbedingt schnell sein muß? Keiner, aber wenn der ADC auch schnell können soll, muss der interne Kondensator klein sein. m.n. schrieb: > Dem TO nützen die speziellen Eigenschaften des RP2040 überhaupt nicht. > Für seine Aufgabe hätte auch ein Arduino mit ATmega328 gereicht. Dann hättet er aber nicht über Micropython schimpfen können.
Stefan schrieb: > Pacing Timer würde ich nicht zu Vorteiler übersetzen. Die Zeit für eine > Wandlung und damit auch die Sample-Zeit, in der der Eingangskondensator > aufgeladen wird, wird damit nicht verändert sondern nur die Zeit bis zum > Start der nächsten Abtastung. Technisch gesehen richtig, jedoch ist der Sampling-Kondensator 1pF. Er schrieb: > um damit die Quelle nicht zu sehr zu belasten. Wenn der Kondensator voll ist - und bei einem einsamen pF dauert das jetzt nicht sooo lange - kann man auch eine Doppelwoche zwischen den Messungen warten und es würde an der Belastung der Eingangsspannung nichts ändern.
Ja, aber aber ADC sieht immer nur das, was zur Sample-Zeit von einer oder wenigen 48MHz Perioden gerade am Eingang anliegt. Ein kleiner Kondensator und ein Widerstand als Tiefpass direkt am Eingang könnten einen Großteil der Störungen herausfiltern.
Das ist die aktuelle Schaltung: > R1 R2 > |---------| |----------| > GND ------| Pt1000 |-------| 3k3 |------- ADC_VREF > |---------| ^ |----------| > U1 | U2 > | > GND ---------------- ADC Und nun? Sollte sie so sein: R1 R2 |---------| |----------| GND ------| Pt1000 |-------| 3k3 |------- ADC_VREF |---------| ^ |----------| U1 | U2 C | GND---------| |---------| hier??? Wieviele Fs? | GND ---------------- ADC ?????????????????? Ich meine (vermute), dass ich besonders die hohen Frequenzen ableiten sollte, wobei "hoch" ja eigentlich ab 50 Hz beginnt, vielleicht sogar schon ab 16+2/3 Hz Zur Erinnerung: Ich will Temperaturen (der Luft, von Wasser oder in hohlen Wänden messen), habe also Änderungen von kaum mehr als 1 K je Minute (wenn überhaupt so viel). Alle induzierten Spannungen will ich nicht messen. Momentan lese ich je 17 msek einen Wert ein, der bei ca. 0,8 V liegt, bis ich 588 Werte habe (ergibt knapp 10 sek) und berechne daraus ein arith. Mittel. Dadurch sollten Störspannungen mit 16 2/3 Hz und darüber ausgemittelt werden. Müsste ich jetzt mal nachdenken, ob vielleicht ein arith. Überlauf auftreten könnte? 588 1000 bis 588 3000 (für 0 °C bis ... °C), wenn aber Integers fast beliebig lang werden dürfen (wie es bei solchen in Python der Fall zu sein scheint (???) ) ... Weiß hier jemand mehr (als ich) darüber? Aber interessant finde ich, abgesehen von meinen Ziel, was man mit einem Pico auch noch messen könnte und dabei die Einwände / Bedenken berücksichtigt, die hier ob schon formuliert wurden. Dabei würden mich aber zuerst mal nur Veränderungen interessieren, die ein Mensch oder jedes Tier erträgt. z.B. mal bei einem Fische jagenden, also tauchenden Vogel messen wie er beschleunigt wird (erst mal im Sturzflug, dann im Wasser --- Wasser kann hart sein). So diverse "Spielereien" eben, die aber halt doch reale Werten liefern (solchen mit denen man dann wirklich etwas anfangen kann). Oder kleinräumige Änderungen von RR (Luftfeuchte), p (Luftdruck) und Luft-Temp (damit kann man die Entstehung insbes. den zukünftigen Ort von Gewittern prognostizieren - rel. kurzfistig). Hat eine(r) von Euch schon mal gemessen wie sich die Temp. im Inneren eines Eies abhängig von der Entfernung zur Schale beim Kochen ändert? Diese ändert sich keineswegs gleichmäßig, weshalb man ein Hühnerei so kochen kann, dass sich ein cremiger Dotter in festem Eiweiß befindet (ich kann das nicht, aber gute Köche schon).
Stefan schrieb: > Ja, aber aber ADC sieht immer nur das, was zur Sample-Zeit von > einer > oder wenigen 48MHz Perioden gerade am Eingang anliegt. Ein kleiner > Kondensator und ein Widerstand als Tiefpass direkt am Eingang könnten > einen Großteil der Störungen herausfiltern. Klar. Aber andere Baustelle. Wir hatten die ganze Zeit vom sample-and-hold Kondensator geredet. Sicherlich kann man "Draussen" filtern, aber die diskutierte Vorteiler/Pacing Timer Thematik berührt das nicht im Geringsten.
Manfred M. schrieb: > Ich meine (vermute), dass ich besonders die hohen Frequenzen ableiten > sollte, wobei "hoch" ja eigentlich ab 50 Hz beginnt, Das weißt du nicht! > vielleicht sogar schon ab 16+2/3 Hz Das weißt du nicht! > Momentan lese ich je 17 msek einen Wert ein, der bei ca. 0,8 V liegt, > bis ich 588 Werte habe (ergibt knapp 10 sek) und berechne daraus ein > arith. Mittel. Dadurch sollten Störspannungen mit 16 2/3 Hz und darüber > ausgemittelt werden. Du machst du das vermutlich mit dem sleep/delay Befehl. Dann ist dein ganzer Ansatz Grütze, denn (zeitliche) Ungenauigkeiten und die Laufzeit des zusätzlichen Codes summieren sich während deiner Messperiode. Aber es ist zumindest ein guter Ansatz um sich das Leben schwerer zu machen als es sein müsste.
Manfred M. schrieb: > GND---------| |---------| hier??? Wieviele Fs? Irgendwas von 100pF bis 100nF direkt und mit möglichst kurzen Beinchen an die Anschlüsse des Pico-Boards gelötet, jeweils zwischen AGND und Eingang.
Stefan schrieb: > Manfred M. schrieb: >> GND---------| |---------| hier??? Wieviele Fs? > > Irgendwas von 100pF bis 100nF direkt und mit möglichst kurzen Beinchen > an die Anschlüsse des Pico-Boards gelötet, jeweils zwischen AGND und > Eingang. OK, Dank, werde ich so machen wenn ich den Pico in ein Gehäuse setze. Ich wollte ja erst mal wissen, ob mein Code halbwegs funktioniert. Leider weiß noch nicht wie ich ein halbwegs sinnvolles Exception-Handling machen müsste; z.B. wie ein Exept filenotfound oder Except diskfull richtig zu formulieren wäre.
Norbert schrieb: > Manfred M. schrieb: >> Ich meine (vermute), dass ich besonders die hohen Frequenzen ableiten >> sollte, wobei "hoch" ja eigentlich ab 50 Hz beginnt, > Das weißt du nicht! > >> vielleicht sogar schon ab 16+2/3 Hz > Das weißt du nicht! Das verstehe ich jetzt nicht. Ich weiß doch, dass fast überall Spannungen mit ca. 50 Hz induziert werden, vielleicht sogar mit 16+2/3 Hz. > >> Momentan lese ich je 17 msek einen Wert ein, der bei ca. 0,8 V liegt, >> bis ich 588 Werte habe (ergibt knapp 10 sek) und berechne daraus ein >> arith. Mittel. Dadurch sollten Störspannungen mit 16 2/3 Hz und darüber >> ausgemittelt werden. > Du machst du das vermutlich mit dem sleep/delay Befehl. ja, mit sleep > Dann ist dein ganzer Ansatz Grütze, denn (zeitliche) Ungenauigkeiten und > die Laufzeit des zusätzlichen Codes summieren sich während deiner > Messperiode. Ist mir bewusst. Da ist zB eine Division in der Schleife. Früher war es so dass Divisionen ziemlich lange dauerten. Ist vermutlich heute noch so (???). Aber: Wie sehr verändert das die Messungen? Geschickter könnte es sein, wenn ich die Zeitabstände zwischen den Abfragen der Rohwerte mittels einem Zufallsgenerator streue. Ich nehme bewusst eine Phasenverschiebung hin, versuche also gar nicht im genauen Abstand von 20 ms zu messen, statt dessen nehme ich sleep_ms(17) ohne zu wissen wie exakt der Pico diese 17 ms einhält (also 17 + x ms), addiere 588 Messwerte (wie lange könnte das dauern? Länger als 10 sec?) und lass dies durch 588 teilen. Ich summiere 588 Messwerte, die in ca. 500 Perioden der 50 Hz liegen (die 500 sind - meistens - m.W. sehr genau, aber trotzdem ungenau). Bewusst nehme ich hin, dass sich die Phasenlage der Messungen verschiebt (588 * 17 ms = 9,996 sec) und meine, dass das gar nicht so ungeschickt ist (aber vielleicht doch, weil ich irgendwas übersehen habe), denn der Versuch, stets die gleiche Phasenlage zu erreichen, wird scheitern (zB weil die 50 Hz doch etwas ungenau sind und die 588 Additionen auch einige Zeit dauern). Dann dividiere ich, schreibe die Ergebnisse in Flash-Memory und beginne bei einer mir nicht bekannten Phase von vorn. Vielleicht wäre es geschickter, weil schneller, nur 512 Werte zu summieren und deren Summe um 9 bits nach rechts zu verschieben. > > Aber es ist zumindest ein guter Ansatz um sich das Leben schwerer zu > machen als es sein müsste. Diesem Satz entnehme ich, dass Du weißt wie ich das durch geschickteren Code vermeiden könnte. Wie? Was man geschickter machen sollte, mag ja bei Spezialisten von digitalen Messverfahren Folklore sei, doch leider kenne ich diese nicht. Kannst Du mir sagen wieviele Bits eine Integerzahl in Micropython sein darf? Vielleicht auch wo das steht? VG
Manfred M. schrieb: > Das verstehe ich jetzt nicht. Ich weiß doch, dass fast überall > Spannungen mit ca. 50 Hz induziert werden, vielleicht sogar mit 16+2/3 > Hz. Da weißt du mehr als die meisten anderen Menschen. Die würden es bestenfalls vermuten und überprüfen. Und feststellen das es sehr (SEHR) oft nicht so ist. > Diesem Satz entnehme ich, dass Du weißt wie ich das durch geschickteren > Code vermeiden könnte. Wie? Was man geschickter machen sollte, mag ja > bei Spezialisten von digitalen Messverfahren Folklore sei, doch leider > kenne ich diese nicht. Hatten wir bereits vor gefühlt 500 posts schon durch. Also kurz nach dem Ende des Pleistozän. > Kannst Du mir sagen wieviele Bits eine Integerzahl in Micropython sein > darf? Vielleicht auch wo das steht? Unendlich viele. Erst ungefähr(¹) Maschinenbreite (schnell), dann unendlich (langsamer). Steht in den Docs. ¹: Ich spar' mir die genaue Beschreibung, steht auch in den Docs.
Zur Abwechselung habe ich mal die Arduino-IDE genommen. Die .txt-Datei zeigt die Raumtemperatur (hier war als Offset noch 0 eingestellt, weshalb sie zu hoch ist) und dann Erwärmung und Abkühlung des Sensors mit einem Lötkolben. An Eingang A0 sind nur PT1000 gegen GND und 1 k gegen ADC_Vref angeschlossen. Das sollte dann endgültig reichen.
m.n. schrieb: > ... > An Eingang A0 sind nur PT1000 gegen GND und 1 k gegen ADC_Vref > angeschlossen. > Das sollte dann endgültig reichen. also fließen bei 0 °C durch den PT1000; 3,3 V/ 2000 V/A= 1,65 mA, also Verlustleistung im Pt1000 (bei 0°C): R*I^2 = 2,7225 mW Lt. Posting vom 14.03.2022 19:01 also zu viel, s. Zeno schrieb: > Beim Pt100 wird im allgemeinen von einem max. Messstrom von 1mA > ausgegangen, was dort 0,1mW entspricht. 1mA beim Pt1000 wären dann 1mW. > Mit anderen Worten der Strom sollte für den Pt1000 deutlich niedriger > als Deine 2mA sein. Ich weiß halt nicht, ob das was "Zeno" schrieb, richtig ist. In dem Datenblatt, das ich mit den Pt1000 bekam steht < 2 mA, eine Norm für Pt1000 gibt es m.W. auch, doch auf die habe ich hier keinen Zugriff. Ich verwende ca. 4k3, wäre also (bei 0 °C) I= 0,767 mA somit Verlustleistung ca. 0,59 mW. Inzwischen ist ein Metallgehäuse bestellt. Akkus habe ich. Unklar ist mir immer noch wie ich die exceptions abfangen könnte, die auftreten könnten. Leider fand ich kein Beispiel wie die Exceptions zu bezeichnen sind, welches Modul ggf. noch geladen werden müsste.
Manfred M. schrieb: > Lt. Posting vom 14.03.2022 19:01 also zu viel, s. > Zeno schrieb: >> Beim Pt100 wird im allgemeinen von einem max. Messstrom von 1mA >> ausgegangen, was dort 0,1mW entspricht. 1mA beim Pt1000 wären dann 1mW. >> Mit anderen Worten der Strom sollte für den Pt1000 deutlich niedriger >> als Deine 2mA sein. > Ich weiß halt nicht, ob das was "Zeno" schrieb, richtig ist. Siehe hier https://asset.conrad.com/media10/add/160267/c1/-/gl/000125029DS01/datenblatt-125029-tauchfuehler-b-b-thermo-technik-0629-0514-55-40-bis-180-c-pt1000.pdf Dort steht: empfohlener Messstrom 0,1-0,3mA. Was das in mW ausmacht kannst Du selber ausrechnen.
Zeno schrieb: > Siehe hier > ttps://asset.conrad.com/media10/add/160267/c1/-/gl/000125029DS01/datenbl att-125029-tauchfuehler-b-b-thermo-technik-0629-0514-55-40-bis-180-c-pt1 000.pdf > Dort steht: empfohlener Messstrom 0,1-0,3mA. Was das in mW ausmacht > kannst Du selber ausrechnen. Seltsam, dass so unterschiedliche Daten angegeben werden. Übrigens: Bei B+B fand ich die Sensoren, die Conrad nennt, nicht. Mich würde nun interessieren was denn eigentlich in der Norm zu PT100 / PT1000 / PT2000 steht, sofern es eine gibt.
Inzwischen habe ich: Frank Bernhard (Hrsg.): Technische Temperaturmessung, 2. Aufl. Springer 2014 1619 Seiten Uff ---- aber die Widerstandsthermometer werden auf "nur" 154 Seiten behandelt, wobei mir momentan noch unklar ist, wieviel aus den 677 Seiten davor ich wissen (und verstanden haben) müsste, um diese weiteren Seiten zu verstehen. Ich könnte leihen: Klaus Irrgang (Hrsg.): Temperaturmesspraxis mit Widerstandsthermometern und Thermoelementen, Vulkan, 2004 über das Buch weiß ich (noch) nicht mehr als hier steht.
@ Nobert und alle, die mehr wissen als ich, mir dennoch helfen wollen Mir wurden bereits viele hilfreiche Hinweise gesendet, wofür ich sehr dankbar bin. Doch neuerdings bekomme ich Verweise auf die Doku zum Pico und zu Micropython, ohne genau mitzuteilen, wo was steht (z.B. durch einen Link). Ich bitte um Mitteilung von Details (Links zu diesen) zu Folgendem: 1. Wo finde ich diesen Code: from machine import mem8 PADS_BANK0_BASE = const(0x4001c000) # s. 4.9.6. List of Registers p.590 in Datasheet 2.19.6.3. Pad Control - User Bank S. 323 GPIO26 = const(0x6c) ... mem8[PADS_BANK0_BASE + GPIO26] = 1 << 7 ... Ich las das schon mal in einer Doku, weiß aber nicht mehr wo. Habe gesucht, doch nicht wieder gefunden. 2. Exceptions Ich will noch Bearbeitungen einiger Exceptions programmieren, müsste dafür solche voneinander unterscheiden könne, weiß aber nicht wie. 3. Ich möchte aus Win-10 auf Dateien des Pico zugreifen. Wie könnte das funktionieren? Und wie geht es aus einem anderen Raspberry z.B. mit einem Raspian? Wo genau kann ich Details nachlesen? 4. Ich fand eine Beschreibung wie der Pico stand alone (ohne Verbindung via USB) in Betrieb gesetzt werden kann, aber keine Info wie ich ihn aus diesem Verhalten wieder heraus bekomme. Wie? VG MM
Manfred M. schrieb: > 1. Wo finde ich diesen Code: ……… > Ich las das schon mal in einer Doku, weiß aber nicht mehr wo. Habe > gesucht, doch nicht wieder gefunden. Kein Wunder, der ist von mir. Und direkt dabei steht die Referenz zum Datenblatt. > 2. Exceptions > Ich will noch Bearbeitungen einiger Exceptions programmieren, müsste > dafür solche voneinander unterscheiden könne, weiß aber nicht wie. Du hattest bereits den Hinweis auf die vollständige Python Docs von mir bekommen. Wenn dir das Konzept der Suche nicht völlig fremd ist, das geht dort auch. > 3. Ich möchte aus Win-10 auf Dateien des Pico zugreifen. Wie könnte das > funktionieren? Und wie geht es aus einem anderen Raspberry z.B. mit > einem Raspian? Wo genau kann ich Details nachlesen? Das hatte ich dir bereits gesagt! > 4. Ich fand eine Beschreibung wie der Pico stand alone (ohne Verbindung > via USB) in Betrieb gesetzt werden kann, Spannung dran! > aber keine Info wie ich ihn aus > diesem Verhalten wieder heraus bekomme. Wie? und wieder weg! So wie ich. Das war's für mich. Lies das Python Tutorial. Mehrmals! Lies die Library Referenz.
Manfred M. schrieb: > also fließen bei 0 °C durch den PT1000; 3,3 V/ 2000 V/A= 1,65 mA, also > Verlustleistung im Pt1000 (bei 0°C): R*I^2 = 2,7225 mW Multipliziert mit dem Tastverhältnis von 7 * 10^-5 ergibt dann effektiv ca. 190 nW. Das soll zu viel sein?
Manfred M. schrieb: > Zeno schrieb: >> Siehe hier >> ttps://asset.conrad.com/media10/add/160267/c1/-/gl/000125029DS01/datenbl > att-125029-tauchfuehler-b-b-thermo-technik-0629-0514-55-40-bis-180-c-pt1 > 000.pdf >> Dort steht: empfohlener Messstrom 0,1-0,3mA. Was das in mW ausmacht >> kannst Du selber ausrechnen. > > Seltsam, dass so unterschiedliche Daten angegeben werden. > Übrigens: Bei B+B fand ich die Sensoren, die Conrad nennt, nicht. Man kann es in mehreren Quellen nachlesen, die von mir gepostete ist nur eine. Ansonsten gilt für Pt100/Pt1000, das die im Sensor umgesetzte Verlustleistung so gering wie möglich sein soll, um eine Eigenerwärmung des Sensor zu minimieren. Für den Pt100 hat sich ein dauernder Messstrom von max. 1mA, entspricht 0,1mW, als brauchbar erwiesen. Der Pt1000 hätte halt bei gleichem Strom eine Verlustleistung von 1mW. Die Krux ist, das geringerer Messstrom auch ein geringes dU/dT zur Folge hat. Irgendwann ist Spannungsänderung so gering das sie nur noch mit erhöhten schaltungstechnischen Aufwand vernünftig erfasst werden kann. Verringert man den Strom jetzt noch weiter dan geht die Änderung sehr wahrscheinlich im Rauschen unter. Man muß also einen Kompromiß zwischen möglichst geringer Eigenerwärmung und möglichst großem dU/dT finden. Geringe Eigenerwärmung erreicht man, indem möglichst wenig Leistung im Messwiderstand umgesetzt wird. Da sind zwei Wege möglich: 1. (Dauer)Strom so gering wie möglich, damit Dauerleistung so gering wie möglich. 2. Gepulster Betrieb, so wie von m.n. vorgeschlagen/umgesetzt, mit höherem Strom. Dadurch hat man eine geringe Dauerleistung (geringe Eigenerrwärmung), weil der hohe Strom nur kurzzeitig fließt und ein hohes gut auswertbares dU/dT. Wie Du Dich nun entscheidest ist nunmehr Deine Sache. Vorschläge wurden mittlerweile genug unterbreitet.
Manfred M. schrieb: > Inzwischen habe ich: > Frank Bernhard (Hrsg.): Technische Temperaturmessung, 2. Aufl. Springer > 2014 > 1619 Seiten Uff ---- > aber die Widerstandsthermometer werden auf "nur" 154 Seiten behandelt, ... Lesen bildet zwar, aber Dir wurden genug Hinweise zur Umsetzung gegeben. WEsentlich Neues wirst Du in den Büchern wohl nicht finden. Auch dort wird man wohl darauf hinweisen, das der Energieumsatz im Messwiderstand so klein wie möglich sein sollte. SEtze doch einfach mal einen der vielen Vorschläge um. Ob das in µ-Phyton, C oder what ever erfolgt ist doch erst mal Rille. Mache wie schon mehrfach vorgeschlagen einen ordentlichen Versuchsaufbau mit einem Messfühler und wenn das zufriedenstellen läuft, dann kann man ja das Gesamtprojekt planen. Für das was Du messen willst sind sehr wahrscheinlich DS18xxx völlig ausreichend. Die machen alles alleine, da mußt Du Dich nicht um Ströme oder ähnliches kümmern, das machen die alles alleine. Der Wert kommt da schon digital. Dann haben die auch noch den Vorteil einiger nützlicher Zusatzfunktionen. Das nächste Deiner Probleme wird die Länge der Kabel werden und zwar nicht wegen irgendwelcher Einstreuungen, sondern wegen dem ohmschen Widerstand selbiger.
Zeno schrieb: > Ansonsten gilt für Pt100/Pt1000, das die im Sensor umgesetzte > Verlustleistung so gering wie möglich sein soll, um eine Eigenerwärmung > des Sensor zu minimieren. > [...] > Da sind > zwei Wege möglich: > 1. [...] > 2. Gepulster Betrieb, so wie von m.n. vorgeschlagen/umgesetzt, mit > höherem Strom. Dadurch hat man eine geringe Dauerleistung (geringe > Eigenerwärmung), weil der hohe Strom nur kurzzeitig fließt und ein > hohes gut auswertbares dU/dT. Pkt 2. ist ein sehr guter Tipp. Habe ich inzwischen realisiert. Dank! > Vorschläge wurden mittlerweile genug unterbreitet. ??? Übrigens: Ich habe die (12) Postings von m.n. in diesem Thread durchgesehen und keinen Vorschlag eines gepulsten Betriebs darin gefunden (mag ja sein, dass ich Tomaten auf den Augen habe).
Hallo Zeno, inzwischen habe ich Messungen bemacht und ausgewertet. Der Widerstand des PT1000 ist im gepulsten Betrieb so gesunken, dass das am Ende 3-4 °C ausmacht. Die Spannung an den Sensor erst anzulegen wenn sie gebraucht wird und auch darauf, dass man das mit dem Pico so machen kann, war ein sehr guter Tipp. Dank! ggf. auch an m.n. der darüber vielleicht in einem anderen Thread geschrieben hat.
Manfred M. schrieb: > @ Nobert und alle, die mehr wissen als ich, mir dennoch helfen wollen > >> Mir wurden bereits viele hilfreiche Hinweise gesendet, wofür ich sehr >> dankbar bin. Doch neuerdings bekomme ich Verweise auf die Doku zum Pico >> und zu Micropython, ohne genau mitzuteilen, wo was steht (z.B. durch >> einen Link). > >> Ich bitte um Mitteilung von Details (Links zu diesen) zu Folgendem: > >> 1. Wo finde ich diesen Code: >> >> from machine import mem8 >> PADS_BANK0_BASE = const(0x4001c000) >> GPIO26 = const(0x6c) >> ... >> mem8[PADS_BANK0_BASE + GPIO26] = 1 << 7 >> ... >> >> Ich las das schon mal in einer Doku, weiß aber nicht mehr wo. Habe >> gesucht, doch nicht wieder gefunden. > Kein Wunder, der ist von mir. Und direkt dabei steht die Referenz zum > Datenblatt. Und welches Datenblatt? Das zum Pico https://datasheets.raspberrypi.com/rp2040/rp2040-datasheet.pdf ? Aber mem8 fand ich nicht mehr oder meinst Du dieses Datenblatt: https://docs.micropython.org/en/latest/library/machine.Pin.html ??? > >> 2. Exceptions >> Ich will noch Bearbeitungen einiger Exceptions programmieren, müsste >> dafür solche voneinander unterscheiden könne, weiß aber nicht wie. > Du hattest bereits den Hinweis auf die vollständige Python Docs von mir > bekommen. Also dann hier: https://docs.python.org/3/library/exceptions.html Demnach sollte "Exception FileNotFoundError:" funktionieren. Bei meinem Pico funktioniert das nicht. Probier das mal an anderem Pico! Daher fragte ich: Wie funktioniert es (gemeint war: auf einem Pico) >> 3. Ich möchte aus Win-10 auf Dateien des Pico zugreifen. Wie könnte das >> funktionieren? Und wie geht es aus einem anderen Raspberry z.B. mit >> einem Raspian? Wo genau kann ich Details nachlesen? Diese Frage stellte ich bereits mal und Deine Antwort war: >> ›pyboard.py --help‹ >> -f, --filesystem >> perform a filesystem action: cp local :device | cp >> :device local | cat path | ls [path] | rm path | mkdir >> path | rmdir path Das soll aus einem Win-10 heraus funktionieren? In der shell? Oder wo? Mit "›pyboard.py --help‹" kann ich gar nichts anfangen. Entschuldige bitte meine Dummheit. Wo sollte ich diese Zeichenkette verwenden? >> >> 4. Ich fand eine Beschreibung wie der Pico stand alone (ohne Verbindung >> via USB) in Betrieb gesetzt werden kann, aber keine Info wie ich ihn aus >> diesem Verhalten wieder heraus bekomme. Wie? Du hast mitgeteilt: Spannung dran! >> Ich fand aber keine Info wie ich ihn aus >> diesem Verhalten wieder heraus bekomme. Wie? >und wieder weg! Und wenn ich sie wieder anlege z.B. via USB-Verbindung zu meinem PC, was passiert dann? Meldet sich dann im Thonny der Pico so: > MicroPython v1.18 on 2022-01-17; Raspberry Pi Pico with RP2040 > Type "help()" for more information. ????
Manfred M. schrieb: > Hallo Zeno, > > inzwischen habe ich Messungen bemacht und ausgewertet. Der Widerstand > des PT1000 ist im gepulsten Betrieb so gesunken, dass das am Ende 3-4 °C > ausmacht. > Die Spannung an den Sensor erst anzulegen wenn sie gebraucht wird und > auch darauf, dass man das mit dem Pico so machen kann, war ein sehr > guter Tipp. > Dank! ggf. auch an m.n. der darüber vielleicht in einem anderen Thread > geschrieben hat. Das war nicht mein Tipp - möchte mich nicht mit fremden Federn schmücken. Das wurde mehrfach von m.n. so beschrieben. Ich habe es in meinem letzten Post eigentlich nur noch mal zusammen gefasst.
Zeno schrieb: > Manfred M. schrieb: >> Hallo Zeno, >> >> inzwischen habe ich Messungen bemacht und ausgewertet. Der Widerstand >> des PT1000 ist im gepulsten Betrieb so gesunken, dass das am Ende 3-4 °C >> ausmacht. >> Die Spannung an den Sensor erst anzulegen wenn sie gebraucht wird und >> auch darauf, dass man das mit dem Pico so machen kann, war ein sehr >> guter Tipp. >> Dank! ggf. auch an m.n. der darüber vielleicht in einem anderen Thread >> geschrieben hat. > Das war nicht mein Tipp - möchte mich nicht mit fremden Federn > schmücken. Das wurde mehrfach von m.n. so beschrieben. Ich habe es in > meinem letzten Post eigentlich nur noch mal zusammen gefasst. aber davon weiß ich nichts, weil ich nur in diesem Thread lese, somit stammt das Rüberbringen hierher von Dir und dafür sei Dir Dank! Du hattest auch geschrieben: > Das nächste Deiner Probleme wird die Länge der Kabel werden und zwar > nicht wegen irgendwelcher Einstreuungen, sondern wegen dem ohmschen > Widerstand selbiger. Ich kennen den Widerstand der Leitungen ziemlich genau, weil ich Sensoren mit 3 Leitungen verwende. Liegen knapp unter 2 Ohm. Ich könnte sogar noch mit meinem Oszi nachsehen welche Signale auf in dieser Schleife der Leitungen, die zum Ermitteln des Leitungswiderstands zu verwenden wären, auftreten. Morgen kommt das metallene Gehäuse. Wenn ich alles zusammengebaut habe, dann ist das in einem faradayischen Käfig. Ginge das Abschirmen dann noch besser? Ich fand allerdings einen Hinweis, dass die Verbindungen (gelötet oder geschraubt oder gesteckt) wie Thermoelemente wirken ... Hmmm
Zeno schrieb: > Geringe Eigenerwärmung erreicht man, > indem möglichst wenig Leistung im Messwiderstand umgesetzt wird. Da sind > zwei Wege möglich: > 1. (Dauer)Strom so gering wie möglich, damit Dauerleistung so gering wie > möglich. > 2. Gepulster Betrieb, Oder aber, der PT1000 ist so montiert, dass die Eigenerwärmung nicht ins Gewicht fällt, abgeführt wird. Eben dann, wenn er in einem z.B. Kapilarrohr steckt. Dann schlägt die Eigenerwärmung nicht durch. Dies hat man auch beim DS18b20 wenn man den im 1-sekunden Rhythmus abfrägt. Dann schnellt der auch nach oben. Gepulster Betrieb, Taktbetrieb naja, ... macht man eigentlich nicht. Kenne ich so in keiner Anlage, weder von z.B. Eloma, noch Wiesheu WiWa. Für die Kundendienst gemacht habe. Die wurden immer konstant dauerhaft betrieben.
PC-Freak schrieb: [...] > > Oder aber, der PT1000 ist so montiert, dass die Eigenerwärmung nicht ins > Gewicht fällt, abgeführt wird. Eben dann, wenn er in einem z.B. > Kapilarrohr steckt. Dann schlägt die Eigenerwärmung nicht durch. Dies > hat man auch beim DS18b20 wenn man den im 1-sekunden Rhythmus abfrägt. > Dann schnellt der auch nach oben. > > Gepulster Betrieb, Taktbetrieb naja, ... macht man eigentlich nicht. > Kenne ich so in keiner Anlage, weder von z.B. Eloma, noch Wiesheu WiWa. > Für die Kundendienst gemacht habe. Die wurden immer konstant dauerhaft > betrieben. Ich habe nun gesehen wieviel das ausmacht. Meine Sensoren stecken in Metallhülsen, die außen 3 mm stark sind. Momentan stehen sie in Wasser, welches Wärme bekanntlich gut ableitet. Zukünftig sollen sie in Luft eingesetzt werden, die wesentlich schlechter Wärme ableitet. Daher gefällt mir die Idee, die Sensoren nur dann mit Strom zu versorgen, wenn man deren Widerstand wissen will, sehr gut.
Hallo Norbert, beim Stöbern fand ich https://datasheets.raspberrypi.com/pico/getting-started-with-pico.pdf und darin ein Kap. 9.2 was so aussieht als könnte ich (nach Installation der Tool Chain) files vom Pico auf meinen PC bringen, was mir momentan wichtig ist. Wahrscheinlich kann ich noch viel mehr damit machen, was ich mit dem Thonny nicht machen kann. Zumindest meine diesbezügliche Frage in meinem posting von 23.03.2022 23:36 könnte damit vielleicht erledigt sei. D.h. ich probiere mal den Weg, der im o.g. pdf-Datei unter 9.2 beschrieben ist. VG MM
Manfred M. schrieb: > aber davon weiß ich nichts, weil ich nur in diesem Thread lese, somit > stammt das Rüberbringen hierher von Dir und dafür sei Dir Dank! Sorry aber dann liest Du diesen Thread nicht richtig. m.n. hat's hier Beitrag "Re: Problem bei Temp-Messung Rasp. Pi Pico & Pt1000" (auch wenn man dazu den Link im Post anklicken muß) gesagt und dann noch mal genau einen Post über meinem (Beitrag "Re: Problem bei Temp-Messung Rasp. Pi Pico & Pt1000"). Noch mal: Mein Post war lediglich eine kurze Zusammenfassung von mehrfach gesagtem. PC-Freak schrieb: > Oder aber, der PT1000 ist so montiert, dass die Eigenerwärmung nicht ins > Gewicht fällt, abgeführt wird. Das halte ich gelinde gesagt für Murks. Was passiert denn wenn die Wärme mal nicht mehr richtig abgeführt wird? Eine Fehlmessung ist da unter Umständen noch das geringste Risiko. PC-Freak schrieb: > Dies > hat man auch beim DS18b20 wenn man den im 1-sekunden Rhythmus abfrägt. > Dann schnellt der auch nach oben Ich habe mehrere dieser Teile im Einsatz und konnte da keine Eigenerwärmung feststellen, allerdings messe ich auch nicht alle 1s.
Angehängte Dateien:
Zeno schrieb: > PC-Freak schrieb: >> Oder aber, der PT1000 ist so montiert, dass die Eigenerwärmung nicht ins >> Gewicht fällt, abgeführt wird. > Das halte ich gelinde gesagt für Murks. Was passiert denn wenn die Wärme > mal nicht mehr richtig abgeführt wird? Eine Fehlmessung ist da unter > Umständen noch das geringste Risiko. Das ist nicht Murks, aber anders wird das auch in der Industrie nicht gemacht. Wenn der PT1000, KTY10, oder der DS18b20 allein in der Luft betrieben wird, hast Du immer dieses Problem. Die PT100, PT1000 werden u.A. ja auch in Einstechfühler am Küchenherd verwendet. Und dieses Fühlergehäuse reicht dem PT ... um die Eigenerwärmung zu eliminieren, und dann vernünftige Messwerte zu liefern. Die Eigenerwärmung geht ja auch nur um ein paar Grad nach oben, und nicht unendlich. Und jedes Messgerät sollte man erst ein paar Minuten laufen lassen, um dann kritische Messungen zu machen. Und wenn dann drauf geachtet wird, dass der Schirm auf Gnd gelegt wird, und der PT 1000 eine stabile Versorgung hat, dann klappt das auch. Ich habe mal schnell nach einer Schaltung gegoooogelt. Sie oben. Dort wird auch ein OP dem Rasphi vorgesetzt. Und genau aus dem Grund wegen der Eigenerwärmung. Dort hat der PT1000 einen 10K Widerstand davor.
Hab grad nochmal den Eröffnungspost angeguggt. ein 1,5 K vor dem PT... ist viel zu wenig. Da wundert es mich nicht, dass der davon läuft.
PC-Freak schrieb: > Ich habe mal schnell nach einer Schaltung gegoooogelt. So eine Schaltung musst du aber abgleichen oder mit den zusätzlichen Fehlern leben. Selbst mit 4 richtig teuren Widerständen bleibt noch der Offset des OP. Ich hoffe ja nur, dass "LM358" nur ein Platzhalter ist - sonst bist du mit 10K Eigenerwärmung besser bedient.
PC-Freak schrieb: > Ich habe mal schnell nach einer Schaltung gegoooogelt. Sie oben. Dort > wird auch ein OP dem Rasphi vorgesetzt. Und genau aus dem Grund wegen > der Eigenerwärmung. Dort hat der PT1000 einen 10K Widerstand davor. Das darf doch nicht wahr sein! Bei dieser Schaltung wird die Temperaturmessung mit dem LM358 gemacht :-( Es bestätigt aber meine Einschätzung, was Anwender von RasPi, Arduino und Co. als "brauchbare Lösung" empfinden. PC-Freak schrieb: > Das ist nicht Murks, aber anders wird das auch in der Industrie nicht > gemacht. Wenn mal etwas anders gemacht werden sollte, dann müßten eine Vielzahl der Anwender das Messprinzip ja auch verstehen. Da klemmt es. Selbst hier im Forum laufen Spinner herum, die es nicht nur nicht raffen, sondern auch noch rumpöbeln. So gilt auch weiterhin der Handwerkerspruch: "Hamm wa noch nie gemacht" bzw. "das machen wir immer so." Beachte bitte: Der TO konnte durch das Pulsen seine Ergebnisse erheblich verbessern.
Manfred M. schrieb: > ... > Mit "›pyboard.py --help‹" kann ich gar nichts anfangen. Entschuldige > bitte meine Dummheit. Wo sollte ich diese Zeichenkette verwenden? Suche nach "pyboard.py" findet: https://micropython-glenn20.readthedocs.io/en/latest/reference/pyboard.py.html "The pyboard.py tool¶ This is a standalone Python tool that runs on your PC that provides a way to: ..."
PC-Freak schrieb: > Hab grad nochmal den Eröffnungspost angeguggt. > ein 1,5 K vor dem PT... ist viel zu wenig. Da wundert es mich nicht, > dass der davon läuft. Das ist schon ziemlich lang nicht mehr so.
Zeno schrieb: > Manfred M. schrieb: >> aber davon weiß ich nichts, weil ich nur in diesem Thread lese, somit >> stammt das Rüberbringen hierher von Dir und dafür sei Dir Dank! > Sorry aber dann liest Du diesen Thread nicht richtig. m.n. hat's hier > Beitrag "Re: Problem bei Temp-Messung Rasp. Pi Pico & Pt1000" (auch wenn > man dazu den Link im Post anklicken muß) gesagt und dann noch mal genau > einen Post über meinem > (Beitrag "Re: Problem bei Temp-Messung Rasp. Pi Pico & Pt1000"). > Noch mal: Mein Post war lediglich eine kurze Zusammenfassung von > mehrfach gesagtem. Hier, bei mir am Bildschirm war nicht erkennbar, dass da ein Link im Posting von m.n. befindet. Mir wird nun klar, was mit "das wurde hier schon oft beschrieben" und ähnlichem Text gemeint ist: Hier im Forum, während ich darunter hier im Thread verstand. Den Hinweis Zeno schrieb: > und dann noch mal genau > einen Post über meinem > (Beitrag "Re: Problem bei Temp-Messung Rasp. Pi Pico & Pt1000"). Das zweite Posting worauf Du hinweist habe ich tatsächlich nicht beachtet. Es war: m.n. schrieb: > Manfred M. schrieb: >> also fließen bei 0 °C durch den PT1000; 3,3 V/ 2000 V/A= 1,65 mA, also >> Verlustleistung im Pt1000 (bei 0°C): R*I^2 = 2,7225 mW > > Multipliziert mit dem Tastverhältnis von 7 * 10^-5 ergibt dann effektiv > ca. 190 nW. > Das soll zu viel sein? Ich habe es nicht beachtet weil: 1. Leistung * Zeit = Energie [zB in Ws] und 2. mir auch nicht klar war, woher "Tastverhältnis von 7 * 10^-5" kommt (die Berücksichtigung eines Tastverhältnisses war zu diesem Zeitpunkt gemäß meiner damaligen Schaltung sinnlos, weil bei mir der PT100 zu dieser Zeit ständig unter Strom stand). Jetzt ist das anders (dank des Hinweises hier im Thread auf die Möglichkeit die Stromversorgung auch vom Pico schalten zu lassen).
PC-Freak schrieb: > Das ist nicht Murks, aber anders wird das auch in der Industrie nicht > gemacht. Wenn der PT1000, KTY10, oder der DS18b20 allein in der Luft > betrieben wird, hast Du immer dieses Problem. Also kann man mit diesen Fühlern keine Lufttemperatur messen - träum weiter, tausende von Fühlern wissen das nicht und messen richtig.
PC-Freak schrieb: > Die Eigenerwärmung geht ja auch nur um ein paar Grad nach oben, und > nicht unendlich. Und jedes Messgerät sollte man erst ein paar Minuten > laufen lassen, um dann kritische Messungen zu machen. Wie will er denn garantieren das die Eigenerwärmung immer gleich ist, damit man das Ergebnis korrigieren kann. Du erzählst hier einfach Blödsinn. Die Schaltung und/oder die SW muß so sein das im Prinzip keine Eigenerwärmung auftritt oder diese so gering ist, das sie das Messergebnis nicht beeinflusst bzw. vernachlässigt werden kann. Das erreicht man eben z.B. dadurch indem man den Messstrom gering wählt. Der DS18xxx erwärmt sich im übrigen nicht durch einen hohen Fühlerstrom, sondern weil der Leistungsumsatz im IC während der DA-Wandlung einfach höher ist. Deshalb ist es wichtig das man das vorgegebene Zeitregime einhält.
Was könnte noch besser gemacht werden? das meiste ist hier im Thread bereits geschrieben (insbes. der Aufbau einer Schaltung auf einer Platine statt dem Steckbrett) und dann der Einbau in ein Gehäuse. Sinnvoll erschiene mir der Einsatz eines Instrumentenverstärkers wie zB INA 114 (wegen des einfach einstellbaren Gains), doch der ist ziemlich teuer (bei Mouser ca. 15 €/Stk). Ich kenne mich aber mit diesen Teilen (Alternativen?) zu wenig aus. Grund des Wunsches nach änderbarem Messbereich: Vielleicht will ich mit dem Teil auch mal Temp. in einem anderen Bereich messen (jetzt ca. 10 bis 20 °C, dann auch ca. 100 bis 300 °C).
Manfred M. schrieb: > Vielleicht will ich mit > dem Teil auch mal Temp. in einem anderen Bereich messen (jetzt ca. 10 > bis 20 °C, dann auch ca. 100 bis 300 °C). Deine konstante Ignoranz ist ja an Peinlichkeit nicht zu überbieten :-(
m.n. schrieb: > Manfred M. schrieb: >> Vielleicht will ich mit >> dem Teil auch mal Temp. in einem anderen Bereich messen (jetzt ca. 10 >> bis 20 °C, dann auch ca. 100 bis 300 °C). > > Deine konstante Ignoranz ist ja an Peinlichkeit nicht zu überbieten :-( Fremdschämen für mich? Naja ist nett, aber nicht notwendig. Trotzdem: Dank!
Zeno schrieb: > Du erzählst hier einfach Blödsinn. Nicht wirklich. Zeno schrieb: > Die Schaltung und/oder die SW muß so > sein das im Prinzip keine Eigenerwärmung auftritt oder diese so gering > ist, das sie das Messergebnis nicht beeinflusst bzw. vernachlässigt > werden kann. > Das erreicht man eben z.B. dadurch indem man den Messstrom gering wählt. Genau deshalb hab ich die Schaltung mit angehängt. Dort ist ein 10K Widerstand in Reihe zum PT1000. Und da passiert nix. Und wenn der Fühler, dann sowieso in einem Schutzrohr (aus Alu, oder Edlestahl) steckt, kommt auch nicht viel bis gar keine Eigenerwärmung. Ausprobieren.
Anmerkung zur Eigenerwärmung eines Pt-Sensors: Spez. Wärmekapazität von Platin: c = 130 Ws·kg^−1·K^−1; ich nehme 100 statt 130 Das ist Stoff der 8. Klasse eine math.-nat. Gymnasiums: Erwärmung eines Körpers der Masse m und spez. Wärmekapazität c bei Energiezufuhr W = P * t ist dT = P * t /(m * c) = R * I^2 * t / (m * c) = U^2 *t / (R m c) Bei einem Strom von I= 1 * 10^-4 A und einer Sensormasse von m= 10^-1 g = 10^-4 kg Platin und Pt1000 bei 0 °C: dT = 1000 * 10^-8 * t / (10^-4 * 100) ~= 10^-3 * t [K] In 1 h also dT = 3,6 K Schmelzpunkt von Pt 1768 °C, dh. nach ca. 500 h ~= 12 d Dauer-Betriebszeit schmilzt der Sensor dahin, ES SEI DENN er wird gekühlt. Das Kühlen muss nach den gleichen Regeln wie das Kühlen eines jeden elektr. Bauteils, in dem Wärme entsteht, erfolgen.
Manfred M. schrieb: > ES SEI DENN er wird gekühlt. Das war unvorsichtig formuliert. Es geht ja darum wie genau man mittels einem PTx-Sensor Temperatur messen kann. Wenn gewährleistet ist, dass der Ptx-Sensor (also das Pt im Sensor) stets genau die gleiche Temp hat und stets behält wie das Objekt, dessen Temp er messen soll, dann kann man ihn zum Messen der Temp diese Objekts benützen.
Jetzt mailde ich mich hier nochmals, obwohl mein pico bereits vor sich hin misst, doch ich bin nicht zufrieden mit der jetzt von mir realisierten Lösung. Bevor ich frage, will noch auf dies hinweisen: Wär ich nicht dumm in Elektronik, würde ich nicht hier schreiben. Ich fand diese Schaltung: https://www.mikrocontroller.net/attachment/551383/PT1000_LM358_Arduino_Converter-040106.jpg Ich will im Bereich 0 bis 30 °C (vielleicht auch 150 °C) messen. Versorgungsspannung (statt 5 V in der Schaltung): 3,3 V, also Spannung über Pt1000 bei 0 °C : 0,3 V, bei 30 ° C: 0,33 V und bei 150 °C: ca. 0,45 V Mittels LM258 will ich die Spannung, die am ADC anliegt, in den Bereich bringen, der zum Pico passt, also Knapp unter 3,3 V (ich hoffe, dass 3,3, V richtig ist i.S. passt gut zu ADC des pico). Dumm wie ich bin, kann ich nur vermuten, dass das, was ich gain nennen möchte, durch R4 bestimmt wird. Wie? Gibt es dafür ein Formel?
Angehängte Dateien:
-
Verstaerkerschaltung_3.GIF
4,7 KB
Ich habe nun versucht für die angehängte Schaltung die Gleichungen zusammenzustellen: Mit f*(R1+R2)=R2 und g*(R3+R4)=R4 und h*(RN+R4)=R4, erhält man (m.E.) U_A=(A*U_E*(f-g))/(1- A*h) wobei A die Verstärkung sein soll. Ich fand für den LM258, von dem ich zwei Chips habe: AOL Open-loop voltage gain mit VS = 15 V; VO = 1 V to 11 V; RL ≥ 2 kΩ : Min 50 Max 100 V/mV (S. 15 in https://www.ti.com/lit/ds/symlink/lm358.pdf) also Faktor 50'000 bis 100'000 Durch herumprobieren fand ich diese Werte R1 50000 50000 R2 1000 1000 R3 40000 40000 R4 900 2000 PT100 bei weniger als -20°C und über 150 °C RN 50000 50000 A 50000 50000 U_E 3,3 3,3 U_A 0,447875 2,40461 (ich hoffe, dass nach dem Versenden dieses Postings die Tabelle als Tabelle erkennbar bleibt wie ich es in der Vorschau sehen kann) Sind die Ergebnisse für die Fachhleute, die hier lesen, plausibel?
VORSICHT In meinen Rechnungen (10.04.2022 21:00) steckte ein Rechenfehler
Bei der Messung einer Teilspannung ist immer auch der interne Widerstand des ADC zu berücksichtigen. Hier an einem Beispiel mit einem NTC gezeigt:
1 | # R_NTC_25 R_TOP |
2 | # |---------| |----------| |
3 | # GND ------| NTC 8k2 |-------| 1000 Ohm |------- 3,3 V (VREF) |
4 | # |---------| ^ |----------| |
5 | # U1 | U2 |
6 | # | |
7 | # ADC |
8 | # | |
9 | # R_ADC | |
10 | # |---------| | |
11 | # GND ------| 100kOhm |--- <-- Internal Resistor Value of the ADC |
12 | # |---------| |
13 | # |
14 | |
15 | |
16 | from machine import Timer, Pin, ADC |
17 | from math import log |
18 | from time import sleep |
19 | |
20 | # Set Pins |
21 | adc_pin = ADC(0) |
22 | |
23 | # Set global constants |
24 | BETA = 3784 # BETA From the NTC |
25 | KELVIN_ZERO = 273.15 |
26 | KELVIN_25 = KELVIN_ZERO + 25 |
27 | VREF = 3.16 # Measured value of VREF from the Pico |
28 | |
29 | R_TOP = 1000 # Resistor from ADC to VREF |
30 | R_NTC_25 = 8200 # Resistor NTC at 25° Celsius |
31 | R_ADC = 100000 # Inner Resistor of the ADC |
32 | |
33 | # Set global variables |
34 | factor = VREF / (65535) |
35 | adc_value = 0 |
36 | |
37 | |
38 | # Function to scan the ADC Value |
39 | def getADCvalue(void): |
40 | global adc_value |
41 | adc_value = 0.99 * adc_value + 0.01 * adc_pin.read_u16() |
42 | |
43 | |
44 | # Initialization |
45 | adc_timer = Timer() |
46 | adc_timer.init(period = 23, mode = Timer.PERIODIC, callback = getADCvalue) |
47 | |
48 | # Get value from ADC |
49 | adc_value = adc_pin.read_u16() |
50 | sleep(1) |
51 | |
52 | |
53 | # Main loop |
54 | while True: |
55 | # Get averaged value from ADC |
56 | print('ADC Value =', adc_value)
|
57 | |
58 | # Calculate Voltage |
59 | adc_volt = adc_value * factor |
60 | print('ADC Volt =', adc_volt)
|
61 | |
62 | # Calculate Resistor |
63 | adc_ohm = adc_volt / ((VREF - adc_volt) / R_TOP) |
64 | |
65 | # Correct Resistor with the inner Resistor of the ADC |
66 | adc_ohm = (R_ADC * adc_ohm) / (R_ADC - adc_ohm) |
67 | print('ADC Ohm =', adc_ohm)
|
68 | |
69 | # Calculate Temperature |
70 | adc_temp = KELVIN_25 / (1 - ((KELVIN_25 / BETA) * log(R_NTC_25 / adc_ohm))) - KELVIN_ZERO |
71 | print('ADC Temp =', adc_temp)
|
72 | |
73 | sleep(5) |
G.B. schrieb: > Bei der Messung einer Teilspannung ist immer auch der interne > Widerstand des ADC zu berücksichtigen. > Hier an einem Beispiel mit einem NTC gezeigt: > GND ------ 100kOhm --- <-- Internal Resistor Value of the ADC Dass ist ja interessant, ein statischer 100kΩ Widerstand also. Würde bedeuten, wenn ich nur einen einsamen, auf 3.3V aufgeladenen 1000µF Kondensator anschließe und ich messe einmalig nach 138,63 Sekunden, dann wäre der auf 25% entladen? Und jetzt alle gemeinsam: DASS IST JA INTERESSANT!
Es ist nicht wirklich ein statischer Widerstand. Bei der verwendeten Schaltung wirkt er nur als ein solcher. Am besten, sie testen:
1 | |----------| |----------| |
2 | GND ------| 1000 Ohm |-------| 1000 Ohm |------- 3,3 V (VREF) |
3 | |----------| ^ |----------| |
4 | U1 | U2 |
5 | ADC |
Hier wäre ein Wert von 65535 / 2 zu erwarten. Er ist aber deutlich kleiner. Zuerst denkt man an Wert-Toleranzen der Widerstände. Aber wenn diese getauscht werden, ist der gemessene Wert immer noch deutlich zu klein. Wenn man die gleiche Messung mit größeren Widerständen probiert, z.B. 10k, 100k, wird der der gemessene Wert immer kleiner, obwohl zu erwarten wäre, das er gleich bleibt. Dieses Verhalten deutet auf einen parallelen Widerstand. Und in der Tat verhält sich die Schaltung als hätte der ADC einen internen Widerstand von 100KOhm. Empirisch ermittelt.
G.B. schrieb: > Es ist nicht wirklich ein statischer Widerstand. > Bei der verwendeten Schaltung wirkt er nur als ein solcher. Ich denke du irrst hier. Im Datenblatt wird ausdrücklich von Impedanz gesprochen. Das heißt, bei maximaler Abtastrate von 500ksps wirkt es wie ein 100kΩ Widerstand. Und zwar weil während der Sample-and-Hold Phase ein 1pF Kondensator geladen wird. Das ist nicht gleichbedeutend mit einer 100kΩ Belastung deines Spannungsteilers. Denn wenn der Kondensator voll ist - und das isser deutlich innerhalb der Sample-and-Hold Phase - fließt bis auf Leckströme im niedrigen einstelligen µA-Bereich gar kein Strom mehr. Möglicherweise hast du aber die Digital Input Pads nicht explizit abgeschaltet (RP2040-E6)
Norbert schrieb: > Möglicherweise hast du aber die Digital Input Pads nicht explizit > abgeschaltet (RP2040-E6) Beziehungsweise den Offset nicht eleminiert. Da ich gerade eine Schaltung mit RP2040 vor mir habe: offener Eingang A0: ca. 940 pulldown aktiviert: ca. 28 Eingang gegen GND: ca. 15 Die Bits OD, IE, SCHMITT verändern den (wackeligen) Wert so gut wie nicht.
Hallo Michael m.n. schrieb: > offener Eingang A0: ca. 940 > pulldown aktiviert: ca. 28 > Eingang gegen GND: ca. 15 welche Werte sind das? So ausgelesen wie es G.B. in Zeile 49 seines am 05.05.2022 14:59 mitgeteilten Code macht?
Manfred M. schrieb: >> offener Eingang A0: ca. 940 >> pulldown aktiviert: ca. 28 >> Eingang gegen GND: ca. 15 > > welche Werte sind das? Die unpythonierten Rohwerte ohne jegliche Umrechnung, wie sie in ADC->RESULT stehen, per SWD ausgelesen.
Hallo Michael m.n. schrieb: > Die unpythonierten Rohwerte ohne jegliche Umrechnung, wie sie in > ADC->RESULT stehen, per SWD ausgelesen. Lies mal in diesem Thread das Posting vom 16.03.2022 23:41, ggf. auch einige davor. Sinnvoll ist es die roh-Werte um 4 Bits nach rechts zu verschieben (den rechtesten Nibble also wegschmeißen) 16 bits auszulesen und über Differenzen <=15 nachzudenken ist unnötig
Thread beobachten
Seitenaufteilung abschalten
Bitte 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.