This section allows you to view all Messages made by this member. Note that you can only see Messages made in areas you currently have access to.
Messages - jawi
What you might want to try is to define a trigger for your signal: SPI works with a /CS signal which needs to be asserted if the master wants to talk to a slave. The BP does have support for simple triggers (only 1 stage IIRC), which might be just enough for your capture to work.
Hope this helps,
1. http://dangerous-prototypes-open-hardwa ... are/SUMP.c
Thanks for reporting!
- Compressed - does it expect RLE compressed data in the file or?[/quote]
I don't know exactly what compressed is doing. It is a remnant of the original SUMP format I based the format on. The OLS client assumes that this value is, if present, true.
- AbsoluteLength - maximum timestamp - but in what units? seconds? milliseconds? microseconds? picoseconds? long integer?[/quote]
The maximum timestamp is the last timestamp seen in the sample data. It is unitless, but you can derive time in second from it by subtracting the trigger point and dividing it by the sample rate.
- cursorX - long int, I assume timestamp in same format as AbsoluteLength?
- TriggerPosition? same as cursorX ?[/quote]
Yes and yes. The trigger position is used to determine the relative time: the time before the trigger moment and the time after.
- sample data == <sample value>@<sample number>, sample value is HEX that's clear 1 byte for 8 channels, 4 bytes for 32 channels right? but sample number - wiki states
The sample number correlates to the absolute time at which the sample was taken.explain this? is this just the order number or this can be a timestamp? Can this happen? Can it be 64bit long?[/quote]
The sample number is a counter that is started at 0 once the first sample is taken and increments for each sample. The data file allows this counter to be non-contiguously in which case it assumes that the sample value did not change. To make this more concrete with an example, suppose we have the following data, which is 16-bits data sampled at 1 kHz:
is the same as the shorter version:
Note that we Because the latter case no longer states the sample value at 8, we need the absoluteLength property to determine what the last sample number was.
Does that answer your questions sufficiently to continue your work?
Yes, that's explainable, as the sample width is what is actually determining how many bytes are read to represent the 16 channels (in the case you had a sample width of 1, it would simply fill the MSB of your 16-channels with zeros).
so you don't define it in raw file but the way you configure "scan" right?
For the raw data, yes.
In the OLS data-file format, you can define these things in detail (see the wiki page I mentioned earlier).
For state data it is assuming we start at state 0 and each sample is an increment of the state.