cast and shift

I have a minority of users I support that are the programmers/techs in the lab. They're the genesis of the various programming-related support I do that has increasingly been things I can handle myself and not have to automatically pitch to a programmer here.


The data acquisition system has a clock that only resets when you cycle the power. I don't remember how many bits the clock is (EDIT: 40 bits) but it will roll over after about a month of being on (and deity help you if that happens during a recording). Anyways, the actual time recorded in the file isn't this clock value because a "start" time is noted and considered to be 0 and all subsequent acquisitions are subtracted against the start value to get the correct relative time. The SDK that can access data on the fly doesn't have access to that information and so it returns the actual value of the timer. Someone wrote in wanting to know if the non-adjusted times were kept in the file, so I modified my file reader to pitch the clock values of the data at me. It was tricky and here's why.

The file format keeps the time of each data block in two variables representing the upper 8 bits and one more variable representing the lower 32 bits (5 bytes total). This was apparently to save space and not use two 32 bit variables. The high byte is stored in an unsigned short, and the other 4 bytes is in an unsigned int. To get this into one variable the following is done:

long int timestamp = ((long int)datablock.upperbyte << 32) + (long int)datablock.lower4bytes;

I take my one byte and cast it to a bigger variable that can hold 5 bytes and then shift that byte to the left 32 bits (4 bytes). Then I add to that my lower 4 bytes. The 5 bytes are recombined.

It's a minor annoyance but it's the first time I did any shifting and I figured I should make a note of it.