Author Topic: Definition of RxBw with RFM69  (Read 18050 times)

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5681
  • Country: us
    • LowPowerLab
Re: Definition of RxBw with RFM69
« Reply #45 on: April 04, 2016, 11:17:32 AM »
Here's where I'm going with this:  right now, I find that changing a radio setting manually is rather cumbersome because those changes often affect what other settings then should be.  I'm starting to toy with the idea that there maybe should really be just two primary levers, which are bitrate and Tx power, and that changing bitrate should *automatically* change the  secondary settings to optimally conform.  Does anyone besides just me perceive a benefit in that approach?    Setting aside the issue of Tx power, is there any reason to think that the optimal settings could not be reduced to a simple lookup table, with bitrate as the primary key?
I tend to agree and I can't think of a reason, from all I know it seems the majority of important settings follow the bitrate.

MikeH

  • Newbie
  • *
  • Posts: 2
Re: Definition of RxBw with RFM69
« Reply #46 on: July 21, 2017, 06:05:44 PM »
After digesting this information, a couple of questions came to mind.  1.  Pertaining to the crystal tolerance, a figure of 20 ppm was used in providing guidance to choose certain settings.  However, at the bottom of page 31 there is a statement saying that the range is more like 50 to 100 ppm.  Is this a reference to something different?

The second Q I have regards the aging of these radios.  I have a pair of 915 MHz RFM69HCs that I have been using for some time (3 mo) that work predictably.  Recently I purchased some replacement parts from a NA Hope distributor as backups.   The problem is that while the newer parts will  communicate with each other, they do not communicate with the older radios.  In my testing, I use the same hardware and software, initializing the radios identically.  At first I thought that perhaps I was dealing with a manufacturing variation but after reading about the possible changes that can occur over time I am wondering if it might be aging related.  Do you think that it is possible for two radios to communicate with some devices but not others when all conditions and settings are equal, and if so, is the solution a matter of individually tuning one radio or the other? 

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5681
  • Country: us
    • LowPowerLab
Re: Definition of RxBw with RFM69
« Reply #47 on: July 21, 2017, 07:04:50 PM »
Mike, you should not assume the parts/crystals were identical off the production line.
That's however very strange to see something like that. I've never had a problem with very old (first generation) RFM69 radios talking to the most new ones.
I would make sure your source is trusty and the radios you get are "new" condition not used or rejects or something like that.
The best way to see what's going on is look at the spectrum, and without a spectrum analyzer that's going to be a bit more tricky. You could "tune" the frequency of one of the nodes up/down until you start receiving on the other end (and keep going until the RSSI is the best - that's when your 2 frequencies are overlapping the most) - then you get an idea how far apart the drifty side is.
Or you could try to use AFC which is another technique, you'd then have to determine the corrected frequency as explained in the datasheet. I would do it by hand as I mentioned above as the easiest way, if you don't have an analyzer.

perky

  • Hero Member
  • *****
  • Posts: 870
  • Country: gb
Re: Definition of RxBw with RFM69
« Reply #48 on: August 06, 2017, 08:14:21 AM »
I've been looking at this a lot more, and come to some rather unfortunate conclusions. There are three contributions to tolerance:

1) absolute frequency
2) temperature deviation
3) ageing

Joelucid posted a generic specification for the crystal used on the RFM69.
https://lowpowerlab.com/forum/rf-range-antennas-rfm69-library/datasheet-of-xtal-currently-used-in-rfm69hw/

This puts 1) as +/-10PPM, 2) as +/-20PPM, but doesn't mention ageing. A resonable assumption would be +/-3PPM for the first year and +/-1PPM per year thereafter, this appears to be a very common ageing specification for these crystal types. So for a 10 year life product we can set that to about +/-12PPM.

So the total is +/-(10+20+12) = +/-42PPM. I've had to pull tricks with my design, like using AFC and calibrating it to a known accurate TX signal, and using a simple linear temperature compensation curve. That halves the temperature value and reduces the absolute to about +/=3PPM.

So I can only get it down to +/-25PPM.

Mark.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5681
  • Country: us
    • LowPowerLab
Re: Definition of RxBw with RFM69
« Reply #49 on: August 07, 2017, 09:13:34 AM »
Mark,
Thanks for the concise summary of your findings. Would you be able to share more details of how you achieve the steps you mention?

I've had to pull tricks with my design, like using AFC and calibrating it to a known accurate TX signal, and using a simple linear temperature compensation curve. That halves the temperature value and reduces the absolute to about +/=3PPM. So I can only get it down to +/-25PPM.

perky

  • Hero Member
  • *****
  • Posts: 870
  • Country: gb
Re: Definition of RxBw with RFM69
« Reply #50 on: August 09, 2017, 11:35:20 AM »
Hi Felix,

I can't go into much detail code wise as I'm under NDA, but I can tell you the general priciples.

First you need to measure temperature accurately, I use a NTC resistor network with an accurate voltage reference source and read it with the ADC. When using AFC the frequency offset from a TX signal to your local oscillator is available in the FEI register, and you can use that to adjust your programmed TX and RX frequencies in the FRF register to match it.

So in production you can lock to a master with an accurate frequency (maybe using a TXCO) at around room temperature and save the offset in EEPROM so your board can compensate for it. A normal production environment is subject to a little temperature variance and its inherent absolute frequency inaccuracy and aging, so that's why only +/-3PPM can realistically be achieved. You may need to to place the TXCO every few years for the aging spec.

The code then uses the accurate temperature measurement and compensates for +/-10PPM using a straight line curve passing through 0 at 25degC. Given the S curve for a crystal is either flat or bent this effectively reduces your temperature error from +/-20PPM to about +/-10PPM. It will over-compensate if your crystal happens to be +/-3PPM for example, and you'll get -/+7PPM, but the worst case is always +/-10PPM.

The aging can't be compensated for.

Mark.

clysm

  • Newbie
  • *
  • Posts: 3
Re: Definition of RxBw with RFM69
« Reply #51 on: February 13, 2018, 09:24:11 PM »
Since I didn't see a link to an online calculator, I decided to make one in google sheets:

https://docs.google.com/spreadsheets/d/1IPxalBKDRDwBtlrxC0cMvN3pJiuh05a8nivPxnWrvjc/edit#gid=0

Given a center frequency and desired bitrate, it'll calculate the F_DEV, RxBw, and RxBwAfc settings to use. It shows the intermediate values calculated as well.

I implemented this in my own RFM69 library with the algorithm in the spreadsheet and have had good results. I'm able to go between 1kbps and 300kbps, from edge to edge of the 915Mhz ISM band, within my home without too much trouble.



This forum was immensely helpful in getting my own implementation working, so I thank everyone for posting.
« Last Edit: February 14, 2018, 09:24:21 AM by clysm »

LukaQ

  • Sr. Member
  • ****
  • Posts: 271
  • Country: si
Re: Definition of RxBw with RFM69
« Reply #52 on: February 14, 2018, 03:40:06 AM »
I have also made "online" calculator with google sheets for every important register, but didn't share it because you can't set file to be changed, but each time you reload, it would goes back to original state (doesn't save it)

Oh and you enter the register values in HEX and then it auto calculates everything to show you what your changes did
« Last Edit: February 14, 2018, 03:42:14 AM by LukaQ »

clysm

  • Newbie
  • *
  • Posts: 3
Re: Definition of RxBw with RFM69
« Reply #53 on: February 14, 2018, 08:02:27 AM »
That's a really comprehensive table you have. Sharing would be beneficial, even as view-only, since people can save it to their own google drive or save it locally for modification.

Another option I was considering toying with is making the F_DEV expand to fill up the quantized RxBw settings. Since the filter is going to accept, say, 7800Hz, it might be best to use all available bandwidth instead of limiting the signal to 7500Hz. I've updated the spreadsheet with an additional calculation for this. I haven't tested this setting to see how beneficial, if at all, it may be.

perky

  • Hero Member
  • *****
  • Posts: 870
  • Country: gb
Re: Definition of RxBw with RFM69
« Reply #54 on: February 14, 2018, 08:28:00 AM »
These are very useful contributions, thanks!

Another thing you might want to consider is channel spacing if you have multiple channels, this will depend on the size of the guard band, receiver bandwidths and local oscillator offsets. In fact if channel spacing is your controlling factor then other things like BR and FDEV and RxBw may need to be optimized to fit. They're all inter-related! ;)

Mark.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5681
  • Country: us
    • LowPowerLab
Re: Definition of RxBw with RFM69
« Reply #55 on: February 14, 2018, 08:38:24 AM »
@LukaQ, nice work.
Can you export to excel/xlsx and post it to this thread?

clysm

  • Newbie
  • *
  • Posts: 3
Re: Definition of RxBw with RFM69
« Reply #56 on: February 14, 2018, 09:32:07 AM »
Oh boy... If I was going to consider guard bands, I'd also want to consider the Gaussian filter / data shaping settings. That's a bit above me at the moment.

LukaQ

  • Sr. Member
  • ****
  • Posts: 271
  • Country: si
Re: Definition of RxBw with RFM69
« Reply #57 on: February 15, 2018, 01:20:06 AM »