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.
1 Like
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.
1 Like
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).
1 Like
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.)
Good thing that there already is a CS. One less thing to consider.
I was thinking I need only signed 16 bit integer, that would give a range of +/-32767, perhaps CBOR can handle positive and negative whole number at least?
Perhaps I need to deal with 32 bit sensordata at some point but I think CBOR will be able to deal with that?
Thx for your input Arjan.
But maybe we wandered a bit of topic now.
I have got answers to my questions regarding SDR and also in the process verified that my first node is working as long as I have a working GW to connect to.
Is it customary to close the ticket then?
How much can we wander off topic w/o beaking the rules?
To nitpick: as long as there is a gateway in range. In WiFi you connect to a gateway, in LoRaWAN you connect to the network using any gateway that is part of that network.
Not forwarding the data to TTN makes it hard to get to the data. TTN decrypts the LoRaWAN packet for you. Also you will still be using airtime so not forwarding the data doesn’t help keeping the air ‘free’. And if you don’t forward data other users will not be able to profit from additional TTN coverage.
Thx.
Let me rephrase: have a working GW to communicate through.