good spot, thanks. I have some additions/changes to do
Hi,
I also have an update. A few days ago I got my TTN gateway. It’s a SX1302 LoRaWAN Gateway HAT. Using this Balena enabled basic station project, I got my gateway up and running.
Turns out, my node was able to join pretty much directly the network. This part of the configuration was actually already working and I was just too far away from my nearest gateway.
I had some issues sending data since I got the error "TypeError: can only concatenate list (not “) to list”. I changed the code a bit and then it worked (@bnnorman, I guess you are using a different version of Pyton!? Mine is 3.9.7).
Now that I can successfully join the network and send data, I’ll try to clean up the code and make it a Balena project. I’ll update this thread once I have published the code.
@bnnorman, thanks again for your code. Awesome work!
–Hardy
Thanks - I am now running on RasPi Bullseye so yeah, Python 3.9.2. I know that error well. I have recently uploaded new versions with more logging but more importantly added code to ACK any CONF_DATA_DOWN (accidentally) sent. Without it the server continues to retry sending the message. I’m very pleased you got yours working ok and keen to see the balena version.
1 Like
hi @bnnorman
fantastic to find your library as I have the same pi hat as you and was struggling to get it working. However I have installed and configured as per instructions but when I start test.py I get the following error code. Could you provide any pointers to the issue as my python coding knowledge is limited (but growing I hope) and I have looked through the referenced libaries but I nothing jumps out at me as an issue
pi@raspberrypi:~/dragino-1 $ ./test.py
Mode ← SLEEP
Mode ← FSK_STDBY
Mode ← SLEEP
Mode ← FSK_STDBY
Mode ← SLEEP
Setting up GPS
GPSDSocket.connect exception is–> [Errno 111] Connection refused
AGPS3 connection to a gpsd at ‘127.0.0.1’ on port ‘2947’ failed
AGPS3 send command fail with [Errno 32] Broken pipe
Traceback (most recent call last):
File “/home/pi/dragino-1/./test.py”, line 21, in
D.join()
File “/home/pi/dragino-1/dragino/dragino.py”, line 479, in join
self.configureRadio(radioSettings.JOIN)
File “/home/pi/dragino-1/dragino/dragino.py”, line 162, in configureRadio
freq,sf,bw=self.MAC.getJoinSettings()
File “/home/pi/dragino-1/dragino/MAChandler.py”, line 223, in getJoinSettings
sf,bw=self.config[self.frequency_plan][DATA_RATES][self.cache[DATA_RATE]]
KeyError: ‘data_rate’
This, I think, is the source of the problem. :-
Setting up GPS
GPSDSocket.connect exception is–> [Errno 111] Connection refused
AGPS3 connection to a gpsd at ‘127.0.0.1’ on port ‘2947’ failed
It looks like the gpsd socket is ‘stale’ or in use. Did you check gpsd was working using something like cgps?
I would stop gpsd with
sudo systemctl stop gpsd
You will get a message about the socket. I would then delete the socket (/var/run/gpsd.sock) and start gpsd again. Check gpsd is working with cgps before running your code.
Rest assured, I am using the dragino code daily developing code for the local council SpeedSign(s).
Good luck
Thanks for the direction. However I still have the problem. I am not sure if the cgps response is showing a gps issue though.
┌───────────────────────────────────────────┐┌──────────────────Seen 0/Used 0┐
│ Time: n/a (0) ││GNSS PRN Elev Azim SNR Use│
│ Latitude: n/a ││ │
│ Longitude: n/a ││ │
│ Alt (HAE, MSL): n/a, n/a ││ │
│ Speed: n/a ││ │
│ Track (true, var): n/a deg ││ │
│ Climb: n/a ││ │
│ Status: NO FIX (0 secs) ││ │
│ Long Err (XDOP, EPX): n/a , n/a ││ │
│ Lat Err (YDOP, EPY): n/a , n/a ││ │
│ Alt Err (VDOP, EPV): n/a , n/a ││ │
│ 2D Err (HDOP, CEP): n/a , n/a ││ │
│ 3D Err (PDOP, SEP): n/a , n/a ││ │
│ Time Err (TDOP): n/a ││ │
│ Geo Err (GDOP): n/a ││ │
│ ECEF X, VX: n/a n/a ││ │
│ ECEF Y, VY: n/a n/a ││ │
│ ECEF Z, VZ: n/a n/a ││ │
│ Speed Err (EPS): n/a ││ │
│ Track Err (EPD): n/a ││ │
│ Time offset: n/a ││ │
│ Grid Square: n/a ││ │
└───────────────────────────────────────────┘└─────────────────────────────────┘
pi@raspberrypi:~ $ cgps -s
cgps: caught signal 2
cgps: caught signal 2
pi@raspberrypi:~ $ cd dragino-1
pi@raspberrypi:~/dragino-1 $ ./test.py
Mode ← SLEEP
Mode ← FSK_STDBY
Mode ← SLEEP
Mode ← FSK_STDBY
Mode ← SLEEP
Setting up GPS
Traceback (most recent call last):
File “/home/pi/dragino-1/./test.py”, line 21, in
D.join()
File “/home/pi/dragino-1/dragino/dragino.py”, line 479, in join
self.configureRadio(radioSettings.JOIN)
File “/home/pi/dragino-1/dragino/dragino.py”, line 162, in configureRadio
freq,sf,bw=self.MAC.getJoinSettings()
File “/home/pi/dragino-1/dragino/MAChandler.py”, line 223, in getJoinSettings
sf,bw=self.config[self.frequency_plan][DATA_RATES][self.cache[DATA_RATE]]
KeyError: ‘data_rate’
I am not sure what I am doing wrong.
Firstly GPSD:
This looks like GPSD hasn’t found the serial port the GPS is working on. It should be /dev/ttyAMA0 (zero on the end) - well, that’s what my Pi has connected to. I had a similar problem and had to edit /etc/default/gpsd and make sure it had DEVICES="/dev/ttyAMA0".
Restart the GPSD and run cgps again. If that fails, stop gpsd then check /dev/ttyAMA0 exists and that it is owned by root with group dialout
I think I’ll add some notes to the readme because I had the same problems. And so had others on the www.
Regarding KeyError: ‘data_rate’
This tells me that the data_rate entry is missing from the cache.json. I think I saw that a while back and fixed it.
Please look at the end of dragino/Strings.py - you should find this:-
# these settings are cached
# MAC settings which can be changed by a downlink msg containing MAC commands
MAC_SETTINGS=[
FCNTUP,FCNTDN,RX1_DELAY,RX2_DELAY,RX1_DR, RX2_DR,RX1_FREQ_FIXED,
RX1_FREQUENCY,RX2_FREQUENCY,DUTY_CYCLE,LORA_FREQS,DATA_RATE
]
Check that DATA_RATE is present at the end. This list is used to populate the cache.json with default values. If you have an earlier version of Strings.py and have to change it then delete cache.json to allow it to be re-created.
Good luck
Thanks.
GPS - looks fixed
Data rate - i had the same settings in string.py as you oulined. I deleted cache.json and things moved forward.
The error now is the following:
pi@raspberrypi:~/dragino-1 $ ./test.py
Mode ← SLEEP
Mode ← FSK_STDBY
Mode ← SLEEP
Mode ← FSK_STDBY
Mode ← SLEEP
Setting up GPS
Waiting for JOIN ACCEPT
Joined
Mode ← RXCONT
Sent Hello World message
Traceback (most recent call last):
File “/home/pi/dragino-1/./test.py”, line 32, in
while D.transmitting():
TypeError: ‘bool’ object is not callable
while D.transmitting(): ← remove the brackets : I’ll check the repo
Yup, my BAD - corrected on github now.
1 Like
Just a reminder. In UK we have a 1% duty cycle limit so if your transmission takes 0.01 seconds you have to wait a further 0.9 seconds before you transmit again. (Legal)
On TTN you have a max of 30s per day transmit time.
2 Likes
Heya Brian. Thanks for all your really great work so far getting the TTNv3 updates done.
I have been for some time [you might recall some of my attempts previously OTAA March 2021 attempts ] been trying to get this setup to work under AU915.
Where we have a semi-unique situation where as the TX and RX frequencies are different.
So I am at it again, I have forked your excellent work and tried to make the AU915 changes to mine, so that once successful I could send you a pull request.
Even with your current RX2 being a fixed freq and my modifications to make RX1 also fixed I can still not for the life of me see any RX downlink messages.
TTN is seeing the OTAA request fro the RAK7246 gateway-
TTN Application is also seeing the request -
And from what I can tell, the RX is being processed - when I see the reports on the gateway the counter for the TX increments.
So I am seeking your guidance please as to what else I can try to include in the code for the AU915 to be functional.
Always remember that the dragino.toml is an initial starting point and values can be modified by MAC commands and current values are cached in cache.json as per LoRaWAN spec (end device must store xyz).
Here in UK the RX1 frequency is the same as the transmit frequency - which is a random choice from the lora_freqs in dragino.toml - but the RX2 is fixed.
If you have joined TTN the evidence of the current state will be in cache.json. If the node is powered off cache.json is restored and a new join is not required.
Ok, if you joined TTN then there was a downlink from TTN to provide you with devaddr and session keys. Those will be in cache.json - further evidence of downlinks.
If you power up your node and it ALWAYS re-joins it indicates there is no devaddr in cache.json and that would indicate no downlink (JOIN_ACCEPT) was received.
Hope that helps
Where next? I assume you are using logging. if you have left the logging level at logging.DEBUG then you will have a heck of a lot of information in it -possibly too much to email to me. If you can place it on a google drive and message the link to me I’ll take a look.
Regards
Brian
Thanks for the prompt reply. Yeah I am aware you are in the position to have the shared RX / TX frequencies.
I have looked extensively at the cache.json file and I do not get any real sense for any of the attempts and adjustments that I have ever managed to complete the join for OTAA. I do not believe the request to change to the RX1 freq or even the RX2 freq is happening. I do have some logs, happy to share as much as you want. Ive sent a msg with contact details. Hope you get that and I can share some logs or even ssh access to have a play if it comes to that 
I really really am going to make me an RFM95 hat to take this for a spin.
If only so I can revel in the strange sentences in the code that start with # - don’t see many of these now-a-days!
But mostly so I can dig in to the details of the Russian dolls that is the structure of the LoRaWAN packet - using LoRaWAN MAC is one thing, knowing the MAC is another and I find reading different implementations helps such dense material sink in.
On your next update of the repro, couple of notes for you to consider some alterations to the readme:
TTN Fair use policy limits you to 10 downlinks per 24 hour period.
The consensus on the forum is that a downlink per fortnight is a good design, 10 a day per device in an area of deployment could actually result in a substantial number of lost uplinks as the gateway will be deaf to all & any uplinks whilst transmitting the downlink. The LinkCheck will also trigger a gateway transmission but I can see that it’s not automagically triggered in the firmware (regional parameters set a suggested count of uplinks before doing a LinkCheck but that’s deep in to the details).
I’ll figure out some weasel words for consideration later.
The TTN servers only send downlinks after an uplink - I assume that is so TTN doesn’t send messages to someone who isn’t listening.
It’s because that’s the LoRaWAN spec for Class A - when device sends an uplink it then listens on Rx1 & Rx2 windows for any incoming messages. It’s not unique to TTN.
As for the GPS issues, a perpetual issue with opening & closing ports & the like on the Pi, maybe it could be turned off by default so that people can get over the challenge of LoRaWAN before making things more complicated?
1 Like
Not sure it’s always required to open and close ports.
Gpsd does operate locally as a port but some of the python implementations for the gps read the nmea data directly from the serial stream and process the changes/data to calculate the long/lat/altitude and time information.
To add some more detail there are 8 uplink channels from the node to Gateway in FSB2, ie channels 8, 9, 10 … 14 and 15. If the network responds and the Gateway transmits it is on one of 8 downlink channels. The first downlink is selected if the uplink was on channel 8, the second downlink channel if the uplink was on channel 9 and so on.
The downlink channels are 923.3, 923.9, 924.5 and so on.
My post back 12 months ago was a little vague on this exact detail as it wasn’t the purpose of that post.
1 Like
GPS point noted . Will do that in next update
Tony, This sounds like my code needs changing to meet FSB2. Currently it expects RX1 freq to be the same frequency that was transmitted on - which I believe is true in UK (It is working for me after all).