Jasper Bussemaker

Wow this is weird. I just tested it the way you did as in the screenshot, and it seems that 0E92 always contains the magnetic ambient wind direction :O Because as you can see in the screenshot, you are above the surface layer, so according to the manual 0E92 should contain the true heading (which should be 173 instead of 153!). Disregard: 0EEE is in metres :P Update: Hmm sorry to have bothered you, it seems that everything is working fine now... :S

Ok so you can confirm that in FSX it works like in the manual? Jasper

Ok I'll state it differently. This is what I want: A variable containing the true ambient wind direction. This is how I am achieving this: I am reading the offset 0E92, which is ambient wind direction. Your "manual" states this: I want to have a value of the ambient wind direction which always contains the true heading of the wind. So if I am not wrong (correct me if I am wrong): If the A/C is flying below the surface layer (0EEE), I have to convert the value read from offset 0E92 to true degrees. This is what I see: Even if the aircraft is BELOW the surface layer, the offset 0E92 still contains a TRUE heading instead of a MAGNETIC heading which you manual states. Can you confirm this? So? You understood me or not? Jasper

Hi Peter, In a new program I am creating I am reading the wind direction. In you manual, it states that because of compatibility reasons the wind direction is magnetic below the surface layer, and true above it. So I did exactly as I was supposed to: Read offset 0EEE (and convert it into feet and then add the ground altitude, because 0EEE is metres AGL). Then I read the wind direction and do the conversion to normal degrees. Then I check if the A/C altitude is lower than the surface wind layer, if this is true I add the magnetic variation to the wind direction. This way I should get the true wind direction, above and below the surface wind layer. However, it seems that FSUIPC is always transmitting the true wind direction, even below the surface layer! I am running FSUIPC v3.90 for FS2004. Can you confirm this bug? Greetings, Jasper

Ok now I have this code: Dim strMessage As String, strMessageB As String, i As Double, dwResult As Long, lACARS As Long, b() As Byte, tmp As Long strMessage = Text If Len(strMessage) > 127 Then strMessage = Mid(strMessage, 1, 127) For i = 1 To Len(strMessage) strMessageB = strMessageB & ChrB(Asc(Mid(strMessage, i, 1))) Next i strMessageB = strMessageB & Chr(0) b() = strMessageB Dim CurrOffset As Long, CurrAsc As Long For i = 0 To UBound(b) CurrOffset = &H3380 + i CurrAsc = b(i) Call FSUIPC_Write(CurrOffset, 1, VarPtr(CurrAsc), dwResult) Next lACARS = -1 Call FSUIPC_Write(&H32FA, 2, VarPtr(lACARS), dwResult) If FSUIPC_Process(dwResult) Then ElseIf dwResult <> 0 Then GoTo NotOpen End If And it works! The problem was that if I put strMessage instead of strMessageB into the byte array (b()) it would write between every char a 0 char and FS doesn't understand that. But it works!! Thanks for your help :) Greetings, Jasper

Good one :) That's because in the code I copied I tested strMessage, it's just because I was testing the various results... ;) Let's try this one :) I'll keep you updated! Greetings, Jasper

Hi Pete, When I use the offset 3380 (and 32FA) to write text to FS to be displayed, it only displays some weird characters. I'm using VB6, and in the readme.txt of the VB6 SDK, they say you might need to convert the string from unicode to ASCII. If I convert the string I am sending, but also if I do not convert it, FS displays weird characters (see below). This is my code: Dim strMessage As String, strMessageB As String, i As Double, dwResult As Long, lACARS As Long If Len(strMessage) > 127 Then strMessage = Mid(strMessage, 1, 127) For i = 1 To Len(strMessage) strMessageB = strMessageB & ChrB(Asc(Mid(strMessage, i, 1))) Next i strMessageB = strMessageB & Chr(0) strMessage = strMessage & Chr(0) Call FSUIPC_Write(&H3380, Len(strMessage), VarPtr(strMessage), dwResult) If FSUIPC_Process(dwResult) Then ElseIf dwResult <> 0 Then GoTo NotOpen End If lACARS = 10 Call FSUIPC_Write(&H32FA, 2, VarPtr(lACARS), dwResult) If FSUIPC_Process(dwResult) Then ElseIf dwResult <> 0 Then GoTo NotOpen End If It first checks the length of the string, then converts strMessage to ASCII in strMessageB. Finally it adds a null terminator to both of the strings. Then when I test it, with both strMessage and strMessageB it displays those weird characters. What I noted was that when I sent strMessageB (the converted one) to FS, it displayed twice as much chars as when I sent strMessage. I think this is weird, because strMessageB is the converted one which only uses 1 byte per char whereas strMessage uses 2 bytes per char (unicode). Note: the part to convert the string was literally copied from the readme.txt file of the VB6 SDK. I hope you can spot and solve the error! Greetings, Jasper

Yeah that's true... Thanks! Greetz, Jasper

Yeah that's what I meant But I think you should give the FSI file a higher priority, because FSInterrogate is the best way to also really get used to the offset you want. Thanks anyway! Greetings, Jasper

Hi Peter, Hope you're having a nice holiday. :) I just came across an error in FSInterrogate. At offset 02A0 (magvar) it says, add to convert true to mag, but it is the other way around as experimenting (and the offset pdf file) shows! Hope you can fix it with the next release of the SDK. By the way, FSUIPC is doing a great job at our VA! I made our own logging software, FSUIPC based, and it's working great! It is the transavia.com virtual airline: http://www.transavia-virtual.com Greetings, Jasper

Yeah I'll take further looks at it. Good its still in beta :) ! Greetings, Jasper Bussemaker

Hi Pete, Thanks for your reaction. The error code to which I am referring (1) is an error code defined by the VB6 source code. So this could be indeed that you don't know about it. These are the codes in VB6: Public Const FSUIPC_ERR_OK = 0 Public Const FSUIPC_ERR_OPEN = 1 ' Attempt to Open when already Open Public Const FSUIPC_ERR_NOFS = 2 ' Cannot link to FSUIPC or WideClient Public Const FSUIPC_ERR_REGMSG = 3 ' Failed to Register common message with Windows Public Const FSUIPC_ERR_ATOM = 4 ' Failed to create Atom for mapping filename Public Const FSUIPC_ERR_MAP = 5 ' Failed to create a file mapping object Public Const FSUIPC_ERR_VIEW = 6 ' Failed to open a view to the file map Public Const FSUIPC_ERR_VERSION = 7 ' Incorrect version of FSUIPC, or not FSUIPC Public Const FSUIPC_ERR_WRONGFS = 8 ' Sim is not version requested Public Const FSUIPC_ERR_NOTOPEN = 9 ' Call cannot execute, link not Open Public Const FSUIPC_ERR_NODATA = 10 ' Call cannot execute: no requests accumulated Public Const FSUIPC_ERR_TIMEOUT = 11 ' IPC timed out all retries Public Const FSUIPC_ERR_SENDMSG = 12 ' IPC sendmessage failed all retries Public Const FSUIPC_ERR_DATA = 13 ' IPC request contains bad data Public Const FSUIPC_ERR_RUNNING = 14 ' Maybe running on WideClient, but FS not running on Server, or wrong FSUIPC Public Const FSUIPC_ERR_SIZE = 15 ' Read or Write request cannot be added, memory for Process is full Code nr 1 is "Attempt to Open when already Open"... From now on I officially hate software (joke!:D): At today's test it suddenly worked without an error :S .... Still, thanks for your time and effort. Greetings, Jasper Bussemaker

Hi Pete, When I start my BlackBox flightlogger with FSUIPC 3.9 and FS running, I get an error from FSUIPC that an application is attempting to make an illegal connection. Also something that this application (in this case the BlackBox flightlogger) isn't meant for the unregistered version... :S I'm sorry, I cannot supply a more detailed description, because I "downgraded" to V3.85, which does work. I don't know what I do wrong, but I didn't change anything of my code, so it must be a bug of V3.9. Could you please download the BlackBox fligthlogger from http://www.utr-online.com/blackbox and install it? I want to know if it connects to flightsim at your PC (assuming you use the latest FSUIPC version! :D)... Just start the BlackBox (when FS is running), click No and check if in the right top it says "Connected". If it doesn't, click Reconnect and check which error code is given... :) Thanks very much in advance... ;) Greetings, Jasper Bussemaker

Hi Pete, Here, when I use the true hdg, I get this in Google Earth: And as you see, this is wrong... But I found out it was a calculation error in my code :( :roll: So now it is working correctly... I'm sorry again for making myself stupid. :( Greetings, Jasper Bussemaker

Hi Pete, I today decided that the GPS60 should get an update. One of these updates include the heading: I want to use the Whiskey Compass value instead of the Heading value, because the Whiskey Compass gives the correct heading when viewing it in Google Earth. BUT: When I access the 02CC value (Whiskey Compass), which does display right in FSInterrogate!, I get a value waaaaayyy to high. :? And when I examined it further, the value seemed to depend on the altitude! When I climbed, the value increased, when I descended, the value decreased. I access the 02CC value the same as I do for the Longitude value (which is also a FLT64). And this is where the next weird thing comes in: In FSInterrogate, the lat and lon display wrong values. :o But my GPS60 does log the flight at the right place, so apparently the GPS60 ís getting the correct lat and lon values... So: GPS60 gets wrong Whiskey compass value, FSInterrogate gets the right. GPS60 get right lat/lon value, FSInterrogate gets wrong values. Weird!! FSInterrogate also states that the format of the Whiskey Compass value is just plain degrees, but I think that is wrong. Can you confirm this? Greetings, Jasper Bussemaker

Hey Pete, I released the GPS60 V2 today, have fun using the TCAS function :P http://www.utr-online.com/GPS60.htm Greetings, Jasper

Hi pete, I now fully got the table :D The crash was caused by reading the callsign. VB includes a function to convert an ascii integer to the actual string, I used that. I am now working hard on V2, which will be released before sunday I think. Sorry for the frustrating moments :( And thank you for your help! :) Greetings, Jasper

The 'mysterious crash' is really mysterious: Off course I run my applications first in debug mode! But when the crash occurs, a message pops up (from Windows) which says that VB doesn't work anymore, so it is not VB error (in the code) but really an application crash! And BTW, it occurs with the way I use it, a second way (read every slot, but then in 40 bytes length) and even your way of grabbing the table! Perhaps it is something in the FSUIPC module which I had to add to my project....... I am going to say goodbye to you now if you can't take it anymore.... Greetings, Jasper

Sorry, but I just TRIED if closing the connection might have helped solve the error, it didn't so I removed it again. If you said this earlier, it could have solved a lot of problems... :? Because this helps understanding is a lot better. Now if I read all the bytes, I must have a way to 'decompress' the data, as I can't do anything with just 3840 bytes.... BTW: The same mysterious crash happens when using this code: If FSUIPC_Read(&HF080&, 3840, VarPtr(Data), dwResult) Then If FSUIPC_Process(dwResult) Then End If End If Jasper

Ok, I now have grabbed the TCAS table by doing this: :D When I looked @ FSInterrogate in Interrogate mode, I saw that every slot, has got its own offsets. I read them all (or actually only the ones I needed like Lat, Lon, Alt, Hdg, Spd, Callsign) by increasing the offset I am reading every time I start a new cycle of 96. Like this: CurOffset = &HF080& + i * 40 (yes, this works) What made me solve this (except a mysterious crash, see below): I looked in the MSDN library at the different types and wrote down what types they were (like U8, U16, U32, FLT32 and FLT64) and declared the variables I used to get the data as the appropriate type. :) There is still one (little) problem: Now I have read everything, but when exiting the procedure VB FREEZES AND CRASHED.... :shock: :? :x :twisted: :evil: :cry: I don't know where it is about, I even added the Call FSUIPC_Close call in the end of the sub!!! :? So this is very weird.... But as it has (likely) nothing to do with FSUIPC, I will continue to solve this myself... :wink: Thanks for your help in any way! Greetings, Jasper

Can't you just compile the code you thought of in C into an activeX control and give it to me :) ?

No but I mean if I wanted to put a name of an aircraft into a label, I must copy the name in the array to a labels caption right? They just were examples... I started a tread about this problem on vbforums.com, so I guess my next post on this forum will be the solutions :) Greetings, Jasper

Well, I actually didn't try it out, but I thought the i * 40 was added to it as decimals, but not really sure. But let's suppose I did load all the 3840 bytes, I just do like: AicraftName(0) = AI(0).idATC AircraftLon(0) = AI(0).lon 'ect. ect. NOTE: The arrays AircraftName and AircraftLon are just examples, I am not going to use them, they are just to show you, in case you wonder... And if I would replace it all by one statement, all the data is put into the AI(0) only, so the rest of the 96 is empty... And what about sending the sourcecode of trafficlook.exe to me :) See my website for my email address Jasper

As I read this all, I definitely realize that VB is not programmed to make applications which use complex bit and byte transferring :P So it must be about this: Dim AI() As TCAS_DATA, CurOffset as Long ReDim AI(0 To 96) For i = 0 To 96 CurOffset = Val("&HF080&") + Val(Hex(i * 40)) If FSUIPC_Read(CurOffset, 40, VarPtr(AI(i)), dwResult) Then If FSUIPC_Process(dwResult) Then End If End If Next

Can't you give me the code of your own reading of the TCAS table (in C). Just the reading, and then I will try to translate it. Because I have read somewhere that C is a bit like Actionscript (flash), and I have got a bit of experience in that... Thank you