does not seem to be completing activation

[dlarue]

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]

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

[JaapBraam]

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]

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]

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

shows the timing of the sending process:

• transmitPkt function invoked 4143us before the message has to be sent
• starting wait loop -263us before the message has to be sent (so 263us late in this case)
• ending wait loop -269us before the message has to be sent (so 269us late in this case)

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]

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]

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.