SparkFun Forums

[erobot]

Hi,

I have the 315 mhz 4800 bps RF link. I am using two Axon microcontrollers for Tx/Rx. Each Axon is running at 16mhz.

I wrote my own routines for each of the GetByte and SendByte

Here is my SendByte routine

Code: Select all

void SendByte(char c) {
  while (!(UCSR0A & (1<<UDRE0)));  // wait until you are able to send a byte 
  UDR0 = c;
}

Here is my getbyte routine

Code: Select all

int GetByte0(void)
{
    while((UCSR0A&(1<<RXC0)) == 0); // wait until a byte is received
    return UDR0;
}

I was getting transmission problems when sending 55,56,59 ( in hex) .

Code: Select all

SendByte(data1);  //55
SendByte(data2);  //56
SendByte(data3);  //59
SendByte(data4);  //5A

I did some tests of transmission packets and here is my results (all tests were run at 4800 bps)

For the following combinations I the transmission is really crappy and I get less than 300 3 byte packets in 30 seconds.
0,55,56,59,0 with 10ms delay after each packet, with 5ms delay after each byte, with 3ms delay after each byte, with no delay at all
0,55,56,59 with 10ms delay after each packet, with 5ms delay after each packet ,with 5ms delay after each byte, with 3ms delay after each byte, with no delay at all

So far the best I've gotten is this combination :
0,55,56,59,0 with 5ms delay after each packet and 852 correct 3 byte packets in 30 seconds - 28.4 packets per second == 85.2 bytes per second - still pretty crappy

I'm going to experiment with different delay times after each packet.


Datasheets are provided on this page for my receiver and transmitter : http://www.sparkfun.com/commerce/produc ... ts_id=7816

More info on my struggle ( in blog like format) can be found in my thread on SoR Forum - http://www.societyofrobots.com/robotfor ... pic=5541.0

Anything I can do to improve transmission and accuracy?

Thank You,
Eric
narobo.com

[riden]

Do you have any code for a software receive routine instead of the hardware UART? A while back someone posted some oscilloscope pics showing that some receivers can stretch the data waveform, which can be problematic for a hardware UART. I've tried similar transmitter/receiver pairs with the USART on a PIC and they seemed to work well at 2400 baud. However, my final design used a software UART (as I needed the USART to communicate with my PC) and I get a very good 2400 baud data stream. I start with an initialization sequence and then send the byte and its complement.

[erobot]

Do you have any code for a software receive routine instead of the hardware UART? A while back someone posted some oscilloscope pics showing that some receivers can stretch the data waveform, which can be problematic for a hardware UART. I've tried similar transmitter/receiver pairs with the USART on a PIC and they seemed to work well at 2400 baud. However, my final design used a software UART (as I needed the USART to communicate with my PC) and I get a very good 2400 baud data stream. I start with an initialization sequence and then send the byte and its complement.

nope no code for a software receive.
can you post it?

also how good was your data stream and at what distance?
I need at least 60 bytes per second(this means a perfect 60 bytes , with no interference) at a maximum of 50m.

Thanks

[busonerd]

Running serial directly over those transmitters can be problematic. Hook up an oscope / logic analyzer, and you'll see why.

However, if you must do rs232-style-serial, do the following:

Send a bunch of 0x55 / 0xAA bytes, [ 1/2 bits 1, 1/2 bits 0, so AGC can adjust], then transmit your payload immediately after. Something else that might help is to have an 0x1E byte, and then immediately after have a start-of-transmission byte that your receiver is looking to lock in on.

This sorta seems like "voodoo" electronics, but there is theory behind it. Basically, the receiver has automatic gain control, that will adjust such that the output has a roughly 50% duty cycle. Basically, if you're spitting out "1"'s all the time [the default state of a serial link], the receiver AGC will tune down the gain until it sees a 50% duty cycle, which would be noise; so then when you start your transmission, the receiver AGC is too low to see your transmission.

The long group of sync bytes gives the receiver AGC a chance to adapt to a 50% duty cycle transmission, and since you don't look for them on the receive side, it doesn't matter if they get lost / corrupted. the 0x1E byte is to provide a big logical '1' area at the end of the SYNC, which the receive UART will see as a stop bit if its not properly synchronized.

I once did a project using similar transceivers, and my eventual solution was to have 8 bytes of sync before my packet, and have my packet data reed-solomon encoded.

The best solution is to encode your data in a more ASK transmitter friendly form; use something like manchester encoding, and add a big SYNC area at the start of transmission to give time for the receiver AGC to adjust.

Cheers,

--David Carne

[riden]

nope no code for a software receive.
can you post it?

also how good was your data stream and at what distance?
I need at least 60 bytes per second(this means a perfect 60 bytes , with no interference) at a maximum of 50m.

Thanks

Hmmm, I thought that I replied to your post, but I think it got lost somewhere. Here goes again...

I'm mostly a PIC guy and only have done a few projects with the AVR family. The Axon board appears to be using an Atmel chip with four hardware UARTS. The code for a software UART is available if you Google it however.

My packet sizes are in the range of 32-48 bytes (plus sync and complements) transmitted at 2400 baud over a range of 30 meters (about 100 feet) through a couple of walls. I haven't tried going beyond 30 meters. The technique that I used was similar to what David presented. I start out with the sync bytes to allow the receiver's AGC to stabilize and then send a signature string (i.e., "TX") followed by the data stream (a character and its complement). This keeps the 0's and 1's balanced enough for the receiver to perform well.

For my application, I found that I didn't need error correction and the fact that each data byte is followed by its complement helps me determine that I received a valid packet. I use the 432 MHz frequency band and I occasionally receive packets from a neighbor's weather system. However, my transmission scheme effectively allows the receiver to ignore those other transmissions. When both transmitters are up at the same time, I throw out the bad data and wait for the next transmission period. Note also that I do not transmit continously as it would cause interference with my neighbor's weather system and would violate the FCC Part 15 regulations.

You might want to look at the XBee Pro and see if it is a better fit for you given your range requirements.

[Edit - append following text]

The best solution is to ...
Cheers,
--David Carne

Hi, David. Nice to hear from you again!