Skip to main content
Topic: pushing external data into client (Read 10438 times) previous topic - next topic

Re: pushing external data into client

Reply #15
[quote author="jawi"][quote author="arhi"]what is the RAW data format?[/quote]

Just raw bytes: given the sample width (in bytes) and the sample depth, it will combine each pair of bytes into a 16-bit sample value (MSB first).[/quote]

ah so there you can't say the sampling time etc ... just states ... might be easiest one to try for start :D

Re: pushing external data into client

Reply #16
you can define the sample rate in Hz, or define that the samples are state transitions...
when good software is not an alternative...


Re: pushing external data into client

Reply #18
For timed data: assuming the time starts at zero, each sample corresponds to the index * sample interval.

For state data it is assuming we start at state 0 and each sample is an increment of the state.
when good software is not an alternative...

Re: pushing external data into client

Reply #19
[quote author="jawi"]For timed data: assuming the time starts at zero, each sample corresponds to the index * sample interval.

For state data it is assuming we start at state 0 and each sample is an increment of the state.[/quote]

so you don't define it in raw file but the way you configure "scan" right?

Re: pushing external data into client

Reply #20
Quote
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).
when good software is not an alternative...


Re: pushing external data into client

Reply #22
hm something is wrong with RAW format ?!

this is what I have on the LA:


this is what my txt display of first 100 states looks like
Code: [Select]
0000000000000111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111111
1111111111111111111111111111111111100000000000000000000000000000000000000000000000000000000000000000
0000000000000000000010000000100000011000000100000011000000100000011000000100000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

This is what hex of the RAW file looks like:
[attachment=2]

And as you can see it coresponds ok (the hex) with what's on LA display and what's in txt representation

but this is what capture in ols client looks like :(

[attachment=2]

you see both the tracewave and the capture settings I used, channel count 16 so 2 bytes (and this is proper since channels 4+ are all low in whole trace), sample rate irrelevant, depth 4k (that's how many samples I have), sample width 1 (no clue what this is)


Re: pushing external data into client

Reply #24
want to use the "fancy" file now .. I have a question  -
 - Compressed - does it expect RLE compressed data in the file or?
 - AbsoluteLength - maximum timestamp - but in what units? seconds? milliseconds? microseconds? picoseconds? long integer?
 - cursorX - long int, I assume timestamp in same format as AbsoluteLength?
 - TriggerPosition? same as cursorX ?
 - 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
Quote
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?

thanks

Re: pushing external data into client

Reply #25
[quote author="arhi"]hah .. that width needs to be 2 ... WORKS !!![/quote]

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).
when good software is not an alternative...

Re: pushing external data into client

Reply #26
[quote author="arhi"]want to use the "fancy" file now .. I have a question  -
 - 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.

[quote author="arhi"]
 - 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.
 
[quote author="arhi"]
 - 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.

[quote author="arhi"]
 - 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
Quote
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:

Code: [Select]
;Rate: 1000
;Channels: 16
;AbsoluteLength: 8
aa@0
aa@1
aa@2
aa@3
aa@4
bb@5
bb@6
cc@7
cc@8

is the same as the shorter version:

Code: [Select]
;Rate: 1000
;Channels: 16
;AbsoluteLength: 8
aa@0
bb@5
cc@7

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?
when good software is not an alternative...