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

[jgskarda]

This is intended to be a continuation of an existing closed topic: Long Range IoT Network Since, it’s closed, I thought I’d start another topic to continue the collaboration here.

The intent of this thread:
In the last 2-3 years, I’ve been continuing to explore the LoRa space in order to overcome several challenges in developing a Particle Powered product for a specific use case. I’ll share more details of that product/use case in another thread in the coming days/weeks to supplement this one. It’s a pretty “Sweet” Project. Overall, I’m excited with what is possible by pairing a Particle Boron with LoRa. I wanted to start this thread by sharing a few of my high level thoughts, observations, opportunities as it pertains to Lora and how Particle + LoRa helps solve several challenges.

@chipmc and I have similar needs given our use cases being rural IoT. We’ve had some great collaboration already that lead to some nice improvements in the approach. The intent of starting this thread is to help others with similar challenges applying Particle + Lora and to spark additional collaboration from the broader community.

1: Request to accept open pull request on RF9X-RK library
First, I wanted to say a big Thank You to @rickkas7 for his initial migration of the RadioHead library to the Particle Platform and including a tutorial How to make LoRa RF95 work on XENON - #5 by rickkas7. It’s been my initial building block thus far. As I continue working with LoRa, I recently forked your RF9X-RK repo on Github and made some updates to it. I then made a Pull request back to your repo. Was hoping you could accept/approve my pull request in order to merge the changes into the master branch and then update the public Particle RF9X-RK library. This way others can easily use the updated library. The main changes made on the pull request include:

• Added RHRouter and RHMesh classes - Required for a Particle Device to participate in a LoRa Mesh network.
• Updated the library in order to sync up with the master branch of the original RadioHead library V1.121. (I.e. migrate from RadioHead V1.89 → V1.121) RadioHead: RadioHead Packet Radio library for embedded microprocessors

2: So Why Particle + LoRa?
There are many challenges with developing an IoT product/device. Particle.IO is fantastic at addressing so many of those challenges. A growing segment of IoT is in rural/remote areas especially in agriculture and similar rural/remote/spread out industries. Challenges/needs of these industries make Particle + LoRa an interesting combination. Two challenges that Particle + LoRa help address are:

1: Overcome the lack of reliable cellular connectivity:

• In general, rural areas encounter more challenges with cellular connectivity. Given that IoT devices will always sense or actuate a physical thing, the IoT device is generally attached/apart of that thing. Therefore depending on the specific location of that thing within the property, if that exact location doesn’t have reliable cellular service, then typically Particle can’t be used for that application. In this scenario, the only real course of action is to try and identify some high gain antenna and cross your fingers it improves or simply turn down that customer.
• In this scenario, a Particle + LoRa device can be located at an optimal location on the property with acceptable cellular connectivity. This is likely at a higher elevation or maybe avoid some obstruction/terrain between it and the closest cellular tower. Then a LoRa Node can be located at the specific location the sensing/actuator is required where cellular service didn’t exist. The LoRa node communicates to the Particle + LoRa device over LoRa and then the Particle + LoRa device interfaces with the Particle Cloud. This allows IoT devices to be located in areas with limited/poor cellular connectivity while still leveraging the benefits of Particle.

2: Multiple IoT devices in relative proximity (100s to 1000s of feet apart over acres of land):

• Many applications require many sensors spread out over many acres. Many of these use cases are too far for Bluetooth or WiFi. Being distributed, typically, these applications do not have mains power at every sensing location. If there is only 1 sensor, the obvious choice is a Particle cellular device, grab a battery, grab a solar panel and you begin sensing. However, what if you have 5, 10, even say 40 over many acres (a typical smart agriculture/rural IoT use case). As the density of sensors increase over the acreage, the practicality of each one being cellular connected stand alone decreases due to hardware costs, operational costs and power requirements of a cellular device.
• A Particle + Lora approach can be used to provide a single Particle cellular connected device on the property. This can be located in an optimal area that has power or has the optimal cellular reception. All other LoRa nodes can be low power, lower hardware cost, with minimal ongoing operational costs in comparison.

What does this look like:
In this example, we need sensors at the end of every line shown below. This allows users to quickly pinpoint leaks and problem areas in the system without aimlessly walking around the entire property. The number of sensors needed over a a 40 acre or so distributed area like this makes it not practical to have the end of every line be a Particle device. By combining Particle + LoRa we can strategically locate a single Particle Device somewhere within the property (best signal strength, power source, etc.) and use LoRa to talk to all others while leveraging Particle as a backhaul for LoRa devices to the cloud.

Initial Observations/Learnings:

• Point to Point Range: LoRa point to point can reach anywhere from 1,000 ft to well over 1 mile with default radio settings in “practical/real world applications” all depending on terrain. In most wooded scenarios, I’m at 1200’ - 2400’ between nodes. Line of sight near ground level has been about 3/4 - 1 mile. Line of sight at high elevation I’ve tested ~3 miles. This is all with the default radio settings.
• LoRa Mesh: As you’d expect, can vastly extend the range. This is great for going up/around obstructions that would generally impede the RF with point to point. For example… this is about 3 miles end to end. Upper right blue dot is a Particle + LoRa and each Red dot is a LoRa Node.
  
  
• Low Power: LoRa node can be very low power, a LoRa device can wake up, take readings, send its data to the Particle + Lora device, receive a response and fall back asleep in 1-2 seconds. I’m not a low power design PCB expert, but I’d estimate about 10-14 months on a single 18650 battery publishing data every 5 minutes with the current design. With less frequent publishes and/or better power management PCB design I’m sure this could easily be years.
• LoRaWAN vs LoRa - To be clear this is LoRa point to point and not LoRaWAN. From my perspective, LoRaWAN in rural settings just isn’t widely adopted yet especially here in the US. In this scenario, I’d have to spin up a dedicated LoRaWAN gateway at every site. I haven’t done extensive research on this option but on the surface, it seems would require higher hardware cost for the gateway, much higher operational costs for the cellular connectivity of a LoRaWAN gateway and higher power requirements of a LoRaWAN gateway (most require mains power, yes could do solar but requires much larger battery and solar panel compared to power requirements of a Particle device). A LoRaWAN gateway is also a dedicated purpose. Whereas a Particle + LoRa device can be multi-purpose and both service the LoRa traffic while also being a sensor itself reducing hardware costs. Finally… since LoRaWAN does not support Mesh, it limits the possible range and won’t always reach up/over obstructions/terrain common in rural areas.

Challenges/Tradeoffs:

• OTA is not available with Point to Point Lora devices or if it is… I’m certainly not smart enough to figure that one out.
• Developing robust firmware for the Nodes and Particle that handles LoRa Mesh, join requests, sleeping/waking while keeping devices in sync, packaging data from many sensors in a single Particle.Publsih() to reduce data operations. There are some but at times limited examples/libraries compared to the great Particle Ecosystem. It’s been fun to figure it out but time consuming.

Well that’s probably good enough for the first post… as I said earlier. I’d encourage anyone to ask questions, provide feedback, ideas, guidance, alternatives, etc.

[Rftop]

Great job Jeff, Thanks for sharing such a detailed overview.
I look forward to reading the discussions that will surely follow.

[peekay123]

@jgskarda this is a great post! Discussing your actual experience adds so much value. I have a few questions that you will likely address in future posts but inquiring minds…

• Which LoRa board or MCU/RF95 combo nodes did you use?
• Which frequency radios did you use? I am assuming 915Mhz for North America.
• You mention Line of Sight near ground level and at high elevation. Can you be more specific on height from the ground and what you mean by “high elevation”?
• Which antenna did you use at your nodes and at the Boron?
• What is the expected temperature range where the Boron and nodes operate?
• And finally, how much data is each node capturing/sending to the Boron?

[chipmc]

@jgskarda ,

First, I want to say what a pleasure it has been working with you on this project. You have done an amazing job adding mesh capabilities to the Particle library (second your request for a “pull” on your branch) and doing the hard work to get practical real world experience. I have benefitted from all you have done and, I hope, so will the rest of the Particle community.

I want to explain why I think that Particle is a great platform for LoRA development. I believe this could be a big benefit to the platform - even as public LoRAWAN solutions are gaining tracking. By building a gateway based on a Boron with LoRA capabilities, you have some significant advantages over LoRAWAN solutions like Helium and The Things networks for these rural implementations. @jgskarda mentioned some above but I want to repeat them and add a couple to his list:

• The gateway can also be a sensor node - this saves money and helps build a “mesh” for more distant nodes.
• This solution is available where there is no public LoRAWAN service is available.
• Private LoRAWAN implementations require gateways are not optimized for the low power use case - they cannot be programmed to “sleep” and generally have power budgets that would make solar implementations larger / more expensive than what you have have with Particle. See link below for an inexpensive LoRAWAN outdoor gateway - they can be much more expensive than this:

102991155 Seeed Technology Co., Ltd | Networking Solutions | DigiKey

• A Particle gateway can take advantage of the amazing Particle API and Libraries to support connectivity, scheduling and publish to queue to name just a few.
• This solution takes a standards-based approach to LoRA so there are many options for pre-made sensors and adding LoRA modules to existing Particle projects is straight forward.

I will share more of my experiences in the coming weeks and I hope others in the community will take advantage of the great work that @jgskarda has done here.

Chip

[jgskarda]

@peekay123 - All great questions... asking questions like this is what fosters the valuable dialog vs me just pontificating.

@peekay123

Which LoRa board or MCU/RF95 combo nodes did you use?

• When prototyping... for the nodes, I started with: Adafruit Feather M0 with RFM95 LoRa Radio - 900MHz [RadioFruit] : ID 3178 : $34.95 : Adafruit Industries, Unique & fun DIY electronics and kits. For the initial Particle + LoRa device prototype, I used the bare Adafruit LoRa Radio FeatherWing - RFM95W 900 MHz [RadioFruit] : ID 3231 : $19.95 : Adafruit Industries, Unique & fun DIY electronics and kits and a double feather wing identical to the tutorial from Rick.
• For the node, this was an easy/natural place to start especially being the feather form factor. I started with the LoRa tutorial on Adafruit and kept growing the understanding from there.
• For the LoRa node, I now use a fully custom PCB that integrates an ARM Cortex M0+, a RFM95 LoRa Radio. The Adafruit Feather M0 LoRa module was the basis of design for the custom PCB. A few key changes I wanted that drove me to my own PCB include: 1) EEPROM to assign a unique Device_ID and other identifier information on each device, 2) Solar charging capable PMIC, 3) External RTC/Watchdog, currently using the AB1805. 4) Integrating an SMA connector to use an external antenna for the LoRa radio instead of needing to solder on a uFL connector or use a lower performance wire/spring antenna. 5) 18650 Battery holder integrated within the PCB. This keeps the enclosure small and the PCB can be secured right to standard "mounting bosses" in the enclosure - Polycase.
• I choose the RFM95 instead of the RFM69 as well as the M0+ MCU over the 32u4 as "theoretically" if a node wanted to be a LoRaWAN node it could be via firmware updates. For now, I'm looking at Rural applications... if that ever changes and/or if LoRaWAN becomes widely available it leaves that door open. For now... I still love the Particle + LoRa approach. Also, some comments in reading about LoRa Mesh is that it requires a bit more memory and so thought the M0+ was a safer bet.
• For the Particle + Lora... I ended up integrating the LoRa Radio right within my application specific carrier board. A Particle Boron plugs into the Carrier board and interfaces with the LoRa radio that way. The rest of the board is the sensors, connectors, RTC, like most carrier boards. I'll try and post some pictures with the "application specific" thread I'll start in another few days/weeks.

@peekay123

Which frequency radios did you use? I am assuming 915Mhz for North America.

Yes, I am also in North America so using 915Mhz

@peekay123

You mention Line of Sight near ground level and at high elevation. Can you be more specific on height from the ground and what you mean by “high elevation”?

Yeah... this is always a dynamic question. In summary, in rural areas, the largest contributor to range is "terrain/dirt/earth". I found trees do affect range but not as much as you'd expect. I assume it'd be similar results in a residential area and even less in a commercial/industrial area with concrete walls. I've tried to study the Fresnel Zone in more detail but for me real world testing brought it to life. Here are 4 examples to help explain my experience to date. Of special note... this is with default LoRa radio settings. I've read about changing SF and other settings to greatly increase range but for now I just use the defaults for simplicity as well as "reduced time on air/better battery life". This is especially true with mesh capability to 2X, 3X, 4X range. This seems like the better "knob" in my use case to extend the range rather than increasing SF, increasing time on air, and reducing battery life.

1. Real world through a medium density woods with each about 6-7' off the ground through trees/brush. ~1400'.
   

   

2. Real world scenario near line of sight/no major obstructions: 1.3 miles
   

   

3. Testing scenario: Flat mostly wooded area, both 6-7' off the ground: 2500'
   

   

4. Optimal/testing scenario: Particle + Boron on top of a 65' silo, node as far away as possible while maintaining line of sight. WI is mostly flat land so hard to do an adequate test: ~2.0 miles with SNR and RSSI indicating more range is possible but I couldn't go farther while maintaining "line of sight" to really test max line of sight range.
   

   

That little spec in the picture is the silo:

This is the view from the silo:

@peekay123

Which antenna did you use at your nodes and at the Boron?

Antenna has been a tricky one... I will say... RF is a bit of "black magic" to me yet. I did some rudimentary tests... Once I found one that worked, I just stuck with it. As for antenna… I currently use this:

ANT-916-CW-HW Linx Technologies Inc. | RF/IF and RFID | DigiKey

I did some quick and dirty tests of 0.8 miles apart, flat land, near line of sight comparing 4 antenna approaches. I too was debating internal vs external. My main consideration was to maximize range with a robust design so I went external antenna.

Although the one highlighted in green did in fact perform better, it had an “elbow” which made mounting the SMA connector in the enclosure clunky/difficult vs direct SMA on the PCB and also the elbow was not very robust. So instead I choose the fixed version with similar RSSI and SNR. I'm sure there is some more work that could be done here but it was "good enough" for me. There is some consideration to remove cost and go back to an internal wire antenna or even PCB antenna but just don't have time/knowledge to investigate that.

@peekay123

What is the expected temperature range where the Boron and nodes operate?

Good question... for the application at hand, when the devices are being used it's typically outside air temperature maybe 20 F --> 70 F. Obviously, there are also cold/hot spells in there too. I'm more sensitive/concerned in cold weather operation over being too hot. The main concern is maintaining a battery that can withstand a long duration of time in cold weather before it's warm enough out to charge. Another benefit of LoRa was battery life can easily last the entire duration as long as it starts the service period fully charged.

@peekay123

And finally, how much data is each node capturing/sending to the Boron?

I should of listed this in the challenges/tradeoffs section... with LoRa we are talking in units of Bytes of data. I try to be conscious as possible to this by only sending the necessary data each transmission and format that data packet in a way to minimize bytes. I currently send about 10-20 bytes of data from each node every 5 minutes to the Particle + LoRa device. This includes things like: a node address/unique identifier, 2-3 sensor readings (temperature and like), battery voltage, RSSI of the last message received, a config index number and a one up message counter to track dropped/missed messages. The message sent back to the node to acknowledge it, is smaller and includes mostly config data when needed as well as time of day in order to "synchronize" it's clock and to tell it when it
needs to send data again. This time synrconization allows the Particle + Boron device to also fall asleep in sync with the LoRa nodes so even it can operate on battery power for many weeks or indefinitely with a small solar panel. This isn't possible with a LoRaWAN gateway.

[jgskarda]

Great points @chipmc - There seems to be many advantages over LoRaWAN and yeah I really believe Particle + LoRa = Better together!

In addition to the hardware costs of a LoRaWAN 4G LTE gateway, I’m guessing the ongoing operational costs are in the neighborhood of MiFi Hotspot of the $20-$50/month. Even if WiFi was available, that adds an entire level of complexity that most customers don’t want to deal with setting up. One of the reasons Particle cellular devices are so nice is the end user experience is just bring it to the field, turn it on and it just connects. This preserves that simplicity factor for the end user.

[gusgonnet]

@jgskarda

It’s a pretty “Sweet” Project.

NOBODY can say no to such a project!
Way to go to post about it.

@Colleen do you think you can try your Discourse super powers to leave a link to this topic on the old topic? I believe around this area you can see a button that can edit info in it:

Thanks

[jgskarda]

@Colleen - did you do something on your end already, or does this show up automagically since I linked to the original one in my first post? Just curious if Discourse handles this already:

This certainly helps… what would be even better if Discourse had a “Continue discussion in a new topic” button which automatically linked to the original… but from my perspective as long as it inserts this in the original thread, I think that’ll work.

[wineisgud4u]

I agree with @chipmc and @jgskarda !!!
Particle + LoRa is a great solution to the high cost / maintenance / complexity of LoRaWAN, especially for Agricultural implementations.
There are many reasons for this - most have already been touched on by Chip and Jeff.
An often overlooked issue in my use case that results in about 1/2 of my field maintenance visits is the solar panel. My clients routinely damage them during normal farming operations. It drives me crazy!
Consequently my new designs are 100% battery powered using off-the-shelf alkaline batteries. This way, my growers can address a power problem to save me a field visit!
A Particle + LoRa base station could be located outside the farming zone and battery powered nodes inside the farming zones.
I would love to see more work here and I appreciate Jeff and Chip’s transparency / willingness to share.
I know nothing about coding, but I’m ok with hardware. So the more code / library work developed and shared, the more likely I can implement a solution like this!

[Colleen]

I did not update it! I will look into a “continue discussion” button.

Great post, Jeff! Love the level of detail you’ve provided!

[Rftop]

I want to mention a few things I learned from my experience, concerning Line-Of-Sight in Sub-GHz which surprised me (mine was also 915 MHz).

My first large scale IoT was for an Industrial Facility with a main Metal building approximately 1 mile long, ceilings range from 40’-60’ in most areas.

This facility is filled with Concrete, huge steel structures, and an unbelievable amount of RF background “noise”.

My initial design (on paper) called for 12 base/receivers to collect and aggregate all sensor data and forward to a Particle Electron (this was years before Boron’s existed).

I installed the first receiver and performed a quick walk around to get an idea on real world coverage.
Turns out only a few were required to provide coverage for 95% of the building, not the 12 that I had expected.
The only explanation was that the 915 MHz bounced around all throughout the building. Line of Sight played no part as a requirement in this setting.

Later on I performed a trial with a few solar powered rooftop receivers.
They provided outstanding coverage, even through the insulated metal deck roof.
I never could get comfortable with a battery chemistry for the Rooftop temps though.

This was the long way of saying… nothing can replace real world testing.
I quickly learned that my expectations (based on reading and learning as much as I could about RF) were meaningless. Sub-GHz wants to sneak through wherever it can. Very similar to Cell Phones and the building penetration we see from large distances away, except we are talking about sending Bytes… not voice.

My experience in Rural Settings was this…don’t setup a project in the Fall/Winter. The “green-up” during the Spring can make you look silly when all the sudden your link dies due to canopy.

None of this is new information to most of you guys and gals… but it might help someone that’s getting started in auxiliary comms for Particle backhaul.

Jeff, thanks again for sharing !
Ryan

[jgskarda]

@Rftop - Thanks for sharing your observations as well. I've been tempted to do a site survey in a large manufacturing facility I work at. This would be just for pure curiosity in understanding range like your saying in the concrete, steal, RF noise environment. I wasn't sure how to best explain what I was up to to when others would ask as I wander aimlessly around a manufacturing facility so I never did. Very interesting hearing your observations I'm sure my wife wonders how she is so "lucky" to ended up with me as I carry a LoRa radio with us on our walk around the block or in the local park!

@Rftop

The only explanation was that the 915 MHz bounced around all throughout the building. Line of Sight played no part as a requirement in this setting.

That's interesting and overall encouraging to hear. Always nice to have better than expected coverage than the other way around... When researching the topic, I thought this tool was interesting. MachineQ - Coverage Tools You'll have to click on "Outdoor tool" to get more meaning out of it I think. As you said... Nothing can replace real world testing though!

@Rftop

My experience in Rural Settings was this…don’t setup a project in the Fall/Winter. The “green-up” during the Spring can make you look silly when all the sudden your link dies due to canopy.

That's a very good reminder! Thankfully for my use case, I'm actually operating when the canopy is not developed yet/no leaves on the tree and less underbrush. So I usually "avoid" range testing in the summer until the leaves are off the trees. I should of called that out earlier in my results to date as well. Most of that was in winter/early spring. I was planning on leaving hardware setup all year in the woods and then plot RSSI and SNR over the months to see how much it decreases/increases with the canopy change between summer and winter but had to use the hardware for development until the next batch came. That would be interesting data though. Maybe next summer.

@Rftop - Obviously you've played in this sandbox before... what are the major challenges or disadvantages you had in using 915 MHz radios with Particle that we should consider or better understand and appreciate?

[jgskarda]

@wineisgud4u

My clients routinely damage them during normal farming operations.

haha... yeah, my background/childhood was farming. I know how rough farmers can be on equipment. This was my approach to the Solar Panel component. Some users have power, some users are OK with an occasional USB battery pack recharge, some users wanted a 12V deep cycle battery. So I made it an add-on option that plugs in. Might be a consideration to make it "replaceable" by purchasing a new one from you while still having the convenience of a rechargeable battery.

[Rftop]

@jgskarda

what are the major challenges or disadvantages you had in using 915 MHz radios with Particle that we should consider or better understand and appreciate?

For me, the largest hurtle was making decisions based on the FCC Certifications/Requirements/etc.

[jgskarda]

@Rftop

the largest hurtle was making decisions based on the FCC Certifications/Requirements/etc.

Yes - very good point. I am eager to get my hands on the BRN404X to try and work through that process. With the BRN404X having a different FCC cert than the BRN402/BRN404 and the BRN402/BRN404 being end of life, I didn't make sense to try and bite that off until having the supply secure hardware. For the LoR radio part, I'm using the RFM95 by hopeRF which is a FCC certified module. Still requires some work as you know but should be manageable. I'm sure I have lots to learn yet in this space though.

[jgskarda]

Time synronization between Particle and LoRa devices
In my exploration of using Particle + LoRa, one of the challenges/early learnings was to “synchronize” time on each device and overall have the Particle device coordinate the show. I’d appreciate any feedback or additional ideas.

@chipmc - I know this is a little different than what I shared with you earlier. Let me know if this makes sense. This approach uses a few more bytes in the LoRa payload then what I use today.

In general, I believe this is needed for a few reasons.

• LoRa nodes can not “talk” on top of each other or the message won’t go through. Although fairly small (depending on payload size and radio settings such as Spreading Factor), there is always a finite amount of “on air” time with each LoRa transmission. During this time, other nodes can not transmit. If it does, neither message will be received properly on the other end. Therefore, if using multiple LoRa nodes, it’s important to “define” a dedicated reporting window for each.
• If the Particle device is battery powered, you likely also want it to sleep along with the nodes. Naturally, if you have two devices sleeping/waking their time needs to be coordinated so they can sleep/wake together.
• For LoRa Mesh to function adequately, the nodes that service the mesh obviously need to wake up before any end to end messages are transmitted.

To help illustrate the strategy, here is a pseudo timing diagram.

Or when using full/mostly “LoRa Mesh”:

To accommodate this strategy… I was thinking of updating the LoRa “payload” sent back to each LoRa node to be the following. I’d be interested in your feedback:

• UNIX Epoch Time - Seconds (uint32_t) - 4 bytes
• Hundredths of a second: From AB1805 RTC - (uint8_t) - 1 byte
• Reporting Interval - Seconds (uint16_t) - 2 bytes
• Reporting Duration - Seconds (uint8_t) - 1 byte
• Device Report Offset - Hundredths of a second (uint16_t) - 2 bytes

This is an illustration of where each value is used for a device to create the overall timing diagram above. Each device would have a different report offset to stagger them.

A few dynamics of this payload structure I’d appreciate feedback on:
Sending full UNIX time - LoRa Devices don’t really need to know full UNIX time in my use case. Was originally debating to just send 2 bytes instead of 4. The precision would then be 12 hours. I’m leaning towards burning 2 extra bytes in the message to send the full UNIX time for simplicity (less math and easier to work with) and maybe there are future use cases I’m not thinking of yet.

Attempting to synchronize to Hundredths of a second - The value I see is the “whitespace” between each device transmitting can be reduced if we attempted to synchronize clocks down to hundredths of a second. I doubt it’ll be even 1 tenth of a second precise but it should be at least sub second precise. The more precise the time synchronization the more “white space” we could remove between each node reporting. The more white space we remove, the shorter the overall reporting window. The shorter the reporting window the less battery power we use. This does require external RTC with sub second accuracy on both the LoRa nodes and Particle + LoRa. Currently I’m already using the AB1805 per the application note on Particle and recently made some updates to set/get the hundredths second register. So it’s doable… just not sure how accurate it’ll be. Hope to find out this week.

Reporting interval having a value of 300 would indicate not only to send data every 300 seconds (i.e. every 5 minutes) but rather we’d use UNIX time to determine when the next reporting interval start time is. In this case, at the hh:05:00 of the hour. Such that it’s 12:00, 12:05, 12:10, 12:15, etc. This both sets the interval and synchronizes the start of LoRa reporting to Unix time across all devices. So far, I’ve always made this multiples of each other. I.e. 1 minute, 5 minutes, 20 minutes, 2 hours, 12 hours. Being 2 bytes the max unsigned value would be about 18 hours. Being multiples, if a node missed a message, it would eventually get in sync again. If it’s 2 bytes and in seconds, the max sleep duration would be 12 hours. This seems fine for most use cases, this seem reasonable?

Report Duration - Was debating on making this 1 byte or 2 bytes. This would save 1 byte in the LoRa payload but limit the Lora report duration to a max of 255 seconds. The artificial ceiling this would cause is the max number of nodes. Say each nodes reporting window was 3 seconds. Then the max number of nodes would be 85. This seems just fine but I hate artificial ceilings. What do you think… better to burn 1 more byte in the payload and not have a limit or use 1 byte and have an artificial ceiling?

Device Specific Rpt Offset - I’m between keeping it simple and using 1 byte with seconds or using 2 bytes and send it as Hundredths of a second. This is related to the question above of synchronize to sub second. The thought is let’s say we can synchronize to sub second. If 3 seconds per node was plenty of whitespace but 2 seconds causes an occasional overlap we would be stuck with 3 seconds. If there were 10 nodes our reporting window would be 30 seconds. Whereas if we could set it to say 2.2 seconds per device. The reporting window would be 22 seconds once again saving battery power on the nodes. Not sure…

[gusgonnet]

@jgskarda

LoRa nodes can not “talk” on top of each other or the message won’t go through.

Hey, other protocol implementations have collision detection (or when there is no ACK for the message they just resend) and would "simply" retransmit after a random delay (random so not two clients would start sending at the same time, and then retry at the same time).
Would a mechanism like this work and save sending the time to all stations?
I confess I did not read the whole thread yet, so if you talked about this already, please disregard.
Also, configuring a time slot for each client to report would be something to manage, and can lead to human errors, troubleshooting, and frustration.
For sleep times, what I just described might be toast, but there may be a way to accommodate, I do not know.

[chipmc]

@jgskarda ,

Thank you for this explanation, I am always impressed by the thoroughness of your work. Quite impressive and a great resource for the community. I like the way you laid out the problem (collisions) and a straightforward solution. I was worried that RTC drift may be an issue but then I remembered that the gateway and the nodes will all have the same RTC hardware and experience roughly the same temperatures so, this should not be a problem. So, sub-second accuracy does seem like a reasonable goal.

That said, I am on a “KISS principle” kick and this leads me to a suggestion that has been percolating for a bit.

In your timing diagrams, if I am reading them right, you are turning on both the LoRa and Cellular radios during the LoRA servicing window. From the Boron data sheet, turning on the LTE radio increases on the power consumption from ~4mA (uC on but cellular and peripherals disabled - no entry in data sheet for peripherals on but cellular off) to 108mA (cellular connected but idle). Given this 25x increase in power consumption, I can see why you are wanting to compress this window as much as possible while avoiding collisions. The goal should be to reduce the time that the cellular radio is on to the maximum degree possible to minimize power consumption.

Another approach might be to separate these events. You could wake and turn on the LoRA radio but not the cellular radio to service the LoRA devices and mesh. This might allow you to stick to simpler seconds-based time math and signaling. A rough estimate of the impact of this approach would be:

Four nodes x 2 extra seconds of 4mA “awake but cellular off” consumption x 24 LoRA windows a day (hourly) = 155mAH per year.

Of course, you could always implement both delaying the cellular and sub-second timing to get the maximum benefit.

I am just wondering if the sub-second optimization juice is worth the squeeze.

Thanks,

Chip

[Rftop]

Jeff, Since you’ve now mentioned a Sleepy Mesh - I remember something else to share.

When I tested a Sleepy Mesh, I soon realized that adding an additional Node to the network became a chore. I eventually created a Particle Function so that the “Gateway” Electron/Boron knew how to handle the addressing, endpoint, and scheduling for the “n+1” Node. But this must also be added to your stock CODE, or the node update will be lost at the next OTA flash. I’m sure there are nice and neater ways to handle this though.

I usually run a 2-week Validation Trial before any deployment. I never could get a Sleepy Mesh to stand up for 2 weeks without my involvement. I ended up with the Mesh Concentrators/Routers being powered 24/7 for projects that required a Mesh Footprint. That eliminates the Nodes needing a time sync. With the 27/7 footprint (and Point-to-Point), I actually sleep my nodes for random periods of 300 seconds (+/- 5 sec). That could be an entire Thread’s worth of discussion by itself.

A lot of that does not apply to your Project.
Everybody knows that I’m a fan of Solar for IoT. I know there are problems associated with keeping a Panel protected. But removing the power budget from the list of concerns is nice , plus it solves a lot of other problems.

[jgskarda]

@gusgonnet

Hey, other protocol implementations have collision detection (or when there is no ACK for the message they just resend) and would “simply” retransmit after a random delay (random so not two clients would start sending at the same time, and then retry at the same time).

@gusgonnet - that's a really good suggestion! In fact, the RadioHead libraries that implement Mesh include what's called "Reliable Datagram" and you can specify how many retries. This is reliable between two nodes not end to end. I currently have it set at 3 retries. They also have what's known as "channel activity detection" Wait Channel Activity Detection. From what I understand, if I try to publish a LoRa message, it first sees if there is any activity on the channel before it begins transmitting. The timout says, wait this long after the lack of any activity.

In short, my observations says this simple technique works quite well for <5 LoRa nodes and works especially well if the Particle + LoRa was always on and wasn't attempting Mesh. Then any node can communicate any time so they can be spread out widely over the time period. As soon as you try and get >5 nodes communicating in a short period (less 30 seconds). Then even with tweaking these settings I started to miss messages. I'd equate it to a LoRa RF storm as all the nodes tried to talk/retry/fail/retry as I added more than 5 nodes. Thus... now thinking about how the Boron can better "orchestrate the show".