Has anyone start to work with LoRa on the new mesh devices. I added the Radiohead library to my project, but I get the following compiling error.
lib/RadioHead/RadioHead.h:574:24: stm32f4xx.h: No such file or directory
I am guess there needs to be some work done to make the Radiohead library to work with the new mesh products.
Note that there are a few parts to this:
- The relatively easy part of exchanging point-to-point packet data using LoRa.
- The harder part of making the Xenon’s cloud connection work over LoRa.
- Implementing LoRaWAN to make the cloud connection work to a public network over LoRaWAN.
I have the Adafruit RF95 FeatherWings and will port a library for it to the mesh devices. That’s part 1.
The other parts may or may not come later.
1 Like
Thank you for the response. I think point-to-point will work for now. I do not see or have the need for a mesh network cloud network. Can always translate to doing a LoRa to Cloud on a device like the Argon or Boron.
There is a new library, RF9X-RK. This is a port of the RadioHead Packet Radio Library version 1.89 for RF95/96/97/98 LoRa compatible radios.
It should work with these Adafruit radios:
- RFM95W 868 or 915 MHz Americas ITU 2 license-free ISM
- RFM98 433 MHz for use in Europe ITU 1 license-free ISM
While I used the FeatherWing version, it should also work with just the breakout.
If you are using the Adafruit Radio FeatherWing you should just follow the Adafruit instructions.
The radio communicates by SPI (MISO, MOSI, and SCK) and these pins are fixed.
However, there is a choice you need to make for the 3 remaining control pins. I selected these pins:
| Pin | Map To | Particle Pin | Color |
|---|---|---|---|
| IRQ | E | D2 | Green |
| CS | A | D6 | Yellow |
| RST | F | A5 | White |
The reason is that D3, D4, and D5 (D, C, B) are used by the Ethernet FeatherWing, and by using different pins you can put the Radio FeatherWing in the Particle Ethernet FeatherWing along with a Xenon to make a nice base station.
After soldering the headers and the jumper wires are shown above:
I included what I believe to be a useful subset of the RadioHead library features:
- RF95/96/97/98 radio support
- Reliable datagram
- Encryption (optional)
You can easily make a fork of this library and add in a different set of features copied from the RadioHead distribution easily, if you wanted to.
There’s also a sample program that displays the output on the Adafruit OLED FeatherWing.
6 Likes
Nice work! This is a bit off-topic, but using LoRa for Mesh doesn’t sound practical to me due to the low bandwidth. Although the Sx1276 radios can also be used in FSK mode with quite a bit higher bandwidth (sitting somewhere in-between LoRa and Bluetooth in terms of bandwidth and range).
The other thing I bumped into is the fact that all the layers for Mesh seem to be pretty tightly integrated and not very modular, so (besides the user/system barrier which can be opened up) I found it difficult to reuse anything. As an example, the DTLS layer can’t be used to encrypt/decrypt packets in isolation for a separate comm layer, it’s intricately intertwined with the Mesh’s buffering. So Mesh over LoRa (or FSK) would have to hook into the system firmware at the very bottom as an additional transport, which may or may not be feasible, or it would need an almost independently developed software stack, which is a lot of work.
This is awesome. Looks like there might be a misspelled file name. I get this compile error.
rf95_reliable_datagram_server.ino:2:21: RF9X-RK.h: No such file or directory
There is a missing include file if you use the Use This Example. Just delete the
#include "RF9X_RK.h"
line as it’s not needed.
Also fixed in version 0.0.2 of the library, just published.
2 Likes
Yea!!! That was fast. It now compiles. Now it is time to play with this library.
This code works great. Exactly what I was looking for. Thank you so much.
2 Likes
Having issues when using the Adafruit Radio FeatherWing with a Xenon with a Particle Ethernet FeatherWing. Everything is working fine without the Ethernet FeatherWing.
Pretty sure that this is the issue:
How do I change the RST pin from A5 to A0 in the library?
Looks like the A5 issue will be fixed:
In the meantime, is it possible to change the RST pin from A5 to another pin? @rickkas7
Actually, the hardware reset line isn’t used by the RH_RF95 library, so you can just remove that connection from A5 to RST. Or you can assign it to a different pin.
1 Like
I just assumed that it was required, since it was wired. I will remove it and test it out.
Thanks!
Removing the connection from A5 to RST did not help. I am leaving it unconnected, which should be fine since there is a pull-up to 3.3V on the board.
Using your firmware with an Argon Client and an Argon Server works fine. When I change out the Argon Server for a Particle Ethernet FeatherWing with a Xenon I get 3 or 4 packets through right after boot up, before connection to Cloud, and then nothing gets to the Server. I assume that as the Particle Ethernet FeatherWing is “booting” up it messes up the other IO lines.
I tried IRQ = D2 , CS = D6, as you recommend and also IRQ = D7, CS = D8, with the same result.
Has anyone got this to work with a Particle Ethernet FeatherWing?
Still having issues with this. @rickkas7
I scoped the lines and the defined CS pin for the RFM is being held LOW and the INTs stop when used with a Particle Ethernet FeatherWing. There is a conflict with the SPI, as sometimes the Ethernet connection works and other times it doesn’t.
I added the RST pin and some delays on start-up, but no difference.
Please test your basic Client/Server code with a Particle Ethernet FeatherWing to see if you get the same results.
1 Like
It’s not currently possible to use the RF95 with the Ethernet FeatherWing. There is a bug in my library where I forgot to enable SPI_HAS_TRANSACTION. However, even after fixing that, it doesn’t work.
There appears to be a bug in Device OS (at least through 0.9.0) where there are two different SPI transaction mutex and thus user code and the Wiznet aren’t actually prevented from interfering with each other.
1 Like
To be clear, the SPI issue with the Particle Ethernet FeatherWing will impact all other SPI devices, so effectively the Ethernet FeatherWing can be the only SPI device used. SPI1 is also not an option, since some if those pins are used and currently can’t be re-mapped.
Waiting semi-patiently for the Device OS fix. 
1 Like