X9D+ Telemetry lost briefly when SD card starts LOG.

[Fpv191]

Is there an existing issue for this problem?

• I have searched the existing issues

What part of EdgeTX is the focus of this bug?

Transmitter firmware

Current Behavior

Brief telemetry loss when logging starts (X9D+)

Logging is configured with a 3-second delay after arming. When logging begins, telemetry drops briefly, triggering a momentary "Telemetry Lost" / "Telemetry Recovered" warning.

Occurs on the first battery after power-up and on every subsequent battery, with both Internal RF and External Module models.

The same setup previously on 2.10.6 did not exhibit this behavior.
2.10.6: No issue
2.11.2: Issue introduced
2.11.6: Issue persists
2.12.2: Issue persists

Were there any changes to telemetry timing, task scheduling, or SD card logging/resource sharing between 2.10.6 and 2.11.x that could explain this?

Expected Behavior

• Arm model
• SD Card to start a log after programmed 3s
• No Telemetry Data Stream loss interruption / disappearing or warnings the moment when LOGS initialize.

Steps To Reproduce

Arm model with SD card logs enabled in Special Functions with 3s delay.
(setting 0s delay doesn't fix the Telemetry Data Stream loss interruption.)

Version

2.12.2

Transmitter

FrSky X9D+, FrSky X9D+2019

Operating System (OS)

No response

OS Version

No response

Anything else?

Additional unrelated observation (changed since 2.10.6):

2.10.6: Holding Exit for ~2 seconds in the ELRS Lua script exited to the Tools menu briefly, then continued to the model main screen without another button press.
2.12.2: Exits only to Tools. A second Exit press is now required to reach the model main screen; holding Exit no longer performs the previous behavior.

The new Quick Model Select feature in 2.12.2 saves an Exit press when changing models, but exiting the ELRS Lua script now requires an extra Exit press.

[Fpv191]

Update: Additional findings

The issue was traced to the size of the LOGS directory.

My original LOGS directory contained approximately 2,250 log files (157 MB total). Renaming it to OLDLOGS and creating a new empty LOGS directory completely eliminated the telemetry loss when logging starts.

However, this same large LOGS directory worked without issue on EdgeTX 2.10.6, but on 2.11.2, 2.11.6, and 2.12.2. consistently caused the brief telemetry interruption.

This suggests a regression in how log files are created or how large FAT directories are handled during logging startup, particularly on the X9D+.

[raphaelcoeffic]

Thanks for the detailed report and especially for narrowing it down to the size of the LOGS/ directory — that was the key clue.

Root cause

Log files are opened lazily from logsWrite(), which runs on the FreeRTOS timer daemon task. Telemetry frame polling runs on that same task. When LOGS/ is large, creating the new log file (f_open with FA_OPEN_ALWAYS) has to scan the whole FAT directory and blocks the task long enough to starve telemetry polling — hence the brief "Telemetry lost" / "Telemetry recovered" right when logging starts. Renaming LOGS/ to an empty folder makes the open instant, which is why that "fixed" it. This also explains the 2.10.6 → 2.11.x regression (telemetry polling moved onto that shared task).

Fix

Move the log-file open off the timer task and onto the UI task, so the directory scan can no longer stall telemetry. PRs:

• fix(logs): open log files from the UI task (#7513) #7523 — main
• fix(logs): open log files from the UI task (#7513) [2.12] #7524 — 2.12 backport
• fix(logs): open log files from the UI task (#7513) [2.11] #7525 — 2.11 backport

Could you help validate?

The fix builds and runs, but I have not been able to reproduce the exact conditions (your large LOGS/ directory on an X9D+). Since you have the failing setup, a test build would be the best confirmation. Once CI builds #7524 (the 2.12 PR), could you flash it, restore your original large LOGS/ directory, arm, and check whether the telemetry drop at log start is gone?

Note: the two additional observations in your report (ELRS Lua Exit behaviour and Quick Model Select) are unrelated to this and are not addressed here — worth separate issues if still relevant.

[Fpv191]

Tested 2.12-fix-7513. It is a noticeable improvement over 2.12.2. when using the 2,250 file LOGS folder, telemetry no longer drops on every arm, but the issue still occurs frequently.

Additional testing: Both 2.12.2 and 2.12-fix-7513 do not lose telemetry when the LOGS folder is reduced to ~1,000 files. However, there is still noticeable lag/stutter during the "Engines Armed" callout (less pronounced now in 2.12-fix-7513).
Performance is still not as smooth as with an empty LOGS folder, which performs comparably to 2.10.6.

For comparison, 2.10.6 never lost telemetry with the 2,250 file LOGS folder and only exhibited occasional minor stutter during the "Engines Armed" callout.

[raphaelcoeffic]

@Fpv191 thx for the tests! I'm afraid this is all I can do for now. The truth is that opening a file in such big directories really stalls the radio. The f_open call for the log file will hold the FatFs volume lock, which causes the UI task priority to be increased above that of the telemetry/timer task at the very moment the audio task tries to access the SD card. IMHO, the only way to solve that would be to swap priorities between audio and timer task, so that the timer task would never block on these things. But that would be a change with a lot of consequences that are hard to foresee at this stage. Not something I'd do on stable branches (such as 2.11 and 2.12).

The better way to solve this at this point is really to use smaller directories, for example by using the feature to create a new directory per day (assuming your RTC clock is correct). Otherwise we'd need to do much more dramatic changes, such as using a separate volume (separate partition on the SD card) for logging and another for audio to avoid these locking issues. Or even use a few more tasks, all at the cost of more RAM usage, which is already really tight on the X9D+ / X9D+ 2019.

[Fpv191]

I really appreciate you looking into this, I understand there are many technical issues
and dependencies under the hood at play. I have to concede that my large 2250 file LOGS Folder is arguably excessive,... And perhaps I could use a faster SDCard than my SanDisk EDGE 8GB Class C4 4Mb/s SDHC1 Class card.

However all that said, something has definitely changed in all versions 2.11.2 and above; since with 2.10.6 the large LOGS Folder is working fine with the above mentioned SDCard.

With regards to memory management, according to statistics menu, there is substantially more memory available on 2.12.2 compared to 2.10.6; largely due to the new Lua 5.3 standard, so I'm unsure as to why this introduced LOGS issue can happen when there are also more resources available in reserve to handle tasks.