I cut a 2x5 ribbon in half and spliced it into those little protoboard wires and stuffed those in the uno spi holes. I did put a tant cap from vcc to gnd, but operation is still flaky.
Everyone seems to be able to use these nordic radios. I can see the spi signals on the scope. Must be doing something wrong.
Are you using a proven library? Or at least, have you followed a proven library when writing your own version for ICC?
In my early experiments with these radios, I learned quickly that you must pull CSN high and CE >>low<< with external resistors. Failure to do so is likely to place the radio into an unhappy state, especially if you're programming over SPI (although I've had trouble even when bootloading over the USART), requiring a power-cycle of the radio before it again behaves.
What are the symptoms you're seeing?
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
 |
What are the symptoms you're seeing?
Benign essential tremor for starters...
Yikes. I didnt even look at the picture. I was so glad that I could see the phone on the usb, and find the picture in the dcim dir, I just sent it. The gist of the photo was that the radios are dangling on 6" of wires, but I do have a tant cap in the vcc-gnd pins on the radios. My tx test just sends 30 bytes in a loop, and the receiver tries to print them out, but I can dangle the 2 radios right next to each other and not get any receive power detect in reg 9 on the receiver. I've tried default ch 2, and someone said ch 55 was quieter because its farther away from 2400MHz. Maybe I could make some sort of adapter to go from the 2x4 on the radio to a 1x8 inline I could use a protoboard.
Channel 82 is the best choice for North America. It is outside (legal) WiFi frequencies, and on the edge of the legal unlicensed 2.4 GHz band. It's also just on the edge of Bluetooth (recent Bluetooth uses adaptive spread spectrum, so any nearby BT radios should quickly avoid any channels you are using.
Six inches of wire leading isn't likely to cause any problems. I've breadboarded with 12" or longer. What is your SPI speed?
Maybe you could post your initialisation code for the sender and receiver...?
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
I've had trouble (the bits were often smeared) with the nRF24L01 using 5" wires when running at the documented max speed (6MHz?). I slowed down the SPI a little (4MHz? it's been a while) and had no trouble after that.
I'm using the slowest spi init 0x53. I'm probably violating some timing constraint. These things work in non shockburst mode where one of em just does tx and the other just does rx? No auto ack?
joeymorin wrote:
Maybe you could post your initialisation code for the sender and receiver...?
|
"Experience is what enables you to recognise a mistake the second time you make it." "Good judgement comes from experience. Experience comes from bad judgement." "Wisdom is always wont to arrive late, and to be a little approximate on first possession." "When you hear hoofbeats, think horses, not unicorns." "Fast. Cheap. Good. Pick two." "We see a lot of arses on handlebars around here." - [J Ekdahl] |
|
I have a feeling that you inadvertently found out that you have clones of the NRF chips. Almost all these modules on ebay or aliexpress or whatever are clones.
And they all have one thing in common: The receiver won't accept a packet twice. It will not move its interrupt pin and it won't acknowledge a packet if it's identical to the one it received just before that.
That means you should always alter at least one byte each time you send a packet, even if the actual message remains the same.
This issue has caused me a tremendous time loss the first time I fiddled with these modules.
I'm using the slowest spi init 0x53. I'm probably violating some timing constraint.
It can only be too fast, not too slow. So I assume this is fine. Did you check the rest of the SPI settings? rising/falling edges and idle state?
Also, have a look at the state diagrams in the datasheet. These will tell you when to change the CE and CSN pins.
-Patrick
Thanks for that tip. I got these at the local surplus place so you must be correct. I had the transmitter sending a couple of a/d readings then a bunch of static payload. I'll rig that to have an incrementing count. Looks like that c source I found polls the status reg rather than waiting for an interrupt.
![20170114_190959[1].jpg](https://www.avrfreaks.net/sites/default/files/forum_attachments/20170114_190959%5B1%5D.jpg){kind=link}