Hey,
Have an SDR (Software defined radio) (Nooelec R820T SDR USB+) and my utilities provider is using Lora to send data.
I ran a capture overnight using rtl_433 on 868.1MHz to see if I can capture it and it looks like I can.
Not sure what you hope to achieve, but if the utility is using LoRaWAN decoding the signal won’t provide you with useful data because LoRaWAN data is encrypted with AES.
a) Meter manufacturer told me that they implemented Lora ‘off label’ and did not encrypting the data. So I should actually get the raw data. I just need to turn that signal to HEX and from there I can figure things out.
b) I would be able to use same receiver for both Lora wMbus and other devices. They run on same 868 Mhz band, so if I pipe the data to both decoders the have one that manages to parse it forwards it to MQTT and in turn home assistant.
c) I would be able to create a Lora gateway and register it with TTN or run ChirpStack either would be cool. Also, if the representative misspoke and the packet is encrypted I could add a gateway that would pass it the things network and then use the end device keys to get the data. (The closest gateway is ~3 km away and Lora devices are underground, so range may be impacted )
a) this forum is for the TTN lorawan network. So Lora with different standards is not really in scope. Google might have an answer for for challenge as over the past years several people mentioned attempts to use SDR for Lora demodulation. I can’t say I recall reading a success story.
b) a LoRaWAN gateway must be able to transmit too very strict timings as well as receive at 8 frequencies with multiple datarates at the same time. It is challenging for an FPGA (they run seriously hot while processing) combined with two tuners, I am unsure how successful an SDR solution can be and how much power you would be wasting (a regular gateway run at 30-40 watt)
a) I know it is TTN forum I was asking if you have tools available for TTN community I do not expect them to work but it would be a good start. Unless everything is closed source.
b) Wait… I was under impression that LoraWAN gateways are just receivers that then forward signals over the Internet? Do LoraWan gateways form some sort of mesh network over radio?
The tools we have for TTN use hardware to decode the RF signals. The firmware for the gateways is very specific for the Semtech chipsets. (They own the patent for Lora, anything you implement might infringe on their intellectual property)
LoRaWAN gateways both receive and transmit, they receive uplinks and forward them to the network server and get downlinks from the network server and transmit them at the time specified. Not every uplink gets a downlink, but some do. And for class B and C nodes downlinks can happen at other times as well.
Dam patents… that explains why there are so few developed tools for general/multi purpose radio receivers beyond research and why all available hardware so expensive.
Even if I would be infringing I think I am fine. I was not planning to develop a commercial product, so I do not think I have to worry about Semtech suing me.
Also any HW decoding can be simulated as long as signal is clear and since the so little data infancies should not be significant.
My hardware does not even have any capacity to transmit any radio signals so I probably can not simulate meeting some gateway spec.
I manage to capture something in the Lora signal range with research tools (GNU radio + gr-lora) with some calibration it should be possible to transmit decoded signals over UDP but either need to find a consumer for it or rethink my entire approach which is probably more likely… meter has M-Bus cable that I may attach some kind wireless transmitter.
Thanks for fast context.
As Jac says all out of scope for the forum…but frankly is data unenctrypted and not LoRaWAN why bother with the SDR and associated complications and limitations…just use a LoRa device ($3-5) to capture the symbols/packets and go from there all then simply in digital domain and a case of reverse enginering the meter manufacturers chosen payload/protocol structure…no worries about Semtech patents or any others at that point I suspect 
As not in scope closing the thread…
