Ez az IC szerintem nem használ "Spread Spectrum Frequency Hopping"-ot.
Katonai felhasználása ismert a szórt spektrumú sugárzásnak, ott a nehezebb lehallgathatóság volt a cél.
A civil életben azt hiszem pl. a Bluetooth is végez csatornaugrásokat kommunikáció közben, ott azért, hogy a zajos vagy használt csatornákat átugorja.
Az nRF24L01-nél fixen beállítod a csatornát, magától nem változtatja. Én ilyen beállítási lehetőséget nem láttam az adatlapjában.
A sikertelenül küldött adatcsomagok számát kiolvashatod az IC-ből, ez alapján dönthetsz, hogy másik csatornára állítod-e a kommunikációt. Ennyi.

Az adatlapon én se láttam, de sajnos semmilyen másik titkosítási módot se találtam rajta, ami alapján az adat titkosítva menne át az egyik oldalról a másikra. Ez azért rossz, mert ez alapján úgy tűnik nekem, hogy ha a vonal két végén az eszközök nem kódolják az adatot, bárki lehallgathatja őket, ha rájön, hogy milyen frekvencián megy az adás. Esetleg ha rájön a hekker hogy mi mit jelent a csomagban, akkor akár át is veheti az irányítást a rendszer felett. Ez elég ilyesztőnek tűnik, bár ne legyen igazam!
Ahogy láttam, a Bluetooth és a Zigbee eszközök mind támogatják az AES titkosítást. Az NRF-hez ilyesmit nem találtam.

Nem hiszem, hogy az RF áramkörnek feladata lenne a titkosítás is. Viszont annyira intelligens, hogy adatokat ad arra nézve, hogy eldöntsd, mit szeretnél csinálni vele. Ezt a vezérlésén keresztül teheted, a titkosítást meg végezze az adatforrásod.

Egy kb. 1 dollár árú eszköztől nem várhatod, hogy hardveres AES vagy hasonlóan erős titkosítást is biztosítson. Nem is banki adatok átvitelére találták ki, az adatok titkosítását külön kell megoldanod.
(azt nem tudtam, hogy a ZigBee képes AES-re)

A ZigBee nem csak RF eszköz, komplett adatgyűjtő, továbbító eszköz.

Sziasztok!

Nem tudom ,hogy lehetséges e de a routernek vagy a laptopnak szeretnék ezzel a modullal adatokat küldeni és gépen feldolgozni. Ez a feladat megoldható ezzel a modullal vagy külön wifi modul kell hozzá ?

Melyik végén akarsz routerrel/PC-vel kommunikálni? Ha a rádiós végével, akkor nem mellette, hanem helyette kellene egy WiFi modul. Bővebben: Link

A soros végét viszont egy USB-UART TTL átalakítóval (FT232, PL2303, CP1202 stb) kötheted a laptop valamelyik USB bemenetére.

Bocs az előbb furán fogalmaztam meg a problémát.
Konkrétan arra gondoltam, hogy egy PIC-el mérek pl hőfokot, ezt SPI-n átküldöm a nRF24L01-modulnak ami megcímezi a routert és az továbbküldi a laptopnak.

Szóval ezzel: nRF24L01 meg tudom címezni a routert vagy kell vennem egy wifi modult amit linkeltél és azt hozzákötni a PIC-hez ?

Egyszerűbb egy BT modult használni.

Üdv.
Bővebben: Link
ESP8266
Ez kell neked, kis wifi modul, egész olcsó, és programozható MCU-t is tartalmaz, Flash-el mellette.

Helló!
Most álltam neki a modulnak, és kérdezném, hogy milyen kondi kell és hova?

Üdv. Én csak simán a táphoz raktak egy kondit, és utána megoldódtak a dolgok. Amit itthon találtam legkisebb konditól is működött, tehát nem tudom mennyi a szükséges
Egy nem túl kis kondit, feszültségben hasonlót ha ráraksz, szerintem biztosan megfelelő lesz (ehhez a részéhez én se nagyon értek)

Na most próbáltam ki. Működik.
A fesz regulátor elé-után raktam 100nf kondit, szóval nem külön a modulnak szántam, de így is jó.

Sziasztok!
Mostanában rákattantam a vezeték nélküli fejhallgató kérdésére.
Kipróbáltam az analóg RF-et, Bluetooth-t, amilyen modult meg lehetett venni, de mindegyikkel volt valami bajom, leginkább a zaj.
A mániám az, hogy a set-top-boxból kijövő SPDIF jelből kinyert I2S jelet küldjem át digitálisan. Az nRF24L01 elméletileg át tudja vinni az 1,4MBit-es jelet. Tudom, hogy van audióra külön a nRF24Z1, de abból nem találtam modult, QFN-t forrasztani, meg NYÁK-ot készíteni hozzá nem biztos, hogy menne.
Szóval láttam ezt a kütyüt, tehát meg lehet csinálni: nRF24L01 audio transceiver
A képen valamelyest látható, hogy az nRF24L01 mellett Atmega48 és a túloldalon egy Wolfson ADC (adó) illetve DAC (vevő) van.
Azt nem tudom elképzelni, hogy az Atmega képes legyen az I2S jeleket megfelelő sebességgel venni a DAC-tól, átadni az nRF-nek, a vevőben mindent fordítva, és mindezt úgy, hogy pontosan időzítve adja át az adatot a DAC-nak, különben csúnya jittert kapunk.
Valaki készített/tervezett/gondolkodott már hasonlón? Működhet ez megfelelő minőséggel?

Sziasztok!

2db nRF24L01 modult szeretnék AVR-el feléleszteni. Csatolmányban vannak a forráskódok, RS232-n debuggolok.
Adó:
A payload length 4, kiküld egy stringet és felvillant egy LED-et, majd leellenőrzi az nrf24_lastMessageStatus(); fügvénnyel, hogy sikeres-e. Az első 3 csomagra azt válaszolja, hogy még küldés alatt (0xFF-et ad vissza), a többire azt, hogy sikeresen elküldve.

Vevő:
Payload length 4, leellenőrzi, hogy van-e adat a FIFO-ban, ha van akkor egy LED-et felvillant, RS232-n kiküldi az adatot. Mindig az első 3 paayload-ot érzékeli csak és RS232-n minden payload adatnak 0x0b-t küld ki.

Mi lehet a probléma, valaki zseni rá tudna nézni?

Üdv.
Hirtelen ez jutott eszembe:
uint8_t nrf24_lastMessageStatus()
{
uint8_t rv;

rv = SPI_TransferByte(0x00);

/* Transmission went OK */
if((rv & ((1 << TX_DS))))
{
return 0x01; //ok
}
/* Maximum retransmission count is reached */
/* Last message probably went missing ... */
else if((rv & ((1 << MAX_RT))))
{
return 0x02; //elveszett
}
/* Probably still sending ... */
else
{
return 0xFF;
}
}

Márpedig a datasheet ezt mondja:
MAximum number of TX retrasmits interrupt Write 1 to clear bit. If MAX_RT is asserted it must be celared to enable further communication.

Aszerintem ha itt 1-est olvasol, akkor vissza kellene írni 1-est, hogy később folytatódni tudjon, bár szerintem nem ez lesz a gond.

Amikor olvasol nem kellene flusholni valahogy az adott üzenetet? (erre hirtelen nem emlékszek)

Elvileg magától flusholja, esetleg meg tudnád nézni?
Még csak most ismerkedem a modullal.

Ma valószínűleg nem, esetleg kódot tudok küldeni, ami nekem jó volt.

Azt megköszönném!

Sziasztok!

Kérdésem az NRF24L01 modulokkal kapcsolatban annyi lenne, hogy milyen topológiában tudnak ezek működni?

Nekem arra kellene, hogy van egy master-em ami sugároz és az összes vevő veszi a jelét, amelyiknek szól az meg válaszol a mester felé.
Gyakorlatilag egy rs485 buszt akarok vele kiváltani, hogy rugalmasabb legyen a slave-k elhelyezése.
Tehát a kérdés mégegyszer az, hogy alkalmas-e a modul arra, hogy egy adó szétküld valamit és azt a többi veszi(akár 20db vevő) ?

Igen alkalmas rá, de még mennyire
Azért egy adatlap "átolvasás" férjen bele, hogy tudd mivel van dolgod.

A hamisítványokkal meg vigyázz, csak megbízható forrásból szerezd be!
Hackaday-en már vesézgették a témát

Sziasztok, nekem is küldenétek működő forráskódot nRF24L01 + AVR összekötéséhez? Köszi előre is!

Válaszolok a kérdésemre Itt találtok minta kódot, köszönöet érte Droot-nak:
Bővebben: Link

Valaki próbálta már, hogy mekkora max. sebességet lehet kihozni ebből a modulból?
Ugye az adatlap 1 és 2 MBitről beszél, de ha megnézem, ill. kiszámolom, hogy milyen gyorsan lehet a csomagokat indítani, akkor a kapott érték meg sem közelíti ezt a sebességet.
Ha nincs retransmit egyáltalán, akkor is a PLL lock (130us) és a Toa (32 byte payload esetén) kb. 170us. Ez ugye 300us, ami idő alatt 32 byte-ot küld, és ez még csak az adatlap alapján - nem számolva a CE min. 10us-ot, ill. az IRQ 6us időket. Ez alig több, mint 100kBit/s.
A valóságban ez az idő a logikai analizátoromon 340us, ami korrektnek tűnik, mert az SPI kommunikációt nem számoltam az előbb, ami nálam olyan 36 us.
Miután kikapcsoltam az auto ACK-t, hogy ne kapcsolgasson a modul RX-TX között - gondoltam így a 130us-os PLL lock időt megúszom - akkor sem lett semmivel sem gyorsabb az adás.
Elképzelhető, hogy hamisítvány nRF24L01+ IC van a moduljaimon, de az adatlap alapján is ilyen időértékek jönnek ki.
Hogy a bánatba lehet ebből a chipből nagyobb sebességet kipréselni?

No, későn már számolni sem tudok. Az előző hozzászólásomban kiszámolt sebesség nem 100kBit/s, hanem 100kByte/s, vagyis 800kBit/s, ami már jobb, de azért még messze van a 2MBit/s-től.
Szóval számításaim szerint ez az IC még papíron sem tudja a 2MBit/s sebességet, hacsak nincs valami módszer, amit nem vettem figyelembe.

Nem értelmezel félre valamit?
Szerintem "Air Data Rate" szerepel az adatlapban, ez a jeltovábbítás órajelét jelenti, nem pedig a "payload" továbításának teljesítményét.

Ha így számoljuk, akkor az alábbi jön ki:
Data = 1 byte preamble + 5 byte address + 32 byte payload + 2 byte CRC + 9 bit packet control field = 329 bit
Ez már olyan 1,09 MBit/s. Ha kevesebb address-t meg CRC-t használnék sem közelítené sokkal jobban a 2MBit/s-et.
Egyébként igazad van, tényleg az AirDataRate-tel kell számolni (csak ez kicsit olyan "csúsztatás" az adatlapban szerintem).

Végül csak rájöttem, hogy hogyan lehet a maximális adási sebességet kipréselni ebből az IC-ből. (Nem is olyan ) röviden leírom, hátha valakit még érdekel rajtam kívül.
A baj ott volt, hogy ahogyan az adás beállítása le volt írva az adatlapban, minden csomag adása után elment az nRF24L01+ Standby-I állapotba. Innen adási állapotba visszahozni 130us-ba került, így ezzel a késéssel csak kb. a sebesség felét lehetett elérni.
Tehát azt kellett megoldani, hogy maradjon adási állapotban. Ennek két feltétele van.
1. CE legyen folyamatosan 1, de ez még nem elég, mert az is kell, hogy
2. TX FIFO soha ne legyen üres.
Ez utóbbira jöttem rá kicsit nehezen. Nem elég, ha csak egy adatcsomagot írok be a FIFO-ba, mert akár IRQ-t használva figyelem a FIFO ürülését és azonnal újra írok a FIFO-ba ha elküldte a csomagot, mindig elment standby-ba. A megoldás így utólag pofon egyszerű. Mivel 3 FIFO regiszter van, 3x32 byte-ot kellett beírnom ahhoz, hogy a TX_FIFO tele legyen.
Ezután a programban csak figyelni kell a TX_FIFO_full flag-et, és ha 0, akkor beírunk egy újabb adatcsomagot. Ezzel együtt adáskor nem megy el standby-ba és a 2MBit/s-hoz közeli adási sebesség elérhető.
Tanulság: nézzük át alaposan az adatlapot, mert nem mindent írnak le benne szájbarágósan. (nRF24L01P_Product_Specification_1_0 20. oldal Figure 3. Radio control state diagram)

Köszi, engem is érdekelt, bár mintha valahol olvastam volna hogy az CE-t nem szabad sokáig magasba tartani, de lehet hülyeség volt.
Esetleg azt leírhatnád milyen távolságra sikerült ezt elérned, és kíváncsiság kép milyen procit használtál.
Így akár már hangot is képes továbbítani gond nélkül
Köszi az infót.

Mintha itt a fórumon írta volna valaki, hogy ha adáskor a CE-t folyamatosan 1-ben tartjuk, akkor melegszik az IC, mert a kimenet folyamatosan megy. Logikus is a dolog, bár én még csak -18dBm jelszinten teszteltem, ott még nem melegszik.
Ha belegondolunk abba, hogy ilyen sebességnél viszont (méréseim szerint) 32 byte kiküldése kb. 160us ideig tart, ebből 36 us az SPI kommunikáció, a maradék nagy része a tényleges adat kisugárzása (van még némi idő, amíg az IC összeállítja a csomagot, CRC számítás, de erről nincs információ az adatlapban, spektrumanalizátorom meg nincs, ami 2,4GHz-en működne), így tehát nagyjából az adónak úgy is be kell lenni kapcsolva az idő 3/4 részében. Lehet, a melegedést nem is lehet elkerülni, hacsak nem kis teljesítménnyel adsz. Bár fogyasztási adatokat még nem mértem.
Van még egy PLL_lock bit, amit csak az IC tesztelésére javasolnak, így azt nem próbáltam, de az (is?) azt eredményezi, hogy a kimenetet bekapcsolva tartja.
Mivel csak a legkisebb teljesítménnyel próbáltam eddig, így a távolságot nem teszteltem, de a -18dB-nél a szoba távolabbi részében már voltak problémák. Nem árt azt sem figyelembe venni, hogy az auto ACK ki van kapcsolva ennél a sebességnél, így ha elveszít egy csomagot, akkor azt nem fogja újraküldeni a vevőnek, így fontos adatokat így nem érdemes küldeni.
Proci: én erre STM32F205-öt használok, mert elég gyors, ha valamit még szoftveresen kellene megoldani, ill. van benne I2S pont a hang miatt. Bár lassabb kontroller is elég lenne, mert az nRF max. 10MBit/s-es SPI-t tud, az STM32 ennek a többszörösét.
Most úgy látom, hogy hangot (48kHz, 16 bit) ezzel az IC-vel átvinni elég mazochista dolog, főleg, hogy vannak erre célIC-k is, pl. nRF24Z1 vagy CC8520. A kihívás viszont tetszik.