RF12 range seems OK for me

Jee Labs Talk » Let's hook it up

RF12 range seems OK for me

(29 posts) (5 voices)

Tags:

No tags yet.

raalst

I just got my wireless (model-)Sonar operational. It uses the RF12 library with an enlarged packet size.
I had the sender (i.e. sonar) transmitting the received echo's in the attic, and the receiver stuck on my netbook in the living room, showing the signals with Processing. It is a modern house with rebar/concrete floors and sides, and the rest filled in with sandstone (i think..). the RF12b is 868 Mhz.
Reception was flawless ! Hurray for the JeeNodes.
I'm confident that the range on open water will be more than sufficient.
as we say around here : onwards !

Posted 25/07/2010 14:57:53
stef007

My experience with the range is this:
- the position of the antenna matters a lot (horizontal or vertical placement)
- the position of the sensor box as a whole also matters
- the packet size: I had a sensor that could almost never get its packets to the jeelink/nas without CRC errors. Then I optimized the payload to reduce packet size. Now I can see that sometimes a packet still gets garbled but most of the time they get through. I'm talking about packets sizes here of 1 to 5 bytes payload as opposed to the bigger ones I used that were about 36 bytes.
My setup:
- jeelink attached to NAS/server in basement (thick poured concrete walls)
- jeenode that had a range problem: outside in garden at about 14 meters
- I also got two jeenodes on the second floor (about 10 meters distance): I had to find a "good spot" for them in the room;-)

Posted 25/07/2010 15:33:26
edwardhorsford

I've been experimenting with different commercial antennas, but so far haven't found any significant performance increase to make it worthwhile.
To improve the performance, I've reduced baudrate to 19,200, reduced the bandwidth, and kept my packets as short as possible. Probably given me 50 - 100% further range, which is very useful.
Downside to reduced baudrate is increased power consumption. So it's a tradeoff to how slow you go.

Posted 26/07/2010 12:01:13
stef007

@edwardhorsford,
interesting... are you using the new rf12control() function to support this new mode? Or does it require more changes to the rf12 lib code? If it is limited to rf12control() calls, could you post your calls here? Thanks.
I'm wondering how much bigger the power consumption is. For example: for the moment it takes about 4 milis to get my packet across with a payload of about 3 bytes. 115200 is 6 times faster than 19200. Does it mean my packet would take 46=24 milis to get across with your modification? Have you done such experiments?

Posted 26/07/2010 13:03:46
edwardhorsford

Hey stef2007,
I previously hacked the library to change speeds, but am now using the rf12control() as it's much easier. I'm currently setting: rf12control(0xC611); //set RF speed - 19.2 kbaud rf12control(0x94C2); //67khz rf12control(0x9820); //45khz deviation I haven't tested enough to know if the second two control commands are having much effect.
Keep in mind that the RF12 library has 9 bytes of total overhead. So your three byte payload is actually a 12 byte message. Yes I would expect a proportional decrease in send time, though some of that time will be waiting for the RF12 to power up, so might not be as bad as your numbers suggest. It does of course mean increased battery usage, but I'm trading that off for improved redundancy and transmitting less often.
Depending on what you're sending, you might be able to queue up messages so each RF12 packet contains data about several events rather than one. As there's so much overhead compared to what you're sending, you might find this quite efficient.
I might run my current sketch under a scope later today to see what it's looking like. I'll let you know what I find.

Posted 27/07/2010 08:14:34
stef007

Thanks great info. Will put this on my todo list for later testing.

Posted 27/07/2010 09:25:29
tankslappa

I'm kind of going the other way, I want range, but what I need is speed. Thanks to information from Edward I'm running my wireless flash triggers at 114.9Kbps using 0xC602. Which is allowing the flashes to sync with the maximum 1/250th second shutter sync of my Nikon. All the other settings are still as set in the standard RF12 library.
It has impacted the range, If I move diagonally across me house, forcing it to go through several brick walls, it no longer worked. Hopefully this situation won't crop up in real use.
So if anyone has any suggestions on settings for the other bits please send them this way!

Posted 27/07/2010 19:39:37
edwardhorsford

As mentioned in this thread: http://talk.jeelabs.net/topic/191 I did do a bit of work at increasing speed. There's a fair amount of optimisation that can go on, but not much that doesn't require significant mods to the RF12 library.
I might get around to looking at the RF12 library again from the speed perspective, as the needs of a photographic trigger are quite different than it's default use case.
Tankslappa - out of interest, what size of payload are you sending? What's in your payload?

Posted 27/07/2010 20:23:21
tankslappa

My payload isn't very optimised really. I send two bytes. The first is the command to say "fire" the second is a group/channel number which all the flashes belong to. This is purely to allow multiple systems to work side by side without cross triggering. At the moment that isn't an issue as I'm the only one with it, but I thought it was something I really should include.
The actual power settings for each flash is sent in advance when you change the levels on the controller. The remotes store this in a variable and in their Eeproms so it's retained through battery changes, power cycles etc.
Given I'm still using the standard RF12 library calls to send the message, complete with its 9 byte overhead, optimising my message from 2 bytes to 1 really didn't seem worth it.
I really am going to have to bite the bullet and take control of the entire message and not just leave it all down to the RF12 library!

Posted 27/07/2010 20:51:49
stef007

@edwardhorsford,
I've tested your rf12 control commands for lower bitrate: it seems that the total transmission time (rf12wakeup-send-rf12sleep) increases by a factor 2. For example:
payload of 2 bytes (thus excluding overhead): it takes 4 milis on regular rf12 mode and 7 to 8 milis with your rf12 control codes active. I'm measuring using the global milis counter so it's not super precise but good enough for me.
When I incremented the payload to 8 bytes the normal mode took 5 milis and the "slow-but-extended-range" mode took 10 milis. So that seems to be consistent.
In practice this meant my temp sensor running on a 2400mAh omnicell would run 8.4 years instead of the 10 years I optimized the "alive" time for. By halving the temperature measure and transmission frequency I got back to my 10 years lifespan.
My sensor would wake-up every 37 secs, measure and transmit its payload. Now I let it sleep for double the amount of time, 74 secs. Extending my range costs me either more batteries or less frequent sensor readings.
Now I only need to find some time to confirm your findings: is the range effectively extended and, more subjectively, is it worth the less frequent readings.

Posted 27/07/2010 21:49:34
edwardhorsford

@stef007 - What's this application for? Environmental temperature won't change all that often to make it worth reading too frequently.
Some other thoughts: What kind of temperature sensor are you using? Is it optimised so that the microcontroller isn't on whilst it's taking readings. Since most of the cost is in the overhead and in waiting for the radio to power up, is there anything stopping you caching several temperature readings for 500 seconds, then sending a single transmission far less regularly?

Posted 27/07/2010 22:07:26
stef007

@edwardhorsford,
it's just the temperature of a room in my house. You're right that I don't need so many readings. I just try to get the most use out of the battery: the shelf life of the 3.6V 2400mAh omnicell I'm using is 10 years. So calculating a bit I can consume about 27.3 microAmps for 10 years. If I consume more than this then the battery will not last 10 years. If I consume less than this the battery might self-discharge anyway and finish at or before 10 years (the estimated shelf life). That's why I target 10 years and increment the frequency of tranmissions if I've got room.
I'm using the ds1820 like in the rooms node. But don't worry: JC's demo code has a delay in there when waiting for the temperature calc/fetch. I've put a powerdown/sleep there instead.
About caching temperature readings: in my case I don't necessarily want each and every reading. I just want to have a value in my server/NAS which is very up-to-date or at least as fresh as possible (when battery life allows it).

Posted 27/07/2010 23:03:32
tankslappa

With consumption levels that low due to good power management you could put a little solar panel on there and receive enough charge from indirect light to never go flat.

Posted 27/07/2010 23:47:32
stef007

@tankslappa,
27,3 microAmps is the average power usage: most of the time power consumption is that of sleep/powerdown of the atmega at 22 microAmps. Then there are peaks of 7-9 mA (atmega alive) and 25 mAmps (transmitting). So not sure that a little solar panel with indirect light could pull that off?
Also, what at night? My sensors must keep running so that I can pull nice graphs in the morning;-)

Posted 28/07/2010 07:06:18
tankslappa

@stef007
22uA now you are showing off! I didn't mean go purely solar. Use solar to top up a battery. Then you wouldn't need to remember to charge it come the end of the decade :-)
With that level of consumption you could even do it with a capacitor, although it will have to be a posh one to prevent it leaking all the charge internally over night.
A 12v panel however might generate enough to get the charger working (I just checked one here, and sitting on the table out of direct light, it was generating 5.6v - all be it to no load). It really depends on how much light your room gets and what colour it's painted!
Don't worry, I'm just thinking random thoughts aloud! If you live in some crazy Northern place like North Norway it probably wouldn't survive those winter nights that last weeks/months! Maybe wind power might be an idea... :o)

Posted 28/07/2010 09:24:21
tankslappa

A thought has just crossed my mind... Doesn't happen often, so please forgive me if it's complete twaddle...
IIRC the power consumption of the ATmega reduces with the clock rate... So if you flashed the ATmega's fuses to run on its internal oscillator, instead of the supplied 16Mhz one it would drop to 8Mhz... Turn on the internal div 8 fuse and you've got 1Mhz. Now I'm not sure how much this would impact the RF12 or any other libraries, but it might be worth a go. I would imagine the power consumption drop for the ATmega could be quite significant.

Posted 01/08/2010 17:05:09
stef007

Interesting yes... If the power consumption is indeed less with fewer Mhz, will this also be the case in powerdown mode? Because for me that's the largest chunk, the 22 uA in powerdown eats most of my battery.
I quickly checked the atmega238P datasheet: on the first page it says promising things regarding your thoughts:
Low Power Consumption at 1 MHz, 1.8V, 25°C for ATmega48PA/88PA/168PA/328P:
Active Mode: 0.2 mA
Power-down Mode: 0.1 ?A
Power-save Mode: 0.75 ?A (Including 32 kHz RTC)

Posted 01/08/2010 20:51:56
edwardhorsford

@tankslappa - Keep in mind that the slower the clock, the longer it takes to process when it does wake up.
@stef007 - I've got to ask why you're targeting 10 years? You're almost certain to be doing things differently before then, so why not just set it up now?

Posted 01/08/2010 21:59:47
stef007

@edwardhorsford,
I'm not sure I understand your question or that you might have misunderstood my posting.
I have this setup and running now (as we speak). What I'm targeting is 10 years of battery life. Indeed, 10 years is a lot, so in my (computer science) eyes this is practically forever;-) If I could I would target even more years but the batteries I'm using only guarantee a 10 years working period (or so I have understood).

Posted 01/08/2010 22:23:02
tankslappa

@edwardhorsford,
Understood. However if he is currently asleep for 10 minutes (600 seconds) and awake for 10 seconds, and the Mhz slows the broadcast down so it has to be awake for 20 or 30 seconds, it is still spending a great majority of the time in snooze, which from the look of the data sheet info stef007 has dug up would be 0.1?A! A current so small I bet the battery's own internal leakage exceeds it!

Posted 01/08/2010 22:34:11
stef007

Yes and while it may take more time doing its thing when it is awake, it will be doing it at lower mAmps (possibly 200uAmps according to spec). In fact, if the factor by which the power usage drops is about the same as the factor it slows down (and takes longer to do its work) the net/average power usage result for the awake period will be about the same.
Your advantage then lies in the power usage during its sleep which might become almost zero (100 nano amps according to spec).

Posted 02/08/2010 08:46:41
tankslappa

@Stef007 Get to it then! By the time JC gets back you could have a Jeenode which can run on the power of a butterflies wing flap!

Posted 02/08/2010 12:27:14
stef007
tankslappa,
when's the last time you saw a butterfly? I think I'll fare better with solar energy;-)
Seriously, my first thought was: this even lower power usage is not usefull to me. Why? My app is already optimized to run 10 years on the omnicel battery I'm using.
But perhaps I'm misunderstanding the 10 year shelf life statement. I initially thought the battery would leak itself to 0% in 10 years. But ofcourse that's probably not correct. I'm reading here and there that a shelf life of x years would mean that the battery still retains at least 80% of its power after x years. Now I don't find that statement on the omnicell website but let's assume that it applies to them also.
So if the battery leaks 20% in 10 years then it might leak 100% in 50 years. Not sure but let's assume the leakage is linear;-) Let's do some calculations:
```
    50 years is 18262.5 days or 438300 hours
```
```
    omnicel AA battery power contents is 2150 mAh (according to the website, but 2400 mAh
    according to conrad.be. Bwah let's assume worst case scenario of 2150mAh)
```
Divide these and you can see that the battery is supposed to leak 4,905 uAmps continously. So if I get the atmega to sleep at 100 nanoAmps, I'm leaking 49 times as fast;-) But if I set the frequency of the atmega so that it is consuming about 5 uAmps in sleep then it might make sense. The question remains: if the leaking is about 5 uAmps and the atmega consumes 5uAmps, what is the total power consumption? 10 uAmps or still only 5 uAmps. In other words: does the leakage occur always, even when consuming power thats larger then the leakage current? Anybody any idea?
Anyway I first need an answer to that question or my calculations are just bogus and fairytales;-)
Still, the extreme low power consumption can be very usefull for other powering solutions like solar cell combined with supercaps.
Posted 02/08/2010 19:54:44
tankslappa

I've seen several butterflies just today! Where are you, the Arctic?! I have yet to attempt harnessing them.
To answer your question about leakage, yes it will always occur. Think of it as a huge resistance between the polls of the battery, which in effect it is. In normal use it's not of any consequence as the device uses the battery up before more than a couple of percent has leaked on its own.
I must admit I've not even thought about making something last ten years! Sounds very impressive if you can do it... Although when it goes flat after the ten years you'll never be able to find the charger! I have enough problem with a mobile phone that does 4 days!
So you're not going to try it then? You know what that means don't you... I'm curious... Which means I'm going to have to try it! I don't think my meter goes low enough to confirm the consumption, but I can certainly find out if there are any issue with the RFM12 at 1Mhz.

Posted 02/08/2010 20:23:59
digit

Hi,
In fact I'm facing the same question right now, how much will the self-discharge influence some calculations i did on estimated battery life. I have a motion sensor that has an estimated battery life of >1 year, but actually i don't have a clue about error margins or battery leakage...
http://blog.hekkers.net/2010/08/02/battery-life-estimation/

Posted 02/08/2010 20:25:55
tankslappa

@Digit
I honestly wouldn't know where to start! It depends on so many things. The construction of the batteries you are using, both physical and chemical. Even the temperature they are working in. I'm sure we've all experienced Li-ion batteries in cold weather just giving up the ghost. Curiously though they haven't lost the charge, just can't convert the chemical energy into electrical at those temperatures. Once warmed up the charge magically appears again.

Posted 02/08/2010 21:09:47
digit

Currently i'm using those Sanyo Eneloop (NiMh) AA 1.2V 2000 mAh batteries. I was told they have a low discharge rate, which seemed to be a good reason to try them out. I've considered LiPo but when i read things like you have to keep a close eye on them while they're being charged, explosions, keeping them in a metal safe box etc. i became less enthusiastic. Maybe i just read the wrong articles, who knows :-)

Posted 05/08/2010 21:29:55
stef007

@tankslappa,
I will sure be listening for your 1Mhz results;-) I've re-done my power consumption calculations keeping in mind the constant battery leakage current. I found the spec for the batteries where it is stated they lose less than 1% per year. So assuming 1% per year and 2400 mAh power contents (according to the same spec) I get to about 2.74 uAmps constant leakage.
For the sensors in my house I have calculated they should run at least for 9 years on the battery (down one year from previous calculations because I missed the leakage current). For me this is good enough;-) Could very well be that within 9 years I'm using other sensors all together or jeenode V23 or something;-)

Posted 06/08/2010 09:13:56
stef007

@Digit,
yes that new type of NiMh batteries indeed have a much lower self discharge rate than the normal NiMh batteries. But still according to spec they loose 15% after one year and 25% after 3 years. So in the first year, assuming capacity of 2000mAh, there is like a constant leakage current of 34 uAmps. That's more than my sensor is using in average;-)

Posted 06/08/2010 09:20:41