# LowPowerLab Forum

## Hardware support => RF - Range - Antennas - RFM69 library => Topic started by: perky on November 25, 2015, 02:00:56 PM

Title: Definition of RxBw with RFM69
Post by: perky on November 25, 2015, 02:00:56 PM
I'm trying to understand how to set the various radio paramemters for a RFM69CW, specifically the relationship between bit rate, frequency deviation and receiver bandwidth for FSK modulation.

So far I've seen these general rules, quoted here and in other places:
https://lowpowerlab.com/forum/index.php?topic=902.5;wap2

1)  0,5 <= 2 * Fdev / BR <= 10    (modulation index, MI)
2)  BR < 2 * RxBw     (bit rate)
3)  RxBw > 2 * Fdev     (receiver bandwidth)
4)  Fdev + BR / 2 < 500 kHz

I also have seen violations of these rules, especially the third rule, RxBw > 2 * Fdev.

One library I've seen has BR = 19.2kHz, Fdev = 38.4kHz, and RxBw = 41.6kHz. That gives a MI of 4. This apparently works though.

My understanding is if the MI is high then the energy is concentrated more around the two modulated frequencies, and if low it is more around the centre frequency, so with a high MI as in the above example you would expect a receiver bandwidth that includes the two modulated frequencies, Fc + Fdev and Fc - Fdev.

So is the definition of RxBw actually the width of the passband from the centre frequency outwards, and not for the whole bandwidth between the two modulated frequencies? The RFM69CW datasheet describes RxBw as "single side bandwidth". This would explain why the above example works, and would also mean rule 3 above is using the wrong definition of RxBw.

Title: Re: Definition of RxBw with RFM69
Post by: Felix on November 25, 2015, 03:44:01 PM
My first thought is that unless there was a copy error I would look at the semtech datasheets instead of the Hope ones: www.semtech.com/images/datasheet/sx1231h.pdf
Title: Re: Definition of RxBw with RFM69
Post by: perky on November 25, 2015, 07:28:00 PM
Yes, I've been looking at the sx1231h as well. The RxBx > 2*Fdev rule didn't come from there, or the RFM69CW spec, I found it on a post which I'm now questioning.

The sx1231h datasheet says that the 20dB bandwidth of a modulated signal is 2*(Fdev + BR/2). If RxBw is actually the sideband bandwidth, and there are two sidebands, then RxBw is half that, i.e. Fdev + BR/2. This formula actually comes from Carson's rule, Bt = 2(Fdelta + Fm) where Fdelta is the maximum deviation from the centre frequency (i.e. Fdev), and Fm is the modulation frequency, but the maximum modulation frequency is half the bit rate (i.e. BR/2) when transmitted as an alternating sequence of 0's and 1's. Bt contains ~98% of the energy of the transmission.

So it appears the optimum bandwidth RxBw = Fdev + BR/2, and RxBw must be equal or greater to this. Just to confirm this thinking, there is a restriction that
Fdev + BR/2 < 500kHz, and 500kHz happens to be the maximum you can select for RxBw. It all fits..!

That's not the full story though as there could be a local oscillator offset (i.e. difference between transmitters LO and the receiver's LO), and that needs to be taken into account:

If not using AFC:
RxBw >= Fdev + BR/2 + LOoffset.

If using AFC you can program the RxBwAfc independently (although I'm not sure how this effects the sensitivity, it can't be made too wide either or you risk 'capturing' an adjacent channel transmission):
RxBw >= Fdev + BR/2
RxBwAfc >=  Fdev + BR/2 + LOoffset

The crystal oscillator specification used on the RFM69 hasn't been disclosed by HopeRf, but has been empirically sampled by this guy who came to the conclusion that the deviation from worst case low frequency to worst case high frequency was around 10ppm at constant temperature/voltage, and at 868MHz this is around 8.68kHz. Very worst case is probably 20ppm, i.e. 17.36kHz as these are probably +/-10ppm crystals.
http://jeelabs.net/boards/6/topics/4624

So the final set of rules I think looks like this (if using AFC):

1)  0.5 <= 2 * Fdev/BR <= 10    (modulation index, MI)
2)  BR < 2*RxBw     (bit rate)
3)  RxBw >= Fdev + BR/2   (receiver bandwidth)
4)  RxBwAfc >=  Fdev + BR/2 + LOoffset (receiver AFC bandwidth)
5)  Fdev + BR/2 < 500kHz  (maximum RxBw setting)

Or this (if not using AFC):
1)  0.5 <= 2 * Fdev/BR <= 10    (modulation index, MI)
2)  BR < 2*RxBw     (bit rate)
3)  RxBw >=  Fdev + BR/2 + LOoffset (receiver bandwidth)
4)  Fdev + BR/2 < 500kHz  (maximum RxBw setting)

BTW the sx1231h appears to be rebadged by Microchip as MRF39RA, and also Freescale's MKW01Z128 and MC12311 look similar. The Freescale datasheets can sometimes be a little clearer to read.

I'm hoping someone can test this theory out with some range tests, I will be doing some tests at some point when I get some more hardware. Any comments on this welcomed.

Mark.
Title: Re: Definition of RxBw with RFM69
Post by: emjay on November 26, 2015, 05:38:17 AM
@perky,

Be very careful with the definition of Fdev - it varies from vendor to vendor and even on the same data sheet !
It can be either:

• The +/- deviation from a nominal (imaginary) central carrier Fc, seen as the two distinct transmitted frequencies of Fc + fdev, Fc - fdev
• The total deviation of the nominal (not imaginary) F1 (modulated to show a '1') and F0 (modulated to show a '0')

Ignoring sign (using a higher carrier frequency to represent a '1' is just by agreement between Tx and Rx) this gives:

Fdev = 2 x fdev  (the use of upper/lower case is not followed consistently in docs)

You see how easy it is for a factor of 2 to creep erroneously into the calculation of modulation index, RxBw etc.

You wrote: .. expect a receiver bandwidth that includes the two modulated frequencies, Fc + Fdev and Fc - Fdev

Indeed, that is essential (and more for the BR/2 + Offset) for successful demodulation. Now think about how a zero-IF receiver works - after the LNA stage, the incoming signal is mixed with a Local Oscillator tuned pretty close to the nominal imaginary Fc. The mixer stage produces the sum and differences  - yielding conveniently +/- fdev (using the first definition above).

Hmm - ok. So what is a negative frequency?  It is just the signal flipped 180º  So the output of the mixer is the modulating signal folded about Fc and then Fc set to 0 (i.e. DC).  This is where the terminology "single-sided" comes from for the RxBw. Phase and amplitude are preserved in the I & Q signals and passed to the demodulator.

All a bit simplified to aid the explanation - perhaps this sheds some light.

Title: Re: Definition of RxBw with RFM69
Post by: perky on November 26, 2015, 07:59:29 AM
Thanks for that explanation, that has shed some light on this. I'm surprised the datasheets don't explictly state that RxBw >= Fdev + BR/2, it's sort of implied when it states the bandwidth of the transmitted modulated signal but leaves it at that. Also a pictorial definition of what RxBw and Fdev are would make it easier to understand.

As this is a commercial product I'm designing I have to understand the reasons why certain parameters are chosen rather than just plugging in some third party library values and hoping for the best ;-) Just to confirm though, I have got these rules right?

Thanks,
Mark.
Title: Re: Definition of RxBw with RFM69
Post by: emjay on November 26, 2015, 09:31:04 AM
Quote
I have got these rules right?

Close enough for Government work  ;)
Title: Re: Definition of RxBw with RFM69
Post by: perky on November 26, 2015, 01:49:56 PM
OK, good to know  :D

BTW I think the RadioHead standard modem settings violate rules 3 and 4, in other words the receiver bandwidth is not set high enough for the frequency deviation and bit rate settings, and doesn't take into account local oscillator offsets either.

An example is modem config for 19.2 kbit/sec which is:
{ CONFIG_FSK,  0x06, 0x83, 0x02, 0x75, 0xf3, 0xf3, CONFIG_WHITE}, // FSK_Rb19_2Fd38_4

This sets the Fdev to 38.4kHz and BR to 19.2kb/s, and then sets RxBw and RxBwAfc to 41.7kHz which is not enough to allow all the signal energy through. If you then add a local oscillator offset of 20ppm which is the worst case difference in transmitter and receiver local oscillator frequencies  the AFC bandwidth is too small by some way.

I think the RadioHead default modem settings use way to high frequency deviation settings, probably to try to achieve a high modulation index, but a MI of 2 should be a good choice. If people are getting poor range this could be the reason.
Title: Re: Definition of RxBw with RFM69
Post by: Felix on November 26, 2015, 10:14:20 PM
Good discussion, I would add that there were some real tests performed in this thread (https://lowpowerlab.com/forum/index.php/topic,357.msg9787.html#msg9787) for temperature drift, which may add value to this topic although it may feel a bit offtopic with regards to RxBw.
Also if anyone that understands the RF technicalities better than the rest of us and would be willing to come up with a few tuned/optimized (and tested) set of settings for low bitrates as well as high, that would be really great.
Title: Re: Definition of RxBw with RFM69
Post by: perky on November 27, 2015, 06:54:11 AM
Thanks Felix. I hadn't seen that link, but actually adds weight to my assumption that the crystal used on the RFM69 modules is +/-10ppm, which at 868MHz makes LOoffset 20ppm or 17.4kHz.  The data in that link is consistent with this. An individual crystal could be anywhere within this tolerance so measuring just one module is not really representative and could give better results.

The standard low cost high accuracy crystal tolerance appears to be +/-10ppm though, tighter than that and the costs start to rise so this is a fair assumption given the empircal data. I'm really surprised that this data is not in the module specifications, it's actually vital when using narrow band transmission so that the RxBw and RxBwAfc can be calculated properly.
Title: Re: Definition of RxBw with RFM69
Post by: emjay on November 27, 2015, 08:31:31 AM
@perky,

Remember that the typical crystal spec is +/- 10ppm when selected from the manufacturing run at the vendor. You need to add on further variations:

• One time frequency "jump" from the stress of reflow
• One time board level installation variation due to track/placement tolerances and RF chip tolerances
• Temperature variation (well understood e.g as noted in that reference)
• Crystal aging - slow, usually monotonic drift as the crystal gets used
• Vdd dependency if Vdd is direct from a fading battery rather than an LDO

Fortunately these are not all in the same direction, so some error cancelling goes on.
The bottom line is that if you really need the narrowest bandwidths, you need some meta-scheme to track and adjust the actual offsets for long term reliability, especially in an increasingly busy ISM band.
Simply widening the RxBwAfc risks trouble from false signal capture.

This is why there are not a set of universal "magic numbers" for narrow bandwidth/low baudrate links.

You mentioned your design is for a commercial product - doesn't this suggest you can ask SemTech for guidance directly?

Title: Re: Definition of RxBw with RFM69
Post by: perky on November 27, 2015, 10:40:40 AM
Yes, that isn't an exhaustive list either. Stability of any load capacitors used (internal or external to the chip), linearity of crystal driver in the chip etc. On top of that this ppm value is statistical in that some (very few) might fall just outside of it.

I know in my system I'm not running over the whole temperature range of the module and Vdd is well regulated, even then I've added some margin to the calcs. It's the best I can do without actual specifications and additional information. BTW I'm not talking very narrow band here, my devation is set to 15kHz with 14.4kHz bit rate at the moment (MI of 2.47).

Although this is a commercial product it won't be big enough to get direct support from the manufacturers, I may get some limited support from distributors.
Title: Re: Definition of RxBw with RFM69
Post by: WhiteHare on December 26, 2015, 10:33:46 AM
In the absence of information about all the detailed factors (listed above) that might influence a "proper" calculation, what is nonetheless a reasonable number to use for Fdev if using FSK and BitRate=1200?

Extrapolating from the  RadioHead RF69 library pre-configured settings, the answer would be 2.4khz.  However, as noted in the discussion above, that number is suspect.  What would be a better number to use?

According to the RFM69 datasheet (section 3.3.3 FSK Modulation),

Fdev = Fstep x Fdev(13,0)

That formula answers the question most directly, but what are Fstep and Fdev(13,0)?  According to Table 5, Fstep has a typical value of 61Hz.  But what the heck does Fdev(13,0) refer to?

Looking at the RFM69's default values for possible insight, the default bitrate is 4.8kbps  and the default Fdev is 5Khz.  That suggests that for FSK and BitRate=1200, maybe Fdev can be much closer to 1200Hz than the 2400Hz extrapolated from the preconfigured values in RadioHead's RF69 library.

According to Section 3.4.11 on the FSK Demodulator, it is "most efficient" (whatever that means) when (2xFdev)/Bitrate is between 0.5 and 10.  If that's the primary consideration, then Fdev could be as low as 601 (because there's another rule which says Fdev must be greater than 600).

The 20db bandwidth is given as (2 x (Fdev + BitRate/2)), but I'm stuck without knowing what Fdev should be.  Can anyone here provide any guidance, or at least explain what Fdev(13,0) refers to?
Title: Re: Definition of RxBw with RFM69
Post by: perky on December 26, 2015, 05:13:03 PM
Fdev(13,0) in that equation is the full value in registers RegFdevMsb (register 0x05, containing bits 13-8), and RegFdevLsb (register 0x06, containg remaining bits 7-0).

You need to satisfy 0.5 > (2*Fdev/BR) < 10. I.e. modulation index must be between 0.5 and 10.

RxBw value must be half of the transmitted 20bB signal bandwidth, or greater, since RxBw is a single side bandwidth and there are two sidebands. so RxBw >= Fdev + BR/2.

RxBwAfc value must also take into account offset of TX and RX due to local oscillator difference, i.e. greater than Fdev + BR/2 + LOoffset.

Fstep is not exactly 61, the actual formula is FXOSC/2^19, or 61.03515625. This is important when calculating the actual frequency to transmit or receive on, the small fraction after the decimal point will offset your frequencies if ignored.

So I'll try to answer your question regarding a 'reasonable number for Fdev if using FSK and BitRate=1200'. Presumably you want RxBw and RxBwAfc to be as small as possible with narrow band transmission and therefore using AFC to increase sensitivity. I'll also assume 433MHz for the LOoffset calculation. So the following should work (untested, but I have no reason to believe these won't work from the data in the datasheet):

LOoffset = 20ppm @ 433MHz, = 8.66kHz.
RxBw = 2.6kHz, Fdev 1.1kHz, RxBwAfc = 10.4kHz, BR = 1.2kHz

Note that the LOoffset widens the RxBxAfc bandwidth considerably, this offset therefore has a major influence on sensitivity. Personally I feel a little uneasy at such low deviations, especially as the AFC is 'lumpy', so I think I'd probably sacrifice a bit of receiver bandwidth for greater deviation:

LOoffset = 20ppm @ 433MHz, = 8.66kHz.
RxBw = 3.9kHz, Fdev 2.4kHz, RxBwAfc = 12.5kHz, BR = 1.2kHz

Mark.
Title: Re: Definition of RxBw with RFM69
Post by: WhiteHat on December 27, 2015, 01:22:33 AM
@perky,

How did you arrive at:
RxBw = 2.6kHz, Fdev 1.1kHz, RxBwAfc = 10.4kHz
for the first set of numbers?  Also, how did you arrive at:
RxBw = 3.9kHz, Fdev 2.4kHz, RxBwAfc = 12.5kHz
for the second set of numbers?

In my case I'm using 915Mhz, so
LOoffset = 20ppm@915Mhz = 18,300
Title: Re: Definition of RxBw with RFM69
Post by: perky on December 27, 2015, 06:56:24 AM
RxBw and RxbwAfc can only have discrete values as given in the table in the datasheet and your goal is to keep these bandwidths as low as possible. The bit rate is already defined as 1200, and LOoffset is already defined. So if you pick an RxBw from the table the only variable you have left to fiddle with is Fdev to meet all of the constraints. I did it by trial and error, but this is a job for a spreadsheet really.
Title: Re: Definition of RxBw with RFM69
Post by: WhiteHare on December 27, 2015, 09:01:35 AM
Thanks for the clarification.  That solves the mystery.  I see that Table 14 in the datasheet must be the table of allowable bandwidths that you're referring to.

I think I was thrown off by the RadioHead RF69 library, which gives "a selected subset of common modulation types" and which doesn't even mention the corresponding bandwidths:
FSK_Rb2Fd5 = 0,      ///< FSK, Whitening, Rb = 2kbs,    Fd = 5kHz
FSK_Rb2_4Fd4_8,    ///< FSK, Whitening, Rb = 2.4kbs,  Fd = 4.8kHz
FSK_Rb4_8Fd9_6,    ///< FSK, Whitening, Rb = 4.8kbs,  Fd = 9.6kHz
FSK_Rb9_6Fd19_2,   ///< FSK, Whitening, Rb = 9.6kbs,  Fd = 19.2kHz
FSK_Rb19_2Fd38_4,  ///< FSK, Whitening, Rb = 19.2kbs, Fd = 38.4kHz
FSK_Rb38_4Fd76_8,  ///< FSK, Whitening, Rb = 38.4kbs, Fd = 76.8kHz
FSK_Rb57_6Fd120,   ///< FSK, Whitening, Rb = 57.6kbs, Fd = 120kHz
FSK_Rb125Fd125,    ///< FSK, Whitening, Rb = 125kbs,  Fd = 125kHz
FSK_Rb250Fd250,    ///< FSK, Whitening, Rb = 250kbs,  Fd = 250kHz
FSK_Rb55555Fd50,   ///< FSK, Whitening, Rb = 55555kbs,Fd = 50kHz for RFM69 lib compatibility

Because of that, I had gathered the erroneous impression that bandwidth was a dependent value, derived from BitRate and FDEV.

Interestingly, the radiohead library states "If you need another configuration, use the register calculator.  and call setModemRegisters() with your desired settings.  "  So, it would appear that there does exist some kind of calculator for the RFM69, perhaps a spreadsheet similar to the RF22B calculator:  https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=1&cad=rja&uact=8&ved=0ahUKEwjd1vGPlvzJAhXEbiYKHYyUAcwQFggcMAA&url=http%3A%2F%2Fwww.hoperf.com%2Fupload%2Frf%2FRF22B%252023B%252031B%252042B%252043B%2520Register%2520Settings_RevB1-v5.xls&usg=AFQjCNGlwgyomYH-WSWInI2winrQu1Oq6A&bvm=bv.110151844,d.eWE

Anyone seen a register calculator for the RFM69?
Title: Re: Definition of RxBw with RFM69
Post by: WhiteHare on December 27, 2015, 09:31:14 AM
Partially answering my own question, it appears that Semtech does have a "calculator" of sorts for the SX1231.  It's documented here:  http://www.semtech.com/images/datasheet/sx1231skb-userguide.pdf

However, the software doesn't seem to work without the corresponding hardware connected.   I don't see an offline mode where it could be used to what-if configurations.  :'(
Title: Re: Definition of RxBw with RFM69
Post by: perky on December 28, 2015, 05:12:30 PM
I've not seen a 'calculator' as such for RFM69, but a speadsheet that calculates an optimum settings from the set of RxBw and RxBwAfc values allowable and given BR would be really handy.

The RadioHead common configurations select entries in the 'modem configuration' array, which are 8 byte entries that set modulation type, Fdev, BR, RxBw and RxBwAfc. These have been pre-configured beforehand, their bandwidth values have (supposedly) been selected for you. And yes, there's no indication in the name as to what they have been set to.

Mark.
Title: Re: Definition of RxBw with RFM69
Post by: WhiteHare on January 08, 2016, 04:27:55 PM
So, in the end did you stick with LOoffset as 20ppm?  Without a dataset of actual measurements to draw upon, or some other references that would be analogous or inform insight, I don't know what more one can do.

With RxBw = 2.6kHz, Fdev 1.1kHz, LOoffset = 20ppm@915Mhz = 18.300kHz, it's easy to see that the Tx and Rx bandwidths might have zero overlap.  How well does the AFC actually work?

As a supplement, I can imagine the Tx sending calibration packets over a range of different frequencies below and above its set frequency, and the Rx using the results of what it receives to better tune itself to the Tx frequency.  It's rather brute force, but maybe it would pay off if going for extreme range.  Also, it would be a way of building up a dataset to better inform what LOoffset actually is between a particular pair of transceivers.
Title: Re: Definition of RxBw with RFM69
Post by: WhiteHare on January 28, 2016, 10:49:29 AM
Parsing the Semtech chip defaults for the SX1231h and figuring their values, it looks like Semtech went for a pretty wide RxBwAfc of 50KHz:

Code: [Select]
``Packet Mode, FSK modulation scheme[ActualBitrate] 4799.760bps = nominal bitrate of 4800bps[regRXBW] B1010101[theDccFreq] B10[RxBw] 10416Hz  [RxBwMant] 24  [RxBwExp] 5[regAFCBW] B10001011[theDccFreqAfc] B100[RxBwAfc] 50000Hz  [RxBwMantAfc] 20  [RxBwExpAfc] 3[FDev] 5004Hz[frequency-center] 915000000Hz``

That's in contrast to the calculations in the posting directly above, which suggests that at 915Mhz (the worst case) Semtech  might have gone as narrow as 10,416Hz + 18,300kHz = 28.716KHz (though in actuality, by rounding up, the next closest match in Table 14 would have been 31.3Khz). The 50Khz figure that Semtech actually settled on as its default for AFC bandwidth was much wider.  Any theories as to why?  I'm just trying to get as much insight as I can to best inform how to set AFC bandwidth when using non-default settings, and working backward from Semtech's defaults is another way to triangulate what Semtech thinks are good numbers.
Title: Re: Definition of RxBw with RFM69
Post by: emjay on January 28, 2016, 12:56:10 PM
@WhiteHare,

Two opposing issues:

Set the AfcBw much wider than RxBw and still capture those sloppy crystals... but let in extra noise power, so not good for very weak signals and/or capture by adjacent channel activity.

Title: Re: Definition of RxBw with RFM69
Post by: perky on January 28, 2016, 01:12:10 PM
Yep, the silicon defaults are 10.4kHz for RxBw and 50kHz for RxBwAfc, it assumes a rather sloppy crystal being used. The 20ppm LOoffset difference between TX and RX assumes 10ppm crystals, reasonably common and nowadays pretty cheap, but if a 20 ppm crystal was used (cheaper run-of-the-mill crystal) at 915MHz you're looking at Fdev+ BR/2+ LOoffset = 5kHz + 2.5kHz +  36.6kHz = 44.1kHz, and the closest one to that is 50kHz.
Title: Re: Definition of RxBw with RFM69
Post by: emjay on January 28, 2016, 03:04:12 PM
Here is some data taken from a sample of over 100 RFM69 modules at room temperature with a measuring system with better than 0.5ppm accuracy.
(http://RFM69CW_Crystal_deltas.jpg)
You see a systematic ~2.5 ppm lower than target plus a reasonable "normal" spread around that mean.
Using +/- 10ppm is a generous estimate allowing for a relatively "small" sample.
Title: Re: Definition of RxBw with RFM69
Post by: perky on January 29, 2016, 06:20:11 AM
I saw that original post about crystals. This appears to show a close tolerance, but we don't know whether these modules are part of the same batch or whether the crystals were part of the same batch. In theory the manufacturer of the cystals, or the model, could be changed without our knowledge too. Given that it is best to have a low tolerance crystal, and the most common generic low cost crystal is 10ppm, it's highly probable that 10ppm spec crystals were used here and is a reasonable assumption IMO.
Mark.
Title: Re: Definition of RxBw with RFM69
Post by: emjay on January 29, 2016, 09:31:58 AM
@Mark,

Actually drawn from three different manufacturing lots, spread over about 9 months.
We are in violent agreement that 10ppm is a good working estimate.
Title: Re: Definition of RxBw with RFM69
Post by: perky on January 29, 2016, 11:25:23 AM
OK, what do you think the spec of the crystal is?
Title: Re: Definition of RxBw with RFM69
Post by: WhiteHare on January 29, 2016, 12:26:59 PM
What frequency were the tested crystals?

I vaguely recollect Felix saying that the 868Mhz and 915Mhz RFM69 modules were identical (though, maybe I'm mis-remembering, and it was the LoRa modules) , and, if so, I was never clear as to which crystal was actually used on it.  Might the  ppm's be "effectively" worse if, say, it turned out to be an 868Mhz crystal forced to operate in the 902-928Mhz range?  Or would it simply not matter?

Title: Re: Definition of RxBw with RFM69
Post by: perky on January 29, 2016, 12:37:43 PM
The crystal is 32MHz on all modules, you can't force it to be any other. The 868MHz and 915MHz frequencies are genereated by a PLL in the chip, so they would have slightly different values programmed in their registers by software.  The 'identical' thing might be that the passives around the sx1231h, specifically around the antenna area, may have the same values as the frequencies are close.
Title: Re: Definition of RxBw with RFM69
Post by: WhiteHare on January 29, 2016, 12:51:06 PM
Wow, I was way off the mark.   :-[   Thanks for clearing that up.

In any case, as implicitly defined in perky's calculations (above), presently:
Loffset = 2*(ppm)*(center frequency in Hz)
Title: Re: Definition of RxBw with RFM69
Post by: emjay on January 29, 2016, 01:14:41 PM
@Mark,

Quote
The 'identical' thing might be that the passives around the sx1231h, specifically around the antenna area, may have the same values as the frequencies are close

No, the L/C values for the mesh between the chip and antenna are different values (HopeRF have different builds for 868 & 915 MHz modules)  They are similar so the mismatch with the antenna is modest, but recall that the mesh is dual function - matching and bandpass filtering to clean up the out of band hash from the Tx section. Working in the "wrong" band has an acceptable signal strength degradation (IIRC <3dBm), but risks making the spurious emissions well out of spec.
Title: Re: Definition of RxBw with RFM69
Post by: perky on January 29, 2016, 02:46:47 PM
OK, thanks for clearing that up.
Title: Re: Definition of RxBw with RFM69
Post by: WhiteHare on February 04, 2016, 04:55:47 AM
BTW, Freescale did some interesting measurements on the AFC's performance.  Among the conclusions were:

"...with AFC operation disabled a 15 to 20 kHz error in frequency results in drastically worse sensitivity. This is about 10% of the RXBW. Whereas with AFC enabled about +/- 150 kHz error can be tolerated.

With AFC enabled the frequency error as much as +/- 100 to 150 kHz can be corrected for. Nearly 10 times as much frequency error can be tolerated without AFC. Care should be taken that AFCBW is not set so wide as to allow adjacent channel signals to be received."

http://cache.nxp.com/files/rf_if/doc/app_note/AN4983.pdf?fpsp=1&WT_TYPE=Application%20Notes&WT_VENDOR=FREESCALE&WT_FILE_FORMAT=pdf&WT_ASSET=Documentation&fileExt=.pdf
Title: Re: Definition of RxBw with RFM69
Post by: wrb010 on March 19, 2016, 07:24:35 PM
Partially answering my own question, it appears that Semtech does have a "calculator" of sorts for the SX1231.  It's documented here:  http://www.semtech.com/images/datasheet/sx1231skb-userguide.pdf

However, the software doesn't seem to work without the corresponding hardware connected.   I don't see an offline mode where it could be used to what-if configurations.  :'(

Thanks for the link for the sx1231skb starter kit software.  Please note that Mike McCauley in his RadioHead RH_RF69.CPP software notes mentions to get the software to work without connected you have to hit the "Ctl-Alt-N" keys.   ;D
Title: Re: Definition of RxBw with RFM69
Post by: WhiteHare on March 19, 2016, 08:25:17 PM
Partially answering my own question, it appears that Semtech does have a "calculator" of sorts for the SX1231.  It's documented here:  http://www.semtech.com/images/datasheet/sx1231skb-userguide.pdf

However, the software doesn't seem to work without the corresponding hardware connected.   I don't see an offline mode where it could be used to what-if configurations.  :'(

Thanks for the link for the sx1231skb starter kit software.  Please note that Mike McCauley in his RadioHead RH_RF69.CPP software notes mentions to get the software to work without connected you have to hit the "Ctl-Alt-N" keys.   ;D

@wrb010 Thank you!  I tried the magic key sequence you posted, and it works!   :)
Title: Re: Definition of RxBw with RFM69
Post by: WhiteHare on March 30, 2016, 10:30:02 PM
For 915Mhz center frequency, the default numbers used in the RFM69 library translate to:
Bitrate: 55,556
FDev: 49,988
Rx Bandwidth: 125,000
AFC Bandwidth:  100,000

For comparison, plugging these numbers into the calculator shows that the same FDev would also support a Bitrate of 200,000.  Alternatively, for a bitrate of 55,556, FDev could be as low as 13,977.

Although the calculator does put-up a red-flag if FDev is too low for a given Bitrate, or if the Bitrate is too high for a given FDev, it doesn't red-flag either of the bandwidths if they are incongruent with Fdev, nor does it red-flag if the Rx and AFC bandwidths are incongruous with each other.  That makes the Semtech calculator less useful than if it were to check whether all the numbers satisfy all the constraints stated in the datasheet, as I was hoping that it might.

So, all in all, the calculator is perhaps partially useful.  For instance, it does appear to compute a DCC frequency for both the Rx and AFC bandwidths.  Also, the calculator will automatically translate whatever figures you give it into the corresponding register values, which might be a useful cross-check.

Title: Re: Definition of RxBw with RFM69
Post by: perky on March 31, 2016, 02:39:10 AM
Interesting, so it only partially implements the rules below (maybe only rule 1):

1)  0.5 <= 2 * Fdev/BR <= 10    (modulation index, MI)
2)  BR < 2*RxBw     (bit rate)
3)  RxBw >= Fdev + BR/2   (receiver bandwidth)
4)  RxBwAfc >=  Fdev + BR/2 + LOoffset (receiver AFC bandwidth)
5)  Fdev + BR/2 < 500kHz  (maximum RxBw setting)

I'm not sure why the AFC bandwidth would be set less than the Rx bandwidth, that makes no sense. Are you sure it's not the other way round? What's needed I think is a spreadsheet that does the above, unfortunately I haven't got time to write one :-(.
Mark.
Title: Re: Definition of RxBw with RFM69
Post by: joelucid on April 01, 2016, 10:51:11 AM
Quote
Interesting, so it only partially implements the rules below (maybe only rule 1):

Looks to me like all rules are satisfied. Felix does not use AFC - so I don't know how the AFC Bandwidth would be significant.
Title: Re: Definition of RxBw with RFM69
Post by: perky on April 01, 2016, 02:14:17 PM
I was referring to the calculator in Whitehare's post, which only seems to red those that violate rule 1. There are some configs in the library that don't meet them all though:
https://lowpowerlab.com/forum/index.php/topic,1434.msg9976.html#msg9976
Mark.
Title: Re: Definition of RxBw with RFM69
Post by: WhiteHare on April 01, 2016, 02:19:41 PM
What are the upsides, if any, of using a larger FDev than the minimum required for a given bitrate?  As I pointed out above, the FDev could be much less and still support the same 55,556 bitrate.

There does seem to be a tangible downside, which is the larger bandwidth would imply less range at the same bitrate.  Are there advantages to using the larger FDev which offset that downside?

For instance, at very low bitrates (say at 1200 OTA bitrate), it would seem that using the minimal FDev that still satisfies the rules might have a downside if the actual Tx and Rx frequencies were to drift too far apart.  If nothing was in place to adequately compensate or correct for that, then I can imagine that maybe using a larger FDev than just the minimum that's theoretically required might make sense as an easy tactic for avoiding that particular pitfall.

So, if it's true that the RFM69 library isn't using AFC (I had just assumed that it was, so that's news to me), then perhaps the larger FDev for the 55,556 bitrate is what compensates for not using AFC?
Title: Re: Definition of RxBw with RFM69
Post by: perky on April 01, 2016, 02:43:06 PM
I don't think there are any, wideband is used mainly for higher bandwidths (and more complex things like spread spectrum) but comes at a cost, the receiver bandwidth has to be high and the increased noise leads to shorter range. Also for high modulation indices using FM the energy in the transmitted signal is spread out more and peaks around the two modulation frequencies, whereas low MI peaks around the carrier, so for a high MI with high receiver bandwidth a significant portion of that bandwidth carries little signal energy but atill contributes to noise. I'd go for low MI with AFC for range.
Mark.
Title: Re: Definition of RxBw with RFM69
Post by: joelucid on April 01, 2016, 03:08:59 PM
Quote
What are the upsides, if any, of using a larger FDev than the minimum required for a given bitrate?

One big advantage: you can use high TX power and still comply with FCC regulations. See http://www.semtech.com/images/datasheet/fcc_digital_modulation_systems_semtech.pdf for example:

At 4.8kbaud an FDev of 150khz allows you to use 7.5dBm TX power. At 5khz you're allowed -1dBm - a much lower link budget. The table in the doc also makes it just abundantly clear how far from the legal constraints we operate with 55kbaud, FDev = 50khz and a TX power of 20 dBm (rfm69hw).

If you want to legally take full advantage of the rfm69hw there's really no way around frequency hopping it appears.

Joe
Title: Re: Definition of RxBw with RFM69
Post by: WhiteHare on April 01, 2016, 04:33:27 PM
Though I may well be wrong, I believes we're still FCC legal at 915Mhz up to an actual transmit power of 18.9dbm (that would be the maximum allowed), provided that extra rules are followed wrt duty cycle to avoid jamming the channel:  https://lowpowerlab.com/forum/index.php/topic,1498.msg10506.html#msg10506
Title: Re: Definition of RxBw with RFM69
Post by: joelucid on April 01, 2016, 05:03:06 PM
Quote
I believes we're still FCC legal at 915Mhz up to an actual transmit power of 18.9dbm

Ah yes, the duty cycle correction. Thanks for reminding me. Of course this doesn't work well with the low bitrates we've been discussing recently, but generally you're right.
Title: Re: Definition of RxBw with RFM69
Post by: WhiteHare on April 02, 2016, 01:13:44 AM
Are you sure it's not the other way round?

Yup, I'm confident it's not the other way around.  Using a Moteino outfitted with an RFM69HW and compiling the RFM69 library's Gateway example sketch (but, for simplicity's sake, with "#define ENABLE_ATC" commented out) using Arduino IDE 1.0.6, Felix's enhanced register dump is:
Code: [Select]
``Address - HEX - BIN1 - 10 - 10000Controls the automatic Sequencer ( see section 4.2 )SequencerOff : 0 -> Operating mode as selected with Mode bits in RegOpMode is automatically reached with the SequencerEnables Listen mode, should be enabled whilst in Standby mode:ListenOn : 0 -> Off ( see section 4.3)Aborts Listen mode when set together with ListenOn=0 See section 4.3.4 for details (Always reads 0.)Transceiver's operating modes:Mode : 001 -> Standby mode (STDBY)2 - 0 - 0Data Processing mode:DataMode : 00 -> Packet modeModulation scheme:Modulation Type : 00 -> FSKData shaping: in FSK:ModulationShaping : 00 -> no shaping3 - 2 - 104 - 40 - 1000000Bit Rate (Chip Rate when Manchester encoding is enabled)BitRate : 555555 - 3 - 116 - 33 - 110011Frequency deviationFdev : 499597 - E4 - 111001008 - C0 - 110000009 - 0 - 0RF Carrier frequencyFRF : 914472960A - 41 - 1000001RC calibration control & statusRcCalDone : 1 -> RC calibration is overB - 40 - 1000000Improved AFC routine for signals with modulation index lower than 2.  Refer to section 3.4.16 for detailsAfcLowBetaOn : 0 -> Standard AFC routineC - 2 - 10ReservedD - 92 - 10010010Resolution of Listen mode Idle time (calibrated RC osc):ListenResolIdle : 10 -> 4.1 msResolution of Listen mode Rx time (calibrated RC osc):ListenResolRx : 01 -> 64 usCriteria for packet acceptance in Listen mode:ListenCriteria : 0 -> signal strength is above RssiThresholdAction taken after acceptance of a packet in Listen mode:ListenEnd : 01 -> chip stays in Rx mode until PayloadReady or Timeout interrupt occurs.  It then goes to the mode defined by Mode. Listen mode stops and must be disabled (see section 4.3)E - F5 - 11110101F - 20 - 10000010 - 24 - 10010011 - 7F - 111111112 - 9 - 100113 - F - 111114 - 40 - 100000015 - B0 - 1011000016 - 7B - 111101117 - 9B - 1001101118 - 8 - 100019 - 42 - 10000101A - 8A - 100010101B - 40 - 10000001C - 80 - 100000001D - 6 - 1101E - 10 - 100001F - 0 - 020 - 0 - 021 - 0 - 022 - 0 - 023 - 0 - 024 - CE - 1100111025 - 40 - 100000026 - 7 - 11127 - D8 - 1101100028 - 0 - 029 - DC - 110111002A - 0 - 02B - 0 - 02C - 0 - 02D - 3 - 112E - 88 - 100010002F - 2D - 10110130 - 64 - 110010031 - 0 - 032 - 0 - 033 - 0 - 034 - 0 - 035 - 0 - 036 - 0 - 037 - 90 - 1001000038 - 42 - 100001039 - 0 - 03A - 0 - 03B - 0 - 03C - 8F - 100011113D - 13 - 100113E - 73 - 11100113F - 61 - 110000140 - 6D - 110110141 - 70 - 111000042 - 6C - 110110043 - 65 - 110010144 - 45 - 100010145 - 6E - 110111046 - 63 - 110001147 - 72 - 111001048 - 79 - 111100149 - 70 - 11100004A - 74 - 11101004B - 4B - 10010114C - 65 - 11001014D - 79 - 11110014E - 1 - 14F - 0 - 050 - 15 - 1010151 - 85 - 1000010152 - 88 - 1000100053 - 8 - 100054 - 0 - 055 - 0 - 056 - 1 - 157 - 0 - 058 - 1B - 1101159 - 9 - 10015A - 55 - 10101015B - 80 - 100000005C - 70 - 1110000``
---------------------------------------------------------------------

Taking my own independent pass at the register data, I get:
Code: [Select]
``Radio Configuration:====================Receiver-Mode(RX)Packet Mode, FSK modulation schemeRegDioMapping1=B1000000=0x40RegDioMapping2=B111=0x7[ActualBitrate] 55555.554bps[theDccFreq] B10 (equals Semtech default)[b][RxBw] 125000Hz[/b]  [RxBwMant] 16  [RxBwExp] 2[b][FDev] 49987Hz[/b]Beta=((2*FDev)/BitRate)=0.62Fcutoff=4973.59Hz  Percentage=3.98%Warning: low Beta.  Setting DCC to 100b=1%.  Enabling AfcLowBetaOn.  Setting RX LO = 104Hz (which equals 12.5% of FDev)[theDccFreqAfc] B100 (equals Semtech default)[b][RxBwAfc] 100000Hz[/b]  [RxBwMantAfc] 20  [RxBwExpAfc] 2[frequency-center] 915000000Hz[regLNA] B1000  [LnaZin] B0 -> Input Impedance = 50 ohm (Warning: Semtech default is 200 ohm).  [LnaCurrentGain] B1 -> G1  [LnaGainSelect] B0 -> gain set by the internal AGC loop.  Matches Semtech default.[regAFCFEI] B10000  [FeiDone] B0 -> FEI is on-going (i.e. not finished).  Matches Semtech default.[b]  [AfcDone] B1 -> AFC is finished (i.e. not on-going). [/b] Matches Semtech default.  [AfcAutoclearOn] B0 -> Invalid, because AfcAutoOn is not set.  [AfcAutoOn] B0 -> AFC is performed each time AfcStart is set (i.e. not each time Rx mode is entered).               ^Matches Semtech default.---------------------------------------------------------------------``

This also confirms JoeLucid's earlier comment that the RFM69 library defaults to a mode where AFC is turned off.   ???  Not only that, but I notice from the datasheet that even Semtech's default is for AFC to be turned off.  Why is that?

[Edit1: So, the answer must be that the AFC is simply not needed at these higher bandwidths.  At what point does it become needed/beneficial to turn on the AFC?  Ideally, that might be done automatically, which means getting a grasp on what the threshhold conditions are that should trigger turning AFC on.]

[Edit2: Reviewing the results of the automatic review, I guess maybe in some sense the library settings actually do have low beta, though I'm not sure that it matters (?).  I didn't expect to see that, and so it came as a surprise.  The commentary about the ensuing automatic adjustments to compensate for low-beta is work in progress, so you can ignore that part, as I'm not sure it is applicable for an FDev this wide. ]

Title: Re: Definition of RxBw with RFM69
Post by: WhiteHare on April 02, 2016, 03:05:41 PM
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?
Title: Re: Definition of RxBw with RFM69
Post by: Felix 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.
Title: Re: Definition of RxBw with RFM69
Post by: MikeH 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?
Title: Re: Definition of RxBw with RFM69
Post by: Felix 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.
Title: Re: Definition of RxBw with RFM69
Post by: perky 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/ (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.
Title: Re: Definition of RxBw with RFM69
Post by: Felix 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.
Title: Re: Definition of RxBw with RFM69
Post by: perky 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.
Title: Re: Definition of RxBw with RFM69
Post by: clysm 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:

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.
Title: Re: Definition of RxBw with RFM69
Post by: LukaQ 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
Title: Re: Definition of RxBw with RFM69
Post by: clysm 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.
Title: Re: Definition of RxBw with RFM69
Post by: perky 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.
Title: Re: Definition of RxBw with RFM69
Post by: Felix on February 14, 2018, 08:38:24 AM
@LukaQ, nice work.
Can you export to excel/xlsx and post it to this thread?
Title: Re: Definition of RxBw with RFM69
Post by: clysm 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.
Title: Re: Definition of RxBw with RFM69
Post by: LukaQ on February 15, 2018, 01:20:06 AM
@LukaQ, nice work.
Can you export to excel/xlsx and post it to this thread?