Lorawan/band: unknown channel for frequency


#8

I think i ve tried that already but with 0, 1, etc. I will test it out again monday and report back.


#9

In my gateway, settings are:
rx frequency: 902300000

My settings are as followed:
name=“US_902_928”
enabled_uplink_channels=[0]

Doing some test right now.


#10

#LoRaWAN network related settings.
[network_server.network_settings]
#Installation margin (dB) used by the ADR engine.

#A higher number means that the network-server will keep more margin,
#resulting in a lower data-rate but decreasing the chance that the
#device gets disconnected because it is unable to reach one of the
#surrounded gateways.
installation_margin=10

#Class A RX1 delay

#0=1sec, 1=1sec, … 15=15sec. A higher value means LoRa Server has more
#time to respond to the device as the delay between the uplink and the
#first receive-window will be increased.
rx1_delay=1

#RX1 data-rate offset

#Please consult the LoRaWAN Regional Parameters specification for valid
#options of the configured network_server.band.name.
rx1_dr_offset=0

#RX2 data-rate

#When set to -1, the default RX2 data-rate will be used for the configured
#LoRaWAN band.

#Please consult the LoRaWAN Regional Parameters specification for valid
#options of the configured network_server.band.name.
rx2_dr=-1
#RX2 frequency

#When set to -1, the default RX2 frequency will be used.

#Please consult the LoRaWAN Regional Parameters specification for valid
#options of the configured network_server.band.name.
rx2_frequency=-1

#Enable only a given sub-set of channels

#Use this when ony a sub-set of the by default enabled channels are being
#used. For example when only using the first 8 channels of the US band.

#Example:
#enabled_uplink_channels=[0, 1, 2, 3, 4, 5, 6, 7]
enabled_uplink_channels=[0, 1, 2, 3, 4, 5, 6, 7]

That is my band configuration


#11

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.


#12

…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=”


#13

That frequency doesn’t look right (too many digits). 902.3MHz = 902,300,000Hz. Not 902,300,000,000,000 (Hz?).


#14

Thats what I noticed too… No where I’ve I entered that much 0’s…somehow somewhere something is added that value.


#15

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 … ?


#16

Report this as a LG01 bug as it is not compatible with the Semtech packet-forwarder protocol? :slight_smile:


#17

Looking into the gateway to see if there is a way to mod it…


#18

… it could be a LG01 bug… but just have a question in my mind right now… why is it working with TTN network ???


#19

Exactly, I was asking myself the same question.


#20

It could be that they created a workaround, e.g. when frequency higher than X assume it is Hz else assume it is MHz?


#21

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…


#22

Testing right now with the changes…


#23

Did the changes on the LG01, so far I dont see anything from my nodes…


#24

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.


#25

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.


#26

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.

  1. 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.

  2. 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

  3. cd openwrt-cc-15.05

  4. run this shell script ./set_up_build_environment.sh (this command will clone the source code of Dragino including lg01_pkt_fwd package)

  5. 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.

  6. 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…


Dragino LG01-P as Gateway
#27

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!