LowPowerLab Forum

Hardware support => RF - Range - Antennas - RFM69 library => Topic started by: ColinR on September 02, 2015, 06:09:48 PM

Title: LoRa Library experiences / range
Post by: ColinR on September 02, 2015, 06:09:48 PM
Hi all,

I'd like to know if any of you have spent time working with the LoRa Radiohead library. I want badly to switch to LoRa radios, but have heard that the library is lacking some pretty basic features, such as support for ACK, and does not include any encryption. This is pretty unfortunate.

Can you all share your stories, workaround, and any plans to bring the library up to the quality of the current RFM?

Cheers,
C
Title: Re: LoRa Library experiences
Post by: Felix on September 03, 2015, 09:28:31 AM
Hi Colin,
Just to share my current thoughts publicly ... I have made basic changes to the RadioHead LoRa library (RFM95 branch under it) to make it compile and run on Moteinos and MoteinoMEGAs with LoRa radios (RFM95 stocked at LowPowerLab, but this should work with any RFM92-98 with proper frequency adjustments). Note that RFM92-98 radios are the same thing, except the differences are in frequency not in anything else, they are all 20dBm (100mW) output power.
So the RF95_client and RF95_server examples is what I use to test the MoteinoLR and MoteinoMEGA-LoRa units. From my little interaction with RadioHead (http://www.airspayce.com/mikem/arduino/RadioHead/) it looks like there are the following options, quoting from the library page:

Quote
The following Mangers are provided:

RHDatagram Addressed, unreliable variable length messages, with optional broadcast facilities.
RHReliableDatagram Addressed, reliable, retransmitted, acknowledged variable length messages.
RHRouter Multi-hop delivery from source node to destination node via 0 or more intermediate nodes, with manual routing.
RHMesh Multi-hop delivery with automatic route discovery and rediscovery.

So that would include "ACKs", please see RadioHead for more info on this. I hope to have more time in the near future to play more with this as well.
Title: Re: LoRa Library experiences
Post by: ColinR on September 03, 2015, 01:38:14 PM
Mesh, you say. I will have to dig more into this when mine shown up. Thanks for sharing.

Colin
Title: Re: LoRa Library experiences
Post by: gpsklaus on September 16, 2015, 06:32:53 AM
Hi All,
with a lot of success i am already using LoRa RFM98W for transmitting GPS navigation data.
Received data can be seen on OLED display and also are available serially for external use.
Used sketches are based on software originally created by Stuart Robinson, UK.
His ideas can be found here: http://www.rcgroups.com/forums/showthread.php?t=2454546

See also my page ( still in preparation ): http://www.kh-gps.de/lora.htm
Future intension is using board MOTEINO LR.

Klaus

 
Title: Re: LoRa Library experiences
Post by: Felix on September 16, 2015, 08:11:59 AM
Klaus,
Thanks for your input, nice resources, is there a particular library you used or was it all in the sketches that you linked?
Title: Re: LoRa Library experiences
Post by: gpsklaus on September 16, 2015, 08:53:16 AM
Hi Felix,
i am using the libraries as provided by Stuart Robinson via Dropbox: https://goo.gl/TYsFBf

Schematics on my page:  http://www.kh-gps.de/lora.htm are showing interconnection between processor and LoRa chip. So, after adding two additional wires, this also should run when using MOTEINO LR boards.

Klaus
Title: Re: LoRa Library experiences
Post by: ColinR on September 16, 2015, 02:44:59 PM
Felix,

Have you yet looked at this library?

Still no encryption. What's the best way to build this in?

C
Title: Re: LoRa Library experiences
Post by: Felix on September 17, 2015, 10:48:31 AM
I have not. It's not a library, just a sketch.
By virtue of the modulation scheme, the encryption is basically almost not needed. If you really want to, you can implement a soft encryption the same way it's done in the RFM12B library (https://github.com/LowPowerLab/RFM12B).
Title: Re: LoRa Library experiences
Post by: ColinR on September 21, 2015, 12:07:58 PM
How about a dedicated encryption engine, such as the ATAES132A? They're about a buck.

C
Title: Re: LoRa Library experiences
Post by: Felix on September 21, 2015, 12:17:07 PM
It could work, if you go that route I'd get AES256.
Title: Re: LoRa Library experiences
Post by: ColinR on September 21, 2015, 12:29:28 PM
I don't see an Atmel with greater than 128. Could probably just get an extra 328 and drop a library/sketch on there.

C
Title: Re: LoRa Library experiences
Post by: WhiteHare on December 01, 2015, 11:16:56 AM
Hi Felix,
i am using the libraries as provided by Stuart Robinson via Dropbox: https://goo.gl/TYsFBf

Schematics on my page:  http://www.kh-gps.de/lora.htm are showing interconnection between processor and LoRa chip. So, after adding two additional wires, this also should run when using MOTEINO LR boards.

Klaus

Hi Klaus,

I visited your web page.  Very nice work!  If I am understanding your results correctly, you achieved a transmission distance of 2,500 meters.  Is that correct? 

A few questions:
1.  What radio settings did you use (e.g. Tx power, bitrate, bandwidth, etc.) to achieve that range? 
2.  At what elevation was your LoRa transmitter?  It appears that your LoRa receiver was at the height of your car dashboard, is that correct?  What I'd really like to know is: what was the difference between the elevation of the Transmitter and the elevation of the Receiver [i.e. (Height of Transmitter) - (Height of Receiver)]?
3.  At the distance of 2,500 meters, about what percentage of packets were getting lost?
Title: Re: LoRa Library experiences
Post by: WhiteHare on December 01, 2015, 01:03:54 PM
I soldered the headers and the provided antenna wire onto some Moteino LR's this morning and loaded the example client and server sketches onto a couple of them (actually, the client came preloaded on the Moteino LR, which makes verifying new Monteino LR's easy).  Applying power to Vin and without making any other modifications, I put the LoRa server in a second story window and then walked around the neighborhood just now, simply looking at the blinking light on the LoRa client to ascertain whether there was a viable roundtrip connection or not.  With only that crude method, I'd estimate I  was getting viable communication within a 500+ foot radius using whatever the defaults are in Felix's adapted Radiohead RF95 sketches.

As far as fresh out of the box experiences go, I'd rate this one as very satisfying.   :)

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.
Title: Re: LoRa Library experiences
Post by: joffers on December 01, 2015, 01:32:01 PM
I had a similar great out of the box experience using Moteino and RadioHead. I was easily able to verify multiple RadioHead client/server examples. Yesterday I put one of the MoteinoMegaLR in the car and drove around the neighborhood. Mind you the radio was in the car, sometime windows open/sometimes not.  With the server in my living room near a window (about 9 ft off the ground) I was able to get pretty consistent results at 640 meters through a heavy urban and wooded area (Seattle). After driving into a deep valley and then up a hill I got again consistent results at 1280 meters while just holding the radio near the open car window.  I was so excited I forgot to print out the signal strength but I'll be doing more tests and will post them here :)
Title: Re: LoRa Library experiences / range
Post by: WhiteHare on December 05, 2015, 12:28:29 PM
From reading the .h file, all the default settings are for medium range.  It offers two prebuilt settings for long range, though i'm not savvy enough yet to know which of the two would be the absolute longest range.  Is it the 32khz one?

The good news for indoor use is that the tx power can be adjusted across the full range (unlike the rfm69).  Also, the rx current is less.  I'll need to try the short range settings to get a better feel for how the two compare in real life though.

Title: Re: LoRa Library experiences / range
Post by: dave_sausages 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.
Title: Re: LoRa Library experiences / range
Post by: WhiteHare 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.
Title: Re: LoRa Library experiences / range
Post by: Felix 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 (https://lowpowerlab.com/forum/index.php/topic,1274.msg10156.html#msg10156).
Title: Re: LoRa Library experiences / range
Post by: syrinxtech 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.
Title: Re: LoRa Library experiences / range
Post by: WhiteHare on December 11, 2015, 07:43:38 PM
Just a WAG, but I'd suggest checking how much free memory you have available.
Title: Re: LoRa Library experiences / range
Post by: syrinxtech on December 11, 2015, 08:37:11 PM
Thanks WhiteHare, I'll check that value.

Title: Re: LoRa Library experiences / range
Post by: WhiteHare 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?
Title: Re: LoRa Library experiences / range
Post by: Nuudeli 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 (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.
Title: Re: LoRa Library experiences / range
Post by: WhiteHare 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.
Title: Re: LoRa Library experiences / range
Post by: Nuudeli 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?

Title: Re: LoRa Library experiences / range
Post by: WhiteHare 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?
Title: Re: LoRa Library experiences
Post by: WhiteHare 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.
Title: Re: LoRa Library experiences / range
Post by: WhiteHare 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? 
Title: Re: LoRa Library experiences / range
Post by: WhiteHare 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.

Title: Re: LoRa Library experiences / range
Post by: WhiteHare 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

Title: Re: LoRa Library experiences / range
Post by: syrinxtech on June 15, 2017, 07:29:23 AM
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?

Could someone post a specific URL for the Semtech LoRa calculator?  I tried downloading it yesterday and was told I had to create an account first.  After filling in a bunch of information I received an email stating that I wasn't allowed to join their club because my work email indicated I was involved in computer/network security and not IoT.  Therefore I was deemed unworthy to join.  What?  I thought the goal was to encourage as many people as possible to use this new technology?  The reason I wanted the calculator is because I have to LoRa radios on my desk that I want to experiment with.....they said if I could prove I had an interest in IoT I could reapply.  No thanks.  Sorry, stepping down off the soapbox.  Apologies to Felix and everyone else.
Title: Re: LoRa Library experiences / range
Post by: WhiteHare on June 15, 2017, 07:09:42 PM
Maybe try this:  http://www.semtech.com/apps/filedown/down.php?file=SX1272LoRaCalculatorSetup1%271.zip
Title: Re: LoRa Library experiences / range
Post by: syrinxtech on June 15, 2017, 10:57:03 PM
Many thanks @WhiteHare!!!

Title: Re: LoRa Library experiences / range
Post by: syrinxtech on April 01, 2018, 09:47:30 AM
Funny.....I joined the Semtech group the other day with no problem and they provided the link so I could download the calculator.

I guess time does heal all wounds and patience is really a virtue.
Title: Re: LoRa Library experiences / range
Post by: fgomes on July 16, 2018, 07:04:44 AM
Hi, I'm currently testing the RFM95W 868MHz radios (have used the RFM69WH in previous projects), and in the first tests I have noticed a strange behaviour. I'm using the Radiohead lib, and configured the following parameters on both nodes:

    rf95.setFrequency(868.0);
    rf95.setTxPower(23, false); // Also tried with 20
    rf95.setModemConfig(RH_RF95::Bw125Cr48Sf4096);

I'm observing a low RSSI even with nodes close (rf95.lastRssi() reads between -50 and -70 with nodes 2 m apart), and goes down to -100dBm with nodes in the same floor but in separate rooms. I have a setup with the RFM69HW radios where I read about -25 or -30dBm for nodes side by side, and for the nodes in the same floor but in different rooms (exactly in the same places where I tested the RFM95W) I read around -60dBm instead of -100dBm. Do you know any configuration problem that can lead to this behaviour? Or could the transceivers be damaged? I'm using a wire as a monopole 1/4 wave antenna without a ground plane, soldered directly in the transceiver antenna pin (similar situation with the RFM69HW radios).

Didn't have yet the opportunity to do a range test (this would be the next step), but until I can clarify this fast RSSI drop the range test will be meaningless.

Best regards

Fernando

Title: Re: LoRa Library experiences / range
Post by: Felix on July 16, 2018, 11:54:14 AM
Can you compare against a known working set of RFM95W nodes?
Are you testing settings randomly to see what works?
How are the RFM95 vs the RFM69HW soldered? You still have a bit of GND plane on the PCB of the module. But you have to ensure you compare apples to apples and not make assumptions that if one works then the other also has to work.
Title: Re: LoRa Library experiences / range
Post by: fgomes on July 16, 2018, 08:37:22 PM
Hi Felix,

Thanks for your comment, the units are similar with the first experiences I made with RFM69, the transceivers are soldered in a breakout board, connected by jumper wires to ATMEGA boards.  I currently don't have other RFM95W nodes, and rotating the ones I have I get similar results. These were just some quick tests, I have some situations where a bit extra range could be extremely useful (I have to use nodes as repeaters in some situations when I use RFM69 radios), so this was just a simple first evaluation of the RFM95W radio. After your message I've added a ground plane below the radio/antenna (and a decoupling capacitor on the RFM95W power supply pins), the results are now better, but the RSSI is still lower when compared with the RFM69 (and the RFM69 don't have the ground plane below the 1/4 wave monopole). But for the RFM95 it had a positive impact, now I have about -38 / -40 dBm in nodes close, and in the same scenario  I had -100dBm now I'm reading -73dBm, so the antenna ground plane / decoupling capacitor on the radio power supply did have a very positive impact on the RSSI level, all the rest being equal.
But I think that the RSSI difference could also be related to the different technologies and radio configuration used, this was the reason for my question in the first place, is it expected or not that the RSSI level would be different when using RFM95 versus RFM69, both at 20dBm output power?
I've noticed some posts referred to the use of the maximum output power at 20dBm and others at 23dBm (setTxPower), besides the legal aspects, is the RFM95 really capable of generating 23dBm? I've only saw 20dBm on its datasheet.

Best regards

Fernando
Title: Re: LoRa Library experiences / range
Post by: Felix on July 17, 2018, 09:21:26 AM
The RFM95/96 can only output 100mW (20dBm).
I would tweak the settings and compare differences there.
Also you can get extended RFM69 range by lowering the bitrates and narrowing the bandwidth. There are various threads in the forum about this, some code shared etc.
Title: Re: LoRa Library experiences / range
Post by: fgomes on July 17, 2018, 11:30:07 AM
Hi Felix,

Thanks once again, I was just testing the RFM95W to see if they are an easy alternative to longer range scenarios (up to 2km without buildings but with some valleys / mountains between nodes, I know about the RFM69 low bit rate settings and have done some tests as well and I have participated in these discussions, the problem when going that way is the stability with temperature (temperature compensation), frequency offset compensation, etc., but going the LoRa way seems to be also tricky since the long-range configuration settings might also need a TCXO to use high SF and low bandwidth. I'll keep testing both scenarios

Best regards

Fernando