PhilippeV8

Pete, The info you gave helped someone else to give me some code which now works. So thanks for that. You say that getting code is not helping one to understand or learn .. that's true .. but my phylosophy is that I don't need to knox exact how it works .. as long as it does work and I know how to mold it so that I can use it. After a while I understand by doing and using the code. That's a total different approach than you suggest .. taking a book and learning 'bout program languages. But I think that would take me way too far and take me way too much time doing/learning things I don't need to know. It's a different phylosophy I guess. Either way, the thing I want to acoumplishe is nearly finished and it'll work for me. So I'm happy. Tnx

Hy Pete, I am having a bit of problems with the data types and conversion. (C++) Could it be possible to get an example of a code which reads the NAV1 frequency from fsuipc and then puts it in a label or textbox ? That would be quite handy. The SDK example from C/C++ doesn't explain me really how to do that.

I think I nailed it; you can see that the image in my first post has changed to the current state. What I did is take the FD LOC (0C48) and substracted the current turn rate and used this to position the LOC needle. Then took the FD GS (0C49) vanlue and substracted the current pitch value to position the horizontal needle. Don't know if this is precise, but it does seem to do the trick. Especialy for the turn. Not sure yet it the horizontal needle shows good ofset but it can't be far off. Tnx Pete, I'm on a roll again :)

http://forums.simflight.com/viewtopic.php?t=29677

I changed that to And it works now. I don't seem to find those % things on the net. I understand that the 05 indicates the number of digits to use ? But what is the d or the f behind ? And what other choises are there ?

:idea: 31E4 ? 8) works fine here.

glPrint("goodADF2 %05d", (double)_fdbank); That's what I got at the moment. I tried with the (double) and without with the same result. The ofsets I was refering to is the 0C48. I think I did try to declare it as "signed double" but I'll check again if it changes anything. I know 'bout the warnings. However I don't know how to fix this :oops: Most of them are: warning C4244: 'argument' : conversion from 'double' to 'float', possible loss of data And the line it refers to is something like this: // 20° up line glBegin(GL_QUADS); glVertex3f( 0.4f, ((double)_pitchrate/1800)-1.43, 0.0f); glVertex3f(-0.4f, ((double)_pitchrate/1800)-1.43, 0.0f); glVertex3f(-0.4f, ((double)_pitchrate/1800)-1.40, 0.0f); glVertex3f( 0.4f, ((double)_pitchrate/1800)-1.40, 0.0f); glEnd();

Hi Pete, So I've just searched what's up on the forum here on the FD matter. Indeed I know 2EE8 and 2EF0 don't give the needle position but a direction in which the needles should point the aircraft. Either way, when I read them from FSUIPC I get wierd stuff. The value changes on each read and goos from very large to very low (below 0) numbers. When I make the plane turn a lot (like from 0° to 100° or 200°) with the autopilot, the bank stabilises on 000008. These numbers are nothing like what I get from FSInterr. I suspect I am doing something wrong here. I'm new at C++ but I have managed to make this work in OpenGL (all you see on the img works) So I guess I'm not such a n00b as you might suspect. I am reading other stuff and using it proprely. Ok so for this FD thing, I declare: double _fdpitch; double _fdbank; int _fdflag; _fdflag works super. I tried changing the data type from _fdpitch and _fdbank to float or int and though the numbers get different each time, I get nothing like I see in FSInterrogate. Then I got this in the FSUIPC code: !FSUIPC_Read(0x2EE8, 8, &_fdpitch, &dwResult) || !FSUIPC_Read(0x2EF0, 8, &_fdbank, &dwResult) || !FSUIPC_Read(0x2EE0, 4, &_fdflag, &dwResult) || //etc.. At the moment I show the values in the green text you see on the picture above. Maybe it gets screwed up while showing it as text ? One other thing. I was working last night on those GS and LOC bugs. The GS was working good but I had a lot of issues with the LOC. It showed me values in the texbox from 0 to 127 and then jumped to 255 and counted backwards to 128. Even if I used double as type it didn't want to show negative values, so I just use an if/else and substract 256 from the value if the value is higher than 127. That works though probably unclean sollution. I hope you can give me some tips here. Cheers,

True, true ..

Ok, that's clear. Hèhè .. but it will be me telling him where to write what :P Because it is me who will be using this afterwards, not him (unless offcours he choses to build a home sim himself) I would ask what the difference is between Open2 and Open but .. never mind :) That's info for Espen and he will probably read 'bout it in the SDK. I do have a key for fsuipc so that should be OK then. I'd suggest him to request a key since his software is freeware (think that's possible to get a free key then, right ?) but that's no use either because I got a key and I am the only user :P No use getting a freeware key for me alone :wink: Ok then! I think I know enough. It's all up to Espen now. I'm outa here 8) Pete, thnx a lot ! If this thing is going to work, my sim is going to rule big time :) Cheers, Pv8

Ok. So Espen should confirm here ? Ow Espen e-mailed me and he expressed concurns about him having to have licence or not. Could you clear it out for us ? Or should it just work from inside FS to write via fsuipc ?

Espen >> the indicators are the button statuses (e.g. btnExtPower = 1 or 0, btnGlareASEL = 1 or 0etc etc.) Shortly said: every button that has a led. This way I could read those statusses from your panel code and adjust led on/off state in my sim. This way I will be 100% sure if a led in the sim is on, that that function IS on in your panel as well! Normal users can see it on your panel but I won't see your panel (or at least not all parts exept left MIP gauges and engine gauges). And I do not feel like show/hide the overhead or main panel each time i press a button to make 100% sure the signal got trough to FS and your panel. Pete >> if "people don't set the altitude hold until the climb or descent is to begin"how then is the aircraft to maintain altitude ? e.g. I come from FL080 to intercept the ILS. I set 3000 ft on the glare and chose descend mode. at 3000 the plane will level off, waiting to intercept the glidepath. Then before intercepting the GP, I will set e.g. 4000 ft on the glare which is the "go around altitude" for that airport. But even I change to 4000 I do not want my plane to climb or even descent! I want it to stick to 3000 so I want to maintain altitude function on untill the intercepting of the glidepath. how do these people solve that then ?? without using a separate variable for the ap-alt as we plan to do ?

Hèhè, that's the comon mistake people make. I had this too at first. I looked at the overhead and though ow yeah like 40 push buttons and about 20 leds I want to work I ended up with more than 70 of those push buttons in total and quite a few switches and other stuff. Most of the push buttons have a led so you'd get to 40 quite fast. If you count gear status leds (4) and glarepanel (+/- 16) then main panel has 4, pedestall has none, overhead has about 40 to 50 I don't know if I will want all of those to work right away (from the overhead I mean) but it would be preferable to leave space to go that far if I would chose to do so. I'm sure you would agree that it would be silly paying 1.50 euro per "push button with led" and have 80 of those and then not use the led Other than that you should agree that annunciators and leds bring your sim to life. And they are vital to the sim as they are in the real cockpit. F50 uses dark cockpit system so the leds should be out ideally but if something is wrong a led will go on and I want that in my sim too. Sometimes if I shift from FS to other programs for a while and then go back to flying my fuel pumps are offI want to see that from the cockpit and not only hear a warning beep beep beep .. cuz the beep could have multiple causes but if those leds are illuminated I know at once what is causing it. My A/P IS on and it is the one from FS. The FS attitude is used and quite a few other AP functions as well. Only not the altitude. If we would use the altitude we wouldn't be able to use any of the rest like attitude or v/s .. so what's the use. You can not use at least 1 of the FS variables to end up realistic in any way. I never made gauges so I am not sure from own experiance, though I know very sure now that PM does it the same way (not using the altitude) and many other advanced panels do exactly the same. I appreciate you trying to find more handy sollutions but trust me on this one. The AP alt is what we need separate from the FS defaults. There's just no other way around it. As long as FS doesn't drop this sillyness. Dito for the rudder. In FS the tail rudder is linked to the front weel. Not realistic at all. But as long as they don't make it loose from eachother we can't build a working tiller and pedal control separated from eachother.

Don't think it is 1 gauge. It just is 1 file. As far as I can see at least. I know little about gauges and how they are made. Thats 1 of the areas of FS that I have never really looked into before. I am not as such the only user of Espens panel, but I am the only user of this version or mod of the panel yes. It is for home sim builders only so as I said, maybe in the future if there ever would be someone building another Fokker50 home sim he would be interested in using the same mod. However most home sim builders chose Boeing or Airbus or regional jets or cessnas, so chance seems small. Concerning conflict .. I think that if I am the only person to use this mod (or maybe 2 or 3 others in the future, who knows) than that conflict would be with PM software. But no one could tell if PM would ever make any software which would be usable from a F50 type cockpit. And even if it would .. PM specialises in software which make it such that you do not need a panel in MSFS ! :) So even if PM would ever make F50 software, that would replace Espens panel and thus create no conflict at all. I understand your concurn. I can immagine that you and the PM folks keep good contact and if this idea I have could in any way create a conflict that could maybe harm your relationship with them. That zone is reserved for their use either way so if you OK for me to use it, they could perhaps not be OK with that. So I understand it fully. However as said .. no chance that normal FS users will download from Espens website the same version of the panel as I got and a conflict is most unlikely to ever occur. But if you prefer to reserve some space for my project that would be ok for me too. Makes no difference really. If you want that, let me know and I'll try to figure out how many bits I would need. ( 12 for the AP altitude + 1 per led , right ? Not sure yet though how many leds that would be but I'd guess somewhat around 30 or 50. 60 would be max I think )

Well as far as I know for now I am the only person building a F50 sim and if there ever will be more, for sure it will never be more than a handfull. People using Espens panel get an other version of the gau file so I got one custom made for me. If any other person would ever build F50 he would get it too probably but it is not to be distributed as a panel for normal FS users. Secondly F50 sim builders (or builder as long as I am alone) will not use PM software simply because they don't have (yet) no F50 type gauges available. This way there is no chance of any conflict between my program and PM because I simply don't have it. Hèhè, no no I am not translator. He is from norway but he sure understands english well enough :) I am just the one to contact you first because I am the one who wants this made possible. Once I figure out as much as I can about how to do it, then I forward all this info to him and kindly ask him if he would edit the gauge file for my needs. Then it is up to him to contact you if he needs more info. I just want to know first if it is possible and it is indeed so I read from your answers. So I will let him know this via e-mail and will direct him to the manual which you point out and then I can only keep my fingers crossed that he will manage to make this happen :wink: So far I am happy to know that it could be done. One last thing from me. Now that you know that PM and my gauge files will never meet on anyones platform .. is it OK then to use the PM zone ? Then also there is no need for any change to the FSUIPC dll (don't know if that WOULD require a change if we were not to use the PM zone) .. you tell me :)

Ow and as to why not use the default FS autopilot altitude variable .. simple. If you change that one,e.g. I am flying on autopilot at FL100. I turn the knob to increase the value to FL120. If you use the default variable, FS will edit the virtical speed variable straigt away to climb (in this case). This is not realistic at all and is not at all the case in ANY airplane that we know off. Speically not the airliner type. That is also why PM uses this zone for passing their own ap-altitude value and chose not to use the default. If MS would change their code and not make FS do this, then we could all use this default variable as you say we should. But as long as those 2 things are linked .. there is no use of it for us cockpit builders.

Hèhè Pete, I told you already. First sorry 'bout the confusion I had. Indeed you need more than a 0 or a 1 to show a single integer (2 to 9). For the led status however a bit would do. Then to tell you some more 'bout who is going to write: Espen is. Espen Oijordsbakken ( http://www.fokker50.com ) made a fokker50 panel for FS95 I think which has been updated and evolved troughout all FS versions till today. I keep close contact with him because my home sim is based upon his panel. E.g. if his panel is not interfacable via the keyboard, then it is not possible to build a home sim around it. I can not tell a button press to use the mouse and click on a panel that is not on my screen. So I asked him if he would change his panel code so that that would be possible for me. He accepted and by now almost all the functions of his panel are controlable via keyboard commands and combo's. Same way I would ask him to change the code of his panel so that it would do a little bit more than what it is doing now. Meaning writing all data which I would like to read trough widefs into my software to the PM zone (if possible). If I understand it correct then the PM zone is wide open and free to use as long as one doesn't have the PM software or doesn't use the PM lines from the FSUIPC gui (wouldn't be interesting to use the PM variables in the FSUIPC gui if one has no PM software anyway :lol: ) So it comes down to this: Espen should try to figure out how he can write some of his variables into that zone and let me know exactly what is where and then all I have to do is read them. Is there anywhere info on how he should do this ? I remember passing over a section in the developers guide telling about how internal (FS) gauges can acces fsuipc variables. Is that the part I should forward to him ?

Ok, if I get this right, Pete, this "zone" can be seen like a string of bits, which PM has devided into their sub-divisions (variables of various length) so that when their software writes something in a sub-zone of this "zone" it can be read and known exactly where it can be read inside the zone or if something is read it can be told exactly what it is. So all people using fsuipc and no PM have this zone filled with 0's ? This would mean that all we need to do is for Espen to figure out how he can write a value to any bits or bytes from the zone and make his own sub-divisions, let me know what is where and then I can read them ? Hope I don't get it all wrong.

Awesome. That's 1 down, couple more to go :D If Espen manages to put his AP alt value into that offset I can read it no problem :wink:

Tnx for the info. The software is my self written Photon interface software (for now still 100% personal use ((I am currently the only Fokker50 sim builder))). http://www.iflightsystems.com sells a hardware interface to enable you to interface switches / buttons / leds / 7-seg. led displays. That's what I got and although the software is also available I chose to make my own. This way I have maximum control over what is going on + his version of software is more focused on Boeing & Airbus. No I am not the panel programmer though Espen Oijordsbakken is and evern since I started building or even planning my home simulator he has been 100% co-operative towards it. As said the idea is to get the AutoPilot ("target") altitude value out of FS, trough fsuipc into my software (so that i can project it onto the segment displays in the sim). So that's is a 3 bit value. ( altitude goos 5 integers though last 2, as you know are 0 always). Other than that it would be great to be able to read a string of bits indicating which led is on, which one is off. Mostly that is for the push switches of the glare panel and some of the overhead. I have no idea how the offset zone for PM is managed or what it does, however I will check their site to see if maybe it could be usefull. If so, there is no need for you to create an extra zone. Maybe you can tell me already before I finish the PM info if it could be used for passing those kind of data out of FS. (no write, just read!)

I see that Project Magenta has an area reserved for, what I think, passing their variables in & out of FS via widefs. My question now is: is it possible to reserve a small zone to use ? Espens panel doesn't use the default "ap altitude" value simply because as soon as you edit that one, the plane wil start going up/down which is not done in real. Other than that it would be great to be able to get a list of bits to read so that it would be possible to know the status of leds. Now if I press a (real) push-button in the sim the led will go on but if for some reason the signal doesn't make it to FS, the option (e.g. HDG hold) is still of. Same way for starting situation. Maybe a led is off in my sim and not in FS and when I push the button to turn the option on, actually I turn it off. Maybe there is already a way to make use of the PM zone ? Since I don't use PM stuff those values are never used ?

I have checked FSI a few times in the past. Then a few days ago I had a breef look at it again. Still I have no idea what I can do with this to improve my code ... All I see I can do is check if what I read is the same as what FSI reads. Either way, if all what I've come up with from test results and such don't help to find what is going wrong in my case, then I'll just stick to what I have made of it nowa cure for an ill situation. I'd rather have it 100% correct first time around and not have to send the read values trough a "debugger" function before using them but if no one has a clue what's going wrong, I'll be more than happy to keep it the way it is. It does work and that's not thanks to a good SDK or clear manuals. I am sorry to say Pete, but I feel kinda bad 'bout your line where you disencourage me to program any further. Quiting is not a good option and if I am only half as determined to do this as the president of US is determined to do bad things, then I too will provail. Maybe you don't realise but each time it seems to me like you want to make me feel as if I were stupid. I guess you're very good into programming. Who knows, maybe you can do assembler. But then again, I guess that you've got long period of experiance with all sorts .. While I just got started with VB.Net. Sure I am a newbie, but that doesn't mean I should quit or find something easyer to do. I did manage to write the software to use with an easy to build hardware interface which is connected to the LPT port. Had I learned anything 'bout coding to LPT ? No I had not. Had I learned anything 'bout going this kind of "low level" in VB.Net ? No I had not. Did I know anything at all about the LPT port at all ? No I did not. But I came up with the idea, I did my research on my own, I asked a few questions and I worked on it untill it worked. I did come across situations where I didn't know where to go to next, but I managed in the end and I learned much doing so. This time as well I am determined to write my own interfacing software for my sim. It is the best way to keep maximum control of the situation. And I can tell you that no matter how n00b I am with coding .. it works at the moment with this "debugger" function. So I can't be that bad, can I ? And sure I know that pc's work with memory and that software runs on it. Only when I write software, I declare a variable and I put data in it. Where it is put or how is none of my concern. The way fsuipc works with data, I still do not understand. And to be honest, I do not want to either. All I think we should have is a clear SDK with not only the fsuipc block code but also with clear examples. If we would have that, there would be lot less "stupid" questions asked. Do I aks for too much here ? :?:

I've put the value which is to long a BDC trough a substring from the right (16 long). Seems to work. Isn't the most beautifull sollution but it seems to work now. Also when I do a write, nav, navsby and xpdr all stay correct now. If only now the com and comsby and adf read without errors, I can let you rest here :D

If I use the logging, I end up with a long list of READ 3364 .. none of my reads show, none of my writes show.

Omg indeed I saw it all wrong :oops: So in the meantime I was changing my code to give that second example I made (which now turns out to be correct indeed) a try. (timer tick) read/read/read/read/write/process/get/get/get/get (timer tick) read/read/read/read/write/process/get/get/get/get (timer tick) read/read/read/read/write/process/get/get/get/get This seams to work. However .. I am doing 5 reads at this time. The IAS (02BC), the altimeter in feet (3324), the xpdr (0354), the nav1 (0350) and the nav1sby (311E). Then I do 2 writes. Geat up (0BE8) and gear down straight after. Then I do the process and then the a get for every read. I get the IAS perfect. I get the Alt perfect. I get the xpdr perfect IF I put a 4 instead of the 2 indicated in the "fsuipc for prog.doc" file. I get the nav1 sby perfect. And I get the nav1 all wrong. Now as a test, i put the read values in labels on my form without converting them first. (e.g. XPDR = 4660, which is 1001000110100 in binary, which is 1234 if you look at the binary in the BCD way. Which is correct for the xpdr) On the nav1 I get 135264, which is 100001000001100000 and if converted with the BCD way .. that makes 21060. If I would take the leading 2 off, than the value is perfect (nav1=110.60). The writing only happens on the initial startup of the program and then every time I hit a button. If I do not press the button on my form there is no FSUIPC_Write action. Now when I do press the button and thus trigger the write event, the nav1sby changes! The direct read value becomes 266288, which is 1000001000000110000 and if converted with the BCD way .. that makes 41030. Again if we drop the leading number that makes a perfet nav1sby=110.30 So at least now I know for sure that I am doing the "procedure" in a right order. Also I get my xpdr read perfect all the time. That's a good thing. Also I assume I am doing something wrong with the write. When I disable the write part however, the nav1 still reads wrong. Sure I've been in the GUI of fsuipc :P But I somehow never looked at the "logging" page so I didn't know it was there, what it did, etc ..