You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This sounds like a very elegant solution. For expanding fields, can be fieldname(expand) or fieldname(*).
I plan on adding a capability to have an array shape be defined by a preceding field in the packet. this allows multiple variable length fields in the same packet. I was told a few instruments being developed at LASP do this with their packets. in this spec, that could be written out as fieldname(otherfield). if we do that maybe we should change fieldname(expand) and array_shape=“expand” to just fieldname(*) and array_shape=“*” so no one thinks there is a field called expand.
We should really put together a page on the site which describes this csv format, too
I would suggest the following convention
So
uint(shape)
.This matches the programmatic way to define it and does not add too much complexity to the csv file.
The text was updated successfully, but these errors were encountered: