Kommunikation über Signaltransformator | Geeignetes Encoding

Schon mal an Funk gedacht? Wenn mehrere Slaves zu einem Master senden, brauchst du sowieso irgendein Protokoll, damit es nicht zu Störungen kommt.

Von TI (und evtl auch anderen Herstellern) gibt es RS485 Transceiver die OOK on Board haben: https://www.ti.com/lit/gpn/THVD8000

Flip B. schrieb:

idealerweise Senden und empfangen mit minimaler CPU beteiligung.

Minimal wäre aus meiner Sicht bei 1kbit/s ein UART mit 2 Optokopplern, Stromschleife für die Richtung Zentrale->Meßeinrichtung und Open-Collector-Bus für die Rückrichtung. Macht aber nicht soviel her, wie eine aufwändigere Lösung.

Gruß Klaus (der soundsovielte)

Digitale Isolatoren verwenden? Z.b. https://www.we-online.com/de/components/products/di/digital-isolators-power Oder was ähnliches von TI?

Dann kann man einen simplen UART nehmen.

Flip B. schrieb:

Kennt jemand einen Standart oder ein Projekt, was sich mit der einfachen Datenübertragung über Signaltrafos befasst? Ich möchte ein paar Daten zwischen Microcontrollern übetragen. Die Messeinheiten hängen auf unterschiedlichen potentialen max. 500V differenz an verschiedenen anlagen, also

Klingt nach Batteriesystem.

• Es muss Galvanisch getrennt werden
• Die Datenmenge ist gering und nur gelegentlich. max. 1kbit/s
• Es sind bis zu 200 solche messeinrichtungen an einem Bus
• Die Daten müssen alle zu einer Zentralen Kontrolleinheit
• Die Zentrale hat unbegrenzt Energie
• Messeinheiten nur Busspeisung oder Batterie. 5-10mA während der komminikationsdauer ist aber ok
• Leitungslänge kurz, bis max 10m
• Es könnten an den Busklemmen beim Anstecken oder im Fehlerfall hohe gleichtaktspannungen anliegen.

Dafür kann man auch Optokoppler/Digitalkoppler nehmen.

Ich denke ein Token-Ring/Daisy-Chain ginge ganz gut, da jede Messeinheit ihren aktuellen Messwert an die Anfrage anhängen kann.

Viel zu fehleranfällig.

Ich bin über Optische trennung hin zu Signaltrafos gekommen, die gibt es reichlich z.b. für 100/1000BaseT Ethernet. Bei Optischer Trennung kann ich nur Empfängerseite oder nur die Senderseite trennen.

Hä? Es gib bidirektionale Koppler im kleinen Gehäuse mit wenig Stromverbrauch, z.B. Si8422 und viele andere.

https://de.rs-online.com/web/p/digitale-entkoppler-ics/7532208

Die gegenstelle muss mittels TVS-Dioden geschützt werden. mit Trafos könnte ich beide seiten schützen, dann sind eben die Übertragungsverluste 2db statt 1db

Jaja.

Wie bekomme ich ganz ohne Ethernet PHY, nur mit den Boardmitteln eines üblichen µC und einigen kleinteilen am besten die Daten über den Trafo. Also Gleichspannungsfreies Signalencoding, zuverlässige Taktrückgewinnung und idealerweise Senden und empfangen mit minimaler CPU beteiligung.

Manchesterkodierung.

Falk B. schrieb:

Batteriesystem

Fast, es geht um testweises spannungsfall- und Temperaturmonitoring an Kontakstellen und steckern. Kann natürlich auch in einem Batteriesystem eingesetzt werden. Ich kann mir aber viele weitere einsatzszenarien für einen Galvanisch getrennten Bus vorstellen, z.B. Elektroverteilungen, Solar, Batterien, Haustechnik

Helmut -. schrieb:

Schon mal an Funk gedacht?

Ehrlich gesagt schon, ja. Es kann schon sein, dass es darauf hinausläuft, falls mir nichts besseres einfällt. Schön an einem Kabel-Medium in Chain-Topologie ist, dass die Adressierung wegfallen kann. Das klappt mit funk nicht, da müsste man noch anlernen oder wenigstens die UID aufdrucken. Ich denke weiterhin brauche ich mit funk recht viel Energie im Standby, da der Empfänger laufen muss. Ein Trafo/optisch getrenntes System kann im Sleep bleiben, bis ein interrupt kommt. BLE käme vielleicht mit energy-harvesting aus, das wäre ganz elegant, dann ist es ein drahtloses system.

N. M. schrieb:

RS485 Transceiver die OOK on Board haben

Das sind echt schöne teile, aber auch exotisch und teuer. Wenn die teile dann mal von 3 auf 10€ aufschlagen, dann kann ich gleich 10Base-Ts transceiver kaufen. Momentan denke ich, ein kleiner STM32G0 sollte als Prozessor reichen, der Transceiver sollte da nicht 10x so viel kosten wie der µC. Dann kann ich auch Toslink-Transceiver nehmen und optisch verkabeln. Dachte eben, mit Ethernet-Trafos geht es simpler.

Ich denke (differentielle)- Falk B. schrieb im Beitrag #7683826:

Manchesterkodierung

und etwas protokoll obendrauf ist eine bewährte sache und wird schon funktionieren. Vermutlich kann ich das vorrechnen und dann per DMA über einen USART oder timer rausschicken. Zum empfangen wäre sowas wie die PIO im RP2040 praktisch. Oder was mittels timer Input Capture basteln.

Zuletzt hatte ich noch den einfall, die paar mA für die Prozessoren der Messeinheiten mit über den Trafo zu schicken. Also wirklich ein BUS an dem paralell alle geräte hängen, die Zentraleinheit gibt eine modulierte sinusspannung aus, der rückkanal über Lastmodulation. Also ähnlich wie RFID/NFC. da fällt mir ein, diese Transceiver sind günstig, können aber sicher nicht 200 geräte mit 2-3mA versorgen.

Flip B. schrieb:

Manchesterkodierung

und etwas protokoll obendrauf ist eine bewährte sache und wird schon funktionieren. Vermutlich kann ich das vorrechnen und dann per DMA über einen USART oder timer rausschicken. Zum empfangen wäre sowas wie die PIO im RP2040 praktisch. Oder was mittels timer Input Capture basteln.

Schau mal beim ESP das RMT Peripheral an. Das ist ziemlich universell was Custom Bitschubsereien angeht. Manchester müsste man damit auch ziemlich leicht hinbekommen. Eigentlich ist das für IR gedacht. Kann auch modulieren/demodulieren. Ich meine aber dass das auch deutlich schneller kann. Bin mir aber nicht mehr sicher wie schnell genau.

Ich werde die architektur etwas anpassen und immer 8 Galvanisch getrennte messungen auf ein Board mit gemeinsamer Spannungsversorgung packen. Trennung über opto oder Trafo.

Nach außen funkt dann ein gemeinsamer BLE- oder Zigbee-Chip.

Falls trafos zum einsatz kommen, würde ich die Parameter nutzen wie sie für das USB-PD protokoll standartisiert sind: 4b5b, Differential Manchester, 300kHz +-10% Dafür gibt es auch einige chips die das in hardware können sowie Prozessoren mit entsprechenden Peripherals (nennt sich UCPD bei ST) als auch Software-Referenzimplementierungen.