OTAA works with TTN router but not lorawan-server local server

[dlarue]

I have the lorawan-server( https://github.com/gotthardp/lorawan-server ) on my machine and for some reason the LoRaWanGateway will not negotiate a join with that backend server. I can use the same arduino-lmic single channel code against the lorawan-server with a MultiTech MTAC gateway and full up standard OTAA works with the MTAC gateway. But when I turn the MTAC off and power up the LoRaWanGateway, I don't see it ever joining.

I did notice that with the MTAC it wants to join on Channel 65(dn2Chnl) in both single channel and multi-channel configuration. But even setting LMIC.txChnl=65 in the Join-failed switch/case does not help the LoRaWanGateway complete a join request.

Any ideas why this might work fine against TTN backend but not the local lorawan-server backend even though that backend works with the MultiTech MTAC gateway?

[JaapBraam]

This is probably not related to your LoRaWanGateway...

However:
If a node wants to join, it sends a join request

• Does your LoRaWanGateway receive that request? (look in the logging)
• Does your lorawan-server receive the request?

If a join request is received ty the lorawan-server, it will prepare a join-response and instruct the gateway to transmit the join-response at a specific time.

• Does your lorawan-server sends a txpk message to your LoRaWanGateway? (look in the logging)
• Does your LoRaWanGateway transmit the message on time?

Your lorawan-server has to know the keys in your node, because it cannot prepare a join-response for the node... Are you sure the lorawan-server knows the correct keys?

[dlarue]

The gateway(LoRaWanGateway) must be receiving join messages because when it's pointing to TTN (router.us.things.network, 1700) the joins work. When I switch to the local network server(lorawan-server) by pointing local( 192.168.2.106, 1680 ) then the joins do not.

I will connect it back to TTN and look at the gateway logs and see if any debug msg are different. Right now, all I ever see are rx timout messages.

I will also look at adding debugging to the local server(lorawan-server) to show txpk messages.

The keys should be ok since I can remove the WeMos/LoRaWanGateway and put in an Multitech MTAC gateway pointing to the local sever(lorawan-server) and the joins work. Both full channel usage OTAA and single channel OTAA.

[JaapBraam]

all I ever see are rx timout messages

That's not good... You should see rxpk's in the logging when the node tries to join...

rx timeouts cannot be caused by choosing another backend...

[dlarue]

I see those no matter what, not because of one backend or the other. Was just saying it's the "standard" logging messages I see.

[dlarue]

FWIW, I made the simple changes to add GW_PORT and repointed to TTN. I tested with an ABP device and saw it on TTN Console and saw the rxpk on the gateway console. I now have my Single Channel Node(SCN) doing OTAA and in 10 minutes or so it should join. I have yet to see any rxpk packets on the gateway console and only see rx timeout messages. Again, those are normal for me no matter what nodes are operating.

[dlarue]

I got the single channel node and this gateway joining with TTN. It happens quickly by setting the txChnl to the same channel as the gateway is set to (in my case chan 10 ) in the event processing for join_failed:

   case EV_JOIN_FAILED:
        Serial.println(F("EV_JOIN_FAILED"));
        #ifdef SCN
        LMIC.txChnl=10; // SCN set next join channel to the one we have open
        #endif
        break;

Switching the gateway to point to my local lorawan-server results in no join but I now see rxpk packets on the gateway console.

transmitPkt 14964 11051 -2 924 160 144 2 64 20 7
rxpk 01ef2000a020a6f42f0277b7 message {"rxpk":[{"rssi":-46,"stat":1,"modu":"L9
txpk {"txpk":{"modu":"LORA","rfch":0,"ipol":true,"size":17,"data":"INsE5mSWTZXtIdXtu}
txpk_ack {"txpk_ack":{"error":"NONE"}}
transmitPkt 15714 11428 -3 924 160 144 2 64 20 7
rx timeout 7 rssi 42
rxpk 017d1400a020a6f42f0277b7 message {"rxpk":[{"rssi":-44,"stat":1,"modu":"L9
txpk {"txpk":{"modu":"LORA","rfch":0,"ipol":true,"size":17,"data":"IE7BKk4uHRwpfNaRU}
txpk_ack {"txpk_ack":{"error":"NONE"}}
transmitPkt 15516 10764 -1 924 160 144 2 64 20 7
rx timeout 7 rssi 46
rx timeout 10 rssi 126
rx timeout 10 rssi 125
rx timeout 8 rssi 125
rx timeout 9 rssi 123
rx timeout 10 rssi 125
rx timeout 10 rssi 51
rxpk 0197a700a020a6f42f0277b7 message {"rxpk":[{"rssi":-45,"stat":1,"modu":"L9
txpk {"txpk":{"modu":"LORA","rfch":0,"ipol":true,"size":17,"data":"ILCv4q94wDLC6dPWn}
txpk_ack {"txpk_ack":{"error":"NONE"}}
transmitPkt 14831 10869 -2 924 160 144 2 64 20 7
rx timeout 7 rssi 48
rx timeout 10 rssi 120
rx timeout 10 rssi 126
rx timeout 10 rssi 125
rx timeout 10 rssi 125
rx timeout 10 rssi 45
rxpk 0156e200a020a6f42f0277b7 message {"rxpk":[{"rssi":-45,"stat":1,"modu":"L9
txpk {"txpk":{"modu":"LORA","rfch":0,"ipol":true,"size":17,"data":"IDpXzx6+cwrg/k0rF}
txpk_ack {"txpk_ack":{"error":"NONE"}}
transmitPkt 14905 10996 -3 924 160 144 2 64 20 7

Someone else is having similar problems after switching from TTN to the local/lorawan-server using a multi-channel concentrator. But IIRC, I was able to get OTAA working with the lorawan-server when I used the Multitech MTAC gateway and why I posted here.

[dlarue]

What I'm seeing is the transmitPkt response has an incorrect freq value compared to when I'm hitting against TTN. It looks like SX1276.lua handles that.

Here's the data I captured comparing hitting ttn vs local(lorawan-server). I reorganized the txpk response(local) to do element-by-element comparison with ttn response to make it easier to look for errors:

Join Request from node-
ttn:
rxpk 01826000a020a6f42f0277b7 message {"rxpk":[{"rssi":-45,"stat":1,"modu":"LORA","rfch":1,"tmst":62114041,"datr":"SF10BW125","lsnr":9,"time":"2017-04-14T21:49:32.286696Z","codr":"4/5","data":"AD0AAPB+1bNw7Dk5gwAAAAFwBXKYQqY=","freq":904.300,"chan":0,"size":23}]} length 237
local:
rxpk 01474600a020a6f42f0277b7 message {"rxpk":[{"rssi":-45,"stat":1,"modu":"LORA","rfch":1,"tmst":90912849,"datr":"SF10BW125","lsnr":9,"time":"2017-04-14T21:55:05.811333Z","codr":"4/5","data":"AD0AAPB+1bNw7Dk5gwAAAAHZv9XcWRY=","freq":904.300,"chan":0,"size":23}]} length 237

Join Response from network server(ttn/lorawan-server)-
ttn:
txpk {"txpk":{"imme":false,"tmst":67114041,"freq":924.5,"rfch":0,"powe":20,"modu":"LORA","datr":"SF10BW500","codr":"4/5","ipol":true,"size":17,"data":"INNibv70rGvkhSoXlHUjQu0="}}
local:
txpk {"txpk":{"modu":"LORA","rfch":0,"ipol":true,"size":17,"data":"IIpBBBgn2rG6szraZ6qnVpw=","powe":20,"imme":false,"tmst":95912849,"codr":"4/5","datr":"SF10BW500","freq":924.5}}
txpk {"txpk":{"imme":false,"tmst":95912849,"freq":924.5,"rfch":0,"powe":20,"modu":"LORA","datr":"SF10BW500","codr":"4/5","ipol":true,"size":17,"data":"IIpBBBgn2rG6szraZ6qnVpw="}}

Join ACK from node-
ttn:
txpk_ack {"txpk_ack":{"error":"NONE"}}
local:
txpk_ack {"txpk_ack":{"error":"NONE"}}

ERROR?
ttn:
transmitPkt 16297 11974 -1 924500000 160 144 2 64 20 17
local:
transmitPkt 15337 11015 -2 924 160 144 2 64 20 17

ttn:
rxpk 01ce6800a020a6f42f0277b7 message {"rxpk":[{"rssi":-42,"stat":1,"modu":"LORA","rfch":1,"tmst":67290261,"datr":"SF7BW125","lsnr":9,"time":"2017-04-14T21:49:37.462913Z","codr":"4
/5","data":"QGokASaAAAAB2c27+dDz2h7/vjKzWs5gCGE=","freq":904.300,"chan":0,"size":26}]} length 240

[dlarue]

I commented out the debug output in SX1276.lua for the transmitPkg function to show the frequency and it sure looks wrong at "0.000924 Mhz".

904.300000 Mhz E2 13 33
904.300000 Mhz E2 13 33
0.000924 Mhz 00 00 00
transmitPkt 14909 5343 -3 924 160 144 2 64 20 17
904.300000 Mhz E2 13 33
904.300000 Mhz E2 13 33
904.300000 Mhz E2 13 33

[dlarue]

Jaap, is this the network server JOIN_ACCEPT message?
transmitPkt 14909 5343 -3 924 160 144 2 64 20 17

If so, the working system(ttn) shows a full freq value and I'm trying to trace this back to the server to see if it's getting set/sent correctly.

the TTN server results in this showing up on the gateway console and with the freq of 924500000:
transmitPkt 16297 11974 -1 924500000 160 144 2 64 20 17

[JaapBraam]

It is a bug!
On line https://github.com/JaapBraam/LoRaWanGateway/blob/master/src/LoRaWanGW.lua#L191

The difference is that TTN puts the freq somewhere in the middle of the JSON, while your local gateway puts it in last...

The float value of the frequency cannot be used as-is, because the gateway uses the integer version of the Lua firmware. The regular expression that matches the frequency expects a comma after the frequency (for the next field), that will only match if there is a next field .

The fix might be as easy as removing the last comma in the regular expression... I will fix this later (soon), unless someone else beats me in making a fix, does some testing and issues a pull request ;-)

[JaapBraam]

Jaap, is this the network server JOIN_ACCEPT message?
transmitPkt 14909 5343 -3 924 160 144 2 64 20 17

No, it is some information about the execution of the txpk message above it. The txpk message is sent from the server to the gateway and specifies how and when to send what message on what frequency...

The third number on this line is the number of microseconds that the timing differs from the time in the txpk (in this case 3 microseconds late). The fourth parameter is the frequency used (in Hz) which clearly shows the bug. The rest are the register values used to specify SF, BW, TXPow, CRC etc. (See SX1276 datasheet if you are interested in those)

[dlarue]

Great! I'll look at what I can do.

[dlarue]

I have it working with both network servers(TTN,lorawan-server). I'll do a pull request and have this and the GW_PORT config updates in it.