Long Range IoT Network

Ok I do not go over 1mb very often.

Hi @lsfarm,

I remember reading a topic about Lora from @RWB and it is here:

Perhaps is of use to you.
Best,
Gustavo.

1 Like

I’m pretty sure @rickkas7 has the RFM95 radio library avaliable now for the Gen3 devices on the Web IDE Library.

If you get the antennas for the RFM95 radios up above single story roof heights the range can go up to many miles. Using directional antennas will help greatly also.

I Played with Digimesh also but it has a much higher learning curve to get up and running.

1 Like

He was nice enough to provide a great tutorial as well:

I personally followed this exact tutorial and sample project. Even started with the exact same hardware. I currently have this library working reliably on a Boron talking to remote (non-particle hardware) LoRa nodes. I've gone as long as 2.1 miles but this was with the Boron + LoRa radio sitting on top of a Silo ~60' in the air. I am pretty sure I would of gone farther but it's pretty flat land where I'm at and the Boron+Lora was in a small valley so couldn't maintain line of site beyond that.

The only thing I couldn't get functional was the different modem settings:

  Bw125Cr45Sf128 	Bw = 125 kHz, Cr = 4/5, Sf = 128chips/symbol, CRC on. Default medium range.
  Bw500Cr45Sf128 	Bw = 500 kHz, Cr = 4/5, Sf = 128chips/symbol, CRC on. Fast+short range.
  Bw31_25Cr48Sf512 Bw = 31.25 kHz, Cr = 4/8, Sf = 512chips/symbol, CRC on. Slow+long range. 
  Bw125Cr48Sf4096 Bw = 125 kHz, Cr = 4/8, Sf = 4096chips/symbol, low data rate, CRC on. Slow+long range.
  Bw125Cr45Sf2048 Bw = 125 kHz, Cr = 4/5, Sf = 2048chips/symbol, CRC on. Slow+long range. 

I should of taken better notes, the default works fine and what I us today, I didn't test the fast + short range, only 1 of the slow + long range versions worked but had no noticeable improvement in range but took 2-3X longer to send. The other one would compile fine but would never send/receive a message and the final one wouldn't compile and through some error. It's been a few months though since I last tested. I believe SF has a big impact on range so would be nice to be able to configure for the 4096 chips/symbol but I didn't have enough time/patience to dig into it at that time. I suspect I wasn't given it enough time for the message to send it before giving up. A few weeks ago after I was testing this I noticed I had myDriver.waitPacketSent(500) I'm thinking I need to run the tests test again with that set to a few seconds OR just commented out. :slight_smile:

I believe it's also discussed more here: How to make LoRa RF95 work on XENON

So far I'm very happy with LoRa + Boron but I am just torn between trying to develop some sort of Mesh network, vs Lora, vs standalone Boron's. I need to do some more playing and learning first.
Per the earlier comments in this post, I am now tempted to swap my non-Particle LoRa nodes, to actually be Boron + Lora but for the most part keep the SIM disabled. Then if/when I need I can do OTA to the remote LoRa nodes.

Yea the Boron + LoRa combo is a pretty sweet combo.

I tried a few of the different modem settings but the default seemed to work good.

Just need to get the antennas up as high as possible or use directional for best results if your needing long range.

I found this info about different modem settings in the RH_RF95.h file

 /// Choices for setModemConfig() for a selected subset of common
    /// data rates. If you need another configuration,
    /// determine the necessary settings and call setModemRegisters() with your
    /// desired settings. It might be helpful to use the LoRa calculator mentioned in
    /// http://www.semtech.com/images/datasheet/LoraDesignGuide_STD.pdf
    /// These are indexes into MODEM_CONFIG_TABLE. We strongly recommend you use these symbolic
    /// definitions and not their integer equivalents: its possible that new values will be
    /// introduced in later versions (though we will try to avoid it).
    /// Caution: if you are using slow packet rates and long packets with RHReliableDatagram or subclasses
    /// you may need to change the RHReliableDatagram timeout for reliable operations.
    /// Caution: for some slow rates nad with ReliableDatagrams youi may need to increase the reply timeout
    /// with manager.setTimeout() to
    /// deal with the long transmission times.
    typedef enum
    {
	 Bw125Cr45Sf128 = 0,	   ///1: Bw = 125 kHz,   Cr = 4/5, Sf  = 128chips/symbol, CRC on. Default medium range
	 Bw500Cr45Sf128,	       ///2: Bw = 500 kHz,   Cr = 4/5, Sf  = 128chips/symbol, CRC on. Fast+short range
	 Bw31_25Cr48Sf512,	       ///3: Bw = 31.25 kHz, Cr = 4/8, Sf  = 512chips/symbol, CRC on. Slow+long range
	 Bw125Cr48Sf4096,          ///4: Bw = 125 kHz,   Cr = 4/8, Sf  = 4096chips/symbol, CRC on. Slow+long range
	 BW41_7Cr45Sf512,          ///5: Bw = 41.7 kHz,  Cr = 4/5, Sf  = 512chips/symbol, CRC on
	 BW62_5Cr45Sf1024,         ///6: Bw = 62.5 kHz,  Cr = 4/5, Sf  = 1024 chips/symbol, CRC on
	 BW62_5Cr45Sf512,          ///7: Bw = 62.5 kHz,  Cr = 4/5, Sf  = 512 chips/symbol, CRC on
	 BW256_7Cr45sf128,         ///8: Bw = 256 kHz,   Cr = 4/5, Sf7 = 128chips/symbol, CRC on
	 BW125_7Cr45sf128,         ///9: Bw = 125 kHz,   Cr = 4/5, Sf7 = chips/symbol, CRC on
	 BW62_57Cr45sf128,         ///10: Bw = 62.5 kHz, Cr = 4/5, Sf7 = chips/symbol, CRC on
	 BW125CR46SF9,             ///11: Bw = 125 kHz,  Cr = 4/6, Sf9 = chips/symbol, CRC on
	 BW62_5CR45SF9,            ///12: Bw = 62.5 khz, Cr = 4/5, Sf8 = 256   chips/symbol, CRC on.
	 BW62_5CR46SF10,           ///13: Bw = 62.5 khz, Cr = 4/6, Sf10 = 1024 chips/symbol, CRC on.
	 BW62_5CR45SF11,           ///14: Bw = 62.5 khz, Cr = 4/5, Sf11 = 2048 chips/symbol, CRC on.
	 BW125CR45SF11,            ///15: Bw = 125 khz,  Cr = 4/5, Sf11 = 2048 chips/symbol, CRC on.
	 BW125CR45SF10,            ///16: Bw = 125 khz,  Cr = 4/5, Sf10 = 1024 chips/symbol, CRC on.
	 BW31_25CR45SF9,           ///17: Bw = 31.25khz, Cr = 4/5, Sf8  = 256  chips/symbol, CRC on.
	 BW41_7CR45SF9,            ///18: Bw = 41.7khz,  Cr = 4/5, Sf8  = 256  chips/symbol, CRC on
    } ModemConfigChoice;

 
1 Like

Here is a interesting setup board that I found a bit ago if you are exploring LoRa.

Thanks for all the great info!! Still working on reading through it all and following the links.

@RWB what LoRa radio have you found that works the best with particle devices? Or maybe you’ve just got 1 that works good. Either way I’d appreciate a link to it. There’s so much stuff out there its hard to sort through it.

Back in my arduino days I had this shield, and was using this as my main antenna and this as my receiver. I was able to send messages 4.5 miles. At 4.5 I disappeared over a hill, so I might have been able to go farther

I just used these: Adafruit RFM69HCW Transceiver Radio Breakout - 868 or 915 MHz [RadioFruit] : ID 3070 : $9.95 : Adafruit Industries, Unique & fun DIY electronics and kits

Nice expensive antenna! I got 1 mile with a simple piece of 16 Awg wire cut to the right legnth about 7 feet off the ground in a housing development.

Your 4.5 mile range is impressive!

Thanks @RWB now to figure out whether RFM95 or RFM69 fits the bill for my project here. Anyone tested out the differences?
I see the library that will work for the RFM95 and your link @RWB takes me to the 69, so I make a guess there’s a library for it as well.

For those interested in my project here. I think I’m going to take the test em all and see what holds up the best out in the real world approach. I plan to install the following and put them all through the paces over this next summers crop. (April-October)
Sim Only System. Thanks for the hologram suggestion @Backpacker87
WiFi System with Ubiquitis antennas
LoRa System running on Boron boards for occasional OTA thro cell. Hopefully we can get some basic mesh

Sim System deployed last week. So simple… if only data charges wouldn’t eat our lunch. Guess we’ll see! Hope to get the WiFi one going this week. Need to do more research on LoRa

It will be interesting to see how your digimesh network comes together @Backpacker87

I meant to link you to the RFM59 not the 69. Sorry😀

I spent alot of time messing with Digimesh. Much higher learning curve.

Stick with Boron + Lora and skip trying the Mesh options unless you like torturing yourself :grinning:

Hi, since you mention $$$ in damages if the system won't behave properly, think about making it more reliable with an external watchdog, so if anything goes wrong, you still have something that pulls the plug and restarts the system.

@lsfarm

3 Likes

If you’re reducing the data length, just send the values as a set of bytes. You know from their position what they represent, e.g. third and fourth bytes are Temperature in degrees and tenths of a degree. Also don’t sent timestamps (the receiver can deduce that) and keep your node Identification as just a byte (unless you will have more that 256 of them).
You can actually pack the data into less bytes if you look at the actual range you expect. e.g. temperature that will only be between 20.0 and 50.0 deg C is only 300 possible values which can be encoded in 9 bits (512 values). Have a look at TTN for “encoding and decoding payloads” .

Dave

1 Like

All great points Dave. Thanks! I fully agree with your comments especially if you are passing data via LoRa. I think I used TTN tutorial to learn some of this. I use most of this strategy with my LoRa to Lora communication packets, I leverage most of what you touched on and most of my LoRa packets are 8-20 bytes in length.

In my opinion this is a less of a need for Particle Boron --> Cloud or Cloud --> Particle. Some rationale for my particular use case in why I did what I did:

  1. I include a date/time as currently the device sleeps, takes readings, falls back asleep, repeats this throughout the day and then at some point wakes up and publishes all the data to the cloud. In this case the "Published at" is not equate to the time the readings were taken. I'm sure there are ways around this but the simple solution is to include the current time the readings were taken.
  2. I have devices that take different readings from different types of sensors. Each device can be a little different but I'd like the same backed to process all events from all devices. The simple way to handle this was to package the data in 3 bytes. Byte 1Byte2Byte3. In this case, Byte 1 is 0-255 representing the type of reading. I.e. value of 1 is temperature, 2 = humidity, 3, something else, etc. So the syntax I use is Byte 1 (What is the data type), Byte2 and Byte3 is the 16 bit value of the measurement. This way the backend can easily process data from any device or sensor type without having to use different decoder rings.
1 Like

Wow that’s so cool. Can your phone still send text messages if the cell network goes down :stuck_out_tongue_winking_eye:
That’s also an interesting way to power the device. Yes, I’ve seen the post for solar stuff here, but just haven’t had the time to dig through them
This piece here is also interesting: “ The last step can be done at any time, remotely, which is essential if, like me, it is mounted a long way away or high up a pole where it’s difficult to access physically.” going to have to study through his code and see what all he’s doing here

Well there goes my weekend. :slight_smile: It’s been on the todo list to investigate LoRa repeaters or implementations of LoRa mesh (if that’s even possible). This seems like a great starting point. @RWB have you implemented a LoRa repeater before? If this tutorial is doing it on a Adafruit RFM95 feather M0, certainly a Particle Boron can. If not this weekend, this certainly is on my list if/when I do have more time to play.

1 Like

Yes!!! For sure. great info @dave.w

I was wondering how I was going to keep time on the boron’s if I disabled the sim for month’s on end while trying to cut out as much extra hardware as necessary. The feather wing layout is great, but when you come from using arduino megas!... Need all the pins I can get for other sensors and outputs.
This will be perfect for my application. I’ll just let the main node be the “boss” and whenever boss needs info from his 6-8 slaves, he’ll just ask for it over LoRa.

Hope this is allowed:

Otherwise, I wonder if others have a similar need and going down this road of Boron + LoRa and if so, has anyone taken this or anything like this as far as FCC listed product?>

This is from @jgskarda thread. Let me know if you come up with anything on this.

Yep! Might be a weekend for you, it’ll be a week for me. I’m no whiz bang programmer, but I got some friends that are :wink:, and we built out a setup on arduinos using those dragino shields I linked earlier. We was working out some meshing around when we quit, not sure if that would’ve worked or not, but we was certainly getting messages to go through from gateway to node. The problem we soon come up on was how to update firmware on those remote node. So the project kinda fell through at that point. Been playing around with particle here now for a good year, and haven’t looked back. For me, being able to just whip out iPad and fix a few last minute code problems out in the field has made a huge difference.

1 Like

A bit unrelated but you might want to checkout this application note regarding ab1805. It provides external hardware watchdog (sounds like you might want that), deep power down reset (power off for 30 seconds if unable to connect to the cloud after 11 minutes of trying, as well as an external RTC. This might kill a few birds with one stone. I've had my new PCB with it for a month or two now and still have a bit to learn/implement but so far I'm very happy that I went to it. https://github.com/particle-iot/app-notes/tree/master/AN023-Watchdog-Timers

This is from @jgskarda thread. Let me know if you come up with anything on this.

  • Glad you found that thread to.LoRa + Boron or B-Series. Is anyone else testing/developing? What's on the particle RoadMap? This might be my barrier or atleast a big hurdle for me to ever selling a product of LoRa + Boron. That said, you are still free to play for personal use with LoRa and Boron +Lora. I've also been told that as long as you don't operate both Radios at the same time then you don't necessarily invalidate the FCC of either the Boron OR the FCC on the LoRa Radio (assuming you are using one with an existing FCC listing). So in a use case where the boron connects once a month for OTA, I would think you can just turn off LoRa radio, Turn on the Cellular and then once done turn the LoRa back on. Although that feels pretty dicey and I'm sure a big gray area though and who's to know if the device ever operates with both radios active if only managed through firmware.
1 Like

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.


Part 2 of this discussion can be found here: