Author Topic: Moteino RFM library VS RadioHead  (Read 128 times)

ydylwj23

  • Newbie
  • *
  • Posts: 4
Moteino RFM library VS RadioHead
« on: April 16, 2019, 08:18:32 PM »
Hi Everyone,

About 2 years ago I used Moteino in one of my project to create a network of 1 gateway and around 10 Nodes and it was a great success. Now I came back to the RF world again trying to build another project but I'm having problems picking libraries and products.

First is the library: According to https://lowpowerlab.com/guide/moteino/lora-support/ , the nice RFM library made by Felix cannot be used in any LoRa modules so I have to look into using RadioHead http://www.airspayce.com/mikem/arduino/RadioHead/index.html since I planned to use LoRa RFM95. After a few examples, I realized that RadioHead library doesn't offer any subnetworking functionalities like Felix's library does. This is really weird to me. Shouldn't subnetworking be a very essential function since crosstalk can be a big problem for these long-range RF modules? For an amateurish coder, it seems that the more popular RadioHead library is far less convenient in this sense. Let along with that subnetworking security is very standard in Felix's library too. Am I missing anything here?

The second question: For some reason, I can't find any direct comparison between Moteino and Adafruit feather. To me, these are pretty much heads-up competitor products. What's your guys' opinion on choosing between these two boards?

Thank you guys! :)

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5708
  • Country: us
    • LowPowerLab
Re: Moteino RFM library VS RadioHead
« Reply #1 on: April 17, 2019, 09:14:19 AM »
RE RadioHead - can't speak for it but I can say I consider writing another library for LoRa that is easy to use. Would that be an appealing prospect?

The second question: For some reason, I can't find any direct comparison between Moteino and Adafruit feather. To me, these are pretty much heads-up competitor products. What's your guys' opinion on choosing between these two boards?
I did not design the M0 to be a clone or a look-alike to the Feather.
There are many differences, from physical and header layout, to pin arrangement, to low power, to OTA support, price. I would go as far as say that apart from the MCU and the radio module, they are 2 different products.

ydylwj23

  • Newbie
  • *
  • Posts: 4
Re: Moteino RFM library VS RadioHead
« Reply #2 on: April 17, 2019, 11:40:07 AM »
Thx for the fast reply Felix!

Another library for LoRa would be appreciated! In my new project, I need 3-5 LoRa sensor networks working in the same building so subnetworking capability is a must. Still don't know why RadioHead doesn't support it.

As for the feather M0 and Moteino M0, I totally understand that it's not a clone or copy from either side. But as the end user, these 2 products are very comparable. Same MCU & Radio, similar function(Moteino has wireless programming support), pinout(feather M0 has fewer pins, they decide not to expose the 2nd hardware serial) and size. Feather has a little more expansion capability with Adafruit's Featherwing "shield" ecosystem. BTW, Moteino m0 Lora without FLASH is $34.95 while Feather m0 Lora is $34.95 as well... So, very comparable for end users in my opinion.

ydylwj23

  • Newbie
  • *
  • Posts: 4
Re: Moteino RFM library VS RadioHead
« Reply #3 on: April 17, 2019, 03:37:17 PM »
I was doing more research on the matter today and found out that your network ID feature comes from part of "syncword" value according to RFM69 datasheet. But for some reason, HOPERF made no mention of this feature in their datasheet for RFM95(Register 0x39) https://cdn.sparkfun.com/assets/learn_tutorials/8/0/4/RFM95_96_97_98W.pdf. In contrast, it appears in SX1276 datasheet (Register 0x39) https://www.mouser.com/ds/2/761/sx1276-1278113.pdf.

Maybe this is why Library like RadioHead is not using it?

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5708
  • Country: us
    • LowPowerLab
Re: Moteino RFM library VS RadioHead
« Reply #4 on: April 17, 2019, 03:47:01 PM »
You can do "networking" in different ways.
Also to note that the Hope RF datasheets are just rebranded versions of the Semtech datasheets for the transceiver chips. They only make a few changes and replace the images with those of the actual modules.

ydylwj23

  • Newbie
  • *
  • Posts: 4
Re: Moteino RFM library VS RadioHead
« Reply #5 on: April 17, 2019, 08:00:17 PM »
Hi Felix,

Can you briefly elaborate what you mean by different ways of doing "networking"? For me, if using RadioHead(no native networking), I plan to add network identifiers in the message or in the address number. Like giving networking #1 nodes addresses 100-199 then networking #2 nodes address 200-299 and so on. Then in the actual code, always filter out messages coming from different networks by checking the hundred digit.
My worry for this method is message collisions since all nodes will be talking to each other in the building of 3 networks. Even though they can still filter messages they want but too much collision might leads to packet loss. Native networking by snycwrods on the other hand, will not have this problem since packets from different networks are just ignored(If I understand this correctly).

Thank you so much!

Felix

  • Administrator
  • Hero Member
  • *****
  • Posts: 5708
  • Country: us
    • LowPowerLab
Re: Moteino RFM library VS RadioHead
« Reply #6 on: April 18, 2019, 08:23:47 AM »
It depends on what you want to achieve and how you want to separate the "networks".
A few examples of how you can separate the "networks":

- using identifiers in the packet payload, everything else the same
- use the network ID in the header, then this is done automatically, allows you to have nodes that can listen to other networks
- use different frequencies to separate networks, this increases bandwidth and allows more networks in parallel but also increases complexity since you have to deal with receiving on all frequencies

For the first 2 above, you have to share a frequency, this is simpler and more convenient if you can live with the "limited" bandwidth of just 1 frequency, but increases collision probability as average number of packets increase.

So this problem comes with pros/cons just like anything else. You have to weigh your requirements carefully and decide what is the best approach.