XRF radio modules

[Haku]

I got some XRF radio modules today, they worked out-of-the-box as advertised (although i didn't actually receive them in a box ) so no having to waste time configuring them on the first run, and have been testing a couple on my RP5 tracked chassis setup.

Some observations & questions:

Components wise it looks pretty scarce compared to an XBee - could be made even smaller if only power/signal/reset lines were used?

One welcome feature is that there's virtually no time between powering one up and being able to transmit/recieve data unlike the XBees which take a few seconds to boot up.

Would've been nice to have a link to this page on the auction listing for the AT command set: http://www.ciseco.co.uk/content/?p=1738

The X-CTU software from Digi is useful for setting AT commands (much better than HyperTerminal which can be a right royal pain in the backside to use) and when you do press the "Test / Query" button it actually returns some info, which is a useful test to see that the module is running.

The whip antennas that came with it are around 82-83mm including the bit that goes through the board and gets soldered which is appropriate for the default 868.3MHz comms frequency, but if I want to run at a different frequency, which is best, 1/2 or 1/4 wave length antenna? and what's the difference between the different fractions of lengths in terms of signal strength?

Baud rates; I'm running at the default 9600 rate and am having to code the receiving end to cope with not receiving data after X microseconds, if I increase the rate will this help keep things smoother?
The transmitter end of my setup is continually reading from two potentiometers, doing a bit of calculation and then spitting out resulting data to the radio, all running as fast as it can at 32mhz.

What effects does changing the Radio Data Rate have on transmitting/receiving? Should I just leave it be?


So far I'm fairly impressed with them, mainly as they didn't need any configuring and could be used straight away, however I notice the auction listing has changed since I bought them to say that the price is introductory, I hope this doesn't mean the price will rise to that of an XBee because I think it wouldn't help sales as potential customers would see the XBee as a reliable option. I would like to see these boards sold in the thousands so the price goes down not up

 

[srnet]

The whip antennas that came with it are around 82-83mm including the bit that goes through the board and gets soldered which is appropriate for the default 868.3MHz comms frequency, but if I want to run at a different frequency, which is best, 1/2 or 1/4 wave length antenna? and what's the difference between the different fractions of lengths in terms of signal strength?

If the module is supplied with a 1/4 wave, then its likley the transmitter output stages are impedance matched for a 1/4wave antenna.

If that is so then changing the antenna to 1/2wave ought to be a complete disaster as a 1/2wave has a very diifferent impedance when compared to a 1/4wave.

Without the proper match between tansmitter and antenna much of the transmitter power can be lost.

From the reciever end it can be worth experiementing, start at say just over 1/2wave and cut bits of the end, testing the range each time. You might gain an improvement in reception, although the best length is likley to change as the frequency changes.

 

[Haku]

Thanks for the explanation re the antenna length (1/2, 1/4 etc.), these are transceiver modules so having different length antennas on a pair might hamper the 2-way communication as I intend to do some sensor feedback once I've gotten the control side running smoothly, starting with the onboard battery voltage.

I'll stick to 1/4 wave antennas and try to do some range tests over the next few days, first real test was through two floors in this 100+ year old house which has thick walls/floors, no problems with the tiny 2.4ghz AV transmitter or the XRF's at 868.3mhz

Might be time to look at DIY yagi builds again.

 

[manuka]

Haku: Thanks for this posting- I agree that the XRF certainly look attractive, even though at -110dBm it's receiver is not that sensitive. What's the transmitter power rating ? Does it have "wake on signal" ? Stan.

 

[Haku]

The transmitter power is selectable between; -30dBm, -20dBm, -15dBm, -10dBm, -5dBm, 0dBm, +5dBm, +7dBm, +10dBm (default)

I don't know if it has "wake on signal", this page http://www.ciseco.co.uk/content/?p=1738 and this pdf http://ciseco.co.uk/downloads/documents/datasheet - XRF v1-6.pdf have more info on the module, including:

"Tested range
Tested at +10dB output, 250kbps over the air rate, 9600bps serial
Wire whip to wire whip - 570 Mtrs
Yagi to wire whip - 1684 Mtrs"

I will however do some power usage tests to see for myself the mA usage under different situations.

 

[manuka]

Thanks- I've browsed the ~250 pages of data,& found mention of timed or external interrupt awakes. In spite of all the info. the nature of the data TX is elusive however. Given the only modest RX sensitivity I'd say FSK, even though GFSK (Gaussian Freq. Shift Keying) is recognised as superior.

 

[Dippy]

I think we have to be a little careful here.

Both the CC1110 and C1101 (it's sister base chip with which I have done huge amounts of work) support FSK and GFSK and other modes.

Sensitivity...
Again, dear readers, be careful when glancing at figures.
Don't just read headlines.
The effective sensitivity is a function of (amongst other things) carrier, modulation and data rate chosen.
So, are you comparing like for like always?

And then on top there is the physical stuff; the balun (or other matching circuit) , the antenna and the PCB design efficiency.
Unless your 'favourite' manufacturer specifies otherwise they will, no doubt, be quoting the RF chip manufacturer's data sheet. This, in turn, will be using their (the Manufacturer's) own Reference Design, with their own chosen balun circuitry, PCB design and antenna.

Maker X may use the same RF chip is Maker Y and quote the same sensitivity figure. BUT one may have a poor balun design or less-than-ideal PCB RF layout. It makes a HUGE difference.

And this makes criticism based on a "sensitivity" figure almost meaningless. Sorry, I don't mean to sound blunt but I have actually designed nitty-gritty RF circuits (not just other people's 'modules') and the difference in performance for the same chip is marked.

And then , add on top, component selection.
Most people (without Googling) don't know that inductors of different construction behave differently.
So, again Maker X may use a differnt type (even if it looks the same SMD footprint) to Maker Y or the original Manufacturer. So many variables huh?

The ONLY real test for comparison is a real-world back-to-back test.... unbiased

 

[ciseco]

Hi,

Half wave whip I have tried, the qtr gives much better range.

An LPRS 9dB yagi (UK firm) to a whip will give you over a mile, use two yagis perhaps 2-3 miles (we are trying to find somewhere we can try it). I've yet to find higher gain ones. One chap (ham) reckons there's close to 10 miles in there with his custom "twigs", if he achieves it I'll write up how he did it (I'm sceptical).

Stan, it's firmware is written for transparent serial and ease of use, if you did want to explore the more complex features of the CC1110 (eg WOR) then you would have to buy a TI programmer and write your own software. Our aim was the best possible features for your average hobbyist. Your needs I suspect are substantially more complex than the average user.

Haku, I'm really glad you are pleased, I'll email your comments round the office.

Sorry, yes the price is to rise to £12.50 shortly (end of this production runs stock), this isn't good I know. It's the exchange rates and the pile of expensive TDK Japanese passives on there that have rocketed since the Tsunami. Hopefully not to worry, we'll soon be buying in bigger quantities so will bring it down again. The long term goal is under a £10 inc vat.

Did you know you can pause and buffer in coming data? It's really useful on lower PICAXE's that have no background receive or if you don't want to get into preambles and interrupts.

Dippy is right, figures mean little in real life. Our very first prototype struggled to do 7 feet, 9 PCB changes later you see the results, even TI were a little surprised that we wern't a million miles (2db) away from theirs. Especially on something about an inch square. The TI reference and their ground plane (and therefore device) is 4 or 5 times larger.

We have a USB version due within the next 8 weeks, this'll remove the need for a separate FTDI adapter. We gave up on doing wireless programming of PICAXE's as no one seemed to be interested. If this or anything else would be a good addition we are always keen to hear. For now only wireless programming of Arduinos is going to be supported.

There's a new article this week that shows how to build a wireless temp sesnor with an XRF and 08M http://openmicros.org/index.php/articles/78-microcontroller-projects/70-picaxe-08m-wireless-aprotocol-sensor

Right, time for a beer

Miles

 

[matherp]

Miles

Any chance of a version on a standard 0.1" pin pitch anytime?

Thanks

Peter

 

[manuka]

Dippy: Valid points old bean- as usual! I'd asked about GFSK and RX sensitivity (the latter assumed at 1200bps) with crowded band 433 MHz use in mind. Such modest rates are typical for occasional wireless transfer (weather stations etc) & when the going gets tough-the bistering data speeds XRF can reach are pretty incidental of course for PICAXE use.

Ciseco: OK on this & thanks for pricing & feature updates. Are those prices VAT inclusive? I'd be interested in ordering a couple for evaluation (& possible promotion via an article) in fact - any downunder agents yet?

FWIW -even here in the colonies 433 MHz has become almost wall to wall noise in many places, and I for one am increasingly tempted with slots now available around 900 MHz. There's no single global spectrum slot however, and power limits vary widely. Stan.

 

[Dippy]

I'm only guessing, but the website suggests the 868 band is the default.

My own designs (CC1101 + 18F25K20) defaulted to the 868 band too, which in my area, is relatively clear.

Stan would be proud of me; I included an auto-site-survey routine and link quality routine to check for the clearest band / reliability and report back. Obviously that's just a snapshot but it saves a lot of faffing around for the user.
The hardware that CISECO uses is really nice and reliable and I found it far batter than the MRF49 module. I would say that the XRF has a very good technical foundation.


Two tips to anyone considering buying the base chip and having a go...
1. If programming is fairly new to you - forget it.
2. If you haven't got experience of CAD and especially D/s or M/L PCB RF layouts and handling 0402 SM components - forget it.

 

[ciseco]

@matherp

We haven't committed to a 0.1" design, it's something been talked about. We haven't however left 0.1" users out in the dark. There's an adapter we have in stock but haven't had chance to do an advert for (need a time multiplier, 24 hours aren't enough). It looks like this (picture below).

It breaks out, PWR, GND, RX,TX and sleep onto a right angled 5 way header. Plugs into breadboard vertically so it doesn't take up too much space. You'll see by the picture it also slots straight into a xino (any flavour). It's a pound fifty if ordered with a module, also works with an Xbee. The DIP row breaks out all 20 pins in a standard narrow DIP socket spacing or for soldering straight to. One thing to remember it's 3.3v nominal (2-3.6v) so the easiest way is to run your PICAXE at 3.3v too (everything I've ever tried works, 2 x AA's is a good way too and removes the need for a regulator).

If using 5v, there's a diagram in the data sheet on how to wire a 10K and 15K resistor to drop the serial line voltage to something safe. If you want everything converted and powered to 5v, then Adafruit Industries do a break out with regulator and level conversion on for the XBee, I'm told it works just peachy on an XRF too. http://www.adafruit.com/products/126

@stan

Core electronics in oz have some, Graham will be able to sort you out for sure. I'm lead to believe it won't be long before NZ is covered locally

Picture is an earlier proto, the retail ones are sexy and blue

 

[Haku]

ciseco, i have read that the output stream of the module can be 'paused' but unsure how to do this, most of the information I've managed to find on the pinouts only say:

1 - +3.3v
2 - Data Out
3 - Data IN
4 - Future use
5 - Reset
6 - Future use
7 - Future use
8 - Future use
9 - Future use
10 - GND

11 - Future use
12 - Future use
13 - Future use
14 - Future use
15 - Future use
16 - Future use
17 - Future use
18 - Future use
19 - Future use
20 - Future use

The only instance I've seen of extra information is the recently released PDF which has these different lines:

4 - RTS
6 - Heart Beat
9 - Sleep
12 - CTS
13 - On Sleep Indicator
20 - Factory Defaults

How do I use these extra functions, pull the lines high or low? and what should I expect to happen for each of the functions?

I hope the specs PDF is updated to include all the AT commands and the extra functions beyond power & serial, I think it's important to keep all the information in one place.

 

[ciseco]

We are in the throws of doing a proper PDF user manual, haven't got to that command yet, the website version people have been 50/50 on. It's the RTS pin. Now off the top of my head you do the following.....

Go into AT mode
Turn on RTS mode
By wiggling RTS (pin 4) up/down you can pause/un pause transmission. (buffer is a couple of hundred bytes)

I'll need to go find which command and if it's pin high/low, want to make sure I tell you the right combination

....................search.......................emails................bingo

ATFC1 turns it on, ATFC0 is normal mode

Taking pin high "pauses" the serial side, the RF still receives and buffers until you are ready to take the pin low and everything "paused" will come rushing out.

This function was Hippy's idea, I can see why it's really useful for picaxe use.

A note on the other pins

6 - heartbeat, this pulses on/off about once a second, this shows the on board micro is executing firmware properly
9 - sleep, can be pin high or pin low depends on AT setting
12 - CTS is like the XBee function, only user wanting this so far was an Arduino user, his shields used it, don't think you'll need it
13 - The eevel changes to indicate it's sleeping (why? dunno, is a copy of the xbee function I believe)
19/20 If you short these two pins together and power up then your AT settings go back to defaults

One last thing, we are just finishing a windows app (sorry mac and linux) that allows you to change config, flash firmware, do serial monitoring etc without going near AT commands, it's our thing a bit like the Maxstream XCTU app. It's in need of a proper testing and some tidying, but's essentially finished so will be out "soon", beta testers welcome

 

[Haku]

Thanks for the info, I'll add this to the other tests I want to do over the weekend.

When pausing the receive buffer is there any way of finding out wether there's anything stored in the receive buffer?

One thing I did a quick test was power usage, on the module designated for transmitting it uses around 26mA when sitting idle and 19mA when transmitting, similar with the module designated for receiving, lower power consumption when receiving.
I'm guessing it's because when the module isn't transmitting or receiving it's listening out for any transmission.

That 5v tolerant XBee breakout module from LadyAda looks ideal, I would have bought some if I weren't already using some plain 2mm to 0.1" XBee adaptors for breadboarding & eventual stripboarding. I wonder if those status LEDs get in the way of the XRF as it doesn't have the corners cut off.

 

[ciseco]

Yes, un-pause it and listen

Sorry couldn't help myself (my humor is terrible I know), the real answer is I dont think so. However there's spare pins so if you think it's a good thing to do, I can bring it up and if there's no good reason not to, then I'm sure we can add such a feature in the next firmware update.

26ma at idle sounds a marginally high it should be more like 23ma, using a voltage regulator or got any resistors/leds on the go too?

If you want to turn "down" power usage at the transmitter end, I'd suggest sleeping it. They sleep/wake so quickly I doubt a PICAXE is fast enough to spit the data at it before it's up and alive again. At a hard power up it's only around 1ms before you can start sending.

Indeed, as you say it's always listening unless you say "sleep".

You can cut the corners off an XRF along the lines to make it identical in shape to the xbee, the reduced ground plane does however reduce the range, it's still better than a series 1 xbee though

The Ada board I think it comes as a kit so if they did get in the way you I guess they could either mount on the back, at 90 deg, use smaller/SMD or not use at all.

Ooooops, I see protopic (they sell picaxe/sparkfun etc) are also Adafriuit resellers, they are in scotland. A nicer bunch you'd hardly ever meet, they might do them, Roy is your man, top fella.

 

[Haku]

If when the receive buffer's output is paused and one of the spare IO lines is used as a "we got some data!" signal, the Picaxe connected to the XRF could use this signal as an interrupt so it wouldn't constantly be checking (using the serin timeout of the higher end Picaxes) or stuck waiting (ie the 08m & 18x etc.) for more data until the XRF actually has some. Then once the buffer is emptied the "we got some data!" signal goes low.
Just an idea.

The multimeter was measuring the amps going inbetween the +3.3v source and the XRF, when I do some proper tests I'll hook up the GND also as the multimeter can measure volts and amps at the same time, and display watts also which is a useful feature.

 

[manuka]

Ciseco: Blame my sheltered life perhaps, but this "Core Electronics" Oz. firm you mentioned is quite unknown. Google gags on it too, although XRF = Xray Fluorescence of course. Any insights?

I naturally appreciate the XRF can be reprogrammed for other bands, but I'm unsure about regs. for your 868.3 MHz default frequency. This seems the centre freq. for the slot between 868.0 - 868.6 MHz. In the UK/EU (at least) aren't just 1% duty cycles usually permitted here?

Not only are these appealing sub GHz "900 MHz" slots a veritable regulatory fruit salad, but apparently reviews are also under way for them. One of the enduring features of the "433" ISM (actually 433.05 - 434.79 MHz ) of course relates to it's global availability. Stan.

 

[ciseco]

http://core-electronics.com.au/eCommerce/

You can chose a range of frequencies so it's down to the user to select the one suitable for location. Indeed the 868 here is 1% per node and full 100% system. At a default 9600 you cant reach 1% over the air rate.

The FCC based 915 we have currently in settings is centred on 915, 150Mhz either side so not really right for the slightly different OZ regs (915 min) so the next revision of firmware will have more choice in frequencies, channels and spacing. Going this way the user can select what will be compliant in every jurisdiction.

The chip is capable of almost anything between 300 something and 1Ghz.

 

[manuka]

Ciseco: Thanks for the Core Electronics link - & Google finds them now too. Must have been a senior moment on my part? They only seem to have one XRF in stock however- are you shipping ?!

 

[ciseco]

Indeed we are shipping, a search for XRF on ebay is probably easiest, you'll also be able to see what other people think of them from our feedback.

 

[manuka]

Thanks-although suggest an update to your EBay pricing ! I'll need several for evaluation, so no doubt p&p will be easier. Of course exports to NZ will be VAT exempt. Any other Kiwis fancy joining in? Grogster maybe ? Stan.

 

[Haku]

I did some range testing earlier, using these two simple programs:

This sends a string every 1/10 second:

#picaxe 18m2
#no_data

' XRF range test - transmitter

hsersetup b9600_4,%00

do
 hserout 0,("qwerty")
 pause 100
loop

And the receiving end has a 20x2 LCD screen plugged into it:

#picaxe 18m2
#no_data

' XRF range test - receiver

symbol counted=w0
symbol missed=w1

setfreq m32

pause 8000 ' 1 second

serout b.5,N9600_32,(254,1)
serout b.5,N9600_32,(254,128,"Caught: 0",254,192,"Missed: 0")

main:
 serin [750,skip],c.1,T9600_32,("qwerty")
 inc counted
skipback:
 serout b.5,N9600_32,(254,136,#counted)
 serout b.5,N9600_32,(254,200,#missed)
 goto main
 
skip:
 inc missed
 goto skipback

Standard whip antennas with the all the default settings (+10dB output. 868.3mhz), line of sight from one hill to the next and around 5% 'message loss' I achieved over 1,100 meters!



I want to improve the testing programs, and add in percentage display but can't work out the coding properly, also maybe two-way 'pinging'. So if anyone has any hints ot suggestions on the percentage calculation for word variables or features of the test code, please chime in.

 

[Haku]

I also did some power testing and a couple of the other features.

Bench power supply set to 3.3v, actual measured was 3.2965v, each module had 0.9940hz output on the Heartbeat pin, no settings have been changed since receiving the modules (that'll wait for another day).

Module 1
24.5mA - no IO activity on pins or RF
18.6mA - receiving RF data
20.8ma - transmitting RF data

Module 2
25.7mA - no IO activity on pins or RF
19.5mA - receiving RF data
21.8ma - transmitting RF data

Module 3
26.2mA - no IO activity on pins or RF
19.8mA - receiving RF data
21.8ma - transmitting RF data

Module 4
24.3mA - no IO activity on pins or RF
18.6mA - receiving RF data
20.5ma - transmitting RF data

I couldn't get the sleep function to work, pulling the line high or low appears to do nothing, the power usage didn't change at all.
Interestingly the mA usage doesn't change when the voltage is slowly cranked down to near 2v, guessing there must be an internal linear regulator in the TI chip.

ATVR returns 0.25

 

[hippy]

I want to ... add in percentage display but can't work out the coding properly

Where 'm' is the number of packets missed and 's' is the number of packets sent, 'p' is the percentage (0-100) missed ...

m = ( p / 100 ) * s

p = ( m * 100 ) / s

The number sent 's' is the number of packets received 'r' plus the number missed 'm', so ...

p = ( m * 100 ) / ( m + r )

The 'm' is limited to 655 before multiplying by 100 gives 16-bit overflow, and 'm+r' must also be below 65536, so the easiest solution there is to divide 'm' and 'r' by a number which keeps the ratio the same. You can keep a 'rolling percentage' going by doing the division repeatedly to keep m at or below 655. This is the same as discarding some samples. The accuracy decreases and result is skewed by most recent results but should work and be usable, untested ...

ReceivedPacket:
r = r + 1
Goto ReportPercentage

MissedPacked:
m = m + 1
Goto ReportPercentage

ReportPercentage:
Do While m > 655 Or r > 64910
m = m / 2
r = r / 2
Loop
s = m + r
p = m * 100 / s
SerTxd( #p, "% missed" )

 

[Haku]

Thanks hippy, I tried these methods before:

p = ( m * 100 ) / ( m + r )
p = ( m / ( m + r ) ) * 100

but found the 655 upper limit on the m of the first calculation too limiting and the 2nd just didn't have any real results on low numbers (it's tough working with whole numbers like this), however I managed to find a compromise:

p = ( m * 10) / ( r + ( m / 10 ) )

This one allows the equation to deal with numbers up to 6553, in the code I used the same idea as you, dividing the missed & received by 10 when they get to 6500 so the percentages stay consistant:

 ' calculate percentages
 if counted>missed then
  temp=counted+missed/10
  if counted=0 then
   missedpercent=0
  else
   missedpercent=missed*10/temp
  endif
  countedpercent=100-missedpercent
 else
  temp=counted+missed/10
  if missed=0 then
   countedpercent=0
  else
   countedpercent=counted*10/temp
  endif
  missedpercent=100-countedpercent
 endif 

 if missed>6500 or counted>6500 then
  missed=missed/10
  counted=counted/10
 endif

The reason for the "if counted>missed" is because you can't rely on always receiving packets, if you're out of range and don't receive anything then the percentage calculations for low numbers get real screwey.

It's not perfect but it does the job well enough.

As the 868.3mhz range test worked better than I expected, i'm intending on trying a 315mhz test with the correct length antennas for them, I quite curious to see how well that one goes.

 

[ciseco]

Sorry haku, totally our fault, the latest manual has the settings for sleep modes.

You have to set the sleep mode with an AT command, I'll dig out what they are when I'm back in, in the morning. I'm 90% sure it's ATSM1 and ATSM2, ATSM0 (default) is sleep not enabled. To read back just enter ATSM and it'll tell you the current mode.

I'm over the moon you got such a range. When we tested it was in a semi urban area (8 lanes of M1 and an overhead powerline) so we weren't quoting figures we didn't expect users to be able to achieve, over 1k with just the modules is stonking.

Your test string, would you try taking it to 12 bytes long or change the commit length to 6 or reduce the timeout (cant remember off hand what that is in ms), I suspect you are close to it's default timeout delay to wait before committing the packet at 10 transmissions a second. The default string length is 12 bytes (for OpenKontrol really). What happens is when the 12th is received (serially) it sends immediately out the RF. You can see these 12 byte chunks easily with hyperterm if you keep your finger on a key. The "payload" length can be increased to around 250 bytes and as low as a couple. The time to wait before nothing else is heard "so send anyway" is the timeout. This gives total flexibility in how you wish to send your data. It might also increase the data reliability.

Just thinking how to eek out even more, there's something we haven't tried since the original TI dev kit, the manual states lowering the over the air data rate improves sensitivity considerably so should have an improvement in range. Taking the air rate to 1.2K and data to something less is the max I think.

Other than in company size or outright sales, can I ask, do you think we have met or exceeded the XBee? and if not, what we need to do to make sure it does, I wont be still till we have squeezed every last ounce of performance out the TI chip

 

[manuka]

You're increasingly getting my attention! At 868 MHz the shorter RF wavelength (~345mm) means parabolic dish antenna become viable. You don't even need a solid surface- just one inch grid (or better) wire mesh will do.

If range is your quest then maybe rustle up some dishes - perhaps browse my infamous "WokFi" site for inspiration! At these sub GHz freqs even quite trivial dishes will usually be good for 10dB gain, but deeper ones will better capture outgoing signals that may otherwise spill over. As every 6dB gain will double range,a pair of 10dB dishes at each end may give 2x2x2 = 8 times the range over isotropic. At 2.4GHz I managed ~3km across water with 1mW XBee pairs using such a simple setup. With your 10mW power you'd be good for 10km LOS I'd say!

 

[ciseco]

10Km would be quite amazing.

However with my company hat on, please make sure, not to do something outside your local RF regulations.

Miles

 

[Haku]

I went out earlier armed with two XRF radios (one set to 315mhz, the other at 868.3mhz) and a Picaxe with an LCD screen and a bi-colour LED that goes green when it received messages and red when it doesn't, stopping on the way up the hill to watch some badgers eat snails until they heard me trying to get closer.

My guess is that the actual range is much further but I lost line of sight beyond 1,700 meters.

The transmitting end has two XRF units on a breadboard both receiving the same 12 character string from the hardware serial output of a Picaxe 18m2 (I put 120ohm resistors on the XRF input lines), both were set to 1.2K radio data rate and normal 9.6K serial rate, 315mhz with a 226mm whip antenna and 868.3mhz with the supplied 82mm whip antenna.

The 315mhz does extremely well within this house, no problems at all going through three floors from the attic to the ground level, even outside, the 868.3mhz isn't as consistant though. The 315mhz managed near 600 meters ok but couldn't get anything at the 1,700 meter range that the 868.3mhz XRF module handled ok. Might be an antenna issue.

I think I'm done range testing for now, 1,700 meters is far beyond anything I currently conceivably need


ciseco, you've done a remarkable job with taking on the XBee at their own game, incredibly easy to use from the very start and great range, one of the most obvious things missing is the option of a chip antenna, I find myself being extremely careful with the antennas because they're solid core and can break at the base too easily, and being especially careful with the solid core 226mm one I put on for the 315mhz tests.
Wouldn't have to worry about damaging the whip antenna or its placement with a chip antenna.

The proposed configuration software similar to the X-CTS for XBees will be most welcome, will it also include a terminal function like the X-CTS?

 

[ciseco]

My sweet lord, 1700 meters and still going, I'm amazed.

The 315Mhz figure is also quite remarkable. The antenna would benefit from being a length divisible of the wavelength, the 433 setting should fair better it's much closer to half of the default 868.3Mhz. A quaterwave would be 22.6 cm rather than the 8.22 it shipped with. Here's a suitable calculator.

http://www.csgnetwork.com/antennagpcalc.html

Don't worry too much about the solid core breaking, we can send you a long length to play around with, it's only a through hole solder pad so easy to replace. Any wire will essentially work, the one we chose was for the fact it's a good fit for the SMA centre hole, inexpensive and easy to get hold of (RS)

Our experience so far of the Johanson chip antenna as deployed by TI in some of their designs has been ranges less than the whip, it would add close to £1 to the price so we've stayed away for the time being. When we start to deliver XRF powered devices the need for something more compact will increase, no promises to time but it will happen at some point.

As you've seen the range is really good, so good that if you coil the antenna around a small screwdriver into a little spiral this saves space. Although the range drops significantly it's more than enough for average home automation needs. For max range, a nice straight and erect whip is the order of the day

Miles

 

[ciseco]

ooops, I should read more carefully, you had already tried a longer antenna

The config software does indeed have a terminal mode.

Something again not in the web docs that will be in the PDF, is node type.

Set ATNT1 and I think it's repeater node, so with your 4 you could do XRF1>1700m>repeater>1700m>repeater>1700m>XRF2 getting you over 5km

The more interesting and more recent addition is theres ATNT3 & 4 which are RSSI modes, you can see in actual dB the relative signal strengths to and back again between a pair.


Miles

 

[Haku]

It was an antenna issue regarding the 315mhz test, I re-checked them and they were short by 12mm putting the frequency of them at around 335mhz, whilst checking I also noticed one of the 868.3mhz antennas was 4.5mm shorter than it should be (it was the one that snapped at the base so had to re-solder it), so all in all getting 1,700 meters and 600 meters with the wrong length antennas is a pretty mean feat

I can see why you're holding back on the chip antenna as you want to get as much range as possible without spending extra on an antenna that reduces the range.

Thanks for the tip about coiling the antenna, just did a quick test with correct 226mm antennas on the 315mhz set XRF modules, one straight the other coiled and the range within the house through a few floors/walls is great, then tried coil to coil and that worked better than expected. Line of sight should work pretty decent.

If anyone gets some of these modules it's definitely worth testing coiling the antenna.

edit: 315mhz line-of-sight, straight to coil whip antenna easily does 220 meters+, coil to coil wouldn't reach 50 meters.
Oh and a bit of odd behaviour with the sleep modes; with ATSM1 you have to pull pin 9 low to make it sleep (measured 153uA), but with ATSM2 it defaults to sleep and you have to pull pin 9 low to make it wake (measured 4.64uA sleeping), which meant I had to short pins 9 & 10 when I plugged it into the socket on my USB-TTL cable to change the settings or it wouldn't respond.

 

[Andrew Cowan]

Haku - nice tip, and excellent photo! Really clear

A

 

[MikeM100]

Good Stuff on RF Modules & Antennas

These people know a thing or two about RF modules !

See: http://www.radiometrix.com/content/application-notes

Datasheets on their products contain practical information on antennas - particular the helical (pictured in post above) and are well worth a read.

 

[manuka]

Don't be too astounded at that LOS range! When the UHF receiver is sensitive, & band conditions are quiet,several km are quite normal. I've had similar with diverse 433 MHz gear, some of it only a few mW TX power too. Path loss increases at higher freqs of course, but this often can be more than compensated for by far quieter band conditions & higher gain (but more compact) antenna.

As mentioned already,using simple parabolic reflectors, suitably positioned behind the XRF antenna, may well give you ~10km LOS point to point. This could be VERY worth while exploring for LOS links, as repeaters (although handy for say valley1-hilltop-valley2 coverage) will need their own power supply & mounting etc. Dishes should be at least twice the wavelength across, which naturally means 433 MHz ones would be a daunting several metres. At 868 MHz (with wavelength ~350mm) however a reflective dish would be more practical. See a typical grid style 900MHz 15 dB gain commercial one here.

Coiling a whip alters it's resonance frequency, so tight windings like Haku's may well benefit from "cut & try" experimentation. FWIW a significant benefit of a coiled whip however relates to eye safety, as (when looking from above) it can be hard to judge the proximity of the whip end. I had a ham radio mate poke himself in the eye badly like this once, & now ALWAYS add either a safety top loop or small flag to any 433MHz whip. Best mention this safety tip in XRF manuals in fact... Stan.(antenna wrangler since 1961) ZL2APS

 

[ciseco]

I love the picture and your results, it's so great for everyone to see what you've been testing with, top job. The sleep behaviour is intentional, I totally agree, one way feels much, much more logical than the other. I was told the internal configuration of the CC chip is why the two figures are so significantly different.

Good call, we need to make a note that mode 2 on most usb adapters the XRF would be in a permanent state of sleep and ignore any serial traffic/ attemps to set up or enter AT mode.

The figures we measured were (below), these were similar on different XRF's on two different DMM's. I'll have to do further investigation and see if our meters are out. It's the 4.6 to 0.2ua I find most concerning. The TI sheet suggests a similar figure to ours.

ATSM1 – sleep pin low 123.2ua @2.6v
ATSM2 – sleep pin high 0.2ua @2.6v

Can I play "nanny state" for a moment, 315 isn't an ISM band here

Stan, also top suggestion, I'm the most accident prone soul when using what should be most familiar too me, burnt fingers and soldering irons, you'd think I'd learn. The solid core wire would easily damage an eye for sure, I wonder if/where we could get some "blunt tops". Perhaps it being white rather than black is a good coincidence.

@Mike - A customer of ours is I'm told co-designing some Radiometrix kit (he's a firmware bunny). A few weeks ago he ran a demo of a GTC01 providing a GSM gateway to an XRF network. Looks good kit, met Shaun from RM a week or two back at the NEC, seemed a nice fellow. We were following up his suggestion to go talk to one of their existing contacts as the XRF might be a suitable alternative to their existing Chinese radio which is due to be discontinued. Its a small world

@Stan - Those 15dBi grids look tasty. My back of fag packet maths, could that equate to as much as 12 miles assuming 2 x 9di might achieve 3m. Our initial goal was just 250 meters

 

[Haku]

In the process of getting to know this module through the configuration settings I found they won't let me set any radio packet length below 12 (for sending packets of 10 characters):

ATPK9
ERR
ATPKA
ERR
ATPKB
ERR
ATPKC
OK

Also shorting pins 19 & 20 together to reset the AT settings back to default does work but it doesn't remember that you set them to default after removing power and the short between 19 & 20, I thought it would automatically save the default settings to flash.

ATNT3 is definitely a useful function, all packets that are received have "MMRSSIM-xxx" tagged onto them, where xxx looks to be signal strength of the incoming packet, I couldn't work out what ATNT4 does. I'll definitely have to incorporate ATNT3 stats into my range testing code at some point.

Regarding the sleep power consumption, I've just done a 'proper' test instead of relying on the breadboard setup with the 18m2 also onboard, I powered just the XRF straight from my bench power supply:
ATSM1 – sleep pin low 115.28uA @2.6v, 145.58uA @3.3v
ATSM2 – sleep pin high 0.24uA @2.6v, 0.27uA @3.3v
Results were virtually identical on two different multimeters.

As for 315mhz, I'm sticking with the default 868.3mhz for controlling my RP5 tracked chassis because it's the default option and the antennas aren't too long
And I'm glad I bought more than two modules, that way when I've got one Picaxe talking to another through XRF's I can have a 3rd module attached to my PC to listen in on the data transmission to see if things are going as expected.

 

[ciseco]

Hi,

I'll get the packet length query looked at, just tried one on my desk it does the same.

The reset to defaults loads the factory config into present memory. It doesn't as you say permanently overwrite your old settings. To save them to flash use ATWR. I do agree with you, it's less obvious to me also. I was given a pile of situations by the developer that it was a more flexible approach, I had to concede he was right. Another note for the pdf

ATNT4 - By having one module set to 3 and the other to 4 you'll get two messages back, essentially the RSSI there and back again. This needs to be documented well, I have requested that the XCM (xrf config manager) have support for this as I find piles of strings difficult to read without pausing serial receive. Indeed the xxxx is the dB figure calculated by the CC.

Phew, that's a weight off my mind, thanks so much for testing the sleep consumption again.

You make a really valuable point, being able to eavesdrop on your own transmissions does make life much easier when straying from the plug 'n play path. Because we have "stuff" at hand it's often difficult to be an "imaginary" user, this never crossed my mind, good call. I'm going to ask if we could do a "rental service".

Would I be right in thinking the more we delve into the inner workings with commands, the more complex the XRF is in some respects to the XBee, on the face I think they are easier, scratch the surface and there's a pile of twiddly knobs. This is one of the reasons for the factory defaults the way they are. If you raise a question with us that we think is config related, we can advise you short the jumper, if all is well then power cycle it, if now your old config replicates the issue, we know where it is and that the module and/or firmware are probably ok. We do our best to chose the most appropriate way, sometimes this does as you've found require a good explanation.

I mentioned what you had achieved yesterday in a meeting, the look of surprise was priceless. The sort of range you are getting is more like the £60-70 XBeePro868. I can't convey how delighted I am. Outside the day job, we are a bunch of avid evening/weekend tinkerers so you can guess how exciting such "stuff" can be, the wife doesnt share that opinion though

 

[manuka]

I'd be more than happy to trial assorted 900MHz antenna - swap you the findings for a couple of XRFs?

Aside from dish & Yagi style, collinear arrays are quite feasible too. In fact these can even be made from suitably "persuaded" coax cable - refer pix. They're still omnidirectional,but their gain arises from the squashed radiation pattern - no point in wasting signals up into the sky when users are all terrestrial. I've had a lot of mileage with "Slim JIM" versions at VHF & low UHF freqs.

Of course transmission line losses may become significant, so perhaps even consider mounting the entire XRF at the elevated antenna feed point,supplying DC & the data from below. This of course is the PoE (Power over Ethernet) approach used by some 2.4GHz WiFi APs. Stan.