Comments (13)
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?
from lorawangateway.
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.
from lorawangateway.
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...
from lorawangateway.
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.
from lorawangateway.
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.
from lorawangateway.
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.
from lorawangateway.
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
from lorawangateway.
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
from lorawangateway.
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
from lorawangateway.
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 ;-)
from lorawangateway.
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)
from lorawangateway.
Great! I'll look at what I can do.
from lorawangateway.
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.
from lorawangateway.
Related Issues (20)
- add localization to the time stamps HOT 3
- NTP server url in Config settings file HOT 3
- docs: Dev branch missing CJSON at https://nodemcu-build.com HOT 2
- Output of telnet strange format HOT 2
- hardware for this project HOT 5
- Compatibility RF95 HOT 8
- Add status messages HOT 2
- connect to ttn-router-eu HOT 2
- PANIC: unprotected error in call to Lua API (bad argument #1 to 'mode' (number expected, got nil)) HOT 5
- ESP8266 --> GPIO 13 busy HOT 4
- Incorrect transmit frequency HOT 9
- [DELETED] HOT 1
- OTA issue with single channel gateway HOT 2
- Problem uploading lua files HOT 5
- Problem with lua shell HOT 2
- Why won't support for multiple channels work? HOT 6
- I need your help on connecting to server HOT 2
- why the percent of receive success is low when set the GW_SF to ALL HOT 11
- Remote Access
- Send to GW
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from lorawangateway.