Hi Steve,
We have worked with the AC4868-250 aerocomm modems since 2006. They work like a charm up to many kilometers away, ... however:
First of all we think they interfere quite heavily with the remote control system. Reliable RC range is often reduced to not more than 300 meters. We believe this is due to ground plane oscillations as 1 single copper wire between the rc-ground and the aerocomm ground is sufficient to cause this RC-interference. In our slightly larger UAVs we use 2 battery packs for longrange/autopilot and separate RC with optical isolation. Then the RC works up to 700 meters again.
Then the aerocomm protocol devides the data into packets. The so-called packets are defined as bytes sent with less than X (configurable) ms pauses in between. The 28k data rate can only be obtained with the proper timing which is not easy to obtain. PPRZ sends many small messages while the aerocomm (amazingly) tends to be more reliable/efficient with fewer larger packets. On our larger UAV we ended up using a different telemetry and control protocol that sends only 4 (slightly larger) messages per second. Setting the retry attempts (in the modem config) to zero together with this 4Hz update rate gives perfect downlink and uplink.
The default settings allow for a maximum of (if I remember correctly) about 15 packets per second (or 30 in half dulpex mode). Especially if the "RETRY" setting is set to more than 0 (default is 3), the modem will retransmit any (older) failed packet instead of transmitting newer ones, building up delays and loosing even more data. Especially in broadcast mode these retries are devastating for the total throughput.
So I propose to group the paparazzi messages together (give them a multiple of 0.25 second in the telemetry.xml), reduce the amount of data to less than 1000 bytes per second and send groups of about 300 continuous bytes (no delay) 4 times per second, over a full duplex configured modem (to allow the important uplink) with a packet delay of > 50-100 milisecond at 56700 baud, no retransmit retries (cretainly not in broadcast mode) (GCS does most of the critical retries).
Note that the so-called aerocomm packages are very seldomly filled a 100 percent so the achievable data rate is much lower than the 28k reported in the data sheet unless your byte timing is perfect. With aerocomm, everything has to do with timing.
Good luck with it!
Christophe
-If you can use the hardware flow control, you should be able to increase the troughput reliably, however with a tiny1.1 that is not a simple thing to do.
-Thanks you for keeping us updated on your progress...
---------- Forwarded message ----------
From: "address@hidden" <address@hidden>
To: address@hidden
Date: Fri, 16 May 2008 21:02:28 GMT
Subject: Re: [Paparazzi-devel] Aerocomm modems
I used the 900MHz version a few years ago and the problem you describe sounds familiar, though I don't recall the solution.
The 868 is used in the old twinjet on the CVS, you may want to try to duplicate that configuration.
It could be that you are just exceeding the bandwidth, try reducing the number of messages and/or their frequency. From conf/conf.xml you can call conf/telemetry/minimal.xml instead of default.xml to test, and then you can make your own file if that's the solution.
Most of us are running 56K links and thus the message structure and rates have evolved in that direction. You'll need to reduce the data quantity a bit to run reliably at 28K (or 14K full duplex)
-- Steve Joyce <address@hidden> wrote:
Hi,
I'd like to hear from someone who has experience with Aerocomm modules
for the paparazzi datalink. Specifically which firmware settings to use
on the modules (RF delivery mode, interface baud rate, any handshaking
etc.).
Right now, I have my datalink working with AC4868-250 modules, but not
very reliably. I get lots of receive errors, messages are often missed,
and the uplink always requires several tries for commands to get
through. I don't think it is an antenna/range problem because the
behaviour is the same in the lab and the Aerocomm OEM range test utility
shows no errors over the link. It almost seems like a buffering or RF
data collision problem, but I'm not sure what to try next.
My setup now is with an interface baud rate of 57600 (gives an RF baud
rate of 28800), broadcast mode (no addressing), Half duplex. I did try
full duplex, but it cuts the total throughput in half and the behaviour
was even worse.
Thanks in advance for any tips.
/Steve