BMS MISSING SHARED MEMORY BITS

[Nigel]

Guys please list any SHMEM bits that you think are missing or are needed and I will ask the Dev's to see if we can add them. This is not a feature request thread, you can ask that on the public forum. This is specifically for cockpit builders including desktop of course. I posted this for the UHF problem, but any other missing bits are welcome.
   Also, dont confuse this with the Beta Innovations issues in a separate thread, that is specific to Beta Innovations only. That one is for his software not responding to SHMEM bits already there.

[KK]

missing or are needed and I will ask the Dev's to see if we can add them

Great idea.

What's definitely missing in the SharedMem is the current HUD brightness level.
We can fire keystrokes INC/DEC to change the brightness level but this is just fine for gamer's with keyboard.
The simpitters with analog thumb wheels on the ICP need the current level in order to properly synchronize BMS with the pit.

It would be great to have it in the form [0,1,2,3,4,5]  where  0=OFF, 5=max brigthness
or
float [0 ... 100%]  if it makes them happier.

More to come ...
Klaus

[Focaldesign]

In game time for the analogue clock (and for standalone clock for GCI/Awacs/ATC).
And in viewpoint of ATC, wind (speed & direction) & QNH would be nice too

[Nigel]

missing or are needed and I will ask the Dev's to see if we can add them

Great idea.

What's definitely missing in the SharedMem is the current HUD brightness level.
We can fire keystrokes INC/DEC to change the brightness level but this is just fine for gamer's with keyboard.
The simpitters with analog thumb wheels on the ICP need the current level in order to properly synchronize BMS with the pit.

It would be great to have it in the form [0,1,2,3,4,5]  where  0=OFF, 5=max brigthness
or
float [0 ... 100%]  if it makes them happier.

More to come ...
Klaus

Klaus,
Already in, go to Setup, Controllers, Advanced then Avionics Control and assign a pot to the HUD brightness analog controller.

In game time for the analogue clock (and for standalone clock for GCI/Awacs/ATC).
And in viewpoint of ATC, wind (speed & direction) & QNH would be nice too

I will ask.

[Red Dog]

Just an inside note:

Sometimes, the coders expect the users to use a combination of different bits to get the expected results.
Don't think about one bit only but use combination of different bits.

Or understand that what you may be requesting is actually already implemented, but though of in another way

the analog values of the hud brightness is an example, it's not required if you use the system how it was intended to be used
When you wire a pot and declare it in the UI as HUD brightness, then when you enter 3D, the HUD brightness is defacto adjusted to the pot position, so no out of sync issues. It works just like a joystick, you don't have to centre your HOTAS before entering the pit
Same for other analog controls.

Beside, also understand that adding bits often means renumbering them is there is a very high chance of loosing backward compatibility with older (or even current) shared memory applications.
It's a request that dev consider very carefully and we should thank them deeply for that

[The_target]

In game time for the analogue clock (and for standalone clock for GCI/Awacs/ATC).

I thought it was already in FlightData2.currentTime. Am I wrong ?

Liquid oxygen on the Right Aux : But it's a nice to have

[Red Dog]

I think it's indeed in Flight data 2
AltCal reading (not per se QNH, but often is)
&
CurrentTime

although it may need additional parameters (or conversion) to get exactly what you need

Guys, there is an applet called BMSFlightData in your tools folder, there you can see it all

[KK]

When you wire a pot and declare it in the UI as HUD brightness, then when you enter 3D, the HUD brightness is defacto adjusted to the pot position, so no out of sync issues. It works just like a joystick, you don't have to centre your HOTAS before entering the pit
Same for other analog controls.

Thanks a lot guys for your prompt response. I have seen that and it surely is the solution for pots that are known to the system and found by the UI. This is unfortunately *not* the case for the pots that are connected to the PHCC mainboard. The OS doesn't know them
because they are not hooked into the system with a proper device driver.
It would have been so easy to solve this problem if I had that feedback value in the shared mem..
I cannot write a device driver for those pots as I don't have that knowledge.

[Focaldesign]

I think it's indeed in Flight data 2
AltCal reading (not per se QNH, but often is)
&
CurrentTime

although it may need additional parameters (or conversion) to get exactly what you need

Guys, there is an applet called BMSFlightData in your tools folder, there you can see it all

I was thinking in line of F4Awacs or sort like programs, without having to be in 3D. But that isn't possible via sharedmem then of course, I now realise

[Nigel]

RD,
I should have consulted you on this, you have WAY more experience with this stuff and your advice will be invaluable. If you could address some of these issues and figure out the best way to proceed it would be great. I feel like the Dev guys are willing to help and between us as pitbuilders we can raise awareness and move forward.

[Red Dog]

Well, i have been on that road quite often and dev wisdom always prevails.
keep the request coming, but i feel indeed that before going back to the dev, we should make sure there is no other way to achieve what we want to do in our pit. because if there is, the dev will point us to it and tell us to use the system as it's intended.

the other aspect is the one presented by klaus.
it's a specific request based on his own interfacing decision.
the system actually provides what he wants but not in the configuration he uses, because the configuration is specific to him

In these cases, it's hit and run to get a blessing from devs. It really is going to depend on the pros and cons of adding such support. If there is the slighest chance that it may break backward compatibility with shared mem readers, the decision will probably be no, we won't do it.
let's face it you can't break a system used by many to please a single guy.
if on the other hand the dev think the costs and risks are low, they will most certainly aim to please (barring their development time and mojo) i'd say

So keep the request coming, it's good to have these questions addressed anyway - but don't anyone be offended if the answer to your request is initially a pointer to where the feature already is implemented

[Nigel]

Agree 100% Olivier. Klaus, I dont understand how PHCC works that is different from any other system. Don't you also have analog pot inputs somewhere on a PHCC card?

[Willy]

Agree 100% Olivier. Klaus, I dont understand how PHCC works that is different from any other system. Don't you also have analog pot inputs somewhere on a PHCC card?

The problem is that the PHCC hardware/software doesn't emulate a Joystick with its analog axis.  I don't think it is reasonable to get the BMS devs to make a special interface for PHCC so I don't think this request should be included. 

Instead, PHCC types need to come up with a way to make the PHCC pots look like a Joystick axis.  I'm pretty certain that is what Lightning's JoyMapper software does via PPJoy drivers. 

Here's the excerpt from Lightnings readme.md file from his GitHub Repository on JoyMapper.

JoyMapper
Desktop application for remapping analog and digital inputs from DirectInput devices, BetaInnovations non-Joystick-class HID devices, and PHCC devices using PPJoy virtual joystick drivers.

@KK, if I were you and you are not using Lightnings code, I would download the JoyMapper C# code and write your own C++ version that does the same thing.  I'll bet it wouldn't be too hard to convert that code from C# to C++.  (But I could be wrong about that.)

[KK]

I dont understand how PHCC works that is different from any other system

Nigel,
PHCC is not a solution like others where everything is presented on the silver tablet with its price tag on it.
There is nobody that you can call up for support 8 am - 5 pm.
PHCC is for freaks. It is a solution that offers total freedom to do whatever you want.
Best example for this is Henkie with his wealth of additional boards etc.

PCBs, Firmware, Protocols, etc, is all available in source code.
No hardware delivery dependency from any person. Send the files to a China etcher
and get as many boards as you like. Soldering is up to you.
And also application programming is totally up to you.
This is the good and the bad. If you can't program an interface program between your pit and the PHCC motherboard, then PHCC might not be for you.
Lightning has developed a solution based on .net/C# that can be taken.
But again you should have some skills to adapt that.

Now back to your question with the pots on PHCC.
YES, the PHCC motherboard has direct inputs for pots (3 of them fast scanning).
BUT you will see the change of the pot only in the communication protocol with the PHCC mobo.
This information is not promoted any further into the OS of your computer with the aid of a device driver.
To my knowledge nobody has done this so far.
So the solution with pots in the BMS UI for display brightness doesn't work.

I was hoping to find an open ear for putting the current value of the HUD brightness into the shared mem.
No problem with backwards compatibility. The developers have extended the shared mem so many times with
additional sections that is won't hurt at all. To me it would be the clean solution to have this extra info in there.
Of course I can program around. Sending 5 INC's to make the maximum brightness, reading my current analog value and the sending DEC's until it matches with my pot. Done. Not a problem. But its a dirty solution and I hate to make workarounds for the shortcomings of a solution if it could be done better.
 
 

 

[Red Dog]

No problem with backwards compatibility. The developers have extended the shared mem so many times with
additional sections that is won't hurt at all. To me it would be the clean solution to have this extra info in there.

First that's an easy way out when you are outside the dev team -  We all tend to believe that solutions are easy when you are not responsible for carrying them out. Being on the inside of the dev group for more than 10 years, I have been on that path myself quite often requesting things from coders.
And from that experience, I can attest that they usually are taking the right decision. ANd yes they turned my request down quite often and showed me the intended way to work the problem out. And yes sometimes, that meant doing a bit of extra work

What would happen if dev would add each time a subsection when one pitbuilder requests something specific due to his own philosophy?
In 5 years, chaos and a completely unorganized shared memory.

Thankfully the shared mem remained pretty well organized and pretty well controlled thanks to the dev's vision, and most specifically one guy's wisdom
I wish it remains so in the future.

That doesn't meant your request is going to be denied today, it means it needs to be properly evaluated as I said above.

So keep the request coming, it's good to have these questions addressed anyway - but don't anyone be offended if the answer to your request is initially a pointer to where the feature already is implemented

The argument you used could be fairly returned to you as well:
Why can't you simply add a device driver interfacing 8 pots (Leo Bodnar BU0836 comes to mind) apart from your PHCC system and connected to your computer to implement these axis like they are meant to be interfaced? (there is actually much more than the single HUD brightness, FLIR and backup reticle comes to mind as well)
It's no different than a HOTAS system, Is your HOTAS part of your PHCC system??

If there is no real benefit in implementation to be gained by going through the PHCC system, why should the dev team work more so that you can work less?
If there is an obvious benefit, then the question is different, but is there? 

[Nigel]

Klaus,
I dont know anything about the protocol or limitations of PHCC other than what I have read. I see there are boards that have analog pot inputs so I dont know what the answer is, it's confusing to me when the strength of PHCC is flexibility but you say analog pots wont work? It hasnt been done, but is it possible? I see a need for it, maybe its time to make one. Regarding the inclusion of the HUD brightness in the SHMEM, along with what RD says, the Dev team has only so much time and resources to work on things and at this point the analog inputs for the HUD pots as well as all the other pot inputs is a perfect and elegant solution. We can ask for it in SHMEM but I think it would be considered done at this point for now. I would think the pot inputs would be motivation to develop a way to make it work with PHCC instead of the other way around. This seems to be a major limitation for PHCC in my mind, every pot input need for building and flying a pit is in or will be so I see it as a necessity for any system. I am sure Henkie is reading this, so lets ask him. Henk, what are the chances of making a PHCC interface for analog pots, lets say a dozen?

[henkie]

 
PHCC already has 35 analog inputs (that should be enough for our pit).
All analog inputs are on the PHCC Motherboard. If you need more than 35 analog inputs, the only solution with PHCC is a second Motherboard.
The Motherboard supports 32 "standard" analog inputs and 3 "fast" analog inputs. The difference between the "standard" and "fast" inputs is that the "fast" inputs are directly connected to the PIC, and the "standard" inputs are read via an analog multiplexer (CD4067). All analog inputs operate with a 0 to +5V working range. Klaus knows all this.
But, as usual with PHCC, on the software side of things you are on your own ...
I am still building/soldering/wiring/testing etc. so the software side of things stills lies ahead of me 

[Willy]

This analog interface issue is just another reason I moved to Pokeys 57U.  It does just about everything (except Steppers and Aircores) that the PHCC solution does.  We are looking into adding support for the Pololu Steppers to the F4toPokeys software as well as adding support for the native Stepper motor functions available in Pokeys.  (After all, Pokeys main market is for CNC builders which of course use Steppers.)

Of course if you have invested in all the PHCC stuff, I can understand not wanting to move away from it.  This is where I "thought" Lightnings software would take the PHCC analog inputs and make them look like a Joystick.  That would give you direct interface into BMS.

My $0.02 worth.

[lightning]

Just to add to Willy’s post - Joymapper uses a very obsolete joystick virtualization driver called PPJoy which, because it is not a signed driver, requires that you temporarily disable driver verification - which is a bit of a process.  You can Google for the steps involved with that...after which you can install the PPJoy driver and then configure a virtual joystick in PPJoy with the axes you want to use as inputs to BMS.  Then you can use a tool like JoyMapper to read the PHCC inputs and map them to PPJoy virtual axes which will be seen by BMS as regular DirectX joystick axes inputs. However - if PPJoy is connected to the PHCc via serial port, no other program can be (that’s how serial ports work - only one program can connect at a time). There are further commercial solutions like Eltima Virtual COM Port that can replicate an underlying physical serial port to enable multiple programs to read from the port simultaneously - but you’re better off just implementing a virtual joystick axis in your own code.

I’d recommend steering clear of PPJoy & JoyMapper and using vJoy instead.
http://vjoystick.sourceforge.net/site/index.php/download-a-install/download

[Willy]

Thanks for the info, Dave.

[henkie]

Having had a brief encounter with José Saraiva's SimLinkUp Manager, I thought that SimLinkUp together with vJoy was a working solution for the analog inputs.
At the time, I was not ready for testing, and I still am not 
Things progress way too slow and RL also messes up plans too often 

[lightning]

That was essentially a third-party “fork” of SimLinkup taken from the mainline code as of several years ago, never kept in sync with the mainline code.  To the best of my knowledge the author(s) of that fork have not merged the mainline code into their project in a way that could be contributed back to the mainline.

[roccio]

I would like to have the internal light status.
Thank you.

[Willy]

I would like to have the internal light status.
Thank you.

Can you be a bit more specific?  What "internal" lights?

[Focaldesign]

I'm assuming flood light and or console backlight.
If that's known, the YAME gauges can change accordingly

[Rufus]

That would be nice...or is it already mech - in a similar manner to the HUD analog inputs?

...and I've gone to Pokeys for the same reasons Willy did...+1, Willy... !

[roccio]

yes, as focal just said. usefull for external extractions to light instruments correctly.


another thing that i miss is the overg flag for negative gs and a flag if player is dead.

[Red Dog]

For the lights, can't you set a hotkey - which when configured to the same callback as falcon will switch on gauges backlight?

You need a configurable hotkey (two actually if you don't want to use toggles - which are always a pain) because there are obviously multiple different key files.
But that should work pretty well. If I remember right that's how the old MFDE did it, at least for Nvgs

For the G's just look at the Gs Vars and once it goes negative to a set value, you have your overG

Why do you need  a flag when the player is dead?
I guess when he's dead, the game end, no?

[roccio]

yes, i can use a key for lights, will go that way.
for the gs in shared memory there is a overg flag, but it's fired only for positive g, so i can simulate a blackuot. For the negative g, i would like to do a redout, but the flag is not set in shared memory, so it's more complicated to sync with falcon.

The dead flag is just to show a black screen meanwhile you exit the 3d world. just eyecandy.

[Willy]

If you want to adjust how YAME renders the instruments, then I don't think you want a bit. Instead you want a numerical value (integer should suffice) that indicates the level of light of the Flood lights or Instrument Backlight (or both). 

[roccio]

yes willy, that's what i wish

[Rufus]

If you are using a key for lights (or anything else), can't you use an encoder and count pulses to dictate a number/key of keystrokes sent? 

One more vote for Pokeys on this point... ...

[roccio]

and one other thing i forgot to mention. it would be nice to have bullseye coordinates also.