[FS2020 and FSUIPC character and input detection - rotary encoders]

At last!

I could test the new FSUIPC with my keyboard emulator: Every keystroke is registered when keyboardhook is on. This works fast enough for rapid turns on encoders.

Best of all for me is that FSUIPC discriminates between left shift and right shift, left ctl and right ctl, left alt and right alt and even left gui and right gui and any combination of these. Together with, i.e., F13 to F24 keys this is more enough to not conflict with any default shortkeys.

Thanks,

Detlef

[FS2020 and FSUIPC character and input detection - rotary encoders]

Hi John,

I am very sorry for the long delay. I have been very busy last time and will be the next days in future. I will tell you my findings then.

Detlef

[FS2020 and FSUIPC character and input detection - rotary encoders]

Hi John,

the code is no secret. I put it here together with the compiled utility program in the 'Release' folder:

https://www.jottacloud.com/s/08862521f62b0504d59a7b21f6077666be7

Consider that it's a work in progress and not yet finished. The KBD03Link.cfg configuration program uses keyboard commands otherwise unused by the default settings of MSFS. The utility program filters these inputs without removing them from the keyboard event queue. So every keystroke is transparent and can also be used by other programs. I am programming simultaneously while MSFS is running for testing the code. It doesn't affect each other.

If you want to have a look at my hardware, I could send you a sample board (40mm by 40mm) for tests as a typical custom keyboard.

Detlef

[FS2020 and FSUIPC character and input detection - rotary encoders]

Hi there,

this is a rather old post, but it addresses my problems too. I have a self made hardware (sold by DesktopAviator) which fully emulates a keyboard. Keystrokes are rarely recognized by MSFS and only if I set key down and key up times rather long (~50ms). So I tried to use FSUIPC as an interface, but I learned from several posts here that FSUIPC relies on MSFS according to key inputs. My final solution was to write a little program which hooks into Windows' keyboard input queue and connects to MSFS via SimConnect. This is independent of who has the focus, and it works fast. I can even implement a fast/slow feature for encoder inputs: turning fast sends 4 characters per detent while rotating slow gives just 1 character per detent. Couldn't FSUIPC have also such a keyboard hook, eliminating much of the problems MSFS has with custom-made keyboards?

Best regards
Detlef

 

[Desktop Aviator Panel in MSFS2020]

I don't know whether josh23913's problem is still existent. When I attach a Desktop Aviator product to the PC and select "Button & Switch assignments" from FSUIPC7 I can clearly see the joystick and assignment works well. This is a log example:

Quote

   246579 ---------------------- Joystick Device Scan -----------------------
   246579 Product= Model 2040/2045
   246579    Manufacturer= Desktop Aviator
   246579    Serial Number= Net03d00
   246579    Vendor=16D0, Product=06E0 (Version 0.1)
   246625    GUIDs returned for product: VID_16D0&PID_06E0:
   246625       GUID= {E747A060-66EF-11EB-8001-444553540000}
   246625       Details: Btns=20, POVs=(0, 0, 0, 0), Cal=x00000000, Max=R0,U0,V0,X0,Y0,Z0

If there is still need for help, give me a sign, @josh23913.

Detlef

[[Lua] Proper use of events]

I did not use com.readlast, just com.read. My device sends a report only when there are new data. So I moved the joystick slowly to achieve a rare update but it misses several inputs and suddenly jumps to a new value.

I am afraid I have to change my HID device into a composite one with a joystick interface and a keyboard interface until SimConnect gets properly implemented. Then I can feed FSUIPC with conventional inputs. Let's see what happens.

Detlef

[[Lua] Proper use of events]

This is an interesting discussion although it is rather old now.

I am connecting a generic HID device (not a joystick) to the PC. It converts my CAN-bus (with CanAerospace protocol) to HID. By means of the LUA interface of FSUIPC I catch the reports and distribute them to the offsets 0BB2, 0BB6 and 0BBA (Elevator Position, Aileron Position and Rudder Position). This arrangement acts like a joystick. I used both, an event.com solution and an event.timer solution. The first showed only spurious reaction while the latter (with an intervall time of 20ms) has fast responses when used with Prepar3D v5. The same lua script is awfully slow when used with MSFS and FSUIPC7.

My goal is to connect a CAN-bus to FSUIPC. It might be highly configurable through the LUA interface. However, timing seems to be a problem.

Detlef

[Desktop Aviator Panel in MSFS2020]

Desktop Aviator boards are mostly joysticks with or without analog axes. A switch panel has buttons only. So it should be recognized as a joystick.

[LUA delays response]

Hi Pete,

 

as my script is a proof of concept I did not do complicated things yet. I am sitting with a small plane on the ground, no movement, just the prop is spinning. No AI. static scenery. Frame rates about 25. By the way, I am using Prepar3D.

I am operating the switch with either a mouse click or a FSUIPC assigned key. The graphic's response is quick: the switch on the screen flips and the annunciator light changes almost immediately (~0.1s). But, even omitting the COM channel the LUA display alone reacts slowly (up to 1s).

I proofed it with this minimalistic script:

-- "annunciators" test program

function lights(offset, value)               
    ipc.display(value)
end

event.offset(0x0D0C, "UD", "lights")

My USB device is polled by the interrupt channel every 5ms. I assume, the time from preparing the USB output buffer to actually sending the message is less than that (Windows 7 with an i5 processor @ 2.3GHz). So the delay seems to be within the action --> offset --> LUA chain.

 

Detlef

[LUA delays response]

Very short:

-- "annunciators" test program

Vendor = 0x04D8
Product = 0xFE7A
Device = 0  -- Multiple devices of the same name need increasing Device numbers
--------------------------------------------------------
-- First, we need to get the device
Report = 1  -- I *think* all joystick types use Input Report 0
dev = 0
dev, rd, wrf, wr = com.openhid(Vendor, Product, Device, Report)
if dev == 0 then
   ipc.log("Could not open HID")
   --ipc.exit()
else
   ipc.log("HID opened successfully") 
   ipc.log(dev.." "..rd.." "..wrf.." "..wr)
end
X = ""
function lights(offset, value)
  X = string.char(1, 0x0D, 0x0C, value/256, logic.And(value,0xFF), 0, 0, 0)
  if dev > 0 then
		n = com.write(dev, X, wr)                 
    ipc.display(value)
  end
end
function HIDclose()  
  ipc.display("Landing Light Closed")  
  ipc.log("HID closed")
  com.close(dev)
end

event.offset(0x0D0C, "UD", "lights")
event.key(89, 1, "HIDclose")
event.terminate("HIDclose")

Dedel

[LUA delays response]

Thanks a lot, Pete,

 

I can see more clearly now. I think, I can live with that delay as far as lights are concerned. If I switch on the cabin light and my ceiling light floods the room half a second later - I can live with it.

 

Dedel

[LUA delays response]

Hi there,

 

I am using a small event driven LUA script to call my HID USB device whenever a light switch is toggled (using offset 0x0D0C). Then the USB device sets it's outputs accordingly.

However, there is a significant delay between the incident and the response: from immediate up to 1 sec. It seems that the event is polled with a fixed 1 sec interval.

Is there a way to shorten this interval to have a more rapid response?

The ipc.display window behaves similar.

 

Many thanks for a hint,

 

Dedel

[No HID device through LUA in Prepar 3D]

Thanks Pete,

 

everything works fine now. The "Debug=Please" did the job: My HID device (and others) are visible in the log again.

I use an ipcReady.lua for starting my script now with success. I was misled by my one FSX implementation which starts my script even without an [Auto] entry nor an ipcInit/ipcReady script!

 

Detlef

[No HID device through LUA in Prepar 3D]

 

 

In what way "logged"? FSUIPC does not log all HID devices. My HidScanner program does. Can you explain what you mean there please?

 

They were, I swear! However, during my efforts to get the script running, they disappeared and I forgot to document this ...

There were 3 HID devices listed with full information - sorry I can't show it any more.

 

 

 

... ie not listed in the [LuaFiles] section of the FSUIPC4.INI file?

 

They ARE listed in the INI file. And that's why I am so astonished that they do not show any action. As a test, I put DISPLAY VALS.LUA into the modules folder and expect to see some variables to show up in the FS window (which works on the one "good" FSX implementation), but there is nothing with Prepar3D and the other FSX.

 

Detlef

[No HID device through LUA in Prepar 3D]

Hi,

 

I have my own modules known as HID devices to the PC. One of them has rotary encoders attached to it and sends the information as a HID report. This report is caught by a LUA script within the modules folder, interpreted and passed on to FSUIPC offsets (NAV1, COM1, AP heading, etc.). This works fine with my FSX installed on my home PC.

 

However, on the same PC I have an incarnation of Prepar3D and also on my laptop. Both do not reckognize the HID device (the PC does)! It is not listed in the log files. Other LUA scripts (from the samples) folder are reckognized neither.

 

My Prepar3D is academic version 2.2.10438 and FSUIPC is registered version 4.934.

 

On my office PC I have a FSX also, here the HID is listed in the log file, but no reaction is visible (i.e. thru ipc.display(...)).

 

Any idea?

 

Many thanks for your replies,

 

Detlef