search

CongducPham / LowCostLoRaGw

Low-cost LoRa IoT & gateway with SX12XX (SX1261/62/68; SX1272/76/77/78/79; SX1280/81), RaspberryPI and Arduino boards
694 stars 352 forks source link

Unable to receive length of bytes on the gateway with latest buster image #284

Open asprakash opened 4 years ago

asprakash commented 4 years ago

Hi, I modified and sending around 160 bytes of datas on the Arduino side.

I can able to receive the entire bytes without any issues on the gateway side, where as I am using RPI Zero W with older Jessie image. But I am not able to receive such length of datas when I am using latest buster image with RPI4. May I know if I need to modify anything on the gateway side to increase the receiving bytes size.

I also found few other issues on this latest buster image. 

#!/bin/bash

INTERFACES_NOT_AP_FILE=/etc/network/interfaces_not_ap
INTERFACES_AP_FILE=/etc/network/interfaces_ap
INTERFACES_FILE=/etc/network/interfaces

#if "interfaces_not_ap" exists, then replace current interfaces file by this one
if [ -f $INTERFACES_NOT_AP_FILE ]; 
  then
    sudo mv $INTERFACES_FILE $INTERFACES_AP_FILE
    sudo mv $INTERFACES_NOT_AP_FILE $INTERFACES_FILE
    sudo systemctl disable hostapd.service
    echo "The access point will be disabled at next reboot, using the file /etc/wpa_supplicant/wpa_supplicant.conf to connect to an access point."
  else
    echo "The access point is already disabled."
fi

TIA.

CongducPham commented 4 years ago

Hi, I don't see any reason for the message length issue you have. Let me try and get back to you.

Then for the WiFi, Buster uses a different system to setup interfaces. I remember testing with the web admin interface. Switching to wifi client must be done carefully as you need to check the SSID and password very carefully. You need to reboot.

asprakash commented 4 years ago

Thanks for your quick reply. Ok, I understand on the Buster OS side setup. I will look the right procedures and update you.

I tested by sending static datas of my all 160 bytes of datas. I am able to receive all of them. It confirms that it is not receiving size issue. But it is for downlink issue. The same data I am trying to receive after I send a downlink request. Now I am not receiving the same size of datas. The gateway log is as below,

2020-06-25T16:51:22.312579> {"status":"send_request","dst":6,"data":"/@Q1#"} 2020-06-25T16:51:22.312973> did not find device 0x00000006 in device key list 2020-06-25T16:51:22.313380> using AppSKey and NwkSKey from default device 2020-06-25T16:51:22.313776> post downlink: write 2020-06-25T16:51:22.314166> {"status": "send_request", "dst": 6, "MIC3": "0x69", "MIC2": "0x83", "MIC1": "0xd2", "MIC0": "0x25", "data": "/@Q1#"} 2020-06-25T16:51:22.314620> rcv ctrl radio info (^r): 125,5,12,0 2020-06-25T16:51:22.315025> splitted in: [125, 5, 12, 0] 2020-06-25T16:51:22.315406> (BW=125 CR=5 SF=12) 2020-06-25T16:51:22.315788> rcv timestamp (^t): 2020-06-25T16:51:22.303 2020-06-25T16:51:22.316174> 2020-06-25T16:51:22.316552> adding time zone info 2020-06-25T16:51:22.316931> new rcv timestamp (^t): 2020-06-25T16:51:22.303+02:00 2020-06-25T16:51:22.317317> got first framing byte 2020-06-25T16:51:22.317695> --> got LoRa data prefix 2020-06-25T16:51:22.318067> +++ rxlora[0]. dst=1 type=0x10 src=6 seq=8 len=160 SNR=5 RSSIpkt=-79 BW=125 CR=4/5 SF=12 2020-06-25T16:51:22.318632> valid app key: accept data 2020-06-25T16:51:22.319049> number of enabled clouds is 1 2020-06-25T16:51:22.319465> --> cloud[0] 2020-06-25T16:51:22.319907> uploading with python CloudThingSpeak.py 2020-06-25T16:51:22.320366> python CloudThingSpeak.py "TC/*INST,70,POSTPAID,00000010,12,50,04,04,05,19,000.00,000.00,000.00,00.000,00.000,00.000,+0.000,49.962,+000000,00000000,00000000,00000,0,000000.00,00000000,#" "1,16,6,8,160,5,-79" "125,5,12,0" "2020-06-25T16:51:22.303+02:00" "0000DCA632341378" 2020-06-25T16:51:22.532513> --> cloud end 2020-06-25T16:51:22.533334> 2020-06-25T16:51:32.608826> ----------------------------------------------------- 2020-06-25T16:51:32.609198> Check for downlink requests 2020-06-25T16:51:32 2020-06-25T16:51:32.609557> Read downlink 1: 118 2020-06-25T16:51:32.610072> Read downlink 2: -1 2020-06-25T16:51:32.610372> Queue all valid downlink requests 2020-06-25T16:51:32.610757> Downlink entry 1: {"status": "send_request", "dst": 6, "MIC3": "0x69", "MIC2": "0x83", "MIC1": "0xd2", "MIC0": "0x25", "data": "/@Q1#"} 2020-06-25T16:51:32.611081> status = send_request 2020-06-25T16:51:32.611418> dst = 6 2020-06-25T16:51:32.611700> data = /@Q1# 2020-06-25T16:51:32.612125> JSON record: {"status":"queued","dst":6,"MIC3":"0x69","MIC2":"0x83","MIC1":"0xd2","MIC0":"0x25","data":"/@Q1#"} 2020-06-25T16:51:32.612442> ----------------------------------------------------- 2020-06-25T16:51:34.079203> ----------------------------------------------------- 2020-06-25T16:51:34.079601> Process downlink requests 1: {"status": "send_request", "dst": 6, "MIC3": "0x69", "MIC2": "0x83", "MIC1": "0xd2", "MIC0": "0x25", "data": "/@Q1#"} 2020-06-25T16:51:34.080243> 2020-06-25T16:51:34.080550> status = send_request 2020-06-25T16:51:34.080915> dst = 6 2020-06-25T16:51:34.081251> data = /@Q1# 2020-06-25T16:51:34.081598> --> CAD duration 201 2020-06-25T16:51:34.081929> OK1 2020-06-25T16:51:34.082254> --> RSSI -127 2020-06-25T16:51:34.082591> Packet sent, state 0 2020-06-25T16:51:34.082917> JSON record: {"status":"sent","dst":6,"MIC3":"0x69","MIC2":"0x83","MIC1":"0xd2","MIC0":"0x25","data":"/@Q1#"}

But gateway is started receiving the next static datas without any issues, not receiving uplink data processed for downlink request.

Any kind of help is appreciated.

CongducPham commented 4 years ago

From what I see, the gateway is correctly sending the downlink message: "/@q1#"

asprakash commented 4 years ago

Yes, processing the downlink request is perfectly working and node also send the datas as per the downlink request. But the problem lies on gateway uplink message receiving side just next to the downlink request processed. As per my further testing, note this log,

2020-06-25T16:51:22.312973> did not find device 0x00000006 in device key list

This is crucial. Because only the uplink data not received next to the downlink request processed and the above error log might relevant to the next receiving data. Means, either the gateway wont accept the uplink data from Node 6 only next to downlink request processed or it wont process the data even it received since the node 6 is NOT in its device list, as per the log. Importantly, It happened only for the uplink data next to the downlink request processed.

May I know from where this did not find device 0x00000006 in device key list error generated?.

TIA

CongducPham commented 4 years ago

Hi, in non-lorawan downlink mode, when generating downlink.txt, post_processing_gw.py also generates the Message Integrity Code (MIC) for the downlink message. This process uses NwkSKey and AppSKey that can be defined in key_LoRaWAN.py (even for non-lorawan downlink). If you do not define a specific key, then the default key is used. When receiving the downlink message, the node can decide to check the MIC or to just ignore it. So this message "did not find device 0x00000006 in device key list" comes from decrypt_LoRaWAN.py module used by post_processing_gw.py. It is not an error message, just informative.

If you observed that the next uplink data from Node 6 only next to downlink request is not processed then it is another error. But can you confirm that you observed such error, check for instance the sequence number to see if you really miss a message.