lfpinit() signed or unsigned?

[Hal Murray]

gem at rellim.com said:
>> There is nothing to normalize in a l_fp  All bit patterns are valid.
> Sort of.  The header notes imply the integral and fractional part may be
> signed or unsigned.  Separately.  I have not confirmed if the code use that.

The whole point of l_fp is so you can do 64 bit arithmetic.  There is no sign 
bit in the fractional part.  It piggybacks on the sign of the high half.


> Actually, there may be a better way.  NTP defines an Epoch on the wire.
> I do not know when it is sent.  We are currently in NTP Epoch 0. In 2036 it
> goes to NTP Epoch 1.  If we can grab that field off the wire we are good. 

It's not on the wire.  At least not in the main packet format.  I don't think 
it is in mode 6.  Yet.


>> I think the build date of the code will be a good start.
> Which breaks regression tests.  We tried that on gpsd and the results were,
> to be kind, loud. 

Please say more.  I don't remember that scene.


> Semms I believed someone that misread the RFC.  NTP Time is based on
> 1Jan1990, but when using the Epoch it can uniquely define any time backwards
> or forward. 

s/1990/1900/

I think the idea is that a 32 bit value can represent a range that straddles 
the roll over boundary.  If you have some known starting time, values of 32 
bit times represent start to roll-over and roll-over to start+32 bits.

That's backwards or forwards from the next roll-over rather than backwards or 
forwards from now.

It's the same problem as the GPS 1024 week.


-- 
These are my opinions.  I hate spam.