News:

Precision Simulator update 10.175 (29 May 2024) is now available.
Navburo update 13 (23 November 2022) is now available.
NG FMC and More is released.

Main Menu

vPilot 134.150 showing 134.149

Started by Aleks, Tue, 12 Sep 2023 19:50

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


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.
Grace and Peace,

Bode

Gary Oliver


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

Quote from: Jeroen Hoppenbrouwers on Sat,  4 Nov 2023 23:41It'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

Quote from: Gary Oliver on Sun,  5 Nov 2023 19:36I 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

Quote from: macroflight on Mon,  6 Nov 2023 08:27This 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. 
Grace and Peace,

Bode

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. 
Grace and Peace,

Bode

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

Bluestar

Quote from: Gary Oliver on Sun,  5 Nov 2023 19:36I thought we fixed this in the latest version, alas not - Will try and take a look this week in between World Flight stuff.


Gary,

Any progress on this issue?

I noticed that Vatsim traffic on NAV display is showing the target aircraft a thousand feet off.  Apparently no issues from Vatsim controllers since they have not said anything.
Grace and Peace,

Bode

Aleks

I was also getting comments from ATC that I am howing 300 feet off, despite having correct QNH set.