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 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.