Second setup, choosing a radio
-
I suppose the pinouts may matter for legacy upgrades, but for new designs I presume you'd be better off using a LoRa module that comes with built-in metal shielding: better SNR and FCC (or equivalent) compliance. Also, the better LoRa modules come with TCXO's, which would be added benefit. None of the HopeRF's shown above have TCXO's or metal shielding. That's not to say they wouldn't work, but if it were me, I'd move on from those to something better, or at least more compliant.
@NeverDie
lora modules are more expensive. You can find rfm69 for 1.8€ shipping included which work great and they are widely available compared to some lora modules.
I think it depends on projects goals.
But I agree with your points of course :) -
Here I'm sharing something I just learned which maybe most people aren't aware of: It used to be that the RFM69 was much faster than LoRa, but with Semtech's SX1280 chip, LoRa can sustain a datarate of up to 254kbps, which is close to the 300kbps maximum of an RFM69. And, I suspect that with LoRa's greater receive sensitivity, it might be able to attain its highest datarate more than the RFM69, under similar conditions. But the cherry on top is that also Included in the SX1280 chip is an FLRC modem which can get up to 1.3mbps.
In addition, the FSK modem that comes with the SX1280 has a top datarate of 2Mbps.
Now, granted, the SX1280 operates at 2.4Ghz, not the sub-1Ghz of previous LoRa or RFM69, but Semtech is claiming the SX1280 has extremely high immunity to both Wi-Fi and Bluetooth interference, well, at least in LoRa mode that is.
The SX1280 also has range finding built into it for asset tracking, so, at least to me, it sounds like an interesting chip. If the environment happens to support high speed communications, then you can use that, but if not, you can always fall back onto LoRa to get your packets through.
I've checked, and EByte has some SX1280 modules available on Aliexpress.
-
I suppose the pinouts may matter for legacy upgrades, but for new designs I presume you'd be better off using a LoRa module that comes with built-in metal shielding: better SNR and FCC (or equivalent) compliance. Also, the better LoRa modules come with TCXO's, which would be added benefit. None of the HopeRF's shown above have TCXO's or metal shielding. That's not to say they wouldn't work, but if it were me, I'd move on from those to something better, or at least more compliant.
@NeverDie Agreed. But at the same time I think it's easy to underestimate which impact projects like MySensors or Low Power Lab (Moteinos) have with the selection of hardware they provide or advertise. If they focus on unshielded HopeRF modules for SX12xx transceivers, then that's what most people are going to buy, because they think that's what they must buy to stay compatible. They're well known, widely supported / documented / endorsed and, of course, relatively cheap. That's exactly why those black NRF24 modules are still so popular.
Different "standard" or go-to hardware is difficult to establish. But if one knows exactly what parts are needed, how to get them working and the design is specifically for a personal project, sure - pick better parts with shielding, etc.
I bought some HopeRF modules to simply test sub-GHz RF and was suprised how well they worked, so I kept using them. They dropped only 1 in about 5000 messages (0.02%) on average over the past two month. I built a Dual-RF GW and am super happy with it (aside from an ATC issue with 2.4.0). I might get different transceiver in the future, but for now, they're doing a great job.
Here's a quick sketch of the coverage in our house (pumice stone walls and reinforced concrete floors), comparing NRF24 and the HopeRF RFM69 transceivers. I can reach every corner of our property with a RFM69HCW on the GW and a non-amplified RFM69CW on the node. LoRa would be totally overkill for me if they have no significant benefits other than increased range. (Maybe lower power consumption?)
-
@NeverDie Agreed. But at the same time I think it's easy to underestimate which impact projects like MySensors or Low Power Lab (Moteinos) have with the selection of hardware they provide or advertise. If they focus on unshielded HopeRF modules for SX12xx transceivers, then that's what most people are going to buy, because they think that's what they must buy to stay compatible. They're well known, widely supported / documented / endorsed and, of course, relatively cheap. That's exactly why those black NRF24 modules are still so popular.
Different "standard" or go-to hardware is difficult to establish. But if one knows exactly what parts are needed, how to get them working and the design is specifically for a personal project, sure - pick better parts with shielding, etc.
I bought some HopeRF modules to simply test sub-GHz RF and was suprised how well they worked, so I kept using them. They dropped only 1 in about 5000 messages (0.02%) on average over the past two month. I built a Dual-RF GW and am super happy with it (aside from an ATC issue with 2.4.0). I might get different transceiver in the future, but for now, they're doing a great job.
Here's a quick sketch of the coverage in our house (pumice stone walls and reinforced concrete floors), comparing NRF24 and the HopeRF RFM69 transceivers. I can reach every corner of our property with a RFM69HCW on the GW and a non-amplified RFM69CW on the node. LoRa would be totally overkill for me if they have no significant benefits other than increased range. (Maybe lower power consumption?)
@BearWithBeard Yes, you're right: there are many advantages to sticking with "known good" hardware--vetted by a larger community--as well as not fixing something if it isn't broken.
On the other hand, if you want to try range-finding asset-tracking, then you maybe (?) have to consider something new in addition to (not as a replacement for) what you already have. What are the alternatives? I guess maybe Bluetooth, or something that beeps when you press a button like a key finder. Perhaps those are good enough. Not sure.
-
@projectMarvin said in Second setup, choosing a radio:
I'm currently in China, 915 and 868 are not legal here :/
oki!
Yes there are some, but even on aliexpress when you look at the sales numbers you will see that basically no one are buying the rfm69w/hw and quite few are selling them.
Still it's available for ordering. I prefer using HCW and CW because they have a more compact footprint. but I ordered HW/W in the past on aliexpress too, no problem. works the same, only the pinout changes.
Really? How does this work? Do you reprogram them?
Considering they are different size, different number of pins and have the pins in different positions.Nope. RFM69HCW and RFM95 have same size and mapping, you can take a look in datasheets. Note: only HCW variant is compatible.
Does is also work with rfm69 <-> rfm96 & rfm98? (96/98 are 433 MHz :) )
If so this would be really interesting solution.Unfortunately, we test what we have in stock and use, so I've no idea about those 433mhz modules..maybe yes in theory, but I've never tried this setup.
@scalz Sorry, I didn't notice you were comparing 69 to 95.
@BearWithBeard Nice drawings! What did you use to draw those?
-
@NeverDie Yeah, different use cases and demands may require to use alternative hardware. I deliberately chose to represent the standpoint of a beginner to provide another perspective as to why people are still buying "mediocre" hardware. I didn't mean to contradict you. You are highly experienced and show that with your contributions. I often learn something new when I read your posts (latest example: the SX1280 above). I hope it stays that way!
@projectMarvin Thanks. In an attempt to step away from Adobe products, I'm using Affinity Designer for a while now and I'm very happy with it for vector graphics and interface design.
-
@NeverDie Yeah, different use cases and demands may require to use alternative hardware. I deliberately chose to represent the standpoint of a beginner to provide another perspective as to why people are still buying "mediocre" hardware. I didn't mean to contradict you. You are highly experienced and show that with your contributions. I often learn something new when I read your posts (latest example: the SX1280 above). I hope it stays that way!
@projectMarvin Thanks. In an attempt to step away from Adobe products, I'm using Affinity Designer for a while now and I'm very happy with it for vector graphics and interface design.
@BearWithBeard I liked the RFM69, but I quickly gave it up over concerns such as: https://hackaday.com/2017/12/20/fcc-fines-drone-fpv-maker-for-using-radio-spectrum/
The way I read the US regulations, it seems much easier for a LoRa device to conform and yet still have rock solid connectivity, whereas the rules effectively handicap narrowband by imposing cripling tx power limitations and non-generous duty cycles. And each ISM band has unique requirements as to what is allowed and what isn't. If you live somewhere else, then obviously the rules may be different.So, rather than being overkill, I see the receive sensitivity of LoRa as a real gift, allowing the Tx power to be dialed down to truly insignificant levels that can't possibly bother anyone or anything.
-
@NeverDie
I agree too. I don't think a Lora module is overkill, it has interesting features. it just depends on project criteria, there are also commercial products using rfm69.A nice setup is using rfm95/Lora module on gw, then you can use rfm69 and rfm95/Lora modules for nodes depending on requirements.
I don't need to mention antenna tuning etc for diy nodes, but it's good to remember, software needs to be compliant too with regulations.
MySensors lets that freedom to users, so nothing prevents them to use too high power levels, or flood a rf band, break duty cycle, and become an outlaw..Still, there are basic mechanisms in MySensors, available only for rfm69/95, like:
- listen before send, for free channel
- automatic power control for better battery lifetime, and greener communication which dials down TX power to very low levels. But it requires to use new rfm69/95 driver.
-
The joke is that "CE" stands for "Chinese Exemption," since Chinese companies and make and sell whatever they want into the US and European markets with with no repercussions whatsoever.
-
Hello everyone :)
I'm about to start my second MySensors setup. First one was a few years ago but I put it on hold and decided to focus on getting a stable setup in OpenHAB with some commercial sensors.
Now I'm back looking to expand on the sensor front and I think MySensors is the best option.But what radio is the best choice today?
I don't have anything left of my old setup so I'm starting fresh.
After digging through the forum I have come up with the following setup and would really appreciate some feedback.MQTT GW: Amplified nRF52840
Nodes: nRF52840 or nRF52832The plan is to mostly have battery powered nodes.
Are these good selections or are there any better options that I have missed?My plan is to initially use a dev kit and a usb dongle to get started and then make custom sensor boards connecting to and powering the nRF52s.
Any and all input is highly appreciated :smile:
@projectMarvin
As you're really interested in Nordic nRF52840 and nRF52832, I can't prevent myself from suggesting you to have a look at this project where I used a mesh of low power sensors with two types of dongles UART and native USB.
https://github.com/nRFMesh/nRF52_MeshI do not place this project as alternative to MySensors as it does not have the same goal at all (no community, not many sensors), it's very custom, but the advantage is flexibility in case someone wants to be closer to the official nRF SDK, as that's my sole dependency and it is not using softdevices so leaves freedom to use priviledges and inetrrupts as needed.
I've been actively looking for standardised method to fulfill low power sensors, mesh network with OTA update. And the way there seems clear but very slow. only nRF52840 supports zigbee, and you need a custom zigbee to MQTT for each network. I have hopes that Thread (OpenThread) will resolve this, but thread is too experimental at the moment and 0 commercial sensors compare to all zigbee sensors available on the market.
So I guess, the radio choice for you will depend if you target a commercially supported project which has a development budget or a DIY plan, also how much effort is intended to be spent on custom sensors creation compared to using low cost existing ones. I realised that I can't make DIY sensors cheaper than the existing zigbee one, which breakes the goal of the DIY model unless you do it for learning purpose or for fun.
I'm checked the micro python / circuit python, but that's also a slow evolving path where it's not the HW supplier that's worried about porting the drivers but a third party have them limited to some peripherals.
Nordic has OTA examples since the very first SDK of nRF5xxx, but it's way challenging to bring it to a seemless user product, just configuring nRF compile flags is quite complicated.
I'll keep watching this forum closely and be happ to see a working solution with nRF52xxx, I do have x5 of those nRF52840 usb dongles. -
@projectMarvin
As you're really interested in Nordic nRF52840 and nRF52832, I can't prevent myself from suggesting you to have a look at this project where I used a mesh of low power sensors with two types of dongles UART and native USB.
https://github.com/nRFMesh/nRF52_MeshI do not place this project as alternative to MySensors as it does not have the same goal at all (no community, not many sensors), it's very custom, but the advantage is flexibility in case someone wants to be closer to the official nRF SDK, as that's my sole dependency and it is not using softdevices so leaves freedom to use priviledges and inetrrupts as needed.
I've been actively looking for standardised method to fulfill low power sensors, mesh network with OTA update. And the way there seems clear but very slow. only nRF52840 supports zigbee, and you need a custom zigbee to MQTT for each network. I have hopes that Thread (OpenThread) will resolve this, but thread is too experimental at the moment and 0 commercial sensors compare to all zigbee sensors available on the market.
So I guess, the radio choice for you will depend if you target a commercially supported project which has a development budget or a DIY plan, also how much effort is intended to be spent on custom sensors creation compared to using low cost existing ones. I realised that I can't make DIY sensors cheaper than the existing zigbee one, which breakes the goal of the DIY model unless you do it for learning purpose or for fun.
I'm checked the micro python / circuit python, but that's also a slow evolving path where it's not the HW supplier that's worried about porting the drivers but a third party have them limited to some peripherals.
Nordic has OTA examples since the very first SDK of nRF5xxx, but it's way challenging to bring it to a seemless user product, just configuring nRF compile flags is quite complicated.
I'll keep watching this forum closely and be happ to see a working solution with nRF52xxx, I do have x5 of those nRF52840 usb dongles.@wassfila Your project looks very cool and I considered it earlier. Thanks for sharing :)
I excluded it because I was concerned that you might stop developing it and that would kill the project.
I want to focus on developing sensor-nodes and using the data in openHAB.
I really think some kind of self-healing mesh solution is the way to go, especially since I want to be able to expand freely and just drop in more nodes at will without disturbing the others.My current plan was to use MQTT-SN over openthread and then use the homie standard to get everything auto-discovered in openHAB.
But now when you say openthread is somewhat experimental I'm no longer sure.
To me openthread seemed quite well documented and I like that Nordic provide so many examples.
In your experience, is thread unstable?I want to go for the DIY approach mainly because.
- I want to be able to choose my own sensors and know that I get quality pcbs that last.
- Commercial multi-sensor nodes are generally fairly expensive. Making one custom doesn't pay off, but 30+ does.
- My end-goal is to make energy harvesting nodes, both indoor and outdoor, that once installed will be able to do their job until their components break.
The more I type in this response, while looking at your github and hackaday I feel like maybe I should give nrf52 Mesh a try.
Do you have any OTA working for your setup? I'm not looking for a fancy gui, just a python script on the border router or similar. -
@wassfila Your project looks very cool and I considered it earlier. Thanks for sharing :)
I excluded it because I was concerned that you might stop developing it and that would kill the project.
I want to focus on developing sensor-nodes and using the data in openHAB.
I really think some kind of self-healing mesh solution is the way to go, especially since I want to be able to expand freely and just drop in more nodes at will without disturbing the others.My current plan was to use MQTT-SN over openthread and then use the homie standard to get everything auto-discovered in openHAB.
But now when you say openthread is somewhat experimental I'm no longer sure.
To me openthread seemed quite well documented and I like that Nordic provide so many examples.
In your experience, is thread unstable?I want to go for the DIY approach mainly because.
- I want to be able to choose my own sensors and know that I get quality pcbs that last.
- Commercial multi-sensor nodes are generally fairly expensive. Making one custom doesn't pay off, but 30+ does.
- My end-goal is to make energy harvesting nodes, both indoor and outdoor, that once installed will be able to do their job until their components break.
The more I type in this response, while looking at your github and hackaday I feel like maybe I should give nrf52 Mesh a try.
Do you have any OTA working for your setup? I'm not looking for a fancy gui, just a python script on the border router or similar.@projectMarvin here's the next gen project that is actually a HW sensorTag but also mainly an nRF52840 firmware compatible with openthread and my previous gen simple mesh framework. The openthread is quite simple as you no longer have to worry about app layer when using directly json from the uC
https://www.homesmartmesh.com/docs/microcontrollers/nrf52/thread_sensortag/
