Skip to content
Snippets Groups Projects
Select Git revision
  • main default
1 result
Blame Permalink
Notizen.md 19.76 KiB
  • Eine Platine pro Heizung.
    • Aber einen zweiten Kanal vorsehen, damit man zwei Heizungen hängen kann.
  • RS485 Bus.
    • Bus ist ernstgemeint, d.h. eine lange Kette, keine Stichleitungen und Abschlusswiderstände am Ende.
    • Entweder an einer Stelle auf LAN brücken, z.B. mit https://www.waveshare.com/wiki/RS485_TO_POE_ETH_(B)
    • Oder per Netzwerkkabel plus USB zu vogon. Das Netzwerkkabel natürlich so, dass es nicht einfach auf Netzwerk zurücksteckbar ist.
    • Protokoll z.B. Modbus RTU oder was eigenes in Anlehnung daran.
  • Abzweigdose als Gehäuse
  • MCU
    • Warum RP2040?
      • Klassische Wahl wäre ein ATmega328.
      • Aber RP2040 hat eigentlich keine Nachteile und der USB Bootloader klärt die Frage, wie man es schafft, dass bei Problemen jeder die Firmware ohne RS485 Bootloader programmieren kann.
      • Den Flash können wir groß genug machen, dass man eine Art A/B Partition vorsehen kann.
        • Direkt A/B geht nicht, weil dem XIP kann man anscheinend keinen Offset vorgeben und dann müsste alles ohne XIP oder mit -fPIC sein.
        • Aber Leute haben sich was überlegt: https://github.com/rhulme/pico-flashloader
        • Dem könnte man noch ein "boote in die alte Version" geben, wenn man immer zwei Images da liegen hat und noch einen Button spendiert.
      • Weiterer Vorteil wäre, dass es ein richtiger ARM ist, d.h. LLVM und Rust sind kein Problem. Genug RAM für sinnvoll MicroPython, falls man das mal will. Und es ist ein Dual-Core. Wobei wir darauf hier ehrlich gesagt verzichten könnten, weil C und Mini-Programm reicht.
      • Ah, und JLC bestückt uns zwar auch den ATmega328P - aber für 3€ statt 1€!
      • Nachteil: Nur 4 ADC Pins.
      • Nachteil: Hardware-Design ist (abgesehen vom Programmer) etwas aufwändiger als beim ATmega. Aber ich würde einfach den Raspi Pico kopieren.
    • ...
  • Kabel
    • fxk8y hat 7-fach Steuerleitung vorgeschlagen, bei Alpha verfügbar. Konkret: Tronic LIYY 7x0.5
    • 2x 24V, 2x GND, 2x RS485 A/B, 1x WS2811
    • Die siebte Leitung ist frei und da noch mal GND zu machen oder so klingt nicht sinnvoll. Stattdessen einen WS2811 auf die Platine zum Signal verstärken und dann kann man quasi an beliebigen Stellen LED-Streifen verteilen.
    • Auch noch eine WS2812-4020 mit aufs PCB zum Debuggen.
    • Der WS2811 hängt am MCU. Das könnte praktisch sein für Auto-Discovery Dinge.
    • RS485 ist nicht separat verdrillt oder geschirmt. Falls das WS2811 Signal den stört, nutzen wir das Feature nicht.
  • Externe Hardware-Features
    • Pins auf Federzugklemmen:
      • 14x Bus-Kabel
        • 8x Power: 2x 24V rein, 2x raus, ebenso für GND (damit man das Kabel direkt anklemmen kann)
          • Alternativ nur 4x und Doppel-Aderendhülsen nehmen. Ist eigentlich auch ok.
          • Einige Klemmen können nur AWG18=0.8mm² - das reicht nicht.
          • KF250T-5.0-2*13P kann 1.5mm², d.h. da geht es.
        • 4x RS485: rein und raus (und beim letzten nen Widerstand statt weiteres Kabel)
        • 2x WS2812 vom/zum Kabel
      • 8x Heizung
        • 2x 24V Ausgang mit PWM für Wachsmotor, 500 mA Peak (einige sec), 85 mA continuous
        • 2x Strom messen auf den 24V Ausgängen
          • bevorzugt: high-side schalten, low-side messen -> deshalb extra Pin nötig
          • alternativ beides low-side und zum passenden Zeitpunkt messen, aber dedizierter 24V Pin ist trotzdem praktisch
          • Sofern der Wachsmotor keinen relevanten induktiven Anteil hat (gut möglich - ist ein Heizdraht), würde low-side messen+schalten reichen, weil dann müssen wir nur während angeschaltet messen.
          • Der Grund für Strom messen wäre, dass ich hoffe damit die Temperatur vom Wachs abzuschätzen, weil warum sollte sich sonst der Strom von 480 mA auf 85 mA reduzieren (laut einem Datenblatt von so einem Aktor). Ist aber nur nice-to-have, nicht nötig. Beziehungsweise schon irgendwie nötig, wenn/weil wir vorhaben die Power-Supply nicht auf Peak auszulegen und versetzt zu schalten.
        • 4x Digital-Eingang für Reed-Relay (2 pro Fenster); aber Umsetzung später, nur Eingänge vorsehen
      • 2x 5V Ausgang
        • I2C
        • WS2812
        • DS18B20
      • 1x GND
      • 1x 0-10V Eingang
      • TODO: Was wäre noch sinnvoll?
    • Features ohne extra Pin:
      • 1x 24V Versorgung messen
      • Nein: 1x DS18B20 oder DS18B20+ als Temperatur-Sensor und Unique ID
        • Eher nicht. Der kostet 1€, wird im Gehäuse nur Mist messen und eine Unique ID haben wir auch so: https://stackoverflow.com/a/74320491
        • Man könnte LM335DT nehmen, aber weil der analog ist hätten wir da auch Offset-Fehler durch die Referenzspannung wie bei dem integrierten Sensor im RP2040 (siehe Datenblatt, Section 4.9.5). Bei 1% Fehler in der Referenzspannung sind es aber nur 0.8 K statt 4 K wie bei dem integrierten.
        • Zu dem integrierten ist darüber hinaus leider nichts angegeben.
    • User Interface:
      • Ich dachte zunächst an seitwärts gerichtet und Loch ins Gehäuse machen, d.h. WS2812-4020 und 90 Grad gekippte Taster. Aber ist eigentlich nur unnötig Aufwand, weil das Gehäuse ist werkzeuglos zu öffnen und beinhaltet keine gefährlichen Spannungen.
      • 1x LED am MCU, z.B. RGB; zum Debuggen vom RS485 und MCU
      • 1x LED in der WS2812 Leitung, zum Debuggen davon
      • 1x Taster für Reset - nicht im Betrieb nutzbar
      • 1x Taster für USB Bootloader - nicht im Betrieb nutzbar, weil hängt am CS vom Flash
      • 1x Taster für unseren Bootloader (z.B. altes Image starten). Im Betrieb nutzbar, z.B. zum Adressen anlernen.
      • 1x USB. Den eventuell schon seitlich, weil sonst teuer und schwer erhältlich.
      • LEDs und Taster nicht dahin, wo Kabel lang gehen.
  • Hardware-Design
    • MCU
    • Power
      • Wir brauchen kaum Leistung, d.h. einfach nen LDO nehmen. Leistung für den Wachsmotor geht nicht durch den LDO.
      • Diode als Verpolungsschutz (nicht so richtig nötig) und um den MCU optional von USB zu versorgen.
        • Diode von USB muss so sein, dass nach dem LDO noch 3.3V raus kommt. Eventuell MOSFET nehmen.
      • Die vier 24V und GND auf der Platine nebeneinander und Plane mit Vias. Da fließen ggf 8A drüber.
    • Anschlussklemmen:
    • Platz:
      • Wir haben grob 66x66 mm und 32 in der Höhe. Das sind 43 dm². Da geht aber noch etwas weg wegen den Plastikpins und den Schrauben.
      • Der Raspi Pico hat 50x20 mm, also 10 dm². Der ist aber nicht gerade platzsparend gebaut.
      • Anschlussklemmen KF250T-5.0-2*13P mit 66x22m, also 15 dm².
        • Plus wenn wir die echt nehmen, kostet uns das 5 mm in der Tiefe, d.h. 5x66 also 3.3 dm².
        • Falls wir das doppelte nehmen können, wäre sinnvoll Platz für Beschriftung.
      • User Interface: 2x LED mit 5x5mm plus Abstand, also 0.4 dm². 3x Taster mit sagen wir mal 8x6mm, also 0.5 dm². Zusammen 2 dm².
      • Damit haben wir noch 13 dm² für MOSFETs und so. Und vielleicht bleibt dann echt noch mal 3.3 dm² für Beschriftung übrig.
    • Strom messen
      • Gut, dass ich mal LTspice dagegen geworfen habe: Wenn ich low-side den Strom messe, wird der leider negativ, sobald ich die high-side abschalte.
      • High-side Messung mit LT138 oder so mag vielleicht helfen, aber der kostet 1.5€.
      • INA2180A1IDGKR für 0.45€ würde wohl gehen. Und der hat dann schon zwei Channel.
      • Einziges Problem am INA2180 ist, dass 26V das Absolute Maximum sind. Das ist mir doch etwas knapp. Und wenn wir nur deshalb nicht die Spannung etwas hoch drehen können, wäre schade.
    • MCU Pinout:
      • 4x ADC ist klar. Da gibt's nur vier von leider.
        • GPIO26..29
      • 1x I2C, PIO, PWM für die Digital-Ausgänge. Eventuell wäre auch SPI TX hilfreich, falls das für WS2812 besser geht als PIO.
        • I2C gibt's alle zwei Pins, abwechselnd I2C0 und I2C1.
        • SPI und UART sind beides 4-er Gruppen, d.h. SPI TX und UART TX bekomme ich nicht beide (oder ich muss es mit zwei Pins verbinden).
          • Andererseits steht WS2812 mit PIO sogar als Beispiel im Datenblatt.
          • UART auch.
        • PWM gibt's quasi überall.
        • PIOs gibt's beide überall und der Start-Offset ist einstellbar.
        • -> GPIO24+25: UART1 RX/TX, I2C0, PWM4
        • Eventuell zusätzlich GPIO23 für SPI0 TX und GPIO18 für SPI0 SCK, aber eigentlich nicht sinnvoll weil langsam. Und CS müsste man über GPIO21 über den Widerstand vom Digital-Eingang treiben. -> Nein, weil sonst habe ich keine Pins für Taster mehr.
      • 2x SBU
        • ebenfalls auf UART1 und wenn möglich I2C0 -> 4+5 oder 8+9
      • 1x I2C auf Stiftleiste für optionales Display.
        • I2C0, d.h. 4*n+0
        • // 8+9, weil da ist PWM4, was wir schon benutzen. -> Nein, da ist SBU.
      • 5x PWM für LEDs.
        • Quasi überall, aber nicht PWM4 nehmen.
      • 2x PWM für Heizung.
      • 1x UART für RS485
        • UART0 nehmen -> 0+1, 12+13, 16+17
        • Erstmal 16+17 und TX_EN auf 15.
      • VBUS_DET? Der Pico hat es an GPIO24 (mit Spannungsteiler), was nicht passt. Der RP2040 Zero hat es nicht. Aber evtl wollen wir USB schlafen legen.
        • GPIO ??
      • 4x Reed / Digital-Eingang
        • Im Prinzip egal wohin, sofern man es nicht anderweitig nutzt.
        • UART RX
        • GPIO20 oder GPIO22 sind Clock Inputs. Das könnte man eventuell als Frequenzzähler nutzen.
        • GPIO19 bis GPIO22: UART1 RX, SPI0 RX
      • Taster-Matrix:
        • Dual-Purpose Ausgänge:
          • TX solange TX_EN nicht gesetzt
          • 5x LED theoretisch aber die ziehen runter und ggf wollen wir die aktiv low treiben; weiß vielleicht?
          • 2x I2C, aber die PU stören vermutlich (wenn mehr als 1 Taster gedrückt) -> Dioden hier oder in der Taster-Matrix sollten helfen
        • GPIO 7, 18, 23
  • Protokoll:
    • Modbus RTU:
      • Viel einfacher wird's nicht, solange man nur die Register-Zugriffe implementiert.
      • Es gibt zwei Python Libraries.
      • CRC sind sinnvoll. Zusätzlich Parity muss ich nicht haben, aber was soll's.
      • Abstand zwischen Nachrichten würde ich evtl nicht nach jeder machen.
      • Die Zusatzfeatures für Diagnose (Event Log) und ID klingen sinnvoll.
    • Baudrate und so:
      • Aufstarten mit Standardeinstellung (19200, 8-E-1)
      • Auto-Baud per Break und dann Zugriff auf Gerät 0x55, wenn man eine andere Baudrate möchte.
      • Mit Adresse 0x55 würde ich dann auch die sonstige Zusatzfeatures machen wie den Broadcast für Auto-Discovery.
    • Auto-Discovery:
      • Ich habe wenig Lust, die Adressen manuell zu verteilen.
      • Simpel: "setze deine Adresse auf xx, falls dein Button gedrückt ist". Das kann ein Schreibzugriff auf ein bestimmtes Register von Broadcast-Gerät 0x55 sein. Adresse wird dann in den Flash geschrieben. Bevor sie eine Adresse im Flash haben, reagieren sie nur auf 0x55.
      • Auto-Discovery ginge auch einfach mit Broadcast und Backoff. Parameter wie Anzahl der Backoff Slots, Seed und die Wahrscheinlichkeit überhaupt zu antworten stehen mit in dem Broadcast. Es gibt eine maximale Zeit und nach der darf nicht mehr geantwortet werden, damit wieder normale Kommunikation möglich ist.
        • Man setzt ein Flag im Device für "ich kenne dich schon". Das deaktiviert Reaktion auf den Broadcast (ggf optional per Flag in dem Broadcast) und erlaubt dem zentralen Controller einen Reset des Geräts festzustellen.
        • Der Vorschlag kam so halb von ChatGPT. Meine Variante wäre eher was in der Art von DS18B20 gewesen, evtl mit mehreren Zeitslots um direkt 4 bit abzufragen.
        • Der Vorteil ist, dass man mit allen Geräten reden kann, ohne sie anzulernen (und man weiß nur nicht, welches wo ist).
        • Die Adresse ist entweder permanent im Flash oder die zentrale Steuerung merkt sich die Chip-ID vom MCU und vergibt die Modbus-Adressen bei jedem Start neu.
  • Non-Features / nicht umgesetzt:
    • USB Host: Der MCU kann es und wäre cool zu haben für Erweiterungen.
      • VBUS EN per P-MOS auf VBUS (und ggf ersetzt der die existierende Diode für die andere Richtung)
      • Die 5.1k PD so mit VBUS EN verbinden, dass die zu PU werden. Es muss aber ein PD dran, damit es sich im Bootloader korrekt als USB Device meldet. Das braucht etwas Kreativität, damit in beiden Fällen der Widerstand im richtigen Bereich liegt. Oder man muss einen Pin finden, den der Bootloader auf low treibt.
      • Problem: Geht auf keinen Fall standardkonform, weil wir nicht genug Strom auf 5V zur Verfügung stellen können.
      • Und wenn man sowieso die 5V extern einspeisen muss, brauche ich auf der Platine nix weiter zu tun.
    • BJT vor den MOSFET, damit man das Gate auf höhere Spannungen bekommt? -> Nein, weil das Gate kann keine 24V.
    • Spulen mit rein zum Motor für langsamere Anstiegszeit / EMV Abstrahlung auf der Zuleitung? -> fxk8y hat sich sehr eindeutig dagegen geäußert.
  • Sonstiges
    • ADC für Strommessung und Option bauen, um wenig Strom auf die Aktoren zu geben (zum Messen)
      • Ich dachte per Widerstand die 5V drauf, aber ne, high-side schalten wir ja gar nicht.
      • Aber per Widerstand die 0V drauf würde gehen.
      • Hm, an sich würde auch reichen, den Strom 1x gemeinsam zu messen und halt kurz den anderen Abschalten zum Messen.
      • Es reicht, wenn ich das für beide gemeinsam anschalte. Dann brauchts nur einen Pin. Auch den habe ich nicht, aber man könnte einen der LED-Pins missbrauchen.
      • Aktuell erwarten wir bei 300 mA eine Spannung von 30 mV. Mit einer Referenz auf 3.0 V und 12-bit ADC sind das: 0.3×0.1/3.0×4096 = 41 counts
      • Das ist nicht toll, aber reicht locker.
      • Wenn ich 10 mA zum Messen drauf gebe, wären das 0.01×0.1/3.3×4096 = 1 count -> nope.
      • Mit OpAmp würde ich das so verstärken, dass wir maximal 0.5 A oder 1 A messen können. Nehmen wir letzteres. Das wäre dann Faktor 30 im OpAmp und wir haben 3.0V / 1 A.
      • Dann wären die 10 mA auch 30x so viel, was konkret 37 counts sind (oben war gerundet).
      • Das klingt voll ok.
      • Für 10 mA muss ich das über 2.4 kOhm mit GND verbinden.
      • Welcher OpAmp kommt in Frage? Wie viel Strom würde der brauchen?
        • OP07C ist anscheinend der einzige OpAmp in Basic Parts. Aber der will mindestens +-3V.
        • Ach ne, Suche war nur doof.
        • LM358D: Wir haben bis zu 30 mV am Eingang normalerweise und 1 mV, wenn wir mit 10 mA messen. Da klingt ein Offset von 2 mV nicht gut.
        • LMV321I: Wenig Supply Current, rail-to-rail, aber auch 2 mV Offset. Grundsätzlich gefällt der mir aber.
        • NE5532DR: Nur 0.5 mV Offset, aber 8 mA Supply.
        • Ok, die anderen sind auch nicht besser.
        • LM324DT hat auch die 2 mV Offset-Voltage - also für unseren Fall ist nix angegeben und wird etwas schlechter sein, aber die Max-Werte sind so wie bei den anderen, die auch 2 mW haben. Und der hat auch weniger Stromverbrauch und ist günstiger durch 4x in einem Package.
        • Ok, die meisten anderen haben 2x im Package und das reicht uns. Aber bezüglich Stromverbrauch und Offset kommen die nicht ran.
        • Oh, Moment... beim MCP6002T ist kein typical Wert angegeben für den Offset und +-4.5 mV maximal ist gar nicht schlecht. Und er hat weniger Power.
        • Dann nehmen wir den.
        • Fun fact: Das untere Ende sind VSS-0.3V, d.h. mit dem hätte man sogar negative Ströme messen können.
      • Ich nehme mal Faktor 60, d.h. funktioniert bis 500 mA. Wenn man mehr will, muss man halt den Shunt tauschen.
    • Wie viel Watt kann ich durch den Widerstand zum Strom messen schicken?
      • Den 0R1 hatte ich schon größer gemacht, aber der ist harmlos wegen der niedrigen Spannung und bei Kurzschluss kann ich nicht viel machen (sofern die Sicherung vor den 24V den nicht rechtzeitig abfängt).
      • Die 2.4 kOhm für die 10 mA Messstrom sind aktuell ein 0402WGF2401TCE. Das WG heißt 1/16 Watt. Es fallen aber 240 mW ab. Upps.
      • In dem Package wäre ok: 24/(1/16)×24 = 9.2 kOhm
      • Das wären 2 mA. Das wären 16 counts am ADC. Nicht so toll. Aber selbst die 0805 haben nur 1/8 W.
      • Dann wird's wohl ein Extended Part mit 1206.
      • Oder auch nicht: Es gibt Basic Parts mit 2k und 4.7k. Wir machen das nicht dauerhaft an und der Motor hat auch noch 100 bis 500 Ohm. Ab 2.3 kOhm passt die Power und wir machen das ja immer nur kurz an. Ich denke, 2k sind ok.
    • Quarz vom MCU:
      • hardware-design-with-rp2040.pdf hat da Infos zu (die aber im Prinzip nur das übliche sind).
      • Relevant ist allerdings, dass sie ggf einen Serienwiderstand empfehlen. Das könnte auch sinnvoll sein zum Strom sparen, vermute ich.
      • Deren Quarz hat ESR 50 Ohm. Ich habe X322512MSB4SI (C9002). Der hat bei 12 Mhz 80 Ohm.
      • Der will nur 20 pF Kapazität. Im PDF haben sie 18 pF als Ziel und tun dafür 27 pF daneben schalten. Hm. Vertraue ich jetzt dem Datenblatt oder dem Pico Schaltplan (und dem RP2040 Zero, die das vermutlich aus dem vom Pico abgemalt haben)?
      • Aber womöglich haben die einen Quarz mit 10 pF Lastkapazität.
      • Dann ändere ich es mal auf 27 pF. Theoretisch würde ich 3 pF mehr brauchen, damit es 20 pF statt 18.5 pF sind, aber nah genug.
      • Mit 27 pF gibt's kein Basic Part. 30 und 33 gibt's. Oder 22 pF. Tjoa, dann eben doch die 30. Ah, ne, gibt doch auch 27 pF. Die hat nur die Suche nicht gefunden.

TODO und weitere Gedanken:

  • Anschlussplan wird nicht auf die Platine passen, aber kann man in den Deckel kleben.

  • Netzklasse für UBS passend machen, z.B. 0.8mm wide with 0.15 mm space. Impedance should be 90R.

  • Testpunkte - auch für Bauteile, die man von der Vorderseite schlecht messen kann.

  • Bilder aktualisieren

  • OLED als Board kaufen oder irgendwie anders auf eigene Platine? -> Nicht gut ohne Breakout kaufbar und Breakout hat noch diverse Kondensatoren und so. Ich würd's einfach von unten an mein PCB löten.

  • Display-Board:

    • OLED mit SSD1306
    • Taster per Matrix oder I2C
    • Noch ein TMP102
    • eventuell eine LED