Great work with the new version 8 - some excellent improvements and features.
Just a few bits I’ve noticed that aren’t akin to pilot language.
Hold axes indicating inbound course (Low IFR charts) should always have a zero prefix e.g. 086, not 86. I saw one that showed as ‘2’ instead of 002. Would be good to see them correctly depicted as it’s a good feature.
VHF frequencies (see Comms) - you never see a frequency written like this: 121.7033 . It should be 121.705. Same for 121.8533 - should be 121.855 (examples given are EGCC Ground frequencies). Also, the VOR freq associated with the ATIS should not show as 113.550. VORs only ever have one or two decimal places. Should be 113.55. VOR freqs are shown correctly on area chart.
On the subject of frequencies, would you have en route VHF, HF and VOLMET frequencies for the various FIRs that you can access when flying a route (as in Communications in Jepp FD). Would be nice to have if the feature isn’t there already.
I have just updated to the latest build and have checked the frequencies. A lot of good improvements. However, there still remain inaccuracies regarding 8.33 Mhz freqs. All 8.33 frequencies should be listed with 6 digits. Using LHR as an example, 121.98 should be listed (and spoken by ATC) as 121.980. Same for Heathrow Director when flying in via LOGAN/LAM. We are instructed to contact Director on 119.730 (not 119.73, as listed in Navigraph Comms).
The correct LHR frequencies should be:
ATIS (Arrival): 128.080
Delivery: 121.980 - Navigraph also lists this frequency as a Ground frequency. I am not aware of LHR using 121.980 for Ground Control.
I have attached an extract from a UK CAA publication that might help.
Use non-8.33kHz spacing frequencies for communications
…and I thought, what have they done? Thankfully despite the confusing commit message, the correct 8.33 kHz channel/frequency “identifiers” appear to be used.
Like Rick, I do agree that radio frequencies should be padded as required to three decimal digits; similarly, leading zeroes in headings/tracks/courses (for holds or otherwise) should not be omitted (if anything, merely for consistency with the charts provided by Jeppesen; although I strongly suspect there must be some kind of applicable norm/regulation somewhere).
Haha, sorry about that. I changed it to make it a little less drastic!
Just for reference: the Jeppesen-owned company ForeFlight presents their frequencies in the same way that we do (without trailing zero on LHR GND), as does Skyvector.
The same goes for ATIS (128.08), Delivery (121.98), and the director frequencies - so we are definitely on par with the real-world alternatives at least! That does not mean that we can’t do something different though…
Perhaps the format you’re suggesting is more common (or even standard) in Europe as opposed to the US? They are both US companies after all, and your reference was from the UK.
Do I understand you guys correctly if I think that you wish for 8.33kHz frequencies to always have three decimal places?
So does ForeFlight/Jeppesen, yet again. However, in this case it would be great if we could include the unique service windows during which this frequency is in use according to our data provider (2200-0630Z during winter and 2200-0530Z during summer, or by ATC) as I believe that would make things a bit clearer. We’ll look into it for sure!
They seemingly use two decimal places everywhere, and for example list “incorrect” frequencies for tower (118.50 and 118.70 instead of 118.505 and 118.705), and you can see they’re zero padded as required (117.00 rather than 117.0 or just 117).
In my opinion, the listing of 121.98 instead of 121.980 seems to just be a consequence of their not properly/completely supporting 8.33 kHz spacing (which is indeed not used/implemented in US airspace).
Not sure about ForeFlight. The Jeppesen charts themselves appear to shorten 25 kHz channels to e.g. 121.7, or 122.95 (with frequencies like 128.125 being listed as e.g. 128.12 on older charts and 128.125 on more recent issues), and 8.33 kHz channels seem to always be zero-padded to 3 digits.
Ultimately, as far as I know, neither is wrong (except the case of SkyVector and Heathrow Tower above), it’s just a matter of preference.
Navigraph frequencies in Comms should technically mirror those as they appear on the Jeppesen charts i.e. if the frequency is written as 121.980, then that’s what it should be. Same for VORs, etc. You will seldom hear ATC shorten this to 121.98. It is more us pilots who take the ‘short cut’ and remove the last zero when reading frequencies back occasionally.
As we know, having the 3 decimal places differentiates an 8.33Mhz frequency to a standard one. Although arguably academic, it is good from a professional standpoint to write the frequency as it should be written. From a real-life flying perspective, a line trainer might criticise a pilot on a line check for not reading frequencies back correctly (omitting the last zero, for instance). It sounds pedantic/fussy, but it’s ultimately about keeping standards high.
It can’t be an easy one for the Navigraph team to reconcile from a display perspective in the App as some frequencies only have one decimal place (121.5) while others will have either two (131.25) and 8.33-spaced frequencies three (132.205). Reconciling that with computer technology (e.g. Excel) must be a challenge!