telemetry with Xbee

swangy · Post by **swangy** » Tue Sep 11, 2012 5:20 pm

Hi guys, been putting together a multiwii now for over a year

finally got it semi-working though it flips over whenever i start increasing throttle, so i wanted to put an Xbee on it to watch the telemetry over the GUI.

i have tested it and have the two connect wireless and transmitting serial data from one arduino to another without problems, but when i plug it into the arduino mounted on the frame with multiwii 2.1 on it, nothing comes through when i start the GUI on the other end. I've gone as far as making the PC-end xbee a Coordinator, and the quad-side xbee an end device..

i've looked around and theres really no description of how to set things up? any heads up or help would be appreciated.

copterrichie · Post by **copterrichie** » Tue Sep 11, 2012 5:35 pm

To my understanding, the GUI communicate at 115200 and I believe the xbee is at 5600, I could be wrong about that however, that would be the thing to check first.

Hamburger · Post by **Hamburger** » Tue Sep 11, 2012 6:13 pm

Right.
1. Baudrate
2. Rx tx wires crossover. or not.

Th0rsten · Post by **Th0rsten** » Tue Sep 11, 2012 6:24 pm

But this will not help if a motor or a prop is in the wrong position = it will flip on takeoff.
The GUI will always show correct behavior.

swangy · Post by **swangy** » Tue Sep 11, 2012 7:37 pm

ok, both xbees are set to 115200 before i plugged it into the Arduino mini
tx on mini to Din on xbee
rx on mini to Dout on xbee confirmed...
i get the wireless light link, but GUI just sits there

so i plugged the wired FTDI cable in and looks like there's lots of vibration noise on the sensors...
also with a quadX config, left back and front right motors are throttling slower than the other two... sounds like ESC issue?

as for flipping, i double/triple checked the rotor and motor orientations.. will quadruple check

when i get the chance i'll post vids of the GUI and the quad flipping over :/

doughboy · Post by **doughboy** » Tue Sep 11, 2012 7:42 pm

first, make sure your xbee is working by running the range text in xctu. use 115200 baud rate if it is not already set to that baud rate.
then it should work transparently (as if it is a wired conneciton) when you hook it up to the FC.

swangy · Post by **swangy** » Wed Sep 12, 2012 2:46 am

ok, so not sure if it matters, but i've got the series 1 not the series 2 (https://www.sparkfun.com/products/8664), so i'm not sure how to get the range test working on it - i tried physically shorting the rx and tx pins with a wire on the remote xbee but no results.

i can hook up a transmitting arduino over one xbee, send a looping string over the wireless connection and receive the results on the other xbee listening over serial port at 115200 on laptop it works just fine
but when i move that same transmitting xbee to the quadX and run the GUI from the laptop, i can see the laptop xbee transmitting and the Tx light flickering, but then nothing...

anyone else got any other ideas what bone headed thing im doing wrong?

swangy · Post by **swangy** » Wed Sep 12, 2012 6:56 pm

interestingly, i uploaded this code into the mini on the frame and the xbees send this stream over just fine, and i see it on laptop terminal.

when i replace it with the multiwii code, nothing...

Code: Select all


#include <SoftwareSerial.h>
 
SoftwareSerial xbee(0, 1); // RX, TX
char c = 'A';
int  pingPong = 1;
 
void setup()  {
   Serial.begin(115200);
   Serial.println( "Arduino started sending bytes via XBee" );
 
   // set the data rate for the SoftwareSerial port
   xbee.begin( 115200 );
}
 
void loop()  {
  // send character via XBee to other XBee connected to Mac
  // via USB cable
  xbee.print( c );
 
  //--- display the character just sent on console ---
  Serial.println( c );
 
  //--- get the next letter in the alphabet, and reset to ---
  //--- 'A' once we have reached 'Z'. 
  c = c + 1;
  if ( c>'Z' ) 
       c = 'A';
 
  //--- switch LED on Arduino board every character sent---
  if ( pingPong == 0 )
    digitalWrite(13, LOW);
  else
    digitalWrite(13, HIGH);
  pingPong = 1 - pingPong;
  delay( 1000 );
}

doughboy · Post by **doughboy** » Wed Sep 12, 2012 9:11 pm

I tested xbee on multiwii yesterday and could not get it to work as well
xbee works on arduino as is, even without using software serial.

I have been using xbee on my aeroquad board and it works fine. I know they set baud rate on the arduino to 111111 but keep it at 115200 on the configurator. So I tried setting baud rate on multiwii to 111111, and only got it to connect for a few seconds then connection dies. It would be nice to get xbee to work on multiwii.

swangy · Post by **swangy** » Thu Sep 13, 2012 3:18 am

so has anyone actually gotten the xbee to work with multiwii or is it just hearsay and presumptions?

doughboy · Post by **doughboy** » Fri Sep 14, 2012 6:31 pm

viewtopic.php?f=7&t=1364

I'm sure it can be done. I'll experiment with it some more as I want to use my xbee.

swangy · Post by **swangy** » Sat Sep 15, 2012 4:08 am

yea, all comments i've seen that successfully used xbee have been with the Pro models.. nothing on the xbee 1s...

keep me updated, would love to hear if you're successful.

doughboy · Post by **doughboy** » Fri Sep 21, 2012 11:50 pm

ok, I studied the multiwii code a little bit, and it uses its own home rolled uart code.

this
static void inline SerialOpen(uint8_t port, uint32_t baud) {
uint8_t h = ((F_CPU / 4 / baud -1) / 2) >> 8;
uint8_t l = ((F_CPU / 4 / baud -1) / 2);

I think is incompatible with xbee. the standard arduino library is 100% compatible with xbee.

whoever said they got xbee working with multiwii, is probably using a very old version of multiwii, when it was using the standard serial library that comes with arduino.

I don't undertand the uart registers enough to figure out how to make it compatible. but I think it may just be a matter of modifying the calculation of h and l.

PatrikE · Post by **PatrikE** » Sat Sep 22, 2012 12:53 am

I can't get it to work with my APC220.
Probably same problem...

doughboy · Post by **doughboy** » Sat Sep 22, 2012 1:41 am

that calculation is for the UART prescaler.
If you substitue baud 115200 and f_Cpu 16000000, you get 16 (using integer calculation).

the standard calculation is
(((F_CPU) / 8UL / (baud)) -1UL)
which gives you a prescale value of 16.

Now I know for a fact in Aeroquad, they use baud rate of 111111 to get it to work with xbee. And I know that is true because I have an aeroquad FC and I am using xbee with it just fine.

If you use 111111 baud in the standard calculation, you get a prescale value of 17. you get 17 also with the multiwii calculation. I tried this and it does not work. so I'm not sure yet how to get around this to get wireless telemetry to work.

KaiK · Post by **KaiK** » Sat Sep 22, 2012 7:05 am

The APC220 works transparently on current Multiwii here. Just set the APC220 to the max. Baudrate (56000) via its software config tool and modify Multiwii Serial0 Baud to the same rate...

doughboy · Post by **doughboy** » Sat Sep 22, 2012 7:31 am

It works probably due to using the lower baud rate. I'll try to lower the xbee baud rate.

kaik, I take it you change the multiwii gui baud rate to 56000 also right? can you describe how you changed the baud rate? it is hard coded in the program to 115200.

doughboy · Post by **doughboy** » Sat Sep 22, 2012 8:21 am

I undid all my changes and ran the program and this is the error I am getting

invalid checksum for command 240: 96 expected, got 224
<240 30> {150302315030238545128161571112812820845142080701010040250100128128128} [224]
––U-€€€-PF
d(úd€€€
invalid checksum for command 113: 207 expected, got 79
<113 10> {16128321281281284128128128} [79]
€ €€€€€€
invalid checksum for command 114: 112 expected, got 240
<114 2> {128128} [240]
€€
invalid checksum for command 100: 51 expected, got 179
<100 7> {2113128128128128128} [179]
Ó€€€€€
invalid checksum for command 104: 120 expected, got 248
<104 16> {2323232323232323128128128128128128128128} [248]
èèèè€€€€€€€€
invalid checksum for command 106: 63 expected, got 119
<106 128> {1063677331281071073677624109128128128128105367762311012512812816367719082541281281281281281281281282463677190710021131281281281281281793677628115910113651612111367762101012209128128112811281281281863677190181021281281281281282128128255255128128128128128128128128118367719016103128128128128128128128128128128128128128128128128} [119]
j$M!€kk$M>m€€€€i$M>n}€€$M¾þ€€€€€€€€ö$M¾dÓ€€€€€³$M>s
o$M>
eÜ €€€€€€º$M¾f€€€€€€€ÿÿ€€€€€€€€v$M¾g€€€€€€€€€€€€€€€€
invalid checksum for command 104: 120 expected, got 184
<104 16> {2323232323232323128128128128128128128128} [184]
èèèè€€€€€€€€
invalid checksum for command 106: 246 expected, got 128
<106 128> {10636773312810710736771904109128128128128105367762311012512812816367719082541281281281281281281281282463677190810825425525425512812812812810036776271002113128128012812817936776281159101136516121113677621010124491281281128112812812814636771901810212812812812812822552551281281281281281281281281281281183677624109128128} [128]
j$M!€kk$M¾m€€€€i$M>n}€€$M¾þ€€€€€€€€ö$M¾lþÿþÿ€€€€d$M>dÓ€€

PatrikE · Post by **PatrikE** » Sat Sep 22, 2012 9:13 pm

KaiK wrote:The APC220 works transparently on current Multiwii here. Just set the APC220 to the max. Baudrate (56000) via its software config tool and modify Multiwii Serial0 Baud to the same rate...

I can get MWii to run Perfect with APC220 @57600 and MultiWiiWinGUI.
But only partial with the Processing Gui!
I think It's requesting to fast or something... :?:

doughboy · Post by **doughboy** » Sun Sep 23, 2012 12:57 am

PatrikE wrote:
KaiK wrote:The APC220 works transparently on current Multiwii here. Just set the APC220 to the max. Baudrate (56000) via its software config tool and modify Multiwii Serial0 Baud to the same rate...

I can get MWii to run Perfect with APC220 @57600 and MultiWiiWinGUI.
But only partial with the Processing Gui!
I think It's requesting to fast or something...

Unless you changed the baud rate on the processing GUI, it won't work because the baud rate is hard coded to 115200.
You can change it in the source and run it in processing IDE. You can then export to create the exe and call that the 57600 baud version.

PatrikE · Post by **PatrikE** » Sun Sep 23, 2012 8:04 am

Iwe already changed that but I can't get it to run anyway!
Rx led i on arduino is blinding but not TX.
Some parts in gui works but not much.

Win Gui works ok.

doughboy · Post by **doughboy** » Sun Sep 23, 2012 9:24 am

I'm trying to get a baseline timing of the signals using a logic analyzer.

signal coming from FC is 93.5us per character

signal coming from PC is 86.75us per character

8N1 serial uses a 10 bit frame. 1 bit is 1/115200 seconds or 8.68us per bit, so 10 bits should take 86.8us.

as you can see, the PC timing is very close to 86.8us. FC timing is off by 6.7us per character.

I am guessing if you run the half the speed (57600), the error is twice as much and the gui is unable to understand the data. the win gui may be more forgiving.

this is the cycle time for each set of commands. its about 50ms, or 20hz.

I'll take the timing with xbee connected tomorrow. maybe try to adjust the FC timing to make it closer to 86.8us.

doughboy · Post by **doughboy** » Sun Sep 23, 2012 10:17 pm

I monitored the signal on the xbee/FC side, and I can see the initial request/response exchange was perfect. But starting with the first command of the next set of request, the FC received an invalid command 22.

the capture below shows FC received a command 22, and responded with error unknown code 22. That command should have been 100, MSP_IDENT.

doughboy · Post by **doughboy** » Sun Sep 23, 2012 11:34 pm

I have confirmed the problem is due to the gui requesting too many bytes at once than the xbee can handle.
I did a loopback test on xbee and it works on 128 bytes at a time, I tried 256 and it times out.

the gui sends a series of commands at a time, instead of doing request-response-request-response....

this line is the culprit
if ((time-time2)>40 && ! toggleRead && ! toggleWrite) {
time2=time;
int[] requests = {MSP_IDENT, MSP_MOTOR_PINS, MSP_STATUS, MSP_RAW_IMU, MSP_SERVO, MSP_MOTOR, MSP_RC, MSP_RAW_GPS, MSP_COMP_GPS, MSP_ALTITUDE, MSP_BAT, MSP_DEBUG};
sendRequestMSP(requestMSP(requests));
}

if it can be spaced out to match the xbee capacity, then it should work.
most of the commands there don't need to be sent repeatedly, like MSP_IDENT, MSP_MOTOR_PINS, etc. Those values won't change.

I tested it to send only one command, and the xbee does not hang and it works fine. I think this area needs to be updated to get xbee to work.

doughboy · Post by **doughboy** » Sun Sep 23, 2012 11:59 pm

in order to work with xbee, either the gui must be enhanced to support it by slowing down the requests, or you need to write your own client to do that. the serial LCD used for configuration and telementry don't have this problem, as they only deal with smaller packets of data. I will test hooking up the xbee to the LCD and see if the configuration and telemetry works.

on win gui where you can control the refresh rate, if I set it to 1 hz, the connection works a bit longer, but eventually stops as well.

doughboy · Post by **doughboy** » Mon Sep 24, 2012 12:31 am

ok, xbee connection works at 9600 with wingui, I have not tested any baud rate in between.

you can see there are a few packet errors, and win gui seems to be able to recover. processing gui still does not work at 9600, I'm pretty sure due to the way it sends all the commands in series.

copterrichie · Post by **copterrichie** » Mon Sep 24, 2012 2:37 pm

I know this is a little off-topic but it seems very interesting: http://www.youtube.com/watch?v=vrnoCCYSC7g

doughboy · Post by **doughboy** » Mon Sep 24, 2012 5:36 pm

copterrichie wrote:I know this is a little off-topic but it seems very interesting: http://www.youtube.com/watch?v=vrnoCCYSC7g

it is still related and confirms what I said. you need to write your own program or modify the way the mw gui use of serial commands.
I'm sure mw gui was designed without xbee in mind, and that is fine. right now, the way it is coded, it blindly sends the same 12 msp commands, whether it is needed or not, like gps data if you don't have gps, every 40 milliseconds (and one command every 20 ms), regardless of whether any or all previous commands got a response.Granted xbee is unable to keep up at 115200 baud, it can however work at that speed with smaller chunk of data. I think perhaps there should be a streaming command (similar to LCD telemetry) where the FC just periodically sends status, sensor data. right now the mwgui seems heavy on the bandwidth.

doughboy · Post by **doughboy** » Mon Sep 24, 2012 6:59 pm

I found this post
http://forums.digi.com/support/forum/vi ... 7255#21770

apparently, xbee transmission problem at 115200 is not a new issue. you find tons of post in digi forum about this.
from the article, the best solution is to use 111111 baud rate. I tried that and result was not any better. I'll try that again. then I'll try using 2 stop bits.

swangy · Post by **swangy** » Mon Sep 24, 2012 8:11 pm

doughboy, that's hard core indepth analysis of the transmission failure...!

doughboy · Post by **doughboy** » Tue Sep 25, 2012 2:25 am

ok, after struggling with this over the weekend, I finally am able to get mutiwiiconf to work with xbee.
only after skimming through a few of the thousands of posts on digi forum, I learned that there are two ways to get xbee to work at 115200.
first is to set the host to use 111111 baud rate, second is to use 2 stop bits. For mutiwiiconf case, I have to do both.

On mutiwiiconf source, you need to edit line in method InitSerial
(note that you need to download processing IDE from processing.org. get version 1.5.1.)
from
g_serial = new Serial(this, portPos, 115200);
to
g_serial = new Serial(this, portPos, 111111,'N',8,2.0);

Then on multiwii source file, config.h,
from
#define SERIAL0_COM_SPEED 115200
to
#define SERIAL0_COM_SPEED 111111
adjust the above accordingly if you are not using serial port 0 (on mega)

Serial.ino is already configured for 2 stop bits. I don't know if that is accidental or intentional, but there is no need to change anything.

I tested this on mutiwin gui, and setting the baud rate to 111111 pretty much works, but I do get a few packet errors. I suspect if it is changed to use 2 stop bits, it will be error free as well.
One thing to keep in mind, if you get errors while testing, you will need to reset both xbees by unplug/plugging the one connected to the PC, and just reset the FC board.

I have to test this a little bit longer to determine the reliability. but so far so good. I don't think you can get the same speed and distance using any other wireless telemetry method like bluetooth or apc220.

swangy · Post by **swangy** » Wed Sep 26, 2012 3:41 pm

got it recompiled, will try to upload to hardware when i find some time.

for those not familiar with Process, within the sketch folder you've got to create a <sketch>/libraries/controlP5/library/ folder and rename controlP5.jar_ to controlP5.jar

doughboy · Post by **doughboy** » Wed Sep 26, 2012 5:10 pm

swangy wrote:for those not familiar with Process, within the sketch folder you've got to create a <sketch>/libraries/controlP5/library/ folder and rename controlP5.jar_ to controlP5.jar

I think I did that at first, then I realized there is an import library feature in the Processing IDE menu that will do all that for you. It is a veery slooow download. And you have to copy the mw config pde source file into a folder with same name under the processing sketch folder (should be under your documents folder). once tested to work, you can do a file/export application to get the exe. you can ignore the 64 bit version, as it does not work due to rxtx dll is only for 32bit.

swangy · Post by **swangy** » Thu Sep 27, 2012 1:33 am

so multiwiiconf compiles and runs but when i actually hook up the xbee and try to activate the port on the top left, it throws java errors about invalid parameters. it doesnt like 111111, but will run just fine if i replace with 115200.. what other voodoo did you do?

doughboy · Post by **doughboy** » Thu Sep 27, 2012 2:13 am

g_serial = new Serial(this, portPos, 115200);
to
g_serial = new Serial(this, portPos, 111111,'N',8,2.0);

remember, when you run into errors, you must reset the xbee by unplug/plugging the one on pc, and resetting the FC before you start your next test.

make sure you changed the FC baud rate to 111111 as well.

get it to work with wired connection first. the 111111 baud rate will work in wired connection. once that is working, switch to xbees. I've been using xbee connection only since monday when I got it to work.

shufflez · Post by **shufflez** » Thu Nov 01, 2012 12:50 pm

Hi all,

Can I use Xbee on Serial3? My Crius Extend Board has Serial1-3 (Serial1 has no break-out

).
I don't have a need to reprogram via Xbee, only need reading telemetry.
Wired connections on 115200 (either via onboard USB or FTDI) work flawlessly.

Thanks for the assistance, again and as always!

P.S. I'm also running an Crius I2C OLED, which might interfere with Telemetry on Serial3?

Hamburger · Post by **Hamburger** » Thu Nov 01, 2012 2:22 pm

if with telemetry you mean MultiWii's telemetry output, then yes, it will interfere. With current code, you can compile in only exactly one version of the output routines at a time; either for the OLED or to a serial device (possibly via a wireless transmitter like BT, xbee, etc.)

shufflez · Post by **shufflez** » Thu Nov 01, 2012 8:18 pm

Ok, so I got the Xbee's working on SER3 now with latest Dev version.

OLED display only shows 'snow' when it's connected during power-on. When I plug in the I2C connection afterwards, it shows the bootlogo and MWC version nicely.
No telemetry displayed though, although I do believe I have the right Define active.

Contrary to my previous post; want to use I2C OLED for OnScreenDiagnosis (Telemetry) and Xbee for GUI (PID tuning and later waypoint-stuff).
Xbee's are working nicely on SERIAL3 when OLED connected. But screen doesn't show anything

I2C and Serial are different procedures as far as I can read the code, that would allow multiple output routines?

Hamburger · Post by **Hamburger** » Thu Nov 01, 2012 8:44 pm

shufflez wrote:I2C and Serial are different procedures as far as I can read the code, that would allow multiple output routines?

right and wrong. Read my earlier post about output routines again.
You can do both
- use serial (cable or xbee or BT) to connect the GUI
and
- use the OLED with proper defines in config.h for telemetry.
in a single sketch.

Your i2c/oled symptom with needling late plugin of oled is weird. All my oleds work while constantly soldered.
Maybe try without logo?
You have to activate the telemetry page you want to see, either with stick combo or as initial automatic setting via telemetry.step.auto

shufflez · Post by **shufflez** » Fri Nov 02, 2012 10:46 am

Thanks for your replies Hamburger!
At least Xbee works!

Don't want to hijack this thread, but OLED still has weird behaviour, so I'll open another thread for that

kavehslt · Post by **kavehslt** » Tue Aug 06, 2013 11:08 am

hi everyone

i connect my xbee pro module to my promini board and i receive data without any problem in 19200 baud rate BUT

!!!!

would you mind explaining for me how is it possible to send this volume of data (256 byte) online and the refresh rate of control loop doesn't change!!

for sending this data cpu should spend time and why doesn't happen any problem for control loop time?!!

Hamburger · Post by **Hamburger** » Tue Aug 06, 2013 9:18 pm

Mwii transmit code uses interrupts.
Your xbee may do some buffering internally.
Do you run the serial between mwii and xbee at 19200?

kavehslt · Post by **kavehslt** » Tue Aug 06, 2013 10:09 pm

Yes
I used 19200 baud rate and by xbee pro module i transmit data in 3550 m without any problem with no error.

I know the cpu using interrupt for sending data but it should wait to transmitting be complete and then running the next step. during this time cpu is busy and i want to know why the control loop time don't change?

Really i want to know when i used the serial port to send and receiving data is there any problem for flying or no? logically motor pulse and control loop time should change.

TNX

dhrvjsh · Post by **dhrvjsh** » Tue Jun 23, 2015 1:59 pm

I tried changing baud rate to 111111 in the source code and i the flight controller
but still it didn't work

can you please provide me the compiled version of the MultiConfig

i am using arduino uno as FC with mpu6050 as sensor

Cereal_Killer · Post by **Cereal_Killer** » Tue Jun 23, 2015 6:05 pm

dhrvjsh wrote:I tried changing baud rate to 111111 in the source code and i the flight controller
but still it didn't work

can you please provide me the compiled version of the MultiConfig

i am using arduino uno as FC with mpu6050 as sensor

111111 is not a valid baud rate. What the the stock rate of the Xbee module you've got? Make Multiwii match that (and the GUI too)

There are to many settings, we can't provide you a ready to flash code file, there are just to many variables.

dhrvjsh · Post by **dhrvjsh** » Sun Jun 28, 2015 7:16 am

i am using multiwii with arduino uno,and i'm unable to connect xbee as telemetry with the uno board. The Xbee that i'm using is xbee pro
So pls help me out with it as my quad is not flying properly as all the motors are not starting as the same time even they are calibrated

Cereal_Killer · Post by **Cereal_Killer** » Sun Jun 28, 2015 4:41 pm

Dude your problem is definitely the baud rate, what is the factory set baud of the Xbee module?

Cereal_Killer · Post by **Cereal_Killer** » Sun Jun 28, 2015 4:49 pm

30 seconds on Google found this...

Factory baud on Xbee is 9600, that's to slow for telemetry / config changes. You'll need to configure BOTH Xbee modules to something higher (remember it MUST be a valid rate, not some random number). See this tutorial for how to.
http://m.instructables.com/id/Changing-Xbee-Baud-Rates/

I always prefer to have my telemetry systems run at 115200, but set it to whatever you want. Then (if you choose a speed other than 115200) go into the config.h file and change multiwii's comm speed to match. Then (after doing all that) try to connect. Remember if you use a different speed than the 115200 the GUI expects you'll need to change the GUI's comm speed too before pushing connect.

We like helping people out man, and I'm not telling you we won't, but you've gotta be willing to help yourself too- that's very literally the first result off google...

dhrvjsh · Post by **dhrvjsh** » Sat Jul 11, 2015 6:44 pm

I had tried everthing but xbee is not working as telemetry in multiwii running on arduino uno