search

JaapBraam / LoRaWanGateway

A LoRaWan Gateway in LUA
MIT License
225 stars 74 forks source link

does not seem to be completing activation #16

Closed dlarue closed 7 years ago

dlarue commented 7 years ago

I tried the new code(didn't change firmware though) and it seems to have a problem activating. After telneting in it looks ok but from a minicom console I'd previously seen a non 902.3MHz freq listed. Here's the telnet output upon connecting:

LoRaWanGateway Configuration GW_HOSTNAME "lorawangw" GW_ROUTER "router.us.thethings.network" GW_FREQ 902300000 GW_BW "BW125" GW_SF "ALL" GW_LAT "32.79242" GW_LON "-117.24457" GW_ALT 2 GW_NSS 0 GW_DIO0 8 GW_DIO1 1 Statistics Uptime 0 days, 0 hours, 3 minutes, 1 seconds Memory free 9568 bytes Rx packets 0 Rx packets OK 0 Rx timeouts 7 Rx forwarded 0 Tx packets 0 Tx packets sent 0 Ack ratio 100.0% (40/40)

dlarue commented 7 years ago

Never mind, another gateway locally was getting involved and once turned off, activation happened.

JaapBraam commented 7 years ago

The statistics show that no packets have been received sucessfully (Rx packets = 0). The gateway seems to have missed your message (Rx timeouts = 7)

The nodes I use (based on the LMIC code) try to join on 3 different frequencies. If a join fails, it will try the next frequency. When the last frequency fails, it steps up to a higher SF and tries to join on the first frequency etc...

Due to duty cycle regulations, there will be quite some time between the join attemps, so it will take a while before the gateway's single frequency is tried again...

The non 902.3Mhz frequency you saw is almost certain a txpk received from the network server. This is a request generated by the network server to send a specific message on a specific time. The network server decides what frequency a message must be sent on, and what SF to use. Your node (if configured correctly) will know when to listen for replies on that different frequency.

dlarue commented 7 years ago

It eventually did activate and a reset of the frame count and of the device shows it going through a few activation cycles again. It'll probably work its way around the frequencies and figure it out once back to 902.3MHz.

On reset of the node:

rxpk 0110e300a020a6f42f0277b7 message {"rxpk":[{"rssi":-45,"stat":1,"modu":"LORA","rfch":1,"tmst":1414640693,"datr":"SF7BW125","lsnr":10,"time":"2017-02-03T21:05:22.175374Z","codr":"4/5","data":"AD0AAPB+1bNw7Dk5gwAAAAFkyG+uSaE=","freq":902.300,"chan":0,"size":23}]} length 239 txpk {"txpk":{"imme":false,"tmst":1419640693,"freq":923.3,"rfch":0,"powe":20,"modu":"LORA","datr":"SF7BW500","codr":"4/5","ipol":true,"size":17,"data":"IGRID9zIPTqPPQA1TLKuh6g="}} txpk_ack {"txpk_ack":{"error":"NONE"}} transmitPkt 4143 -263 -269 923300000 112 144 2 64 20 17 rx timeout 7 rssi 42

JaapBraam commented 7 years ago

transmitPkt 4143 -263 -269 923300000 112 144 2 64 20 17

shows the timing of the sending process:

So the message is sent a bit late...

If messages are frequently sent late (negative values) it is best to take a larger margin on line 444 of SX1276.lua. The margin is 20 on that line: instruct the ESP8266 to call transmitPkt 20ms before the message has to be sent. Due to fact that the ESP8266 'is not so precise' in timed calls, it is necessary to use this margin.

I will change the margin to 30ms in the next commit, just to be sure.

dlarue commented 7 years ago

It still took ~15 minutes to join using the 30ms number. I do wonder if the fact that I started the single channel at Channel 0(902.3MHz) instead of something higher has anything to do with it. I see others starting at 912.2 and 904.2 MHz.

JaapBraam commented 7 years ago

I use LMIC based nodes, and LMIC picks a random channel to start joining. With each failed join attempt the next channel is tried. After the last channel is tried, the next SF is tried on channel 0. So if your gateway only listens on the first channel, the chance that it will be skipped when joining on SF7 is biggest. So choosing the last channel will guaranty that it will be in the SF7 join attempt process.

However, in my nodes I patched LMIC to always start joining on channel 0, and my gateway is listening on channel 0. This causes the first join attempt to succeed (usually), making experiments taking less wait time.