twm's blog

If you have ever worked with GPSes you probably know about the NMEA protocol. Many of the sentences there have got a time stamp that is in UTC (universal time coordinated – thank the French for the odd word order). Like me, you might have assumed that GPS works with UTC, but that is not the case.

Internally GPS works with GPS time which is kept as weeks and seconds since the start of the GPS system at 00:00:00 on 1980-01-06. This time is kept by atomic clocks. The other GNSSes (Global Satellite Navigation Systems) also have their own internal clock.

UTC (formerly known as GMT) is the local time at longitude 0 (where the London district Greenwich is located, hence Greenwich Mean Time), without any fiddling with daylight savings time. Since UTC is meant to conform closely to the rotation of the earth and the latter is not stable, it needs the occasional leap second. At the time of this writing, there have been 18 of these since 1980. So UTC is 18 seconds behind GPS time by now.

Why do I write about this? I have recently started integrating an OXTS INS into one of our measurement vehicles. These devices can be configured to send NMEA data over a serial port, just like a conventional GPS. They can also send NCOM data, which is their internal binary format. While the NMEA data adheres to the NMEA specification of providing the times in UTC, the NCOM data does provide the “native” GPS time. So they do not match, which took me by surprise when I encountered it.

Of course I first assumed a bug in my own code, but it wasn’t. The first hint was that the times were always 18 seconds off. I still didn’t get it and had to actually call support. (Afterwards I googled it and found lots of references, so I guess I should have been able to figure it out myself.)

Since that offset is not constant – there might be yet another leap second soon – the NCOM format also contains the current UTC time offset. Look in Table 26 on the NCOM format documentation.

It’s sent in the Status Information as channel 15 and is stored in byte 7 of the BatchS structure. Just to make it difficult to read it is encoded as a 8 bit signed integer with a twist: Bits 1–7: UTC time offset, valid when Bit 0 = 1.

Here is some Delphi code to decode that particular value:

function TSTable26Rec.TryGetUtcTimeOffsetSecs(out _Offset: Integer): Boolean;
begin
  // only valid if Bit0 = 1
  Result := ((UtcTimeOffset and $01) <> 0);
  if Result then begin
    // the type cast to Smallint is necessary to get the sign correctly
    _Offset := Smallint(UtcTimeOffset shr 1);
  end;
end;

In December 2018 I found out that some of the functionality in my Delhi IDE explorer was broken in Delphi 10.3, namely the function to select the current active control or automatically follow the focus. The reason was that the IDE now used the Screen.ActiveControlChanged event itself, disabling it for to my plugin.

Today I finally found a way to fix it, so the current source code will work with Delphi 10.3 (all three releases).

I keep forgetting this so this post is mostly so I can look it up:

Delphi uses DST files to store the desktops – that is the layout of the various parts of the IDE. Theses files are in INI format and are stored in

Delphi 2007 and later

[users]\[username]\AppData\Roaming\[Company]\BDS\[version]
e.g. c:\users\johndoe\AppdData\Roaming\Embarcadero\BDS 20.0

Delphi 2006 and older

[programfiles]\[company]\[Delphi X]\bin
e.g. c:\program files\Borland\Delphi 7\bin

Since AppData is a hidden directory, a search for *.dst in the Windows Explorer will not find these files. An easy way to get to AppData is opening an Explorer Window and typing %appdata% into its address field.

Why would you want to find these files?

Delphi 10.3 has a very annoying bug where it does not store the window position correctly. E.g. I move the IDE window to my secondary monitor and maximize it. When I exit and restart it, the Window will appear somewhere on my primary monitor and usually be very small. Editing the DST file fixed that for me.

NOTE: The following applies to Delphi 10.3 Rio. Old versions stored the size and position in pixels. I don’t know when exactly they switched to “percentages”.

WARNING: If you write invalid values into the file, the IDE will crash on startup (We call that “failing gracefully”. 😉 ) So be sure to always keep a backup of a working file (or copy one of the default files over your borked file if you run into problems).

I set the following entries:

[Main Windows]
PercentageSizes=1
State=0
Left=-10000
Top=0
Width=10000
Height=10000

PercentageSizes apparently means that the values are stored as percentages of the actual width and height of the monitor, for an appropriate meaning of “percentage”, in this case 1/10000, so 10000 means: Use the full width and height. The same goes for Top and Left. My secondary monitor is to the left of the primary one, that’s where the -10000 value for Left is coming from.

State=0 means that the window state is normal, that is: not maximized (and also not minimized, but who wants a minimized window for this?). State=2 means maximized and is what does not work for me at all.