Long Range IoT Networks - Chapter 2 | Particle + LoRa Better together

I agree with @Rftop - Even a few feet makes a BIG difference. I think farther the distance the more height you need based on the Fresnel zone. In a very unscientific way, I tested about 2,000’ through a woods. At “knee” level would not communicate, at “waist” level would marginally communicate maybe 50% of the time with very low RSSI, at “shoulder” level jumped RSSI by maybe 5 points and communicated all the time, at above “head” height was another 10 points in RSSI. Like I said, very unscientific I know. :slight_smile:

I personally have trialed Yagi as well as an antenna “extension” to get up another 10’. Any additional cable and connector loss is made up for and then some by gains in height. I’d go with a 10’ extension on the Antenna cable if that would be feasible for your use case.

Yagi antenna also made a world of a difference, maybe 50% even 2X the range. It was about 0 F here and about 15 MPH wind when I went for a hike, I got too cold before I was able to hike far enough to be out of range. I made it to about 50% farther than where I did previously and had plenty of RSSI left. This was a high gain Yagi.

1 Like

Do you have any recommendations on best way to do this? I agree, I've been concerned in this being the reason for a node to be orphaned if it received bad data. It doesn't happen often and most of the time it recovers but might be good to do some validity check on it before responding to it. Any recommendation?

It is often debated. I have used CRC16 often used in data communication, and a measurement range check.

A bit of nerdy reading on the subject: https://www.lammertbies.nl/comm/info/crc-calculation

What code to trust with this, is your choice. There are some Arduino libraries. CRC16 must be in Particle OS code as well. The important thing is to use the exact same routine on both ends of the data transfer.

1 Like

Making no guarantees, this cyclic function avoids buffers and lookup tables. b is each data byte in the packet to be sent, and crcPrev is the result of the previous calculation starting with a zero. The last result is added as two bytes to the packet:

word crc16cyc(byte b, word crcPrev) {
    word crc16 = 0;

    crc16 = (b * 256) ^ crcPrev;
    for (int i = 0; i < 8; i++) {
        if (bitRead(crc16, 15) == 1) {
            crc16 = (crc16 << 1) ^ 0x1021;
        } else {
            crc16 = crc16 << 1;

    return crc16;
1 Like

@Rftop that was my experience today. I would add one more thing that is a big help - a lake.

I know some people enjoy swimming, fishing and boating - but what lakes are really good for is extending the range of LoRA radios.

First, I picked a spot for the gateway that would be near the lake's edge and where I could get some height - both for range and because this lake can flood up to 10 feet. I wanted to use this pole but there was an aggressive looking bird in its nest so I had to find a backup.

You can see the eagle in the background through the trees.

This spot had a great view across the lake toward the two park entrances I needed to cover:

Here is what the end result looked like:

The green marker is the gateway on that pole. The light blue pins were from the beach looking straight across the lake and the dark blue pins (both about 1.8 miles away) were where the counters needed to go.

The signal strength across the lake was fantastic with readings at the beaches at -94/10 and -114 /6 (RSSI / SNR) for the closer and farther beaches respectively. That little bit inland to the park gates is what really impacted the signals which dropped to -130/-6 and -132 / -8. It may be that, as the foliage fills in, I will need to elevate and improve the antennae to keep a reliable link. I could also experiment with some of the other radio settings discussed in the earlier post.

Both of these locations were practically unreachable with cellular so LoRA has opened up a bit set of new possibilities. Also, with the gateway in place, the park could put in more counters and other sensors (such as a flood sensor) easily and reliably.

I am going to let these three park installations run for a couple weeks before tackling a couple Western parks with mountainous terrain. I suspect I will struggle to get a connection over a fraction of the distances I was able to cover today.

@Rftop, given the connections I needed to make here, would a YAGI antenna work given it is directional?

Thanks, Chip


No Sir, that's about the worse scenario that you could ask a Yagi to do at the Gateway.
Yagi's could help at the Nodes though.

But for your Counters, you might not want to draw the extra attention with a 2' long yagi (I'm thinking about vandalism). And if it's at Ground/Head Level, you'd probably want to look into Product Certification w/ a particular Yagi. I realize that holding a cell phone to your head all day is more radiation than a person would get from walking by your Yagi, but "Lawyers".... ya know.

[Edit] Just Joking around about Lawyers...They gotta eat too :slight_smile: [/Edit]

Looks like you have great results already :grinning:


OK, so that was short lived.

The closer node is reporting but that farther one is not. When the spring comes and the foliage is in full bloom, the signal levels will drop even more so, as I see it, I have three options to get signal from my farther node back to the gateway. I would be interested in any advice you all have on which to pursue. I will put them in order as I see them based on my goal to develop a repeatable and approachable product - not something that will require expertise or labor hours to implement at scale.

  1. I could go back and try different LoRA Radio settings. Perhaps at this extreme range, I will see a difference in the modes that are supported by the Radio Head library.

  2. I could deploy a dedicated repeater node at the shoreline which could easily reach the gateway and would be close to the node.

  3. I could upgrade the gateway antenna with a more expensive and higher gain option such as this one from SeeeedStudio. This antenna has 8dBi gain and covers the current range.


  1. I could use a YAGI antenna at the node keeping @Rftop’s concern in mind and mounting it on the roof of the structure the node is currently on. This would require some skill / software functions to support the proper mounting and orientation of the antenna.

Ideally, I could develop this idea so a park ranger could deploy it. Ideas 1 & 2 support common hardware and do not require significant skill to install correctly.

What do you think?





Looking at RSSI and SNR values can be frustrating as the values seem to change on every connection. However, when you look over time, you can see a significant improvement.

In this example, the gateway had this stick antenna


but the node had a sticker antenna (a good one but …)


I made two changes:

  1. I changed the node antenna to the same stick antenna as the gateway
  2. I changed the center frequency as described above.

Take a look at the difference in RSSI and SNR - hard to see when you are in the moment but, over time…

As much as I don’t want to admit it, I am beginning to think that hardware makes the biggest difference here.


So, I’ll be the first to admit that I know very little when it comes to the details of RF transmission.
But your Node antenna supports a huge frequency range : 617MHz ~ 6GHz.

That’s not optimal for a 915 MHz (typ) Lora signal, as you discovered.

Now’s a good time to take SF12 for a spin. You have a great test case.

1 Like

What LoRa settings did you run with?

Devices closer to ground cut the link budget, If the last picture location was forced, double the distance to ground should be better.

I have seen signals travel over a hill bouncing off something unknown. You can loose that property with directional antennas, that are really powerful for more line of sight situations.

Cables can be lossy, so my first bet would be the same good stick antenna on both ends. Devices mounted 2+ meters off the ground. Then use the necessary Spreading Factor

That said, I have seen a video somewhere of a radio amateur, who had a long coax cable, stripped off the end and tied it to a small heavy thing, so that antenna end, could be thrown high up and land in the tree tops. Than worked really well long distance, but not sure that would be practical :grinning:

@Rftop ,

Agree that patch antenna was not optimized for LoRA but it was the best of the ones I tried. It seems that the stick antenna is the way to go.


I am currently using the default settings of

Bw125Cr45Sf128	Bw = 125 kHz, Cr = 4/5, Sf = 128chips/symbol, CRC on. Default medium range.

There are a couple of higher spreading factor options in the default library including this one which is (I believe SF12 - 4096chips/symbol. My longest message is only 29 bytes so I should be able to make this work.

One other (crazy?) idea I may try. As these locations had poor cellular service, I had installed this high gain antenna at each location. These are mounted about 8’ up in the air and are sitting on a 12" square ground plane (you can see it above the eaves on the left in my last picture). They are not LoRA antennae per se but they do cover the ISM band. I may simply try using them as I no longer need to make a cellular connection. Worst case, I could get a proper LoRA antenna and mount it on the existing ground plane.


I knew this install would be at the edge of what was possible and I picked a park that is about 20 minutes from home. So, I am going to chalk all this up to learning. I also greatly appreciate the advice and support of this group.

Thanks, Chip

1 Like

You might think this is a crazy idea but, you could DIY a hinged/swinging antenna mast and have that design nailed down for any challenging location (gateway and node).

Best case scenario is to also mount your device on that antenna to minimize the antenna cable and connectors.

Keep plenty of overlap in your hinged section (several feet). You’re only really asking a Park Official to drive a tall “Fence Post” in addition to a typical install. Then Mount the device to the top and swing it up into position.

1 Like

It is great to see a real world test setup.

In that case, I would stay with 125kHz for high sensitivity and increase from SF7 to about SF11 (2048 chips) to better match the low signal strength.


I worked with an amateur radio operator (HAM) once who told me his best field antenna was a spool of 30ga wire-wrap wire and a slingshot! His advice was to get green insulated wire since it blended in better. :grinning:


@jgskarda, is this handled automagically by the RH driver or do you need to do something to make the retransmit determination and put the device into transmit mode by using a command like manager.sendtoWait();?




So, I tried to salvage the operation at Jordan lake today.

  1. First, I changed the radio settings as @thrmttnw had suggested on the Gateway and told it to stay on-line so I could do all my work from the near side of the lake.
	driver.setFrequency(RF95_FREQ);					// Frequency is typically 868.0 or 915.0 in the Americas, or 433.0 in the EU - Are there more settings possible here?
	driver.setTxPower(23, false);                   // If you are using RFM95/96/97/98 modules which uses the PA_BOOST transmitter pin, then you can set transmitter powers from 5 to 23 dBm (13dBm default).  PA_BOOST?
	driver.setModemConfig(RH_RF95::Bw125Cr48Sf4096);	// This optimized the radio for long range - https://www.airspayce.com/mikem/arduino/RadioHead/classRH__RF95.html
	manager.setTimeout(2000);						// 200mSec is the default - may need to extend once we play with other settings on the modem - https://www.airspayce.com/mikem/arduino/RadioHead/classRHReliableDatagram.html

  1. Then I updated the radio settings on the nodes and was able to get them to connect. The signal levels were lousy but I sent packet after packet without issues.
  2. I tried the Taoglas external antenna - it was worse than the LoRA stick antenna
  3. I moved each of the nodes up as high as I could get them (from 3’ to 6’) not much but…

For the moment, they are both connecting but with RSSIs in the -130s and SNR values of -10. So, I think I will next try putting a repeater at the beach and do some homework on buying / building better antennae.

Thank you all again for your help and advice.


Maybe a $30 12V Solar Panel on the beach repeater could be an easy solution for a 24/7 operation?

@Rftop ,

Putting a big solar panel and a big battery and running the gateway all the time? Too easy!

Actually, I do appreciate that having the gateway sleep adds complexity. I may end up doing something like that but, I have not yet come to the conclusion that my issue is timing.

I don’t want to jinx it but, despite obscenely negative RSSI and SNR numbers, both nodes are connecting every hour. I understand that these will be problem children unless I can get the signal numbers up.

Wondering. If I was to invest in a better antenna and/ or higher placement - gateway or nodes?


I was talking about the beach repeater just being an always on LoRa node for backhaul to the Gateway.
Your actual Counter Node and Gateway would stay on their existing sleep schedule.

Maybe $50 + the LoRa

@Rftop ,

I see, that is a very good idea. Plenty of sun on the beach too.

I need to learn how to implement a repeater using the RadioHead Library. I could imagine this being a simple and task optimized device.

Thanks, Chip