Reading Array values into variables

[Tom Gonser]

Thanks for the responses..

The precision is only tenths of meters. I don't know *why* the data is stored in 24 bits, it just is - not under my control, I am only trying to read it.

Regardless - the fundamental problem is that I have a 24 bit value stored in 3 bytes that I need to make into a variable I can do something with..... like read it digit by digit, and put a "." in the tenth's spot, and then multiply it by a factor to convert to feet..

TG

[Acetronics2]

Have a look to that thread :
http://www.picbasic.co.uk/forum/showthread.php?t=1217

here you have the solution to put your 24 bits into something usable ... just divide them as soon to reduce it to less than 16 bits ...

and that's all !!!

Alain

[Ingvar]

And the answers to my questions are ...... ? Can't help if i don't know.

/Ingvar

[Tom Gonser]

Oh- yes, sorry.

We are at about 300ft. Should be reading about 100meters or so. The GPS alt data 'wanders' so tenths of meters is a little silly, yes, but that is what is output.

The full range would want to support over 100,000ft in altitude.

TOm

[Ingvar]

Ok, you're building a spaceship, 100000 ft is high. I'd love to see this baby fly

First i think you need to look over your inputdata, methinks it's not properly extracted. I can't see any correlation between your data and 100(ish) metres, unless ofcourse it's already in tenths of ft(000D0Dhex=3341dec 3341*0,3048=1018.34 which would be close to your 100m).

Are you getting the data from a NMEA sentence($GPGGA) or is it a binary protocol? If it's NMEA you need to know that the data is separated by "," characters, they're not at a fixed position in the string. Atleast not towards the end of the string. This makes it difficult to extract and convert the data.

When you have your data properly extracted, the conversion would look something like this(pseudocode) ....

    R0.HIGHBYTE = 0        'Prepare system variables for DIV32
    R0.LOWBYTE = alt[2]
    R2.HIGHBYTE = alt[1]
    R2.LOWBYTE = alt[0] 
    AltMetres = DIV32 10
    Alt10Ft = AltMetres ** 21501  '21501/65536=0.32808
    SEROUT blah..,blah..,["Altitude :",dec Alt10Ft, "0 ft",13,10]

..... you could increase the resolution when "alt[2]" = 0 ......

    AltMetres.HIGHBYTE = alt[1]
    AltMetres.LOWBYTE = alt[0] 
    AltFt = AltMetres ** 21501  '21501/65536=0.32808
    SEROUT blah..,blah..,["Altitude :",dec AltFt, " ft",13,10]

.... you could ofcourse combine them .....

IF alt[2] = 0 THEN
    AltMetres.HIGHBYTE = alt[1]
    AltMetres.LOWBYTE = alt[0] 
    AltFt = AltMetres ** 21501  '21501/65536=0.32808
    SEROUT blah..,blah..,["Altitude :",dec AltFt, " ft",13,10]
ELSE
    R0.HIGHBYTE = 0        'Prepare system variables for DIV32
    R0.LOWBYTE = alt[2]
    R2.HIGHBYTE = alt[1]
    R2.LOWBYTE = alt[0] 
    AltMetres = DIV32 10
    Alt10Ft = AltMetres ** 21501  '21501/65536=0.32808
    SEROUT blah..,blah..,["Altitude :",dec Alt10Ft, "0 ft",13,10]
ENDIF

/Ingvar

[Tom Gonser]

Thanks much!!

Apparently it is important for the system to report over 100k...

The data is binary, not NMEA. The 3 bytes are the altitude, and it is in tenths of a meter. (binary value in tenths of meters)

My challenge is that I have THREE bytes.. each with values that together equal the value I need.

Value is sent in these 3 bytes as LSB first, then NMSB, then MSB.

Does that help?

TG

[Ingvar]

The code i posted handles your THREE bytes, alt[0] to alt[2], when needed. Alt[0] = LSB, alt[2] = MSB. At high resolution(1ft) it will go to 21500ft, low res(10ft) will go to 215000ft.