PilotEdge Forums

Is there anyway to link the transponder in P3D/FSX to the PE client (a script through FSUIPC possibly)?

There has been some discussion about this lately. You can set norm/stdby via FSUIPC, but not the ident yet afaik.

I will work on IDENT support via FSUIPC when I can, but there's a long list of things higher on the list right now.

Ok Keith thanks for the response, I'll give it a shot.

Ident Transponder problem solved!....I hope..

I have conducted various tests and observations on the Ident problem and I came up to the conclusion that there is not a problem at all, the FSUIPC Ident offset is ''x7B93'' with parameter of ''1'' is working like an off/on toggle switch.
I have tested it in the PilotEdge system and it was a success. The software that I'm using to connect my hardware to FSX is Link2fs Multi. My method is simple, the Ident is running for 3000 milliseconds and on every each 150 milliseconds of the interval I'm sending ''x7B93'' with parameter ''1'' to FSX.
I come up with this idea while watching the behavior of the PE client. Whenever I click on the Ident button it starts behaving like the previous off/on method.

PS - Probably both intervals are not 100% correct and i would be grateful if Keith Smith shares with me the correct Intervals.

SimeonPA, Did you verify this approach actually registered an observed ident with a controller? I have been trying to get a Lua script to fire that ident off for a couple of days with no luck. I'm using the FSUIPC offset you have below, but no luck getting the controllers to see the ident.

Alright, I'm seeing every attempt to script the ident function in the FSX/P3D PE Client end in failure. I know the number of aircraft that have actually implemented an ident button is pretty limited, but for (the growing number of) 3rd-party airplanes that have, as well as the folks with hardware controls, It would be a very welcome capability.

Keith, if this ever makes it far enough up the priority list, add me to the list of people willing to test for you. Hopefully somewhere along the way the FSUIPC offset was simply changed and it is just a matter of rediscovering and publishing what the new offset is. One can hope, anyway

I assume you are using FSUIPC and lua scripts.

Have you tried using the "Additional FSUIPC Controls" provided with FSUIPC? (FSUIPC Adv User Guide pg 31)

ipc.control(1122) ;Xpndr ident (sb3)

The one plane I have this scripted for appeared to work fine when I was asked to SQUAWK IDENT by the controller. I don't often fly that plane anymore. (One thing though in my testing it does NOT cause the IDENT button on the PE Transponder Popup to flash on-off as my understanding that is part of the gauge coding. However, the other SB Offset writes for STBY, Mode C, Transmit and Receive DO light up with the appropriate offset writes, or control parameters.)

If you want to PM me, I'd be glad to help if I can.

Don

Hi, Don. The script I originally tried used ipc.control(1122,1) when the ident button was pressed and ipc.control(1122,0) when released. I didn't try simply using ipc.control(1122) without the second parameter. If you successfully got it to work, maybe I'll give a shot at simply mapping it to a keypress to see what happens.

Chris,

I'm not a programmer other than the courses I took in school years ago (too long ago -- don't ask) but have written and have employed about 80 or so relatively simple lua scripts to customize my aircraft and use the keyboard and mouse as little as possible. Some scripts are more complex than others, but compared to the standards of the pros, these are definitely simple scripts.

I know that Keith and company completely reworked the guts of the transponder/comm gauge, but at least most of the functions appear to utilize the same simconnect offsets as SB3/4. (For example the PTT for the Comm Radios, and the STBY/Mode C Transponder settings.) This, of course is subject to change as the propriatary software and PE expansion plans change and expand, and although they function now, there is no guarantee that this will not change as the network and service and interface evolves.

But, that being said, it's GREAT from my perspective that there is presently an overlap of workable functions, as it allows me (us) to tailor our system to best enhance our experience. As PilotEdge is a professional service (versus a hobbiest network) I completely understand why some of the specifics are apparently kept under wraps, or not shared on the open forum -- it opens a whole different can of worms, and handling support and squashing conflicts from misapplications by hamfisted neophytes (like ME) could easily take away from the main purpose and thrust of PilotEdge. The only reason I even started working on alternatives was to get away as much as possible from keyboard/mouse flying, and the "floating PE gauge" was becoming problematic on my screen setup for a number of reasons. Some aircraft developers openly provide offsets and LVAR data to users, others don't. (for example PMDG does. Flight1 has been pretty open about it as well on their registered forums) Nevertheless, if I were to be asked for my vote (I WASN'T, and this isn't a democracy.... ), I would definitely prefer to have the information openly available for interfacing these common-type functions on PilotEdge

So, as far as the SquawkBox and hobbiest "standard" this is what is stated in the SquawkBox SDK documentation:

"Offset: 0x7b93 (1 Byte) "Transponder Ident pressed. When the user presses the ident button on your transponder gauge, you should set this value to 1. When SquawkBox notices it is set to 1, it will transmit an ident on the network and reset the value to 0."

So, (to the degree that the current PE Transponder Gauge utilizes this offset and method) it is the gauge logic that resets the value to 0, not the user/pilot. By quickly "toggling" the offset (1 on press, 0 on release), your button press may not be "seen" or effectively nullifies itself. (Depends on the gauge coding and how often it reads the offset value)

In general using a FSUIPC control (if available), versus a ipc.write(offset, value) is more efficient. Many times you have to write to the offset as there is no control function available.

Not sure this is much help. Let me know if there is anything I can do to assist.

Don

Thanks, Don. What development skills I once had have been severely dulled by years of working in project management Despite having a decent comfort-level with C, FSUIPC and Lua is brand new to me...but not completely foreign. This certainly falls under the category of "wouldn't it be cool if". And I agree it is fortunate that enough of the legacy SB hooks are still in the PE client. Transponder mode switching was a breeze. I'm sure the risks of having some of those functions open for those of us who know just enough to be dangerous is...well dangerous

Ok, so now reading that SB resets the value back to 0 once it has transmitted ident message on the network, that certainly makes things easy and definitely worth one more shot. Thanks for the information.