vdkeybus

jjjanezic, Another possible problem is RAM shortage. I'm doing a comparable thing as you (albeit I'm using Borland C++ Builder). Luckily BCC is quite small, but especially when running FS2004 (instead of FS2002), I experience the symptoms you're talking about. It happened once that I had to wait one minute (!) before a key got accepted, because Windows was apparently doing a major rearrangement of the memory resources. My notebook is a P4 2.4GHz with 512 MB of RAM. Try and find out which application is hogging the CPU and also look at the peak memory usage. J.

Hmm, I found (with FS2002 and FS2004) that I can perfectly run them minimized. In fact, I often did programming while FS was running in the background and someone in the cockpit was flying on instruments. He did not notice much difference. I measured the FSUIPC update rate in that case and I achieved something between 31 and 47 per second. I cannot see the rate when FS is in the foreground, but the FS frame rate is then 20. Perhaps the high update rate is due to FSUIPC quickly returning non-updated values ? J.

Loc. 3888 reports the number of tanks the engine is draining fuel from. This is mostly 1, but if you select 'All' or 'None' as the fuel source in Loc. 3880, this number may be larger (2 or more) or even zero. Personally, I don't think this value is of much use. Loc. 3880 selects the tank the engine is connected to. The source is as mentioned under Loc. 0AF8. I myself am using the series of values at Loc. 3B98 to turn on and off separate fuel pumps per engine. If you want to model more than one booster pump per engine, you have to write code that ORs both fuel pump switches for that engine. FS apparently accepts only one value per engine. A sidenote one fuel pumps and tanks: the existence and use of these tanks and pumps is entirely up to the flight model ! Some aircraft models may allow you to start happily without booster pumps. Additionally, selecting a tank that isn't defined in the model will starve the engine. Finally, reciprocating means that the engine uses a piston which moves back and forth during operation (like a car engine). These engines run at low RPMs, allowing direct connection with a propeller. This is opposed to jet (turbo) engines, which use only rotating fan disks. Thrust comes from accelerating the incoming air (several tens of kg per second) to extremely high speeds. In all modern airliner engines, an extra, large compressor disk also accelerates cold air around the engine (bypass, turbofan) for additional thrust and lower noise. The high operating RPMs of jet engines make it impossible to connect a classical propeller to their shaft, unless a massive gearbox is used. In that case, we're talking about a turboprop. FS requires the aircraft model designer to select one of the above three propulsion mechanisms: piston, jet (turbofan) or turboprop. You should use Loc. 0609 to check which engine values you can use for each model. Fuel selector and pump operation seems to be the same for all types. Pete, all locations mentioned here were checked in FS2004. J.

Even the FS2004 default gauge doesn't seem to track 0x02C8 directly... Most noticeable when making a hard landing or strongly pulling up the nose: the needle always moves smoothly and rather slow. Anyway, I'll have a look at 0x0842 tomorrow. Thanks for you suggestions and I'll keep you informed. Jeroen.

I'm using the value at offset 0x02C8 for a VSI indicator. Flying with this gauge is difficult, as the vertical speed value is 'true', i.e. not damped as in a real aircraft instrument, as was pointed out to me by an experienced pilot. To fix this, I'm now applying a filter to this value. However, is the readout of the standard VSI gauge in the panel possible using FSUIPC ? Or is another offset available for it ? Jeroen.

Brian, I have recently completed a project in which data is sent between FS200x and a remote simulator platform. The communication was done using RS-232. Communication is bidirectional and happens in the background. If you like, I can send more details. For your problem, I would consider using a small, fast microcontroller (e.g. Atmel C2051) and a bus driver to generate the ARINC data stream from the RS-232 data stream from the PC. This controller could be programmed in 'C', saving considerable amounts of development time. Only consider using a CPLD if ARINC is really fast ( > 1Mb/s ). CPLDs are expensive and not that easy to work with (you need excellent power supplies and plenty of EMI countermeasures due to their speed). Regards, J.

I'm not familiar with VB, but here are some remarks: 1. After ACID = RTNString, there is an End If, directly followed by Else. Is this syntax correct ? 2. When you assign the RTNString to to function's return value, does VB return the pointer to the string (like in C) or the whole string object ? In the first case, you will probably corrupt the string because it is a local object (you Dim'med it inside the function), as the storage space (stack) is immediately reused when any other function is called. Perhaps try and Dim it outside the function, i.e. at the same level as a function declaration ? This problem doesn't present itself with numbers, which may explain why everything worked fine for you up to now. Again, I'm not sure. I always program in 'C'. J.

Beware of the decimal point. I noticed that it may be a dot ('.') or a comma (','), depending on the locale settings. atof() and scanf() only convert numbers containing a dot as decimal point. J.

I've implemented option 1. Works fine. Thanks for the support. In fact, the only remaining problem I have is to shut the radios down. Every radio has a mode switch with an OFF position. I can clear the displays in this case, but FS still operates as if the radio is alive. Again I have 2 options: 1. Write 1 in 0xB70 or an unspecified value in 0x3BE1. 2. Tune the radio to 108.00 MHz. Switching off the avionics is out of the question; it turns off all radios at once. Jeroen.

I have an external radio stack. Its controller keeps track of the different dial settings and sends them periodically to a PC running FSUIPC. For example, if I am frantically turning the NAV1 MHz button to the left, the PC may get the following data, spaced at 0.1 s intervals: 23, 20, 16, 12, 8, 3, 254, 251, ... Notice the wraparound of the byte value. It is fairly easy to convert this to 'number of ticks per interval': -3, -4, -4, -4, -5, -5, -3, ... The question: what would be the best way to control the radio stack MHz value ? 1. Read the frequency settings from offset 0x0350, calculate the new MHz value including limit checking and write it back. 2. Send one or more (key ?) commands to FS (via FSUIPC) telling it to increase or decrease the setting by an amount of -3, -4, etc ? I'm inclined to option 2 (the ADF has 2 offsets to check and set, for example and I must take care not to update any values when the avionics power is OFF) but I don't know how I could use FSUIPC to do it. Ideally I want a situation in which I turn ten ticks, and the value changes by exactly ten ticks as well. Jeroen.

Isn't the simulation time or timer halted whenever the simulator stops ? Couldn't you use that to detect a frozen state ? (Like comparing with the system time.) Jeroen.

You seem to assume that the oil pressure reading is in psi units. It is not. From the offset list I saw that in fact a value of 16384 is 55 psi. So you must probably add: OilPressAngle=OilPress * 55 / 16384 to your code. but this again may go wrong because you defined OilPressAngle as a long integer. Better change OilPressAngle to a floating point number (Dim Float ?) and use: OilPressAngle=OilPress * 55.0 / 16384.0 Better still, use FSUIPC offset 3B60, which gives you a nice double precision lbs/sq in. number. Scale this by 1/144.0 to get psi. J.

Go to http://www.simmarket.com. From the product list, select 'FS Utilities'. Then click 'FSUIPC 3'. Then you can add FSUIPC and/or WideFS to a shopping cart. On this page is also a link to download the unregistered version. After payment (VISA etc.), the Simmarket folks will send you your personal registration code(s) by e-mail. This code unlocks the unregistered version. Good luck, J.

Dear Paco, Send your special software insight to bypass the FSUIPC security to (remove the anti-spam rubbish after my name): vdkeybus_remove.this.including.the.undeotmail.com so I can see for myself if I have wasted my time replying to a boaster. Include a phrase stating that I won't tell Pete. Since I'm a registered FSUIPC user, do not worry that I will misuse it. Jeroen.

I have tried engine starting on the FS2002. Mixture setting (0x890) is indeed 16384 to turn fuel on and 0 to turn fuel off. So don't set it at zero after starting. Setting the 0x892 offset value to 1 starts the leftmost engine. This has to stay 1 for a few seconds (until N1 starts increasing). You can keep it 1 as long as you want. However, after some start attempts, I inadvertently ran out of battery power. You can use a checkbox under FSUIPC's Technical tab to extend the battery life to last sufficiently long for your tests. Jeroen.

Dear Paco, Last week I needed a better twin flight model. So I went and bought a Seneca V from FSD Intl. To my surprise, even with the CD at hand, I have to have an internet connection in order to get access codes and get on with the install. A damn nuisance if the simulator is actually located into a remote location without internet, as happened to be in my case. The reason I have to return home, send 2 personal numbers, an invoice number and wait for the FSD reply is simple: people like you. Thank you. They don't pay for the costs involved in getting a reliable product working and instead, they make me pay more. Thank you. The fact that you're offering: is an invitation for other people to do things they shouldn't. The special insight you may have can only be used by others to commit a 'crime' that's very hard or even impossible to detect, which is exactly why many will do it. And you know that. Please do not brag about that. If you want to hack around, do so in SIM1.DLL and find some useful offsets there. That's a real challenge: the code is probably C/C++, compiled with all optimizations on and MMX support. It will give you an idea of the work Pete currently puts into FSUIPC. Jeroen.

Dear Aashq, You will have to write your own MS code to emit FSUIPC values through the ethernet interface of your PC. If you're doing a microcontroller (uC) design, seriously consider using the serial port. It is well supported in Windows, and you don't have to worry about / debug the TCP/IP stack on your uC. BTW There's a cockpit builders forum in the simFlight forum index. Consider continuing this thread over there.

Hi Pete, I feel very much obliged. Thanks. J.

Hello everyone, I have connected a dial type altimeter to FS. I'm achieving update rates from FS to the instrument of over 60 per second (it being the only instrument that gets updated). I noticed that the altitude is not changing smoothly on the instrument, but seems to 'jerk' a little. It looks as if the FS altitude is internally updated only 2 times per second and then filtered to get smooth values in the panel. Has anyone seen this behaviour and is there a cure for it ? I'm using FS2002, locked at 30 Hz frame rate. The FSUIPC memory location I read is 0x3324 (barometric altitude). J.

Given the definition of chTmpBuffer (8 uchars), this piece of code will overwrite the byte following chTmpBuffer. Change 'i<=4' to 'i<4', or you will get exceptions someday. Rather, you could get the job done like this (I avoid the use of 64 bit integers. Some older compilers/libraries do not support them. Hence the more elaborate number conversion.): #include #include bool fs02if::bAltWrite2FS(double dAlt) { static struct { unsigned lval; int hval; } val; // Make static, so the FSUIPC pointers point to // something meaningful when we return from // this function. (The struct will get allocated to // the .bss section during linking.) DWORD dwResult; bool bTmp; val.hval=floor(dAlt); val.lval=(unsigned)((dAlt-val.hval)*2*MAXINT); bTmp=FSUIPC_Write(0x0570,8,&val,&dwResult) && FSUIPC_Process(&dwResult); // Due to the static allocation of 'val', you can now postpone the // FSUIPC_Process call (not done in this example). return(bTmp); } J.

Hello Pete, Is it allowed to partially read a value from FSUIPC ? E.g. I'm interested the first 3 characters of the VOR1 Identity, so I would like to enter (offset 0x3000, size 4). And, by extension, can I read in the middle of a value, so I don't have to read the full 4-byte integer, but only its most significant byte (handy for bit words) ? Thanks. Jeroen.

Hi Pete, If you get data at a 1Hz rate, it is simply impossible to filter it at 18Hz. Do not put effort in it. The filter just won't work. If it is impossible to crank up the PFC sample rate, I'm afraid we must resort to something like: diff=thrL_in-thrR_in; // Get the difference if (abs(diff) > e_large) { thrL_to_FS=thrL_in; thrR_to_FS=thrR_in; } else { avg=(thr_L+thr_R)/2; corr=sign(diff)*(abs(diff)/e_large)^3; thrL_to_FS=avg+corr; thrR_to_FS=avg-corr; } The first if-clause (diff > e_large) ensures that the axes are independent when they're clearly different (Engine-out situation). Set e_large to 30 or so. In the second, small axis differences are made smaller, but large ones are amplified (play with the 3 to tune this somewhat). It's only a rough idea... From nmthomas I've got the impression that the other axes (mixture, propellor) are perhaps to blame as well. Anyway, I should have some samples to test the above idea. Isn't there any way of getting the data from the PFC HW to a file in a simple program issuing commands to the COM port directly ? If no, just send me the sequence you've got. But please tell which data I have to look at. But again, don't try filtering on a 1 Hz data stream. Filtering relies on the fact that samples are unpredictable (noisy). If you would interpolate 1 Hz data, they're no longer unpredictable. It'll be waste of your time and I wouldn't want that :wink: on my conscience. J. BTW I'm always willing to improve my vocabulary. What does 'bemused' mean ?

I do not own PFC hardware. From what I've just heard from Pete these controls have a fairly low resolution (i.e. 7-bit) and it is most probably due to this fact that you get 'asymmetric thrust'. Remember that you've got probably around 500 hp on the turbine shafts. Adding only one bit drags one end of the plane by 4 hp. Especially at low output powers, this may create an asymmetry of more than 10% and apparently you've got noise in the order of 3 bits. No wonder the aircraft 'wobbles'. Filtering can possibly alleviate this a bit. I do have an idea to fix this, but I need more data on the PFC output characteristics. Can someone give me a continuous series of samples from 2 (or more) of its throttle axes ? Jeroen.

The file is called FSUIPC.LOG, not FSUICP.LOG and is by default located in: C:\Program Files\Microsoft Games\FS2002\MODULES if you haven't installed it somewhere else. I don't know where it sits when using FS2004. (probably replace FS2002 in the path above) And indeed, type the code and restart FS/FSUIPC. J.

Hi Peter, I just wanted to supply a possibly interesting solution to the problem. Maybe someone else finds it useful as well. Some cockpit builders may encounter noise somewhere in their quest, I guess. And I see many posts covering PFC.DLL, so I thought you had something to do with the software part. Anyway, I just noticed that your last post in this thread was over 4 months old... :oops: The filter coefficients can be calculated, but it's not a straightforward back-of-the-envelope calculation. With the tool I mentioned earlier it has become a lot easier though. The calculations assume that your input data is more or less regularly sampled. Supposing a sample rate of 18.2 Hz, I put the cutoff frequency at 2 Hz. Any signal variation beyond this frequency (noise) will be attenuated. The attenuation is determined by the 'filter order'. The higher the order, the higher the attenuation, but more computational effort and precision is required. An order of 2 is good for this application, I think. (Note that there are a lot more filter designs around, and this is only a simple example.) I admit that choosing the filter parameters requires some insight, but in this case, setting the cutoff frequency at 2 Hz seems very reasonable as in reality, aircraft engines won't be able the follow such quickly varying throttle commands. Using this data, one can instruct a computer to calculate the coefficients. (I used a Butterworth filter characteristic which leads to good all-round designs.) And voila, there is the filter program (execute this at 18.2 Hz): float filter(float in) { static const float a0=0.0790, a1=0.1579, a2=0.0790; static const float b1=-1.0631, b2=0.379; static float in_1=0.0, in_2=0.0, out_1=0.0, out_2=0.0; float out; out=a0*in + a1*in_1 + a2*in_2 - b1*out_1 - b2*out_2; in_2=in_1; in_1=in; out_2=out_1; out_1=out; return(out); } 2 lines of code per channel. That's not complicated, is it ? And it doesn't use branching, which is nice for your Pentium's pipeline. An optimizing C-compiler will also allow simultaneous execution of the addition and the multiplication on the FPU. How is this filter useful ? Let's return to the additional piece of code that has the e parameter in it: if (abs(thrL_filtered-thrR_filtered) > e) { thrL_to_FS=thrL_filtered; thrR_to_FS=thrR_filtered; } else { thrL_to_FS=thrR_to_FS=(thrR_filtered+thrL_filtered)/2; } It is meant to avoid asymmetric thrust with controls that are not too well matched along their travel. The e should be set so that when the throttle controls are held together, e remains larger than any difference observed in the filtered values when the levers are moved together from bottom to top. Because the data have been filtered before, noise does no longer require you to select a high value for this one. I expect that in your case, e=6 or so should give good results. Again, I will be able to comment on the workings of this algorithm during next month. I also have a simulated response to a noisy input signal with a spike, but I don't know how to attach a bitmap file in here. Jeroen. (And never use in your text - followed by a backspace to correct your error - in this forum editor :x )