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.
Yes, you’re right!
Thx.
I’ve played around with this using an RTL-SDR USB stick which is very cheap. This picture shows the best resolution I’ve been able to get, that’s with SF12, any faster and the waterfall plot is too fast to make out anything much. I’m not sure if it would be better with a better SDR device (but they start to get expensive) or a more powerful PC that can produce the live plot faster or if I just don’t know enough about GNU Radio since this is the first and only time I’ve tried anything with it.
1 Like
I’d say it is good enough to be able to see when something is being sent from the node. An SDR cannot replace a spectrum analyzer to properly measure the signal.
But as such it helped me to see that my Lora node actually sent something on the expected channels and was not broken.
Anyway I bought a proper 8 channel gateway and have succeded to get som packets through.