Hi,
Talking about UIR/FIR sector frequencies listed in Charts, I see frequencies like 135.9533, or 126.6033. My question is : Are they equal to i.e. 135.955 and 126.605 respectively ?
If yes, what is the reason for not listed in the latter format ?
Thanks ,
Sotiris
Looks like an old bug resurfacing?
Regards,
Tim
Hello! Welcome back to our forum @sotstavr
Would you mind providing me with some examples of airspace with this issue?
@Rodeo314 Do you have any references? Such as an old forum post or something. I have a slight recollection of this issue, but I can’t find anything related…
Kind Regards,
Malte
Thanks for your reply.
Go to Charts/right click on Madrid FIR-UIR/COMMUNICATIONS. If you check the frequencies (the 8.33 KHz spacing - not the 25 KHz ones), you will find the two examples of my post among many others. Of course, this issue does not apply in Madrid FIR/UIR only. It shows in every other European country/FIR/UIR using the 8.33 KHz.
Thanks! I can confirm the issue, and as mentioned, it feels familiar. We shall investigate!
Also here:
For example:
https://forum.navigraph.com/t/incorrect-frequencies-in-frequency-list/8305
IIRC there were more topics but it’s difficult to find them after all this time.
Regards,
Tim
Thanks! Yes, I found that topic as well but there is no solution, which is odd…
I have looked into some of our old data, and this issue seems to go back at least to the beginning of this year, most likely longer than that! I’ll keep you updated as I gather more details!
This has been fixed internally, and the fix will be included in the next update. Thanks for the feedback! The root cause is related to the fact that these frequencies are using 8.33 kHz spacing - just as mentioned here earlier.
Kind Regards,
Malte
OK thanks, standing by for the update.
Best regards,
Sotiris
Hi Malte,
Any news about the release of the expected update ?
Best regards,
Sotiris
Hello!
Everyone has returned from summer vacation; the next release is expected within days! This update 8.36.0 will include the fix.
This has now been fixed with today’s release of version 8.36.0 of the app.
Thank you for the feedback!
Kind Regards,
Malte
Hi, Malte,
Thanks for your efforts about that correction and update.
Yet, allow me a small correction about HELLAS FIR : the frequency 135.88 must be 133.88, as the latter is not listed in the latest updated and I am sure it is currently used as upper northeastern sector frequency.
Best regards,
Sotiris
Hmm, we seem to have both frequencies in our data.
The frequency that you mentioned (133.88) belongs to the Makedonia ACC & sectors, as per the Greece AIP: HASP - Integrated Aeronautical Information Package
Do you see something incorrect in our data, and if so - could you back this up using the AIP?
Kind Regards,
Malte
Except frequencies are not mapped correctly.
Alicante Volmet should be 126.005
Barcelona Volmet should be 127.605
Madrid Volmet should be 126.205
GEN 3.5 METEOROLOGICAL SERVICE.pdf (633.0 KB)
Should be 121.075, 124.955, 121.075 again and 128.305 MHz
GEN 3.4 COMMUNICATION SERVICES.pdf (3.9 MB)
Regards,
Tim
I confirm 133.880 belonging to Makedonia ACC. I can assure you that even today was used by ACC, as I live in this country. 135.875 looks more realistic than 135.880.
129.675 is still used (not 129.68).
Skopje ACC use the following frequencies : 120.015 119.375 136.425 contrary to Navigraph comms list.
In general, a comms list review and/or frequency correction is needed within 8.33 european ACCs.
Thanks again.
Thank you both!
This is not the same issue, but it seems to be an issue, unfortunately. I see our source data is correct, but somehow, information is lost in translation somewhere.
We shall investigate!
Kind Regards,
Malte
Well it can’t really be the same issue indeed, but it’s been introduced by the fix, so to speak.
I found the older version of Charts on my iPad:
Here, the conversion is incorrect, .xx33 to .xx00 in one case, and .xx33 to .x100 in the other (where .xx33 should become .xx50 in both).
Here’s it’s deciding to turn a 25 kHz frequency into an 8.33 one, plus the same issue as above, .xx33 turned to .xx00 in one case and .xx33 to .x100 in the other instead of .xx50
My guess is whatever algorithm you’ve implemented is simply incorrect.
Regards,
Tim
That depends on how you look at it, I guess. The fix in this particular case was to stop relying on a field in our database that contained a “formatted version” of the frequency that was wrong. This is what you see in the old version of the app.
Instead, the app manually formats the frequency value based on provided units. As far as I can tell, that algorithm is working as intended! However, the raw value stored in the database seems incorrect. Here is an example:
This can be compared with another database of ours which is not used for the apps, which instead looks like this:
We shall investigate to see what the cause may be!
Kind Regards,
Malte
Interesting. That database does look weird indeed 
Regards,
Tim
Edit: it might be easier to keep using comm_frequency_display and simply translating the value to the corresponding 8.33 kHz representation for display.
