vPilot 134.150 showing 134.149

[Aleks]

Just flew on Vatsim and when tuned in to 134.150 in PSX it would send 134.149 to vPilot.
Seems only 134.150 would give this error, as 124.150 would send correclty to vPilot.

Any suggestions?

Attached is the screenshot.

[Hardy Heinlin]

Looks like a 32-bit floating point round-down to 134.149999999.

I don't know these systems. But that's why in PSX I coded point-less integers, e.g. 134150, and insert that dot just on the graphics display, not in the stored value itself.


|-|

[Gary Oliver]

Oh.. I'll check that one

[Bluestar]

This appears to be a MSFS2020 problem.  I just tried it with P3dv6 and did not have any issues.  I was able to reproduce the problem in MSFS2020.

[Gary Oliver]

Fixed in 10.0.3

[JRBarrett]

I am running MSFS SU13, PSX.Net.WASM 10.0.3, PSX 10.172 and VPilot 3.7.0 and I just had this problem. Trying to tune 129.700 it actually tunes 129.699

Not sure if this is a PSX problem, a PSX.Net problem, or a VPilot problem.

I'll keep an eye out for this issue on future flights and will tune the COM with VPilot dot commands for now if it happens again.

[Jeroen Hoppenbrouwers]

It's NOT a PSX problem. To avoid these floating point rounding problems, Hardy programmed PSX largely with integers. For example, this frequency is stored internally as x 1000: 129700.

[JRBarrett]

It's NOT a PSX problem. To avoid these floating point rounding problems, Hardy programmed PSX largely with integers. For example, this frequency is stored internally as x 1000: 129700.

I figured it's not PSX. No problem. It took me by surprise, but now that I know it can happen, I can always direct tune in the VPilot console. Based on Gary's comment above it might be related to PSX.Net.WASM.

I certainly don't expect him to look at it now, as he is right in the middle of World Flight!

[Gary Oliver]

I thought we fixed this in the latest version, alas not - Will try and take a look this week in between World Flight stuff.

[JRBarrett]

I thought we fixed this in the latest version, alas not - Will try and take a look this week in between World Flight stuff.

FWIW, I am running VPilot in client/host mode, with the host on my PSX/MSFS computer and the client on a separate laptop, connected via WiFi. I don't know if that might have any bearing on the problem. In general, VPilot and VATSIM voice works very well with this setup.

[macroflight]

Worth mentioning: I had some problems even when tuning using vPilot, it seemed like PSX would sometimes change the frequency back from e.g 134.150 to 134.149 a second or two after I typed ".com1 134.150" in vPilot.

Gary pointed out that there is a setting DisableRadioInjection in PSX.NET.MSFS.Client that can be used to completely prevent PSX to change vPilot COM1. This allowed me to continue the first Worldflight leg without going insane.

[Jeroen Hoppenbrouwers]

This allowed me to continue the first Worldflight leg without going insane.

It's only Monday.

[Bluestar]

I experienced the same digits problem last night with vPilot. This is the first time I've had this problem.  The only change to my system has been a Windows update last week.

I used JRBarrett's suggestion of .com1 132.50 as a workaround. 

[Bluestar]

I did a check for this problem and found the following frequencies had the rounding error -

128.2, 128.7, 129.2, 129.7, 130.2, 130.7, 131.2, 131.7, 132.2, 132.7, 133.2, 133.7, 134.2.

Interestingly 134.7 worked.  Also I went back and checked 134.149 and it is now showing 134.500. 

Out of all the frequency combinations it is interesting that these are the only errors. 

[macroflight]

I was able to make a Python script (100% vegan) to sync PSX radios with MSFS that seems to be working even for the frequencies that have been troublesome.

To get rid of rounding errors the script will take PSX string (e.g "121500"), append three zeroes ("121500000") and convert that to an integer which is then sent to MSFS via the SimConnect COM_RADIO_SET_HZ or COM2_RADIO_SET_HZ events.

The result: https://raw.githubusercontent.com/macroflight/psxhacks/main/radiosync.py

Please note that you need Python, the SimConnect Python module, patch the SimConnect module and update its copy of simconnect.dll to get this working. You might want to wait for Gary to repair PSX.NET.MSFS.

[Gary Oliver]

@Macroflight - good work, I'll no doubt steal the code in the script and update PSX.NET.WASM when i get a moment

[Hardy Heinlin]

So MSFS wants to see Hz instead of kHz? And the existing PSX add-ons convert the integer 121500 from PSX to a 32 bit float 121500.0 and then multiply that by 1000? I think such conversions typically generate rounding errors at certain numbers. The integer should first be multiplied by 1000 and then be converted to a 32 bit float.

[Aleks]

Also adding 130.450 shows 130.449 on vpilot