OTAA - waiting repeats.... v2 ttn and v3 both see the activation. #6
Comments
I use the code, from 9 months ago, on a project and it worked fine in the UK (815Mhz). The MIC Mismatch you get from using V3 suggests to me that V3, somehow, calculates the MIC differently so you should stick with V2 for now. Look at dragino\LoraWAN\JoinAcceptPayload.py and JoinRequestPayload.py - you will find an example of the compute_mic() method. However, 'waiting' forever suggests the join-accept response has been missed or not sent. What does your logfile have in it? If you look in dragino.py there's an on_rx_done() method on line 118 which logs the message "Received message". If the message is a JOIN_ACCEPT it logs 'Join resp' to the log file then validates the MIC etc. This should give you some idea what is/isn't happening. |
I'm afraid I'm not sure what's going on here - I suspect there's something else that needs changing to adapt it to the different region. As it works fine on both v2 & v3 in the Uk |
Thanks @pjb304 & @BNNorman . D = Dragino("dragino.ini", logging_level=logging.INFO) changing it to DEBUG - but nothing of note was showing on stdout or elsewhere. Also tried - Anyhow - I made a small change in the v3 console and updated my settings to be 1.0.1 Lorawan and I got a few extra steps, no sign of the MIC errors now. I have a feeling the issue is that I am not receiving anything. When I tweaked the dragino/FrequncyPlan.py to align to the AU915 (subband 2) frequencies for TTN in Australia, I didnt see any place to adjust the down (RX) frequencies. As you can see from this - https://github.com/Fluent-networks/floranet/blob/f025825fa234194646d9831bd52fa3a3a55c0666/floranet/lora/bands.py AU915 TX freq are 200khz stepped - Channel 8 (916.8) through Ch15 (917.5) plus a 500khz Ch65 (917.5) but unlike the EU868 the downlink (RX) frequencies are (also for US915) not the same as the uplink (TX). I have tried a few quick and dirty edits but all without any progress. dragino/SX127x/LoRa.py: def init(self, verbose=True, do_calibration=True, calibration_freq=923): Any suggestions as to next (easy) steps I can try? Or will it require a significant code edit to have a TX and RX frequency alignment for this region? |
Yes, the code does currently have the assumption that uplink and downlink happen on the same frequency. I think the way to change that would be to use similar calls to those in As for the calibration I'm afraid I'm not sure how best to change that to 923MHz. |
Yeah.... cool Thanks. I tried (i think) something along the lines of your suggestion prior to you suggesting it. As I looked at some of the other other forks - specifically the https://github.com/ryanzav/LoRaWAN/blob/master/otaa_helium.py
didnt seem to hit the mark, or make any real difference. but its late here.... time to goto bed and perhaps tomorrow have another look |
According to the specs, in the US902-928 channels:
In other words, there are two sets of frequencies in the US frequency plan, one for uplink and one for downlink. If you use the first uplink channel, you will get a response on the first downlink channel. I modified the code slightly to this effect: FrequencyPlan.py
Dragino.py
Then, every time there would be an uplink (such as when registering), I call |
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`
The text was updated successfully, but these errors were encountered: