| Author |
 Topic  |
|
|
ziozanna
Pulcino
Italy
25 Posts |
 Posted - 01/01/2026 : 12:05:04
|
Description: I am an ultralight pilot and a long-term user of LK8000 running on a Kobo Glo HD. After updating to version 7.4.45 and refreshing my airspace files (sourced from OpenAir via alus.it), I have identified a significant issue regarding the visualization of TMAs that are sub-classified within TMZs.
Technical Issue: Currently, these TMAs do not have a dedicated filter/category within the "Airspace" settings. Instead, they are being categorized as "Unknown."
This creates a safety and navigation problem:
These TMAs are critical as they represent prohibited vertical development zones overlying large portions of Italy.
If I enable the "Unknown" filter to see these TMAs, the screen becomes cluttered with other "Unknown" airspaces that start from Ground (GND).
This makes it impossible to distinguish between controlled airspace and Class G (uncontrolled) airspace while in flight.
Current Workaround: I have temporarily resolved this by manually editing the OpenAir file:
Renaming TMZ/FMC entries to "XXX" (to keep them in "Unknown").
Renaming TMA entries to "TMZ" to force them into a filtered category I can toggle.
Requested Change: Could you please include a specific filter category for TMAs in the next release? This would allow pilots to toggle these critical zones independently without cluttering the map with "Unknown" data.
Thank you for your hard work, and Happy 2026 to the team! |
|
|
ziozanna
Pulcino
Italy
25 Posts |
Posted - 02/01/2026 : 18:02:31
|
Following up on my previous post regarding the TMA/TMZ filtering issues, I have some additional technical observations that might help pinpoint the cause.
Update on Workaround Instability: Unfortunately, manually reclassifying the airspaces in the file is not a stable solution. I am experiencing a recurring rendering bug:
The Issue: Frequently, and without a clear trigger, TMZs with a defined floor (e.g., 2000ft QNH) are incorrectly rendered as starting from Ground (GND).
The "Quick Fix": I have found that forcing LK8000 to reload the airspace file (Read Airspace) temporarily resolves the issue, and the floors return to their correct altitudes.
Version Comparison: This behavior was not present in previous builds. It appears to be a regression or a parsing instability introduced in the recent updates.
Conclusion: Because reliable airspace visualization is critical for flight safety—especially to distinguish Class G from prohibited zones—I have decided to roll back to version 7.4.22 until this is resolved.
I am available to provide my specific airspace files or logs if that would help the dev team investigate why the altitude floors are "dropping" to the ground in this version.
Best |
 |
|
|
ziozanna
Pulcino
Italy
25 Posts |
Posted - 02/01/2026 : 18:51:45
|
Hi Team,
I have conducted further testing regarding the TMA/TMZ rendering issue on v7.4.45 and I can now confirm a specific, reproducible bug.
Test Scenario:
Hardware: Kobo Glo HD.
File: Official OpenAIP dataset (OpenAir Version 1).
Observation: In this file, TMAs (e.g., "TMA MILANO Z1") are correctly classified as Class A with a floor at 2000ft AMSL.
The Bug:
Before GPS Fix: When I start LK8000 at home, the software shows the last known position. At this stage, the airspace is displayed correctly (Class A, floor 2000ft).
Upon GPS Sync: As soon as the GPS acquires a valid 3D fix and synchronizes the position, the airspace data becomes corrupted.
Data Corruption: The same TMA MILANO Z1, which previously showed a 2000ft floor, suddenly displays a negative floor (ranging from -299ft to -9201ft).
Result: Because the floor value drops below zero, the airspace is rendered as starting from GND. This hides the "Clear" Class G space and makes the map unusable for legal navigation.
Conclusion: There is a critical regression in how v7.4.45 handles airspace altitude offsets or coordinate transformations once the GPS position is active. This effectively "breaks" the vertical boundaries of the airspaces.
As mentioned, I am reverting to v7.4.22, where this behavior is not present. I hope this specific detail helps you identify the calculation error in the current build.
Best regards, |
|
|
|
brunotl
Pterodattilo
France
1199 Posts |
Posted - 07/01/2026 : 00:32:04
|
| i've found a bug in QNH airpaces reference, fixed will be available in next few day ... |
|
|
|
ziozanna
Pulcino
Italy
25 Posts |
Posted - 07/01/2026 : 10:10:18
|
Thanks Bruno,
Ready for testing. |
|
|
|
brunotl
Pterodattilo
France
1199 Posts |
|
|
ziozanna
Pulcino
Italy
25 Posts |
Posted - 10/01/2026 : 21:57:53
|
Ciao Bruno
I cannot test in flight but same test perfomed at home was successfully.
I think bug is fixed now
Thanks once again |
|
|
|
ziozanna
Pulcino
Italy
25 Posts |
Posted - 15/01/2026 : 22:55:33
|
Tested in flight an it works :)
Thanks |
|
|
| |
Topic |
|
Airspace TMA unknown