NDBs can have half frequencies - for instance EME 353.5 kHz near East Midlands airport. Currently the adf instrument can only accept full frequencies as the property is an int.
Maybe need a discussion on the list about handlign this, eg do we need to add a config property to the NDB cxx instrument, eg config/accept-half-freq= true ? And in this case the frequency type will be double, not int?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Agree. Yes it would be double. Actually - X-Plane's data format can only do integers, so maybe this is a can't fix / won't fix, since it would be difficult to do this without X-Plane changing their specification for nav.dat?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Welll .... is there a way we can aks them? At this point we have a few edits, I'm not adverse to adding support for fractions on our side, it's niot like we need our nav.dat to remain compatible.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Apparently the bandwidth of NDB's is big enough that it's fine to tune the frequencies 500 Hz lower, and you'll still pick up the NDB. Many commercial NDB instruments don't support the decimal point. Although Airbus does support it!
it's niot like we need our nav.dat to remain compatible.
As long as backwards compatibility is maintained? Without having our own data source
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
What I mean is, we could make our parser support a decimal in that column, and just edit our nav.dat, and we'd be fine, as far as I can see. Do you agree?
(And, we're already making drive-by edits to these files in particular cases, since we're not doing any /other/ updates...)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Researching NDB's I came across this discussion..
Would an acceptable solution be to keep the original interface intact (i.e. the frequency property remains an int) and add second property (like int frequency_fraction) to the instrument?
This additional property would default to zero, so all existing ADF instruments would simply continue to work as if nothing had changed.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
That's possible but I'm not sure it really helps anyone: a config property is opt-in and if people set it, they can deal with a non-integer frequency, and other systems (generic radio dialogs, etc) can also detect this case.
If we add a second property for the fraction, we have to base UI policy, etc on whether it's zero or not, but that is not very nice: what we want to know is whether the ADF tune can or can't handle fractional frequencies, and a config property is the right way to do that.
All 'in my opinion' of course.
See also the discussion about, in our current navaid DB, we cannot actually model fractional NDB frequencies, I think.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maybe need a discussion on the list about handlign this, eg do we need to add a config property to the NDB cxx instrument, eg config/accept-half-freq= true ? And in this case the frequency type will be double, not int?
Agree. Yes it would be double. Actually - X-Plane's data format can only do integers, so maybe this is a can't fix / won't fix, since it would be difficult to do this without X-Plane changing their specification for nav.dat?
Welll .... is there a way we can aks them? At this point we have a few edits, I'm not adverse to adding support for fractions on our side, it's niot like we need our nav.dat to remain compatible.
Apparently the bandwidth of NDB's is big enough that it's fine to tune the frequencies 500 Hz lower, and you'll still pick up the NDB. Many commercial NDB instruments don't support the decimal point. Although Airbus does support it!
As long as backwards compatibility is maintained? Without having our own data source
What I mean is, we could make our parser support a decimal in that column, and just edit our nav.dat, and we'd be fine, as far as I can see. Do you agree?
(And, we're already making drive-by edits to these files in particular cases, since we're not doing any /other/ updates...)
OK; that's fair enough -- the only thing to be wary of, then, is whether custom ADF instruments will still work.
Can you point me at any examples? I'm guessing most will not care that the property is a double, unless they do something very specific.
c172p\Models\Interior\Panel\Instruments\kr87-adf\
Aircraft\Instruments-3d\kr87-adf
At least these 2.
The A320 has its own code of course as well. but it supports decimals. They just can't be tuned yet.
Researching NDB's I came across this discussion..
Would an acceptable solution be to keep the original interface intact (i.e. the frequency property remains an int) and add second property (like int frequency_fraction) to the instrument?
This additional property would default to zero, so all existing ADF instruments would simply continue to work as if nothing had changed.
That's possible but I'm not sure it really helps anyone: a config property is opt-in and if people set it, they can deal with a non-integer frequency, and other systems (generic radio dialogs, etc) can also detect this case.
If we add a second property for the fraction, we have to base UI policy, etc on whether it's zero or not, but that is not very nice: what we want to know is whether the ADF tune can or can't handle fractional frequencies, and a config property is the right way to do that.
All 'in my opinion' of course.
See also the discussion about, in our current navaid DB, we cannot actually model fractional NDB frequencies, I think.
You are right.
I think I missed the 'opt-in' idea. Sorry for making noise in this thread.