Transponder INC & DEC code defective ??

[N6722c]

Is there somthing know to be defective with the Microsodt Transponder INC & DEC code ?

Not all transponders work in FSX Multiplayer, in that, some do not send updated Squawk codes (to a controller).

The Transponders that do not work use INC/DEC to change their codes.

Transponders that do work Enter Digits into the Transponder from a 0-7 set of buttons.

All Transponsponders work if you use an addon method to write the whole Code to the Transponder.

So FSX MULTIPLAYER is more than capable of sending codes from ALL transponders, provide the INC/DEC method is not used.

Even defining keys with FSUIPC to INC & DEC the Transponder does not, as predicted from the above, cause the Codes to be sent.

The conclusion is, that the INC DEC, while changing the Displayed new Squark Code, does not cause a triggering (event ?) to send the new code from the Pilot's plane through the MP system.

--------------------

Assuming it is an INC/DEC problem, then also, maybe it is an INC DEC problem in FSX Shared Cockpit that causes COM1 radios to get out of sync with each other ?? They CAN be resynchronized with a hidden guage that constantly reads and writes back their values, implying that maybe it is a similar problem to the transponder.

So, I guess my questions are mainly directed to Peter, the expert in these matters ...

(1) Is this a know Problem ?

(2) If so, is this something that MS should be able to fix (they have it working OK on COM2, Nav1, Nav2 etc) ?

(3) If FSUIC aware of this as a problem ?

(4) If this something that FSUIPC could be used to make a "work around", assuming MS will not fix the problem ?

BRUTE FORCE solution is to put a hidden, dummy gauge in each plane (real pain), that does this READ/WRITE to these two Guages every second or so, to FORCE them to operate correctly -- but there has to be a BETTER way ???

Geoff_D

[Pete Dowson]

Is there somthing know to be defective with the Microsodt Transponder INC & DEC code ?

In FS9 or FSX or an older one? I've not noticed. The controls to do that are the same as assignable and usable in FS from the keyboard. Did you check?

Not all transponders work in FSX Multiplayer, in that, some do not send updated Squawk codes (to a controller).

Ah .... you are talking about FSX. AND multiplayer?

Not sure you've come to the right place. I don't think anyone knows much about the innards of FSX multiplayer, as there's no SDK for it. It doesn't look like MS will be releasing one.

By a "controller" you don't mean for on-line flying with one of the virtual ATC systems do you? If so, I don't think they use MP at all in FSX -- the MP in FSX seems to be more to do with flying in the Game Zone.

The conclusion is, that the INC DEC, while changing the Displayed new Squark Code, does not cause a triggering (event ?) to send the new code from the Pilot's plane through the MP system.

Quite honestly, I don't know what you are talking about. I've never been involved with MP at all. I wasn't even aware that it should be sending such things.

So, I guess my questions are mainly directed to Peter, the expert in these matters ...

Sorry, you are wrong. I've never ever dabbled in Multiplayer, nor do I know anything about it, or even much about what it does. I know that in FS2004 and FS2002 programs like Squawkbox interfaced to it, using a documented SDK and interface, primarily to transmit images of the aircraft to other players and theirs to yours. For most other things such programs either interfaced directly to FS, or in some cases, for some information, did so via FSUIPC.

As far as I am aware, in FSX, this system is all dead. Microsoft are not publishing the Multiplayer interface, and encourage on-line programs like Squawkbox and FSInn to instead use SimConnect completely. They are supposed to create the other players aircraft images by creating and controlling AI-type objects. Nothing I'm involved with really comes anywhere near any of this.

Regards

Pete

[N6722c]

My fault, I did not explain the problem clearly enough.

Yes, we are talking about an effect seen in FSX Multiplayer, but I do not believe it is caused by anything in Multiplayer.

(1) We are talking about what happens when the Transponder Gauge is updated, and if that update is recognised as an update, and sent through the FSX MP system.

(I know no MP SDK etc etc... I don't believe it is a MP issue).

The Transponder works fine if it is a type where a new Value is written to the Transponder. Writting a new value to the Transponder is recognised as an event, and the MP system does it job, and the value is sent out to the Controller. ( So the MP part is working OK).

Where I believe the problem is in the INC & DEC functions of the Transponder, that while cosmetically changing the value on the display, does not cause a system event, that triggers the new Code to be sent into the MP system.

If one writes a new code to the Transponder, that write function causes an update (event)....

So, the question is, what is missing in the standard INC DEC Transponder code. Whatever that may be, I suspect only MS can fix that . (and INC DEC tranbsponder would have to be re-comopiled again etc etc)

I thought that this may be a know issue, and if not, I was bringing it to this forums's attention in the hope that FSUIPC could, like it has done so many times in the past, produce a work around for MS's faulty programming.

Maybe this is not the case, I don't know -- I am looking towards the experts here to maybe throw some light on what is really happening.

What I do know is that FSX MP DOES (100% SURE), send the transponder code correctly if the Transponder is update by a "WRITE SQUAWK CODE to the Transponder", and does not if if it updated using the "INC DEC" functions, which seesm to imply, that there may be something defective or missing with those INC DEC functions.

Futher, if the Current Transponder display was READ, and then WRITTEN Back to, the the code would trigger an update event (or whatever the process is), and the code would be sent into the MP system.

So, some 3rd part program, that constantly READ, and then WROTE back to the Gauge the same value, would seem to FIX (work around) the problem.

If this is the case, could this possibly be one additional function that FSUIPC could perform ? (rather than having to run yet another background program to perform this trivial work-around function).

[Pete Dowson]

(1) We are talking about what happens when the Transponder Gauge is updated, and if that update is recognised as an update, and sent through the FSX MP system.

I didn't even know the MP system was so pro-active. Do the MP packets contain everything about an aircraft?

(I know no MP SDK etc etc... I don't believe it is a MP issue).

But if it changes on screen, and is recognised by everything else as being changed, and only the "MP system" is excepted, then surely it must be an MP issue?

The Transponder works fine if it is a type where a new Value is written to the Transponder. Writting a new value to the Transponder is recognised as an event, and the MP system does it job, and the value is sent out to the Controller. ( So the MP part is working OK).

Where I believe the problem is in the INC & DEC functions of the Transponder, that while cosmetically changing the value on the display, does not cause a system event, that triggers the new Code to be sent into the MP system.

Well, I'm not sure what "events" these are. The Simconnect interface for this certainly works 100% -- including using the XPNDR_1_DEC/INC, 10, 100 and 1000 controls. They all change the actual transponder value and the changed Transponder code is sent to any Simconnect clients who've asked to receive such changes.

So, the question is, what is missing in the standard INC DEC Transponder code. Whatever that may be, I suspect only MS can fix that

.

Well, yes, it is their code. And as it does only appear to affect the MP system it explains why I really have no idea. There's nothing in any of my explorations in this or previous versions of FS which overlaps with MP I'm afraid. Sorry.

I thought that this may be a know issue, and if not, I was bringing it to this forums's attention in the hope that FSUIPC could, like it has done so many times in the past, produce a work around for MS's faulty programming.

Only in areas I know, and I'm afraid MP is not one. There's nothing appearently wrong with the Transponder stuff in all the areas I deal with.

Futher, if the Current Transponder display was READ, and then WRITTEN Back to, the the code would trigger an update event (or whatever the process is), and the code would be sent into the MP system.

What methods are you talking about for these "reads" and "writes"? SimConnect? You are talking a slightly different FS language to the one I know. Are you talking as a Gauge programmer?

If you think there is a bug, have you sent it to FS? Try reporting it, in detail, via tell_fs@microsoft.com.

If this is the case, could this possibly be one additional function that FSUIPC could perform ? (rather than having to run yet another background program to perform this trivial work-around function).

Well, if this is simply a SimConnect "TransmitClientEvent", yes, it could be done. But I'd really very much prefer that it be fixed at source. After all, Microsoft are actively changing things at this moment. Do you want me to submit it to MS on your behalf? There's no way I can provide corroborating evidence as I've never used MP and don't realy want to start now. It would be better coming from you directly if possible. If you are quick it might even make it into the forthcoming SP1 update.

Regards

Pete

[N6722c]

(1) We are talking about what happens when the Transponder Gauge is updated, and if that update is recognised as an update, and sent through the FSX MP system.

I didn't even know the MP system was so pro-active. Do the MP packets contain everything about an aircraft?

(I know no MP SDK etc etc... I don't believe it is a MP issue).

But if it changes on screen, and is recognised by everything else as being changed, and only the "MP system" is excepted, then surely it must be an MP issue?

The Transponder works fine if it is a type where a new Value is written to the Transponder. Writting a new value to the Transponder is recognised as an event, and the MP system does it job, and the value is sent out to the Controller. ( So the MP part is working OK).

Where I believe the problem is in the INC & DEC functions of the Transponder, that while cosmetically changing the value on the display, does not cause a system event, that triggers the new Code to be sent into the MP system.

Well, I'm not sure what "events" these are. The Simconnect interface for this certainly works 100% -- including using the XPNDR_1_DEC/INC, 10, 100 and 1000 controls. They all change the actual transponder value and the changed Transponder code is sent to any Simconnect clients who've asked to receive such changes.

So, the question is, what is missing in the standard INC DEC Transponder code. Whatever that may be, I suspect only MS can fix that

.

Well, yes, it is their code. And as it does only appear to affect the MP system it explains why I really have no idea. There's nothing in any of my explorations in this or previous versions of FS which overlaps with MP I'm afraid. Sorry.

I thought that this may be a know issue, and if not, I was bringing it to this forums's attention in the hope that FSUIPC could, like it has done so many times in the past, produce a work around for MS's faulty programming.

Only in areas I know, and I'm afraid MP is not one. There's nothing appearently wrong with the Transponder stuff in all the areas I deal with.

Futher, if the Current Transponder display was READ, and then WRITTEN Back to, the the code would trigger an update event (or whatever the process is), and the code would be sent into the MP system.

What methods are you talking about for these "reads" and "writes"? SimConnect? You are talking a slightly different FS language to the one I know. Are you talking as a Gauge programmer?

If you think there is a bug, have you sent it to FS? Try reporting it, in detail, via tell_fs@microsoft.com.

If this is the case, could this possibly be one additional function that FSUIPC could perform ? (rather than having to run yet another background program to perform this trivial work-around function).

Well, if this is simply a SimConnect "TransmitClientEvent", yes, it could be done. But I'd really very much prefer that it be fixed at source. After all, Microsoft are actively changing things at this moment. Do you want me to submit it to MS on your behalf? There's no way I can provide corroborating evidence as I've never used MP and don't realy want to start now. It would be better coming from you directly if possible. If you are quick it might even make it into the forthcoming SP1 update.

Regards

Pete

Peter

I will submit the problem as a bug once again on the CONNECT site.

I do not hold out ANY hope for it making into SP1 - I am sure you appreciate why, but I will at least try once again.

However, if after SP1 is released (and your corresponding work load reduces), maybe you would consider adding the required processing to FSUIPC to effectively make the Transponsers in question functional in MP, by the READ-WRITE process. Once again, it will be a case of Peter Dowson's FSUIPC correcting problems in MS code @!!@.

As you are probably aware, there is a growing interest in using the FSX MP system, and , for example, FS-MP, as a fast growing FSX MP Community of over 1000 members, would dearly like to start using Transponder Codes in our sessions.

Knowing that if MS does not fix the issue in SP1, then FSUIPC will provide a work around (hopefully in the non registered mode), would allow us to plan ahead, and use the Transponder as an integral part of our sessions.

Geoff_D

[Pete Dowson]

I will submit the problem as a bug once again on the CONNECT site.

Ahyou are the "Geoff D" on the Beta group? Why aren't we discussing this there, then?

However, if after SP1 is released (and your corresponding work load reduces), maybe you would consider adding the required processing to FSUIPC to effectively make the Transponsers in question functional in MP, by the READ-WRITE process. Once again, it will be a case of Peter Dowson's FSUIPC correcting problems in MS code @!!@.

Well, FSUIPC4 is of course always receiving changes in the Transponder code, so it can populate the Offsets and supply such values readily to its own clients. If you think that a simple TransmitClientEvent back to SimConnect, presumably of an XPNDR_SET control, might "fix" it, then I can add it in now for you to try (just in case, as it were).

What would worry me, however, is the latency imposed by SimConnect's use of TCP/IP asynchronous stacks and the associated queues. Supposing someone is incrementing through valuesx, x+1, x+2etc. By the time FSUIPC received the x+1 value the actual transponder might be already on x+2, and if FSUIPC then transmits the x+1 back, by the time that arrives the correct value might be x+3. This would effectively end up in a never-ending loop with nothing actually getting done properly at all!

The only possible way out of that I can think of is for FSUIPC not to send any changed value until it has remained unchanged for a period of time, perhaps as much as a second. There's still a possibility that this would conflict with another change though.

Knowing that if MS does not fix the issue in SP1, then FSUIPC will provide a work around (hopefully in the non registered mode), would allow us to plan ahead, and use the Transponder as an integral part of our sessions.

I wouldn't agree to it unless the above worries are resolved. I may have to insert some test code, with an adjustable delay (milliseconds up to several seconds), and only set the code as permanent after thorough testing.

Regards

Pete

[N6722c]

I will submit the problem as a bug once again on the CONNECT site.

Ahyou are the "Geoff D" on the Beta group? Why aren't we discussing this there, then?

However, if after SP1 is released (and your corresponding work load reduces), maybe you would consider adding the required processing to FSUIPC to effectively make the Transponsers in question functional in MP, by the READ-WRITE process. Once again, it will be a case of Peter Dowson's FSUIPC correcting problems in MS code @!!@.

Well, FSUIPC4 is of course always receiving changes in the Transponder code, so it can populate the Offsets and supply such values readily to its own clients. If you think that a simple TransmitClientEvent back to SimConnect, presumably of an XPNDR_SET control, might "fix" it, then I can add it in now for you to try (just in case, as it were).

What would worry me, however, is the latency imposed by SimConnect's use of TCP/IP asynchronous stacks and the associated queues. Supposing someone is incrementing through valuesx, x+1, x+2etc. By the time FSUIPC received the x+1 value the actual transponder might be already on x+2, and if FSUIPC then transmits the x+1 back, by the time that arrives the correct value might be x+3. This would effectively end up in a never-ending loop with nothing actually getting done properly at all!

The only possible way out of that I can think of is for FSUIPC not to send any changed value until it has remained unchanged for a period of time, perhaps as much as a second. There's still a possibility that this would conflict with another change though.

Knowing that if MS does not fix the issue in SP1, then FSUIPC will provide a work around (hopefully in the non registered mode), would allow us to plan ahead, and use the Transponder as an integral part of our sessions.

I wouldn't agree to it unless the above worries are resolved. I may have to insert some test code, with an adjustable delay (milliseconds up to several seconds), and only set the code as permanent after thorough testing.

Regards

Pete

Pete,

For all practical purposes, a delay of up to 5-10 seconds before implementing the READ-WRITE would be fine.

As far as the Pilot is concerned, the display changes as he INCs & DECs.

As far as the controller is concerned, he is not aware of the exact time that the pilot changes the code, but provide he gets an update in 5-10 seconds, he is happy. This should avoid any race conditions that you are worried about.

ie. Transponder has to be at the same value for 5 seconds bfore FSUIPC does a READ-WRITE, and then not do any more WRITES until the transponder has changed from the last value when it was WRITTEN, and has once agan been stable for 5 seconds.

ACTUALLY: This is far more realistic that INSTANTLY changing the Transponder, as, in real life, a Controller will not see a Transponder update from the pilot until the Secondary Radar swept through the Pilots bearing, and received a response from the Radar's Transponder Interrigation. Typical SSR rotation speeds are 5-10 sec/rev.

Should be fine -- and like most of your "fixes", maybe it could be something that the user can select, so, if for some unforseen reason it caused a problem with some other systems, the user has the option to turn it on or off. ( Default is OFF).

I would be delighted to test any "test coded FSUIPC" and report back to you with the results both in FSX Multiplayer (where it is needed) as well as test for any undesirable effects in Free Flying, or when on Vatsim.

Regards

Geoff_D