Forum: HF, Funk und Felder Daten übertragung in ISM band mit wenig jitter delay


von Mat. K. (matthias_kornfield)


Lesenswert?

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?

: Verschoben durch Moderator
von Obelix X. (obelix)


Lesenswert?

Schau mal bei LoRa aber nicht LoRaWAN.

: Bearbeitet durch User
von Sebastian R. (sebastian_r569)


Lesenswert?

Woher kommt denn diese Anforderung? Was hast du vor?

von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

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. :-)

von Mat. K. (matthias_kornfield)


Lesenswert?

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

: Bearbeitet durch User
von Mat. K. (matthias_kornfield)


Lesenswert?

>> 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.

von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Mat. K. schrieb:
> 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"

: Bearbeitet durch User
von Irgend W. (Firma: egal) (irgendwer)


Lesenswert?

Mat. K. schrieb:
> ...sollte doch ein verbreitetes Problem sein

Dafür wird in der Regel "NTP" eingesetzt:
- https://de.wikipedia.org/wiki/Network_Time_Protocol

von Mat. K. (matthias_kornfield)


Lesenswert?

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.

: Bearbeitet durch User
von Εrnst B. (ernst)


Lesenswert?

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.

von Uwe (uhi)


Lesenswert?

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.

von David S. (ds2000)


Lesenswert?

Mat. K. schrieb:
> 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?

von Rainer W. (rawi)


Lesenswert?

Mat. K. schrieb:
> 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?

: Bearbeitet durch User
von Jörg W. (dl8dtl) (Moderator) Benutzerseite


Lesenswert?

Rainer W. schrieb:
> 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.

: Bearbeitet durch Moderator
von Niklas G. (erlkoenig) Benutzerseite


Lesenswert?

Jörg W. schrieb:
> … 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.

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
Noch kein Account? Hier anmelden.