For some reason I just cannot get any data from my APM2.5 via xbee. Never had any troubles with APM2.
I am connected to the "new wireless port" on APM2.5 via a UartSBee breakout. The two XBee's connect to each other, no problem, however I am receiving zero data from APM. I have scoped the line and it is sending but the TX LED (or RX) is not flashing. I have also tried using a XbeeExplorer breakout, here the LED flashes saying APM is sending out, however nothing is coming through XBee to the GCS (or hyperterminal).
I have tried the usual things of TX&RX being the wrong way around to no avail, and also a different XBee module. Works fine when I USB both of them to a computer on the same breakout boards.
I'm quite puzzled by this. My only possible thinking is that the logic level is not high enough to register as a "1", but I thought APM was 5v and Xbee 3v3 so surely there shouldn't be a problem through the level shifts on the breakout?
I'm currently using the AutoMUX UART0 port on APM2.5, will try switching to UART3 tomorrow but I'm doubtful this will work after scoping the line & seeing the data flowing fine.
Anyone else had similar problems with APM2.5? Any solutions or suggestions?
I have tried enabling UART2 in the code, and soldering the jumpers on the reverse of the board. Still the same problem.
UART is sending out but nothing is being sent over XBee.
Interestingly if I send data from the PC to the APM Xbee, the RSSI lights up as expected, the transmitting XBee RX flashes but the receiving XBee (and the APM) TX/RX does NOT flash at all.
I'm thinking this may be the XBee breakout being the weak link, but I have no idea why?
Are these 2.4ghz Xbee or the 900mhz? I believe the 2.4ghz have *known* issues with supportability. I assume you *are* able to make these devices speak to each other using the X_CTU terminal or range test?
You may consider trying a Saleae or other logic analyzer to verify that data is exiting the telemetry port in the first place. http://www.saleae.com
They are 2.4gig...however I have news.
Having plugges in some spares, different boards, cables, xbees etc etc I get the same problem. Unplug everything and it scopes fine as expected. Plug in the USB explorer and use it as a glorified FTDI it works fine, GCS connects. Plug in any xbee, or unplug the USB, then all of a sudden the zero's are not being driven low enough by a long long way.
With all plugged in, scoping the xbee gives this "not driven low enough" data, however scoping pin 3 of the 2560chip and the line is fine.
With a few more pokes I can conclude Something between the 2560chip and the telemetry port is killing the line when a device is plugged in. I am also now back to using UART0 with the same problem on UART2. Therefore it's the APM that is cream crackered :-(
I know of you poke around the forums you can find several folks that had problems with the 2.4ghz Xbee. I also know in the manual it says the following: "Please note that the DIY Drones team will only support the recommended 900Mhz Xbee modules, so if you use something else please turn the community for help, not the DIY Drones developers."
In general, we recommend 900Mhz Xbee modules, but in some countries 900Mhz is not approved. In those cases you can use 2.4Ghz Xbee modules. In that configuration, we use these Xbee Pro wireless modules. Setup can be a little tricky, so please see the comments below in this manual to see how other people have done it. In particular, we do not recommend the DIY Drones XtreamBee adapter for those modules. Instead, try the Adafruit or Sparkfun adapters. Please note that the DIY Drones team will only support the recommended 900Mhz Xbee modules, so if you use something else please turn the community for help, not the DIY Drones developers.
Which series Xbee are you using? I know the Series can make a difference, the firmware can as well. Which firmware flavor are you using?
Hi, thanks for the info, doesn't look promising.
I'm stuck to 2.4 because of the regulations in the UK.
Using the Pro ZB series 2 with the latest firmware, whatever that is.
It is a hardware issue which we are semi-convinced is not standard in my case. With no load the APM board is able to drive the line properly (bottom image), but with a load attached it cannot (top image).
Thanks for the help though!
I actually struggled to get this to work a year or so ago and randomly tried again with the older MaxStream Xbee FCCID: OUR-XBEE using the Xtremebee on the APM side and the Sparkfun USB shield on the PC side. I was not having any luck with the Digi version that came after MaxStream (they were bought out I think).
One thing I can remind you to double check is that the master / slave switch is in the correct position if you are using the Xtremebee.
For some reason off the top of my head I am recalling that a certain pin does not get pulled in the proper direction (or at all) on some adapter boards. If you have others you may consider that.
There may be *known* issues with the "pro" variant of 2.4ghz if I recall as well...
Glad I'm not the only one with issues!
I've actually just ordered some 3DR 433meg radios anyway. I hear they're better, but more importantly supported fully and link in with mission planner properly. we'll see how they go and I'll use XBee for non-APM stuff.
I'm not surprised about the complaints if it doesn't work...
However, it did work fine on APM2, but not APM2.5. Interesting; I assume the driver for the TTL signal in APM2.5 is pants if it can;t cope with the impedance of a XBee! Not good, not impressed!
I've already sent the board back to be replaced, in the mean time I'm awaiting arrive of the 3DR which should get me up & running.
It could be argued that APM 2.5 is pants, OR that the UartSBee is not good enough for the job? (just like the older sparkfun product) There are no changes to the serial telemetry port between 2.5 and 2.0, just track layout that i could see.
When using a 3.3V signal, less current flows, so you can get away with connecting devices that have nominally lower impedances. If the device connecting is outputing a TTL 5V signal, a lower impedance on the input device means more current. That means the low is going to be higher.
The APM2.0 setup may have just have tolerated that, but it was probably still out of manufactures specifications. 3DR do sell the ExtremeBee adapter which does have fets to do the level shifting (and I would expect it works better).
I have purchased an ExtremeBee because of the issues I have been having, i'll report back if my expectations are fulfilled! :-)
Interesting points raised, thank you all.
I think the heart of the problem has now been identified that the APM2.5 does not have the power in the IO line to drive the XBee (meaning that the setup guide is wrong, or at least misleading, and should be updated for clarity).
A solution is to use the new explorer board which has MOSFET level shifts on it (I've personally not tried this though), or use a different radio.
I received my XtremeBee yesterday and plugged in the RN-XV module at it worked first-time after setting it up.
I think that you need to be careful when connecting 5V signals to 3.3V devices (and vice versa). You need proper level shifting to get a good result. I'm guessing that the UartSBee and also Sparkfun XBee adapters original chose a flexible design that lets you use 3.3V signals, but can power with 5V, if you need 5V signals as well you need to add the level shifting, and that where lots of the complaints come from.
Anyway, it works, for me now, so I'm happy.