Hardware switch

[JackZ]

Hello again

In the Wiki, when I look at the hw_switch add function, it reads:
" You can choose to bind to an existing Hardware ID (Hardware_id_list), or define your own Hardware ID, which you can dynamicly couple to an external type of hardware, such as the Teensy or Arduino."

I know it's still a work in progress, but does that mean it will interface with a Teensy or Arduino in the future?
Quite an interesting prospect! Could you elaborate more on that?
What inputs are expected on the AM side (text, byte?) If I can help on the Arduino side, I'll try my best.

Jacques

[Corjan]

Hi,


I'm sorry to say, but that text on the wiki is outdated.

We have had allot of discussions about that type of platform we should build for first. Teensy, Arduino or Raspberry.
At first we wanted to go for arduino and teensy, but we have changed out mind to the raspberry in the end.

Since the hardware API is not fixed to any type of hardware, we still have the option to support the arduino later on.
We had the plan to develop one program for the arduino, which will be able to connect to the AM desktop using USB. So you can determine what the pins should do in the lua script.
If you feel like it, I'm open to share the AM sources with you, so you could give the arduino implementation a go. All sources are written in C.


Kind regards,
Corjan

[JackZ]

Ok Corjan thanks for your offer.

I'll keep in touch with you by PM to see if I can help. Not a professional programmer though, but I understand C
What is your cross-platform development environment?

Jacques

[jmig]

Just so I understand correctly. Since Air Manager is interfaced with the flight sim program, any external switch/encoder, etc that addresses one of the sim's registers through FSUIPC and an I/O card, should work with the Air Manger instruments? For instance setting the altimeter. If I have an encoder programmed to adjust the SET ALTIMETER offset through FSUIPC, the AM altimeter gauges should reflect the change. Right?

John

[shadyowl2]

I use LINDA to interface my switches and encoders to FSX and Air manager reads them just fine.

[JackZ]

. If I have an encoder programmed to adjust the SET ALTIMETER offset through FSUIPC, the AM altimeter gauges should reflect the change. Right?

John

John you are correct.
As long as the variable changed by a hardware switch or encoder through whatever interface card(Pokeys, Arduino, Open Cockpit, LeoBodnar, to name a few) is a Simconnect variable, there's no problem.
The Hardware-->Fsim--> Simconnect-->Air Manager path works well, as here AM doesn't KNOW that the input is coming from hardware. It'the other way around that poses problem.

The problem resides with AM gauges which have no Simconnect/Xplane variables counterpart (even via Simconnect or Lvars for a specific addon) for some of their buttons/switches/dials, for example the ASPEN EFD1000.

In this instrument, the menu, range button, and in fact all the buttons cannot be accessed via hardware, unless using the workaround to emulate mouse clicks on AM dials/buttons using programs such as Key2mouse, Joy2key, Fsuipc or AutoHotkey on Windows and JoystickMapper on Mac for example.
Some of these buttons do not even interfere with FSX/Xplane, such as Zoom or TPS, they only are interpreted by AM to change the internal behavior/display of the gauge.
Don't know Linux equivalent of these smal utility programs but pretty sure it exists.

Hence my suggestion for at least a basic counterpart of the AM mouse/touch events for the dials/button/switches via keypresses. This will avoid having to deal directly with HID devices, since all this part is handled by the programs above mentioned.

Jacques

[russ]

Is this a very BIG problem? Are you talking about things that , since there is no Lvar available, need to be access in some other way (offsets?). This wan't a problem with the Twin Otter. Is it very common?

I would favor creating a way for Air Manager to do this without FSUIPC or LINDA as that is our ultimate goal. We want to SIMPLIFY the sim building process by offering a single tool that can do the whole job. To reduce the number of moving parts and require only a single tool to communicate ( two way) with the sim using screen based or hardware controls.

Please, help me to better understand what is needed.

[JackZ]

Let me try to explain:
The key is of course to avoid using third party program to interact by hardware with AM instruments.

There is two cases:
1- So far, whenever it exists a standard Sim variable in Simconnect/Xplane (such as moving the heading bug for example) It is easy to interface such a dial with hardware, as AM is directly informed by FSX/P3D/XP itself that the AP heading has changed, and moves the heading bug accordingly, provided that the corresponding variable has been monitored. In fact this is a two step process, one variable to change the behavior of the instrument, and the corresponding event to allow a manual change of this very variable through mouse or touch gesture on the AM dial.

Be it with Linda, Arduino, Open Cockpit or whatever hardware interface, in fact AM doesn't even know that it's driven either by a real hardware that updates directly the Fsx variable OR by changing the variable directly from the screen on AM dial via mouse gesture.

2- Now let's assume that an AM gauge has a switch to turn on/off certain features such as GPS display or the keys of a MCP. The switch is declared in the Lua program and will react as usual via a mouse or a touch event.
But nothing comes from the Sim, and nothing goes to the sim, since this switch is specific to this AM instrument and there is actually NO event nor variable in the sim (and of course No Lvars) that exist in Simconnect or Xplane and that can be monitored/acted upon....
The only way up to now to interact via hardware with this type of AM button/dial is via a third party program that emulates a mouse click on the screen when activated by a specified keypress or joystick button, keypress/button press sent by the hardware card that either act an HID device such as a Keyboard or a mere joystick, such as Leonodnar interface card.

To address the case number 2, a very basic direct mapping with keypresses along mouse/touch events would be the easy solution to avoid any "man in the middle", and also avoid the HID complexity when dealing with devices as different as USB yokes, quadrant, joysticks, etc... Only keypresses, even the Simconnect/Xplane plugin is not needed in that case!

Did I mention that if such basic keypress existed (I didn't say keyboard as AM doesn't need to know what type of hardware actually generated the key press, be it via a keyboard or a joystick or an interface card), the case number one would also be simplified as there would be no need to monitor the Sim variable?

Of course, one can imagine interesting application through AM inter communication variables, such as a hardware switch operated on a remote computer that actually triggers an AM variable and the corresponding AM gauge on another computer or an IPad that monitors and reacts to the same AM variable.

Hope I made this clear!

Jacques

[russ]

I think I get it. You are saying that AM should have a function that would allow the user to program a simulated mouse click on the remote sim screen? Is that the gist of it? It seems fairly simple to add and doesn't require FSUIPC or Linda...but would add functionality to use controls that have no Dataref/Variable/Lvar/ Event/X-Command ?

One question if I have this right: How can you be sure the mouse click target hasn't changed as the view might be changed. Is such a reference point good from session to session. In X-Plane I am not sure how this would work since I don't think there is away to configure the view from session to session. We do want to maintain Cross platform as much as possible.

I saw a product several years ago that this reminds me of. Of course it went a bit further. It was FS Displays (formerly FS Spy) that allow one to capture a screen rect from the sim and transmit (stream) it to a window on a remote computer. For example if you had a GTN750 in an undocked window in FSX, you could transmit that in real time to a remote computer to use in a cockpit. It also allow clicks to be sent back to the sim. Sadly the founder died recently and it is questionable where this might go in the future...if it even survives the loss. The website hasn't changed in months.

http://www.fs-displays.eu/

I thought it was a novel way to reproduce complex graphical glass displays to a sim build without the thousands of hours required to reinvent the wheel with Air Manager. I even asked Corjan if such a feature might be possible to have such a feature in AM but this wan't really practical considering how our ideas are already years ahead of programming manpower.

[brodhaq]

Just an idea - what prevents you from creating your own Lvar or X-Plane dataref for this "custom" switch? You could for example create a boolean dataref for your switch, use your whichever I/O card to controll this switch and just read its state using AM (or vice versa - control a custom dataref by AM and read the dataref value by your IO card for example for LED output). Creating Lvars can be done using custom LUA script running under FSUIPC (or maybe even in the gauge XML file), registering a custom dataref in xplane is possible with just any plugin (or if you dont want to write your own plugin you can use Gizmo or preferably SASL to simply script that).

This is actually the way I am going to give a try with my build in few months when I move from hardware to software phase of my build. I am not very impressed the idea of SimInnovations to create their own I/O hardware, so I am going to use my current I/O (which is arduino - ethernet - xplane) to control my own dataref and access them using AM. Hope it works, not tested yet

Ironical how LUA is just everywhere... AM runs LUA, FSUIPC runs its own LUA scripts, and for X-Plane we have LUA interpreters like SASL, Gizmo or Flywithlua...

Pavel