Hi all,

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?



Views: 1498

Reply to This

Replies to This Discussion

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?


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 :-(

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!

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.


The problem is the older xbee breakout board design (this includes the one you are using). They are too basic and would benifit from a switching circuit on TX/RX lines to improve the connection impedence. I have had the same issue with a sparkfun adapter and a RN-XV wifi module with the low not being low enough. The XtremeBee adapter does have a switching circuit on the data lines so should improve the situation.

There are lots of complaints on sparkfun about the breakouts they were selling, but now they have a new one that does data line switching see https://www.sparkfun.com/products/11373

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. 

Reply to Discussion


© 2019   Created by Chris Anderson.   Powered by

Badges  |  Report an Issue  |  Terms of Service