ps - It's better to post just the relevant code, instead of ALL of it, because it makes it easier for us to just zoom in on the important stuff. But don't abbreviate your code too much, because then we might not see the mistake right next to it

I dont think so. I checked the output from the xbee on the robot and it is correct

Can you post here the output? Or is that the example below?

Quote

25625625625612752525252525252525252525252511127891271271271271271271271271279294127127127127127127127127127127I dont have to say new line everytime I send a byte right? Could it be my UART port that is not working (unlikely)?

You don't need a new line each time. But for debugging purposes, could you add a space between each value transmitted? I can't tell if you are sending a '56', or a '25', etc.

I cant remember exactly, but I think I may have touched a joystich which either read as 52 or 5. I cant remember. I know that the Xbees are properly sending bytes though. I wouldn't waste your time on that. I dont have the output with lines inbetween anymore either. I have tested that multiple times though.

I guess I'm being a bit dump (never used XBee etc) but you talk in your original post about 'PS2 controller over XBee'. Hence I'm not sure what s/w is running on the cpu - ie is it using WebbotLib PS/2 controller code or is the whole XBee thing just sending a serial command to a UART which you are trying to make sense of? If its the latter then connecting straight into HyperTerminal, or others, would show would what's being received.

As always - a copy of your .prj file might help (me!) or at least the PDF output from ProjectDesigner (menu option File|Print).Apologies if it seems dumb - but don't forget like Admin asked re code commenting - you have lived/breathed this project and know what is what and how it all hangs together. We are totally blind and so you must bear with us and help us to 'see' your set up in detail .

is the whole XBee thing just sending a serial command to a UART which you are trying to make sense of? If its the latter then connecting straight into HyperTerminal, or others, would show would what's being received.

This is correct. I connected UART3 to Hyperterminal (where I sent my rprintf). But thats where Im getting numbers like 50, 53, 54. I will post the output I get directly from the Xbee receiver on the robot so you guys can see

Quote

Apologies if it seems dumb - but don't forget like Admin asked re code commenting - you have lived/breathed this project and know what is what and how it all hangs together. We are totally blind and so you must bear with us and help us to 'see' your set up in detail .

Oh I understand completely. That's why I included all my code at first.

So for '256' you are receiving three separate bytes/chars. You will have to write code on your receiver to parse it back into a number (int say).Hopefully your sender either has a delimiter between numbers, or always uses 3 character bytes, otherwise you wont know when one number ends and the next begins. eg is"256123456"parsed as 256, 123, 456 or as 256,12, 345,6 etc etc

-- edit --Alternatively you could change the Arduino code to send them as numbers, not text, but then you could only use numbers in the range 0 to 255 (to fit into a byte)

I was suspecting the problem to be the Arduino code, too, but I wouldn't have figured the above out given the available information in a million years lol

Referring to other questions . . . if it was the wrong baud rate, you'd get random crazy characters, or none at all. As for ground, you need *a* ground connected. I included one for each UART to serve as a reminder and as an extra pin. But any ground on the Axon is ok. If ground wasn't connected, you'd like not get any data at all.

if it was the wrong baud rate, you'd get random crazy characters, or none at all. As for ground, you need *a* ground connected. I included one for each UART to serve as a reminder and as an extra pin. But any ground on the Axon is ok. If ground wasn't connected, you'd like not get any data at all.

Yeah that's what I thought would happen with the bauds and grounds. Thanks a lot for your help Admin. Much appreciated

The other thing I noticed in your project was an output pin E5 called 'Xbee5v'. I presume you are not using this to provide power to the XBee ? That could be bad and blow the pin, or worse, if the XBee needs more power than the cpu can provide. Either use a 5v regulated supply pin or, if you want to turn supply to the XBeee on and off, then you should use the pin to control either a relay or a MOSFET to do it.

EDIT: but i still get occasional buffer overflow and then everything goes haywire. I took out all my rprintfs. Should I increase the buffer to 120 or 130? Can I do this in my code or do I have to go back into Project Designer and do it? Right now I have it set in my c file and in pd to 80/80

Ok I commented out all my rprintfs so that shouldnt be a factor. Small delays in the Arduino code right? Yeah I'm doing a bit of research. I dont understand buffers completely, but I notice a lot of people have like 20/40. I'm using the max baud rate of 38400.

Ok I commented out all my rprintfs so that shouldnt be a factor. Small delays in the Arduino code right? Yeah I'm doing a bit of research. I dont understand buffers completely, but I notice a lot of people have like 20/40. I'm using the max baud rate of 38400.

The reason it goes 'mad' is because, due to the overflow, you have missed one or more characters and so your parsing routine probably gets confused. Its usually a good idea to have some sort of delimiter between the number (ie spaces or commas say) - your parsing routine can then reset itself when it receives a delimiter to expect the start of a new number.

Other alternatives are to not constantly keep xmiting the same info from the Arduino. eg don't keep saying that a button is down/up - just send a msg when the button is pressed and then another when it is released.

Just looking at your code:-The atoi function looks at data in packet - but suppose you've just written a '6' and '4' in there. The answer to atoi will be 64? Not always- if it previously had '256' then it will now have '646'. The '64' being new and the trailing '6' being old stuff.

So you need to make sure that since 'packet' is being treated as a string that you write a zero terminator in there.change

You would be correct if I didn't buffer every number with 0's. but like for 64, I actually send 064. So it always is full with the correct #. You wouldn't know this b/c its on the arduino side of things. Not thats its bad practice, but thats not our problem for the packet response. Helpful though. Sorry I should've mentioned that.

When this odd phenomenon occurs, the red led on the Sabertooth lights up. I dont think this is the source of my problem because I believe that lights due to high startup current. This is very odd. I've had a lot of odd problems!

You would be correct if I didn't buffer every number with 0's. but like for 64, I actually send 064. So it always is full with the correct #. You wouldn't know this b/c its on the arduino side of things. Not thats its bad practice, but thats not our problem for the packet response. Helpful though. Sorry I should've mentioned that.

Yes - but you are storing the three digits in memory and the 'atoi' function keeps on going until it finds something that is not a digit. ie 'atoi' works with a string not an array of characters. A string is the same as an array of characters except that it has an extra zero at the end to makrk the end of the string.

You probably have no idea what data is living in memory immediately after the 3 'packet' bytes.For example: if you hadchar packet[3] = { '0','0','1'} and this was followed in memory by something else say like:char foobar[] = { '3', '2', '1'}then when you do 'atoi(packet)' you would get back 1321 which is probably not what you expect.

Even worse foobar could be a variable and so the atoi may sometimes do what you want and at other times not.

Don't forget - only the compiler know that 'packet' is 3 digits long - at runtime the 'atoi' function just takes its first byte to be the start of a, potentially, infinitely long list of characters.

To fix your code then you MUST declare packet as 4 bytes rather than 3 and make sure that the last byte is a zero (ie the number 0 not the character '0' - ie you can use packet[3]=0 or packet[3]='\0')