Not getting timestamp when pps is disable in basic station

[AbhishekLakhara0209]

Hi,
I am getting issue that not getting timestamp in uplink frame with basic station wenever i disable the pps is disable in station.conf file. Also when pps is false at that time Gateway not sending any time sync request to server.

My station.conf file look like below.

{
/* If slave-X.conf present this acts as default settings /
“SX1301_conf”: { / Actual channel plan is controlled by server /
“lorawan_public”: true, / is default /
“clksrc”: 1, / radio_1 provides clock to concentrator /
**"pps":false,"**
/ path to the SPI device, un-comment if not specified on the command line e.g., RADIODEV=/dev/spidev0.0 /
/“device”: “/dev/spidev0.0”,/
/ freq/enable provided by LNS - only HW specific settings listed here /
“radio_0”: {
“type”: “SX1257”,
“freq”: 865400000,
“rssi_offset”: -166.0,
“tx_enable”: true,
“antenna_gain”: 0
},
“radio_1”: {
“type”: “SX1257”,
“freq”: 866385000,
“rssi_offset”: -166.0,
“tx_enable”: false
}
/ chan_multiSF_X, chan_Lora_std, chan_FSK provided by LNS /
},
“station_conf”: {
“routerid”: “xx:xx:xx:xx:xx:xx:xx”,
“euiprefix”: “::0”,
“log_file”: “~temp/station.log”,
“log_level”: “XDEBUG”, / XDEBUG,DEBUG,VERBOSE,INFO,NOTICE,WARNING,ERROR,CRITICAL */
“log_size”: 10000000,
“log_rotate”: 3,
“TC_TIMEOUT”: “2s”,
“gps”: “/dev/ttyUSB0”,
“pps”: “gps”,
“radio_init”:"/usrdata/reset_lgw.sh start",
“RADIO_INIT_WAIT”: “2s”
}
}

[beitler]

Could please provide more details on your setup and what you are trying to achieve?

• Which gateway are you using?
• Does your gateway have a GPS module and is deployed with sufficient skyview?
• What do you mean with 'timestamp in uplink frame'? There are multiple timestamps. Are you referring to the nanosecond-precision fine timestamp used for TDOA geolocation?
• What are the different configurations you are trying, what is your observation, and what would be your expectation for each of them? Could you please post examples of uplink messages for each case?
• Are you expecting that a fine timestamp is part of the uplink message although pps is set to false?

[AbhishekLakhara0209]

@beitler,

Which gateway are you using?

IMST Gateway. Raspberry pi as a host controller and SX1301 concentrator board.

Does your gateway have a GPS module and is deployed with sufficient skyview?

Yes

What do you mean with 'timestamp in uplink frame'?

I have attached the image of a frame.

What are the different configurations you are trying.

First of all i am talking about the pps field in radio configuration not in station configuration.

Test Case 1:
pps : false for radio configuration means pps capture is disable and "gps": "/dev/ttyUSB0", "pps": "gps", for station configuration
In this test we are not able to get time stamp as well as gateway not sending any time request.

Test Case 2:
pps : true for radio configuration means pps capture is enable and "gps": "/dev/ttyUSB0", "pps": "gps", for station configuration
In this test able to get time stamp as well as gateway sending time request.

Test Case 3:
pps : true for radio configuration means pps capture is enable and "gps": "/dev/ttyUSB0", "pps": "fuzzy", for station configuration
In this test able to get time stamp as well as gateway sending time request.

My main question is if we disable the pps capture then we will get the time stamp?

[AbhishekLakhara0209]

@beitler,
Any update on this?

[beitler]

Test Case 1:
pps : false for radio configuration means pps capture is disable and "gps": "/dev/ttyUSB0", "pps": "gps", for station configuration
In this test we are not able to get time stamp as well as gateway not sending any time request.

This is expected. With radio_conf.pps: false you are telling station that no PPS signal is available That means station will not try to acquire a GPS time fix.

Test Case 2:
pps : true for radio configuration means pps capture is enable and "gps": "/dev/ttyUSB0", "pps": "gps", for station configuration
In this test able to get time stamp as well as gateway sending time request.

With radio_conf.pps: true and station_conf.pps: gps station will try to establish GPS time synchronization using timesync message exchanges with the LNS.

Test Case 3:
pps : true for radio configuration means pps capture is enable and "gps": "/dev/ttyUSB0", "pps": "fuzzy", for station configuration
In this test able to get time stamp as well as gateway sending time request.

With station_conf.pps: fuzzy station will establish GPS time synchronization without locking to a PPS signal. The GPS time synchronization is directly provided by the LNS.

A more detailed explanation of the time synchronization aspects is contained in the documentation: https://doc.sm.tc/station/time.html

[AbhishekLakhara0209]

This is expected. With radio_conf.pps: false you are telling station that no PPS signal is available That means station will not try to acquire a GPS time fix.

As per this, we will not get gps fix time and received NULL value for all time related field as show image in my previous comment.
So do we required to handle any fallback time if we received NULL value for time field?

[beitler]

The image you included here is showing a message structure which does not originate from Basic Station directly. I am guessing this comes from a Chirpstack Network Server. You will have to check with Chirpstack on the meaning of these fields and how they are populated.
Do you have the corresponding original Basic Station message?

[AbhishekLakhara0209]

I am given that image for your reference.

Do you have the corresponding original Basic Station message?

you can see the original basic station message as below
{"msgtype":"updf","MHdr":64,"DevAddr":xxxxxxxx,"FCtrl":0,"FCnt":10,"FOpts":"","FPort":2,"FRMPayload":"B3354E4C7F7C4356CE207E51AF7C4F","MIC":-433357060,"RefTime":0.000000,"DR":0,"Freq":865062500,"upinfo":{"rctx":0,"xtime":7599824395191180,"gpstime":0,"fts":-1,"rssi":-109,"snr":-2.5,"rxtime":1613033399.383087}}

You can see the GPS time as 0.

[beitler]

gpstime:0 means that basic station is not synced to GPS time and thus is not able to provide the GPS time at which the frame is received. However, you are given rxtime:1613033399.383087 which is the receive timestamp in UTC time.

[AbhishekLakhara0209]

Ok i got the point.
Thanks for your support.

[beitler]

The documentation has been extended to include the information described in this post.

[AbhishekLakhara0209]

Hi @beitler ,

Thanks for the update.