Add 8.33 khz support

[legoboyvdlp]

The KX165A radio has support for 8.33 khz. Add support for 8.33, in order to allow our aircraft to be used in Europe. Documentation: http://antena.fe.uni-lj.si/literaturgithub/Razno/Avionika/Kx155/Kx155a.pdf

While we are at it, we might as well simulate all the other functions of the KX165A.

@wlbragg I wonder if you could edit the 3D of the instrument to closer match the KX165A? https://vimeo.com/177075004

Basically, the most urgent thing is to allow the radio to show three digits. This is required if we are to simulate 8.33.

The second thing would be to remove the separator between the COMM and NAV segments - the instrument should just have one LCD display.

[legoboyvdlp]

Marked as high priority since Stuart would like this in the release seemingly.

I have already simulated the pulling of the knob to change between 25khz and 8.33 khz. However, to display the frequencies we need a proper 3D model of the 165A.

This may also require nasal code in order to skip 0.020 khz, which does not exist in 8.33.

[gilbertohasnofb]

@legoboyvdlp The image you posted is of a KX 165A, our model is the KX 165. See:

So no need to do anything about the 3d model.

[legoboyvdlp]

In that case we will not be able to have 8.33 radio if the model does not change, since the KX165 does not have 8.33.

[gilbertohasnofb]

Perhaps for now we can just implement the 8.33 Hz support anyway even if this specific model does not have this feature. Then in the future we can revamp the 3D model and the textures.

[legoboyvdlp]

Fair enough - let me push what I have.

In order to allow the user to switch between 25khz and 8.33, is it fine to make shift-clicking the khz knob to toggle that (as in the real aircraft)? Notice that you can no longer use shift to increase the frequency by 0.1 mhz. Or will we simply always have 8.33 on?

[gilbertohasnofb]

@legoboyvdlp I think having it always on might be annoying for people flying in regions where they use 25 kHz steps only. I think the shift + clicking sounds like a good solution, particularly if this is how you can toggle it in the real aircraft. I would also set the default to 8.33 Hz, so that anyone not knowing about the shift + click thing can still fly anywhere in the world. Sounds good?

@wlbragg what do you think about this?

[legoboyvdlp]

Sure, can do. I'm having one problem though - my bindings aren't working for some unexplained reason. It decreases but doesn't increase. I am recording a gif to show what I mean:

`

property-adjust /instrumentation/comm[0]/frequencies/standby-mhz 0.005 0.0 1.0 0.005 true decimal `

[legoboyvdlp]

[gilbertohasnofb]

That's weird, I don't know why this is happening. I might have some time to take a look at it in the evening in case you don't figure it out until then.

[legoboyvdlp]

Thanks! I pushed to branch Issue-1275.

[wlbragg]

It all sounds good to me!

[gilbertohasnofb]

I pushed to branch Issue-1275.

Did you manage to solve the issue you previously reported?

[gilbertohasnofb]

@legoboyvdlp also, would you mind using aliases for the radio properties to keep the code consistent in that file? The aliases are declared on the very top of the file inside the <params> tag.

[legoboyvdlp]

No, I didn't manage to solve the issue, and I am unable to use aliases, since for some reason the logic doesn't seem to work with aliases. If anyone can figure out how to use aliases with logic, feel free to commit it :)

[gilbertohasnofb]

I will try to take a look at this asap if nobody else beats me to it, but I am super busy in these next days, I'm presenting a paper on a conference and I still a lot of work to do on it (wish I was coding!).

[wkitty42]

In that case we will not be able to have 8.33 radio if the model does not change, since the KX165 does not have 8.33.

really? how comes the KX165 image shows "pull 25k" if it doesn't switch between 25k and something else? there's only the two, 25k and 8.33, right?

[gilbertohasnofb]

@wkitty42 nice catch. Yeah, I think you are right. @legoboyvdlp what made you think that our model did not allow 8.33 Hz intervals for the COMM radios?

[legoboyvdlp]

That, I presume is because it used to be 50K and 25K; every source I have seen says explicitly only the 165A model has it, our model is the 165. Something else to support the ordinary 165 not having 8.33 is it only having a 2-decimal point display.

The funny thing is the 165A still says to pull for 25K when you actually pull for 8.33k and push for 25!

[legoboyvdlp]

https://www.google.com/url?sa=t&source=web&rct=j&url=http://www.monticellofc.org/aircraft/king%2520kx155%2520guide.pdf&ved=2ahUKEwjIgYSRpKHiAhVnUxUIHawEACYQFjAAegQIBBAB&usg=AOvVaw1fyMvuXjjUomvcwl-SEHKI

So it seems the 165A has the option for both from factory and can be retrofitted for 8.33 - the ordinary 165 cannot. Sorry about the confusion.

Regardless it's very clear the ordinary 165 doesn't have 8.33 in any circumstances.

[gilbertohasnofb]

So I think you are right, @legoboyvdlp. Let's just add the 8.33 support for the moment even if this is not the correct thing with our radio model and then @wlbragg and I can work on the new model in the near future, after the release. Sorry I still did not have a chance to check your code :cry:

[wlbragg]

Did you guys see this on the dev list?

Item 1) I don't recall seeing an issue raised about this, is there a 8.33kHz radio available to install?

I have implemented 8.33 support in commradio.cxx ages ago. So for our stock kx155 it should be as easy as setting the property "eight-point-three" to "true" in your instrumentation.xml.

--

Torsten

[legoboyvdlp]

Yes, and I verified it works; nevertheless I just need to update the bindings of the knob to update in 0.05 increments, not 0.25.

(Yes, I know it's 0.0083 khz and not 0.05... however thats exactly how it should be, the radio code translates 0.05 to 0.0083, 0.05 was chosen to make life easier for pilots!)

I've done that; however there is an extremely odd bug - I posted a gif above.

[dany93]

Weird: by observing /instrumentation/com/frequencies, after a decreasing sequence, it increases by two steps, then it stops increasing. Also, it seems to depend on the frequency we start from.

Can it be that it refuses to increase if on some particular frequencies?

Can this 8.33 kHz (should be 25/3 kHz) 'submarine' true step be responsible? It can reach a 25 kHz step frequency from above (by decreasing), but not from below.

[gilbertohasnofb]

I think this post here explains well what lego is talking about: https://developer.x-plane.com/article/8-33-khz-radios-for-users-and-authors/

[dany93]

Yes, this one too, easy to read by looking at the table. http://www.lightaircraftassociation.co.uk/2013/Magazine/May/radio.pdf (it is given as a link at the end @gilbertohasnofb's one)

[legoboyvdlp]

Well, one thing of note is that some frequencies do not even exist - it should e.g. skip from 123.015 to 132.025. Maybe we need some form of a controller (nasal or jsbsim) to make it work properly?

[dany93]

@dany93 wrote

Can this 8.33 kHz (should be 25/3 kHz) 'submarine' true step be responsible? It can reach a 25 kHz step frequency from above (by decreasing), but not from below.

[gilbertohasnofb]

@legoboyvdlp what confuses me is that the article I post talk about radios with 6 digits representing numbers with 7 digits. Our radio has 5 digits only. With intervals of 0.025, it's easy and there are unique representations to each frequency:

true frequency -> shown frequency 120.025 -> 120.02 120.050 -> 120.05 120.075 -> 120.07 120.100 -> 120.10

But for intervals smaller than 0.10, there will always be at least some numbers that won't have a unique representation. Here is an example with 0.00833:

120.008 -> 120.01 120.016 -> 120.02 120.025 -> 120.0? <== 120.033 -> 120.03 120.042 -> 120.04 120.050 -> 120.05

With steps of 0.005, the issue is even worse, now every second frequency doesn't have a representation:

120.000 -> 120.00 120.005 -> 120.0? <== 120.010 -> 120.01 120.015 -> 120.0? <== 120.020 -> 120.02

Can anyone clarify this?

[gilbertohasnofb]

From https://www.caa.co.uk/General-aviation/Aircraft-ownership-and-maintenance/8-33-kHz-radios/ :

An 8.33 kHz channel will have a 6 digit channel ending: 05, 10, 15, 30, 35, 40, 55, 60, 65, 80, 85 or 90.

That is, things like 120.000, 120.005, 120.010, ... But our radio only has five digits.

[gilbertohasnofb]

Well, one thing of note is that some frequencies do not even exist - it should e.g. skip from 123.015 to 132.025.

@legoboyvdlp this one is clear. It works by mapping some frequencies twice when you have six digits. See that pdf @dany93 posted, it has a table that explains that.

[legoboyvdlp]

I think it would be easier to make a whole new radio 3D that has the proper six digit display - I'm willing to do that but I need texture work and I'm sure other people would do it better and quicker.

As for the question of what frequencies it shows: it appears it does it something like this:

where bold is 25khz, and italic is 8.33 khz (and each number is ONLY the displayed frequency, the c++ code deals with mapping the channel to the correct frequency).

Possible channels = 00, 05, 10, 15, 25, 30, 35, 40, 50, 55, 60, 65, 75, 80, 85, 90, 00 for each 100 khz interval.

so: 118.000 = 118.000 118.005 = 118.000 118.010 = 118.083 118.015 = 118.167 118.025 = 118.250 118.030 = 118.250

so the pattern is 00khz, +05khz, +10khz, +15khz, +25khz and so on? Is that correct? 😕 If only they could choose a simple system 😆

[gilbertohasnofb]

Is that correct?

I think so. It's super confusing, really... but that seems to be correct according to that pdf.

I think it would be easier to make a whole new radio 3D that has the proper six digit display

But then we run into a more fundamental issue: both models of the KX 165 have only 5 digits. So does this mean that this model is not any longer compatible with the EU standards and thus cannot be used in Europe? Otherwise I can't see how it would handle the 8.33 Hz frequencies.

[legoboyvdlp]

The KX165A has six digits:

[gilbertohasnofb]

Great. I thought it didn't because of the second image posted in the initial issue report, but I think that one is wrong. In that case we definitely need to change the model, but I am not sure we can do it in time for the release, I am ultra busy in the next days... should we maybe hold off with the 8.33 Hz support?

[legoboyvdlp]

Oops - missed that; that's a 155A, not a 165A in the first post. sorry about that!

That's definitely fine by me; I don't think VATSIM requires it yet although I may be wrong.

[wlbragg]

@legoboyvdlp what confuses me is that the article I post talk about radios with 6 digits representing numbers with 7 digits. Our radio has 5 digits only. With intervals of 0.025, it's easy and there are unique representations to each frequency:

true frequency -> shown frequency 120.025 -> 120.02 120.050 -> 120.05 120.075 -> 120.07 120.100 -> 120.10

But for intervals smaller than 0.10, there will always be at least some numbers that won't have a unique representation. Here is an example with 0.00833:

120.008 -> 120.01 120.016 -> 120.02 120.025 -> 120.0? <== 120.033 -> 120.03 120.042 -> 120.04 120.050 -> 120.05

With steps of 0.005, the issue is even worse, now every second frequency doesn't have a representation:

120.000 -> 120.00 120.005 -> 120.0? <== 120.010 -> 120.01 120.015 -> 120.0? <== 120.020 -> 120.02

Can anyone clarify this?

The 7 digit frequency is tabled to be 6 digits, so that should be all we need to be concerned about. Although I really don't know how detailed the inner workings of our simulated radio needs to be setup . As in, are any of the addons that use radio support expecting the 7digit frequency output or the 6 digit table representing the 7 digit freq?

I think trying to adapt our radio means you see

120.000 -> 120.00 120.005 -> 120.00 <== 120.010 -> 120.01 120.015 -> 120.01 <== 120.020 -> 120.02

and you have a really odd tunning dial. Unless in RL there is another indicator such as a light or marker denoting the "invisible" freq. Such as...

120.000 -> 120.00 120.005 -> 120.00 ` <==

120.010 -> 120.01 120.015 -> 120.01 ` <== 120.020 -> 120.02 But now I may be inventing how I would have done it!

[gilbertohasnofb]

Cool, so let's make this a high priority and work on it soon. I will prepare the textures as soon as I can, I will try to do it next week. @wlbragg The model will require very little changes, I think

[gilbertohasnofb]

@wlbragg Just to make it clear, the examples above are tables from 6 to 5 digits (I am not counting the decimal point, obviously). So 6 digits is enough for unique representation of any frequency multiple of 5Hz or 8.33Hz or 25Hz, but 5 digits has a bottom limit of 10 Hz. Anyway, the solution is to upgrade our radio model, should be easy.

[legoboyvdlp]

Here's a model of the 165A - however, it does need a texture.

Gilberto, once I uv-map it, would you be able / willing to texture it? I'm not much good at that bit 😃

[gilbertohasnofb]

@legoboyvdlp that looks nice! I will work on the texture asap, I will try to find some time to do it still today.

once I uv-map it, would you be able / willing to texture it? I'm not much good at that bit

Let me suggest the opposite: let me first create the texture and then you map it, it will be much easier for such simple object.

[gilbertohasnofb]

@legoboyvdlp texture is ready. I added the CH sign as well as the vertical orange line, and I added the white buttons separately. Should be straightforward to map. I use the dimensions from the photo you used before stretched above the previous texture.

[gilbertohasnofb]

pushed to branch Issue-1275

[legoboyvdlp]

I'll be away all day today but I'll try and animate it once I get home or tomorrow.

[gilbertohasnofb]

That looks really good, lego! Thank you so much for taking this task up, and no rush concerning the animation.

Once you open a PR, I will test it and merge it. I also want to see how the colour of the new texture will look like in the radio stack, I think I might need to tweak the other radio instruments in order to match the colours better. But I will do that only after the PR is opened.

[wlbragg]

Excellent guys!

[wkitty42]

i'm guessing this one and the one about loading the GPS once and using translation to move it will both be added to fgdata pretty quickly so they will be available for the new release?

[legoboyvdlp]

I don't know if this will be ready for the new release.

The other bugfixes have been requested to be merged already.

[wkitty42]

On 5/20/19 12:43 PM, Jonathan Redpath wrote:

I don't know if this will be ready for the new release.

The other bugfixes have been requested to be merged already.

ok :)

[legoboyvdlp]

I'll need to edit the materials I think to match the old one?

Regardless here it is in the sim:

[legoboyvdlp]

One other thing - I think the lightmaps might need to be regenerated unfortunately for the instrument @wlbragg