Hi,
Is it possible to use a SW defined radio tuned to 868 MHz to detect LoRa Node radio transmissions?
I have a LoRa node that I haven’t got to work and I want to check if the radio transmitter works as expected.
I use an antenna tuned to 868 MHz for the SDR and an external antenna for the Lora node, and they are a few decimeters apart.
brdgs
Jerker
Yes you can, cheap usb SDR devices work well to listen, you can see the Lorawan chirp’s - do a search for SDR on this forum for more info
Thx jezd, much appreciated!
I’d encourage anyone new to lorawan to grab a cheap SDR, its a lightbulb moment when you see each nodes chirp, see the device hop frequencies whilst at the same time monitor the TTN console and see the live data confirming the transmission details - even now I love to do it.
Luckilly I got one 
I configured my Lora Node (RAK811 based) to not skip the ACK.
And I also setup the SDR to display 867.0 - 868.7 MHz.
I restarted the Lora Node at 22:47:25 UTC.
Is it possible that the transmission can be seen at just after 22:47:32 UTC and between 868,1 and 868,2 MHz?
No sure what SDR software that is, I have used SDR Console a bit - you need to play around with the visuals but you can get some very good scrolling timelines of lorawan chirps as they move around
I used GQRX, which is based on GNU Radio to record the waterfall image. And I’m using a RPi4 to run the SDR.
I also looked at the RX2 DownLink, DL, from the gateway at 868.525 MHz and there is nothing there what I can see, no modulation at all, but there is a carrier way.
I read that the DL must be configured manually to use SF9BW125.
In the process of figuring that out.
Edit: I assume that SF9 stands for Spread Factor 9 and BW125 is Bandwidth 125 KHz?
For ABP only. For OTAA you should use SF12BW125.
no modulation at all, but there is a carrier way.
There is usually a small spike at the tuned frequency, kinda looks like a CW. In you move the freq off center is it still there? Some UIs have an option to compensate.
I took a snap shoot of the downlink:
It looks flat but if is just a short spike and I missed it?
A LoRa signal will be at least 125 KHz wide.
I thougth I stay with ABP in the beginning just to try and get my first node up and running.
I read that the Up Link channels should all be set to either SF7 or SF12 except for channel 9 that should be set to FSK?
Thx for your replies kersing and jasonreiss.
As it stands right now I think I have two possible reasons for why my setup doesn’t
work:
1/ Bad configuration of spread factor and band width for each channel.
As I’m using the RAK811 I thought I check in the RAKwireless forum for how to configure this properly (but of course if you know this
2/ I do not have line of sight to any of the Gateways covering the area where I live.
I will get mobile and move my little testbed to a spot where I get LOS to the respective GW’s antenna.
If you have any other suggestion for things I can try it would be great.
Edit: @jasonreiss I just use the SDR to “see” what is going on. But given the scale in the particular snapshoot I guess that 125KHz would look very narrow.
Line of sight isn’t always required. It all depends on things like distance, antennas use, what kind of obstacles are between transmitter and receiver, RF noise floor in the area…
If you aren’t near the gateway sending a return packet chances are small you’ll be able to see it using SDR. Lora modulation is made to be detectable below the noise floor, in a visual inspection of the spectrum it will be hard to detect.
Take into account you can’t always predict which gateway will be chosen to send downlinks in an area where multiple gateways receive your nodes transmissions. Usually the closest gateway will have the best signal conditions and will be chosen, but airtime and gateway use are factors as well.
Using a generic SDR dongle and Windows software I haven’t been able to scan the entire band used by EU868 with sufficient speed to be able to capture all transmissions of my test node (at least I wasn’t able to recognize them).
Thx, your answer.
Yes, antennas and radios and everything else thats affect the transmission are a whole sciense on its own.
Of course, you’re right, the signal is much to weak in the DL to be seen in the waterfall.
As it seems, see below, I don’t have any Gateway cloes enough for me to use.
Tweaking the SDR a project on its own. I am satisfied with that I got some hints that my node doesn’t have a broken radio:
The red line in the spectrum is the node transmitting.
Today I went on an excursion to some different Gateways and finally at the second Gateway:
So I have to get me a Gateway!
Thx, again all of you who have commented in this thread!
See also https://revspace.nl/DecodingLora And surely my SDR tests easily showed chirps like that, but maybe I was always using SF12 then, to have some time to see things.
Aside: don’t send text, even though that makes your payload extra long for testing. 
Thx for the link Arjan!
No, I will stop that now when I have finalised the first test to prove that the node’s HW is functioning.
I’m deliberating wether to send the data in JSON format and then compact with CBOR or if I should just send bytes with data in binary format and then a checksum in the end.
I guess it depends if I am going to integrate with some cloud service to access the data and what fits best the cloud service I choose, and if I do that at all.
I’m thinking that I can stop the data from being transmitted from the GW to TTN while I developing the sensor nodes and data formats.
And also trim down TX power so the radio will only cover the lab.
So not to disturb the TTN.
The nearest GW seems not to be i operation, altough it is indicated as operational on the map. The second closest that is like 6 km from me, had a reach of some kilometer.
The goal is to fulfill the requirments with a bit of a margin.
I feel CBOR is really unpredicatable, hence a bad choice for LoRaWAN:
A checksum (the MIC) is already included in each LoRaWAN message. If that fails, your application won’t even see the uplink. (Even more: TTN wouldn’t even be able to tell it’s your uplink.)