Von einer âaltenâ Ofensteuerung (zum Sintern von Keramik) hin zu einer âneuen groĂenâ und einer âkleinenâ Steuerung. Alle Steuerungen regeln die Temperatur, fahren eine vorgegebene Temperaturkurve ab rund steuern digitale AusgĂ€nge fĂŒr Gase und Pumpen.
Wie so ĂŒblich wurde zunĂ€chst aus dem Matschklumpen eine strukturierte Software geschaffen, dann wurde die Hardware strukturiert â und weil das doch recht schwierig ist â eine Miniausgabe davon erstellt.
Ofentemperaturregelung mit Rezeptsteuerung (ĂŒber Stunden) und Steuerung von 8 digitalen AusgĂ€ngen (Relais).
Um âimmer malâ einen Rauchmelder fĂŒr die Platzierung in OfennĂ€he parat zu haben, ist es zweckmĂ€Ăig, diesen mit einem jedermann bekannten USB-Stecker zu versehen und mit HID+WebUSB auszurĂŒsten. Die Geizhalsversion verwendet nicht Arduino, sondern PIC16F1455.
Die Bereitstellung der Betriebsspannung fĂŒr den Rauchmelder geschieht ĂŒber eine Spannungsverdopplerschaltung, dessen Rechteckgenerator ein Ausgang des Mikrocontrollers ist. Das bidirektionale Pin 7 des Melders dient zur Abgabe akustischer Warnungen bei Ăbertemperatur und Gas, d.h. auch ohne Rauch. Ăber USB und eine Webseite können die Messwerte abgelesen und Alarm-Grenzwerte eingestellt werden. An Stelle der LED kann auch ein Relais sitzen, welches den Rauchmelder zusĂ€tzlich zum FrostwĂ€chter macht. In dieser Schaltung dient die LED nur als Hilfe zum Erstellen der Firmware.
R6 ist unbedingt erforderlich, damit der Urlader ĂŒberhaupt einen Power-On-Reset erkennt (und zur Anwendungsfirmware springt). Verwendet wurde der Urlader bootCDC-lvp.hex. FĂŒr den Spannungsverdoppler ist C3 unbedingt ein keramischer Kondensator; fĂŒr die 47 kHz mĂŒssen es 470 nF sein. Bei höherer Taktfrequenz geht auch weniger. Hingegen C4 muss ein ziemlich groĂer Elko sein, weil der Rauchmelder beim Unterspannungs-Test ziemlich reichlich Strom zieht und dann (bei Spannungseinbruch) der Piepser nervtötend alle 1 min piepsen wĂŒrde. Bei einigen Rauchmeldern ist D1 und C4 bereits enthalten. Solange der Urlader âlĂ€uftâ und der Spannungsverdoppler nicht arbeitet, piept der Rauchmelder alle 1 min.
KanÀle | Typ | Beschreibung | Verwendung |
---|---|---|---|
Peripherie | |||
4 | DO;AO | Triac-AusgÀnge 400 V~ 12 A mit Strommessung (Kurvenformmessung mit 2 kSa/s/Kanal) | Heizwendel |
16 | DO;AO | DigitalausgÀnge 24 V, Spannung reduzierbar per Software-PWM, Grundfrequenz 100 Hz | Magnetventile |
4 | AO | AnalogausgĂ€nge 0..5 V (per BestĂŒckungsoption Ă€nderbarer Ausgangsspannungsbereich) via Hardware-PWM und Tiefpassfilter | - |
16 | DI | DigitaleingĂ€nge TTL, mit EingangswiderstĂ€nden vor Spikes geschĂŒtzt, Pullups fĂŒr Schalter nach Masse | Starttaste, Gashahnkontakte |
4 | AI | AnalogeingÀnge 0..5 V; liefern jeweils 5 V (Spannungsteiler vorsehen?? Gesonderte Jumper?) | Gassensor MiCS5524 |
4 | AI | AnalogeingĂ€nge fĂŒr Thermoelemente | Thermoelemente |
4 | AI | AnalogeingĂ€nge fĂŒr MessbrĂŒcken; liefern jeweils 5 V (Zur Not auch fĂŒr Pt100, Pt1000) | Drucksensor |
1 | DIO | Rauchmelder-Anschluss (mehrere Rauchmelder können parallel geschaltet werden); liefert 9 V | Nebelkammer-Rauchmelder |
1 | BUS | IÂČC-Anschluss: Hardware-IÂČC; liefert 5 V | Pyrosensor MLX90614KSF |
1 | BUS | OneWire-Anschluss, universell verwendbar: Software-OneWire; liefert 5 V | Temperatursensoren |
1 | BUS | RS485-Anschluss; liefert 5 V | - |
Versorgung | |||
1 | BUS | USB (Das GerÀt ist self-powered, USB nur Datenschnittstelle) | Steuer-PC |
1 | PWR | 24-V-Eingang (Gleichspannung! Netzteil je nach Verbrauchern dimensionieren! DĂŒrfen auch 12 V sein.) | Netzteil |
1 | PWR | 400-V-Eingang (Wechselspannung! Sicherung 12 A oder je nach Verbraucher extern vorsehen! DĂŒrfen auch 230 V sein.) | Stromnetz |
Anzahl | Bauteil | Bestellbezeichnung | Lieferant | Preis | Bemerkungen | GehÀuseform | Einsatz |
---|---|---|---|---|---|---|---|
16 | IRLML6344 | IRLML6344 | Reichelt | 0,14 ⏠| n-Kanal-MOSFET 30 V 5 A 1,3 W 0,8 V | SOT-23 (winzig!!) | digitale AusgÀnge |
16 | AO6402A | AO6402A | Reichelt | 0,18 ⏠| n-Kanal-MOSFET 30 V 7,5 A 1,3 W 0,8 V | SOT-23-6 (DDGSDD) | |
16 | AOD4148A | Reichelt | 0,28 ⏠| n-Kanal-MOSFET 40 V 50 A | DPAK | ||
16 | B360F | B360F | Reichelt | 0,09 ⏠Sonderangebot | Schottky-Diode 60 V 3 A | SMC | |
16 | B340F | B340F | Reichelt | 0,20 ⏠Alternative | Schottky-Diode 40 V 3 A | SMC | |
4 | ? | Reichelt | ? | Varistor | Triac-AusgÀnge | ||
4 | ? | Reichelt | ? | X1-Kondensator 47 nF 375 V | |||
4 | ? | Mouser | ? | Optotriac 800 V 0,1 A beliebige Phase | DIP6 | ||
4 | ? | Reichelt | ? | Snubberless-Triac 800 V 12 A | TO220ISO | ||
1 | LM2575 | LM 2575 T5,0 | Reichelt | 1,25 ⏠| Tiefsetzsteller 5 V 1 A | TO220V5 | 5-V-Versorgung |
1 | MC34063 | MC 34063 ADR | Reichelt | 0,32 ⏠| Schaltregler 1,5 A | SO8 | |
1 | ATmega32U4 | 556-ATMEGA32U4-AU | Mouser | ? | AVR-Mikrocontroller mit USB | TQFP44 |
Von einem Arduino wurde Abstand genommen, da unvorteilhaft: Frisst Platz, muss fĂŒr Self-Power-Betrieb frisiert werden, teuer. Stattdessen wurde ein ATmega32U4-Chip vorgesehen. Es wurden BestĂŒckungsvarianten freigehalten fĂŒr:
Position | Funktion | Bauteil | Anmerkung | verwendet |
---|---|---|---|---|
1 | 5-V-Versorgung | LM2574 (DIP8) | 1 A | â |
LM2576 (DPAK, teuer!) | 3 A (Drossel passt nicht) | |||
2 | LEM-Modul | ? | 3 Pins | â |
LTS25NP | 4 Pins | â | ||
? | 3 Pins, versetzt | |||
3 | Triac | BTA8-800CW | 8 A | |
BTA12-800CW | 12 A | â | ||
4 | MOSFETs | AO6402A (SOT23, 0,14 âŹ) | 5 A | |
AO6402A (SOT23-6, 0,18 âŹ) | 7,5 A | |||
AOD4148A (DPAK, 0,28 âŹ) | 50 A | â | ||
5 | Thermoelement-Wandler | MAX6675 | 5 V | |
MAX31855 | 3,3 V | â | ||
6 | Pt100-Wandler | MAX31865 | 3,3 V | vergessen |
Ofensteuerungs-Ăpp (Silberbox).
231006: Die Ăpp und die Firmware wurde auf 32-Bit-Zeistempel mit Millisekunden-Auflösung aufgebohrt. Ziel ist eine Betriebsdauer > 18 h. Sie liegt nun bei 49 Tagen. Die Ănderungen sind erheblich, unter anderem weil das Eingabe-Element <input type="time"> nicht fĂŒr ĂŒber 24 h funktioniert. (Es ist nur fĂŒr Uhrzeiten gemacht.)
231010: Die beiden DIL-Schalter der Steuerbox, die schon lange als 2 Tasten verlĂ€ngert herausgefĂŒhrt wurden, sind nun in eine extra Box gewandert. Zur Erinnerung, die beiden Knöpfe haben folgende Funktion:
Damit erwiesen sich die DIL-Schalter als weitere Fehlkonstruktion der Silberbox, 2 Taster + 1 Anschluss zum VerlÀngern sind einfach besser. Neben dem vergessenen ISP-Anschluss und der Huddelei mit dem Thermoelement-Wandler.
Runde | Strommessung | Extra | |||
---|---|---|---|---|---|
0 | i0 ADC4 | i1 ADC5 | i2 ADC6 | i3 ADC7 | j0 = ADC1-ADC0 |
1 | j1 = ADC1-ADC0 | ||||
2 | j2 = ADC1-ADC0 | ||||
3 | j3 = ADC1-ADC0 | ||||
4 | Langsames siehe unten | ||||
0..5 V, 25 mV/A, Nullabgleich in Software? |
Der Vorteiler 128 ergibt sich aus der Forderung, den A/D-Wandler mit 50..200 kHz zu takten. Der Teiler 13 ergibt sich bei kontinuierlicher A/D-Umsetzung. Somit liegt die Summenabtastrate bei etwa 10 kHz. Die Messstellen mit der höchsten effektiven Abtastrate sind die LEM-Stromwandler, um die Kurvenform des Stroms beim Phasenanschnitt zu erfassen. Schnelle A/D-Wandlung wird auch benötigt fĂŒr Beschleunigungs- und Kraftmesszellen, die am INA126 angeschlossen sind. Temperaturmessungen sowie Gasdruck sind hingegen nur langsam erforderlich. Dabei lĂ€uft die Temperaturmessung fĂŒr Thermoelemente am A/D-Wandler des ATmega32U4 vorbei und wird parallel dazu im MAX31855 abgewickelt.
Runde | Messung | Unteraufteilung mit IC18 | |||
---|---|---|---|---|---|
0 | OneWire = ADC8 | - | |||
1 | Zusatz = ADC9 | 24-V-Versorgung (12,2:2,2 â 5,55) | DI1 | DI2 | DI3 |
2 | Gas = ADC10 | X25 | X26 | X27 | X28 |
3 | Rauchmelder = ADC11 (2:1) | - | |||
4 | Chiptemperatur | - |
Wie man sieht ergeben sich FĂŒnfergruppen mit folgenden Abtastzeiten und -frequenzen:
Gruppe | Abtastzeit | Abtastrate | PuffergröĂe |
---|---|---|---|
4Ă LEM-Strommessung | 104 ”s Ă 5 = 0,52 ms | â 1,9 kHz | 100 |
4Ă INA126 | 104 ”s Ă 25 = 2,6 ms | â 385 Hz | 20 |
5Ă langsames | 104 ”s Ă 125 = 13 ms | â 77 Hz | 4 |
Ergibt eine GesamtpuffergröĂe von 4Ă100 + 4Ă20 + 5Ă4 = 500 Samples = 1000 Bytes, bei Doppelpufferung 2000 Bytes, was die RAM-KapazitĂ€t des Mikrocontrollers schon âganz gut ausfĂŒlltâ. Dabei diktiert der A/D-Wandler die Abholrate von 52 ms entsprechend â 19 Hz und damit die Aktualisierungsrate der WeboberflĂ€che.
Die Nettodatenrate allein fĂŒr die A/D-Daten entspricht genau der Summenabtastrate von â 10 kSa/s, somit â 20 kByte/s. FĂŒr USB kein Problem.
Um den RAM-Verbrauch zu senken kann man den Datenstrom des 10-Bit-A/D-Wandlers auch ohne Arrayzuordnung zum PC leiten. Damit das Javascript-Programm die Werte auseinanderklamĂŒsern kann, werden die 5 MSB zur spĂ€teren Zuordnung genutzt:
Wert | Bedeutung | Periodendauer in ms |
---|---|---|
000xx | Temperatur | 13 |
0y100 | Strommessung i0 | 0,52 |
0y101 | Strommessung i1 | |
0y110 | Strommessung i2 | |
0y111 | Strommessung i3 | |
01000 | INA126 j0 | 2,6 |
01001 | INA126 j1 | |
01010 | INA126 j2 | |
01011 | INA126 j3 | |
100xx | OneWire | 13 |
10100 | 24-V-Versorgung | 52 |
10101 | DI1 | |
10110 | DI2 | |
10111 | DI3 | |
11000 | Gas X25 | 52 |
11001 | Gas X26 | |
11010 | Gas X27 | |
11011 | Gas X28 | |
111xx | Rauchmelder | 13 |
Das letzte freie Bit wird fĂŒr das Vorzeichen (bei INA126) benötigt. Eine Entscheidung wird noch gefĂ€llt.
3 Jahre nach Entwicklung und BestĂŒckung erfolgte nun endlich die Inbetriebnahme am realen Ofen. Die Umgebungsschaltung, bei der diese Ofensteuerung eingebettet ist, sieht so aus:
Dabei ergaben sich folgende Probleme:
Um den BerĂŒhrschutz bei geöffnetem Ofendeckel zu gewĂ€hrleisten wĂ€re der Einsatz eines Deckelkontaktes sinnvoll, der das SchĂŒtz betĂ€tigt. Um dafĂŒr Kleinspannung verwenden zu können, Ersatz des SchĂŒtzes durch eins mit 12 V= Spulenspannung. Es wurden entsprechende Beschriftungen zur Handlungsanweisung angebracht.
Es ist noch angedacht, das HID-Interface unter LabVIEW anzusprechen, um die gewohnte BenutzeroberflÀche weiter nutzen zu können. Das bisherige LabVIEW-Programm, die Relaiskarte, ein USB-Hub, ein USB-Seriell-Wandler, eine NI-USB-Messkarte, ein NI-USB-Termoelement-Konverter und eine Menge Starkstrom-Installationsmaterial wurden obsolet: Hinter der Steuertafel sieht es nun richtig aufgerÀumt aus!
GewissermaĂen als Starthilfe fĂŒr die âgroĂeâ Ofensteuerung soll âmal eben schnellâ eine universelle Heizprozess-Steuerung ohne Gassteuerung implementiert werden. Es genĂŒgt 1 Thermoelement und 1 Heizungsrelais. Letzteres war bereits in einer Steuerkiste mitsamt 24-V-Netzteil vorhanden. HinzugefĂŒgt wurde ein Arduino Pro Micro von ebay, ein (gefundener) Schaltregler fĂŒr 5 V (ein MC34063 hĂ€tte es fĂŒr die wenigen mA auch getan) und ein Thermoelement-Modul mit MAX6675. FĂŒr das 24-V-Relais und 6 digitale 24-V-AusgĂ€nge der Renner ULN2003.
Gesteuert wird der beliebige Ofen per Schwingungspaketsteuerung (allerdings mit mechanischem statt Festkörperrelais) mit 1..4 s Periodendauer, um die Kontakte zu schonen. Zum Festlegen der Regelungsparameter und der gewĂŒnschten Temperaturkurve sowie Prozessdauer wird ein PC mit Windows-Programm via USB angeschlossen. Start/Stopp sowie der Heizvorgang an sich lĂ€uft unabhĂ€ngig mit oder ohne PC. Da kein Raspberry verbaut wurde, ist das Ganze sehr zuverlĂ€ssig auch bei StromausfĂ€llen.
Die gesamte USB-Kommunikation basiert auf der HID-GerÀteklasse.
So wird kein Treiber benötigt.
Die Firmware
arbeitet ausschlieĂlich mit Integerzahlen
und kommt ohne Flash fressende
printf()
/scanf()
aus.
Nein, die Firmware baut nicht aufs Arduino-Framework auf!
Sondern macht alles selber.
Der letzte Schrei ist nun die Erweiterung der Firmware um ein WebUSB-Interface und eine Ăpp, die im Browser lĂ€uft. Geeignete Browser sind derzeit Google Chrome und Microsoft Edge.
Ausfall Keine USB-KonnektivitÀt. Ursache: USB-Micro-Buchse nochmals von Platine abgerissen, wohl heftig am Kabel gezogen. Reparatur: Diesmal USB-Kabel direkt an den 22-Ohm-WiderstÀnden, am Masseanschluss und an der Sicherung angelötet sowie mit Zugentlastung versehen. Sollte halten, macht jedoch den Pro Micro schwerer austauschbar.
Datei | Beschreibung |
---|---|
prozess.zip | Firmware (fertig, mit WebUSB) und Win32-Software (unfertig) |
Eagle.zip | âGroĂeâ Ofensteuerung: Schaltplan + Layout |
SE.zip | âGroĂeâ Ofensteuerung: CAD-Daten GehĂ€use-Blechteile, Gesamtansicht |
Ofen.zip | Backup LabVIEW-Programm fĂŒr âalteâ Steuerung (Steuerung wurde in Bestandteile zerlegt) |
Arduino.zip | Backup Arduino-Software (ungenutzt, Teil der alten, zerlegten Steuerung) |
Masterarbeit Geidel.pdf | Ein mittlerweile ĂŒberholtes Pamphlet |
grafik.llb | LabVIEW-Beispiel zum nicht-ĂŒberlappenden Platzieren von Text (fĂŒr Anmerkungen) in einem XY-Graf, LabVIEW 8.5 |
grafik.png | Screenshot des Demo-Programms |
Serial-Win32.vi | LabVIEW-Programm |
Geometrie-Routinen zur Plotdarstellung sowie zum Maus-Treffertest. Da Drag-und-Drop im Plot nur bei weniger als 100 sichtbaren Punkten funktionieren sollte, sollten nur Grafen (Punktlisten) untersucht werden, die bei aktuellem Zoom auf eine derart reduzierte Punktzahl kommen.
Trivial: r = |mousepos - pointpos| = âMath.hypot(mouse.x-point.x,mouse.y-point.y)
Nicht so trivial: Sei A = Streckenanfang, B = Streckenende, C = Mausposition:
B -= A, C -= A, r = |B|, also B.x-=A.x; B.y-=A.y; C.x-=A.x; C.y-=A.y; let r=Math.hypot(B.x,B.y);
Distanz zur (unendlichen) Geraden: (B.x*C.y - B.y*C.x)/r
LĂ€ngsanteil zur Strecke, 0 = Anfang, 1 = Ende, <0 = davor, >1 = dahinter:
(B.x*C.x + B.y*C.y)/(r*r)
Preiswerte Temperaturaufnehmer, die das MCPS (??) und die teure und schwerfĂ€llige Yokogawa-Kiste ersetzen. FĂŒr USB, treiberlos, etwa 8-kanalig, je 2 Exemplare.
Da sich
Steckbrief: 2 Exemplare 8-Kanal-Temperaturlogger fĂŒr Thermoelemente Typ K, Abtastrate 1 Sa/s/Kanal, Logdauer mehrere Tage; PC-UnterstĂŒtzung. Daher genĂŒgt ein USB-Interface, das Messdaten direkt (ohne zu puffern) zum PC durchreicht. Irgendein Programm (WebUSB = JavaScript, LabVIEW, C++, Python, Matlab âŠ) nimmt die Daten entgegen und speichert als .csv oder (vielleicht besser) Matlab-Matrix (.mat).
Angedachte Realisierung: MAX31855 mit 4051-Analogsignalschalter und irgendein 3,3-V-USB-Mikrocontroller. Dabei genĂŒgt ein ATtiny44 mit V-USB und 3,3-V-LDO, typischerweise LP2950-33.
TatsĂ€chliche Realisierung: Wenn Datenlogger in Matlab, dann muss es eine serielle Schnittstelle sein (gĂ€hn đ„±). Also Full-Speed, kein V-USB. Also PIC16F1454. Das Loggen (ohne Zeitstempel) ginge dann mit einer simplen Kommandozeile: copy com8 Dateiname.csv, Linux đ /dev/ttyS0 > Dateiname.csv oder so Ă€hnlich. Eine VerwandtÂschaft besteht mit dem Frequenzmesser zur Durchflussmessung. Der MikroÂcontroller generiert an einem freien Ausgang eine WechselÂspannung zur BereitÂstellung einer negativen HilfsÂspannung fĂŒr den AnalogÂmultiplexer. Mal sehen ob dieser dadurch besser funktioniert. Die LED D1 ist vor allem zum Debuggen, da das Pin 8 = RC2 nicht frei verfĂŒgbar ist sondern vom SPI als serieller Datenausgang in Beschlag ist.
Hier kommt das (bereits herumliegende) Hammond-FlanschgehĂ€use 1590AFL (93Ă39 mm) zum Einsatz, welches um 9 mm heruntergefrĂ€st wird: Gesamthöhe nun 22 mm. Die UNC-Gewinde mĂŒssen dazu etwas nachgeschnitten werden, damit die Schrauben noch passen.
Der seltsame Spannungsregler IC4 = LDCL015-33 wurde in einer alten MesseÂmusterÂverpackung gefunden und âmusste mal wegâ. Er ist pinkompatibel zum bekannteren MIC5219.
Pufferung: Da der eingebaute USB-Seriell-Konverter âweiĂâ, wann Daten abgeholt werden und wann nicht, kann der Mikrocontroller die bis dahin noch nicht abgeholten Daten in einen (Flash-)Ringpuffer ablegen und âen blocâ liefern (= sich auskotzen). Das vermeidet LĂŒcken im Protokoll durch Windows-Reboots. Weiterhin kann durch ein (wie auch immer geartetes) AbfrageÂkommando zwischen ASCII- und BinĂ€rÂausgabe umgeschaltet werden â sowie die gesamte Historie abgefragt werden. Zudem erscheint das Einstellen der SummenÂabtastÂrate sinnvoll.
banksel
aufpassen!
Lieber einmal zuviel verwenden, Platz ist hier reichlich.
subwf
als auch sublw
sind teuflisch!subwf reg,w
entspricht w = reg - w
(invertiert w)
und c = reg >= w
subwf reg,f
entspricht reg -= w
und (genauso) c = reg >= w
sublw k
entspricht w = k - w
(invertiert w,
daher ist sublw 0
eine Negation)
und c = k >= w
addlw -k
!
skpb skpnb brb brnb
.
banksel
und pagesel
generieren
und SprĂŒnge anpassen (bra
durch goto
ersetzen)
ist ein Armutszeugnis fĂŒr die Assembler,
wobei gpasm durch seine gigantische GröĂe (ĂŒber 5 Megabyte mit DLL,
ohne Include-Dateien!) unangenehm auffÀllt
und mpasmx mit dem Popup-Fenster nervt.
Nirgends ist irpc
implementiert.
Die Makroverarbeitung in der LST-Datei ist unpraktisch:
WĂŒnschenswert wĂ€re die Kombination keine Makroexpansion
aber trotzdem Kodeausgabe.
So einfach ist das nicht! Weil man bei ThermowiderstÀnden besser mit einem Vierdrahtanschluss arbeitet sind diese Sensoren deutlich umstÀndlicher zu handhaben. Pt100 ist ohnehin old-school, wenn möglich sollte man zu Pt1000 (1 k⊠bei 20 °C) umschwenken, weniger EigenerwÀrmung, geringerer Stromverbrauch. Diese gibt es in klitzekleinen SMD-GehÀusen, aber man darf sie nicht (wie Dehnmessstreifen) starr aufkleben, da sie sonst einen parasitÀren Dehnmessstreifen-Effekt zeigen.
DafĂŒr gibt es den maĂgeschneiderten Chip MAX31865. Diesen gibt es entweder einzeln im QFN20-GehĂ€use mit (IMHO) 0,65 mm Pitch oder als Arduino-Baustein mitsamt Pegelwandler und Spannungsregler. Auch wenn die Lochraster-Verdrahtung irre aufwĂ€ndig ist, bleibe ich auch diesmal dem Lochraster treu und verwende das Arduino-Teil von Ebay. Diesmal mĂŒssen vier Analogmultiplexer 74HC4051 vorgeschaltet werden. Das praktische Konzept mit dem superbilligen Mikrocontroller PIC16F1454 (mit Urlader vorprogrammiert) wird beibehalten.
Hier kommt das Hammond-FlanschgehĂ€use 1590BFL (112Ă60 mm) zum Einsatz, welches um 9 mm heruntergefrĂ€st wird: Gesamthöhe nun 22 mm. Die UNC-Gewinde mĂŒssen dazu etwas nachgeschnitten werden, damit die Schrauben noch passen.
FĂŒr einen Temperaturbereich von -55 .. +125 °C tun's auch die viel leichter anwendbaren DS18B20 (parallelschaltbare Temperatursensoren mit A/D-Wandler und OneWire-Interface im TO92-GehĂ€use), wenn das GehĂ€use klein genug ist. Das ist hier der Fall. Das praktische Konzept mit dem superbilligen Mikrocontroller PIC16F1454 (mit Urlader vorprogrammiert) wird beibehalten.
An den beiden Schraubklemmsteckern können zwei Gruppen von DS18B20 angeschlossen werden, oder mit einer Firmware-Modifikation kann an einem von beiden ein Schaltsignal, bspw. bei Ăbertemperatur, ausgegeben werden.
Hier kommt das (bereits herumliegende) Hammond-FlanschgehĂ€use 1590LBFL (51Ă51 mm) zum Einsatz, welches um 9 mm heruntergefrĂ€st wird: Gesamthöhe nun 22 mm. Die UNC-Gewinde mĂŒssen dazu etwas nachgeschnitten werden, damit die Schrauben noch passen. Der quadratische GehĂ€usedeckel kann mitsamt Schaltung um 90° zu den Flanschen gedreht werden, wenn das zum Einbau besser passt.
Eine eventuelle Verpolung der Temperatursensoren wird dadurch erkannt, dass bei Busruhe ein Kurzschluss nach Masse besteht. Dieser wird als solcher erkannt, bevor das betreffende Portpin zum Ausgang umgeschaltet wird. Damit bleibt der Strom vom 4,7-kâŠ-Pullup mit 1 mA so klein, dass nichts kaputt geht.
Es ist durchaus eine gute Idee, von den DS18B20 nicht allzu viele parallel zu schalten, da diese nur bei Busruhe (sicher) die Temperatur messen und dafĂŒr bei maximaler Auflösung eine knappe Sekunde (!) benötigen.
Wenn man sich umsieht, werden ĂŒblicherweise Sensoren mit DS18B20 mit drei AnschlĂŒssen angeboten und (anscheinend) angeschlossen. Dabei verliert man den Verpolungsschutz und gewinnt:
Was macht man mit einer ESP32-CAM? Abgesehen von der Verwendung der unverĂ€nderten Anwendungssoftware, der WLAN-Kamera (fĂŒr die Anwendung im Heimnetz) möglicherweise mit âKnipsfunktionâ auf die Mikro-SD-Karte fallen mir immerhin zwei AnwendungsfĂ€lle ein, die einen erheblichen Eingriff in die Firmware erfordern:
Ressourcen ĂŒber hardwarenahe Programmierung sind dĂŒnn gesĂ€t. ESP32 Bare Metal vielleicht, der Installationsaufwand ist trotzdem riesig. Leider hat sich Espressif auf CMake und Python als zwanghafte Teile der Entwicklungsumgebung festgenagelt, was mich als Makefile-Auskenner elend ausbremst. FĂŒr mich ist ESP32 erst dann âBare Metalâ wenn nur noch gcc und make und ein Flashprogramm (als Echse) nötig sind.
EntfĂ€llt! Genau dafĂŒr gibt es das WLAN tuc-special, bei der man den Zugang bei bekannter Ethernet-ID beim URZ beantragt. Damit verhĂ€lt sich das UniversitĂ€ts-WLAN etwa so wie ein heimisches.
Trotzdem wĂ€re es hilfreich, den Datenstrom auf WebSocket auszugeben und die feilgebotene Webseite aufzuhĂŒbschen. Es wĂ€re nicht schlecht, wenn eine Client-Webseite mehrere derartige Webcams beobachten kann.
Der Videostream erscheint als MJPEG auf http://host:81/stream. Sobald man diesen angestoĂen hat. Leider ist das Bild (warum auch immer) kleiner als die ausgewĂ€hlte Kameraauflösung, sodass die Kamera nicht so recht bewertet werden kann. Auch handelt es sich mit MJPEG nicht um ein modernes Videostream-Format, welches man in den HTML5-<video>-Tag packen kann. Aber es ist bereits eine erhebliche Softwareleistung des ESP32-CAM, jedes Bild als JPEG zu komprimieren.WebSockets sind also unnötig. Eine Konfiguration der BildgröĂe, etwa mittels http://host/?width=1600&height=1200&whitebalance=auto, wĂ€re sinnvoll. Auch unterstĂŒtzt die Firmware nicht den Output zu mehreren Clients. WĂ€re das ein Fall fĂŒr Multicast?
Nach einiger Fummelei entstand dieses Kamera-Projekt im Arduino 2.0.1. Dieses generiert keine Webseite sondern nur den Kamera-Stream als MJPEG. Wiederum nur fĂŒr 1 Client. Es wird kein PSRAM erkannt. Da ist ein 8-beiniger APS6404L-3SQR (8 MByte via SPI/QSPI) drauf. Die Adresse des WLAN-Routers wird beim Hochlauf oder bei Verbindungsproblem via serielle Schnittstelle erfragt, wobei ein (fĂŒr Arduino viel zu schicker und unnĂŒtzer) Zeileneditor zum Einsatz kommt. Idealerweise lĂ€sst man auf der seriellen Schnittstelle ein PuTTY laufen. Wie gewĂŒnscht werden die WLAN-Zugangsdaten abgespeichert.
Die Kamera ist einsetzbar, lĂ€uft aber noch ohne Konfigurationsmöglichkeit (Auflösung + Framerate) und - noch schlimmer - mit angezogener Handbremse (kein PSRAM) und auf halber Kraft (ohne zweite CPU). FĂŒr den Zugriff auf tuc-special muss man sich im gleichen Subnetz befinden.
Ich habe etwas durcheinandergeworfen:
Einerseits gibt es die (zuerst getestete) Kamera-Ăpp,
die so elend plump zu bedienen ist,
und dann gibt es den reinen VideoBilder-Stream-Generator.
Beide Ăpps liefern mangels (erkanntem) PSRAM ein zu kleines Bild.
Obendrein werde ich von dem Umstand ausgebremst,
dass der Firmware-Download mit dem heimischen
Dell-Notebook mittendrin versagt.
Wacklige Versorgungsspannung?
Auf Arbeit funktioniert das mit den dortigen Barebones einwandfrei.
Heute zum Nikolaustag 2022 geht endlich der PSRAM: Nachdem ich das ganze Arduino-Geraffel nochmal unter Windows installiert habe (weil das Linux neuerdings dazu tendiert, immer hĂ€ufiger abzustĂŒrzen und kaum eine Stunde(!) durchhĂ€lt), gab es weitere Tools-MenĂŒpunkte, u.a. die das Debug-Level und die Flash-Aufteilung betreffen. Ob es daran liegt oder nicht, ich konnte die (meine) Quelle damit ĂŒbersetzen, flashen, und voilĂ , es meldet PSRAM vorhanden (juhu) und volle BildgröĂe! Angezogene Handbremse gelöst, jetzt noch den zweiten Topf aktivieren und (v.a. fĂŒr die Bilderkennung) nutzen. Kamera-Konfiguration fehlt auch noch.
Daraufhin habe ich mich mal in das Thema Multicast eingelesen. Einerseits muss die URZ-Infrastruktur (hier: tuc-special) Multicast zulassen. IPv4 oder IPv6 erscheint egal, IPv4 erscheint einfacher. Wie man's fĂŒr IPv4 in C programmiert steht da auf deutsch beschrieben. Es ist aber zu befĂŒrchten, dass man dazu einiges in den Espressif-Sourcen anpassen/einbauen muss, damit das klappt. Interessant ist auch, wie Multicast im Ethernet funktioniert. Leider sieht es auf der Browserseite mau aus, weil per JavaScript kein UDP empfangen werden kann. Schade. Der gĂ€ngige Umweg dafĂŒr ist ein Python-Hilfsprogramm, das die UDP-Pakete in WebSocket eines lokalen Webservers umpackt; das kann dann per JavaScript weiterverarbeitet werden. In jedem Fall muss das Konzept mit dem HTTP-Header aufgegeben werden, da sich Clients (hier: Videobetrachter) jederzeit einhĂ€ngen können dĂŒrfen und eine Modifikation der BildgröĂe und Bildrate alle Teilnehmer betrifft (logisch!).
Bisher kommt dafĂŒr ein Raspberry Pi mit Weitwinkel-Kamera zum Einsatz. Aber mit dem Raspberry auf einem Fahrzeug fangen die Probleme an:
Hinzu kommt, dass der Raspberry dazu verleitet, vorhandene Software zur Bildverarbeitung unverĂ€ndert zu nutzen â und dann reinzufallen, etwa mit Genauigkeits- und Latenzproblemen. Besser ist es stets, jeglicher Software auf den Grund zu gehen, noch besser, sie neu zu schreiben: Github ist nicht mehr als eine SoftwaremĂŒllhalde. Zur BewĂ€ltigung der Datenmenge durchaus in Assembler.
FĂŒr ArUco-Erkennung gibt es bereits diese Lösung in JavaScript.