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’:
Sometimes
FAILURE lmic.c:1759
but more often
FAILURE radio.c:629
This is exactly what I use my Dragino hat for by using the on board GPS. lmic-rpi-lora-gps-hat/examples/ttn-mapper/main.c at master · maxious/lmic-rpi-lora-gps-hat · GitHub is the program which works with the http://ttnmapper.org 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 GitHub - gtjoseph/mt3339-utils
6 Likes
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?
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 router.eu.staging.thethings.network” 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 
).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?
cheers
cabs
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.
Has anyone tried to download the file found at https://github.com/dragino/lmic_pi/archive/master.zip mentioned in the tutorial used by @smbunn ? Because I’m following the same tuto, and trying to do download it, but while doing so I get the 404: Not Found error, it seems that it has been removed. Anyway, have someone found an alternative to get this file?
Thanks for the help.
I realise this may feel like a different issue, but it has huge potential for turning in to your other topic and we aren’t keen on double-posting. So please choose one of these threads and stick to it.
This topic would be the best.
Linked from the product page is the wiki page that gives lots and lots of information:
Okey, I understand, thank you for the remark.
In fact I found the same LMIC library source but not from the Wiki, I should have looked for it there before, my bad.
Anyway, if anyone is looking for the library, here is the link to download it: https://github.com/ernstdevreede/lmic_pi/archive/master.zip
Beware that is a truly ancient (5 years old) fork of LMiC missing many recent bugfices and evolutions, so it’s probably not going to work correctly, especially not with TTN v3.
Having a radio directly on a pi is an odd and obscure enough sort of platform its not clear that anyone is investing effort in getting a LoRaWan stack to really work correctly on that.
Generally speaking, the idea of a LoRaWan node fits uses cases that a pi does not fit, and vice versa. In the rare cases where LoRaWan would provide sufficient connectivity for a pi based system, and where a pi’s power draw can be supported, something using at AT-command based module containing not just the radio but an MCU to host a “canned” LoRaWan stack is probably going to be the easiest path forward.
Those who ended up at this hardware combination not out of specific need but because it seemed like a good starting point for learning may want to reconsider. It’s likely going to be an easier path to do something like connect that pi hat with jumper wires to a feather M0 rather than a pi, and then use a modern supported branch of LMiC such as MCCI’s.
So I finally installed my TTN Kickstarter Gateway and I’m running the thethingsnetwork-send-v1 example on my Rpi3 connected to the LoRa/GPS Dragingo HAT. I think it’s working properly because the shell shows me the output that should show when sending packets correctly (at least, based on what is shown in the tutorial as correct output). However, in the TTN console no traffic is registred, neither on the application side, neither on the gateway side.
I have verified that the APPEUI, DEVEUI, DEVKEY, ARTKEY and DEVADDR values I introduced are correct, just in case.
Here the kind of line is shown in the shell:
Event EV_TXCOMPLETE, time: 646
[c99c2b] (1616750947) Fri Mar 26 10:29:07 2021
Any idea of what is causing such problem?
1 Like
I don’t think that’s expected to work. And it’s all but certainly not compatible with TTN v3, so even if it sort of did momentarily, there’s no future in it beyond the next few months.
The basic problem here is that you’re trying to use an architecture (Pi + bare radio) that doesn’t make a lot of sense, and as a result doesn’t seem to be receiving ongoing support from anyone.
Okey, thank you very much for that answer, I hope this is useful for other users while selecting hardware to work with.
Do you think you could give me more specific information about why this combination does not make a lot of sense? I would like to give punctual reasons in my report, for future LoRaWAN development projects at my University.
Thank in advance for your precious help and feedback.
It’s most likely not working due to the age of the software you are using.
But additionally, LoRaWAN is timing critical and the Pi could be off doing something else when the radio chip needs some attention. It depends on what you have running on your Pi.
Whereas a serial comms module that has an MCU & radio on board can get on with the job of doing LoRaWAN whilst the Pi communicates with it as and when it can.
LoRaWAN requires hard realtime scheduling capacities for this combination of hardware because of the timing requirements. Linux does not provide this on an RPi. (By default Linux has no realtime capabilities. There are patches for some Linux distributions to add this)
LoRaWAN on an RPi (or desktop/server/whatever running a non realtime OS) is easy to implement using a module like the RN2483/RN2903 which takes care of the critical timing and uses non critical timing critical uart communication to interface to other hardware. There are other modules with similar functionality.
Thank you so much @kersing and @descartes for the specific information about it.
Just an aditional question, linked with what you said @kersing. If RPi is not real-time capable using Linux, and therefore not LoRaWAN compliant, then how there was people capable to create a LoRaWAN module with this shield and the RPi? I’m not saying I don’t believe you, it’s merely curiosity.