RFM22 versus XRF

[srnet]

Hope RFM22 versus XRF

I have recently been testing the RFM22 transceiver for possible use as a satellite up-link receiver. I know the XRF has had good reports for its receive sensitivity so I decided to compare them.

Both devices allow the power output to be reduced, which makes the job of range testing a bit easier.

I have used the RFM22 before as a Morse beacon on my PICAXE Lost Model Locator projects, and whilst its not the easiest device in the world to drive, once you have mastered it, there are several very useful features, most notable being the 100mW power output and the ability to fine tune (calibrate?) the output frequency, useful if you are using low deviations.

Both units were the versions optimised for 868Mhz, I have previously been using the RFM22s at 434Mhz without realizing they were the 434Mhz version, which does have and effect on output power and sensitivity.

The RFM22 was run 500bps and the XRF at 38.4Kbs, the XRF does have a 1.2kbps mode, but a firmware issue appears to prevent it from working at present.

At 1mW output power for a 75% success rate in receiving packets the RFM22 had a range (ground level line of sight) of 350M, the XRF a range of 440M. These results are both reasonably good.

Of the two units the RFM22 has more features and more available output power, but requires considerably more programming effort to get results. The XRF in comparison is a very easy unit to use and gets better range than the RFM22.

The PIXACE driver programs I used for the XRF are attached, this shows how the units can be configured for different powers and bands etc. The example shown sets up the devices for 434.075Mhz, which will give about half the range at 868Mhz.

 

[srnet]

And if you want to see how easy the XRFs are to drive, here is a pair of programs that can be used with the XRFs out of the box, the transmitter sends a 6 byte packet and reports if it gets an acknowledge from the receiver.

'28x2 XRF Transmitter test

'The XRFs will work out of the box with no confuguration !!!!!!

'This program uses serout and serin commands, no hardware UART required. 
'Connect PICAXE Transmit data pin (see symbol TX) to XRF pin DATA IN/RX
'Connect PICAXE Receive data pin (see symbol RX) to XRF pin DATA OUT/TX
'Stuart Robinson - May 2012

'Transmitter program, sends a numbered packet and waits for "RX" returned as an acknowledge

#picaxe 28x2
#terminal 9600
#no_data


symbol PXLED = a.3  		'pin to drive red LED on PICAXE
symbol var1 = b4
symbol var2 = b5
symbol var3 = b6
symbol var4 = b7
symbol var5 = b8
symbol var6 = b9
symbol var7 = b10
symbol packetcount = w27
symbol TX = c.6
symbol RX = c.7
symbol baudmode = T9600_8

main: 
	setfreq m8
	pause 1000
	sertxd ("Program Running",CR,LF)
		
loop1:
	high PXLED 								'turn on LED, flash indicates packet sent 
	inc packetcount
	bintoascii packetcount, var3,var4,var5,var6,var7
	serout TX,baudmode,(var3,var4,var5,var6,var7," ")	'send 6 character packet
	sertxd(var3,var4,var5,var6,var7," ",CR,LF)		'send to serial terminal also
	low PXLED
	
	serin [2000,noack], RX,baudmode,var3,var4		'wait for 2 characters to arrive, goto noack if not seen in 2 seconds
		
	if var3 = "R" and var4 = "X" then				'check if RX received
		high PXLED							'double LED flash for packet acknowledged
		sertxd("Packet acknowledged",CR,LF)
		low PXLED
	else
		sertxd("Invalid response from receiver",CR,LF)
	end if
	pause 1000
goto loop1

noack:
	sertxd("No acknowledge from receiver",CR,LF)	
	goto loop1

end

'28x2 XRF Receiver Test

'The XRFs will work out of the box with no confuguration !!!!!!

'This program uses serout and serin commands, no hardware UART required. 
'Connect PICAXE Transmit data pin (see symbol TX) to XRF pin DATA IN/RX
'Connect PICAXE Receive data pin (see symbol RX) to XRF pin DATA OUT/TX
'Stuart Robinson - May 2012

'Receiver program, receives 6 bytes of a packet and then sends "RX" as an acknowledge


#picaxe 28x2
#terminal 9600
#no_data

'hardware definitions
symbol PXLED = a.3  	'pin to drive LED on PICAXE
symbol var1 = b4
symbol var2 = b5
symbol var3 = b6
symbol var4 = b7
symbol var5 = b8
symbol var6 = b9
symbol var7 = b10
symbol TX = c.6
symbol RX = c.7
symbol baudmode = T9600_8

main:
	setfreq m8
	pause 1000
	sertxd ("Program Running",CR,LF)

loop1:
			
	serin [5000,nopacket],RX,baudmode,var3,var4,var5,var6,var7	'wait for 5 characters to arrive, goto nopacket if they arrive in 5 seconds
	
	high PXLED						'flash LED for packet received
	sertxd (var3,var4,var5,var6,var7,CR,LF)	'print them out
	serout TX,baudmode,("RX")			'send an acknowledgment that packet received 
	low PXLED
goto loop1

nopacket:
	Sertxd("No Packet received",CR,LF)		'indicate timedout waiting for packet 
goto loop1
	
end

 

[ciseco]

Good to see that the TI chip betters the Hope in range even though the data sheet would make you think the opposite. There's nothing I've come across yet on the market to equal it's performance (we are always on the lookout). We are just playing with the TI CC1190 power amp, +30dB TX and an extra 6dB inbound, ranges should be in the order of 10's of KM.

The XRF unlike the Hope (which is a solo RF front end) is a three part system on a single chip, at the front you get the CC1101, in the middle is an 8051 micro thats about as powerful as the PIC which is the 28x2 and what you interface with in plain old serial is our software. The software takes care of almost everything for you and for example supports 128bit AES, the hope I believe has no security.

There's a 433 tuned version of the XRF in the pipeline which might go even further.

I would try at the faster default 250kbps over the air as I think you might get even further, the lower baudrates on the v1.5 have had to be tweaked to get the TI hardware to play nice with the different tolerance of the XTAL, the impact has been the lowest speeds the range is reduced. Getting a couple of meters plus off the ground will also improve things.

 

[srnet]

Getting a couple of meters plus off the ground will also improve things.

Sure.

But my 'standard' method (so I can do comparisons) is to fix the transmitter to the back of a 'standard' plastic garden chair, about 2.5ft from the ground. Its over the local park which had a field that is about 300M across.

Its also opposite my brothers house, so we can sit on his garden wall, looking at the park, drinking tea, discussing important issues of the day, such as the the propogation loss of free space, the effect on propogation of wet grass and the price of milk.

 

[srnet]

I would try at the faster default 250kbps over the air as I think you might get even further, the lower baudrates on the v1.5 have had to be tweaked to get the TI hardware to play nice with the different tolerance of the XTAL

What sort of deviations are being used by the XRF, high data rates versus low data rates ?

 

[ciseco]

"What sort of deviations are being used by the XRF"

In the two lower data rates the deviation had to be increased, the rest remain the same as they have always been

For more detail on the CC1110 visit http://www.ti.com/product/cc1110f32

A quick search of the PDF for the following will give you all the info on the TI chip.

"The frequency deviation is programmed with
the DEVIATION_M and DEVIATION_E values
in the DEVIATN register. The value has an
exponent/mantissa form, and the resultant
deviation is given by:"

 

[srnet]

So what are the deviations used ?

Not sure how knowing which registers in the cc1110f32 control deviation help me.

 

[Goeytex]

Good to see that the TI chip betters the Hope in range even though the data sheet would make you think the opposite.

The comparison tests done here were not done in a manner that could possibly support that conclusion.

The range difference could just as well have been related to board layout or antenna matching/selection (among other things). Besides, the comparison is not really between the TI chip and a Hope (chip) since Hope does not make RFIC chips. The comparison was between a commercial product (XRF) that uses a TI Cc1101 RFIC and a user built device that uses a SI 4432 RFIC on a Hope manufactured RF front end board. There is no way that this simple test should lead to the conclusion that a TI CC1101 performs better than an SI4432 in regards to range. Likewise we cannot objectively conclude that XRF is better than Hope.

To do a fair comparison of range, the XRF ( CC1101) should be compared with a well designed & mature commercial product that uses the SI4432 RFIC. Both should be using the same frequency, same power level, same serial data rate and and the same RF data rate. The frequency should match the front end components. Both should be using the same modulation method ( FSK or GFSK). Something like a Dorji DRF4432D20 could be used to make a fair comparison.

 

[srnet]

What you say is true, but as a comparison between two RF devices from a consumer end user perspective the comparison seems valid.

I was just doing some long range LOS tests with the 434Mhz tuned RRM22, I got 100% reception reliability at 4.3Km with 25mW output, 50% reliability at 12mW. This was using 5khz deviation and 250bps data rate with Manchester enabled.

 

[Goeytex]

I was specifically addressing Ciseco's comment that I quoted and nothing else really.

Certainly from a consumer end user and novice programmers prospective, the XRF would win hands down. However, that is comparing apples to oranges. Front end modules are not targeted at consumer end users as a ready to use devices.

 

[srnet]

Certainly from a consumer end user and novice programmers prospective, the XRF would win hands down

Very definitely.