Hi
ich wollte zwischen 2 Arduino boards mit einem jitter unter 500us 3 bytes hin und her schicken.
Das ist weder mit BLE noch WLAN möglich. ESP-NOW hat CSMA und geht auch nicht.
Eine idee?
Schau mal bei LoRa aber nicht LoRaWAN.
Woher kommt denn diese Anforderung? Was hast du vor?
Vor allem, was machst du, wenn die von dir ausgewählte Frequenz gerade belegt ist?
Prinzipiell kann man natürlich ein Datenpaket erstmal mit "fire & forget" abschießen – und dann hoffen, dass die andere Seite es empfängt. Ich habe einige Jahre mit IEEE 802.15.4 beruflich zu tun gehabt, man könnte dort alle Einstellungen so vornehmen, dass eben kein CSMA/CA erst gemacht wird, und ACK/retry verbietet sich bei den Jitter-Anforderung ohnehin, denn jeder Retry erzeugt Jitter.
Wenn der Kanal aber gerade belegt ist, dann kommt eben das Paket einfach gar nicht an. Hat dann immer noch null Jitter. :-)
ich möchte 2 geräte synchroniseren. Ich habe meherer Boards die mit einer Samplingrate von 1000 Hz per ADC irgendwelche Messwerte aufnehmen. Jeder sample hat einen timestamp. Ich muss meine Boards synchronsieren damit die Zeitstempel und die ADC werte von den verschiedenen Boards eine synchronisation mit max 500 us (besser 100) jitter aufweisen.
Ich habe schon ein BLE chip wo ich den RF manuell programmiere. Das Projekt ist aber veraltet und sehr kompliziert. So ein BLE chip selber zu programmieren (komplett vorbei an BLE stack) ist nicht ganz ohne.
Embedded bards wireless mit einander zu syncen sollte doch ein verbreitetes Problem sein. Ich konnte mir vorstellen dass gerade in Robotik oder Fernsteuerung wo es auf geringe Latenzen (geringer als WLAN oder BLE) sowas existieren musste
Vor allem, was machst du, wenn die von dir ausgewählte Frequenz gerade belegt ist? redundanz: ich schicke einfach immer wieder. Das aktuelle System läuft auch gerade gut. Nur dass ich es erweitern muss, und es zu aufwendig ist mit mein Wissen einen BLE chip selber zu programmieren.
Ich habe schon ein BLE chip wo ich den RF manuell programmiere
Aus Interesse, welcher IC ist das bei dem das so geht?
Das Problem hatten wir gerade erst: Beitrag "Drahtlose Kommunikation mit NUCLEO-H723ZG"
...sollte doch ein verbreitetes Problem sein
Dafür wird in der Regel "NTP" eingesetzt:
NTP bringt da nix. A: Es gibt dir nur den statistischen Mittel an B. FÜR NTP brauchst du ja erst mal einen Protokol mit der du die TIME Stamps austauschst. Setzt du auf TCP/IP , hast du eine genauigkeit von gerade mal 1ms. Setzt man auf BLE, ist man an connection interval von BLE gebunden.
Das ESP32-IDF bringt doch PTP (IEEE-1588) mit... Allerdings, soweit ich gesehen habe, geht das Hardware-Timestamping nur per Ethernet, nicht WLan.
Damit kriegen die zwei ESP32 auf 60ns synchronisiert, das wäre schonmal ~4 Größenordnungen besser als deine Anforderung. Ob und wie genau das über WLan geht, wäre ja leicht auszuprobieren.
Wenn du einen LoRa (nicht LoRaWan) Sender hinstellst der z.B. alle 10s die Zeit sendet (plus Prüfsumme zur Plausibilisierung), können mehrere Empfänger die "grobe" Zeit aus dem Dateninhalt entnehmen, und die "genaue" Zeit an der Flanke des Interrupt-Pins vom LoRa-Modul festmachen. Die Modulationsparameter können so gewählt werden, dass eine hohe Bandbreite (also kleine Bitzeit) verwendet wird, und mit 27kBit (laut https://en.wikipedia.org/wiki/LoRa) wären die gewünschten 100µs locker erreichbar. Wenn das Paket nicht ankommt, müssen die Empfänger stabil genug sein, autark die Zeit zu zählen, und beim nächsten korrekt empfangenen Paket kann das wieder synchronisiert werden.
ich wollte zwischen 2 Arduino boards mit einem jitter unter 500us
Jitter unter 500µs ist doch Kindergarten. Muss es denn irgendein schweres Protokoll wie BLE oder WLAN sein?
Eine idee?
Nutze eine gemeinsame, frei verfügbare Zeitbasis und verpasse jedem deiner Arduinos einen eigenen Empfänger. Dann braucht du keine Frequenzen oder Time Slots mit LoRa, BLE oder sonstwas zu belegen, auch wenn Broadcast dir vielleicht zu old School ist. Man braucht nicht für jeden Mist einen eigenen Funkkanal.
Mit dem 1PPS Signal eines GNSS-Empfängers lägest du unter 100ns. Das wäre dann einen Faktor 5000 genauer als gefordert - aber was soll's.
Wie wackelig ist denn das Timing von deinen Arduinos, d.h. wie oft musst du neu synchronisieren?
Mit dem 1PPS Signal eines GNSS-Empfängers lägest du unter 100ns.
Brauchst aber freie Sicht zumindest auf einen Teil des Himmels.
… außerdem nicht ganz wenig Energie.
… außerdem nicht ganz wenig Energie.
Moderne GPS Empfänger sind extrem sparsam, brauchen nicht mehr als ein LoRa oder BLE Empfänger aber um Größenordnungen weniger als WiFi.
Nordic NRF serie
Sind da die Peripherie Register für die RF Peripherie dokumentiert? So wie bei anderen (Nicht-BLE) Funk-Mikrocontrollern?
Wie weit sind denn die beiden zu synchronisierenden Arduinos von einander entfernt? Gibts keine anderen Möglichkeiten einer Signalübermittlung? Mir fallen da so ein:
-
Magnet-Impuls mit größerer Spule? Früher gab es mal Modellfernsteuerungen per Induktionsschleife, die reichte einige Meter weit
-
Infrarot-"Blitze"? (per LED oder indirekt mit 1mW-Laser an die Decke/Wand)
-
notfalls Kabel, auch LWL
-
Piraten-Funk (sofern kein offizielles bzw. kommerzielles Projekt) auf irgend einer freien Wellenlänge, z.B. 455kHz oder 10,7MHz (Radio-ZF), das dürfte kaum bemerkt oder überwacht werden.
-
Snchronisation auf GPS-Signal (nur theoretisch angedacht, sollte aber grundsätzlich genau genug sein. Problem ist wahrscheinlich die Signalausgabe aus dem Empfängerchip per UART?)
- Snchronisation auf GPS-Signal (nur theoretisch angedacht, sollte aber grundsätzlich genau genug sein. Problem ist wahrscheinlich die Signalausgabe aus dem Empfängerchip per UART?)
Wenn man über ein GPS-Signal eine Zeitsynchronisation im Bereich von 0.5ms machen möchte, verwendet man dafür das 1PPS-Signal. Das serielle Signal vom UART wird evtl. nur gebraut, um die Mehrdeutigkeit aufzuheben.
Antwort schreiben
Bitte melde dich an, um einen Beitrag zu schreiben.