SparkFun Forums

[kane21]

Hi guys,
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:

Code: Select all

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.

Cheers,
Kane

[brennen]

Have you put the SPI lines on a logic analyzer or oscilloscope to verify that you're reading the correct/incorrect value from the L01?

[kane21]

Unfortunately I dont have a logic analyzer. I have an old Gould 20Mhz oscilloscope which probably isn't much use either?

[brennen]

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).

[kane21]

Thanks Brennen,
I have the Clock Polarity Select bit (CKP) set as zero.
From the datasheet:

CKP: Clock Polarity Select bit
In SPI mode:
1 = Transmit happens on falling edge, receive on rising edge. Idle state for clock is a high level.
0 = Transmit happens on rising edge, receive on falling edge. Idle state for clock is a low level.

This seems to correspond with the CPOL value you suggest.

However I originally had a problem with the clock edge select bit (CKE) of the PIC, which I'm guessing corresponds to CPHA.
I had it set as CKE = 0, which from the datasheet appears to be what you suggest, but with this I had alot of read/write errors to the module.
Setting it as 1 seemed to fix this and all worked normally apart from the errors I described above.

CKE: SPI Clock Edge Select bit
1 = Transmit occurs on transition from active to Idle clock state
0 = Transmit occurs on transition from Idle to active clock state

[brennen]

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.

[kane21]

Could it be a problem with the power supply?
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.

[kane21]

Well I managed to fix it ....

I was running the receiver on a 9v battery .... a now dead 9v battery ... now back to 0% corrupt packets