vdkeybus

Hi Peter, Regarding the PFC throttle axis filtering you proposed. The problem seems to originate from noise and nonlinearity of the controls, although - from my experience in designing hardware - the noise usually predominates. In that case, a good thing to do is to use a digital filter and get rid of the noise first. The result is a smoothed value that is the mathematically most likely estimate of the actual lever position. (Actually your proposed decision algorithm implements a filter, but in a rather awkward fashion.) Then, after filtering, you could implement something like: // Sample algorithm (thr1_in is the input from PFC, thr1_out is the output to FS) // Second-order IIR digital filter: thr1=thr1_2*a2 + thr1_1*a1 + thr1_in*a0; thr1_2=thr1_1; thr1_1=thr1_in; thr2=thr2_2*a2 + thr2_1*a1 + thr2_in*a0; thr2_2=thr2_1; thr2_1=thr2_in; // Evaluate the results and compensate for any nonlinearity if (abs(thr1-thr2)) > e) { thr1_out=thr1; thr2_out=thr2; } else { thr1_out = thr2_out = (thr1+thr2) / 2; // Average both inputs } The filter and the e value depend on the PFC resolution. If you're interested I can give more details on the filter design. You could use the 30-day trial version of a program written by Nuhertz Technologies (http://www.filter-solutions.com) to make a digital filter. Or use a tool like Matlab. Hope this may help you. I am currently interfacing similar hardware to MSFS and I intended to use this algorithm. I should be able to provide more feedback in a week or two. Jeroen.

I have created a Windows program with a dedicated thread that transfers data between FSUIPC and the serial port. This thread yields to other processes (e.g. FS) whenever the serial port is busy transmitting or receiving a block of data (synchronous, non-overlapped I/O). Currently, I'm updating FSUIPC variables at a rate between 2 and 20 Hz using C code that looks like this (the program is based on the BCB example in the FSUIPC SDK and I'm using FS2002): FSUIPC_Write(0x3ae8, 8, &throttle_L, &dwResult); FSUIPC_Write(0x3a28, 8, &throttle_R, &dwResult); FSUIPC_Write(0x3af0, 8, &mixture_L, &dwResult); ... [Another 10 R/W requests] ... FSUIPC_Read(0x0574, 4, &alt, &dwResult); FSUIPC_Read(0x02c8, 4, &vsi, &dwResult); I noticed that the FSUIPC_Process() function takes a while to complete. On the other hand, it seems to return almost instantaneously when FS stops processing (when e.g. the FS menu bar is popped up using ). What is the typical request completion time ? Does it strongly depend on the number of requests in the transfer frame ? Should I consolidate a few variables in a larger block ? I'm planning on posting FSUIPC requests in a more intelligent way, omitting FSUIPC_Write()s with (nearly) the same values. Is this worth the while, given the fact that data copying shouldn't take more than a usec on Pentium IV ? Perhaps some synchronization mechanism with FS is executed for each request in the frame ? Finally, I must congratulate the creator of FSUIPC for developing an excellent piece of software. It's stable as a rock and very easy to program with. If you need to read or write FS data, I wouldn't even consider the option of writing a DirectInput driver or module .dll anymore. Thanks for your support, Jeroen.