HTTP Integration POST JSON Data has no time property

Hi, brocaar. I have configed a HTTP Integration Endpoint: Uplink data URL

and received data like below, but I found no property related to data’s time,

“applicationID”: “1”,
“applicationName”: “rimelink_demo”,
“deviceName”: “test-node-02”,
“devEUI”: “323436470147003a”,
“rxInfo”: [
“mac”: “b827ebfffe3ef775”,
“rssi”: -79,
“loRaSNR”: 8.8,
“name”: “rimelink-demo-frist”,
“latitude”: 0,
“longitude”: 0,
“altitude”: 0
“txInfo”: {
“frequency”: 487900000,
“dataRate”: {
“modulation”: “LORA”,
“bandwidth”: 125,
“spreadFactor”: 7
“adr”: true,
“codeRate”: “4/5”
“fCnt”: 12345,
“fPort”: 200,
“data”: “QV+uFEKe4cxBJ6Hz”

Please see the documentation:

"time": "2016-11-25T16:24:37.295915988Z",  // time when the package was received (GPS time of gateway, only set when available)

If your gateway does not have a GPS fix, there will not be any time object in the JSON.

1 Like

Thank you! I understand it’s mean now. when GPS time of gateway is not available, time property will not appear 。

Said nothing, It can be faked with fake_gps.

Edit: Seems to not be working, but it is probably the lora_pkt_fwd that is included in the Conduit. Said something about autoselecting if the device does not detect a GPS, so far not working. Will check with the outdoors version.

Not working with the other conduit I have.

Neither of them transmit the Time only timestamp. It seems to be empty, the only thing I can see is that they are using “protocol: 2”.

Here is a packet from the mosquitto log, after it has been parsed by bridge

Any one have this version of conduit and has the same problem? Will ask too in Multitech forum and post here the answer.

Multitech Conduit AEP 1.4.4 SPI version, have the outdoors version with GPS and the indoors version without it.


EDIT: I have old versions of conduit without GPS and they DO transmit the time. I dont understand anything.
Old version packet:

Make sure your gps_tty_path is set to the correct path of the GPS device. Else you have GPS, but the packet-forwarder won’t use it :wink: (the value is just an example, it needs to match the path on the Conduit!).

You might be interested in:

I really don’t understand the behaviour of this gateway.

The other 3 (old version without GPS) work perfectly fine with the time. New ones no.

Will retry to configure GPS (was already configured) and see if there is any update to the system.
Will try to convince my boss to try your Yocto in hope to get them working.


Here is the answer. Seems that new packet forwarder does not add the time unless there is a valid GPS.

We decided to edit packet forwarder.

I know that you have more experience with this. So I have a little question.

We compiled the new packet forwarder and everything went pretty well, but we have a problem when we try to execute it. Seems that does not find the concentrator.

Do I have to compile it in a special way? I don’t know how to “select” the SPI. It worked with our RisingHF gateway, but Yocto is pretty new to us.

We simply forked the lora packet forwarder.


EDIT: Seems to me that the spi link is not working properly, something I’m missing.
EDIT2: Working with the big one (outdoors) not working with the indoor version.
Last EDIT: Working in both versions, seems that AP Conduit has an older version of the FPGA that have to be added to HAL.


why is GPS needed in order to populate the time? why cant just use the gateway internal time?

See the gateway bridge configuration page to configure it to use gateway time.

1 Like