UART error rate?

[bens]

You could try to remove Easy Radio from the picture to see if the problem still occurs.  At any rate, if the Easy Radio's busy pin is only letting you send data at 18.5Hz, that would seem to confirm that you were sending the Easy Radio data before it was ready for it.  So now the next question is, can you increase the loop speed of your data logger by transmitting fewer bytes?  For example, maybe you should send your sensor values as numbers, not as ascii decimal (or at least send them as ascii hex).

The mega644 datasheet (page 315, section 26.2 - DC Characteristics) says that the minimum input high voltage on an I/O line is .6Vcc, so if your AVR is at 5 V, they guarantee that the I/O line will read high from 3 to 5.5 V.

[dunk]

hi Admin,
looks like the Easy Radio modules are the bottle neck all right.

what about using simple single direction radio modules? get 2 pairs on different channels.
providing you only have 2 nodes this way you could transmit in both directions simultaneously on different channels without having to pause transmission to allow data to flow in the other direction.

alternatively, you could check out http://www.zigbee.org/en/index.asp modules.
i haven't used them but maybe they allow for higher data transmission rates?

dunk.

[Admin]

You could try to remove Easy Radio from the picture to see if the problem still occurs.

doh! got to rewire some stuff then . . . I got some bluetooth stuff I can hook it up to, just lazy to resolder stuff . . . Ill try with software for a bit longer because my final project cannot use bluetooth - this datalogger will be underwater and bluetooth doesn't transmit very far in that situation . . . Im operating at 400Mhz right now, and thats still a bit too high (lower the better for underwater). Dunk, this is why I wont be able to use the XBee because it also operates at a too high 2.4Ghz.

For example, maybe you should send your sensor values as numbers, not as ascii decimal (or at least send them as ascii hex).

hmmmm I've been trying to understand and pick apart this rprintf stuff, not much success yet . . . still working on it . . . I blame my mechE-ness for my slow programming skills . . . Ill toy with it for awhile . . . anyone have code to do this that they can send me?

The mega644 datasheet (page 315, section 26.2 - DC Characteristics) says that the minimum input high voltage on an I/O line is .6Vcc, so if your AVR is at 5 V, they guarantee that the I/O line will read high from 3 to 5.5 V.

man I feel dumb, I stared at that page for like 20+ minutes until it made sense . . . All I saw was .6Vcc and I couldn't figure out where you got 3V from . . . till I realized it was .6 X Vcc =3V . . . bllaaaahhh

what about using simple single direction radio modules? get 2 pairs on different channels.

Well, I rarely have data flow the other direction, mostly just for bootloading . . . does the transceiver stop transmitting to check for receive data occasionally?

[4u_allie]

   Okay, So this is my Input and Output chart for my robot: Anybody can use it if theirs doesn't work:
  
 DEC.   BINARY             TURN                          OUTPUT                                         OPERATION
           8 4 2 1    HRT    HLT  SRT   SLT       FW REV                 SPEED
                                                           R           F        SLO   MED   FAS   STO        
 o        0 0 0 0     0       0       0      0       1          0          0       0       0       1             RSTO
  1       0 0 0 1     0       0       0      0       1          0          1       0       0       0             RSLO
  2       0 0 1 0     1       0       0      0       1          0          1       0       0       0             RHRT
  3       0 0 1 1     0       0       0      0       1          0          0       1       0       0             RMED
  4       0 1 0 0     0       1       0      0       1          0          1       0       0       0             RHLT
  5       0 1 0 1     0       0       1      0       1          0          0       1       0       0             RSRT
  6       0 1 1 0     0       0       0      1       1          0          0       1       0       0             RSLT
  7       0 1 1 1     0       0       0      0       1          0          0       0       1       0             RFAS
  8       1 0 0 0     0       0       0      0       1          1          0       0       0       1             FSTO
  9       1 0 0 1     0       0       0      0       0          1          1       0       0       0             FSLO
  10     1 0 1 0     1       0       0      0       0          1          1       0       0       0             FHRT
  11     1 0 1 1     0       0       0      0       0          0          1       0       1       0             FMED
  12     1 1 0 0     0       1       0      0       0          1          1       0       0       0             FHLT
  13     1 1 0 1     0       0       1      0       0          1          0       1       0       0             FSRT
  14     1 1 1 0     0       0       0      1       0          1          0       1       0       0             FSLT
  15     1 1 1 1     0       0       0      0       0          1          0       0       1       0             FFAS
                        

[dunk]

anyone have code to do this that they can send me?

if i don't need all the features of printf i generally just send bytes straight to the UART like this:

Code: [Select]

void uartSendByte(char  data)
        {
         while (!(UCSRA & (1<<UDRE)))             // ensure UART has finished sending last byte.
                {
                wdt_reset();
                }
        UDR = data;                                        // put data in UART output register.

        return;
        }

easy peasy.

dunk.

[Admin]

another question . . .

in the error rate charts, what is the difference between U2Xn=0 and U2Xn=1? The latter sometimes has a lower error rate . . .

[bens]

Setting the U2X register bit causes the UART to run at double speed, which can sometimes make it possible for you to achieve baud rates closer to standard values.  If you take a look at the formulas for calculating baud rate from the value of the UBRR (baud rate) register, the error rates should make sense.

U2X = 0 => baud rate = Fosc / 16 / (UBRR + 1)
U2X = 1 => baud rate = Fosc / 8 / (UBRR + 1)

Error arises from the fact that Fosc is usually not a standard UART frequency, so the baud rate you when you divide Fosc by some number isn't going to be a standard UART frequency.

[Admin]

This problem has come back to haunt me . . .
http://www.societyofrobots.com/robotforum/index.php?topic=2880.msg21085#msg21085

Its breaking my bootloader

Perhaps if I use cts and rts on the EasyRadio that might fix stuff?

I'm going to contact the Easy Radio people right now to see what they think . . .

[rgcustodio]

Hello Admin,

i've been reading the ER datasheet and the previous posts. here are some comments and ideas that might be able to start some new discussion.

i'm assuming here you're using the ERx00TRS modules. these are the transceiver variety, and hopefully the 2nd generation version. i'm assuming you are communicating to your ER enabled robot/system with, obviously, an ER enable PC. the ER might be connected to a USB-RS232 converter or a dedicated RS232 on your PC. i also assume that the software that you are using to transfer/download the "application" is FBOOT17.EXE. wheew too many assumptions!

all page references refer to the ER data sheet.

1) on page 12, End of Data Delay, is your code implementing this delay?
i don't think the downloader you are using knows this, so it might just be streaming data continuously. this would work if your wired since the connection is more stable, ie less erroneous packets, and you have no transfer overhead!
for an ER radio connection, according to page 12, there's a 13.2ms of overhead for each packet (this occurs even if you just transfer one character) so for example you are streaming data, the buffer gets full and the ER transmit, but while transmitting (before the 13.2ms is over!) you begin writing to the ER again, you risk destroying the data in the buffer that is currently being transmitted.

2) on page 12, Buffer Size, i hope you're buffering or sending your data in chunks/blocks that are 180-bytes or less in length.
i assume the 180 buffer is used for both Tx and Rx, since the ER is half-duplex only and there are those warnings of buffer corruption strewn all over the ER's data sheet.
do you still remember the UART_TX_BUFFER_SIZE that you posted? maybe you can try increasing that to 128 to closely match the ER's buffer size.

3) the ER is only half-duplex!
did i mentioned this already? you risk destroying the contents of the receive buffers if you try to send anything through the air while the ER is still receiving (again, based on the data sheet).

4) use Busy Output (CTS) and Host Ready Input (RTS) pins on the ER, as you've mentioned
this will be additional coding and probably additional traces/wires on your board. this could be extra work but incorporating CTS/RTS to your solution to 1 and 2 above is the best solution.


understanding 1, 2, 3 above is very important. If you continuously stream data over the air without the End of Data Delay, you'll be writing over the ER's buffers which will cause loss of data. blocking the data you are sending will also maximize the throughput of your ER since you will be trying to use up most of ER's 180-byte buffer before transmitting, and minimizing the overhead caused by the transmission delay. but everything will be in vain if 4 is not implemented.

try to find the "Easy-Radio Software Guide" mentioned in the data sheet, it might be helpful.

btw, a disclaimer, i don't have any actual experience working with the ER! so all this assumptions and theories could be totally rubbish

Seriously, I hope this helps!

[DomoArigato]

Hey admin, I have the BlueSmirf working on my AVR.  Everything is working great at 38.4k baud rate.  If BlueSmirf will work for you it was pretty simple to get up and going.  I can even connect to it with my phone.  I'm using it for data logging on my computer.  I'd be glad to give you my serial code I use with it.  It ran like 50$.

[Admin]

I feel really bad for causing a double post . . . I had no idea that the two different problems were related . . .

A quick recap of my situation . . . The reason why I needed the Easy Radio module is because it is the lowest frequency transceiver I could find on the market. Why do I want 400MHz? Well, because it's for my robot fish - meaning underwater. Water absorbs more RF at higher frequencies, so to improve range, I need to use lower frequencies - avoiding bluetooth and zigbee and such that use 2.5GHz . . .

I'm really not sure if I should just call defeat, or try to reverse engineer that bootloader written in assembly . . . I spent like 6 months working on an underwater wireless bootloader - a key selling point for my underwater robot . . . but I might just be better off if I change mission parameters . . . I'll think about this for a bit and talk with my group on it too for tomorrow's meeting . . .

I'm thinking I should keep the Easy Radio to transmit data, and also have bluetooth on it so I can reprogram without constantly opening up my waterproof seals . . . I'd have to take the robot out of the water to do this, but alas probably still easier than my other options . . .

Unless you guys know another transceiver that works on a low frequency without a buffer issue?


Anyway, I emailed the guy who makes the Easy Radio modules and says two important things:
1) confirms what you said, rgcustodio
2) says he is making a new Easy Radio version with much more ram

Hello John,
Well that forum post took some digesting, but the latest comments from 'rgcustodio' were pretty much there.
To understand your timing issues (provided you no longer have BAUD issues) you need to understand the process the modules go through to send and receive data.
The ER4/900 modules (02 versions) use a PIC which is limited in its internal RAM to 384 bytes. Therefore, each process (upload to module, transmit over air, receive over air and download to target) uses the SAME 180 Byte buffer, and can only do one operation at a time.
Therefore before sending the next set of data, you need to give enough time for the overair comms to complete AND the target to receive the downloaded data. (The timing for a packet of data is in the datasheet.)
The data rate over air is a constant, and does not relate to your RS232 BAUD rate. This enables two end points with different BAUD rates to connect together without conversion.
To operate the quickest, you could start uploading to the transmitting end at a time where the 'bytes to send' = 'bytes still being delivered'.
(If that makes sense)
FYI, I am close to completion of the 900MHz 03 version of the modules. These now use an ATMEL MEGA168, which has allowed me to use independent buffers for all functions. This means that Upload/Download/Transmit or Upload/Download/Receive can be done simultaneously.
This is a massive step forward to easyRadio efficiency. I am also adding features to allow deliver DURING over air reception, but as this involves a change to the over air protocol, it will be software switched and would not be understood by an 02 module.

If you need any help just ask. If you send me your bootloader code, I could take a look for you as well.
The new 03 module also contains a bootloader for flash upgrades which will include (once I have written it) and overair upgrade facility from the eval software.
Oh yes... Eval software... I wrote it, and it is a bit buggy on the comms. This is because it was written on Borland C++ Builder and unlike MS Visual Studio, they did not provide a serialPort class. I therefore had to write my own, but it hits a couple of cross thread problems and dies a death. The faster the machine, the worse it gets... I think!.
Anyway, also about to be uploaded to the server, is the new eval software, which solves all these issues and adds a bit of transparency to how to understand the modules better. (Not written the help file yet though.. doh!)
Well... that's about it.
You can contact me through any of the means on the signature right at the bottom of this email.
Kind Regards
David Schmider

[dunk]

Unless you guys know another transceiver that works on a low frequency without a buffer issue?

so i know this solution is not ideal but have you considered using 2 one way radio links on separate frequencies?
each one way RF link will obviously not have the buffering issues you are experiencing.
use one pair of RF modules in each direction.

to be honest i'm not sure if you will need to separate the aerials by some distance to stop cross interference or if it will Just Work....

i actually have some of these modules sitting in my bits box that i intended using this way in a long range wireless project but i never did start building that one....
let me know how you get on if you try playing with this.

i suppose you could also keep your existing EasyRadio modules and use another single direction RF link for the bootloader....


dunk.

[rgcustodio]

I'm really not sure if I should just call defeat, or try to reverse engineer that bootloader written in assembly . . .

it's not defeat yet!

you could probably rewrite an open source C bootloader to fix the problem in software [oooh seems awfully familiar ] you've got 4Kb of bootblock to use, that is if your user application isn't using up all of the flash. if you could code tightly and conservatively your bootloader should fit 4k or less.

[Admin]

so i know this solution is not ideal but have you considered using 2 one way radio links on separate frequencies?

I just asked David (the ER guy) if this was a good idea and he said "Two modules wouldn't help".

But he volunteered to look into modifying the bootloader for me

I think he just got a loyal customer and perhaps a tutorial supporting his product

you could probably rewrite an open source C bootloader to fix the problem in software [oooh seems awfully familiar Wink] you've got 4Kb of bootblock to use, that is if your user application isn't using up all of the flash. if you could code tightly and conservatively your bootloader should fit 4k or less.

you have waaaaayyyy too much undeserved faith in my programming skills

[dunk]

I just asked David (the ER guy) if this was a good idea and he said "Two modules wouldn't help".

i don't mean 2 ER modules.
i think the ER modules all have buffers built in.
regular RF modules do not.
i mean 2 pairs of plain RF modules, one in each direction. 2 separate frequencies. no delay between transmit time and receive time.

the only thing i can think that would stop that working is RF interference between the 2.
i'll be traveling most of the rest of this week but next time i'm at home i'll experiment and report back.


dunk.