Hallo zusammen, ich spiele derzeit etwas mit o.g. nRF24L01+ rum. Ich habe die Module von iteadstudio, Layout & Infos finden sich im Shop (http://iteadstudio.com/store/index.php?main_page=product_info&cPath=7&products_id=53). Die Herstellerseite: http://www.nordicsemi.com/kor/Products/2.4GHz-RF/nRF24L01P Nun haben wir hier merkwürdige Probleme. Konfiguration erstmal: 2 Mbit Air Data Rate, Enhanced Shockburst deaktiviert (geplant ist mal eine Many-to-Many Datenübertragung, das scheidet mit Enhanced Shockburst aus). Payload 32 Bytes. 1 Sender, 1 Empfänger. Maximale Sendeleistung (= 0 dBm) Bereits auf dem Schreibtisch in 20cm Entfernung gehen einige Pakete verloren, in 3 m Abstand kommt etwa die Hälfte an, durch die Tür um die Ecke fast garnichts mehr (keine 5m, Sandstein, welcher bei Wlan 2,4 GHz kein Hindernis darstellt). Dabei sind die Platinenantennen allerdings nicht ausgerichtet worden. Ich habe ja mit schlechter Reichweite gerechnet - aber DAS schaff ich mit Infrarot besser... Gibt es hier anderweitige Erfahrungen? Zielanwendung ist die intelligente Heizungssteuerung. Reichweite von 15-20m inkl. 1-2 o.g. Wände wäre echt toll. Back to the RFM12?! Morgen folgt ein Test mit 250 kBps - allerdings wird der wohl leider keine Wunder vollbringen. Nen Packetloss von 50% mag man noch gut durch Retransmissions auffangen können, aber ich dachte eher, dass das dann die Reserve für schlechte Bedingungen bringt und nicht zum Tagesgeschehen wird. Bei deaktivierter CRC sieht man auch einen ganzen Haufen gekippter Bits - halt die Pakete, die sonst nicht ankommen. Ganz schöner Mist, das Zeug! Von wem hab ich hier kürzlich das Zitat "Kennste Funk nimmste Kabel" gelesen? Gruß, Matthias
Hallo Matthias, das hört sich nicht gut an! Ich habe mir ein paar Module vor einem Monat besorgt und wollte zur Jahreswende einige Tests mit ihnen machen. Kennst Du die Seite http://blog.diyembedded.com/ ? Dort gibt es viele Infos und Tutorials zum nRF24L01. Vielleicht ist das schon einmal hilfreich. Gruß kokisan
Hi Matthias! Ich arbeite auch gerade mit dem nRF24L01+ und auch mit dem gleichen Modul, nur habe ich meines von Ebay, sieht aber genau so aus. Ich habe dann noch ein zweites Modul mit einer etwas anderen Antennengestaltung. Ich habe leider noch keine Reichweitentest machen können da ich auf weitere Breadboards warte. Aber ich kann zumindest sagen, daß mir auf dem Schreibtisch keine Pakete verloren gehen. Allerdings arbeite ich auch mit Enhanced Shockburst. Ich frage auch die "resent packages" ab und da sehe ich auch, daß kaum ein Package wiederholt gesendet wird. Ich sende aber auch mit zwei Sendern gleichzeitig. Wie schaut denn Dein Code für TX und RX aus? Wie viele Pakete schickst Du in welcher Zeit? Schon mal einen anderen Kanal ausprobiert? Schon mal RPD abgefragt? FIFO Full? LG Ernst
Noch eine Frage aus persönlichem Interesse: Wieso wird das eine many to many Übertragung? Ich kann mir gerade nicht vorstellen wieso eine Heizungssteuerung eine many to many Übertragung braucht? Gerade Enhanced Shockburst ist doch der Bringer bei dem Chip? Eine Heizungssteuerung klingt jetzt nicht danach, als ob da extreme Datenmengen zeitkritisch übertragen werden müssen? LG Ernst
Hi, Ja, das many-to-many steht derzeit auch auf dem Prüfstand. Dennoch bleibt bei der Stern-Architektur eine Beschränkung auf max. 6 Teilnehmer. Das reicht mir allerdings sogar - nur etwas schade, soetwas speziell auf einen Chip auslegen zu müssen. Jedes Paket, welches dir bei Enh. Shockburst als Resent angezeigt wird, ist bei mir verloren. Somit decken sich ja unsere Schreibtisch-Erfahrungen. Bei einer zweiten Schaltung mit nem Cortex M3 verliere ich auch dort über 50%, das kann aber noch ein Softwarefehler sein (denn der AVR-Empfänger im Thermostat funktioniert dort recht gut). Der Code ist derzeit noch nicht bei Github, daher erstmal ein paar Ausschnitte, vom Empfänger (Sender steht mir derzeit nicht zur Verfügung, dort geht aber vermutlich alles glatt). Flags werden keine weiteren überprüft. Empfangen im Interrupt:
1 | void nRF24L01_IRQ(void) |
2 | {
|
3 | static uint8_t irqCount = 0; |
4 | uint8_t status; |
5 | uint8_t rpd; |
6 | status = nRF24L01_command(NOP, 0, 0); |
7 | displayBargraph(++irqCount * 2); |
8 | |
9 | if(status & (1 << TX_DS)) |
10 | {
|
11 | if(TxActive == 2) |
12 | {
|
13 | RX; |
14 | mirf_CE_hi; |
15 | |
16 | }
|
17 | |
18 | |
19 | TxActive = 0; |
20 | displaySymbols(0, LCD_TOWER); |
21 | nRF24L01_write_register(STATUS, 1 << TX_DS); |
22 | }
|
23 | #ifdef RX_CALLBACK
|
24 | if(status & (1 << RX_DR)) |
25 | {
|
26 | rxCallback(); |
27 | }
|
28 | #endif
|
29 | }
|
30 | |
31 | uint8_t nRF24L01_get_data(uint8_t * data) |
32 | {
|
33 | uint8_t len; |
34 | uint8_t status; |
35 | //status = nRF24L01_command(R_RX_PL_WID, &len, 1);
|
36 | len = 32; |
37 | |
38 | if(len > 32) |
39 | {
|
40 | nRF24L01_command(FLUSH_RX, 0, 0); |
41 | return 0; |
42 | }
|
43 | nRF24L01_commandR(R_RX_PAYLOAD, data, len); |
44 | nRF24L01_write_register(STATUS, (1 << RX_DR)); |
45 | /* todo: datasheet says we shall read FIFO_STATUS to check for more data */
|
46 | |
47 | return len; |
48 | }
|
Die Callback Funktion ruft dann getData auf. Gesendet wird derzeit etwa mit 3-4 Paketen pro Sekunde, sodass der Fall, dass 2 Pakete gleichzeitig eintreffen nicht auftreten sollte (denn der empfangende AVR hat nichts zu tun). Selbst wenn: Ein geringer Paketverlust ist mir egal - das Problem hier ist ja eher, dass es auf 3-5m schon richtig mau aussieht. Das scheint mir weniger ein Codeproblem. RPD habe ich leider noch nicht überprüft, kommt noch. Konfiguration nochmal:
1 | #define DISABLE_ENHANCED_SHOCKBURST 1
|
2 | |
3 | /* Callback out of Interupt for incoming packet */
|
4 | #define RX_CALLBACK 1
|
5 | |
6 | /* 1 Byte CRC */
|
7 | #define DEF_CONFIG ( (1<<EN_CRC) | (0<<CRCO) | (1 << MASK_MAX_RT))
|
8 | |
9 | /* no retransmission delay, up to 0 retransmissions */
|
10 | #define DEF_SETUP_RETR ((0 << ARD) | (0 << ARC))
|
11 | |
12 | /* Channel Offset in MHz*/
|
13 | /* ISM is 2,4-2,5 GHz, WLAN g */
|
14 | #define DEF_RF_CH 65
|
15 | |
16 | /* Data Rate 2 MBps, maximum output power */
|
17 | #define DEF_RF_SETUP ((1 << RF_DR_HIGH) | (3 << RF_PWR))
|
18 | |
19 | /* Dynamic Payload Length, Payload with Ack */
|
20 | #define DEF_FEATURE (0)
|
21 | |
22 | /* Static Payload on all data pipes */
|
23 | #define DEF_DYNPD (0)
|
24 | |
25 | nRF24L01_write_register(RF_CH, DEF_RF_CH); |
26 | nRF24L01_write_register(CONFIG, DEF_CONFIG); |
27 | nRF24L01_write_register(SETUP_RETR, DEF_SETUP_RETR); |
28 | nRF24L01_write_register(RF_SETUP, DEF_RF_SETUP); |
29 | nRF24L01_write_register(FEATURE, DEF_FEATURE); |
30 | nRF24L01_write_register(DYNPD, DEF_DYNPD); |
31 | #ifdef DISABLE_ENHANCED_SHOCKBURST
|
32 | nRF24L01_write_register(EN_AA, 0); |
33 | #endif
|
34 | |
35 | nRF24L01_write_register(EN_RXADDR, 0); /* disable all rx pipes */ |
36 | nRF24L01_command(FLUSH_RX, 0, 0); |
37 | nRF24L01_command(FLUSH_TX, 0, 0); |
38 | nRF24L01_write_register(STATUS, (1 << RX_DR | (1 << TX_DS) | (1 << MAX_RT))); |
Callback:
1 | void funkRxDataAvailable(void) |
2 | {
|
3 | static uint16_t readCounter = 0; |
4 | uint8_t rxData[32]; |
5 | uint8_t readLen; |
6 | readLen = nRF24L01_get_data(rxData); |
7 | |
8 | readCounter++; |
9 | displayWeekday(rxData[0]); |
10 | displayNumber(readCounter); |
11 | }
|
(RX Pipe wird natürlich wieder aktiviert; Empfänger ist die ganze Zeit ohne Senden im RX Modus, alles andere an dem Controller ist deaktiviert und die Hauptschleife tut nichts. Paketkontrolle über Zähler auf Display, welcher aus der Empfangsroutine hochgezählt wird. Realisiert über itoa ist er zwar sicher nicht der schnellste, dürfte aber kaum mehr als wenige ms in Anspruch nehmen, 1 MHz Systemtakt) Ich werde nachher/am WE nochmal Enhanced Shockburst testen, und eben die 250 kBps. Rückmeldung gibts bis Sonntag, da nicht besonders viel Zeit :) Vielen Dank für deine Unterstützung.
Hi Matthias! Matthias Larisch schrieb: > Ja, das many-to-many steht derzeit auch auf dem Prüfstand. Dennoch > bleibt bei der Stern-Architektur eine Beschränkung auf max. 6 > Teilnehmer. Das reicht mir allerdings sogar - nur etwas schade, soetwas > speziell auf einen Chip auslegen zu müssen. Sollte es nicht ausreichen dann könntest noch immer beim Empfänger-µC zwei nRF24L01 betreiben und so zwei mal 6 Sender betreiben. Das sollte aufgrund moderaten Datenmenge die zu übertragen ist leicht zu bewerkstelligen sein. > > Jedes Paket, welches dir bei Enh. Shockburst als Resent angezeigt wird, > ist bei mir verloren. Somit decken sich ja unsere > Schreibtisch-Erfahrungen. Bei einer zweiten Schaltung mit nem Cortex M3 > verliere ich auch dort über 50%, das kann aber noch ein Softwarefehler > sein (denn der AVR-Empfänger im Thermostat funktioniert dort recht gut). Ich habe das nochmals probiert - wie gesagt, nur Tischvariante - und ich verliere bei zwei Sendern die gleichzeitig aktiv sind mit Enhanced Shockburst und versetzten Sendezeitpunkten kein einziges Paket. Testdauer waren ca. drei Stunden bei 2Mbps. Unsere Aufbauten sind halt insoferne nicht vergleichbar weil Du ohne Enhanced Shockburst arbeitest. Ich sende ja Pakete nochmals wenn kein Ack ankommt. > Der Code ist derzeit noch nicht bei Github, daher erstmal ein paar > Ausschnitte, vom Empfänger (Sender steht mir derzeit nicht zur > Verfügung, dort geht aber vermutlich alles glatt). Flags werden keine > weiteren überprüft. Empfangen im Interrupt: >
1 | > void nRF24L01_IRQ(void) |
2 | > { |
3 | > static uint8_t irqCount = 0; |
4 | > uint8_t status; |
5 | > uint8_t rpd; |
6 | > status = nRF24L01_command(NOP, 0, 0); |
7 | > displayBargraph(++irqCount * 2); |
8 | >
|
9 | > if(status & (1 << TX_DS)) |
10 | > { |
11 | > if(TxActive == 2) |
12 | > { |
13 | > RX; |
14 | > mirf_CE_hi; |
15 | >
|
16 | > } |
17 | >
|
18 | >
|
19 | > TxActive = 0; |
20 | > displaySymbols(0, LCD_TOWER); |
21 | > nRF24L01_write_register(STATUS, 1 << TX_DS); |
22 | |
23 | Warum prüfst Du beim Empfänger das TX_DS? Ich nehme an, das sind noch Reste vom Sender-Code? |
24 | |
25 | > } |
26 | > #ifdef RX_CALLBACK |
27 | > if(status & (1 << RX_DR)) |
28 | > { |
29 | > rxCallback(); |
30 | > } |
31 | > #endif |
32 | > } |
33 | >
|
34 | > uint8_t nRF24L01_get_data(uint8_t * data) |
35 | > { |
36 | > uint8_t len; |
37 | > uint8_t status; |
38 | > //status = nRF24L01_command(R_RX_PL_WID, &len, 1); |
39 | > len = 32; |
40 | >
|
41 | > if(len > 32) |
42 | > { |
43 | > nRF24L01_command(FLUSH_RX, 0, 0); |
44 | > return 0; |
45 | > } |
46 | > nRF24L01_commandR(R_RX_PAYLOAD, data, len); |
47 | > nRF24L01_write_register(STATUS, (1 << RX_DR)); |
48 | > /* todo: datasheet says we shall read FIFO_STATUS to check for more |
49 | > data */
|
50 | >
|
51 | > return len; |
52 | > } |
53 | >
|
> Da oben steht noch ein eventuell wichtiger Punkt denke ich. Du prüfst ja auf das RX_DR Bit ob ein neues Datenpaket angekommen ist. Probiere einmal noch zusätzlich den FIFO_STATUS zu kontrollieren ob noch weitere Pakete im FIFO sind die aufs auslesen warten. Du hast recht, daß es unwahrscheinlich ist, daß da mehr warten aber so hast Du die Sicherheit, daß nicht Pakete wegen überlaufenden FIFOs verloren gehen. Ich polle übrigens bei meinem Programm und lese die Daten nicht über den Interrupt aus. Aber das macht keinen Unterschied denke ich. Du könntest auf das RX_DR Bit ja mal im Interrupt reagieren und die Payload auslesen und den FIFO-STATUS in der While Schleife auslesen und gegebenenfalls darauf reagieren. > Die Callback Funktion ruft dann getData auf. > > Gesendet wird derzeit etwa mit 3-4 Paketen pro Sekunde, sodass der Fall, > dass 2 Pakete gleichzeitig eintreffen nicht auftreten sollte (denn der > empfangende AVR hat nichts zu tun). Selbst wenn: Ein geringer > Paketverlust ist mir egal - das Problem hier ist ja eher, dass es auf > 3-5m schon richtig mau aussieht. Das scheint mir weniger ein > Codeproblem. > RPD habe ich leider noch nicht überprüft, kommt noch. Was Du eben noch machen könntest mal einen anderen Kanal zu probieren. Vielleicht ist zufällig der Kanal auf den Du sendest durch W-Lan und Konsorten bei Dir besonders verseucht. Noch was ist mir eingefallen: Hast Du die Standard-Adressen vom nRFL01 übernommen oder eigene gewählt? > Vielen Dank für deine Unterstützung. Gerne. LG Ernst
Ernst B. schrieb: > Sollte es nicht ausreichen dann könntest noch immer beim Empfänger-µC > zwei nRF24L01 betreiben und so zwei mal 6 Sender betreiben. Das sollte > aufgrund moderaten Datenmenge die zu übertragen ist leicht zu > bewerkstelligen sein. Das führt eben wie beschrieben zur Abhängigkeit von genau diesem Nordic Chip (Enh. Shockburst mit Adressierung eben generell), das würde ich gerne vermeiden, werde es aber nun wohl doch erstmal so machen, da das Projekt langsam mal "life" gehen muss - ne Heizungssteuerung im Sommer bringt mir nicht viel :). Für mich selbst reichen 3-4 Nodes zusätzlich zur Basis, das passt also. > Ich habe das nochmals probiert - wie gesagt, nur Tischvariante - und ich > verliere bei zwei Sendern die gleichzeitig aktiv sind mit Enhanced > Shockburst und versetzten Sendezeitpunkten kein einziges Paket. > Testdauer waren ca. drei Stunden bei 2Mbps. Unsere Aufbauten sind halt > insoferne nicht vergleichbar weil Du ohne Enhanced Shockburst arbeitest. > Ich sende ja Pakete nochmals wenn kein Ack ankommt. Ich hatte dich so verstanden, dass du mal den ARC_CNT in OBSERVE_TX ausgelesen hattest. Der ist Paket-individuell (muss also vorm nächsten Versand gelesen werden), und ich verstand dich weiter so, dass der nicht bei 0 war. > > Warum prüfst Du beim Empfänger das TX_DS? Ich nehme an, das sind noch > Reste vom Sender-Code? Jede Node bei mir kann senden und empfangen. "Empfänger" schrieb ich deswegen, weil das Teil eben zum Test nur als Empfänger genutzt wurde. > > Du hast recht, daß es > unwahrscheinlich ist, daß da mehr warten aber so hast Du die Sicherheit, > daß nicht Pakete wegen überlaufenden FIFOs verloren gehen. Deswegen schrieb ich: Es ist mir erstmal egal, ob ich 20% Paketverlust habe. Aber 90% sind nicht akzeptabel. Diese können eben nicht vom Fifo-Überlauf stammen, zumal ich ja auf dem Schreibtisch nur etwa 1-2% der Pakete verliere. > > Was Du eben noch machen könntest mal einen anderen Kanal zu probieren. > Vielleicht ist zufällig der Kanal auf den Du sendest durch W-Lan und > Konsorten bei Dir besonders verseucht. Das könnte ich nochmal tun, ja. Zumindest Wlans sind in dem Frequenzbereich (Kanal 8-13) jedoch nicht stärker als -82 dBm (laut Notebook auf dem Schreibtisch) empfangbar. Das sagt natürlich nichts über die eigentliche Feldstärke aus - RPD war allerdings immer 0, solange nicht mein eigener Sender gesendet hat. > > Noch was ist mir eingefallen: Hast Du die Standard-Adressen vom nRFL01 > übernommen oder eigene gewählt? Nein, eigene. Dabei habe ich versucht, mich von der Preambel etwas zu unterscheiden und trotzdem möglichst viele Bitwechsel einzubauen: 0xA7, 0x5B, 0xCD, 0x14, 0x15 Wobei mir gerade jetzt einfällt, dass ja das rechteste Byte das MSByte ist (das 0xA7 sende ich zuerst zum Chip), in Gedanken hatte ich das genau andersherum konstruiert. Meine Erkenntnis gab allerdings auch eher, dass die Pakete korrekt erkannt wurden, jedoch aufgrund der CRC verworfen wurden, da ich ohne CRC deutlich mehr Pakete erhalte, welche jedoch gekippte Bits aufweisen. Ich bin leider derzeit nicht in der Lage, weitere Tests durchzuführen. Bis morgen Abend wird das allerdings nachgeholt und dann melde ich mich nochmal mit den neusten Erkenntnissen :) Gruß & ein schönes Wochenende, Matthias
Matthias Larisch schrieb: > Das führt eben wie beschrieben zur Abhängigkeit von genau diesem Nordic > Chip (Enh. Shockburst mit Adressierung eben generell), das würde ich > gerne vermeiden, werde es aber nun wohl doch erstmal so machen, da das > Projekt langsam mal "life" gehen muss - ne Heizungssteuerung im Sommer > bringt mir nicht viel :). Für mich selbst reichen 3-4 Nodes zusätzlich > zur Basis, das passt also. > Ah, verstehe. Abhängig macht man sich immer in irgendeiner Form, den Code kannst eh nicht weiter verwenden wenn Du ein anderes Modul einsetzt. Und wenn ich mir die Probleme ansehe die bei den RFM-Modulen hier immer nachgefragt werden dann scheint mir doch der nRF24L01 ein wunderbares Produkt im Vergleich. Produkte die kein Enhanced Shockburst bzw. ähnliches onchip bieten sind dann ja doch schwieriger und mühsamer zu programmieren weil man sich um diese Dinge selbst kümmern muß. Sollte ein Paket trotz resent nicht ankommen stellst eh über MAX_RT fest und dann schickst es halt nocheinmal. Bis es halt angekommen ist. Ich würde jetzt gar nicht so viel Energie da rein stecken wie es ohne Enhanced Shockburst geht sondern mal schauen wie es mit läuft. Was nicht heißt, daß ich Deine Neugier nicht verstehe. :-)) > Ich hatte dich so verstanden, dass du mal den ARC_CNT in OBSERVE_TX > ausgelesen hattest. Der ist Paket-individuell (muss also vorm nächsten > Versand gelesen werden), und ich verstand dich weiter so, dass der nicht > bei 0 war. Da hast mich schon richtig verstanden. Ich wollte auch durch Deine Erfahrungen mal schauen ob ich bei aktiviertem Enhanced Shockburst Pakete komplett verliere über eine längere Zeit. Bei dem Versuch habe ich resent nicht mitgeloggt. Für mich persönlich ist wichtig, daß die Pakete schlußendlich ankommen. Und mein Projekt ist ganz ähnlich, ich messe die Zimmertemperatur und Feuchte in weiterer Folge. Nur steuere ich (noch) keine Heizung damit. > Deswegen schrieb ich: Es ist mir erstmal egal, ob ich 20% Paketverlust > habe. Aber 90% sind nicht akzeptabel. Diese können eben nicht vom > Fifo-Überlauf stammen, zumal ich ja auf dem Schreibtisch nur etwa 1-2% > der Pakete verliere. Ja, mich wundert das auch, daß Du da gleich so viele Pakete verlierst. > Das könnte ich nochmal tun, ja. Zumindest Wlans sind in dem > Frequenzbereich (Kanal 8-13) jedoch nicht stärker als -82 dBm (laut > Notebook auf dem Schreibtisch) empfangbar. Das sagt natürlich nichts > über die eigentliche Feldstärke aus - RPD war allerdings immer 0, > solange nicht mein eigener Sender gesendet hat. >> Bin schon gespannt ob das eine Änderung bewirkt. Auch auf Deine Versuche mit 250k bin ich neugierig. Teste doch auch mal 1Mbps, wenn ich das richtig im Kopf habe belegt das nur 1 Kanal im Vergleich zu 2Mbps. > Nein, eigene. Dabei habe ich versucht, mich von der Preambel etwas zu > unterscheiden und trotzdem möglichst viele Bitwechsel einzubauen: > 0xA7, 0x5B, 0xCD, 0x14, 0x15 > > Wobei mir gerade jetzt einfällt, dass ja das rechteste Byte das MSByte > ist (das 0xA7 sende ich zuerst zum Chip), in Gedanken hatte ich das > genau andersherum konstruiert. > Gut, dann fällt da mein Gedanke auch aus, daß es an den Bitwechseln liegt. > Ich bin leider derzeit nicht in der Lage, weitere Tests durchzuführen. > Bis morgen Abend wird das allerdings nachgeholt und dann melde ich mich > nochmal mit den neusten Erkenntnissen :) Ich kann heute leider auch nix testen. Bin aber auf Deine nächsten Erkenntnisse schon sehr gespannt. > > Gruß & ein schönes Wochenende, > > Matthias Wünsche Dir auch ein schönes Wochenende, LG Ernst
Hallo Matthias, gibt es schon neue Erkenntnisse zu diesem Thema? Gruß kokisan
Jein: Ein Teil der Probleme (die Erkenntnisse mit den gekippten Bits) beruhen auf einer fehlerhaften Versorgungsspannung (Billig-LM1117, welcher > 300 mVpp output ripple erzeugt hat). Über Weihnachten bin ich anderweitig beschäftigt (wer ist das nicht) - daher ruht das Projekt großteils erstmal. Somit: Keine wirklichen neuen Erkenntnisse. Aber ebenso wie zum "Sparmatic Thread" werde ich auch hier wieder weiterschreiben, wenn es weitergeht :) Schöne Feiertage an alle!
Hi Zusammen! So, ich habe ein paar News nachdem ich heute endlich ein paar Tests machen konnte die über die Tischplatte hinaus gingen. Es sind schnelle Tests gewesen ich kann das Ergebnis also nicht genau quantifizieren. Es ging ja um die Reichweite und ich habe folgendes festgestellt: Mit diesem Sender http://www.ebay.at/itm/2PCS-NRF24L01-2-4GHz-Wireless-Transceiver-Module-/230684823300?pt=UK_Computing_DesktopComponents_RL&hash=item35b5e30f04 wurden die Tests durchgeführt. Es ist nicht der gleiche Sender wie ihn Matthias verwendet. Die Ausführung von Matthias habe ich auch hier aber damit noch keine Tests gefahren. Das folgt noch denn ich plane meinen Endausbau mit der anderen Version welcher auch der Empfänger ist in diesem Fall. (http://www.ebay.at/itm/Mini-2-4Ghz-Wireless-NRF24L01-Transceiver-Module-/320608404697?pt=LH_DefaultDomain_0&hash=item4aa5c004d9) Enhanced Shockburst ist aktiviert mit 15 Wiederholungen falls kein Ack zurückkommt. Datenrate 2Mbps. Durch zwei Wände mit einer Entfernung von ca. 7m verliere ich kaum ein Paket. In einer Entfernung von nur 5m aber durch eine Glasfront (senden vom Balkon) verliere ich doch einige Pakete. Möglicherweise liegt das aber am Metalltisch auf dem der Sender stand? Hat mich doch ziemlich überrascht. 3m innerhalb eines Zimmers verliere ich kein Paket und alle Pakete kommen sofort an. Für mich bedeutet das, daß ich meinen Code erweitern werde da ich nur alle 5 Minuten Daten übertrage. Bei erreichen der maximalen Wiederholungen werde ich die Daten nochmals auf die Reise schicken. Außerdem werde ich noch langsamere Übertragungsraten ausprobieren wobei ich soweit eigentlich zufrieden bin mit dem wie es funktioniert. Das war es mal kurz, lg Ernst
So, wieder News von mir: Das verändern des Kanals sowie die Geschwindigkeit auf 250kbps setzen brachte den Durchbruch. Damit kommen viele Pakete an, sogar von meinem Sorgenkind dem Balkon. Getestet wird inzwischen nur mit diesem Modul: http://www.ebay.de/itm/ws/eBayISAPI.dll?ViewItem&item=320608404697&clk_rvr_id=303038203596 Mir kommt vor, daß das insgesamt besser ist als das andere Modul. (Siehe Beitrag davor) Als nächstes werde ich mit dem nRF mal einen "Scanner" programmieren, vielleicht kann man so jene Kanäle herausfiltern wo besonders viel Verkehr lauert. LG Ernst
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.