But on a more serious note, I did read this but I’m too noob in lorawan to understand what the differences are with alternative solutions. Even more, I have no oversight in what alternatives exist to choose from.
Excellent, you have a sense of humour, good stuff!
Read all of this: https://www.thethingsnetwork.org/docs/lorawan/ - then you will be more qualified than most.
For your specific question, it’s sort of answered here: https://www.thethingsnetwork.org/docs/devices-and-gateways/adding-gateways/
Thx for the links. This is getting off topic, but after reading a lot more my conclusion is that basics station has two major advantages (but correct me when Im wrong or missing something):
- more secure communication between gateway and the network server (the things stack)
- central provisioning when managing a lot of gateways
The second advantage is not interesting for me since I only have 1 gateway.
Am I missing a major advantage?
I looked at the LIG16 documentation, and it should support configuring Basics Station from the web GUI. See wiki here: Notes for TTN - Wiki for Dragino Project
But this option is not available in the latest stable firmware. I am considering installing the latest beta to see if it is available there.
Edit: looking at the docs and the firmware levels the latest beta firmware should indeed be the right one. Will try tomorrow.
These are indeed two of the key, if not the two key benefits. There are others, including the move away from UDP based comms - not only more secure but also more resilient than UDP, as used for the original Semtech (oft Aka ‘Legacy’) Packet Forwarder as UDP packets often go astray or get dropped as they transit ‘the net’. - So secure comms not only in the sense of being authenticated and hence from a known reliable source vs rogue/unauthorised hijacking GW but also secure in terms of greater probablility of packet delivery.
I’d respectfully suggest you do an install with what you have so you have a good chance of having a working gateway and learn the basics of devices, the console, integrations etc etc before going for the juggling of fire brands on a unicycle.
This morning I tried to connect my LIG16 to TTS Basic Station using the beta firmware. I could connect without problems, data-packages were transferred from my gateway to TTS. I could see all my nodes in their applications.
But then I observed that the system-log of my gateway filled up with “Time sync rejected”-messages.
2021-09-11 06:58:14.551 [SYN:INFO] Mean MCU drift vs SX130X#0: -1.8ppm
2021-09-11 06:58:33.457 [SYN:VERB] Time sync rejected: quality=346 threshold=340
2021-09-11 06:58:46.060 [SYN:VERB] Time sync rejected: quality=341 threshold=340
2021-09-11 06:58:56.563 [SYN:VERB] Time sync rejected: quality=346 threshold=340
2021-09-11 06:59:02.865 [SYN:VERB] Time sync rejected: quality=379 threshold=340
2021-09-11 06:59:04.965 [SYN:INFO] MCU/SX130X drift stats: min: +0.0ppm q50: +3.6ppm q80: +7.4ppm max: -12.4ppm - threshold q90: +8.6ppm
2021-09-11 06:59:04.965 [SYN:INFO] Mean MCU drift vs SX130X#0: -1.3ppm
2021-09-11 06:59:11.267 [SYN:INFO] Time sync qualities: min=272 q90=346 max=379 (previous q90=340)
2021-09-11 06:59:24.921 [SYN:ERRO] Repeated excessive clock drifts between MCU/SX130X#0 (3 retries): 11.4ppm (threshold 8.6ppm)
2021-09-11 06:59:28.072 [SYN:ERRO] Repeated excessive clock drifts between MCU/SX130X#0 (6 retries): 8.8ppm (threshold 8.6ppm)
2021-09-11 06:59:35.425 [SYN:VERB] Time sync rejected: quality=376 threshold=346
2021-09-11 06:59:41.726 [SYN:INFO] MCU/SX130X drift stats: min: +3.3ppm q50: +8.3ppm q80: +11.0ppm max: +17.6ppm - threshold q90: +13.3ppm
2021-09-11 06:59:41.726 [SYN:INFO] Mean MCU drift vs SX130X#0: 7.0ppm
Additionally nothing was shown anymore in LogRead/ Gateway Traffic of the LIG16.
I stopped the experiment and went back to Semtech UDP.
btw: I recognized that this thread is in End Devices (Nodes) / Dragino.
imho it should be in Gateways/Dragino-gateways.
Hi @wolfp have you refered this back to Dragino team - would be interested to get their take on this… Please report back here if you hear anything. Also is there an option to reduce the amount of logging within the setup? This feels like debugging level logs.
I tried just as you this morning. Connection works well. I also get time sync rejected errors after some time. But I think it is also able to correctly do time sync. At least I still have incoming messages…
2021-09-11 08:38:46.613 [SYN:INFO] MCU/SX130X drift stats: min: +0.0ppm q50: -2.4ppm q80: -9.8ppm max: -13.8ppm - threshold q90: -11.9ppm
2021-09-11 08:38:46.613 [SYN:INFO] Mean MCU drift vs SX130X#0: -1.0ppm
2021-09-11 08:39:21.272 [SYN:INFO] Time sync qualities: min=306 q90=340 max=341 (previous q90=343)
2021-09-11 08:39:23.373 [SYN:INFO] MCU/SX130X drift stats: min: +0.0ppm q50: +6.2ppm q80: +13.3ppm max: +17.6ppm - threshold q90: +17.1ppm
2021-09-11 08:39:23.373 [SYN:INFO] Mean MCU drift vs SX130X#0: 4.0ppm
2021-09-11 08:39:35.976 [SYN:VERB] Time sync rejected: quality=371 threshold=340
2021-09-11 08:39:40.177 [SYN:VERB] Time sync rejected: quality=341 threshold=340
2021-09-11 08:40:03.282 [SYN:VERB] Time sync rejected: quality=341 threshold=340
2021-09-11 08:40:09.584 [SYN:INFO] MCU/SX130X drift stats: min: +1.0ppm q50: +3.8ppm q80: +16.7ppm max: -24.4ppm - threshold q90: -24.3ppm
2021-09-11 08:40:09.584 [SYN:INFO] Mean MCU drift vs SX130X#0: -1.5ppm
2021-09-11 08:40:22.187 [SYN:INFO] Time sync qualities: min=294 q90=341 max=371 (previous q90=340)
2021-09-11 08:40:34.790 [SYN:VERB] Time sync rejected: quality=354 threshold=341
2021-09-11 08:40:53.695 [SYN:INFO] MCU/SX130X drift stats: min: +1.0ppm q50: -3.3ppm q80: +11.4ppm max: -16.2ppm - threshold q90: +14.8ppm
2021-09-11 08:40:53.696 [SYN:INFO] Mean MCU drift vs SX130X#0: 0.7ppm
2021-09-11 08:41:02.098 [SYN:VERB] Time sync rejected: quality=347 threshold=341
2021-09-11 08:41:03.902 [S2E:VERB] RX 867.9MHz DR5 SF7/BW125 snr=-3.8 rssi=-118 xtime=0x4700000D2F54B3 - updf mhdr=40 DevAddr=26088ABD FCtrl=80 FCnt=2541 FOpts=[] 036D0C54..1E47 mic=-1989087438 (59 bytes)
2021-09-11 08:41:10.500 [SYN:VERB] Time sync rejected: quality=342 threshold=341
2021-09-11 08:41:12.600 [SYN:VERB] Time sync rejected: quality=350 threshold=341
2021-09-11 08:41:24.517 [S2E:VERB] RX 867.7MHz DR3 SF9/BW125 snr=-15.5 rssi=-125 xtime=0x4700000E69ED7E - updf mhdr=40 DevAddr=2601280E FCtrl=C2 FCnt=17965 FOpts=[0307] 0D3865CC..5189 mic=-495581456 (27 bytes)
2021-09-11 08:41:25.203 [SYN:INFO] Time sync qualities: min=295 q90=347 max=354 (previous q90=341)
2021-09-11 08:41:33.606 [SYN:VERB] Time sync rejected: quality=355 threshold=347
2021-09-11 08:41:42.008 [SYN:INFO] MCU/SX130X drift stats: min: -3.3ppm q50: -8.6ppm q80: -9.5ppm max: -20.9ppm - threshold q90: -16.8ppm
2021-09-11 08:41:42.008 [SYN:INFO] Mean MCU drift vs SX130X#0: -7.8ppm
2021-09-11 08:41:52.511 [SYN:VERB] Time sync rejected: quality=503 threshold=347
2021-09-11 08:42:13.516 [SYN:VERB] Time sync rejected: quality=353 threshold=347
2021-09-11 08:42:26.119 [SYN:INFO] Time sync qualities: min=311 q90=353 max=503 (previous q90=347)
2021-09-11 08:42:28.220 [SYN:INFO] MCU/SX130X drift stats: min: -2.4ppm q50: +7.1ppm q80: -10.5ppm max: -16.7ppm - threshold q90: -15.2ppm
2021-09-11 08:42:28.220 [SYN:INFO] Mean MCU drift vs SX130X#0: -4.1ppm
2021-09-11 08:42:55.526 [SYN:VERB] Time sync rejected: quality=380 threshold=353
2021-09-11 08:43:11.378 [S2E:VERB] RX 867.3MHz DR0 SF12/BW125 snr=8.8 rssi=-73 xtime=0x47000014C85984 - updf mhdr=40 DevAddr=260B1790 FCtrl=80 FCnt=39 FOpts=[] 02B67C6A..9DE9 mic=-1490846239 (31 bytes)
2021-09-11 08:43:11.821 [S2E:DEBU] ::1 diid=50352 [ant#0] - next TX start ahead by 4s537ms
2021-09-11 08:43:12.330 [SYN:INFO] MCU/SX130X drift stats: min: -1.0ppm q50: -2.9ppm q80: +9.5ppm max: -13.8ppm - threshold q90: -13.8ppm
2021-09-11 08:43:12.330 [SYN:INFO] Mean MCU drift vs SX130X#0: -2.0ppm
2021-09-11 08:43:16.338 [S2E:VERB] ::1 diid=50352 [ant#0] - starting TX in 19ms915us
2021-09-11 08:43:16.364 [S2E:INFO] TX ::1 diid=50352 [ant#0] - dntxed: 867.3MHz 16.0dBm ant#0(0) DR0 SF12/BW125 frame=6090170B268509000340FF00..B80695A4
2021-09-11 08:43:17.513 [S2E:DEBU] Tx done diid=50352
2021-09-11 08:43:29.135 [SYN:INFO] Time sync qualities: min=273 q90=341 max=380 (previous q90=353)
Also I got some nice logs about the temperature sensor after a while:
2021-09-11 08:46:33.984 [SYN:INFO] Time sync qualities: min=273 q90=341 max=376 (previous q90=341)
2021-09-11 08:46:42.387 [SYN:VERB] Time sync rejected: quality=629 threshold=341
2021-09-11 08:46:46.035 [S2E:VERB] RX 867.7MHz DR5 SF7/BW125 snr=14.0 rssi=-78 xtime=0x4700002193DE7D - updf mhdr=40 DevAddr=260B1790 FCtrl=80 FCnt=40 FOpts=[] 0293D7C6..4093 mic=449092140 (31 bytes)
2021-09-11 08:46:46.475 [S2E:DEBU] ::1 diid=50614 [ant#0] - next TX start ahead by 4s547ms
2021-09-11 08:46:50.789 [SYN:VERB] Time sync rejected: quality=342 threshold=341
2021-09-11 08:46:51.003 [S2E:VERB] ::1 diid=50614 [ant#0] - starting TX in 19ms838us
2021-09-11 08:46:51.017 [___:INFO] lgw_start:850: --- IN
Opening SPI communication interface
Note: chip version is 0x10 (v1.0)
INFO: using legacy timestamp
INFO: LoRa Service modem: configuring preamble size to 8 symbols
Loading AGC fw for sx1250
Loading ARB fw
ARB: dual demodulation disabled for all SF
INFO: no temeprature sensor found on port 0x39
INFO: found temperature sensor on port 0x3B
lgw_start:1179: --- OUT
lgw_receive:1310: INFO: RSSI temperature offset applied: 1.574 dB (current temperature 35.7 C)
lgw_receive:1313: INFO: nb pkt found:1 left:0
lgw_receive:1310: INFO: RSSI temperature offset applied: 1.564 dB (current temperature 35.5 C)
lgw_receive:1313: INFO: nb pkt found:1 left:0
lgw_receive:1310: INFO: RSSI temperature offset applied: 1.567 dB (current temperature 35.6 C)
lgw_receive:1313: INFO: nb pkt found:1 left:0
lgw_send:1340: --- IN
lgw_send:1474: --- OUT
lgw_receive:1310: INFO: RSSI temperature offset applied: 1.574 dB (current temperature 35.7 C)
lgw_receive:1313: INFO: nb pkt found:1 left:0
lgw_send:1340: --- IN
2021-09-11 08:46:51.028 [S2E:INFO] TX ::1 diid=50614 [ant#0] - dntxed: 867.7MHz 16.0dBm ant#0(0) DR5 SF7/BW125 frame=6090170B26850A000352FF00..4698E443
2021-09-11 08:46:51.069 [S2E:DEBU] Tx done diid=50614
2021-09-11 08:46:52.889 [SYN:INFO] MCU/SX130X drift stats: min: +0.0ppm q50: +2.6ppm q80: -11.4ppm max: +12.9ppm - threshold q90: -11.9ppm
2021-09-11 08:46:52.890 [SYN:INFO] Mean MCU drift vs SX130X#0: 0.2ppm
I told Dragino about this behaviour in their Google-Groups. Maybe someone from Dragino will read it and answer.
That is just a GUI thing of the webinterface. When I refresh the page I get to see new logs. Edit: gateway traffic graph stays empty indeed. But in theThingsStack I see normal traffic coming in.
I have tested Basics Station for about an hour now, and I seem to get all uplink messages and am also able to do downlink messages. I will keep the LIG16 configured as it is for now and see how it behaves on the long term.
1 Like
I am testing a LIG16. I flashed the newest firmware
OpenWRT 18.06, Version: Dragino-v2 lgw-5.4.1636008262, Build Thu Nov 4 14:44:22 CST 2021
I can join TTS-CE for both modes: UDP forwarder 1700 and basic station 443.
Now, i want to join a private TTS server but i can’t do it the… easy way.
This server has some Lorix one GW’s running fine and they join by basic station port 8887.
So, any use cases for LIG16 and private TTS servers ?
So, no one tried connecting to a LNS basic station port 8887 on a dragino LIG16 ?
There is a new firmware available from Dragino for LIG16. This one allows the user to provide his own server certificate so it’s usable for any TTS scenario.
https://www.dragino.com/downloads/index.php?dir=LoRa_Gateway/LIG16/Firmware/Release/
Latest is 2021-Dec-24
ChangeLog
===========
lgw–build-v5.4.1640315898-20211224-1120
*Add Iot_keep_alive Script interval setting
*Update the display of the helium page on GUI
*Reduce the gateway data traffic
*Fixed the loss of the gateway downlink queue
*Update the display of the Basic-Station page for TTN on GUI
1 Like
New fw seems stable. But also with this new firmware the gateway does not show traffic statistics when you use it in Basic Station mode. If I remember correctly someone already contacted Dragino about this months ago (@wolfp was that you?)
For now I reverted again to semtech udp.
I think you’re going to find that’s pretty common with Basic Station on most platforms. Whatever log scanning was used to capture it is expecting log messages from the UDP forwarder, while Basic Station would produce that information in a different format if at all.
New firmware, tested ok for LIG16.
GUI for gateway traffic does not show anything, don’t bother for that.
lgw–build-v5.4.1644990565-20220216-1352
*Add LPS8-N support
*Add AT&T disconnection detection
*Add Secondary LoRaWAN Server for Semtech UDP
*LPS8/LG308/DLOS8’s software of pkt_fwd iterates to fwd
*LPS8/LG308/DLOS8 supports the GUI of Gateway traffic
*Fixd fallback address lost after save WiFi setting
For me the new firmware version is not ok. There is still nothing shown in “Gateway Traffic” when you use BasicStation. I need to know what’s going on with my gateway without using the console.
Therefore I installed the new firmware using Semtech UDP.
Due to the differences between the UDP based packet forwarder and BasicStation that is unlikely to change anytime soon. So no need to report this every update.
1 Like
I see a lot of reboots on my LPS8, on average every 15 hours, and Basic Station freezes after a few days/weeks.
I updated it 2 weeks ago with the new firmware (16 Feb 2022 lgw-5.4.1644990565) and configured it for Basic Station, connected over WiFi. It ran fine for 2 weeks (lots of reboots) but froze yesterday. Completely unresponsive, no ping.
I had noticed the same issue on the previous firmware (24 Dec 2021), Basic Station freezing, so I switched back to UDP and that ran without freezing; lots of reboots but always coming back online. I wanted to give Basic Station a chance with the new firmware but it seems to reboot more often, and now it froze.
The only modification i made to the firmware is installing nano and a cron job that sends the uptime over MQTT SSL every 5 minutes. Earlier i had tried to avoid the freezes with watchcat (did not work), and directing the syslog to permanent storage to investigate post freeze but i did not find any errors.
Does anyone have similar reboot/freeze issues with Dragino gateways over WiFi?
My WiFi signal is not strong, but acceptable?
