mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Funk Modul Arduino - mit kollision Management - wenig Daten - 50m sicher?


Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, das mache ich:
Ich baue eine Duell-Schießanlage für Airsoft:
10x Targets mit Arduino, ADXL345 & Funk -zu-> Arduino mit LCD & Buzzer

Duell heisst 2 Leute versuchen jeweils als erstes 5 Targets zu treffen.
Die Zeit wird gemessen von Start bis Ende. Es werden 2 Byte auf bis zu 
25m (von der Rückseite - sicher auch bei Stahlzielen) übertragen.

Das ist mein Problem:
Bei dem Versuch mit dem 433Mhz HC-12 (SI4463) habe ich bei dem Fall das 
beide Spieler gleichzeitig treffen manchmal nur einen Auslöser oder gar 
keinen. Das passiert in ca. jedem 2ten Match und macht das ganze Kacke.

Ich habe versucht vor dem Senden die serielle zu checken klappt aber 
nicht zuverlässig (denke das das HC-12 zu viel Versatz hat). Überlege 
jetzt ein Bestätigungsystem - habe Angst vor Latenz für die Zeitanzeige.

Hast Du einen Tipp für ein passendes Funkmodul?
- 11 Teilnehmer
- 50 Meter in einem Raum (aber auch hinter einer Metallplatte)
- Kollisionssicher
- nicht Lizenzpflichtig (Bluetooth)

Autor: Christian S. (roehrenvorheizer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

warum fiel ursprünglich Deine Wahl auf das HC12? Dies ist über 
AT-Befehle ansprechbar wie ein klassisches Modem.

Es dürfte jedes Funkmodul mit SPI-Bus schneller auszuwerten und wieder 
auf Empfang zu stellen sein. Bustakt < 10 MHz.

RFM23 und RFM69 fallen mir da als erstes ein. Zwei gleichzeitige 
Sendesignale können sie allerdings nicht verarbeiten.

Guten Gutsch morgen!

: Bearbeitet durch User
Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank schrieb:
> Ich baue eine Duell-Schießanlage für Airsoft:

Darf ich fragen wo ihr spielt?

Bei uns in BW gibts nicht gerade viel Möglichkeit dies zu machen!

Frank schrieb:
> Duell heisst 2 Leute versuchen jeweils als erstes 5 Targets zu treffen.
> Die Zeit wird gemessen von Start bis Ende. Es werden 2 Byte auf bis zu
> 25m (von der Rückseite - sicher auch bei Stahlzielen) übertragen.

Schau dir mal die ESP8266-Module an. Die machen WLAN. ESP32 kann 
zusätzlich noch Bluetooth.

Wir haben uns mit den ESP8266 einen T-UGS (bzw UGS laut Wikipedia) 
gebaut.

Frank schrieb:
> Bei dem Versuch mit dem 433Mhz HC-12 (SI4463) habe ich bei dem Fall das
> beide Spieler gleichzeitig treffen manchmal nur einen Auslöser oder gar
> keinen.


Die Latenz ist schon ein Problem.

Die 433MHz-Module stören sich gegenseitig. Deshalb hast du das Problem.

Beim ESP müsstest du aber eine gemeinsame Zeitbasis setzen und dann beim 
Matchende vergleichen. dann wäre es egal wann die Pakete ankommen, 
solange die Zeit im Paket mitübertragen wird und bei allen Sensoren 
gleich ist.

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Vorschläge!

Christian S. schrieb:
> warum fiel ursprünglich Deine Wahl auf das HC12? Dies ist über
> AT-Befehle ansprechbar wie ein klassisches Modem.

Habe ein anderes Projekt, lagen noch 10 Stück rum. Aber die taugen nicht 
für mehrere Sensoren.

RFM69HCW liegen grad im Warenkorb wenn ich das richtg verstehe kucken 
selbst ob der carrier frei ist bevor die senden. Dieses Pakete senden an 
eine Anschrift kommt mir entgegen, das ignorieren für die anderen 
Sensoren auch. Für Arduino gibt es viele Beispiele, Reichweite soll 
super sein.


Alex W. schrieb:
> Darf ich fragen wo ihr spielt?
> Bei uns in BW gibts nicht gerade viel Möglichkeit dies zu machen!
Im Keller, aber nur auf Ziele ;) Frankreich soll schön sein hab ich 
gehört...

> Schau dir mal die ESP8266-Module an. Die machen WLAN. ESP32 kann
> zusätzlich noch Bluetooth.
Ich versuche es mal zusätzlich zu den RFM69 mit NRF24L01 "Auto ACK & 
retransmit" hat mich mehr angemacht als die Lösungen für die ESP8266.

> Beim ESP müsstest du aber eine gemeinsame Zeitbasis setzen und dann beim
> Matchende vergleichen. dann wäre es egal wann die Pakete ankommen,
> solange die Zeit im Paket mitübertragen wird und bei allen Sensoren
> gleich ist.
Das geht nicht, ich will gleich die Treffer übertragen wie im Biathlon 
im Fernsehen ;)

Autor: Christian S. (roehrenvorheizer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
" wenn ich das richtg verstehe kucken selbst ob der carrier frei ist 
bevor die senden"

Nein, nur wenn das Programm diesen Vorgang entsprechend steuert, z.B. 
über RSSI.

MfG

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank schrieb:
> NRF24L01

Im Prinzip ja, aber ohne Vernetzung kann der nur 6 Module. Du kannst 
natürlich an einen Arduino oder Raspi zwei empfangende Module hängen.

Mit Vernetzung kann der viele Module, aber da muss man das Netz schlau 
aufbauen, damit der Ausfall eines Knotens nicht stört.

Alex W. schrieb:
> ESP8266-Module an. Die machen WLAN.

Auf 50m? Bei bewegten Objekten?

Autor: Mike J. (linuxmint_user)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank schrieb:
>> solange die Zeit im Paket mitübertragen wird und bei allen Sensoren
>> gleich ist.
> Das geht nicht, ich will gleich die Treffer übertragen wie im Biathlon
> im Fernsehen ;)

Du kannst doch die Zeit (4Byte) mit übertragen, wenn es dann ein paar 
Millisekunden dauert bis die Daten übertragen worden sind, dann ist das 
nicht schlimm.

Die nRF24L01+ (hier die Module mit PA nehmen) können auch auf anderen 
Frequenzen senden, also alles von 2,4GHz bis 2,528GHz. Sende doch 
einfach auf verschiedenen Frequenzen und nutze entsprechend mehrere 
Empfänger welche auf die entsprechende Frequenz eingestellt worden sind.

Kannst du deine SI4463 nicht einfach auf eine etwas andere Frequenz 
setzen um die Kollision der Daten zu verhindern?

Autor: Beo Bachta (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Karl K. schrieb:
> Im Prinzip ja, aber ohne Vernetzung kann der nur 6 Module. Du kannst
> natürlich an einen Arduino oder Raspi zwei empfangende Module hängen.

Völliger Käse.

Der NRF24 kann

a) eine individuelle 6-Byte_Adresse schicken und damit
sehr viele Kommunikationspartner einzeln ansprechen.

b) auf eine von 128 Frequenzen im Band von 2.400 bis 2.527 GHz
senden ohne die Nachbarn zu stören (in der Praxis vielleicht
etwas weniger). Damit sind also 128 Kanäle gleichzeitig und
paralell nutzbar.

c) unabhängig von TCP Protokollen seine Pakete sehr schnell
und sicher übertragen (keine Latenz wie im LAN/WLAN).

Autor: Beo Bachta (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Beo Bachta schrieb:
> c) unabhängig von TCP Protokollen seine Pakete sehr schnell
> und sicher übertragen (keine Latenz wie im LAN/WLAN).

Nachtrag:

Beim NRF24 ist ein volles 32-Byte Datenpaket ist innerhalb
maximal einer Millisekunde übertragen, inklusive Fehler-
überprüfung und ACK.

Ich behaupte mal dass dies mit jeglicher Art von Übertragung
über LAN/WLAN niemals zuschaffen ist da die diversen Stacks
jede Menge Overhead und Latenzzeiten mit sich bringen.

Auch die diversen 433 MHz "Fertig"Module werden das nie schaffen
solange sie über über Terminal-I/O angesteuert werden.

Beitrag "Re: NRF24L01+ test program for Arduino Uno"

Autor: Frank (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Beo Bachta schrieb:
> Der NRF24 kann

> a) eine individuelle 6-Byte_Adresse schicken und damit
> sehr viele Kommunikationspartner einzeln ansprechen.

> c) unabhängig von TCP Protokollen seine Pakete sehr schnell
> und sicher übertragen (keine Latenz wie im LAN/WLAN).

Und er ist gar nicht so teuer mit SMA Antenne ;)

Ich denke das wird es...

Autor: Beo Bachta (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Frank schrieb:
> Ich denke das wird es...

.... und berichte  bitte  später nicht  du hättest die
zusätzlichen Abblock-Massnahmen (Kondensatoren) weggelassen
weil es die ja nicht braucht!

Autor: Karl K. (karl2go)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
Beo Bachta schrieb:
> a) eine individuelle 6-Byte_Adresse schicken und damit
> sehr viele Kommunikationspartner einzeln ansprechen.

Er will aber nicht an viele Partner schicken, sondern von vielen 
Partnern empfangen, Du Depp.

Und da kann ein nRF24 nur einen Kanal und auf diesem 6 Geräte 
adressieren. Nur von Sendern auf diesem Kanal mit diesen Adressen 
empfängt er Daten.

Natürlich kann man Kanal und Adressen wechseln. Aber dann verpasst man 
die Telegramme der Sender, die gerade nicht auf diesem Kanal und dieser 
Adresse senden.

=> Ein Empfänger kann nur 6 Sender empfangen. Für mehr Sender muss man 
entweder mehrere Empfänger nehmen, oder ein Netzwerk aufbauen, wo Knoten 
solange selbst Empfänger von 6 Sendern sind, bis sie was empfangen und 
mit eigener Adresse weitergeben, oder selbst was zu senden haben.

Autor: Jim M. (turboj)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank schrieb:
> - Kollisionssicher

Kollisionen werden sich kaum vermeiden lassen. Besser man schickt einen 
Timestamp mit - den muss man dann aber irgendwie synchronisieren können.

Beo Bachta schrieb:
> Ich behaupte mal dass dies mit jeglicher Art von Übertragung
> über LAN/WLAN niemals zuschaffen

Gigabit LAN hat Ping Zeiten von deutlich unter 1ms. WLAN - siehe oben.

Autor: Karl K. (karl2go)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Jim M. schrieb:
> Kollisionen werden sich kaum vermeiden lassen.

Kollisionen handhaben die nrf24 dadurch, dass sie bis zu 16mal 
wiederholt senden, wenn sie kein Ackn vom Empfänger erhalten. Das läuft 
bei richtiger Einstellung automatisch ab.

Autor: Gerhard O. (gerhard_)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Im Circuit Cellar war mal ein Artikel über ein Großmausefallensystem mit 
bis zu 20 Fallen. Dort wurden auch ähnlich funktionierende Radiomodule 
verwendet.

Um das Problem der gegenseitigen Störung bei gleicher Sendezeit von mehr 
als einem Sender abzuschwächen, programmierte er die Mausefallensender 
so, daß die Packets mindestens viermal ausgesendet wurden. Der Zeit 
Intervall zwischen den Packets wurde durch die Adresse des Moduls 
abhängig gemacht. Die Empfänger soft Modem Software war so programmiert, 
daß jeweils zwei Packets intakt ankommen mussten. Angeblich soll das so 
wie vorgesehen funktioniert haben.

Auch wenn nun zwei Module zur exakt gleichen Zeit anfangen zu senden 
sind die Pausen unterschiedlich genug um sich gegenseitig minimal zu 
stören und es wahrscheinlich ist, daß mindestens zwei der Packets nicht 
gestört werden.

Der Artikel ist irgendwo im Forum verlinkt. Der Original Code lief auf 
einem Hc908.

http://faculty.petra.ac.id/resmana/private/circuit-cellar/Wireless%20Monitoring%20System.pdf

: Bearbeitet durch User
Autor: Beo Bachta (Gast)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Karl K. schrieb:
> => Ein Empfänger kann nur 6 Sender empfangen.

Ein Empfänger kann soviele Sender empfangen wie Sender-Codierungen
(Adressen) in ein Datenpaket hinein passen. Dazu braucht es nicht
mehr als eine (NRF24-)Adresse. Kollisionen werden durch das
implizite Protokoll des NRF24 gehandled, weitere (höherwertige,
längerdauernde Kollisionen) kann der Sender selbst intelligent
behandeln.

Autor: Karl K. (karl2go)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Beo Bachta schrieb:
> Dazu braucht es nicht
> mehr als eine (NRF24-)Adresse. Kollisionen werden durch das
> implizite Protokoll des NRF24 gehandled

Nee, das kannste knicken. Dann funktioniert kein Ackn und kein 
Retransmit mehr.

Autor: Frank (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Karl K. schrieb:
> Beo Bachta schrieb:
>> Dazu braucht es nicht
>> mehr als eine (NRF24-)Adresse. Kollisionen werden durch das
>> implizite Protokoll des NRF24 gehandled
>
> Nee, das kannste knicken. Dann funktioniert kein Ackn und kein
> Retransmit mehr.

also erstmal Danke für die Vorschläge, ich habe mich bis auf das „Du 
Depp“ von Karl K. sehr gefreut über die Beiträge.

Es gibt einen Workaround für die 6er Beschränkung:
If you configure two nodes with the same identifier they will be 
considered as one and their clicks will not be distinguished. You can 
leverage this in some situations and have two sensors appear as one, if 
that’s what you want.

Da der nicht einzigartige Sender das Ack erwartet wird der stille 
Zwilling vom Sender nicht auf die Bestätigung reagieren. Die 
Unterscheidung der Sender nehme ich dann im Payload vor - die bekommen 
so ein Mäuseklavier.
Sollte das wiedererwarten nicht gehen, ich habe 2x5 Ziele, bei dem Preis 
kann ich auch 2 Empfänger am Mega einsetzen... und die könnte man noch 
bequem einige Kanäle getrennt setzen.

Die Funkmodule kommen bis Montag werde nächste woche die Ergebnisse 
posten.

Autor: Frank (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Nachtrag zu den reading Pipes:

Stellt euch vor ihr habt 6 Briefkästen in 2 davon (0,1) könnt ihr nur 
von einem eindeutigen Sender empfangen. Bleiben noch 4 Briefkästen in in 
die kommen nur Briefe von bestimmten Postleitzahlen Gebieten an. Also 
z.B. alle Sender aus Stuttgart kommen in Briefkästen nr 3.

Genau gesagt werden bei den Pipes 2,3,4,5 von 40 bits die oberen 32 bits 
gesperrt - aber das untere Byte ist offen. Werden die 32 oder 24 bit 
limiter gesetzt, bleibt das untere byte dennoch variabel.

Damit sind wir bei 4x255 + 2 empfangbaren Sendern mit allen Vorzügen in 
der Datenübertragung.

Ist ein wenig wie die Netzwerkmaske 255.255.255.0 bei mir zuhause.

Also wenn ich das jedenfalls richtig gerafft habe :)

Autor: Karl K. (karl2go)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Frank schrieb:
> ich habe mich bis auf das „Du
> Depp“ von Karl K. sehr gefreut über die Beiträge.

Angenehm, ich hab mich über das "völliger Käse" von dem Dummschwätzer 
auch gefreut. Wald => rufen.

Autor: Karl K. (karl2go)
Datum:

Bewertung
-2 lesenswert
nicht lesenswert
Frank schrieb:
> Da der nicht einzigartige Sender das Ack erwartet wird der stille
> Zwilling vom Sender nicht auf die Bestätigung reagieren.

Und hast dann Ausfälle, wenn beide gleichzeitig senden wollen. Dann 
bekommt nämlich doch der zweite das Ack, was eigentlich für den ersten 
ist, und sendet sein Retransmit nicht, seine Daten gehen verloren.

Anhand der Anzahl der Treffer pro Zeiteinheit, Anzahl der Sender und 
Dauer der Übertragung (Datenlänge x Wartezeit x max. Anzahl Retransmits) 
kannst Du die Kollisionswahrscheinlichkeit abschätzen.

Frank schrieb:
> bei dem Preis
> kann ich auch 2 Empfänger am Mega einsetzen... und die könnte man noch
> bequem einige Kanäle getrennt setzen.

Das wäre die saubere Lösung.

Frank schrieb:
> Also wenn ich das jedenfalls richtig gerafft habe :)

Nein, hast Du nicht. Du kannst die Bytes nicht variabel halten. Es 
werden nur die eingetragenen Adressen empfangen, und wenn Du das Byte 
veränderst, ändert sich die Adresse. Kann man machen, aber dann geht 
halt alles flöten, was gerade nicht mit der Adresse sendet.

Das wird gemacht, wenn man nach sendenden nRF24 scannt. Aber dann gehen 
halt Übertragungen verloren.

Autor: Christian S. (roehrenvorheizer)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
"Damit sind wir bei 4x255 + 2 empfangbaren Sendern mit allen Vorzügen in 
der Datenübertragung."

Ja, schön, das ist wie bei den RFM70 anscheinend.
A_BÄR: Es ist nicht gemeint, daß mehr als ein Sender gleichzeitig 
empfangen werden kann, auch nicht mit den Pipes. Deshalb wäre es 
schlauer, mehrere Empfänger am Bus vorzuhalten, die auf 
unterschiedlichen Frequenzen lauschen. Aus diesen dann die 
Statusregister lesen zur Auswertung.

"Die Funkmodule kommen bis Montag werde nächste woche die Ergebnisse 
posten."

Wohl demjenigen, der dies so schnell programmiert und aufgebaut 
bekommt...

mfG

: Bearbeitet durch User
Autor: Alex W. (a20q90)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Frank schrieb:
>> Beim ESP müsstest du aber eine gemeinsame Zeitbasis setzen und dann beim
>> Matchende vergleichen. dann wäre es egal wann die Pakete ankommen,
>> solange die Zeit im Paket mitübertragen wird und bei allen Sensoren
>> gleich ist.
> Das geht nicht, ich will gleich die Treffer übertragen wie im Biathlon
> im Fernsehen ;)

Du hast mich falsch verstanden! Du wirst nicht mitbekommen ob das Paket 
10ms oder 200ms braucht bis es am Empfänger ankommt. Du musst nur dafür 
sorgen dass alle ESP eine gemeinsame Zeitreferenz haben (wie beim 
NTP-Protokoll).

Sobald ein Treffer gesendet wird, spielt es keine Rolle ob das Paket 
früher oder später eintritt, denn die Zeit im Paket ist entscheidend. 
Durch TCP hast du auch noch Verbindungssicherheit. Selbst wenn ein 
2,4GHz-Jammer an wäre, sobald der aus ist, kommen die Daten an und 
können angezeigt werden.

: Bearbeitet durch User
Autor: Frank (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, NRF24:

Kondensator:
Der Kondensator sollte 100uF sein, 10uF war zu wenig ;)
War schon am verzweifeln 3 Tage wegen Instabilität.
Noch welche zusätzlich zu den 100uF dazumachen?

5er Stern:
Ich werde 2 Sterne mit 5 Sendern auf unterschiedlichen Kanälen aufbauen.
Mit der Scanfunktion kann man sehr gut sehen welche Frequenzen wenig 
genutzt werden.

Energieversorgung:
Versorgen werde ich mit LiPo (Handyakku + Ladeplatine mit 
Tiefentladeschutz).
Wenn Sich die Entladung auf den 3,3V auswirkt -> sendet das Gerät:
"bitte fütter mich"

DANKE:
Vielen Dank für die Hilfe und nicht so ausgeartete Diskussion ;)

Grüße, Frank

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank schrieb:
> Der Kondensator sollte 100uF sein, 10uF war zu wenig

10µ als 0805er Keramik direkt zwischen die Pins gelötet reicht 
eigentlich aus. Vielleicht sind Deine Elkos zu schlecht.

Autor: Beo Bachta (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Frank schrieb:
> Der Kondensator sollte 100uF sein, 10uF war zu wenig ;)

Karl K. schrieb:
> 10µ als 0805er Keramik direkt zwischen die Pins gelötet reicht
> eigentlich aus.

Tja es ist ein grosser Unterschied ob 10uF Keramik oder 10uF Elko.
Elkos alleine sind viel zu träge für HF. Auch grosse Kermik-Cs
sind schlechter als kleine.

Die "Wahrheit" liegt dazwischen (aus meinen bescheidenen
Erfahrungen):

Kleiner Keramik Kondensator (1 uF) für die HF-Entstörung plus
grosser Elko (10..100uF) für die Pufferung der schwankenden
Stromaufnahme. Dabei ist der grosse Elko üblicherweise bei
Batteriebetrieb sehr von Vorteil wegen der "Weichheit" (Innen-
widerstand) der Batterie.

Autor: Karl K. (karl2go)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beo Bachta schrieb:
> grosser Elko (10..100uF) für die Pufferung der schwankenden
> Stromaufnahme.

Den der Arduino eh drauf hat. Oder haben sollte.

Autor: Beo Bachta (Gast)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
Karl K. schrieb:
> Den der Arduino eh drauf hat. Oder haben sollte.

Na klar! Du weisst es.

Du hast auch schon mehr Erfahrung mit den NRF24 als alle
anderen hier im Forum zusammen.

Daher auch die grosskotzige Ausdrucksweise.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.