I have been looking through the forum and the library system and can’t seem to find a good example of a Particle library to use with an RFM69 connected to my Boron.
I have tried the RFM69-Particle library but cannot get the example code to compile. Others, like the Radiohead port from Sparkfun are over 8 years old.
Could someone point me to a library that would work with the current LTS release - deviceOS@2.3.0?
Thanks,
Chip
Chip, my first thought is to ping @RWB as I know he made a deep dive into this a while back.
I haven’t noticed forum activity from Ryan in a while…but it’s worth a shot.
@chipmc - Looks like you getting a chance to play with 915 Mhz radios a bit? Curious… what is driving you to use the RFM69HW vs RFM95? Wouldn’t mind learning more the advantages of the RFM69HW over the RFM95. It’s been some time since I researched but I thought RFM69 had less range:
Since range was my biggest factor, I went with RFM95 (LoRa). I personally use the following libraries:
#include <RH_RF95.h>
#include <RHEncryptedDriver.h
I believe both of these are from the RF9x-RK library
My seasonal time of year is starting to wind down… happy to connect again sometime and discuss if you would like and compare notes.
Yes, good question. I was only going for point-to-point and did not need too much range so I went with the cheaper RFM69. That said, I also have RFM96 boards here and plan to look at them too.
I am imagining three different use cases and would love to get your or other’s inputs.
In the first two cases, the Boron is connected to the cellular network for backhaul:
Finally, I wanted to see what I can do with LoRAWAN with a base station that connects to cellular, WiFi or Ethernet and connections to the Particle devices via Particle function calls.
Does this make sense?
Let’s find a time to connect, I would appreciate your expertise on this.
Chip
@chipmc Yeah, I think your 3 cases make sense… A few additional comments:
I personally have not explored mesh capability or repeater capability yet within RFM95. Supposedly it’s possible, as I’ve seen libraries and examples but we didn’t explore that yet. So far, I’m all point to point.
One potential advantage to RFM95 is through loading different firmware you can configure it to be LoRaWAN or LoRa point to point. I at one point for a quick test, just loaded firmware and was able to send data to The Things Network (TTN). I then re-loaded my original firmware to send data point to point. Was thinking it could be more “future proof” hardware if/when LoRaWAN continues to grow or I stumble upon use cases that already have LoRaWAN access I wouldn’t have to make a hardware change but rather just firmware. Could potentially do it via a DIP switch on the PCB even to have identical hardware be compatible with both. That’s all down the road…If I stumble into an opportunity with existing LoRaWAN…
The standalone LoRaWAN as a base station and connect to particle devices via RFM95 I’m not sure I understand. Is the intent to send most data via LoRaWAN but still maintain a particle device (maybe a Boron) for occasional and simple Firmware updates when needed. Keep the cellular off for low power when publishing data but you can flip it on for a firmware update? Or what’s your thoughts on the dual back haul capability (cellular and LoRaWAN)?
For customers who want WiFi, I am debating between the Argon (same form factor as the Boron which I use now for easy swap out with no PCB changes but deprecated Argon hardware) vs Photon2 (new hardware but I think require different PCB) vs spin up a LoRaWAN gateway, connect that to WiFi and then use RFM95 nodes as sensors configured as LoRaWAN. Not sure what path we will go down to meet that need.
What’s the power difference between a RFM69 and RFM95x with/without MCU. I don’t have much of a size constraint, so using a single 18650 Lipo. publishing every 5 minutes I should last 12 months or more. It’s not quite linear but publishing every 2 hours or even less frequent then that I’d think I’d go multiple years. Need to pull out the low current sleep meter again and calculator to see how long it would last with less frequent data pushes. This is with RFM95 + MCU. But that battery and extra MCU certainly adds some cost.
Thank you for your note - that is a great point. Perhaps the RFM95 is a better answer for both of my first two use cases. I had not thought of the LoRA / LoRAWAN being selectable in software - that could support a standardized hardware platform covering all my use cases with the RFM96.
So, I am thinking that there are some compelling use cases and, as you can see, I am still trying to wrap my head around this.
I did some more digging on the idea of a RFM69 or 96 without a microcontroller. This does not seem to be viable so, for now, I will stick with the transceiver / uController combo.
Happy to talk more. Who knows, perhaps there could be a Particle solution in this space someday. 
Chip
Yup... That would be awesome! 
Every year I get hopefull around Spectra something will be announced in this space but nothing yet.
Your use case #1: is essentially what I am doing today. Have 1 Boron act as a sensor and have it also act as a Lora Bridge with cellular backhaul to "listen" to neighboring LoRa sensors. Every reporting cycle, the Boron first takes its own readings from hardwired sensors, then listens for other LoRa sensor nodes. It assembles all the data from itself and nodes in a single JSON to publish. This way all the data is sent out in 1 data operation. With 10 or fewer nodes, the number of data operations is the same (i.e. 1) so adding nodes didn't affect monthly cost as long as I'm under the 640 byte limit. If I'm over, then we just break it up into two publish events. In some cases, it's another 10-20 sensors within a 40-80 acre property. Not only is LoRa node hardware slightly less expensive, it is very light on power so doesn't require any large solar or large battery and as I mentioned, I plan on going several years on a single 18650 since it's so light on power. I did include a micro USB plug on the PCB so IF/When it comes time to charge, a user can pop the enclosure open and just plug it in for a few hours to give it another few years OR they can swap it out for a fully charged one from a wall charger. One of my strongest value propositions is a lower cost point of entry. I.e. a customer can start with just the Boron that has sensors wired to it and at any point in the future add just LoRa nodes. Most competing products and products in the LoRa/LoRaWAN space requires a standalone gateway that requires wifi/internet, and then individual sensors. For me, that would be 4 components that I all wrapped into 1 piece of hardware so able to keep the cost of entry more cost effective than other options. The customer also just has to turn the thing on vs having to try and spin up their own MiFi hotspot, configure wifi on it or somehow establish internet connectivity in the remote location. The particle boron all-in-one approach keeps it more affordable and very simple for the end customer.
Your use case #2 I'd think is pretty strong possibility as well. I'd have to think most parks have some sort of internet service somewhere even just at the welcome/ranger station. That said, you know your customers more. Maybe county parks or other smaller parks don't have that. I'm also guessing that internet connection if it did exist, is likely not in the "optimal" location to cover the entire park. So maybe a particle Boron + LoRa can be located in the most optimal location to maximize coverage.
A few other considerations I've been contemplating and soon exploring in this space:
If I write the LoRa Node firmware using Circuit Python instead of Arduino, conceptually, a user could update firmware easily himself (acts as a USB memory stick and just drag/drop a new file onto it). No special software/hardware needed. I added some EEPROM to store device ID and a few other device specific parameters on the PCB so firmware is generic for all devices. I don't expect it to occur often but trying to not close that door of allowing remote firmware updates for remote LoRa Nodes. This still takes several physical steps and user intervention vs OTA but would be nice to keep the door open.
On going monthly cost I believe is also less using Particle LTE Cat M1 vs I believe traditional LoRaWAN gateway requires true 4G LTE service. This is both higher cost but also likely more connectivity issues in remote areas compared to Particle LTE Cat M1. (I think... I never really tested or investigated this myself)
Particle Boron sleep is I recall ~120 uA... If it also has a LoRa radio and "synchronizes" the sleep/wake cycle of all LoRa nodes, it can be a low power sleeping LoRa Bridge. It can be a low power sleep "pseudo" LoRa gateway allowing it to operate in areas without mains power without excessively large solar panels and battery packs. I personally use a 6600mAH LiPo battery with a 3.5 Watt solar panel and been operating several of these for the last 2 months supporting 5-10 LoRa nodes each transmitting data every 5 minutes. I never looked at true LoRaWAN gateways besides the one I spun up myself using a raspberry PI for testing but I'm guessing they all require much more power and non of them are able to sleep/wake. Even in my case, I actually keep the Boron in the "always on" mode and battery charge still never went less than 60%.
If I went true LoRaWAN, I'd just configure The Things Network/Helium network to send the packet of data via Web hook to the same Azure Function I use to process Web Hooks from Particle. That way the rest of the backend would be identical weather it came from Particle or TTN/LoRaWAN provider.
So that was very long winded... but just a few other considerations. By no means am I saying I made all the "right" decisions but just sharing some of my rationale for the road I went down and learnings along the way.
Thank you for the insights. I think this is very consistent with my thinking.
I thought it might be fun to imagine what a Particle LoRA offering might look like:
So, with no hardware sales, why would Particle do this? Simple, all this LoRA data would drive data operations - this is an advantage Particle’s new pricing model.
What do you think? If this existed, would anyone buy it?
Chip
My general impression is Particle focused the last major development on the “Micro Mobility” or just mobile IoT applications within the broader IoT space. Thus the tracker and all things involving the tracker was developed. I’m sure lots of opportunity in that space/segment of the market. However, much of what you and I are discussing is more of the “precision agriculture” or other remote/rural type IoT segment within the broader IoT space. Most other conversations around LoRa in this community involved some sort of agriculture/irrigation type of application. I hope Particle can also see the potential in the application of IoT in the agriculture segment and extend additional products (maybe just firmware libraries, tutorials, etc.) to better address the needs of the agriculture/rural settings of IoT applications. I have a feeling there is a lot of complexity/trade offs that would have to happen if offer just firmware/cloud/libraries and it likely would require a hardware offering as well to be full featured and a “product” but at this point, I’ll take whatever can be offered.
When the time comes that Particle focuses on meeting the needs of the rural/agriculture/irrigation segment in IoT (whatever that entails), I most certainly would buy It!
The RFM95W radio feather wing is great for prototyping. I prototyped with that exact hardware. I ended up using that same radio RFM95W on my final Particle Boron custom carrier board. By using the radio directly on the carrier board, it removed the dependency upon Adafruit availability/stock and I could purchase just the radio for $6-$7 vs using the full Adafruit feather for $20. This also took up less space, became a cleaner design and was much easier to have a good location for the SMA antenna having it all on the carrier board vs using the feather wing. Once again… great for prototyping though.
You may want to consider the Adafruit Feather M0 RFM95 instead of the 32u4. If you ever wanted to go mesh and/or full LoRaWAN I think you’ll need the extra processing and memory of the M0. Atleast that was my rationale for going M0. Here’s the M0 version:
Here is some quick explanation as to why in a deprecated tutorial:
However, I’m a bit out of touch with what changes happened on TTN but wondering what is all affected by this deprecated statement and IF a standalone FeatherWing M0 can still join the TTN or not or if it’s only the gateway the mentioned in the tutorial. Will have to dig into that more. It was last summer when I did my original TTN testing and seems like things have changed since then. Not sure what. May need to test that again just to understand.
One other note… either I’m dumb and couldn’t figure it out, but the M0 and 32u4 does not have EEPROM. If you wanted to use the identical application code on all devices, then you need some sort of EEPROM to store each devices unique ID outside of the application firmware. Between that, keeping hardware cost down, and not wanting to be dependent upon Adafruit part availability, it also drove me to a custom PCB for my LoRa nodes even after I prototyped with the Feather M0 LoRa feather. I simply load the device ID and some other config data to EEPROM first and then load the application firmware when commissioning a new LoRa Node.
This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.