EmbDev.net

Forum: µC & Digital Electronics AVR RF12B problem


von Davide T. (Company: Polytechnic of Turin) (dadomgilmour) Flattr this


Rate this post
useful
not useful
Hello to everybody,

I'm new here. I think that it is a good forum and I hope that you can 
help me.

I have two devices composed as follow:

ATmega328P <--SPI--> RF12B

I created my own library but I have a big problem. The two devices 
(configurated as transmitter and receiver respectively) communicate well 
but the receiver miss a lot of characters. The receiver cannot receive 
up to 3 bytes (excluding the preamble and the synch bytes). It is very 
strange and makes me mad! I tryed a lot of methods to avoid this 
problem, but with no results. I am sure that the problem must be the 
underflow of tx's buffer or the early stop in receiving.

other info:
- I use polling RX (Read the Status, then FFIT control and finally do RX 
byte command for reading the FIFO)
- During TX, SDO signal confirmed me the receiving of all the bytes

example:

TX: AA AA D2 0A 0B 0C 0D 0E AA
RX: 0A 0B 0C

Any suggestions?

Thank you in advance!
Davide

von Thomas B. (nichtessbar)


Rate this post
useful
not useful
overrun of receive buffer... i'm not quite sure with spi, but most avr 
usarts behave this way if receive buffer isn't read fast enough, in my 
opinion 3 bytes is a characteristic value for AVR receive buffer 
overrun...

von Davide T. (Company: Polytechnic of Turin) (dadomgilmour) Flattr this


Rate this post
useful
not useful
Thank you for your answer Thomas!

I think that this problem is not related to SPI's buffer overrun, 
because every time I get the data I wait the SPIF flag and then I get 
the data from the buffer. It should prevent from the buffer overrun. 
Isn't it? I think that the problem is related to the speed of getting 
the data from RX's FIFO.
Now I am using another method: When the reading of RF12B's status 
returns me FFIT flag I force the reading of 8 byte.

With this bad bad method I can see this:

TX(payload): 0x0A,  0x0B,  0x0C,  0x0D,  0x0E,  0x0F,  0x10, 0x11

FROM TERMINAL (RX)

Start!
Inizializzazione terminata! (=end of init)
frame RX:
 0x0A,  0x0B,  0x0C,  0x0D,  0x0E,  0x0F,  0x11,  0x0F,
frame RX:
 0xFF,  0xFF,  0x0A,  0x0B,  0x0C,  0x0D,  0x0E,  0x0F,
frame RX:
 0x10,  0x07,  0x0A,  0x0B,  0x0C,  0x0D,  0x0E,  0x0F,
frame RX:
 0x11,  0x07,  0x0A,  0x0B,  0x0C,  0x0D,  0x0E,  0x0F,
frame RX:
 0x11,  0xC7,  0x0A,  0x0B,  0x0C,  0x0D,  0x0E,  0x0F,

there are a lot of mistakes but I have received more than only 3 correct 
bytes now :)

von Davide T. (Company: Polytechnic of Turin) (dadomgilmour) Flattr this


Rate this post
useful
not useful
NEWS:

TX(payload):
0x10,  0x0A,  0x0B,  0x0C,  0x0D,  0x0E,  0x0F,  0x10,  0x11,  0x12, 
0x13,  0x14,  0x15,  0x16,  0x17,  0x18,  0x19

frame RX:
 0x10,  0x0A,  0x0B,  0x0C,  0x0D,  0x0E,  0x0F,  0x10,  0x11,  0x12, 
0x13,  0x14,  0x15,  0x16,  0x17,  0x18,  0x06,
frame RX:
 0x10,  0x0A,  0x0B,  0x0C,  0x0D,  0x0E,  0x0F,  0x10,  0x11,  0x12, 
0x13,  0x14,  0x15,  0x16,  0x17,  0x18,  0x06,
frame RX:
 0x10,  0x0A,  0x0B,  0x0C,  0x0D,  0x0E,  0x0F,  0x10,  0x11,  0x12, 
0x13,  0x14,  0x15,  0x16,  0x17,  0x19,  0xC6,
frame RX:
 0x10,  0x0A,  0x0B,  0x0C,  0x0D,  0x0E,  0x0F,  0x10,  0x11,  0x12, 
0x13,  0x14,  0x15,  0x16,  0x17,  0x19,  0xCF,
frame RX:
 0x10,  0x0A,  0x0B,  0x0C,  0x0D,  0x0E,  0x0F,  0x10,  0x11,  0x12, 
0x13,  0x14,  0x15,  0x16,  0x17,  0x18,  0x07,
frame RX:
 0x10,  0x0A,  0x0B,  0x0C,  0x0D,  0x0E,  0x0F,  0x10,  0x11,  0x12, 
0x13,  0x14,  0x15,  0x16,  0x17,  0x18,  0x3D,

The problem is related to the last two bytes!

von rfm (Guest)


Rate this post
useful
not useful
you have to send 2 dummy bytes at the end of your payload.

von Davide T. (Company: Polytechnic of Turin) (dadomgilmour) Flattr this


Rate this post
useful
not useful
LAST NEWS:

my code works good! The problem was that I called the TX stop command 
too early!!! :)

Bye :)

von Davide T. (Company: Polytechnic of Turin) (dadomgilmour) Flattr this


Rate this post
useful
not useful
rfm wrote:
> you have to send 2 dummy bytes at the end of your payload.

No, the dummies are not mandatory.

von rfm (Guest)


Rate this post
useful
not useful
If your tx routine is programmed according to the datasheet, then just 
one dummy is enough. Obviously it wasn't done so, and the last bits got 
stuck in the tx buffer. Then the second dummy byte is next best 
solution.

von Davide T. (Company: Polytechnic of Turin) (dadomgilmour) Flattr this


Rate this post
useful
not useful
rfm wrote:
> If your tx routine is programmed according to the datasheet, then just
> one dummy is enough. Obviously it wasn't done so, and the last bits got
> stuck in the tx buffer. Then the second dummy byte is next best
> solution.

What you have said is true! With the 2nd dummy byte all works fine! 
Thank you! I have resolved the problem with a delay, but your solution 
is the best if we think about a wireless sensor network application.

Thank you :)

von rfm (Guest)


Rate this post
useful
not useful
Well, I had the same issues once. Also, the delay may look as a solution 
at first but could cause a unwanted RGIT-IRQ if too long, because the 
RFM wants to transmit another byte and so get the tx buffer filled up 
again.

Cheers.

Please log in before posting. Registration is free and takes only a minute.
Existing account
Do you have a Google/GoogleMail account? No registration required!
Log in with Google account
No account? Register here.