Hi Andrew,
Thanks for the quick response.
Generally, yes, I acquire and save in Spike, and process the data in my own Python applications. I sometimes also look at the recorded data in Spike. Probably 75%/25% split. In either case, it would be good to know which sweeps are potentially corrupted (or uncalibrated) due to overload.
Preferentially, all sweeps would be kept, and those that are overloaded would be flagged. This would allow continuous data acquisition, even if some of the sweeps should be considered suspect, and then I can deal with them accordingly and as desired in post-processing.
The next best solution would be to simply not record sweeps that are overloaded, but personally I would prefer the first solution, since to me it’s always better to collect as much data as possible and deal with imperfections accordingly in post-processing. For some applications, I could imagine it’s better to have a sweep even if it’s uncal than to be missing data completely (for example, when trying to capture the exact time and general nature of an infrequent short burst, for example).
Of course, the truly ideal solution is to have both: the option to either record and flag overloaded sweeps, or not record them.
I believe there’s 16 bytes of unused data in each sweep (unint64_t reserved[2]). Could the overload condition be encoded in part of those unused bits?
By the way, when decimation is used, how are overloaded sweeps that occur during the decimation period handled? Is there any special treatment or are they handled like any other sweep? If the latter, it would probably be good to flag the affected decimated sweeps too, if they are possibly corrupted.
I always try to avoid acquiring important data in overload conditions, but sometimes I’m on the edge due to dynamic range considerations, and it would usually be good to be able to identify uncal data if it happens.
Thanks!
Andy
