Ich möchte einen Raspberry Pi mit einem tragbaren ARM-MCU-basierten Gerät verbinden, das ein Display und einige Tasten enthält, um Informationen vom Pi anzuzeigen und Befehle zu übertragen. Ich möchte dafür nrf24l01 + 2,4-GHz-Transceiver verwenden.
Ich denke darüber nach, wie ich die Kommunikationsverbindung einrichten soll und insbesondere, ob ich Enhanced Shock Burst (ESB) verwenden soll oder nicht. ESB ist sehr praktisch, da es Auto-Ack unterstützt und mich daher von der manuellen Ack-Verwaltung befreien könnte, die insbesondere auf dem MCU-basierten Gerät mühsam ist. Soweit ich die Datenblätter verstanden habe, erfordert ESB jedoch, dass ein Gerät ein primärer Empfänger und ein Gerät ein primärer Sender ist, und nur letzteres initiiert eine neue Übertragung, obwohl ersteres Daten in seiner Antwort übertragen kann. In meinem Fall ist dies problematisch, da beide Geräte externe Ereignisse erhalten, die die Notwendigkeit einer Datenübertragung auslösen.
Ich habe mich eingelesen und es gibt im Grunde drei mögliche Lösungen für dieses Problem:
Konfigurieren Sie ein Gerät als PTX und eines als PRX und lassen Sie den PTX leere Nachrichten senden, um dem PRX die Möglichkeit zu geben, seine Daten in einem Antwortpaket zu senden. Dies scheint bei einigen Projekten der Fall zu sein. Ich sehe den Nachteil des ständigen Verkehrs in der Luft, was schlecht für batteriebetriebene Geräte ist. Außerdem benötigt der PRX noch etwas Puffer, um die Nachrichten zu speichern, bis eine Übertragung eintrifft und die Nachricht in der Bestätigung gesendet werden kann.
Konfigurieren Sie beide Geräte als PRX. Wenn ein Gerät eine Nachricht übertragen muss, wechselt es zur PTX-Rolle und überträgt die Nachricht. Der Vorteil ist, dass kein Dauerverkehr in der Luft ist und beide Geräte die Nachrichten nach Bedarf übertragen können. Allerdings habe ich nirgendwo festgestellt, dass das so gemacht wird. Ich frage mich also, ob dies möglich ist oder ob es andere Einschränkungen bei dieser Lösung gibt?
Verzichten Sie auf Enhanced Shock Burst und erstellen Sie ein eigenes Protokoll. Die am wenigsten bevorzugte Lösung, da sie mehr Arbeit erfordert und die Steuerung stärker belastet. Die automatische Retransmit-Funktion klingt sehr gut und es wäre schade, dieses Potenzial ungenutzt zu lassen.
Deshalb frage ich mich, ob jemand dieses Problem schon hatte und wie Sie es gelöst haben. Ich würde besonders gerne wissen, ob es Probleme mit Möglichkeit zwei gibt.
Die zweite Option ist eigentlich sehr verbreitet. Im Wesentlichen können PRX und PTX auf einer Pro-Übertragungs-Basis sein. Beide sollten sich die meiste Zeit im RX-Modus befinden, und wenn Sie etwas übertragen müssen, sehen Sie sich zuerst das Statusbit an, das Ihnen sagt, ob auf Ihrem Kanal ein Signal vorhanden ist oder nicht. Wenn dies nicht der Fall ist, legen Sie die Sendeadresse und Ihre Ack-Adresse fest und schießen los. Wenn dies der Fall ist, gehen Sie zurück in den RX-Modus und haben Sie eine Zeitüberschreitung.
Ihre erste Option scheint, als würden Sie ein Beaconing-Netzwerkprotokoll beschreiben. Wie Sie bemerkt haben, hat dies den Nachteil eines kontinuierlichen Datenverkehrs und eines höheren Stromverbrauchs. Es ist jedoch wirklich die einzige Möglichkeit, die Kommunikation zu gewährleisten, wenn etwas zeitkritisch ist.
Ihre erste Option erlaubt dem Master, den Zugang zum Äther zu kontrollieren – Slaves senden nur, wenn sie vom Master dazu angewiesen werden. Dies kann in Situationen mit hoher Auslastung gut sein, um Kollisionen zu vermeiden, aber es erfordert, dass die Slaves eingeschaltet bleiben, zumindest wenn sie etwas haben, das darauf wartet, an den Master gesendet zu werden, und es erfordert, dass der Master "oft genug" abfragt.
(Ich gehe davon aus, dass Sie mit "Antwortpaket" wahrscheinlich ein ACK-Paket mit Nutzlast meinen, obwohl die gleiche oben beschriebene Dynamik implementiert werden kann, wenn der Slave kurz nach Aufforderung durch den Master manuell kurz in den PTX-Modus wechselt, um das Antwortpaket zu senden.) .
Bei einigen Sensornetzen, bei denen Übertragungen weniger häufig sind, ist es sinnvoll, eher etwas wie Ihre zweite Option zu verwenden. Listen-before-send ist aus mehreren Gründen nicht 100% zuverlässig, daher kann es zu Kollisionen kommen, aber bei geringem Datenverkehr können diese ungewöhnlich genug sein, um akzeptabel zu sein, und manchmal sind Sensormesswerte nicht kritisch (wenn Sie die Temperatur alle 5 Minuten senden, ist dies der Fall normalerweise nicht kritisch, um ein paar Updates zu verpassen).
Die Hauptoptionen unterteilen sich also in die Optionen "master timed" und "asynchronous send" (Ihr "eigenes Protokoll" als dritte Option müsste sich ebenfalls für eine dieser Optionen entscheiden). Und jeder hat seine Nische. In einem Design, in dem der Master viele Daten sendet (zur Steuerung der Weihnachtsbeleuchtung), verwende ich ersteres und lasse den Master nach Belieben Daten von den Slaves abrufen. In einem Sensornetzwerk denke ich daran, die zweite Dynamik zu verwenden, um den Sensor-Slave-Knoten die meiste Zeit zu ermöglichen, zu schlafen.
Erik Kaplun