Character missing from Comms button.

[Crunchmeister1]

When you’re in the comms panel, the circled button is short 1 character. It will only hold xxx.xx whereas all the other comm buttons hold xxx.xxx. So it doesn’t display the last character of a frequency like 123.475 shows up as 123.47. Not a big deal really, but it’s nice to be able to double check the frequency before hitting the Xfer button.

[nguyenquyhy]

I initially model this whole numpad based on the TBM screen, so everything has 2 decimals (the 3 decimals is auto-filled). Later on, RMROC updated the button display to show 3 decimals, which makes total sense if you need to know the exact frequency you are on. However, it creates the discrepancy you report here.

I'll do a bit more testing and will fix this soon. 😂

[Crunchmeister1]

o everything has 2 decimals (the 3 decimals is auto-filled).

The TBM screen totally has 3 decimal places, not 2.

And this is causing problems. As per the screen shot below. I'm expected to dial in 124.47. The comms plugin enters 124.475 automatically. The sim WILL NOT accept that as a valid frequency. The only way I can then switch frequencies is using the 1 in the ATC panel, which defeats the purpose of being able to tune radio from the SD. This has happened to me many times so far. This should be an easy fix.

.

[rmroc451]

I tried this morning to allow the button to set 3 decimal places, but it pukes.

I tried a valid 3 digit one from KHYI Tower, 126.825, leaves prior value in STBY. I tried a valid 2 digit one from KAUS Tower, 121.000, leaves prior value in STBY. I tried setting your 123.47 value, leaves prior value in STBY.

if I trunc the last digit from the numpad, and set 126.82 (BCD16: 9858), it sets correctly to 126.825. if I trunc the last digit from the numpad, and set 121.00 (BCD16: 8448), it sets correctly to 121.000. if I trunc the last digit from the numpad, and set 123.47 (BCD16: 9031), it puts it in as 123.475.

The real reason I think we are seeing this, after doing some more investigation as to what the type of the value we are setting follows.

BCD16 (what the frequencies are stored as), stores 4 digits in two bytes. One digit per half byte. Currently we are truncating the leading digit (1), to get down to 4 (minus the decimal). If you enter in the deck 121.90, we only encode the 2190 part, which fits in the BCD16.

If I increased this to allow the 3rd decimal place, 121.900, we'd try to stick 5 digits in a place that can only handle 4, which is why our "set" isn't working.

So we are between a rock and a hard place, where the sim tells you to use 123.47, but then changes what we send (when we send 123.47) to 123.475.

I don't think we can fix the entry part @Crunchmeister1, unless the way those values are encoded is updated.

I'll enter a zendesk ticket, but I don't expect this to get much traction.

[Crunchmeister1]

Another care of a frequency that can't be entered via the panel. It specifically assigns me 120.420. Flight Tracker converts it to 120.425, which it won't take.

[Crunchmeister1]

It will be unfortunate if you can't get this fixed as these frequencies appear more regularly now it seems. That's my 4th one today.

[pieterwasalreadytaken]

As @rmroc451 already explains, we only have 4 digits we can send. This is a SimConnect limitation, so not much we can do for now.

[rmroc451]

I got a "solved" in my zendesk ticket this morning...

Either they fixed the SDK (doubtful) or they probably did a find and replace and fixed the bad frequencies to have the .005 on the end of them lol

[JBP77]

Hi, I wonder if the issue is partially related to the 25khz vs 8.33khz discussion happening in the Mobiflight forum. Based on my (limited) understanding this could explain why certain frequencies are correctly converted, and others are not. Maybe a similar „offset“ or conversion could be built into the streamdeck profile when punching in the frequencies? https://www.mobiflight.com/forum/topic/5949.html

[nguyenquyhy]

This is now done in v0.42.