Basics for setting up LoRaHAT/GPS on Raspberry Pi

The values that you are looking for are all on the Overview Page for the Device that you registered under your Application. If you already have an application created, and a device created you have access to this information in your account. Also you can always just create another device under your previously made application. The fourth photo under step 1 ( shows you exactly what you’re looking for on your own account. If you’re using ABP activation you already know that you only need the Network Session Key, the App Session Key, and the Device Address.

While I agree that some of the documentation from Dragino is lacking, out of date, or in some cases just incorrect this set of instructions doesn’t seem to be that bad in comparison. But that might just be my previous experience in programming these devices and also going through Dragino’s other walkthroughs. This could be slightly clearer and probably better organized which I will agree with you on.

If you would like anymore help feel free to ask.


Thanks Geof

so what is the Device Address? It seems that setting up a device wants you to enter the device address, which makes sense. It then issues the Network Session Key and App session Key. I just haven’t found any documentation that tells you where to find the device Address. Is there some magic Linux code that reveals it? A command line statement? Do I just make one up, if so, what format, string characters, or is it in hex, how many bytes…




As you can see it looks quite different than the image you hyperlinked too, and asks for a Device ID and a Device EUI. There doesn’t appear to be any documentation on how you are supposed to fill these two fields in. Can I just make up any stream of 8 bytes? How then does this actually link to my real device, i.e. how will it recognize it as the same device?


The 30 second google was to say that there could be more info out there.

3 links were posted to you.
1st gives info about how to manipulate files (you did ask how to edit it - anyway, you’ve updated your post now, so clearly you now know how to do it)
2nd gives info about setting up a node (your main Q)
3rd gives info about how to register (Your q about the keys)

At the danger of you assuming you’re an idiot when people are trying to help you :slight_smile:
Have a look at this video from 8 mins on. It answers a lot of questions that you are probably going to ask - N.B. I can’t remember if it is LSB or MSB and video may be slightly out of date so be prepared to deal with some ambiguity without getting angry about it

The Device Address should be created for you as well. When I went to just register a device the only piece of information that I needed to put in was the Device ID which is different from the Device Address. After you register the device you’d then go into the settings and change the activation method to ABP. You should then see that the Device Address, Network Session Key, and App session key will be generated. After you save the new setting(s), you’ll be back at the Device Overview page where it will display that info for you.

Also a side note if you do want a random hexidecimal value generated you can use the following command in a terminal

openssl rand -hex 8

Where the 8 is length in bytes that want generated. This also requires you to have openssl installed but there are other ways to generate a random code as well.

Also sorry, I read through your last response quickly and I just wanted to make sure I was more clear. The image you show is just from the first page of the registration process. As I mentioned in my previous post you only really need to fill in the Device ID. Device EUI can be generated by TTN just by clicking on the button on the left side of the field to toggle it from User Generated to TTN Generated (See Picture 1). After you select an ID and if you choose to, let TTN create the Device EUI, hit the register button. This will bring you up to your Device Overview window (see picture 2). You are then going to want to click on the Settings button in the upper right, which will bring you to a new screen where you’ll see something like in my 3 picture. You will want to select ABP, as my picture is already from after I’ve done that. You should now see the options for a Device Address, and the two Keys are listed and they will be generated for you, so after selecting ABP all you have to do is hit save at the bottom of the window. This will bring you back to the Device Overview page which then shows you all three bits of information that you need for you code. Please see my 4th picture to verify that what you are seeing is what I do aside from the the keys and ID being different and this should look like the photo that I posted in my first response if all has gone well. Also note that by default the keys are hidden so you’ll need to click on <> button to switch between the hiding and showing the keys in their two formats. For your code you’re going to want the preformatted keys in curly braces {}.

(1) reg1

1 Like

So I just create a random 8 hex character Device ID and then everything else is created by TTN. I then copy the created values into the thethingsnetwork.send-v1.cpp file.

I note it says that DEV EUI and APP EUI are not used.

Thanks, will try tomorrow


The ID you pick doesn’t need to be in hexadecimal. It just needs to be lowercase and one word. Like in my example I gave my new devices the id/name testytest1. Hope your attempt today works out.

I have successfully modified both


config.h (from the LMIC library installed at /home/pi/lmic_pi-master/lmic) to use 915 frequency

I started the application

sudo ./thethingsnetwork-send-v1

and it reported

[894] (1525493216) Sat May  5 04:06:56 2018

2203: freq=902300000
Event EV_TXCOMPLETE, time: 2
[62334] (1525493236) Sat May  5 04:07:16 2018

402232: freq=902300000
Event EV_TXCOMPLETE, time: 22
[c3dd1] (1525493256) Sat May  5 04:07:36 2018

802261: freq=902300000
OhOh. Unknown interrupt flags for FSK

Note the frequency is definitely wrong for AU915. So after a bit of googling I saw the frequencies are stored in lorabase.h
So I changed the frequency plan to:

// Default frequency plan for US 915MHz
enum { US915_125kHz_UPFBASE = 916800000,
       US915_125kHz_UPFSTEP =    200000,
       US915_500kHz_UPFBASE = 917500000,
       US915_500kHz_UPFSTEP =   1600000,
       US915_500kHz_DNFBASE = 923300000,
       US915_500kHz_DNFSTEP =    600000

and recompiled and started the app, Now it reports:

[5224] (1525494942) Sat May  5 04:35:42 2018

21035: freq=916800000
OhOh. Unknown interrupt flags for FSK

and I get one message on my gateway. So it works once and once only. No amount of googling will tell me what the error radio.c :629 means

help please


Fixed it, I also had to change the minimum frequency on the next two lines:

enum { US915_FREQ_MIN = 916800000,
       US915_FREQ_MAX = 928000000 };

I figured out that radio.c:629 was simply that it had failed at line 629 in that module.


Thanks smbunn. I found this helpful. Any chance you have tried getting this to work with OTAA?

I agree with @smbunn that the documentation is really lacking. Which I personally find a bit disappointing, as the Dragino seems to be a really nice device. It took me days to setup the Dragino Lora Hat on my Raspberry and finally get it to work. Yes, you find endless amounts of documents on Google, but also lots of it is outdated or “not maintained anymore”. And you wonder which git repository to use.

Anyway, I am also looking for a nice example for the Raspberry as a node sending data via LoRaWAN to TTN. The Dragino Hat has a GPS sensor included, it would be cool to just send the current position every minute to TTN while driving through the country to be able to check the coverage of gateways. And I wouldn’t even mind another programming language like python or node.

1 Like

I am also getting erratic failures when running ‘./thethingsnetwork-send-v1’:



but more often


This is exactly what I use my Dragino hat for by using the on board GPS. is the program which works with the integration

I also recently discovered you can load GPS assistance data from the internet to the Quectel L80 chip to get a faster location lock with


Finally, I got this working with thethingsnetwork-send-v1. But actually, my task is to turn on an LED when a special word is received. How can I modify this to receive messages? Or is there a thethingsnetwork-receive-v1 ? And is there a way to work with Raspberry’s LEDs/GPIOs out of this C code?

2 posts were merged into an existing topic: Sending Customized Data

so what was fix and is it possible to.connect dragino lorawan hat to tnn directly without gateway

Hello Sir,
Can I use my Dragino LoraHAT v1.4 with Raspberry pi 3B+ as dual channel packet forwarded? If Yes, what should I mention in the server addresses?

As of now, my Gateway shows “Successfully contacted server” band the Thread is activated on the Pi.

But on the status of TTN, after registering the gateway, it shows “not connected”, what possibly could be the reason?

P.S. : When I tried it with single channel packet forwarder, the situation was same

@maxious -hello! just bringing this subject up again (COVID lockdown gives me time to re-invigorate this :slight_smile: ).I have the same set up as this (Dragino HAT on a Pi talking to a local gateway I also own). I can see outgoing traffic on the Pi, and the corresponding traffic being relayed by the gateway-but there is no GPS payload I can see. I can see the lat/long of the GW on the TTN console, timestamp etc so I know some data is going out.
Running cgps -s on the Pi shows GPS lock is enabled-and looking at the output on the Pi whilst running the ttn-mapper.out file, I can see the GPS data also. Running Wireshark on the my local router (which my gateway is connected to) shows no GPS data from the Dragino Pi.

Any idea or thoughts on why the ‘basic’ date is being fed into the TTN network-but not the GPS data from the Pi?



It is not permitted to connect such a device to TTN.

TTN only allows gateways based on proper multi-channel LoRaWAN concentrators.

Because TTN gateways are shared by all users, devices which falsely claim to be a LoRaWAN gateway while not actually have the capabilities of one cause connectivity problems for other users when the network adapts to the false impression that they are actual gateways.