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?
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.
I’d not use the phrase “LoRaWAN compliant” as we use that to refer to devices that aren’t implementing the protocol correctly. This is about an Operating Systems ability to respond quickly enough. If you cut down the OS enough on a Pi it should work reasonably well but, and I’m not sure this point is getting through, the code base you are using is very very old.
There has been a time when only transmitting data was sufficient to have it received on a LoRaWAN network. For transmission only the timeline requirements are not as strict.
However to be LoRaWAN compliant a system must be able to receive data as well and that is where any generic Linux system will fail. And current networks require compliant hardware/software.
LoRaWan is really designed for battery powered nodes which can do useful work while only infrequently moving truly tiny amounts of data.
A pi is a power hungry system typically chosen for tasks than need to move larger, more traditional amounts of data.
It’s not that there can never be a pi-based node that fits within the constraints of LoRaWan, it’s just that such is very unusual.
Just about all existing full LoRaWan codebases are written for the idea of battery power. As such, they put the radio to sleep except for the exact, tight windows of time when it might need to receive. This creates a tight timing requirement that’s hard to achieve with a pi.
If one were implementing LoRaWan based on the idea of having mains power (as practically forced by the power draw of the pi), then one could simply operate the receiver for much wider periods of time around any possible message. For example, after the end of a transmission it could wait a half second, then turn on the receiver. If by 1.5 seconds after no downlink packet has started, then switch to the frequency and spreading factor of the second receive window. If by 2.5 seconds that hasn’t started either, give up and turn off the radio. For join accepts and for TTN V3 the window occur at 5 and 6 seconds rather than 1 and 2, but the idea is the same.
It’s do-able, but when most of the people who could do it think using a pi in a node is a bad idea, it’s probably not going to happen unless there’s an unusual need that makes it sensible.
Thanks to the three of you. Those informations have given me a better understanding of this.
However, this example happens to still work. The module was just to far away from the gateway, because of the short reach of the shield’s antenna. Once the module near to the gateway, it sends the packets and they can be visualized in the TTN console (the app and the gateway traffic) Now I’m trying to add a sensor and send data through this module to the gateway.
Nevertheless, I understand why this isn’t a good combination of hardware for LoRaWAN protocole, so I’d discourage others to work with this. I had to work with what I had, otherwise I would choose other materials.
Does the downlink path work?
Part of the point is that having that is no longer optional, but becoming required: talking without hearing responses directed at you is “impolite” and wastes network airtime sending administrative information over and over if you don’t acknowledge receipt of it.
How could I verify such thing? Let me know if you can help, and therefore I could share that info.
Hi there.
I am newbie in this technology, and I am having difficulties setting up my demo LoraWAN lighting.
My gateway is Shuncom SZ11LR GW2. I have also two demo lamp controller, with given ABP and DEVEUI. Gateway is connected with sim card, and I have connection via web app, but my web app can’t see controller online?
Hope that you can at least give me direction where to start
Cheers