868MHz Issues - Revision history

Esden at 00:01, 10 March 2011

2011-03-10T00:01:11Z

← Older revision		Revision as of 18:01, 9 March 2011
Line 23:		Line 23:
	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.		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.

	[[Category:Hardware]] [[Category:Radio]] [[Category:Telemetry]] [[Category:~~Documentation~~]]		[[Category:Hardware]] [[Category:Radio]] [[Category:Telemetry]] [[Category:User_Documentation]]

Esden at 23:45, 9 March 2011

2011-03-09T23:45:39Z

← Older revision		Revision as of 17:45, 9 March 2011
Line 23:		Line 23:
	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.		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.

	[[Category:Hardware]] [[Category:Radio]] [[Category:Telemetry]] [[~~Categeroy~~:Documentation]]		[[Category:Hardware]] [[Category:Radio]] [[Category:Telemetry]] [[Category:Documentation]]

Esden at 23:44, 9 March 2011

2011-03-09T23:44:47Z

← Older revision		Revision as of 17:44, 9 March 2011
Line 23:		Line 23:
	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.		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.

	[[Category:Hardware]] [[Category:Radio]] [[Category:Telemetry]]		[[Category:Hardware]] [[Category:Radio]] [[Category:Telemetry]] [[Categeroy:Documentation]]

Esden at 23:21, 9 March 2011

2011-03-09T23:21:44Z

← Older revision		Revision as of 17:21, 9 March 2011
Line 22:		Line 22:

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

			[[Category:Hardware]] [[Category:Radio]] [[Category:Telemetry]]

Limaiem: /* AeroComm */

2010-01-01T00:28:15Z

AeroComm

← Older revision		Revision as of 18:28, 31 December 2009
Line 17:		Line 17:
	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.		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).		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 ==		== 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.		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.

G R: /* Getting them to work */

2009-09-19T22:06:48Z

Getting them to work

← Older revision		Revision as of 16:06, 19 September 2009
Line 22:		Line 22:

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

G R: /* Getting them to work */

2009-09-19T21:59:26Z

Getting them to work

← Older revision		Revision as of 15:59, 19 September 2009
Line 35:		Line 35:
	*Type ATWR to store the new stuff in the firmware. You should get an 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.		*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).		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.		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.		Thanks to CheBuzz for this info, and for working this all out at 11pm the night before EMAV09.

G R: /* Getting them to work */

2009-09-19T21:57:46Z

Getting them to work

← Older revision		Revision as of 15:57, 19 September 2009
Line 24:		Line 24:

	=== Getting them to work ===		=== 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.		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.		I did this using a command window, but you could use X-CTU if you are a wuss or have Windows handy.
Line 34:		Line 34:
	*ATRR0 and enter => OK		*ATRR0 and enter => OK
	*Type ATWR to store the new stuff in the firmware. You should get an 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 probably want to do this to both XBees (at least I did) ~~and use them in transparent mode~~. 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!		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.

G R at 21:55, 19 September 2009

2009-09-19T21:55:16Z

← Older revision		Revision as of 15:55, 19 September 2009
Line 23:		Line 23:
	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.		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.		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.

G R at 21:54, 19 September 2009

2009-09-19T21:54:34Z

← Older revision		Revision as of 15:54, 19 September 2009
Line 26:		Line 26:

	I did this using a command window, but you could use X-CTU if you are a wuss or have Windows handy.		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 ~~9600~~", you can also use pico- or microcom)		*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.		*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...		*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...