byte compression

[skimask]

Month var byte:Day var byte:Hours var byte:Mins var byte:Secs var byte
logdata var byte [8]:logdir var byte:modir var byte:daytra var byte
transwrite var byte:flittime var word:thermo var byte:humi var byte
logdata[1]=Hours:logdata[2]=Mins:logdata[3]=Secs

logdata[4]=(month & $f)+(logdir << 4):logdata[5]=flittime.lowbyte
logdata[0]=(day & $1f)+((flttime & $0700)>>3)
logdata[6]=thermo:logdata[7]=humi

No idea if this will work...it's just simple boolean logic and combining terms...

[SteveB]

Another idea, which can be implemented together with the bit-packing, depending on the exact specification/requirements of your application:

If your data is aquired and logged at consistant intervals (say every 20 sec) you can log the data as a group. Start by saving a time/date. Then every 10 (or whatever interval is approariate) events, save another time/date. Since you know the interval of the datapoints, and have the time stamps, the rest can be determined later in whatever application does the post processing of the information. You can reduce a lot of overhead this way.

If the events are not periodic, you could implement this as an offset from the start time. Start with the time/date, then each data event contains an offset from the original time/date. Depending on the expected max interval, this could save you a lot of overhead as well.

SteveB

[skimask]

If your data is aquired and logged at consistant intervals (say every 20 sec) you can log the data as a group. Start by saving a time/date. Then every 10 (or whatever interval is approariate) events, save another time/date. Since you know the interval of the datapoints, and have the time stamps, the rest can be determined later in whatever application does the post processing of the information. You can reduce a lot of overhead this way.

If the events are not periodic, you could implement this as an offset from the start time. Start with the time/date, then each data event contains an offset from the original time/date. Depending on the expected max interval, this could save you a lot of overhead as well.
SteveB

Just like the 'sliding window' method used in most compression methods...
(Wait a minute...was that example out in left field or what?)
Maybe something like the julian calender, but extended down to date/time offset from a certain start date/time, but then you'd get less than one day's worth of seconds in a word...

[SteveB]

Maybe something like the julian calender, but extended down to date/time offset from a certain start date/time, but then you'd get less than one day's worth of seconds in a word...

Yea, like a julian calander, except instead of restarting the count of days every year, you can restart the count of seconds every 18.2 hours (if you use a word). But, once an event occurs, you can restart the counter, and the new offset begins from that last offset. Sort of like restarting the Julian Calandar every time it rains in Del Rio! Or better yet, SNOWS!!