INT field not decoding negative numbers properly

[pyrog]

See jcmb/RTCM3#6 and jcmb/RTCM3#7

How to reproduce it

go run latency.go -caster http://caster.centipede.fr:2101/PAS64 -username centipede -password centipede

{AbstractMessage:{MessageNumber:1006} AntennaReferencePoint:{ReferenceStationId:0 ItrfRealizationYear:0 GpsIndicator:true GlonassIndicator:true GalileoIndicator:false ReferenceStationIndicator:false ReferencePointX:46320270351 SingleReceiverOscilator:true Reserved:false ReferencePointY:274126208576 QuarterCycleIndicator:0 ReferencePointZ:43694212166} AntennaHeight:0}

ECEF coordinates must be 46320270351 -751698368 43694212166

[umeat]

Interesting. All integer RTCM fields are two's complement in the spec. They should be being parsed as such (everything else appears to work correctly). Perhaps there is some other bit alignment issue. I'll take a look when I get the chance.

[umeat]

You're definitely correct - this issue stems from the restruct library not correctly dealing with integers which aren't int8, 16, 32, or 64. It just unpacks the bits into the larger int type and therefore the sign bit is not considered correctly (but works fine for positive numbers).

go-restruct/restruct#46

In this specific case you can do the following:

    bit37 := int64(math.Pow(2, 37))
    bit38 := int64(math.Pow(2, 38))
    if x&bit37 == bit37 {
        x = x - bit38
    }
    if y&bit37 == bit37 {
        y = y - bit38
    }
    if z&bit37 == bit37 {
        z = z - bit38
    }   

I'd rather wait until this is fixed upstream, because otherwise we'll have to add similar code to all of the serialize and deserialize methods for all the structs containing ints.

[umeat]

Thanks for reporting - this is fixed now, I'll cut a release v0.0.2.

[pyrog]

thank you very much 😃

[fenggolang]

For RTCM SSR, the decoded number is beyond the range of precision representation？

#5