PSX and IO Cards compatibility

[JP59]

Will the future PSX compatible with the IO Cards system ? In other terms will the team release the FSUIPC Offsets such as Project Magenta does ?

Thank you and all the best to all for 2014

[Hardy Heinlin]

Hello,

FSUIPC offsets is MSFS stuff. PSX has nothing to do with MSFS.

The PSX network is easy to handle. No offset hacking required.

Data is sent to and from PSX using simple ASCII text messages via TCP/IP. Each variable has an index and a value.

The network documentation will be available online on the Aerowinx website.

Some hardware interfaces are already available (check FDS), some will follow when PSX is released.


Thank you for your interest!

|-|ardy

[JP59]

Thank you for your reply. My simulator is actually based on IOCards system and Project Magenta. I seriously think about switching to PSX when it will be released and I wonder if the software will be compatible with SIOC. But if you tell me PSX doesn't use variables such as $5214 for example, and SIOC only works with these FSUIPC variable adresses, I think I already found my answer, unfortunately...

But, you speak about FDS hardware compatibility. If I could I'll be ready to switch to InterfaceIT in order to get PSX. But FDS InterfaceIT doesn't handle Encorders and 7 Segment Displays. How will FDS Hardware owners do to program this hardware with PSX ?

[farrokh747]

Hi JP

FDS is working as we speak on compiling the PSX modules for their range of products - this would include CDU's, MCP, EFIS, DSP, RCP, XPDR' and the SYS cards - (have i left out anything?)

Since the 7 segment displays are in the MCP, RCP and the XPDR, this is already accounted for in the modules for those units - so plug and play for these....

Ill leave it to the FDS folks to elaborate further -

In parallel, there is some  plenty (!) work being done on arduino as well -

Once PSX (and the variable data) is officially released, i don't believe it would take too long for other developers to patch their existing hardware/software packages to PSX...

cheers,

fc

[JP59]

I really hope. The problem is that I choose IOCards because I built my MCP myself (with encoders and 7 Segment displays). So SIOC is the only language I can program this hardware with. I do not have choice. I have to keep my IOCards.

I don't know how PSX works, but if the variables have an hexadecimal adress, maybe it will be possible to interrogate, read and whrite inside with SIOC. Do you have an example of PSX variable and the instructions to read/write/interrogate values ?

Thank you for your help

[Jeroen Hoppenbrouwers]

PSX works completely (as in totally) different from anything else out there, as it has been designed from the ground up with hardware flight decks in mind. So it is very easy to interface it with any technology, if you have access to the library that controls the technology and a general programming language.

It won't be a matter of plug and play until somebody or some company produces a complete turnkey interface package. But in all fairness, this holds for any product out there. If you are the first one to try something, you will have to do it all by yourself.

The good thing is that there will be plenty of help available, on this forum and beyond.


Hoppie

[David Z]

PSX will certainly have addresses that you can read directly from. Whether those addresses change from time-to-time and whether it's a good idea to read them is another story.

When you start reading the memory of another program, you already know that there is something wrong with the design of either your program or the host program! Doesn't FSX have SimConnect anyway? It might be a stupid protocol, but it's still cleaner than memory hacks!

PSX will be great from a hardware point-of-view. Have a look at what John Golin is doing. He's planning on using Arduino to control the hardware. You can get Ardionos with RJ45 ports that will allow you to talk directly to PSX over TCP. That means you don't need to scour ebay for $10 Pentium Ones!

If you built the hardware yourself, you might be able to rip out the IOCards and depending on how cleanly you designed your hardware, you may be able to plug it straight into an Arduino (obviously, you'll need to program it, but that's another challenge).

[JP59]

I had a look yesturday and I can now connect SIOC with PSX Router via IOCP client. Now I need to look if I can modify PSX variables with SIOC. I need to look how to do.

[Jeroen Hoppenbrouwers]

Just a heads up: do not modify PSX variables. They are read-only. Instead, just push buttons per the network interface, and let PSX figure it all out by itself.


Hoppie

[Hardy Heinlin]

To be more specific:

Qh variables (buttons etc.) are read-and-write
Qi variables (lights, LCDs etc.) are read-only

E.g. you should never overwrite PSX'S MCP altitude display (this is a Qi). Instead, you should overwrite PSX's MCP altitude selector knob (that's a Qh). PSX will process the selector event and update its altitude display. This display update should be read by the hardware addon.

1. Inject Qh
2. PSX computes a new system status
3. PSX ejects a Qi
4. Add-on reads Qi


|-|

[JP59]

Thank you very much to all for your help ! Thanks to you and this forum, I begin to understand little bit.

I tried to connect SIOC (witch can handle IOCP protocol) with PSX Router. The connexion is ok but I have some trouble when I want to inject values to PSX Router. Here is a screenshot of the PSX Router log after the connexion is established between my SIOC computer (192.168.1.11) and my PSX Router computer (192.168.1.6). What is the message "Missing = sign -- skipped" ?



When I try to send a value from SIOC to PSX Router, the log shows this (see picture below) and PSX Router freeze.



After some minutes, I see the command I sent appearing in the MSG window of PSX Router (see picture below)



My questions are :

What I'm doing wrong with the connexion ?

With SIOC, I cannot set variable name as Qh396. I can only set 396, so when I send a command, I can only send 396=1. Is it ok for PSX or do I need to send Qh396=1 ? Do you have an example of Qh injection script ?

[Hardy Heinlin]

You need to send Qh396=1

There are three Q categories: Qh, Qi, Qs

Qh and Qi are used to transfer integer variables.

Qs is used to transfer string variables.

E.g.:

Qh123=98752

Qi288=-99

Qs305=________POS_INIT____1/3_


I can't help you with your Router question. Is this Hoppie's PSX network test simulation from 4 years ago?


Cheers,

|-|ardy

[JP59]

Yes it is

[Jeroen Hoppenbrouwers]

JP, I fear that you need to completely rebuild that software. It may be able to connect to PSX because it also uses the TCP network connection protocol, but PSX and SIOC do not speak the same language. We are not talking offsets here, we are not talking memory dump addresses.

In short, nothing built for MSFS is going to ever work with PSX.

You need to write specific communication software that translates what SIOC needs in terms of hardware control to PSX network protocol. There's no way around that. But as soon as you get one switch and one light to work, the rest is incredibly straightforward.

Does SIOC come with a lower-level hardware control library?

Are these pages handy?
http://www.hoppie.nl/psxrouter/docs.html


Hoppie

[JP59]

After my yesturday tests, I do the same conclusion as you. SIOC only hold variables as $552E. I cannot assignate Qh... for variable name, unfortunately because SIOC is a good software. I'll have a look to find a software. If I understand, I only need an add-on witch can send ASCII messages to PSX ?

[Jeroen Hoppenbrouwers]

You will not find suitable software, it does not work like that, this kind of software is never written to be so flexible as it would basically end up providing its own programming language to tell it what to do with the ASCII messages. However there is not a lot of infrastructure you need to support these messages, either.

Did you consider contacting the producer of SIOC and inquiring how far they could push it in the right direction?


Hoppie

[JP59]

I do not have the skills to write a program myself and I don't know in what direction to go. I'm waiting for the answer of the SIOC conceptor. Thanks for your help.

[Hardy Heinlin]

By the way ...

PSX does not only require the Qh prefix.

The addon also needs to correctly interprete the value after the "=".

I don't know MSFS, but -- for example -- when the MSFS autobrake selector is in the DISARM position, MSFS may send you a "1" or whatever (I don't know). The same autobrake position in PSX would be coded as "0", for example.


|-|

[Blake H]

I guess like myself, not everyone want to use ASCII hardware like audrino.

Which would be a huge limitation for sales, I would say 99% of builder out there are using FSUIPC and offsets. I could only commit to buy PSX if someone makes a FSUIPC to ASCII interface. Or something for my opencockpit serial port card (now USB) to ASCII Q codes through TCP/IP from PSX.

PMDG 747 v2 will be coming out with offsets this year. So if I can't interface like most people. I will have to go with PMDG 747 v2 or X-planes super critical 747-8 or PM.  

Been in the builder community, I find a lot of guys with extreme hardware desktop set-ups to generic sim which would like to try PSX also utilising there msfs 737, 747 or citation jet ect. With my current flight deck setup I even bust out the Airbus every now and then for fun. I know I am sick in the head. It is just for fun. As I am able to interface with fsuipc.

So I hope there is a solution, because we will  see some unhappy cockpit builders.

Blake Hauswirth
www.747flightsensation.com.au

[John Golin]

I guess like myself, not everyone want to use ASCII hardware.

Which would be a huge limitation for sales, I would say 99% of builder out there are using FSUIPC and offsets. I could only commit to buy PSX if someone makes a FSUIPC to ASCII interface. Or something for my opencockpit card to ASCII Q codes.

PMDG 747 v2 will be coming out with offsets this year. So if I can't interface like most people. I will have to go with PMDG 747 v2 or X-planes super critical 747-8 or PM.  

Been in the builder community, I find a lot of guys with extreme hardware desktop set-ups to generic sim which would like to try PSX also utilising there msfs 737, 747 or citation jet ect. With my current flight deck setup I even bust out the Airbus every now and then for fun. I know I am sick in the head. It is just for fun. As I am able to interface with fsuipc.

So I hope there is a solution, because we will  see some unhappy cockpit builders.

Blake Hauswirth
www.747flightsensation.com.au

I think your don't have the situation correct in your head...

PSX isn't an aircraft, it's an entire simulator AND an aircraft that are inextricably linked.

I guess it's all about expectations - people can't expect to jump between PSX and MSFS and have addon things 'just work' any more than they can jump between XPlane and MSFS and have them 'just work'.

To try to link hardware to PSX via FSUIPC is a bad idea on many levels - not only is it impossible at the moment, to simply scope what changes would be needed to FSUIPC and PSX to handle that would be a massive project, and ultimately totally the wrong way to go about it.  

As with other sims and systems, the correct solution is that hardware vendors (or programmers) interface directly - Hardy has provided a mechanism for them to do this if they choose to - as FDS have done.  I also know there is an interface done for the AerosoftMCP, and FlyEngravity CDU is currently in progress.

As an example, interfaced directly to PSX the Aerosoft MCP now exhibits dimming and test functions that are not available in MSFS / via FSUIPC - the character displays dim with the dimmer knobs, and the LEDs with the dim switch or when a bulb fails.  This hardware from the early 2000's now has a new life because it is not restricted by the FSUIPC interface.