I'm using Reality XP 430W in conjunction with Carenado F33A and Flight Manager and XPilot/VATSIM.

Everything works just fine, except I'm not seeing the TX and RX indications on the 430 when I transmit and receive.

They are showing up in just fine in XPilot.

Any ideas?

Cheers,

Eric 

Hi,

This is expected and here is why:

In the X-Plane world we're supporting this feature with PilotEdge, xSquawkbox and xPilotClient.

In the FltSim world however, these add-ons have chosen not using the FltSim SDK facilities for sharing their data, instead, they are enforcing the end-user to installing FSUIPC.

We'll be able to also support this feature in FltSim, like we're already doing in X-Plane, only when they'll be publishing their simvars, and not FSUIPC offsets.

NB: If I've missed their latest development and they are now publishing their data via simvars, please just let me know!

Edited October 12, 20205 yr by RXP

I think I had posted links to this in the past but they do claim Simconnect support -- just that they state that for some setting the FSUIPC offsets are easier...

https://forums.vatsim.net/topic/20584-vpilot-externally-controled/

I read that as him saying that they read and write the squawk box simconnect data.....

 

Les

Thank you @LesOReilly for the link! A quick glance is not showing anything TX/RX flags related though but it is late and I'll see this in more details tomorrow.

On 10/12/2020 at 9:37 PM, RXP said:

Thank you @LesOReilly for the link! A quick glance is not showing anything TX/RX flags related though but it is late and I'll see this in more details tomorrow.

But we could at least get the TXPDR Mode control and the IDENT control into the 750 🙂

Not sure about the TX-RX.....Looks like the Ross guy is the dev of the vPilot Client...I think he also did the pilot edge client...

The main issue with integration of this kind of features is forcing both the end user and the developers in using a custom 3rd party layer (FSUIPC in this case) just for communicating data because they are not also using the facilities which are already existing in the FS SDK.

SimConnect is a good option but in this case and in order to support just the flags, we'd have to implement SimConnect in our product. However we don't need nor use it for now, and adding SimConnect in our products could add uncertainty about performance impact and potential bugs.

If any of these 3rd party clients are running in-sim, which means they are DLL loaded automatically by the simulator, there is no reason for them using the heavy SimConnect machinery for sharing a few data bytes and using this only.

There is an SDK facility compatible from FS9 to P3D5 doing just this: register_named_variable(). The added benefit of using register_named_variable() is that any developer could even embed their data source (TX/RX flags for example) in any XML gauge (default GPS500 for example).

In short, should they use register_named_variable() then set_named_variable_value(), which is not much different that what they would be doing if they were using FSUIPC offsets, it would just be a couple more lines of code for them with the immediate gain of broadening integration compatibility with any gauge.

Of course if their software is an executable not running in-sim process space, they won't be able to use the register_named_variable() SDK function directly and in this case SimConnect is probably the best avenue.

Now if any of the information published in the forum is clearly documented and supported (via a downloadable 'SDK' or similar) I'd be please to fully consider this. NB: I'm saying this because the information in the forum is 3 years old and it is referring a structure of data which layout might have changed or might be changing.

 

 

They don't insert any gauge into the sim.

vPilot runs outside of the sim and uses the same Simconnect items as Sqwak

Simconnect is literally the API given for 3rd party apps to connect and send Data....

While I am willing to side with you that implementing FSUIPC as a "Bridge" to simconnect is bad I can not agree with you that using simconnect directly with the sim is bad.

There have been no updates since none of that data has changed.

You don't want to do it...fine .. Don't do it.. but don't say that simconnect is going to cause you an issue...that is an argument that has no merit since most of the major players use simconnect to receive and send data into the sim....

Please, I'm saying "could add uncertainty about performance impact and potential bugs.", not "will add..."

I'm well aware of the SimConnect technology rest assured. We've been there when it was first introduced and as a matter of fact we're using it with the Panel Assistant module in order to handle the RXP Add-on menu. It is solely used with the Add-on menu module, not the gauge.

I'm also well versed in SimConnect operation at a very low level within the simulator and when I'm saying it could add uncertainty about performance, please believe my experience with these matters, and my prudent statement regarding adding this technology into our gauge.

Again, could, not will !