TBeam will not accept JOIN-ACCEPT without GPS lock

[ab0oo]

I have several TBeam 1.1 devices running ttgo-tbeam-ttn-tracker, which work well, eventually. The problem I'm seeing is that the device will not accept (apparently, doesn't even receive) the JOIN-ACCEPT message from the TTN server until after GPS lock is acquired. I run my own basicstation gateway, so I can see every step in the process:

• when I power the TBeam on with all prefs/keys cleared, it will power up and begin sending correctly formatted join requests
• the TTN NWS gets the request, validates that the DevEUI is correct and the APPKEY is valid, and schedules a downlink on my basestation, which gets transmitted (I've verified that with a spectrum analyzer)
• the TBEAM either ignores/doesn't hear the downlink and sends another join-request within 15-20 seconds, ad nauseum
• as SOON as the TBeam gets GPS lock, it 'magically' hears the join-accept, writes the correct data to Preferences, and starts merrily reporting its position.

It's probable that I do not completely understand the OTAA conversation, and accurate time is part of the initial key exchange. In this case, what can I do to prevent the TBeam from even sending join-requests until it has correct time? If I fire one of these suckers up in the house, where there's no GPS signal, it will literally go for HOURS sending join-requests and merrily ignoring the response.

I'm using the master (1.2.1) branch and current libraries. Logs available, if anyone wants to see them, but I'm not sure what to include initially, so I'll wait for someone to ask.

Thank you. John Gorkos

[ab0oo]

It's a clock error of some sort. Adding the following two defines worked: in configuration.h

define CLOCK_ERROR 10

and in platformio.ini [env:esp32] ... -D LMIC_ENABLE_arbitrary_clock_error=1 -D LMIC_DEBUG_LEVEL=2 -D LMIC_PRINTF_TO=Serial ...

The debug and printf are not necessary, but they helped me see what was going on. Couldn't hurt to add it if you're struggling. I'm not an export in platformio, but it didn't seem like these parameters were picked up whtn I included them in the [arduino_base] build_flags, just when I moved them to [env:esp32]. I'm also building in VSCode, using platformio. I have not experimented with CLOCK_ERROR values smaller than 10 to see just what the threshold is.

I have seen a weird message about highly inaccurate crystal frequency (Expected 40.00Mhz, got 41.01MHz), which might account for the RX window timing being off. It shows up during the binary upload through the serial port: Chip is ESP32-D0WDQ6-V3 (revision 3) Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None WARNING: Detected crystal freq 41.01MHz is quite different to normalized freq 40MHz. Unsupported crystal in use? Crystal is 40MHz FWIW, the markings on my board indicate: T22_V1.1 20210222 with a NEO 6M Ublox GPS. I'm using 915MHz in the US.

I'll leave this issue open for a day or two to see if anyone wants to comment, and then close it.