<t4nk_freenode>
I think I got the directory content here
<t4nk_freenode>
still unclear of how it works precisely, but I now construct a datastream by putting bits from the 4 data lines together
<t4nk_freenode>
somehow it doesn't add up from what I read about the protocol; I've yet to find a crc16 that actually computes
<t4nk_freenode>
better read up on FAT16 while I'm at it :|
<t4nk_freenode>
(though I'm getting sick and tired of the whole world and their dogs using SPI.. bah)
Degi has quit [Ping timeout: 255 seconds]
Degi has joined #scopehal
bvernoux has joined #scopehal
<d1b2>
<johnsel> hmmmm t4nk_freenode
<t4nk_freenode>
hi, I was just messing around a bit more ;)
<d1b2>
<johnsel> that's progress!
<t4nk_freenode>
setting up a transfer with a file just over the 512B block size, so I can hopefully get the 'multi-block' command sorted
<t4nk_freenode>
something about the crc16 eludes me still, I'm probably contaminating the data while processing in my prog
<azonenberg>
on my end, the siglent load i ordered is finally out for delivery
<azonenberg>
so ngscopeclient and libscopehal should start getting electronic load support in the next day or two
<t4nk_freenode>
has this 'ehntoo' fellow, orsth been around lately? I think he may have some tips on the sd protocol perhaps
<azonenberg>
i dont recall having seen them in a little while, no
<d1b2>
<20goto10> Hmm, the Hantek USB scopes (6000 series) look interesting as a Picoscope alternative
<d1b2>
<20goto10> And looks like the Sigrok project have some reverse-engineered information
<azonenberg>
there is an open wishlist item for some hantek scope support, i cant remember the model
<azonenberg>
nobody has had both the time and hardware
<azonenberg>
so the ticket has been open for years
<t4nk_freenode>
pff, got it! turns out to be XMODEM for the crc16
<azonenberg>
So I'm starting to think again about how we handle low rate livestreaming instruments such as multimeters and power supplies
<azonenberg>
i.e. they essentially output a scalar, which you poll a few times a second
<azonenberg>
in scopehal, we have a method that you call to get that value (in most cases there's more than one channel or more than one value, e.g. a PSU that can output current and voltage simultaneously)
<azonenberg>
and in ngscopeclient, we display trends of those values via a UI that is completely separate from the main scope waveform display
<azonenberg>
And is locked to only that instrument, etc
<azonenberg>
This has a lot of issues and I'd like to improve it
<azonenberg>
for example, i want to be able to calculate power output by a supply by multiplying the voltage and current values
<azonenberg>
or plot multiple power supply channels on a single timeline
<azonenberg>
or even cross instrument, plotting say a multimeter reading plus a power supply reading on a single timeline
<azonenberg>
Also doing this on the filter graph
<azonenberg>
miek, lain, louis, electronic_eel, monochroma: any thoughts on good ways to structure APIs for this?
<azonenberg>
(and/or guis)
<azonenberg>
keeping in mind again that instruments can be polymorphic, e.g. an oscilloscope can also have meter channels
<azonenberg>
Anyway, so the other fundamental API issue is what to do with things like multimeters that can sample at high sample rates into a buffer, basically acting like a scope
<t4nk_freenode>
after this, unresponsive for a while.. I get thrown to a kde plasma login screen, and my session is gone
<t4nk_freenode>
reproducible, like every time
<t4nk_freenode>
or, every other time actually
<t4nk_freenode>
the other time I just get a segfault but the pc stays alive
<electronic_eel>
azonenberg: multimeters that sample - aren't they ususally triggered by some trigger input or command? so in this regard they act very similar to a scope, just slower
<electronic_eel>
the question is if them being slower means that a completely different api/gui is needed or not
<electronic_eel>
you even might want to mix timestamped slow data from a multimeter with some waveform from a scope. would be possible if you have some trigger/gate input on the multimeter you could use to sync
<azonenberg>
yes exactly. making them actually be oscilloscope class is probably a bad idea
<azonenberg>
because scope and meter frontends are totally different
<azonenberg>
one possible implementation is for the base instrument class to expose a set of N channels in its API
<azonenberg>
each channel can be either vector (outputs a waveform), scalar (outputs a single value), or both (e.g. a meter with a high speed sample buffer)
<azonenberg>
then derived classes would provide additional controls on specific channels
<azonenberg>
e.g. an oscilloscope would have options for input coupling and attenuation
<azonenberg>
a meter would have options for controlling the measurement mode
<azonenberg>
etc
<azonenberg>
And then we would have conversion filters to, say, extract the Nth sample of a vector as a scalar
<azonenberg>
or trend a scalar over time to create a vector
<azonenberg>
thoughts? sound sane?
<electronic_eel>
so the conversion filter would be the way to bridge the speed gap between the two
<electronic_eel>
allowing you to show scope & multimeter channels in one display
<azonenberg>
Correct
<azonenberg>
well within a single WaveformGroup there's a fixed time scale
<azonenberg>
But you could have, say, a multimeter measurement at 2 Hz spanning a minute
<azonenberg>
with a scope waveform in the middle of it
<azonenberg>
(this would take some thinking to do right - what happens if the scope triggered mutliple times in that minute?)
<electronic_eel>
how would you align / sync the scope and multimeter measurements?
<electronic_eel>
i mean on the time scale
<azonenberg>
so every waveform has an absolute time stamp associated with it in the header already
<electronic_eel>
so the multimeter driver would be responsible to set some reasonable time stamp value then
<electronic_eel>
you probably wouldn't need picosecond precision there
<azonenberg>
more specifiacally, the trend filter
<azonenberg>
you'd give it a scalar value and an optional timestamp
<azonenberg>
i.e. you can provide the time the instrument said that scalar was sampled, if it tells you
<azonenberg>
if not it uses the clientside time() value
<electronic_eel>
minus some offset for readout/transmission maybe
<azonenberg>
and then inserts that value into the waveform
<azonenberg>
well my thought was, most of the time the sample rate is a few Hz and the latency is ms to us
<azonenberg>
so its not significant
<electronic_eel>
yes, exactly
<azonenberg>
if it is significant, the instrument probably gives you a time value you can deskew
<azonenberg>
or a sync pulse you can measure with another instrument
<azonenberg>
etc
<azonenberg>
Anyway, there's still lots of details to figure out
<azonenberg>
for example, all of our multi-instrument stuff to date has assumed a single, global trigger shared by all instruments
<azonenberg>
and nothing updating except when that happens
<azonenberg>
having scalars coming in from other stuff at irregular intervals raises the question of what happens in the filter graph when that update takes place
<azonenberg>
do we refresh the entire filter graph? everything in the downstream cone of that one scalar?
<azonenberg>
So this is going to take some time to figure out how to do right
<azonenberg>
but i think it needs to happen
<electronic_eel>
there is the trend filter on top of the scalar, it will continously "output" new values
<azonenberg>
yes, exactly. but how this impacts the overall filter graph is the challenge
<azonenberg>
obviously we want to refresh the trend filter every time a new scalar update comes in
<azonenberg>
but a lot of stuff in ngscopeclient is based on the idea of a new data available event
<azonenberg>
so we might need to restructure *that* code to have updates on subsets of the whole dataset
<azonenberg>
so you don't, say, rerun an expesnsive pcie protocol decode when your meter has a new voltage sample come in
<azonenberg>
and then things like the start/stop trigger button - do they interact with the meter trend too?