I am hoping someone can help me with this...
I have my APM board hooked up to the GPS, magnetometer, XBee and groundstation software. I have connected using my XBee com port at 57600 and everything seems to be working ok, I get what seems to be very good IMU feedback on the HUD and GPS position updates... and I always say "don't fix what ain't broke"
However.... when I look at the console part of the Mission Planner application, there are a bunch of messages about Mavlink Bad Packets being displayed as follows :
Mavlink Bad Packet (crc fail) len 45 crc 61283 pkno 32
Olost 16 pkts 81
20/01/2012 00:04:33 action received:
Request stream MAV_DATA_STREAM_POSITION at 3 hz : currently 0
Ylost 60 pkts 83
Mavlink Bad Packet (crc fail) len 109 crc 25766 pkno 27
qMavlink Bad Packet (crc fail) len 45 crc 10082 pkno 32
ZZlost 65 pkts 88
Mavlink Bad Packet (crc fail) len 45 crc 37560 pkno 32
]lost 107 pkts 91
Mavlink Bad Packet (crc fail) len 45 crc 21200 pkno 32
Elost 149 pkts 94
'`lost 191 pkts 96
Mavlink Bad Packet (crc fail) len 109 crc 36964 pkno 27
BNMavlink Bad Packet (not addressed to this MAV) got 227 45 vs 1 1
BCI?Wlost 196 pkts 101
Mavlink Bad Packet (crc fail) len 45 crc 42789 pkno 32
lost 238 pkts 104
Mavlink Bad Packet (crc fail) len 45 crc 59556 pkno 32
I am now wondering whether this is normal behavior of if I am missing messages and it is affecting the efficiency of my telemetry feedback... perhaps this can be sorted out by a firware update or something else I am missing.
The XBee modules themselves work 100% when wired in loopback and also fine when running the com port test scetch, I have also used then to transmit large amounts of data without using the APM and had no problems so I doubt it is that.
Has anyone else noticed these messages.
I can post the actual HEX data of the messages or even the logic timings from my osciloscope/logic analyser if that would help...
Thanks in Advance for any help...
As a further update to this, I have found that I AM losing some information in the lost packets... I will often not get a GPS fix although the LEDs on the APM and GPS show that I do have one... then when diconnecting over the telemetry port and reconnecting over USB I have a 3D GPS fix right away, I guess the info about the GPS fix was one of the lost packets.
Are the Xbee's very close together and there is a swamping issue? Try moving them apart.
Thanks for the sugestion Peter... tried your suggestion but no luck... I even put them at opposite ends of the property and although the data was transmitting without any problems (good hud feedback) - the packet/CRC erors are still coming through
OK I take my words back... it is definitely realted to my XBee modules...
I disconnected them completely and put a USB to TTL cable/module on the telemetry port and connected to the MP software... no errors at all!
I am using the XBee Pro Series 2 modules (yes I know they are not officially supported) and I suspect that what is hapening is that the Mavlink packets are not arriving in one burst i.e. the RF modules are doing some sort of buffering into their own packets. I think that when the serial data arrives on the serial port (PC side) it may not yet contain all of the bytes required to complete the Mavlink packet as these bytes are in the next RF packet being sent by the XBee, which has not yet arrived. I have tried to disable buffering on the XBees with various parameter changes but no luck, the Packet/CRC errors persist. I may knock together a quick .NET application to try and test this though I suspect it will be difficult to reproduce the same timings in debug mode....
Perhaps it is time to go shopping for some standard, supported 900Mhz XBee modules...
It would be interesting to know if anyone has the Mission Planner Software working with the Pro version of the XBee modules.... and if so what settings are being used on the modules.
same for me, I'm trying two XRF modules, and with them I'v a lot of crc errors. If I use Xbee pro 900 the errors goes away...
After severals hours of test I suppose that the problem is in the packet size or in the radio conversion "inside the module".
With these cheap XRF modules I've a 10% of loss packet, that is 10% at 1 meter and remain 10% at 100 meter.
the packet loss are in communication from APM to PC in MAVLINK, others stream work fine with no loss, for explample if I read or Write 100 waypoints I've no CRC errors, when I finish to read/write waypoints crc errors start again.
I hope my experience may help.
I hope this thread can help : http://diydrones.com/forum/topics/2-4ghz-xbee-suggestions?id=705844...
For series 2 xbees Sparkfun Regulated board is needed.
I've been through exactly the same with my Xbee journey. I kept reading comments like the following in the Digi International Support forums:
...If you are using this as a simple point to point application, is there a reason why you chose the XBee Series 2 radios to do this? Point to point applications may be performed much easier using the XBee Series 1 radios instead, as they use only the 802.15.4 standard and do not rely on the ZigBee protocol with it's accompanying overhead. Unless mesh networking is required, I would suggest working with the Series 1 over the Series 2 for point to point applications.
The extract was taken from this forum post.
So it seems the extra data overhead required for Mesh radio networks has a big impact on a simple point to point connection.
I finally gave in and bought a pair of 2.4Ghz Series 1 Xbees from Martin at Build Your Own Drone. Perfect 100% link every time :o)