So I’ve been writing my own code (assembly for PIC 16F88) for these little wireless devices.
I have them working great, but I have a small problem.
Currently I’m simply loading two bytes into the payload and transmitting (with 2 byte CRC, enhanced shockburst, 250kbps), then increasing the number and sending again.
The receiver is connected via another 16F88 and the received numbers are sent via software UART to the serial port on my computer.
However very occasionally one of the bytes seem to get corrupted e.g:
166 166
167 167
136 168
169 169
170 170
Now I don’t think it is a problem with the serial code/connection, as if I send the received numbers twice (from the receiver to the serial port) the error is printed twice, indicating that this is how the numbers are received at the receiver.
But looking at the numbers where this error occurs, it is always just a single bit that has been flipped
For the example above:
168 = 1010 1000
136 = 1000 1000
Is there anything I could do about this? and how does this get past the CRC etc?
I could always fill the 32 byte buffer with numerous copies and only keep the number that occurs most (given that this only occurs rarely), but this seems a little wasteful.
You may be able to run SPI slow enough to catch it on that scope if you have. You would need the SCK and MISO lines on the scope at the same time (if you have a four-channel scope, putting CSN and MOSI on there would be good, but not absolutely necessary). You would want to basically stop reading SPI immediately when you discovered that you had read an incorrect value in order to leave the bad transmission active on your scope screen.
My bet is what is happening is that you have set up CPOL (clock polarity) and CPHA (clock phase) incorrectly in your microcontroller’s SPI hardware configuration registers. This would be easily visible on a scope, but you should be able to verify it with the datasheet of your microcontroller. CPOL should be set up such that the clock is low when SPI is idle (typically, CPOL = 0). CPHA should be set so that bit reads and writes happen on rising edges of the clock line (typically, CPHA = 0).
In looking at the respective timing diagrams on page 93 of the PIC16F88 datasheet and page 52 of the nRF24L01P datasheet, it looks like you need to set up the 16F88 with CKP = 0, CKE = 1, and SMP = 0. This sounds like what you already have, though. If this is the case, then there’s not much else you can do than try to probe the lines to see what is actually coming across to/from the L01.
I’m using a 5v L78L05 to power the PIC and a separate 3.3v regulator for the NRF24L01 (the 5v reg doesn’t supply the 3.3v reg).
I only had 0.1uf capacitors on hand, but the 3.3v requires a 2.2uf on the output , and the 5v a 0.33uf on the input.
I know I’m probably causing myself more problems here.
Starting up from cold I get good data for about 5 minutes (0% corrupt packets), then the results seem to get increasingly erratic (~30% of packets are corrupt).
I noticed the 5v regulator to the PIC seems to get quite warm, I wouldn’t have thought this would occur as it is only supplying the PIC and blinking an LED very briefly.
Although measuring the output voltage (with a DMM) it doesn’t appear to change.
