Replies to This Discussion

Permalink Reply by Dom P on December 4, 2012 at 7:40am

Swaroop and Christian,

I also am trying to get the xbees working in API mode, but I am getting stuck with implementing the code.  I don’t have too much programming experience, but I have been doing a lot of research on API mode.  I am using Mode 1 Xbee 900 Pros.

 

I have a couple of questions.  Are you using the xbee API Arduino library or are you entering the API header and checksum manually in mavlink_helpers.h?  If so, are you using the following for the header: Frame Delimeter, Length, Frame type, Frame ID, 64 bit Destination Address, Reserved, Broadcast Radius, and Transmit Options?  Payload and then checksum would then follow this header.  I noticed that there is already a length and checksum being calculated in _mav_finalize_message_chan_send, but do we have to use a different length and checksum with API mode?

 

Have you had any luck transmitting data from a ground station to the APM while using xbees in API mode and would further modification of the code be required?  Any help would be greatly appreciated!

• ▶ Reply

Permalink Reply by swaroop.hangal on December 4, 2012 at 5:43pm

Hi Dom,

Nope we are not using the arduino lib for xbee. We just added out code in mavlink_helpers.h. Nope, we were using a XBP24 xbee in our case, but it should not matter. You can code these fields in the mavlink_helpers.h. The length and checksum being calculated in _mav_finalize_message_chan_send is for the mavlink packet which you have to enclose inside the API packet. So you will have to calculate your own length & checksum. 

We have not been able to transmit data from GCS to the APM, but we were working on it. QGCS does have the option to use the XBees in API mode.So, fingers Xed....

Hope this helps...

Swaroop

• ▶ Reply

Permalink Reply by swaroop.hangal on November 30, 2012 at 7:25pm

By that sentence I meant that Configure the QGCS side XBee for API...all configurations in the XBee...then leave the "API Enable" to 0/disabled. QGCS is intelligent enough to look for just the MAVLINK packet header inside the Xbee API crap.

We have not tried using the option in QGCS about xbee with API...

Hope this helps...

Swaroop

• ▶ Reply

Permalink Reply by Christian Lopez on November 30, 2012 at 9:07pm

So, I think I am encountering a different kind of problem. I figured out that everything is connected properly, and the router is joining the coordinator's network. However it seems like the transfer rate/ amount of data that the APM is trying to send to the GCS is too much for the XBees in API mode (Or at least that is my conclusion).

Were you successful in getting the standard telemetry link to work with the API mode? Are there settings I am missing that will allow the XBee to transfer the data fast enough?

I get brief, intermittent connections established to QGCS, but not a reliable link.

Also, what does setting API Enable to 0 supposed to do? Thanks for getting back to me.

-Christian

• ▶ Reply

Permalink Reply by swaroop.hangal on December 4, 2012 at 5:38pm

Christian,

Sorry was a bit busy...so cud'nt reply.and hold on...." the router is joining the coordinator's network" means that you are using a simple XB24-B rgt? We were using XBP24 with the vanilla firmware and it works perfectly at 57600 baud rate. There is no such thing as router/co-ordinator in that firmware.  If possible try using the vanilla XBee in API mode.

The API mode 0 is supposed to make the Xbee ignore the API mode requirements on the Tx/Rx packets...but right now as there is just incoming comm @ the GCS and the packets are in API mode, it does not matter.

Hope this helps,

Swaroop 

• ▶ Reply

Permalink Reply by Christian Lopez on December 4, 2012 at 6:17pm

Swaroop,

Thanks for getting back to me- I think the issue is becoming more clear. XBP24 firmware is for Series 1 radios, and I am working with Series 2 radios. I originally bought these because my control scheme to keep the formation together is decentralized, and I wanted a decentralized communication scheme to match (seems like more of a hassle now). So, yea- I am using XBee Pro S2B modules that run at 2.4 GHz.

If I am guessing right, you are using XBee Pro (802.15.4) modules. 

What does that mean for the communication architecture? If you are communicating from a/c to a/c, are the communications passed through a central router? 

I am betting that the extra over-head of setting up the router, coordinator network is what is causing the differences in our results.

Thanks,

Christian

• ▶ Reply

Permalink Reply by swaroop.hangal on December 5, 2012 at 1:26am

Christian,

Yeah...even I am inclined to think in that direction. Our architecture is the peer to peer NW of a/c...they do not go thru a router. Putting a router in between would have introduced a single point of failure in the system.

Regards,

Swaroop

• ▶ Reply

Permalink Reply by Christian Lopez on December 5, 2012 at 11:20am

Swaroop,

Went ahead and bought the Series 1 - I never fully understood the difference between the 2.4GHz modules and the 900Mhz modules that were part of the telemetry kit DIYDrones used to promote. It looks like the peer-to-peer setup is all I needed this whole time. 

Thanks for your help- I'll keep you posted on progress once I get them in.

-Christian

• ▶ Reply

Permalink Reply by criro1999 on December 5, 2012 at 11:37am

it depends of your uplink (TX) or downlink (video RX) frequency. it is better to avoid having same frequency on all the links in order to avoid interferences.

Usually, 2.4GHz has a shorter range (higher frequency means lower length of wave and vice-versa) and cannot penetrate buildings, trees. But is more accurate.

900MHz could have a better range (because could penetrate buildings or trees or other obstacles on the LOS), but less accurate.

• ▶ Reply

• ‹ Previous
• 1
• 2
• Next ›
• Page