Lorawan/band: unknown channel for frequency


#1

Hi, recently bought a dev kit from dragino with a LG01 (915) wit a lorashield and a loragps. I also installed a loraserver on a Ubuntu. I added my devices and set all my configuration on the web interface.
I am using a single channel which is 902300000 on my gateway.
Looking at my loraserver logs, I always see the same error:

level=error msg=“processing rx packet error: run uplink response flow error: get data down tx-info error: get rx1 frequency for uplink frequency error: lorawan/band: unknown channel for frequency: 902300000000000” data_base64=“QJ8dAiaAIAABPj78Due0CS1z/BVT8oWrKCwkhKmBI6g=”

Anyone has an idea ?


#2

That looks like you need to configure the correct band in the LoRa Server loraserver.toml. Please see https://www.loraserver.io/loraserver/install/config/


#3

My gateway is connected to the server.

Apr 25 12:24:10 loraserver[1252]: time=“2018-04-25T12:24:10-04:00” level=info msg=“backend/gateway: gateway stats packet received” mac=
Apr 25 12:24:10 loraserver[1252]: time=“2018-04-25T12:24:10-04:00” level=info msg=“gateway updated” mac=

Setting in loraserver.toml:

name=“US_902_928”


#4

Anyone as another idea ?? still get the same error.

level=error msg=“processing rx packet error: run uplink response flow error: get data down tx-info error: get rx1 frequency for uplink frequency error: lorawan/band: unknown channel for frequency: 902300000000000” data_base64=“QAgWAiaACgAByrVhQejt0nrl/R4HRaMGVFhVDtHh1M8=”

Settings in my dragino gateway is 902300000, setting in loraserver.toml:

name=“US_902_928”

I used the TTN sketch on my loragps and shield, it is working fine on TTN.

I got no clue right now…


#5

Can you copy your loraserver.toml here?
I’ve been workin with 902 all week and it works fine with 8 channels so I guess that it should work with just 1.


#6

I dont have access to my server right now but basically, the changes I ve made are the region setting(us_902_928), changed my dsn with my password, added my mtqq username and password. I basically followwed the quick setup guide. Also tried the enable channel but no luck, I reverted to the default for that setting. There might be something in shield amd loragps sketch ?


#7

Is it possible that you did not enable uplink channels?

There is a line in the config file that you have to set right.

enabled_uplink_channels=[0]
Something like that. Depends on the frequencies that are being used


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