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

perky

  • Hero Member
  • *****
  • Posts: 871
  • Country: gb
Re: Definition of RxBw with RFM69
« Reply #30 on: January 29, 2016, 02:46:47 PM »
OK, thanks for clearing that up.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1297
  • Country: us
Re: Definition of RxBw with RFM69
« Reply #31 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

wrb010

  • Newbie
  • *
  • Posts: 1
  • Country: us
Re: Definition of RxBw with RFM69
« Reply #32 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

[Edit: here is a download link for the software:  http://www.semtech.com/apps/filedown/down.php?file=sx1231starter-kit-setup.exe]

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

WhiteHare

  • Hero Member
  • *****
  • Posts: 1297
  • Country: us
Re: Definition of RxBw with RFM69
« Reply #33 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

[Edit: here is a download link for the software:  http://www.semtech.com/apps/filedown/down.php?file=sx1231starter-kit-setup.exe]

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!   :)

WhiteHare

  • Hero Member
  • *****
  • Posts: 1297
  • Country: us
Re: Definition of RxBw with RFM69
« Reply #34 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.




« Last Edit: March 30, 2016, 10:36:22 PM by WhiteHare »

perky

  • Hero Member
  • *****
  • Posts: 871
  • Country: gb
Re: Definition of RxBw with RFM69
« Reply #35 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.

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Definition of RxBw with RFM69
« Reply #36 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.

perky

  • Hero Member
  • *****
  • Posts: 871
  • Country: gb
Re: Definition of RxBw with RFM69
« Reply #37 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.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1297
  • Country: us
Re: Definition of RxBw with RFM69
« Reply #38 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?
« Last Edit: April 01, 2016, 02:32:47 PM by WhiteHare »

perky

  • Hero Member
  • *****
  • Posts: 871
  • Country: gb
Re: Definition of RxBw with RFM69
« Reply #39 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.

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Definition of RxBw with RFM69
« Reply #40 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

WhiteHare

  • Hero Member
  • *****
  • Posts: 1297
  • Country: us
Re: Definition of RxBw with RFM69
« Reply #41 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 

joelucid

  • Hero Member
  • *****
  • Posts: 869
Re: Definition of RxBw with RFM69
« Reply #42 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.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1297
  • Country: us
Re: Definition of RxBw with RFM69
« Reply #43 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 - BIN
1 - 10 - 10000
Controls the automatic Sequencer ( see section 4.2 )
SequencerOff : 0 -> Operating mode as selected with Mode bits in RegOpMode is automatically reached with the Sequencer

Enables 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 - 0
Data Processing mode:
DataMode : 00 -> Packet mode

Modulation scheme:
Modulation Type : 00 -> FSK

Data shaping: in FSK:
ModulationShaping : 00 -> no shaping

3 - 2 - 10
4 - 40 - 1000000
Bit Rate (Chip Rate when Manchester encoding is enabled)
BitRate : 55555

5 - 3 - 11
6 - 33 - 110011
Frequency deviation
Fdev : 49959

7 - E4 - 11100100
8 - C0 - 11000000
9 - 0 - 0
RF Carrier frequency
FRF : 914472960

A - 41 - 1000001
RC calibration control & status
RcCalDone : 1 -> RC calibration is over

B - 40 - 1000000
Improved AFC routine for signals with modulation index lower than 2.  Refer to section 3.4.16 for details
AfcLowBetaOn : 0 -> Standard AFC routine

C - 2 - 10
Reserved

D - 92 - 10010010
Resolution of Listen mode Idle time (calibrated RC osc):
ListenResolIdle : 10 -> 4.1 ms

Resolution of Listen mode Rx time (calibrated RC osc):
ListenResolRx : 01 -> 64 us

Criteria for packet acceptance in Listen mode:
ListenCriteria : 0 -> signal strength is above RssiThreshold

Action 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 - 11110101
F - 20 - 100000
10 - 24 - 100100
11 - 7F - 1111111
12 - 9 - 1001
13 - F - 1111
14 - 40 - 1000000
15 - B0 - 10110000
16 - 7B - 1111011
17 - 9B - 10011011
18 - 8 - 1000
19 - 42 - 1000010
1A - 8A - 10001010
1B - 40 - 1000000
1C - 80 - 10000000
1D - 6 - 110
1E - 10 - 10000
1F - 0 - 0
20 - 0 - 0
21 - 0 - 0
22 - 0 - 0
23 - 0 - 0
24 - CE - 11001110
25 - 40 - 1000000
26 - 7 - 111
27 - D8 - 11011000
28 - 0 - 0
29 - DC - 11011100
2A - 0 - 0
2B - 0 - 0
2C - 0 - 0
2D - 3 - 11
2E - 88 - 10001000
2F - 2D - 101101
30 - 64 - 1100100
31 - 0 - 0
32 - 0 - 0
33 - 0 - 0
34 - 0 - 0
35 - 0 - 0
36 - 0 - 0
37 - 90 - 10010000
38 - 42 - 1000010
39 - 0 - 0
3A - 0 - 0
3B - 0 - 0
3C - 8F - 10001111
3D - 13 - 10011
3E - 73 - 1110011
3F - 61 - 1100001
40 - 6D - 1101101
41 - 70 - 1110000
42 - 6C - 1101100
43 - 65 - 1100101
44 - 45 - 1000101
45 - 6E - 1101110
46 - 63 - 1100011
47 - 72 - 1110010
48 - 79 - 1111001
49 - 70 - 1110000
4A - 74 - 1110100
4B - 4B - 1001011
4C - 65 - 1100101
4D - 79 - 1111001
4E - 1 - 1
4F - 0 - 0
50 - 15 - 10101
51 - 85 - 10000101
52 - 88 - 10001000
53 - 8 - 1000
54 - 0 - 0
55 - 0 - 0
56 - 1 - 1
57 - 0 - 0
58 - 1B - 11011
59 - 9 - 1001
5A - 55 - 1010101
5B - 80 - 10000000
5C - 70 - 1110000


---------------------------------------------------------------------


Taking my own independent pass at the register data, I get:
Code: [Select]
Radio Configuration:
====================
Receiver-Mode(RX)
Packet Mode, FSK modulation scheme
RegDioMapping1=B1000000=0x40
RegDioMapping2=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.62
Fcutoff=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. ]






« Last Edit: April 02, 2016, 03:30:18 PM by WhiteHare »

WhiteHare

  • Hero Member
  • *****
  • Posts: 1297
  • Country: us
Re: Definition of RxBw with RFM69
« Reply #44 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? 
« Last Edit: April 02, 2016, 03:29:46 PM by WhiteHare »