Any RFM95 user reports?
-
Well, let's not get overhyped here, there's the story of the guy reaching 160km with an RFM69, not RFM95, but to talk about hundreds of km away with line-of-sight is almost impossible due to geographical restraints. And if we were to talk about ionosphere propagation, I'm sure it may work under ideal conditions, but propagation is very iffy, relies a great deal on the solar conditions and is totally unreliable throughout the 24h cycle. So except from a range success story, there's really nothing to it.
The real thing is the urban propagation with vanilla RFM95/RFM96 along with omnidirectional antennas if a city-wide mesh would be deployed. Yagi's will only help with point-to-point directional setups and perhaps a magnetic loop could prove an awesome option but they require extremely fine tuning due to their very narrow bandwidth, sometimes in the range of +/- 10kHz. I'm considering ordering two custom built magloops but the issue at hand is that for them time being I don't have a VSWR meter for UHF bands. And with entry level UHF antenna analyzer models starting at about $700, it seems a bit too much for current hobby level requirements. -
Every standard has its own application. I have not heard about rf69 reaching 160km (can only imagine what antennas he used) transmission, but I know that loraWAN is covering cities like Amsterdam. The latter has more use to what I do.
Additionally, Lora is good for protects like HAB (High Altitude Ballooning) - and this is a distance of a few km with no special antennas! Take a look here:
-
Yes, I am very much aware of that, it's just that I wasn't expecting such a long TX time. And my conclusion is that they have no use with battery powered sensors, unless maybe BW500CR45SF128 is used, but then it will defeat the "LoRa" purpose.
-
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".
-
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".
@mihai.aldea I'm waiting for the delivery of loraWAN GW. So far I have an ESP Single Channel GW, but it has got limitations. I will try to measure time / consumption a node is transferring packets.
There is a battery application for it. Like a remote flood warning device. Or gas sampling
-
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. -
The duty cycle limits combined with long send times makes it very hard to use LoRa for home automation. Having to wait 20-200 seconds (depending on frequency band) between messages is a severe limitation.
There are definitely some use cases where LoRa is still applicable, but I think the duty cycle is a big reason to why there are no gateways between LoRa and home automation systems.
A good thread on the limitations https://www.thethingsnetwork.org/forum/t/limitations-data-rate-packet-size-30-seconds-uplink-and-10-messages-downlink-per-day-fair-access-policy/1300
An airtime calculator is available at https://docs.google.com/spreadsheets/d/1voGAtQAjC1qBmaVuP1ApNKs1ekgUjavHuVQIXyYSvNc/edit?usp=sharing
-
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 don't see any good point is directly interfacing a home automation system with a LoRaWAN device: if you need to perform data collection or some remote control, the controller could take care of that without having bridges rfm69<->nrf24. As mentioned before, there is a community for Lora public GW https://www.thethingsnetwork.org/community that people could use maybe together with mqtt.
-
Anything concerning loraWAN is expensive and one has to develop it. This is probably good for developers aiming for a final product, for example, air sampling at the remote site without any internet access. However, even in this case 4G network can be used. If such site does not have internet / electricity, this is where loraWAN comes very handy
-
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.
-
@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
@alexsh1 said in Any RFM95 user reports?:
@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.
-
@alexsh1 said in Any RFM95 user reports?:
@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.
When I said Lora I'm referring to LoraWAN, which is not the same thing.
-
2G requires more power to transmit than LoraWAN
-
LoRaWAN is optimized for uplink (from the node to a server). For downlink there is 8 times less bandwidth available. This means it is designed to received info from sensors
-
A gateway can receive on 8 channels at the same time
All that said, the ideal use case for LoRaWAN is:
- Simple sensors that need to transmit infrequently
- Missing 5-85% of data at times is okay
- Little ability to control this device
- No ability to update device firmware over-the-air
- Deployed in the dozens to hundreds
Some Automatic Meter Reading is a great example of a good use case for LoRaWAN. For meters that update the reading, say once per hour, it does not matter if some readings are missed, as long as some make it through.
Finally, places like Amsterdam were completely covered by LoraWAN in just two weeks. There is no chance for the city of this size to be covered by 2G in such a short time.
-
