Hallo, ich habe schon seit knapp 2 Jahren diese Dinger im Einsatz bei einer selbstgebastelten Wetterstation aber wie ich mich grad wieder reinarbeite und neue Hardware baue fällt mir auf, dass diese billigen Dinger mit der Ätzantenne auch mehr oder weniger zufällig mal was empfangen. Der ACk für Shockburst Übertragung mit dyn. Payload kommt dann öfter mal nicht an die Basisstation, je nachdem wie die Platine im Raum gedreht ist, ob man die Hand über die CPU hält (EMV?) oder nicht. Da tickert ein STM32F103 mit 72 Mhz in der Nähe, keine 4cm weiter weg. Jetzt habe ich in der Bucht die hier gefunden, sicherlich auch China Klone. Die Original Nordic Steine liegen ja bei ca 8 Euro nur der Chip. http://www.ebay.de/itm/2-x-NRF24L01-PA-LNA-SMA-Antenne-Transceiver-Modul-2-4G-Antenna-Long-Range-/252713959128?hash=item3ad6ecfed8:g:Aj0AAOSwTglYl0hr Sind die besser und zuverlässiger als diese mit der Ätzantenne? Und da ist da noch die Sache mit der 5 Byte Adressierung. Ich habe soweit festgestellt, dass man nicht jede Byte Kombination nehmen darf. Hatte erst meine Telefonnummer genommen. Lief nicht. Bei einigen gibt es jede Menge Datenmüll. Gibt es da Regeln welche gut laufen?
Man soll möglichst viele Flankenwechsel haben. Bei den Adressen geht das ja noch, bei den Nutzdaten wird es wohl schwierig...
Christian J. schrieb: > ... fällt mir auf, dass diese billigen Dinger mit der Ätzantenne auch > mehr oder weniger zufällig mal was empfangen. Das nennt sich Funk und hat was mit dem Rauschen der Welt zu tun. Es ist eine reine Frage der Statistik, wie oft ein empfangenes Rauschen/Störungen einem echten Signal so ähnlich ist, dass der Empfänger es bis zum Ausgang durchprozessiert. Das nennt sich Fehlerwahrscheinlichkeit. Du musst deine Daten inklusive Prüfsummen so gestalten, dass die Wahrscheinlichkeit für solche Fehler so gering wird, wie es für deine Anwendung nötig ist. Du könntest beispielsweise in deinem Protokoll festlegen, dass die Daten innerhalb eines Zeitfensters zwei mal richtig empfangen werden müssen, damit sie als gültig gewertet werden.
Lutz schrieb: > Man soll möglichst viele Flankenwechsel haben. Bei den Adressen geht das > ja noch, bei den Nutzdaten wird es wohl schwierig... Wieso soll das für Nutzdaten schwieriger als für Adressen sein? Das ist eine reine Frage der Kodierung. Beispielsweise die Manchesterkodierung sorgt genau für ausreichend viele Flankenwechsel im Datenstrom.
W.A. schrieb: > Das ist eine reine Frage der Kodierung. Beispielsweise die > Manchesterkodierung sorgt genau für ausreichend viele Flankenwechsel im > Datenstrom. Soweit ich weiss machen diese Super-Duper Steine aber genau das schon intern. Da ist ja allerhand drin verbaut, was den Nutzdatensatz derart verschwurbelt, dass dieser auch nahezu fehlerfrei ankommt. Mit den Daten habe ich kaum Probleme, notfalls sorgt das protokoll dafür, dass diese bis zu 15 Mal wiederholt werden bis der ACK sitzt. Eine erste Abhilfe war es übrigens den Kanal auf höhere Werte zu ändern, den meine Kinder für ihre WLAN Sucht ja ständig benutzen. :-)
Diese von dir verlinkten Module setze ich in einem Projekt ein. Zur Zeit sind ca. 300 St. im Einsatz und laufen sehr zuverlaessig (Test über mehrere Stockwerke verlief absolut fehlerfrei). Auf dem Feld überbrücken sie Distanzen zwischen 40 und 120m; und schon mehrmals erhielt die Firmware (ca. 25kB) via Funk ein Update. Nichtsdestotroz ist mein Eindruck sehr zwiespaeltig. Die Software dermassen fehlerfrei hinzukriegen war echt schmerzhaft: selbst die SPI Clock-Frequenz hat einen Einfluss auf das Ganze. Weiterhin weiss man nie, was man aus China erhaelt. Unser Zwischenhaendler empfahl uns ein Modul, das etwa doppelt so teuer war als die üblichen (so um die 7,50 USD). Wir bestellten 2 Muster - und in der Tat waren diese in der Herstellung sehr professionel. Von der Leistung her konnte ich aber keine Unterschiede feststellen. Nichtsdestotrotz enschlossen wir uns, die teueren einzukaufen und bestellten 100 St. Keines dieser 100 St. hat funktioniert! All jene Module zu Preisen so um die 3 USD funktionieren aber einwandfrei; obwohl bei manchen erst mal Lötzinn-Kurzschlüsse entfernt werden musste :) Auch mit den Modulen, die eine PCB-Antenne haben, bin ich sehr zufrieden. Ich habe sie zwar nur zu Testzwecken getestet, aber 2 (oder 3?) Mauern stellten kein Hindernis dar. Was Deine Aussage hinsichtlich der Adresse betrifft, so ist sie korrekt. Ich glaube, dazu gibt es auch einen Hinweis im NRF24L01-Manual. Aber die Daten selbst (ich benutze 32 Bytes) verschicke ich unverarbeitet.
Ich frickel grad am Schreibtisch mit den Dingern, habe rund 10 Stück hier, kleinere und größere. Mit und ohne 10uF Elko am VCC. Gestern lief es noch einwandfrei, der Master (Basisstation hängt an der Wand, holt die Daten der Sensoren von draussen rein und sendet im ACK auch Befehle für Sleep etc.) sendete die geforderten Daten, was ich am Blinken der Led sehe und auch wenn er kein ACK bekommt, weil das dann länger ist. heute morgen läuft es nicht mehr, es wird nur ein Datensatz empfangen, danach sind die Module zu. Spannung weg, CPU gelöscht, anderes Modul... alles geht wieder. Seltsamerweise klappt die Verbindung Arduino (1 Chip Lösung, Arduino nur als Programmierhilfe) mit radiohead Lib einwandfrei zum Cortex. Da liegen 2 Stück draussen in Butterbrot Dosen wetterfest gemacht, funken seit einem halben Jahr mit 2 Mignon Zellen. Sehr seltsam....
Christian J. schrieb: > Ich frickel grad am Schreibtisch mit den Dingern ... Was mir dazu einfaellt: mit der Sendeleistung muss man bei solchen Distanzen auf Minumum.
Christian J. schrieb: > Sind die besser und zuverlässiger als diese mit der Ätzantenne? Das sind die PNA+LNA mit onBoard Verstärker die in Deutschland leider über den zugelassenen Sendeleistungen senden wenn man nicht ein sehr schwieriges Software Frequency-Hopping benutzt, da die keinen integriertes FH haben. Es gibt irgendwo auch Boards die einen kleinen SMT-Anschluss besitzen.
:
Bearbeitet durch User
Mehmet K. schrieb: > Was mir dazu einfaellt: mit der Sendeleistung muss man bei solchen > Distanzen auf Minumum. Jaja.... man darf auch keine Autos in Hamburg anzünden. Haben sie trotzdem getan und sind straffrei ausgegangen. Das Land wird die paar Millisekunden überstehen.... beim FPV Fliegen senden wir mit bis zu 2 Watt per Richtantennen. Habe allerdings die Leistung der Ätz Version auch verbessert durch 2 kleine Dipol-Silberdrähte, statt der Spule. Deutlich bessere Ergebnisse.
Christian J. schrieb: > Mehmet K. schrieb: >> Was mir dazu einfaellt: mit der Sendeleistung muss man bei solchen >> Distanzen auf Minumum. > > Jaja.... Es ging darum, die Sendeleistung für Tests auf dem Schreibtisch zu reduzieren, um die Empfänger nicht zuzustopfen ...
Christian J. schrieb: > Und da ist da noch die Sache mit der 5 Byte Adressierung. Und da ist da noch die Sache mit der Frequenzgenauigkeit. Das scheint niemanden zu interessieren bzw ist noch niemanden aufgefallen. Der verwendete Quarz als Zeitbasis ist 16MHz, der kann schon mal im vervielfachten Ergebnis 200KHz daneben liegen. Mag auch mehr sein, ich habe mir nur ein Exemplar angesehen. Jedenfalls wird sich eine Abweichung von der Sollfrequenz in einer Verringerung der Empfindlichkeit niederschlagen. Im Extremfall kann ja auch Sender und Empfänger in entgegengesetzter Richtung abweichen .... Wenn man es genau nehmen und höchste Reichweite erzielen will müsste man also die Quarze mit den Lastkapazitäten auf die "optimale" Mittenfrequenz abgleichen.
Arduinoquäler schrieb: > Wenn man es genau nehmen und höchste Reichweite erzielen > will müsste man also die Quarze mit den Lastkapazitäten > auf die "optimale" Mittenfrequenz abgleichen. Ich glaube wenn man es wirlich so genau nehmen will, dann kauft man sich nicht für 1,50 Euro diese Dinger bei ebay sondern nimmt Industrieware. Ich habe mit Bluetooth Modulen, die auch in Handys verwendet werden beste Ergebnisse erzielt bei der Anbindung an einen RS232 Port von uC's. Die sind abgeglichen, normenkonform und funktionieren einfach. Du weisst ja nicht genau, ob der 16 Mhz für den RF Teil des Chip zuständig ist, wo die die per PLL dann daraus 2,4Ghz machen. Das kann auch Chip intern erzeugt werden und die 16 Mhz bedienen nur den digitalen Teil. Diese Chips sind Imho festverdrahtete Statemachines ohne Rechenkern. Es gibt bei diesen Billigmodulen auch Unterschiede, manche lassen noch mehr Beschaltung der Chips weg. Ich krieche da aber nicht hinein, sie sollen nur funktionieren und das tun sie gerade ... mal wieder. Die Software war schon aufwendig genug.
>Du weisst ja nicht genau, ob der 16 Mhz für den RF Teil des Chip >zuständig ist, wo die die per PLL dann daraus 2,4Ghz machen. Das kann >auch Chip intern erzeugt werden und die 16 Mhz bedienen nur den >digitalen Teil. Ich glaube nicht, dass man die Sendefrequenz mit der notwendigen Genauigkeit ohne Quarzreferenz erzeugen kann.
Hier gibts es nen langen Thread über gefälschte NRF24L01+: https://forum.mysensors.org/topic/1153/we-are-mostly-using-fake-nrf24l01-s-but-worse-fakes-are-emerging
Heinz schrieb: > Hier gibts es nen langen Thread über gefälschte NRF24L01+: > > https://forum.mysensors.org/topic/1153/we-are-mostly-using-fake-nrf24l01-s-but-worse-fakes-are-emerging Mag sein, aber chin. Halbleiter sind nicht schlechter als japanische. Die Chips von Nordic sind recht teuer, habe da was von 8-10 Euro im Kopf in kleinen Mengen. Markus schrieb: > Ich glaube nicht, dass man die Sendefrequenz mit der notwendigen > Genauigkeit ohne Quarzreferenz erzeugen kann. Unter der Annahme, dass sich bei einer PLL Fehler natürlich auch vervielfachen, selbst wenn die PLL einen 0% Fehler aufweisen würde. 16 Mhz auf 2.4Ghz wäre schon eine sportliche Leistung. Aber das geht auch durch temperaturstabile Schaltkreise, die nachträglich getrimmt werden. So wird das ja auch bei RTC gemacht, da werden Korrekturzellen bespielt kurz vor dem Ausliefern oder aber der Quarz wird durch Lasertrimmen eben "gezogen".
Christian J. schrieb: > Du weisst ja nicht genau, ob der 16 Mhz für den RF Teil des Chip > zuständig ist, wo die die per PLL dann daraus 2,4Ghz machen. Das kann > auch Chip intern erzeugt werden und die 16 Mhz bedienen nur den > digitalen Teil. Diese Annahme bezeichne ich hier mal locker als absoluten Käse. Und bei diesem Käse wird es auch bleiben.
Christian J. schrieb: > Aber das geht auch > durch temperaturstabile Schaltkreise, die nachträglich getrimmt werden. Auch diese Annahme bezeichne ich hier mal locker als absoluten Käse. Und bei diesem Käse wird es auch bleiben. Christian J. schrieb: > selbst wenn die PLL einen 0% Fehler aufweisen würde Eine PLL hat bereits per Definition eine Frequenzabweichung von null Prozent. Sogar null Promille.
>Auch diese Annahme bezeichne ich hier mal locker als absoluten Käse. >Und bei diesem Käse wird es auch bleiben. Arbeitest Du in einer Käserei?
Die verlinkten Module haben z.T. Fehler im Layout des PCBs, wenn du Pechhast bekommst du so eines angedreht. Beitrag "Re: Funkmodule NRF24L01 nicht alle kompatibel?"
Ups sorry das ist das mit Keramikantenne, du hast ja die Schraubversion.
Löten an Klöten kann Leben töten schrieb: > Die verlinkten Module haben z.T. Fehler im Layout des PCBs, wenn du > Pechhast bekommst du so eines angedreht. Kurzer Nachsatz zu den verlinkten Modulen oben. Diese arbeiten hervorragend! Ich sehe es an dem Bblinken der LED ja, wie oft und lange ein Datensatz wiederholt werden muss, bevor er von der gegenstelle akzeptiert wird. Quer durchs Haus einwandfreier Empfang, fast kein Wiederholungen. Es scheint also, dass da doch eine Verbesserung statgefunden hat gegenüber diesen Billigdingern mit der Ätzantenne.
Christian J. schrieb: > Kurzer Nachsatz zu den verlinkten Modulen oben. Diese arbeiten > hervorragend! Kurzer Nachsatz zu deinen HF-Kentnissen zu diesem Modul die ja hauptsächlich aus Käse-Vorstellungen zu bestehen scheinen: Die "neuen" Module funktionieren hauptsächlich deshalb so gut (ähhh "hervorragend!") weil sie - gepaart verwendet - im Übertragungsweg einen Gewinn von 30 dB gegenüber den Modulen "mit Ätzantenne" bringen: 20dB auf der Senderseite durch Erhöhung der Sendeleistung von 0dBm auf 20dBm. 10dB auf der Empfangsseite durch den zugeschalteten Vorverstärker der vor dem NRF liegt.
Ich habe gerade beim Kisten sortieren 2 Versuchsplatinen wiedergefunden.. die benutz ich noch manchmal als PPM to NRF24L01 im RC Bereich. Die Boards waren nicht viel teurer wie die Ätzantennen und komplett mit Antenne. Keine Ahnung woher, muss man nur 5 Minuten Bilderbuch bei Ali schauen.
Hallo, weiss zufällig ein Spezi, wie man den TX FIFO maximal vollschreibt? Ich habe bisher nur einen Datensatz (20 Bytes) reingetackert und dann gesendet. Aber schneller geht es ja, wenn man gleich den TX FIFO ganz voll macht mit 3 Datensätzen. Wie schaut das denn codemässig aus? Bei mir bisher:
1 | CSN_LOW; |
2 | /* Kommando Wort senden fuer Payload mit ACK*/
|
3 | SPI_TransferByte(NRF24L01_CMD_W_TX_PAYLOAD); |
4 | for (uint8_t i = 0; i < len; i++) |
5 | SPI_TransferByte(*(ptr++)); |
6 | CSN_HIGH; |
7 | |
8 | /* RF Modul sendet jetzt */
|
9 | CE_HIGH; |
Christian J. schrieb: > weiss zufällig ein Spezi, wie man den TX FIFO maximal vollschreibt? Nein, ich weiss es nicht, aber ich hab ins Datenblatt geschaut. Da steht: ------------------------------------------------------------------ The following FIFOs are present in nRF24L01+: • TX three level, 32 byte FIFO • RX three level, 32 byte FIFO Both FIFOs have a controller and are accessible through the SPI by using dedicated SPI commands. A TX FIFO in PRX can store payloads for ACK packets to three different PTX devices. If the TX FIFO contains more than one payload to a pipe, payloads are handled using the first in - first out principle. The TX FIFO in a PRX is blocked if all pending payloads are addressed to pipes where the link to the PTX is lost. In this case, the MCU can flush the TX FIFO using the FLUSH_TX command. ------------------------------------------------------------------ Daraus würde ich entnehmen dass ich in das FIFO solange hinein- schreiben kann bis es voll ist, dann kann ich für jeden FIFO- Inhalt einen TX auslösen, was zuerst reinkommt, kommt zuerst raus.
Moin, weis zufällig jemand, wie man einen "optimalen" Kanal heraus finden kann? Ich meine es geistert ja viel 2.4 Ghz Geraffel durch die zahllosen WLAN in der Luft herum. Man müsste irgendwie rauskriegen wieviel Störungen auf einem Kanal sind und dann den raussuchen der die wenigsten hat. Das mit dem FIFO ist recht tricky, ein 10us CE Puls haut nur 1 Fifo Inhalt raus, hält man CE auf HIGH schiebt er alle raus bis leer. Die Reichweite der LNA Module bekommt man deutlich besser, wenn man denen mal Schirmung angedeihen lässt mit normaler ALU Folie. Gruss, Christian
Christian J. schrieb: > Du weisst ja nicht genau, ob der 16 Mhz für den RF Teil des Chip > zuständig ist, wo die die per PLL dann daraus 2,4Ghz machen. Kann man im Datenblatt nachlesen, das es so ist. Der Quarz wird mit tolerablen Abweichung von der Nennfrequenz spezifiziert.
Hast du eine Fritzbox? Die zeigt sehr schön die Belegung im Frequenzbereich an. Aber der nRF kann doch auch den RSSI ausgeben, damit müsste man auch einen Scanner bauen können.
Johannes S. schrieb: > ber der nRF kann doch auch den RSSI ausgeben, damit > müsste man auch einen Scanner bauen können. Kann er nicht. Die einzige Anzeigemöglichkeit die er hat ist ein Schwellwert von -64 dBm, ein Eingangs-Signalpegel der entweder überschritten wird oder nicht. Daraus einen RSSI abzuleiten - wie bei Handys oder WLAN Boxen üblich - ist schon recht kühn. Einfach schnell mal eine gewagte Information ins Forum hinfetzen und gut is, gell? Jeden Tag eine "gute" Tat .... Aus dem Datenblatt: ------------------------------------------------------------ 6.4 Received Power Detector measurements Received Power Detector (RPD), located in register 09, bit 0, triggers at received power levels above -64 dBm that are present in the RF channel you receive on. If the received power is less than -64 dBm, RDP = 0. ------------------------------------------------------------
Johannes S. schrieb: > Aber der nRF kann doch auch den RSSI ausgeben, damit > müsste man auch einen Scanner bauen können. Woher stammt diese Information? Ich lese nur, dass es ein einziges Bit gibt, was über einen Schwellwert Auskunft gibt. Und die Fritzbox zeigt das zwar an, ist aber selbst ein Frequenzhopper. Das kann man ändern aber da fasse ich lieber nichts an, da weitere 6 Boxen hier im Haus aktiv sind. Die einzige Chance, die man haben könnte ich eine Präambel als Schlüssel zu wählen, die viele Störsignale durchlässt und damit die Kanäle zu scannen. Leider erfährt man nicht, wann ein Störsatz kam, da dieser direkt wieder verworfen wird.
Der nRF51822 hat eine RSSI Info, und da Nordic schreibt das der nRF24 kompatibel ist (+ integriertem Cortec-M0) hatte ich angenommen das der nRF24L01 das auch ausgeben kann. Aber zum Glück gibt es hier Götter die das gleich korrigieren können. Im Nordic Forum findet man auch schnell die Antwort das der nRF24 keine RSSI Anzeige hat.
Vielleicht lässt sich das ja doch benutzen. Wenn dieses Bit, unabhängig von dem digitalen Zahelnsalat gesetzt wird heisst das ja, dass der Kanal belegt oder frei ist. Da andere teilnehmer aber im Millisekundentakt die Kanäle wechseln ist diese Info auch nicht viel wert. Ich stelle nur fest, dass mein Slave viele Pakete erst beim 2.ten oder 3.ten Versuch empfängt. Ich muss die Daten mehrfach senden, damit einer durchkommt. 6.4 Received Power Detector measurements Received Power Detector (RPD), located in register 09, bit 0, triggers at received power levels above -64 dBm that are present in the RF channel you receive on. If the received power is less than -64 dBm, RDP = 0. The RPD can be read out at any time while nRF24L01+ is in receive mode. This offers a snapshot of the current received power level in the channel. The RPD status is latched when a valid packet is received which then indicates signal strength from your own transmitter. If no packets are received the RPD is latched at the end of a receive period as a result of host MCU setting CE low or RX time out controlled by Enhanced ShockBurst™. The status of RPD is correct when RX mode is enabled and after a wait time of Tstby2a +Tdelay_AGC= 130us + 40us.
Gähn.... nach einigem Testen in freier Luft hier hat sich dieses RPD Bit doch als ganz nützlich erwiesen.
1 | val = DWT->CYCCNT; |
2 | for (int i = 0; i < 128; i++) { |
3 | RF_SetChannel(i); |
4 | Delay(200); |
5 | if (RF_ReadRegSingle(NRF24L01_REG_RPD) & 0x01) { |
6 | channels[i] = 1; |
7 | RF_PowerUpRx(); |
8 | }
|
9 | }
|
Nach einer gewissen Zeit sieht man, dass sich die Kanäle um die Masterfrequenz herum füllen der auf 40 sendet, also 37 bis 43 sind 1 und auch diverse andere von den WLANs um mich herum. Es bleiben aber auch genug frei. Mit einer pfiffigen Routine lässt sich also ein freier Bereich eingrenzen. Nach jeder 1 Abfrage des Bits muss das 24L01 zurückgesetzt werden, also Status löschen und Fifos. Sonst bleibt es 1.
Moin, ich bastel immer noch mit diesem Stein herum und studiere das Datenblatt zum x-ten Male. Was mir immer noch nicht ganz klar ist und das vielleicht auch zu Datenverlusten führt (nur jedes 2-3 te Paket kommt auch an) ist dieses: Wie frage ich den TX Mode ab, ob er beendet ist? Funktioniert die SPI Abfrage überhaupt in diesem TX Mode? Denn manche Befehle lassen sich nur im Standby Mode einspielen. Ich lasse CE=1, da ich mir die Möglichkeit offenhalten will den FIFO voll zuschreiben für fortlaufende Übertragung. Ist das korrekt schon während der Sendephase laufend den Status zu testen auf MAX_RT oder TX_DS? Aktuell wiederhole ich jede Sendesequenz max. 5 Mal, da ich bemerkt habe, dass oft der erste Satz nicht ge ACK'ed wird aber die nachfolgenden schon. Außerdem ist die Reichweite stark abhängig von dem Kanal: Von 1 bis ca 40 alles ok, reicht ein Mini-Modul für 1 Euro. Darüber ab ca Kanal 60 brauche ich ein LNA Modul mit Antenne, um noch ins Wohnzimmer zu kommen. Sehr seltsam.... Datenblatt: The nRF24L01+ stays in TX mode until it finishes transmitting a packet. If CE = 0, nRF24L01+ returns to standby-I mode. If CE = 1, the status of the TX FIFO determines the next action. If the TX FIFO is not empty the nRF24L01+ remains in TX mode and transmits the next packet. If the TX FIFO is empty the nRF24L01+ goes into standby-II mode. The nRF24L01+ transmitter PLL operates in open loop when in TX mode. It is important never to keep the nRF24L01+ in TX mode for more than 4ms at a time. If the Enhanced ShockBurst™ features are enabled, nRF24L01+ is never in TX mode longer than 4ms
1 | /* TX und ACK Pipe setzen */
|
2 | RF_WriteRegMulti(NRF24L01_REG_TX_ADDR,receiver,0x05); /* TX Pipe: Hier wird gesendet */ |
3 | RF_WriteRegMulti(NRF24L01_REG_RX_ADDR_P0,receiver,0x05); /* RX Pipe: Hier wird ACK empfangen */ |
4 | |
5 | RF_PowerUpTX(); |
6 | |
7 | CSN_LOW; |
8 | /* Kommando Wort senden fuer Payload mit ACK*/
|
9 | SPI_TransferByte(NRF24L01_CMD_W_TX_PAYLOAD); |
10 | /* Datenbytes in Pipe einspielen */
|
11 | for (uint8_t i = 0; i < len; i++) |
12 | SPI_TransferByte(*(ptr++)); |
13 | CSN_HIGH; |
14 | |
15 | /* RF Modul sendet jetzt... */
|
16 | CE_HIGH; |
17 | Delay(11); |
18 | |
19 | /* Ende der Übertragung abwarten... */
|
20 | uint16_t to = 50000; |
21 | do { |
22 | RF_GetStatus(&rf_status_reg); |
23 | if (!to--) { |
24 | /* Timeout: Modul zurück auf Empfang vom Sensor setzen */
|
25 | CE_LOW; |
26 | RF_PowerUpRx(); |
27 | return RF_TIMEOUT; |
28 | }
|
29 | } while ((rf_status_reg.tx_ds == false) && (rf_status_reg.max_rt == false)); |
30 | |
31 | CE_LOW; |
32 | |
33 | /* Modul ist jetzt im Standby-II Mode, zurückschalten in RX Mode für Sensor*/
|
34 | RF_PowerUpRx(); |
35 | if (!rf_status_reg.tx_ds) /* Keine Antwort? */ |
36 | return RF_NO_ACK; |
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
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.