Author Topic: LoRa Library experiences / range  (Read 135180 times)

dave_sausages

  • NewMember
  • *
  • Posts: 49
Re: LoRa Library experiences / range
« Reply #15 on: December 07, 2015, 01:39:34 PM »
+1 for wanting to know what parameters to change to increase the range of the LoRa modules from default. Current range going through 1 brick wall and several cars is 150-170metres using default "reliable datagram" sketches.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: LoRa Library experiences / range
« Reply #16 on: December 07, 2015, 01:58:52 PM »
For "the next guy":  I'm noticing the RadioHead library consumes a lot of the available memory on a Moteino LR.  For that reason, it may be worth purchasing the Moteino Mega LR instead, unless doing something very simple.

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 6866
  • Country: us
    • LowPowerLab
Re: LoRa Library experiences / range
« Reply #17 on: December 09, 2015, 08:02:56 AM »
+1 for wanting to know what parameters to change to increase the range of the LoRa modules from default. Current range going through 1 brick wall and several cars is 150-170metres using default "reliable datagram" sketches.

See this post for some explanations.

syrinxtech

  • Sr. Member
  • ****
  • Posts: 347
  • Country: us
    • Syrinx Technologies
Re: LoRa Library experiences / range
« Reply #18 on: December 11, 2015, 05:38:12 PM »
Has anyone tried connecting the Moteino/LoRA to either an ENCJ2860 or Wi5100 Ethernet card?  I have several Moteino's with the RFM69 radios working with both Ethernet cards and no problems.  I usually move the SS/CS pin to 7 and modify the appropriate library.

Today I tried doing the same thing with a Moteino/LoRa and it continually kept restarting in the IDE monitor window.  I tried both the standard Ethernet library and the UIPEthernet libraries with no luck.  I have used both of these libraries with the RFM69 radios.  The problem arises when the code gets to the Ethernet.begin(mac) line of the code.  At that point the monitor screen keeps scrolling as the unit resets.

I have tried changing the SS on the ENCJ2860 chip like I do with the RFM69 radios with no luck.  I have also tried changing both the interrupt and CS of the radio.  Even if I comment out all traces of the LoRa radio in my sketch, as soon as the Ethernet.begin() line is executed everything goes south.

Any tips or pointers would be appreciated.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: LoRa Library experiences / range
« Reply #19 on: December 11, 2015, 07:43:38 PM »
Just a WAG, but I'd suggest checking how much free memory you have available.

syrinxtech

  • Sr. Member
  • ****
  • Posts: 347
  • Country: us
    • Syrinx Technologies
Re: LoRa Library experiences / range
« Reply #20 on: December 11, 2015, 08:37:11 PM »
Thanks WhiteHare, I'll check that value.


WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: LoRa Library experiences / range
« Reply #21 on: January 02, 2016, 03:50:28 PM »
A closer read of the datasheet reveals that to get maximum range, you need a TCXO.  That buys you an extra 8dB of receive sensitivity.  Would it be practical/feasible to supplement the RFM95 with a TXCO, or would should that be baked into the module itself?

Nuudeli

  • NewMember
  • *
  • Posts: 14
Re: LoRa Library experiences / range
« Reply #22 on: January 06, 2016, 01:57:31 PM »
Depending on the case you could do just fine with temperature compensation on software side. See this post: https://lowpowerlab.com/forum/index.php/topic,357.0.html

Of course, someone should complete similar measurements for RFM95. Let see if I find some inspiration to do that after getting modules I ordered.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: LoRa Library experiences / range
« Reply #23 on: January 06, 2016, 02:45:56 PM »
I was calling attention to what the official Semtech SX1276 datasheet is stating, which is:

"for all bandwidths lower than 62.5 kHz, it is advised to use a TCXO as a frequency reference. This is required to
meet the frequency error tolerance specifications given in the Electrical Specification
- Higher spreading factors and longer transmission times impose more stringent constraints on the short term
frequency stability of the reference."

Table 12 shows the difference in sensitivity that results from using xtal instead of tcxo, and it's a sizable difference.  You need 50 ppm accuracy or better to use spreading factor 12.  Is that possible with a software-only temperature calibration?  With a spreading factor of 12, a packet might take 10+ seconds to send/receive, and I suppose one question is whether the temperature might shift enough over that time interval (perhaps from self-heating?) to throw a software-only temperature calibration out of wack.

For whatever reason, that information didn't find its way into the HopeRF datasheet.    ;)

Anyhow, it would be great if you're right.  Please do post if you get it to work.
« Last Edit: January 06, 2016, 04:46:36 PM by WhiteHare »

Nuudeli

  • NewMember
  • *
  • Posts: 14
Re: LoRa Library experiences / range
« Reply #24 on: January 07, 2016, 02:11:21 PM »
Well, a good point! Didn't remember that LoRa requires significantly larger transmitting time than normal FSK to achieve very long range . That can cause serious self heating depending on the power level which could wreck the idea.

Table 12 shows that sensitivity improvement comes from narrowing RXBW, not from reference clock itself.  50ppm (which is requirement for 125kHz RXBW case, datasheet page 21) accuracy is easy to achieve with normal XTAL. I did measure ~10ppm drift over temperatures with RFM69HCW with initial offset smaller than 3ppm. Initial offset can be easily calibrated with ~20dollars SDR. If XTAL is similar/same as in RFM69, quite long range without TCXO could be achieved.

Actually, it could be possible to characterize the self-heating during transmission, but SW correction is not possible while transmitting?


WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: LoRa Library experiences / range
« Reply #25 on: January 07, 2016, 04:52:11 PM »
I did receive a reply from one Lora module manufacturer who claims they use 10ppm xtal crystals, and they said that "They seem to work reliably down to BW=20.8".  Anyone know what the specs are on the crystals that Hoperf uses?

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: LoRa Library experiences
« Reply #26 on: January 08, 2016, 07:33:00 PM »

Subjectively, this setup seemed to send more roundtrip packets successfully when standing still than when moving, even within my own house and even then at fairly short distances.  (i.e. it seems to do better when everything is stationary).  Call it an impression.  I don't have hard data that would prove it to a skeptic.

Apparently g-forces from motion can change the crystal frequency enough to matter (at least according to http://www.semtech.com/images/datasheet/an120014-xo-guidance-lora-modulation.pdf:  "Thus it is recommended that for those applications which may be subjected to acceleration forces, such as shock or vibration, for example where the SX1272 is implemented in a mobile link (such as a handheld or vehicle mount application, a low-g crystal is used as the reference oscillator. "), so I'm going to guess that explains my impression above.

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: LoRa Library experiences / range
« Reply #27 on: January 08, 2016, 09:20:11 PM »
I did receive a reply from one Lora module manufacturer who claims they use 10ppm xtal crystals, and they said that "They seem to work reliably down to BW=20.8".  Anyone know what the specs are on the crystals that Hoperf uses?

There's some inferential evidence that the xtal in the RFM69 is 10ppm (https://lowpowerlab.com/forum/index.php/topic,1434.msg9957.html#msg9957), so maybe HopeRF uses the same crystal in its RFM95.  Admittedly, that's purely just a WAG.  Wouldn't you be surprised, though, if HopeRF put a worse crystal in the LoRa than it puts into the RFM69?

Here's the rub:  using the Semtech Lora calculator,  it would appear that the required ppm is a function not of the spreading factor but rather of bandwidth.  According to the calculator, at a bandwidth of 31.25kHz (which is what I tested with a pair of Moteino LoRa's), the max crystal offset is 8.5ppm.  In comparison, at a bandwidth of 20.8kHz, the max crystal offset is 5.7ppm, and at a bandwidth of 7.1kHz the max crystal offset is 2.1ppm.  So, maybe that explains why 31.25kHz is the narrowest of the RadioHead preconfigured settings.

So, assuming that's true, is there a way to compensate in software if it turns out that the HopeRF module uses 10ppm or even 20ppm crystals?  Maybe.  Here's an idea, and maybe you all can help me vet it.  According to the datasheet, if you're running the Tx at maximum power, you're limited to a 1% duty cycle.  So, suppose you run the Tx at low enough power that you can instead run it at 100% duty cycle.  [What Tx power would that be?  Simply anything that's not the maximum?]  The idea is that the module would warm up but eventually reach a steady state where the temperature is constant (let's assume ambient temperature is constant, or else  that won't be true and this gets more difficult).  Likewise, run the receiver in constant Rx mode, so that it too reaches a steady state temperature (same ambient temperature assumption).  Let's assume voltages are held rigidly  constant, so that we can ignore that as a possible cause of variances in frequency offset.   Let's assume both sender and receiver are stationary, so g-forces are not a factor.  With those assumptions, is there anything else that might cause variations in the frequency offset?   If not, then the crux of the idea is that the Tx module could programmatically (and purposefully) send packets at a range of frequencies above and below its set frequency with the aim that some of them will closely align with the receiver's Rx band.

If that holds water, then
1. the above method suggests redundant packet transmissions at different frequencies is a shotgun way of getting some packets through, and
2. the receiver could take note of which packets get through the best and adjust its frequency accordingly so as to better align with the Tx frequency.

Through progressive refinement from further iterations, perhaps the receiver could be well tuned to the transmitters frequency, despite using less than ideal crystals.  If the above possibly/probably unrealistic assumptions of duty cycle and ambient temperature needed to support method #2 can't be met, then at least there's still the shotgun technique of method #1. 

At least on its face, does that idea hold water?  Or did I fail to account for something? 

WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: LoRa Library experiences / range
« Reply #28 on: January 09, 2016, 03:47:25 AM »
This evening, starting with Bw31_25Cr48Sf512 (which equates to spreading factor 9) on two nodes, I was able to upgrade both transceivers to run at spreading factor 10, and both continued to work without incident.  However, when I upgraded from spreading factor 10 to 11 or 12, neither spreading factor 11 nor 12 would work.


WhiteHare

  • Hero Member
  • *****
  • Posts: 1300
  • Country: us
Re: LoRa Library experiences / range
« Reply #29 on: January 09, 2016, 12:38:37 PM »
In case anyone else wants to try, here's a function I wrote for setting the spreading factor:

Code: [Select]
boolean setSpreadingFactor(byte SF) { // abort and return FALSE if new spreading factor not in acceptable range; otherwise, set spreading factor and return TRUE
  uint8_t currentSF, newLowerNibble, newUpperNibble, current_register_1E_value, new_register_1E_value;
  if ((SF >= 6) && (SF <= 12)) {// only set if the spreading factor is in the proper range
    current_register_1E_value = rf95.spiRead(0x1E);
    Serial.print(F("Current value of RF95 register 0x1E = "));
    Serial.println(current_register_1E_value, HEX);
    currentSF = current_register_1E_value >> 4;  //upper nibble of register 0x1E
    Serial.print(F("Current spreading factor = "));
    Serial.println(currentSF, HEX);
    newLowerNibble = (current_register_1E_value & 0x0F); //same as old lower nibble
    newUpperNibble = (SF << 4); // upper nibble equals new spreading factor
    new_register_1E_value = (newUpperNibble + newLowerNibble);
    rf95.spiWrite(0x1E, new_register_1E_value);
    Serial.print(F("New spreading factor = "));
    Serial.println(SF);
    Serial.print(F("New value of register 0x1E = "));
    Serial.println(new_register_1E_value, HEX);
    return true;
  }
  else {
    return false;
  }
}

Then, after the typical initializing, the setup loop is just this:
Code: [Select]
  rf95.setModemConfig(RH_RF95::Bw31_25Cr48Sf512);  //set for pre-configured long range
  setSpreadingFactor(10);
  rf95.printRegisters();  //Print all the RFM95 register values

The debug output after running it is what you'd expect and confirms the new spreading factor was successfully set:
Code: [Select]
Current value of RF95 register 0x1E = 94
Current spreading factor = 9
New spreading factor = 10
New value of register 0x1E = A4
1: 81
6: E4
7: C0
8: 0
9: 88
A: 9
B: 2B
C: 20
D: 0
E: 0
F: 0
10: 0
11: 0
12: 0
13: 0
14: 0
15: 0
16: 0
17: 0
18: 10
19: 0
1A: 0
1B: 0
1C: 0
1D: 48
1E: A4
1F: 64
20: 0
21: 8
22: 1
23: FF
24: 0
25: 0
26: 0
27: 0

« Last Edit: January 09, 2016, 01:11:26 PM by WhiteHare »