Reading DME data with VB

[CaptnKebec]

Hi,

I use VB to read data from the radio panels, I succeeded for all COM and NAV, ADF and XPDR. I try to read DME distance and speed and getting strange number as results (808333630) I found a thread explaining how to read it with C in this forum but I'm unable to do it in VB, does anyone have a clue how to do it??

Thanks

Michel

[jd]

maybe this will help

Public Function Velocity() As Single ' knots Plane's current groundspeed.

Dim x As Long

Dim dwResult As Long

Call FSUIPC_Read(&H2B4, 4, VarPtr(x), dwResult)

Call FSUIPC_Process(dwResult)

Velocity = (x / 65536) * 3600 * 3.28084 / 5280

End Function

Public Function Velocity_Indicated() As Single ' knots Indicated airspeed.

Dim x As Long

Dim dwResult As Long

Call FSUIPC_Read(&H2BC, 4, VarPtr(x), dwResult)

Call FSUIPC_Process(dwResult)

Velocity_Indicated = x / 128

End Function

Public Function Velocity_Y() As Single ' meters/second Vertical speed rate

Dim x As Long

Dim dwResult As Long

Call FSUIPC_Read(&H2C8, 4, VarPtr(x), dwResult)

Call FSUIPC_Process(dwResult)

Velocity_Y = x * 60 * 3.28084 / 256

End Function

[Pete Dowson]

I try to read DME distance and speed and getting strange number as results (808333630).

Because that data is a character string not a number. I hope JD's answer helps you.

Regards,

Pete

[CaptnKebec]

JD,

The code you wrote is OK, I've already succeeded to get COM, NAV, ADF and XPRD data with a similar code because all those offsets are numbers and not character. What I'm unabled to do is get something right with a offset who is returning character string. The offsets for DME (0C29,0C2E, 0C33, 0C38) are 5 bytes strings as Peter mention.

I can't put a string type in the FSUIPC_read call because it need a long type, and even if I convert the result to string I still get those strange numbers.

Did you succeeded to read a string value in VB?

Thanks,

Michel

[jd]

oh, i thought you needed to get the speed too. i'm off to my wife's foot surgery, i'll return later

jd

[Pete Dowson]

I can't put a string type in the FSUIPC_read call because it need a long type, and even if I convert the result to string I still get those strange numbers.

I know this is addressed to JD, but I have to butt in and say how amazed I am that VB has so much difficulty handling things as basic and simple as strings. As long ago as 1978 I remember using the very earliest forms of Basic, and their handling of strings was exemplary. I really can't understand what Microsoft has done to it all. :cry:

Anyway, just in case your comment causes more confusion, please note that the FSUIPC_Read and _Write procedures themselves do not care one iota what the data is. The form of the data can be absolutely anything you like. It is most certainly not just a "long".

What you are confusing the DATA with is the pointer TO the data. That's all FSUIPC needs -- the pointer to wherever the data is, in memory, and of course its length, in bytes. After all, all the interface has to do is move stuff from one place to another (one process to another, or in the case of WideFS one PC to another).

In most languages pointers appear to be quite fundamental and straight forward. They are simply addresses in memory, something fundamental to computers almost since Babbage. I don't know what VB has done to them but they are evidently a continuous cause of pain. Since much of the Windows API depends on pointers too, I really can't understand how folks actually manage to make VB programs do anything useful. :wink:

Sorry, I can't be more helpful, but this is so disparaging. :cry:

Regards,

Pete

[Erups]

Anyway, just in case your comment causes more confusion, please note that the FSUIPC_Read and _Write procedures themselves do not care >>>one iota<<< what the data is.

[CaptnKebec]

Oups sorry Peter,

you're right, the data type can be anything with the read statement of FSUIPC, it effectivly need the address of that variable and that's why in VB we use VarPrt to get that address and pass it to FSUIPC.

The thing is, I defined a string variable and put it in FSUIPC using VArPrt and I get those strange numbers, when an offset returns a number or a boolean the result I get is OK but when it's string the data is incoherent??

There must be a way in VB to get the right result (I hope). I'm not to familiar with C, but if I have no choice I'll make a small exe ic C to do the job or re-write my prog completly in C.

Thanks Peter and sorry for the misleading comment.

[CaptnKebec]

Mr Dawson,

I keep calling you Peter! I've noticed your name is PETE.

I'm just beginning in the sim community and I already noticed that your work is everywhere! So I should have known your name better!

Sorry about that!

Michel

[Erups]

I read you used "string" as type for the variable.

Don't know VB, but for C string and char are two different things.

And anyway how are you checking what data has been loaded in the variable?

Because it may be that now you are getting the data right, but you are displaying it wrong always because of data type...

[Pete Dowson]

I defined a string variable and put it in FSUIPC using VArPrt and I get those strange numbers

But any string character data, viewed as a number, would look strange. View it as a string of characters and see what it looks like.

For example, take the string "Pete". Inside the computer, in ASCII, this is 4 bytes (one per character) plus a zero terminator. Ignoring the latter for the moment, the 4 bytes in hexadecimal would contain:

50 65 74 65

If these 4 bytes are viewed as a 32 bit integer, the hex value is

65746550

which in decimal is 1702126928. Doesn't look much like "Pete", but it's the same data.

Regards,

Pete

[Pete Dowson]

Mr Dawson,

I keep calling you Peter! I've noticed your name is PETE.

Not a problem, Pete is short for Peter! However, my family name is actually Dowson, with two o's, no 'a' at all. :wink:

Regards,

Pete

[CaptnKebec]

So I was right for the name the first time and wrong in my correction!!

Sorry again.

OK, now here's the exact code line I use for testing the output

Dim dme_txt As String

If FSUIPC_Read(&HC33, 5, VarPtr(dme_txt), dwResult) Then

If FSUIPC_Process(dwResult) Then

MsgBox (dme_txt)

End If

End If

The string I get is 808333630 if I use the logic Pete describe, I should have 5 byte so it's 80 83 33 63 0, how can I convert this to the real data?

[Pete Dowson]

The string I get is 808333630 if I use the logic Pete describe, I should have 5 byte so it's 80 83 33 63 0, how can I convert this to the real data?

The number you are quoting is DECIMAL! You canot take a decimal number and convert it to a set of hexadecimal bytes simply by chopping it up into pairs! Please refer back to the example I gave you! You are not reading what I wrote!

808333630 is actually hexadecimal 302E313E, which is wrong but close -- the ASCII character codes there are

3E 31 2E 30

I think you may have a small error in your number, because this gives ASCII string ">1.0". I think the first character may have been something different. If your decimal number was 808333620 instead then the sequence would be:

34 31 2E 30

which is "41.0", a reasonable range from a DME.

You won't see the terminating zero because your number is from the first 4 characters only (4x8=32), a 32 bit integer can only accommodate 4 characters, not 5.

The fact that the "number" is so close to being a good ASCII string means you ARE reading the data correctly via FSUIPC. Your problem is only in the way you are looking at it.

Someone who knows how to program VB needs to help you, unless you can refer to some books, because I have no idea why you cannot look at the data you are getting as a string instead of a number.

Regards,

Pete

[CaptnKebec]

Hi,

Got it finally!!

Pete please don't be mad at me, I was reading your response but didn't understand. As you can see in the code below, with VB it's a lot of work to extract a single value, well thank's a lot for your help.

Here's the code to make it work:

Dim dme_txt As String

dim dm(4) as string

If FSUIPC_Read(&HC33, 5, VarPtr(tmp), dwResult) Then

If FSUIPC_Process(dwResult) Then

aa = hex(tmp)

dm(1) = Chr(CLng("&h" & Right(aa, 2)))

dm(2) = Chr(CLng("&h" & Mid(aa, 5, 2)))

dm(3) = Chr(CLng("&h" & Mid(aa, 3, 2)))

dm(4) = Chr(CLng("&h" & Left(aa, 2)))

dme_txt = dm(1) & dm(2) & dm(3) & dm(4)

End If

End If

msgbox(dme_txt)

[Pete Dowson]

Pete please don't be mad at me, I was reading your response but didn't understand. As you can see in the code below, with VB it's a lot of work to extract a single value

I'm not at all mad (well, not in that sense! :wink: ), but I must admit that I don't understand it at all. Why isn't a string a string?

Are you by any chance compiling with a wide-character or Unicode option set someplace? Those character codes are not ASCII, but 16-bit codes (i.e. 2 bytes for each character).

However, for the basic ASCII subset I think the high byte is always zero. So if this were the case at least the first character should appear correctly. I don't understand how all you got was a decimal integer representing the first 4 characters.

Regards,

Pete

[CaptnKebec]

It's not in the compiling since I didn't compile it yet, I was just in the interpreter and running it to see if it works.

It's just VB I think, it's not the first time I see strange things in this language, but I already use to much languages, I don't want to learn C or another language yet, so I'm dealing with the "weird" VB.

Thanks

Cheers

Michel

[Pete Dowson]

It's just VB I think, it's not the first time I see strange things in this language

But what if you did this:

dim dm(5) as string 

If FSUIPC_Read(&HC33, 5, VarPtr(dm), dwResult) Then 
If FSUIPC_Process(dwResult) Then 
msgbox(dm)
End If 
End If

Isn't this really what your version boils down to? It seems extremely odd to have to expand the characters, already in ASCII the way you want them, into hexadecimal character form then back again. That's taking weirdness to extremes! :o

[LATER]

I just had a scan through some older threads here, as I was sure this must havecome up before. Try this thread:

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

It seems to end up with a more sensible solution. Still makes VB look poor to me, but not as daft as the antics your code has to get up to (if you don't mind me saying so -- ingenius, but daft, yes? :wink: ).

Applying the solution there, your example would become something like:

Dim dm(5) As Byte 
Dim dme_txt As String 

If FSUIPC_Read(&HC33, 5, VarPtr(dm(1)), dwResult) Then
If FSUIPC_Process(dwResult) Then 
   cnt = 1 
   Do While dm(cnt) <> 0 
      dme_txt = dme_txt & Chr(dm(cnt)) 
      cnt = cnt + 1 
   Loop 
End If 
End If
msgbox(dme_txt)

(Thanks to Armando!)

Regards,

Pete

[CaptnKebec]

I've tried it but this method strips the zeros, example if the actual reading is 105 i'm getting 15.

With a little work I could simplify the code, but now it's working and I'll concentrate on the input from my switches (hope it's gonna be more easy).

Thanks a lot

[Erups]

For example, take the string "Pete". Inside the computer, in ASCII, this is 4 bytes (one per character) plus a zero terminator. Ignoring the latter for the moment, the 4 bytes in hexadecimal would contain:

50 65 74 65

Pete, sorry to bring this thread up again, but here i need to know:

which one is wrong between your statement above and this ascii table? http://www.asciitable.com/

Please, forgive me, i do not intend to just point out your errors, i really need to know which one is right for an article i'm writing.

Thank you

Claudio

[Pete Dowson]

50 65 74 65

Pete, sorry to bring this thread up again, but here i need to know:

which one is wrong between your statement above and this ascii table? http://www.asciitable.com/

Neither. Are you looking in the wrong columns?

50 = P

65 = e

74 = t

65 = e

which spells Pete.

I've been in computers using ASCII (well, EBCDIC originally) since 1963. The alphabet and numerics I know by heart! :wink:

Regards

Pete

[Erups]

Mhhh ok you were talking HEX i was talking DEC...

Thank you Pete, helpfull as usual :)

Best regards

Claudio

[Pete Dowson]

Mhhh ok you were talking HEX i was talking DEC...

Yes. The original paragraph, above, from which you took it did say so, viz:

For example, take the string "Pete". Inside the computer, in ASCII, this is 4 bytes (one per character) plus a zero terminator. Ignoring the latter for the moment, the 4 bytes in hexadecimal would contain:

50 65 74 65

If these 4 bytes are viewed as a 32 bit integer, the hex value is

65746550

which in decimal is 1702126928. Doesn't look much like "Pete", but it's the same data.

excepting, of course, the original didn't have the word emboldened. :wink:

Regards,

Pete