Could you describe the advantages of using a rfm96 instead of rfm69, when not using LoRa mode?
Then I don't understand your statement.
So what you're telling me is that I'm not using the RFM96 in LoRa mode? I now seem really dumb, but in all fairness, after a lot of digging, I only found these modem configrations available:
* | CONFIG | BW | CR | SF | Comment * |---------------------------|-------|-----|------|----------------------------- * | RFM95_BW125CR45SF128 | 125 | 4/5 | 128 | Default, medium range * | RFM95_BW500CR45SF128 | 500 | 4/5 | 128 | Fast, short range * | RFM95_BW31_25CR48SF512 | 31.25 | 4/8 | 512 | Slow, long range * | RFM95_BW125CR48SF4096 | 125 | 4/8 | 4096 | Slow, long range
I chose RFM95_BW31_25CR48SF512 after some extensive trial and error range tests.
If I'm not currently using LoRa, how can I actually switch to that?
I couldn't not notice the large overhead associated with the MySensors transport protocol. You see, as discussed before, the issue at hand is not using a coin cell for 3 years instead of 2, but it's about the RFM69 and RFM95/RFM96 modules which are capable of using really low bitrates or special modulations.
Eg. I had a 14250 battery that drained within a month with an RFM96 sending data every 5 minutes using RFM95_BW31_25CR48SF512 which was sending only one sensor value. This happened because unlike RF24 which can have a total awake cycle of 100-150ms, the RFM96 had an awake cycle of about 5000ms. It took it 5 seconds to send the single sensor value.
RFM69 is another case in which a lower bitrate -> longer range -> longer TX time. I went as low as 300bps only to see that a single packet is sent in about 1500ms. That's way too much for a battery powered node.
Some of us need long range sensors and we don't want a constant power messy setup, or the complex circuitry and increased cost associated with adding "UPS" like features to our boards.
My RFM96 node now sends a ping every 3h and the RFM96 nodes run in 9600bps so that I wouldn't have to replace those 14250 batteries monthly and actually use them for the intended life-cycle, that's more than 3 years.
The alternative is to give up MySensors altogether and use third party libraries, concatenate the messages as raw data then parse them on the remote gateway based on predefined rule set. But although this gets the job done, it's not a really good idea to mix various libraries and properly maintain the whole system in the long run.
Well, I'm glad that the posting got some traction and some very interesting ideas were shared. While the bits and pieces of information were all out there, your argument helped drawing some conclusions.
So at the end of the day, it really leaves us with a couple of applicable scenarios when taking public LoRaWAN meshes into consideration. Smart meters and perhaps security devices which only have to send a daily keepalive ping and if ever needed, tripped sensor alerts, provided that they would be immune to jammers. I'm not taking into consideration the close range stations where a daily 30s air time would suffice, because this defeats the purpose of LongRange. Other than that I see no real use of LoRaWAN, but feel free to share your ideas, perhaps I'm missing something.
And after apparently trashing both LoRa and LoRaWAN I will only say that I can barely wait to get myself a LoRaWAN gateway and set it up in my area
@gohan in a highly populated area Lora is better from my perspective. However, as already mentioned the cost is high (GW - €300, node - €55+ etc). Plus one is expected to develop
And why is that? Dense population = likely more users = frequent gw congestions.
Indeed, I see LoRa as an option for either experimenting, or as a solid alternative where there's no other option. Because at the end of the day, those who'll require a reliable transport layer will not resort to the open bands but use 2G/3G modems or even radio modems or satellite uplinks. While the LoRaWAN users will have to cope with the drastic FAP limitations, or use point-to-point systems for setups that allows no alternative, like I do.
I see, but the end nodes shouldn't necessary route their data in an a synchronous manner. The gateway can buffer the data and commit the reading asynchronously over to the LoRaWAN network once every 5 minutes. Sensor data downsampling could be performed by the gateway in order to shorten the TX window to the utmost minimum. Downsampling and/or a heavy compression algorithm could help.
On the other hand, I do realize that all these feature could lead to a fairly complex solution that's going to be so complicated to use that's never gonna get any traction.
I'm planning to get myself one of those and set it up in my neighborhood, however at least for the time being I find it a bit useless since I don't know of any Home <-> LoRaWAN gateway that would effectively push the end nodes data over the LoRa network and up to a hub. Moreover, if that gateway would exist, then there should be some considerations regarding the way the LoRaWAN gateway handles packets, eg. authentication, message signing, encryption, ACL or rate limiting. This would enforce a private communication channel, free of any abuser that would hammer down the gateway by sending readings every 5 sec. from a set of couple of dozen sensors, congesting the gateway.
It may be that some manufactures such as Cisco have already considered these but I'm not aware of that, and testing their solutions is rather cost prohibitive.
It would though be very nice to have RFM9x <-> RFM69 or RFM9x <-> RF24 home gateway. The end nodes would use an appropriate protocol for the required range and cost (RFM69 or RF24) to send data to the gateway, and then the gateway would forward the packets over the LoRaWAN network to "the cloud".
Looks like your connection to MySensors Forum was lost, please wait while we try to reconnect.