Thanks Steve - I'm pleased that my original solution (compound types) was similar to what you have used. I appreciate the heads up on bit fields - that would probably have got me.
Cheers On Fri, Dec 17, 2010 at 11:42 AM, Steve Bissell <[email protected]>wrote: > > Hey karl - not sure about "best practices" but what I've done, which seems > to > work pretty well so far, is indeed to use compound types, with the first > element of the struct being time. This works well for our application, > where > we may be recording several thousand distinct channels that can be regarded > as asynchronous, and hence each of the packet tables storing the channel > data carries its own timestamp in the table entries. > Only thing to watch out for is that you cannot store bit-sized parameters > inside a compound type, see my post > > http://hdf-forum.184993.n3.nabble.com/Possible-to-pack-bit-types-into-compound-data-types-td1131024.html#a1168717 > for an example of the problem (and a very basic example of a compound > type). > For our application, it's hard to see how we'd store time any other way, > since each record in the packet table arrives unpredictably, so referencing > some "other table" would just add complication storage - arrival time is an > essential property of the data itself. > Cheers > Steve > -- > View this message in context: > http://hdf-forum.184993.n3.nabble.com/Best-practice-for-timeseries-and-storing-timestamps-in-Packet-Table-API-tp2104069p2104301.html > Sent from the hdf-forum mailing list archive at Nabble.com. > > _______________________________________________ > Hdf-forum is for HDF software users discussion. > [email protected] > http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org >
_______________________________________________ Hdf-forum is for HDF software users discussion. [email protected] http://mail.hdfgroup.org/mailman/listinfo/hdf-forum_hdfgroup.org
