[SOLVED] gateway: could not handle packet: json: cannot unmarshal number into Go value of type uint32

[litrium]

Hi, I'm trying to configure a Lora server in my PC, and already installed mosquitto and the lora-gateway-bridge. As shown in the log, It's receiving the Keepalive and stat packets sent from the gateway OK but when data is sent from the modules, I always get this error:

level=error msg="gateway: could not handle packet: json: cannot unmarshal number 473387129083000 into Go value of type uint32"

the value 473387129083000, is the 'tmst' parameter, as shown in the output of the python script for reading data received from the packet-forwarder gateway.

tmst = number | Internal timestamp of "RX finished" event (32b unsigned)

Python script output:

Data received from Gateway: xx:xx:xx:6D:7D

{u'rxpk': [{u'stat': 1, u'modu': u'LORA', u'lsnr': 7.0, u'chan': 0, u'datr': u'SF7BW125', u'tmst': 473386384150000L, u'codr': u'4/5', u'rfch': 1, u'time': u'2015-01-01T00:13:04.000000Z', u'rssi': -40, u'freq': 868.3, u'data': u'gLgCAGAADgACQ0FGRd6mSaA=', u'size': 17}]}

{u'stat': 1, u'modu': u'LORA', u'lsnr': 7.0, u'chan': 0, u'datr': u'SF7BW125', u'tmst': 473386384150000L, u'codr': u'4/5', u'rfch': 1, u'time': u'2015-01-01T00:13:04.000000Z', u'rssi': -40, u'freq': 868.3, u'data': u'gLgCAGAADgACQ0FGRd6mSaA=', u'size': 17}

Lora-gateway-bridge Log:

time="2017-05-09T13:33:04+02:00" level=info msg="gateway: stat packet received" addr=10.10.1.238:15555 mac=xxxxxx6d647d0000 time="2017-05-09T13:33:04+02:00" level=info msg="backend: publishing packet" topic="gateway/xxxxxx6d647d0000/stats" time="2017-05-09T13:33:04+02:00" level=info msg="gateway: sending udp packet to gateway" addr=10.10.1.238:15555 protocol_version=1 type=PushACK time="2017-05-09T13:33:08+02:00" level=info msg="gateway: received udp packet from gateway" addr=10.10.1.238:15555 protocol_version=1 type=PullData time="2017-05-09T13:33:08+02:00" level=info msg="gateway: sending udp packet to gateway" addr=10.10.1.238:15555 protocol_version=1 type=PullACK time="2017-05-09T13:33:23+02:00" level=info msg="gateway: received udp packet from gateway" time="2017-05-09T13:33:33+02:00" level=info msg="gateway: received udp packet from gateway" addr=192.168.10.26:15555 protocol_version=1 type=PushData

time="2017-05-09T13:33:33+02:00" level=error msg="gateway: could not handle packet: json: cannot unmarshal number 473387129083000 into Go value of type uint32" addr=192.168.10.26:15555 data_base64=ARRVANiAOW1kfQAAeyJyeHBrIjpbeyJ0bXN0Ijo0NzMzODcxMjkwODMwMDAsInRpbWUiOiIyMDE1LTAxLTAxVDAwOjI1OjI5LjAwMDAwMFoiLCJjaGFuIjowLCJyZmNoIjoxLCJmcmVxIjo4NjguMzAwMDAwLCJzdGF0IjoxLCJtb2R1IjoiTE9SQSIsImRhdHIiOiJTRjdCVzEyNSIsImNvZHIiOiI0LzUiLCJsc25yIjo3LjAsInJzc2kiOi0zNSwic2l6ZSI6MTcsImRhdGEiOiJnTGdDQUdBQUZRQUNRMEZHUmVMeVpQaz0ifV19

I don't know why this 'tmst' value is so big and does not allocate in the size of the uint32 variable. It's automatically generated, so, it should comply....

I'm using Nemeus MK002 module and MG003-EU-1.1 gateway configured as packet forwarder.

Any help would be appreciated, Thanks in advance.

[brocaar]

I don't have any experience with this gateway, but the value does not seem right. The tmst represents the gateway internal timestamp (not related to an actual timestamp as in a day of the year, hour of the day), which is used by the network-server / LoRa Server to schedule downlink transmissions.

This value is supposed to be 32bit, meaning that the max value = 2^32=4.294.967.296 - 1. The value that the LoRa Gateway Bridge received from your gateway is exceeding this max value, so it seems not to be a 32bit integer.

I think this could be related to a bug in the firmware of your gateway. Are you able to mention this issue to the manufacturer / supplier of this gateway?

Could you also make sure that your gateway is running the latest firmware version?

[litrium]

Hi brocaar, many thanks thanks for your fast reply.

I have contacted with the manufacturer already. I thought that is was a gateway bug too. Here is the answer:

" In fact our tmst field is not on 32 bits but on 64 bits. It is absolute time since 01/01/2000 00h00. The precision of the gateway is the millisecond, "000" is concatenated to be in microseconds. "

I understand the gateway does not comply with the specification at this point, but I'm have not access to modify it. Any work around for dealing with this?

About the firmware version, I'm sending the gateway to the manufacturar so as to update it. In the new version they embbed a Lora Network server too, among the packet forwarder.

I will tell you when I have news,

Kind regards,

[brocaar]

I understand the gateway does not comply with the specification at this point, but I'm have not access to modify it. Any work around for dealing with this?

It will be better when this is fixed at the gateway side. LoRa Server makes use of the int32 overflow property, e.g. when (timestamp + delay) >= 2^32, it starts counting at 0 again. It will be hard to make an exception for special brands. Did they tell you why they follow a different implementation?

[litrium]

No, they only told me what I quoted in my last post. I sent the gateway to factory for upgrading and It's travelling back to me right now. When I receive it back, I will tell you if the problem has been solved.

[litrium]

Hi brocaar. The issue was solved. Nemeus support guys were very kind helping me with that, and they modified the firmware so as to adapt the 'tmst' value to a 32 bit integer. Regards,

[S0UL4]

@litrium hello bro . i have same problem could you please help with that ? or provide me with the modified firmware ??