868MHz Issues

EUROPEAN REGULATIONS

ETSI requirements as specified in the ETSI EN 300 220-1 define the requirements for the 868-870MHz bands. For a conducted output of 180mW and radiated outputs up to 500mW, the maximum allowed duty cycle is <10%. This duty cycle is measured as the amount of TX time on, monitored over one hour and relative to a one hour period.

868 MHz

To comply with regulations, 868MHz modems with more than 5mW are limited to a 10% DUTY CYCLE. As 868MHz modems have an exceptional range, it is important not to block the frequency for a radius of 40km.

Both AeroComm and XBee comply with the 10% duty cycle rule.

AeroComm

Tech support of AeroComm confirmed the 10% duty cycle compliancy.

Due to some conflicting numbers on performance, some measurements were done on the modem. The RF transmission time depending on nr of bytes was measured on the antenna as about: 0.15 * Bytes + 0.35 milliseconds by sending packets of different lengths in a know scheme to be certain. With 8 bits/byte this makes a RF data rate of certainly well above 50kbps. In another aerocomm document I came across the number 76000bps actual RF rate. If the modem takes care of the 10% duty cylce that would mean you can send a maximum of 7600 bits per second. Finally things are starting to make sense as the manual says that in full duplex mode the modem can send 7500bit/s (10% duty cycle with 76kpbs RF rate). However 76kpbs RF rate would mean that in half duplex mode (15kbps), the modem is not legal anymore to send continuously and would use 20% duty cycle. This might be what the manual says about the OEM manufacturer being responsible to stay below the 10% [namely: use full duplex mode or send half the time]. The only question left to me is what this 'VIRTUAL' number of 28k8 RF rate physically means. I have no idea. To me it stays a virtual number. My guess is that its probably got something to do with the communication speed between the RF frontend and the protocol uC in the modem.

Furthermore the the serial port speed of the aerocomm has a little influence on the transmission speed (with aerocomm there are 2 pseudo-RF-rates: 28k and 19k2 depending on your usart setting: p33 table 8. multiples of 28k8bps baudrate set the RF to the fast speed while multiples of 19k2 set the RF to low speed). So setting your USART to 57k6 or 28k8 makes no difference for instance. It is just the speed at which you copy the bytes from you micro controller to the internal data buffer of the RF module. So except for the RF bitrate the only things that count are the amount of bytes per second and the timing (packets).

XBee

The difference between XBee868 and aerocomm868 as far as I know is that aerocomm drops packets of bytes and xbee stops sending. (quite a big difference actually) Again: an aerocomm packet is a continuous set of bytes sent without any pause. The default pause is 4ms. Since paparazzi nicely shedules the messages on its 60Hz periodic, this means very often full messages are dropped and the receiver does not necessarly even get message decoder errors! So with aerocomm the problem is indeed quite transparent to the user. default.xml in paparazzi sends messages so often that you might not even notice that 60% is dropped. (At least we didn't in the beginning). Xbee on the other hand stops sending after 6 minutes (10% of an hour) if the data rate is exceeded. So its more important to control the total amount of bytes.

Getting them to work

Even with the xbee868.xml telemetry file, XBee868s will not last over 6 minutes. There is a special 868 build flag (in slayer1.xml), and matching option for the datalink but I could not get this to work. Eventually, I got them to work for about 20 minutes, which happily is the flight endurance of a heavily overloaded GWS Formosa.

I did this using a command window, but you could use X-CTU if you are a wuss or have Windows handy.

• Attach Xbee and start serial comm program (I use "screen /dev/ttyUSB0 <baud rate, just a number, no angled brackets>", you can also use pico- or microcom)
• Type AT and enter. You should get an OK back.
• ATMT and enter. You should get a number - this represents the number of extra times each packet will be broadcast. We now need to change this to 0...
• ATMT0 and enter => OK
• ATRR and enter. This number is the number of retries that will be sent if an ACK is not received. Disabling this will also have the side effect of disabling ACKs, giving us more packets to play with.
• ATRR0 and enter => OK
• Type ATWR to store the new stuff in the firmware. You should get an OK.
• Set the datalink to transparent mode both in your airframe file and on the datalink.
• You may also want to drop the power level to 1mW for testing, or it won't actually work - they are just too damn powerful to talk to each other at a range of a couple of feet. I also used 1mW for flying - never lost the link, even after a mile. Didn't get round to range testing them though.

You probably want to do this to both XBees (at least I did). I personally had the baud rate at 57600 for legacy reasons, but it should work just as well at any other baud rate. Thanks to CheBuzz for this info, and for working this all out at 11pm the night before EMAV09.