computenodes / dragino Goto Github PK

Hello,

I'm having a problem with the test.py. I'm using pi 3 B+ and dragino lora hat v1.4 with raspbian.
Here is what it tells me:

pi@raspi:~/dragino-master $ ./test.py
Mode <- SLEEP
Mode <- FSK_STDBY
Mode <- SLEEP
Mode <- FSK_STDBY
Mode <- SLEEP
2021-04-17 11:48:24,532 - Dragino - 58 - DEBUG - Nonce = [133, 179]
2021-04-17 11:48:24,534 - DraginoConfig - 357 - CRITICAL - Missing required field 'gps_baud_rate'
Traceback (most recent call last):
File "./test.py", line 13, in
D = Dragino("dragino.ini", logging_level=logging.DEBUG)
File "/home/pi/dragino-master/dragino/dragino.py", line 67, in init
self.config = DraginoConfig(config_filename, logging_level)
File "/home/pi/dragino-master/dragino/dragino.py", line 358, in init
raise DraginoError(err) from None
dragino.dragino.DraginoError: 'gps_baud_rate'

I haven't modified dragino.ini.default except to put my TTN keys for ABP. But it seems to have a problem at the first line. (second if you don't count "#GPS configuration".

Thanks
Marius

Transmitting should be set False at end of 'on_tx_done()'

If code is waiting for the 'transmitting' flag to become False it could start execution before the on_tx_done() method has finished setting the dio mapping etc.

Basic idea...where D is a dragino instance

while D.transmitting:
    pass

# do something here
# this could be called whilst on_tx_done() is completing it's handling of the interrupt.

Will this code be compatible with TTN V3? I understand TTN are switching to V3 in September this year.

I used this code & the dragino HAT for a project and would like to know if there would be any problems to overcome.

Many Thanks

This time I have a question about the dragino.py code.

The app I'm developing will spend most of its time listening for (occasional) downlink messages and a short time transmitting responses.

What is the best way to do this with dragino.py?

Looking at the code it appears to me that it just sends MHDR.UNCONF_DATA_UP and MHDR.JOIN_REQUEST messages and responds only to MHDR.JOIN_ACCEPT. I cannot see how I can receive messages into my app without changing the dragino.py code.

This is how I see it (roughly):-

1. in init () add self.UNCONF_DATA_DOWN=None
2. add new method setDownlinkCallback(myCallback): set self.UNCONF_DATA_DOWN=myCallback
3. add a new IF clause to rx_done()
   elif lorawan.get_mhdr().get_mtype() ==MHDR.UNCONF_DATA_DOWN and self.UNCONF_DATA_DOWN is not None: self.UNCONF_DATA_DOWN(payload)

Your thoughts would be appreciated.
Thanks

I know this code works well on V2 and you said it was tested on V3 but I created a V3 app and added a new test device but have been unable to join TTN.

Occasionally I can see, in the V3 console the message 'Accept join-request' but I don't receive the JOIN_ACCEPT. I'm wondering if the JOIN_ACCEPT is, for some odd reason, on a different frequency - that's something I haven't been able to explore as I haven't seen 'Accept join-request' messages for some time (hours) now and , I didn't keep the meta data to see if there was any more info.

As I said, your code works fine on V2 I get uplinks and can send downlinks with no bother.

I've tried a few ttn-lw-cli commands - specifically --mac-settings.resets-f-fcnt, which seemed to work earlier but now does not so I may be on the wrong track with that one.

The dragino.ini shows fcount=1 and none for the session keys. I'm just using the simple test.py to establish a join.

So, I was wondering what you did to verify the code works on V3?

Thanks for any help.

will the OTTA functions still be implemented?

I'm reading this:-

https://www.thethingsnetwork.org/forum/t/lorawan-1-1-devnonce-must-be-stored-in-a-non-volatile-memory-on-end-device/48995/4

And in particular this

This is telling us that DevNonce is no longer a random 2 byte number but an incrementing number which has 64k possible values. A random number can be repeated.

Do you plan to change the dragino.py code? It will need to store the devnonce (probably in dragino.ini) and increment it on each join attempt till it reaches it's max value. One hopes that 64K values is more than enough for testing.

I'm hoping this is why my dev code is only occasionally showing a join-request in the V3 console and making dev difficult.. I'm about to test that today.

Does the code currently support confirmed downlink messages? Need to investigate and if not add it.

Hello,

I need more processing power than the RPi 3B+ for my application, so I work now with a RPi 4. Is the dragino lora/gps hat 1.4 compatible with RPi 4 ? The test.py work like on the RPi 3 but I don't get anything on TTN. I use a public gateway from someone else I don't know so I can't see where the problem is. I don't even know if the message is sent correctly except for the confirmation in the command prompt from the test.py. Does someone know of an issue with RPi 4 ?

Marius

Hey,

The original project claimed this worked with an RFM95, is there any way this code might work too?

When running test.py I get:

Mode <- SLEEP
Mode <- FSK_STDBY
Traceback (most recent call last):
  File "./test.py", line 13, in <module>
    D = Dragino("dragino.ini", logging_level=logging.DEBUG)
  File "/home/pi/LoRaWAN/dragino/dragino.py", line 56, in __init__
    super(Dragino, self).__init__(logging_level < logging.INFO)
  File "/home/pi/LoRaWAN/dragino/SX127x/LoRa.py", line 100, in __init__
    self.rx_chain_calibration(calibration_freq)
  File "/home/pi/LoRaWAN/dragino/SX127x/LoRa.py", line 854, in rx_chain_calibration
    self.set_mode(op_mode_bkup)
  File "/home/pi/LoRaWAN/dragino/SX127x/LoRa.py", line 221, in set_mode
    sys.stderr.write("Mode <- %s\n" % MODE.lookup[mode])
KeyError: 0

I'm guessing this is due to using a different hat?

Hi All.
I have tried to get this working on my Raspberry Pi2 (with Dragino Lora/GPS_HAT v1.4)
https://wiki.dragino.com/index.php?title=Lora/GPS_HAT

After adjusting for Subband 2 within AU915 (which TTN uses). I run the test.py code and all I see is the Waiting repeat.

pi@raspberrypi2:~/dragino $ ./test.py Mode <- SLEEP Mode <- FSK_STDBY Mode <- SLEEP Mode <- FSK_STDBY Mode <- SLEEP 2021-03-28 16:07:16,977 - Dragino - 58 - DEBUG - Nonce = [240, 225] 2021-03-28 16:07:16,986 - DraginoConfig - 303 - INFO - Using OTAA mode 2021-03-28 16:07:16,987 - DraginoConfig - 416 - DEBUG - Converted 8/8 items 2021-03-28 16:07:16,988 - DraginoConfig - 416 - DEBUG - Converted 8/8 items 2021-03-28 16:07:16,990 - DraginoConfig - 416 - DEBUG - Converted 16/16 items 2021-03-28 16:07:16,991 - DraginoConfig - 313 - WARNING - Unable to read session details 2021-03-28 16:07:16,992 - DraginoConfig - 325 - DEBUG - GPS Baud Rate: 9600 2021-03-28 16:07:16,994 - DraginoConfig - 326 - DEBUG - GPS Serial Port: /dev/serial0 2021-03-28 16:07:16,995 - DraginoConfig - 327 - DEBUG - GPS Serial Timeout: 1 2021-03-28 16:07:16,997 - DraginoConfig - 328 - DEBUG - GPS Wait Period: 10 2021-03-28 16:07:16,998 - DraginoConfig - 329 - DEBUG - Spreading factor: 7 2021-03-28 16:07:16,999 - DraginoConfig - 330 - DEBUG - Max Power: 0F 2021-03-28 16:07:17,000 - DraginoConfig - 331 - DEBUG - Output Power: 0E 2021-03-28 16:07:17,001 - DraginoConfig - 332 - DEBUG - Sync Word: 34 2021-03-28 16:07:17,002 - DraginoConfig - 333 - DEBUG - RX CRC: True 2021-03-28 16:07:17,003 - DraginoConfig - 334 - DEBUG - Frame Count Filename: .lora_fcount 2021-03-28 16:07:17,004 - DraginoConfig - 335 - DEBUG - Auth mode: OTAA 2021-03-28 16:07:17,006 - DraginoConfig - 349 - DEBUG - Device EUI: 00 60 59 E0 EF F9 49 A3 2021-03-28 16:07:17,008 - DraginoConfig - 352 - DEBUG - App EUI: 70 B3 D5 7E D0 03 FE 74 2021-03-28 16:07:17,009 - DraginoConfig - 355 - DEBUG - App Key: 0A 50 50 01 40 07 06 00 E3 0D E0 F2 09 D0 4D 04 2021-03-28 16:07:17,016 - DraginoConfig - 365 - DEBUG - Joined False 2021-03-28 16:07:17,018 - Dragino - 171 - DEBUG - Performing OTAA Join 2021-03-28 16:07:17,019 - Dragino - 175 - INFO - App key = [10, 80, 80, 1, 64, 7, 6, 0, 227, 13, 224, 242, 9, 208, 77, 4] 2021-03-28 16:07:17,020 - Dragino - 176 - INFO - App eui = [112, 179, 213, 126, 208, 3, 254, 116] 2021-03-28 16:07:17,021 - Dragino - 177 - INFO - Dev eui = [0, 96, 89, 224, 239, 249, 73, 163] 2021-03-28 16:07:17,023 - Dragino - 102 - INFO - Frequency = 916.8 Mode <- STDBY Mode <- TX Waiting 2021-03-28 16:07:17,092 - Dragino - 148 - DEBUG - TX Complete Mode <- STDBY Mode <- RXCONT Waiting Waiting Waiting Waiting Waiting Waiting
Similar reported issue - jeroennijhof#5

When I have looked at the console of the v2 TTN - I see that the activation request was seen.

{ "time": "2021-03-28T07:57:37.449676372Z", "frequency": 917.2, "modulation": "LORA", "data_rate": "SF7BW125", "coding_rate": "4/5", "gateways": [ { "gtw_id": "eui-00800000a0003e55", "timestamp": 3476306715, "time": "2021-03-28T07:57:37.39437Z", "channel": 2, "rssi": -110, "snr": -3.5 }, { "gtw_id": "eui-60c5a8fffe76f86a", "timestamp": 1912733067, "time": "2021-03-28T07:57:37.394368Z", "channel": 2, "rssi": -120, "snr": -7.3 } ] }

For fun I also added to the v3 and the following was a little more detailed, but still im at a loss as to the problem..

`Last seen7 minutes ago
arrow_upwardn/a
arrow_downwardn/a
Created 7 minutes ago

16:07:17
Drop join-request
MIC mismatch

16:07:17
Join-request to cluster-local Join Server failed
MIC mismatch

16:07:17
Send join-request to cluster-local Join Server
JoinEUI
70B3D57ED003FE74
DevEUI
006059E0EFF949A3
Selected MAC version
1.0.2

16:07:17
Receive join-request
JoinEUI
70B3D57ED003FE74
DevEUI
006059E0EFF949A3
Bandwidth
125000
SNR
-6.2
RSSI
-110
Raw payload
0074FE03D07ED5B370A349F9EFE0596000F0EDE55EB292
Event details
Close event info
Eve`

I haven't scheduled any downlink messages, so not sure where they are coming from.
Don't see this behaviour in v2

I am using your code (with minor modifications) to trigger a callback to my own code when a downlink message is received. Your code just accepts a JOIN_ACCEPT - which is fine if all it does it transmit GPS or other stuff but I need to send downlink commands to request data to be transmitted and I'm having trouble finding anyone who has done this. (maybe no looking in the correct places)

I am successfully receiving the payloads as MDHR.UNCONF_DATA_DOWN. I can pass the payloads to my routines but I'm uncertain what methods to call to decode the payload and recover my downlink message (normally only 1 to 5 bytes long) before it is sent to my code.

I have trawled through your code and can see decrypt exists in one of the modules but I'm unsure how to use it.

Could you point me in the right direction please?

Many thanks

on_tx_done() sets the dio_mapping to [0, 0, 0, 0, 0,0]

When the join() function is called a second time the dio_mapping is not setup and the tx_done interrupt does not happen hence the radio isn't put into RXCONT mode.

When I add the following line before the switch to transmit mode the tx_done interrupt works just fine.

self.set_dio_mapping([1, 0, 0, 0, 0 , 0])

With my dev RasPi I have to retry joins at different SFs and frequencies because I'm 11km away from a gateway and my device isn't always seen by the gateway using SF7. Often it is SF8 or 9 and it varies from test to test.

I'm still not getting the join_accept reply but that's another issue relating to RX1 and RX2 windows, which I'm working to resolve.

Hi,

I will like to ask if the code can support SF12 (Spreading Factor)?

Also i testing Downlink code is working perfect in the RX1 windows but if the gateway send in RX2 windows can not receive downlink why??

In order to manage air time I need to know how long a transmission has taken then wait 99x that to adhere to the 1% duty cycle.

send_bytes() returns immediately after passing the payload to the radio so that call duration alone doesn't give me the airtime which can be several seconds at some SFs.

my solution:

in dragino.py _init()_ add a tx_done flag e.g.

self.tx_done=False

in send_bytes() add this just before the switch to TX mode.

self.tx_done=False

Also, in join() just before the switch to TX mode add the above line.

In on_tx_done() add

self.tx_done=True

Now it become possible to know how long a transmission took and adjust the duty cycle accordingly. (This is not complete code)

from time import time,sleep()
from dragino import dragino
D=dragino(...)

D.join()
while not D.registered:
   sleep(0.1) # must be v small or use a non-blocking wait
 
start=time()
D.send("Hello world")
while not D.tx_done:
    sleep(0.1)
airtime=time()-start

# now we wait 99xairtime before the next transmission.

Ok this isn't microsecond accurate because send calls send_bytes() and both do some work before the radio switches to TX mode. But it helps.

This also helps with setting up for receiving in RX1 and/or RX2 - though I haven't got that bit working yet. I guess your use case doesn't have those problems because, as you said in an earlier exchange, you are in close proximity to your gateway. Mine became a brick when I tried to put it on V3 - ho hum.

During testing my end device on TTN V3, I created a loop (see below) which tried to re-join after a period of time when the code didn't get a JOIN_ACCEPT back (that's another issue) .

NOTE: This is not really an issue once the device has had a successful join and cached the keys.

D = Dragino("dragino.ini", logging_level=logLevel)
D.join()

print("Waiting for JOIN ACCEPT")
start=time.time()

while not D.registered():
    if time.time()-start>15:
      start=time.time()
      print("Retrying join")
      D.join()
    sleep(2)

The TTN V3 console shows an error something like 'devNonce already used'.

If the program is halted and restarted that isn't an issue but my use case involves a remote end-node which cannot be accessed manually although I could add code to use systemctl to restart my service. However I think this suggestion is neater and easier.

edit dragino.py
Immediately after line 291 in join() add the line self.devnonce=[randrange(256),randrange(256]].
That way, whenever a call to join() occurs the devnonce is changed.

Hi,
Can this code support downlink? If yes can you provide me more details...
I can uplink data with otaa.

Hey,
I've tried your code with a raspi 4 and a dragino hat and I get this error.
Unfortunately I don't understand it.
Help would be much appreciated.

Mode <- SLEEP
Mode <- FSK_STDBY
Traceback (most recent call last):
File "/home/pi/Downloads/dragino-master/test.py", line 13, in
D = Dragino("dragino.ini", logging_level=logging.DEBUG)
File "/home/pi/Downloads/dragino-master/dragino/dragino.py", line 55, in init
super(Dragino, self).init(logging_level < logging.INFO)
File "/home/pi/Downloads/dragino-master/dragino/SX127x/LoRa.py", line 100, in init
self.rx_chain_calibration(calibration_freq)
File "/home/pi/Downloads/dragino-master/dragino/SX127x/LoRa.py", line 854, in rx_chain_calibration
self.set_mode(op_mode_bkup)
File "/home/pi/Downloads/dragino-master/dragino/SX127x/LoRa.py", line 221, in set_mode
sys.stderr.write("Mode <- %s\n" % MODE.lookup[mode])
KeyError: 0

Greetings Mel