I actually have data coming in, but still the same error on the loraserver journal about unknown channel for frequency: 902300000000000"
For my loragps, the error is Event payload, type: CODEC, error: “js vm error: ReferenceError: ‘Decode’ is not defined”
Might be related to paylaod decoder function.
…payload decoder function… maybe… same error on my side…
same node same config with two different GW (1 = pycom nano gateway, 2 = LG01)…
********** PYCOM - GW (nano gateway) **********
4/29/2018, 12:24:09 AMnode: 66c8f101.9f79e
gateway/240ac4fffe07315c/rx : msg.payload : Object
object
rxInfo: object
mac: “240ac4fffe07315c”
time: “2018-04-29T04:24:09.390085Z”
timestamp: 211137343
frequency: 902300000
channel: 0
rfChain: 0
crcStatus: 1
codeRate: “4/5”
rssi: -85
loRaSNR: 6
size: 56
dataRate: object
board: 0
antenna: 0
phyPayload: “QH0UASYABAMCroKVPPJFoRE/Q+LPvlYn8bjbBYk3T8Y0gHufzv7WSi6ItAZ0WWsBMeASseTcbQk=”
*********** LG01 - GW ***********************
4/29/2018, 12:24:11 AMnode: 66c8f101.9f79e
gateway/a8404118c048ffff/rx : msg.payload : Object
object
rxInfo: object
mac: “a8404118c048ffff”
time: “2018-04-29T04:24:11.67425Z”
timestamp: 468589269
frequency: 902300000000000
channel: 7
rfChain: 0
crcStatus: 1
codeRate: “4/5”
rssi: -89
loRaSNR: 7.8
size: 56
dataRate: object
board: 0
antenna: 0
phyPayload: “QH0UASYABAMCroKVPPJFoRE/Q+LPvlYn8bjbBYk3T8Y0gHufzv7WSi6ItAZ0WWsBMeASseTcbQk=”
That frequency doesn’t look right (too many digits). 902.3MHz = 902,300,000Hz. Not 902,300,000,000,000 (Hz?).
Thats what I noticed too… No where I’ve I entered that much 0’s…somehow somewhere something is added that value.
here is the root cause… from a UDP debug session we can see that LG01 is transmitting the frequency in HZ not in MHz, if we compare to the Raspberry GW:
PACKET UDP - RASPBERRY GW
20:39:34.962077 IP raspberrypi.NET0000.34797 > LORAS2.NET0000.1700: UDP, length 244
E…@.@…d…’…3 .{“rxpk”:[{“tmst”:878095390,"**freq":902.3,"**chan":0,“rfch”:0,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“rssi”:-66,“lsnr”:9.0,“size”:56,“data”:“QH0UASYAcgYCuWWOagYcVVKPBVHAWYQRvZJwwPd+FEXqald54+nmTCkMI8Mcya1/i8VakOrwKZA=”}]}
20:39:34.963025 IP LORAS2.NET0000.1700 > raspberrypi.NET0000.34797: UDP, length 4
PACKET UDP - LG01 GW
20:39:35.400504 IP dragino-18c048.NET0000.46586 > LORAS2.NET0000.1700: UDP, length 285
E…9…@.@…~…%…n…@A…H…{“rxpk”:[{“tmst”:878533759,“time”:“2018-05-01T00:39:35.408693Z”,“chan”:7,“rfch”:0,"freq":902300000,“stat”:1,“modu”:“LORA”,“datr”:“SF7BW125”,“codr”:“4/5”,“lsnr”:7.8,“rssi”:-86,“size”:56,“data”:“QH0UASYAcgYCuWWOagYcVVKPBVHAWYQRvZJwwPd+FEXqald54+nmTCkMI8Mcya1/i8VakOrwKZA=”}]}
20:39:35.401143 IP LORAS2.NET0000.1700 > dragino-18c048.NET0000.46586: UDP, length 4
According to Semtech:
RXPK:
freq | number | TX central frequency in MHz (unsigned float, Hz precision)
… in the source code:
**source code : lora-gateway-bridge / internal / gateway / pf_structs.go **
line 507…: Frequency: int(rxpk.Freq * 1000000),
line 554…: Freq: float64(txPacket.TXInfo.Frequency) / 1000000,
Source code for RXPK:
rxPacket := gw.RXPacketBytes{
PHYPayload: b,
RXInfo: gw.RXInfo{
MAC: mac,
Timestamp: rxpk.Tmst,
Frequency: int(rxpk.Freq * 1000000),
Channel: int(rxpk.Chan),
RFChain: int(rxpk.RFCh),
CRCStatus: int(rxpk.Stat),
DataRate: dataRate,
CodeRate: rxpk.CodR,
RSSI: int(rxpk.RSSI),
LoRaSNR: rxpk.LSNR,
Size: int(rxpk.Size),
Board: int(rxpk.Brd),
},
}
Frequency: int(rxpk.Freq * 1000000),
UDP from RASPBERRY GW…: freq = 902.3 * 1000000 = 902300000
UDP from LG01…: freq = 902300000 * 1000000 = 902300000000000
so we obtain the frequency that doesn’t look right, too many digits.
… what’s the solution now … ?
Report this as a LG01 bug as it is not compatible with the Semtech packet-forwarder protocol? 
Looking into the gateway to see if there is a way to mod it…
… it could be a LG01 bug… but just have a question in my mind right now… why is it working with TTN network ???
Exactly, I was asking myself the same question.
It could be that they created a workaround, e.g. when frequency higher than X assume it is Hz else assume it is MHz?
Hi redpotatoes
made some progress…
Start LoRaWAN Single Channel Gateway
RX Frequency: 902.30
TX Frequency: 923.00
Spread Factor: SF7
connected!
TX Spread Factor: SF7
Coding Rate: 4/5
Bandwidth: 125000
PreambleLength: 8
connected!
but still having some issue, can you complete some testing on your side with these changes:
you have to apply these changes to the Single_pkt_fwd_v003.ino sketch like this:
Modification to single_pkt_fwd_v003
//Read frequency from uci ####################
int j = 0;
memset(tmp, 0, sizeof(tmp));
p.begin("uci");
p.addParameter("get");
p.addParameter("lorawan.radio.rx_frequency");
p.run(); // Run the process and wait for its termination
while (p.available() > 0 && j < 9) {
tmp[j] = p.read();
j++;
}
freq = atof(tmp);
freq = freq/1000000; //add this line into single_pkt_fwd
//Read txfre from uci ####################
j = 0;
memset(tmp, 0, sizeof(tmp));
p.begin("uci");
p.addParameter("get");
p.addParameter("lorawan.radio.tx_frequency");
p.run(); // Run the process and wait for its termination
while (p.available() > 0 && j < 10) {
tmp[j] = p.read();
j++;
}
txfreq = atof(tmp);
txfreq = txfreq/1000000; //add this line into single_pkt_fwd
let me know what’s the result on your side…
Did the changes on the LG01, so far I dont see anything from my nodes…
Hi Brocaar,
That’s just to give you a heads-up on that LG01 hz frequency vs Mhz.
I completed some testing with the modification I did to the lg01_pkt_fwd and LG01 is now working in UPLINK and DOWNLINK mode with the server.
I’m also in contact with Edwin from Dragino and will try push to include this mods to the LG01_pkt_fwd …
Will see what we can do to close this isssue.
Thx.
ric2498, can you please explain how did you get this issure resolved on the LG01? the modifications to the Single_pkt_fwd_v003.ino sketch you provided does not work.
Hi,
This is what I did to update the lg01_pkg_fwd (package), and by the way my first test with the lg01_pkt_fwd.ino sketch for arduino to fix the problem, was not the solution to this problem, as it is mentionned above.
I took the decision to follow the instruction provided by Dragino to build an updated firware containing the lg01_pkt_fwd (package) running into linux in the LG01.
By this link (https://github.com/dragino/openwrt-cc-15.05) you can get all the instructions to create the environment, which I followed to create a virtual machine running Ubuntu LTS 16.04 and then cloning the openwrt-cc-15.05 github source code with the command: git clone https://github.com/dragino/openwrt-cc-15.05.git openwrt-cc-15.05
cd openwrt-cc-15.05
run this shell script ./set_up_build_environment.sh (this command will clone the source code of Dragino including lg01_pkt_fwd package)
the source code is now residing into /openwrt-cc-15.05/openwrt/feeds/dragino/lg01_pkt_fwd/src/main.c; which I modified to change the frequency in Mhz before to build the firmware by the next step.
Some manipulation of the .config.IoT file must be done before to execute the next step, if you need it I can provide more details.
7 ./build_image.sh -a IoT
Voila…
you can use this link to see the lg01_pkt_fwd source code that must be modified:
Also as I said I’m trying to push this update to Edwin from Dragino to include this mod into a new firmware… but I can’t guarantee it…
Hey - thanks for the note. I was suspecting the way to fix this was editing the lg01-pkt-fwd souce and recompiling, your note confirmed it.
Thanks for the source code I’m going to re-build the utility right away!
Hi,
Do you know if any of the latest firmware negated the need for any config modifications?
I am running:
OpenWRT Chaos Calmer 15.05
Version: Dragino-v2 IoT-4.3.7
Build Wed Sep 11 22:30:26 CST 2019
I connected this to my lora network server and it has shown up in chirpstack. All I did however was update the firmware on the Dragino LG01 P.
Do you know if I have to uypdate the packet forwarder on the gateway?
I have seen this post: https://www.chirpstack.io/gateway-bridge/gateway/dragino/ however this is for a different version of the gateway… could you provide any guidance? I am just waiting for some new batteries for a ABP node to test… Any help would be greatly appreciated…
Hi,
No I don’t, I’m not using it anymore.
Regards.
my system works fine with TTN .I also have the same system LoRa IoT Development kit v1.4 from Dragino with LG01-N gateway. Have you succeed to connect with ChirpStack server ? I also need to go further with this system.
TTN prevents/denies Single Channel Gateway (SCG) for connecting to its server beacuse this gaeway is not fully match and disturbs other fully loRawan gateways,which comes with 8 channels.