Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Class B Beacons not working #129

Closed
gregbreen opened this issue Oct 26, 2021 · 4 comments
Closed

Class B Beacons not working #129

gregbreen opened this issue Oct 26, 2021 · 4 comments

Comments

@gregbreen
Copy link

Probably this is user error on my part, but I'm struggling to get Basic Station to send beacons. My router_config includes (for AU915):

"bcning":{"DR":8,"layout":[3,9,19],"freqs":[923300000,923900000,924500000,925100000,925700000,926300000,926900000,927500000]}

This results in:

Beaconing suspended for 10s - insufficient GPS data: time position

My gateway is a RAK2246G. This includes a UBLOX7 GPS.

Tracing back in the code, I see that gpstime, as returned from ts_xtime2gpstime, is always zero:

static void s2e_bcntimeout (tmr_t* tmr) {
    s2ctx_t* s2ctx = tmr->ctx;
    ustime_t now = rt_getTime();
    sL_t xtime = ts_ustime2xtime(0, now);
    sL_t gpstime = ts_xtime2gpstime(xtime);
    double lat, lon;
    int latlon_ok;
    ustime_t ahead;
    
    if( gpstime == 0 || !(latlon_ok = sys_getLatLon(&lat, &lon)) ) {
        // We don't have PPS or we are not yet time synced -- retry after a while
        ahead = rt_seconds(10);
        LOG(MOD_S2E|INFO, "Beaconing suspended for %~T - insufficient GPS data: %s %s",
            ahead, gpstime==0?"time":"", latlon_ok?"position":"");
        rt_setTimer(tmr, now + ahead);
        return;
    }

I also see in gps.c that UBLOX7 support is omitted by default (CFG_ubx). There is the comment:

We don't need UBX to operate station - we get time from server

Tracing back further, it seems that ppsSync.pps_xtime is always zero, and this should be updated by the timesync message exchange. But Basic Station is not sending timesync messages. Instead the ts_updateTimesync() function exits at line 256:

    // We update ppsSync only if we have two consecutive time syncs with valid PPS timestamps
    // and if they are apart ~1s - we might be weird values if no PPS pulse occurred during time sync span.
    if( !last->pps_xtime || !curr->pps_xtime )
        goto done;

I have not dug further yet because the rabbit hole keeps going down. What is the status of Class B beacon support? I currently have PPS set to "fuzzy" in station.conf. Is this right? If not, what should the config be?

I tried to use my GPS, by enabling CFG_ubx, but this doesn't seem to set ppsSync.pps_xtime anywhere anyway.

@gregbreen
Copy link
Author

I think answers are here: #98

@beitler
Copy link
Contributor

beitler commented Oct 27, 2021

Hi @gregbreen,

Your error message

Beaconing suspended for 10s - insufficient GPS data: time position

Indicates that time and position are not properly configured.

Thanks for referencing #98. Indeed, for class B beacon operation, proper time synchronization is required. The parameters radio_conf.pps and station_conf.pps are used to control the time synchronization.

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.

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.

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.

For class B beacons the typical scenario would be the availability of a GPS receiver and PPS signal. Hence, radio_conf.pps: true and station_conf.pps: gps are the right set of paramters.

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

@gregbreen
Copy link
Author

Thanks! Better:

2021-10-28 13:28:14.005 [S2E:INFO] TX ::0 diid=0 [ant#0] - on air: 923.3MHz 0.0dBm ant#0(0) DR8 SF12/BW500 frame=0000000068A54E7900000000..00000000

So far, I couldn't get my device to lock to the beacon. Probably another user error.

@gregbreen
Copy link
Author

@beitler I want to run something past you to see if you have any tips. Example beacon transmission:

2021-11-02 05:47:25.198 [S2E:DEBU] ::0 diid=0 [ant#0] - next TX start ahead by 801ms364us
2021-11-02 05:47:25.980 [S2E:VERB] ::0 diid=0 [ant#0] - starting TX in 19ms866us
2021-11-02 05:47:26.005 [S2E:INFO] TX ::0 diid=0 [ant#0] - on air: 927.5MHz 0.0dBm ant#0(0) DR8 SF12/BW500 frame=0000008093AB4E9400000000..00000000
2021-11-02 05:47:26.289 [S2E:DEBU] Tx done diid=0

And corresponding attempt, and failure, to receive and lock by an ST Nucleo-WL55JC1 (running LoRaMAC):

1635832009s152:LoRaMacClassBProcessBeacon() IN BEACON_STATE_ACQUISITION_BY_TIME
1635832009s152:LoRaMacClassBProcessBeacon() OUT BEACON_STATE_ACQUISITION_BY_TIME
1635832063s995:LoRaMacClassBProcessBeacon() IN BEACON_STATE_ACQUISITION_BY_TIME
1635832064s011:RX_BC on freq 927500000 Hz at DR 8 RxTime=2120
1635832064s011:LoRaMacClassBProcessBeacon() OUT BEACON_STATE_ACQUISITION_BY_TIME
1635832064s075:IRQ_RX_TX_TIMEOUT
1635832064s075:MAC rxTimeOut
1635832064s078:LoRaMacClassBProcessBeacon() IN BEACON_STATE_ACQUISITION_BY_TIME
1635832064s089:LoRaMacClassBProcessBeacon() OUT BEACON_STATE_LOST
1635832064s092:LoRaMacClassBProcessBeacon() IN BEACON_STATE_LOST
1635832064s093:temp= 23
1635832064s093:LoRaMacClassBProcessBeacon() OUT BEACON_STATE_ACQUISITION

The RX_BC message is printed just as it's about to turn the receiver on to try to receive the beacon. Correct channel and DR. The IRQ_RX_TX_TIMEOUT 64 milliseconds later is the expiry of the 8 symbol window time. So it seems nothing was received during that time.

From the Basic Station point of view, if I have the GPS going and beacons transmitting, is there any reason why it would not be accurate enough to land in that 64ms window?

Just watching both terminals, they both print this stuff out at the same time (to human perception). So if it's just a timing mismatch, it's small. I've tried increasing and moving the window, all to no avail.

beitler added a commit that referenced this issue Jan 31, 2022
* deps: Updated sx1302_hal dependency to version 2.1.0 (no LBT yet) (Resolves #89, #103, #121, #130)
* deps: Added sx1302_hal patch for handling of latched xticks rollover
* deps: Updated mbedTLS dependency to version 2.28.0 (LTS)
* deps: Fixed lgw patch causing IQ inversion in 500kHz channel (Resolves #81)
* s2e: Added support for AU915 (Resolves #43)
* s2e: Added support for LoRaWAN Regional Parameters Common Names (Resolves #18)
* s2e: Fixed dnchnl2 issue (Resolves #79)
* s2e: Fixed class C backoff logic (Resolves #87)
* s2e: Fixed class B beacon format (Resolves #129, #131)
* s2e: Fixed DR range check in upchannels list parser (Resolves #141)
* ral: Changed handling of xticks for lgw1302
* ral: Fixed radio in use issue (Resolves #53, #62)
* ral: Fixed types in txpow assignment (master/slave) (Resolves #118)
* ral: Fixed class B beacon parameters (Resolves #132)
* sx130xconf: Fixed parsing of rssi_tcomp values for sx1302 (Resolves #144)
* tls: Fixed TLS cert parsing issue (Resolves #76)
* sys_linux: Added support for usb/spi prefix in radio devname
* sys_linux: Added mbedTLS version to startup log
* sys_linux: Changed version to be printed to stdout (Resolves #51)
* sys_linux: Changed default max dbuf size (Resolves #95)
* sys_linux: Fixed relative home path handling (Resolves #140)
* sys_linux: Fixed memory corruption during system command execution (Resolves #146)
* tc/cups: Fixed sync on credset file IO (Resolves #94)
* timesync: Fixed UTC to PPS alignment
* log: Changed verbosity of XDEBUG log level
* log: Changed logging experience for improved clarity
* log: Added HAL log integration into logging module
* make: Changed makefiles for more space-friendliness (Resolves #66)
* net: Changed strictness on line-endings in key files (Resolves #68)
* gps: Fixed parsing of ublox NAV-TIMEGPS message
* Restored LICENSE file (Resolves #63, #67)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants