Author Topic: Extended RFM69 lib - functions added  (Read 12279 times)

john k2ox

  • Full Member
  • ***
  • Posts: 110
Extended RFM69 lib - functions added
« on: September 04, 2013, 12:59:07 PM »
Hi All,

I,ve attached a new class RFM69NEW.  It adds new functions to read and set the frequency and to read the temperature. Also included is a test sketch.

Why these functions?  I plan to deploy nodes outside.  As the seasons change so will the temperature and I get big temp changes here in Syracuse.  Unfortunately, the crystal frequency also changes with temperature.  A 100hz change in Fxo will result in a 2.859KHz at 915MHz.  That means on cold days my link will most likely stop working.

My plan is to use the temp data to correct the radios freq so that data errors are kept to a minimum.  It is also neccessary to insure long range com.

john
« Last Edit: September 05, 2013, 09:59:28 AM by Felix »

englund

  • Newbie
  • *
  • Posts: 30
Re: Extended RFM69 lib - functions added
« Reply #1 on: September 23, 2013, 01:42:40 PM »
Can I simply run rcCal() every 10 seconds to keep the frequency calibrated to the ambient temperature or is there a downside?

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5939
  • Country: us
    • LowPowerLab
Re: Extended RFM69 lib - functions added
« Reply #2 on: September 23, 2013, 02:13:20 PM »
You sure can, but probably don't need to that often, maybe once every hour or something like that. Whenever the temperature is expected to change significantly.

john k2ox

  • Full Member
  • ***
  • Posts: 110
Re: Extended RFM69 lib - functions added
« Reply #3 on: September 23, 2013, 02:35:45 PM »
Wrong.
The RC cal is for a totally different purpose.  It is used to bring the radio out of sleep.

The problem is with the low cost 32MHz crystal.  I'm getting close to a solution that uses a combination of correction for temperature and the radios AFC(automatic frequency control) function. 

I see 32MHz TXCOs(temperature compensated cystal oscillator) for sale on EBAY for $20.  Cheap for a txco, but prob more than you want to pay. 

BTW, of the four radios I have, when set for 915MHz they are all low on frequency by 1000 to over 6200 Hz at the same temperature.  Then by simply fanning them with a sheet of paper I can shift the freq another 1000 Hz.

Stay tuned I'll have a software solution coming.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5939
  • Country: us
    • LowPowerLab
Re: Extended RFM69 lib - functions added
« Reply #4 on: September 23, 2013, 02:39:02 PM »
Oh, didn't know that. Maybe that's why I was seeing some weirdness when calling the rcCal() myself, sometimes it would stall...
Thanks for shedding the light, and also didn't know about the low freq. A solution to that issue would be great.

joao_ladeira

  • Newbie
  • *
  • Posts: 9
Re: Extended RFM69 lib - functions added
« Reply #5 on: September 23, 2013, 02:52:44 PM »
So im not sure iv understood correctly the purpose of the rc cal after reading this :p, this weekend iv implemented my code in a way if temperature drops or rises more than say 3 degrees it then calls the rc cal and sets that new temperature as new one.
Am i doing this wrong?
So if i understood correctly, instead of rc call i would have to call that new method you are working on (for AFC and temperature correction)  correct?

Best regards,
JL

john k2ox

  • Full Member
  • ***
  • Posts: 110
Re: Extended RFM69 lib - functions added
« Reply #6 on: September 23, 2013, 03:02:48 PM »
Cellphones would need to be recharged every couple hours if the receiver were always listening for a call.  To extend battery time they sleep say 1 second then they wakeup and listen say for 10mSec. This gives a 1% duty cycle, effectively extending battery charge a hundred times.

Rfm69s can use this same technique.  Set the listen registers on the battery powered mote and have the 'master' mote call it until it wakes up to answer.

Food for thought.

john

joao_ladeira

  • Newbie
  • *
  • Posts: 9
Re: Extended RFM69 lib - functions added
« Reply #7 on: September 23, 2013, 03:11:06 PM »
Nice :) , i think iv got it now.

So i will be waiting for that new software solution you have talked about :), if i can help with anything you can say.
I'm also thinking of deploy mines on the outside , im thinking of putting them as ground humidity and temperature sensors spread on a field (just a littlle below ground with the antenna poking out :p) so most probably i will encounter that problem of the broken link you were talking about :p.

JL

john k2ox

  • Full Member
  • ***
  • Posts: 110
Re: Extended RFM69 lib - functions added
« Reply #8 on: September 23, 2013, 03:19:43 PM »
take a look at AFC if you want to understand what is happening. The FEI block will tell you the difference between the  received signals frequency(tx) and the radios(rx) frequency.

You can set one radio to call the other every second or so. On the radio receiving enable AFC and read the FEI result.  Multiply it by FSTEP and Serial.print the result.  Now you can see how temp, your hand, and everything else conspires to disrupt communications due to the cheap xtal.

joao_ladeira

  • Newbie
  • *
  • Posts: 9
Re: Extended RFM69 lib - functions added
« Reply #9 on: September 23, 2013, 03:32:30 PM »
i will take a look on AFC, thanks :), so after that its just a matter of adjusting the right deviation correct?

john k2ox

  • Full Member
  • ***
  • Posts: 110
Re: Extended RFM69 lib - functions added
« Reply #10 on: October 01, 2013, 10:26:13 AM »
I've spent the last four days and nights trying to get stable temperature readings from the rfm69.  Finally, I believe I have something.  I had posted 'readTemp' and it was quite simple and performed as expected.  I was using it to transmit its temperature and all was fine.  When I started using it with Moteino receive code it didn't work and I discovered the radios mode needed to change to standby or syth. 

After that simple fix I found that about one in a hundred temp readings were out of the ballpark.  BAD BAD news if you are using the readings to correct for frequency drift.  All of a sudden your frequency jumps 10s of KHz off frequency.  So, if your code is set up to do a freq correction once every ten minutes, your radio would be listening/transmitting way off frequency.

I found that the radio continues to listen when in sythesizer mode and if it hears anything while you try to read the temp you get a corrupt measurement.  Standbye mode fixes it but, it takes more time to enter and exit this mode.  There is no mention of this in the datasheet.

It has been running in RX mode for 7 hrs. now taking a reading every second without a bad measurement.

Stay tuned I'll be posting the new 'readTemp()' and an updated 'tcfo()' functions after more testing.

john

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5939
  • Country: us
    • LowPowerLab
Re: Extended RFM69 lib - functions added
« Reply #11 on: October 01, 2013, 11:41:18 AM »
John,
I feel your pain. It was more or less the same experience building the driver for it. I think the datasheet is covering most things but subtleties are a lot of guesswork.
Thanks for all your efforts and time you're putting into this transceiver.
Looking forward to your updates.

john k2ox

  • Full Member
  • ***
  • Posts: 110
Re: Extended RFM69 lib - functions added
« Reply #12 on: October 01, 2013, 01:30:15 PM »
On a slightly different topic I have found sending a trigger and waiting for the status bit to go low is probably not the way to go.

Example:   

  writeReg(REG_XX, RF_ABCD);  //trigger an event
  while ((readReg(REG_XX) & (RF_ABCD_DONE)));  //stay here while the busy bit is set
  return (readReg(REG_XY);  // now get the value

I have experienced cases where this doesn't work as expected. i.e. checking if the 'mode' is ready, reading the temp...

What happens is that after the trigger is sent it the next line immediately checks to see if it is busy, but the radio is slow(slower than 328p) and hasn't set the bit yet.  It drops through and the reg is then read prematurely.

Using this seems to work:

  writeReg(REG_XX, RF_ABCD);  //trigger an event

  while ((readReg(XX) & RF_READY) == 0);   //wait until the radio catches up
  while ((readReg(XX) & RF_READY) == 1);   //stay here while it's busy
  while ((readReg(XX) & RF_READY) == 0);   //i'm sure it's done   <<<<  probly not neccessary

 return (readReg(REG_XY);  // now get the value


Also, I think it makes sense for your lib to block when changing modes until the 'mode ready' is valid.  Just a suggestion.

john

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5939
  • Country: us
    • LowPowerLab
Re: Extended RFM69 lib - functions added
« Reply #13 on: October 01, 2013, 01:40:10 PM »
Will have to revisit the mode switching but I think I recall trying that and running into some timing issues and lost packets.

bstott

  • Newbie
  • *
  • Posts: 37
Re: Extended RFM69 lib - functions added
« Reply #14 on: October 01, 2013, 04:22:03 PM »
Programming formatting question ---->

I see that John's RFM69NEW.h references/includes RFM69.h. His new example sketch calls out his revised library: RFM69NEW.h.

Here are my basic programming questions:

1) Is it this simple to add functions to someone else's library by creating your own NEW-LIBRARY.h file with new features and referencing "#include <OLD-LIBRARY.h>"?

2) To use both library's features - call out in your future sketches NEW-LIBRARY.h as "#include <NEW-LIBRARY.h>"?

3) You can now use old functions by calling out OLD-LIBRARY.h or have old & new features by only calling out the NEW-LIBRARY.h?