_whitelogger_ has quit [Remote host closed the connection]
_whitelogger_ has joined #scopehal
_whitelogger_ has joined #scopehal
_whitelogger_ has quit [Remote host closed the connection]
_whitelogger has joined #scopehal
ericonr has quit [Ping timeout: 256 seconds]
ericonr has joined #scopehal
juli968 has joined #scopehal
bvernoux has joined #scopehal
<codysseus>
Is there a coding guidelines document anywhere?
<_whitenotifier-4>
[scopehal-apps] Codysseus forked the repository - https://git.io/JYUlj
<_whitenotifier-4>
[scopehal-apps] Codysseus opened pull request #310: Improve the usbcsv example - https://git.io/JYU0p
<codysseus>
Let me know what I can change. Hopefully others can use that example in a headless context.
<codysseus>
Also, you might find this interesting. The sigrok project already has a tool that extracts the firmware of Logic devices from Saleae's old software. Here's the link: https://sigrok.org/wiki/Saleae_Logic16#Firmware
<azonenberg>
Interesting. And yes, saleae support has been a to-do for a long time
<azonenberg>
I dont own one, we have them at work but none are at my house right now
<azonenberg>
So i'm not able to work on it
<codysseus>
I understand. I just thought I would contribute this for eventual support.
<codysseus>
How much work would it be to get support for a Saleae device? I am getting a bit tired of using their software.
<azonenberg>
Basically, we don't know as nobody's looked into it :)
<azonenberg>
at a high level the steps are:
<azonenberg>
1) Make/get a tool to obtain the firmware from Saleae's software (since they own the copyright and we can't redistribute it)
<azonenberg>
sounds like that's done
<azonenberg>
2) Reverse engineer the protocol used to communicate between the firmware and the software (not sure how far the Sigrok people got with that)
<azonenberg>
3) Write a libscopehal driver class (relatively easy once 1/2 are done)
<azonenberg>
as an alternative path, we can develop an open source firmware from scratch and sidestep their proprietary code entirely
<azonenberg>
this would be more work, but eliminate any dependency on their firmware and allow us to function without their software having ever been installed
<azonenberg>
so it's the superior long term route
<codysseus>
I see! Yes, Sigrok already has support for the Saleae Logic Pro 16, so adding that to scopehal would be easier (and it would help with the implementation of the Logic Pro 9)
<codysseus>
8*
<codysseus>
Open source firmware would certainly be a dream. I would work on it if this were my personal LA
<azonenberg>
Yeah i figured starting with support for the stock firmware would be a good start
<azonenberg>
especially if sigrok has done most of the legwork re the protocol
<azonenberg>
We just cant copy any of their code directly due to license incompatibilities (sigrok is GPL and libscopehal is BSD, so they can copy our code but not the other way around)
<codysseus>
Ah those copyleft folks
<azonenberg>
that was in fact one of the original reasons for building scopeclient (before the "GL" part was there) way back in the day
<codysseus>
Need certainly breeds innovation! Is GL from OpenGL?
<azonenberg>
Yeah
<azonenberg>
glscopeclient is a from scratch rewrite of all the ui code with shader based rendering instead of Cairo
<azonenberg>
libscopehal was pretty continuously developed over the whole course of the project
<azonenberg>
but the old scopeclient codebase died circa 2017?
<codysseus>
Huh, interesting. Sounds like a rocky development.
<azonenberg>
well, it was just getting too slow to software render everything
<azonenberg>
in the waaaay early days, scopeclient was the viewer for RED TIN, an FPGA based logic analyzer I built because ISE ChipScope wasn't a thing in the free version of Vivado
<azonenberg>
then i added support for my Rigol DS1102D
<azonenberg>
this must have been 2011-2012 ish?
<codysseus>
That's neat! That sort of history should be catalogued.
<azonenberg>
You can definitely see the lineage, but it's come a long way :p
<azonenberg>
i had no intensity grading or anything back then
<codysseus>
Oh wow yeah it's loads different.
<azonenberg>
i was looking for some older pics, like from the early days
<azonenberg>
this is when scopeclient was relatively mature, i.e. shortly before i decided it had gone far enough and killed it off :p
<azonenberg>
the shot there of the analog waveform was off my first lecroy scope
<azonenberg>
much of that backend code is still in use today, although tuned and optimized
<azonenberg>
The UI is almost unrecognizable though
<d1b2>
<thirtythreeforty> At a 10000 ft view, what are the differences between your driver object model and Sigrok's?
<d1b2>
<thirtythreeforty> Like, if I have a library that has a "get samples" function call, will that be equally easy to interface to both scopehal and sigrok?
<azonenberg>
So the main difference is that libscopehal's API and data structures are a lot more generic
<azonenberg>
e.g. I do not assume all channels have the same sample rate, or data type, or units
<azonenberg>
you can have one channel with 512 FFT bins and another that's an 1287x391 eye pattern and another that's a 1M sample analog waveform with sparse/irregular samples
<azonenberg>
on the same instrument
<d1b2>
<thirtythreeforty> Gotcha. That's powerful. When you say irregular samples - that was actually my next question. As a driver can I specify arbitrary time/value samples or do they still have to occur on a timebase?
<azonenberg>
A waveform consists of a vector of start times, a vector of durations, and a vector of sample data of arbitrary type
<azonenberg>
Start times and durations are measured in timebase ticks
<azonenberg>
the timebase is defined in the waveform header as an integer number of femtoseconds
<azonenberg>
all of these values are 64-bit integers
<d1b2>
<thirtythreeforty> I see. Is it optimized for having few vectors each consisting of many samples, or would many vectors of few/one sample perform equally well?
<azonenberg>
Samples must be in order from oldest to newest, and should not overlap, but gaps between them are acceptable and common
<azonenberg>
e.g. for protocol decodes
<azonenberg>
("byte of data in an ethernet frame" or "I2C start bit" are actual sample data elements in the current object model)
<azonenberg>
At any given time, each channel has zero or one waveform associated with it
* codysseus
needs to head off to lunch with the wife. Ttyl!
<azonenberg>
although the history database can store arbitrarily many past waveforms per channel up to the limits of RAM
<d1b2>
<thirtythreeforty> Ah gotcha. Then yeah multiple sample vectors would be super common. Background: my currently-hypothetical scope would have a variable capture time depending on input voltage
<azonenberg>
history is only stored for "physical" channels, i.e. those corresponding to actual instruments
<azonenberg>
filter graph output is recomputed lazily as you navigate the history
<azonenberg>
And so in your case what i would do is have the timebase unit be 1 fs
<azonenberg>
then report sample start/duration for each sample based on the actual sample rate
<azonenberg>
Since you can only render a single waveform at a time for a given channel
<azonenberg>
so if you have time varying sample rate, you probably want to see more than a few samples at once
<azonenberg>
generally speaking a waveform corresponds to all data captured from a single trigger event
<d1b2>
<thirtythreeforty> Exactly what I was thinking. (If this would make things choke, you could snap each fast-time sample into its slow-time bucket, but this would add noise to the signal)
<d1b2>
<thirtythreeforty> But if the framework can directly handle fast-time data, then that makes everything very nice 🙂
<azonenberg>
So there is a "dense packed" bit in the header of each waveform
<azonenberg>
If set, this means that all durations are exactly one timebase tick
<azonenberg>
and offsets are monotonic from zero to N
<azonenberg>
this allows various optimizations, e.g. a filter doesnt even have to look at the duration/offset values or copy them each trigger
<azonenberg>
it can focus entirely on the time domain samples
<azonenberg>
most data coming from typical oscilloscopes will be dense packed
<azonenberg>
and typically data coming from a filter or protocol decode will not be
<d1b2>
<thirtythreeforty> Most scopes have a sane architecture 😄
<azonenberg>
e.g. the "rise time" filter outputs one sample per cycle of the incoming waveform
<azonenberg>
But yes, the libscopehal API was intended to be flexible and handle weird instrument types
<azonenberg>
also X and Y axis can be in arbitrary units
<azonenberg>
The *default* unit is fs for X and V for Y
<azonenberg>
but you can change that
<azonenberg>
e.g. you could have Hz for X and dBm for Y in a spectrogram
<azonenberg>
i started out using ps for X but switched to fs to get better results with high speed serial data where quantization error became significant
<azonenberg>
at 10GbE it made a big difference
<azonenberg>
i'm seriously considering switching the frequency base unit from Hz to mHz or uHz
<azonenberg>
but havent decided
<azonenberg>
Longer term, I will also be adding support for "higher order" units derived from algebraic combinations of existing units
<azonenberg>
e.g. when I add the "differentiate" filter, applying it to a time domain waveform will produce Y axis units of V/fs
<azonenberg>
I have no way to represent this right now
<azonenberg>
I do however support SI prefixes on all units
<azonenberg>
Which takes a bit of special casing since some of my internal units are scaled rather than SI base units (fs is much more convenient than s for working with high speed stuff, since you can keep everything as integers)
<d1b2>
<thirtythreeforty> It's super cool that it follows the everything's-a-filter strategy
<azonenberg>
Unifying the model like that makes things a lot nicer on the back end
<d1b2>
<thirtythreeforty> "JACK for instruments"
<azonenberg>
I modeled it on VTK/ITK as that was the filter pipeline tool i had the most experience with
<azonenberg>
But yeah
<azonenberg>
also "everything is a channel". both filters and physical instrument channels support the same base API to get the vertical range, offset, etc
<azonenberg>
which makes rendering code nice
<azonenberg>
it doesnt care what's a filter and what's not
<azonenberg>
the one thing that does need a little special casing is channels marked as "overlays" meaning they're drawn on top of another channel rather than on their own
<azonenberg>
this is currently exclusive to filters but it's plausible one could make an instrument channel like that for some special reason?
<d1b2>
<thirtythreeforty> Maybe like Saleae does with the analog/digital samples of the same physical signal?
<azonenberg>
Yeah i guess. but realistically the way i'd normally do this is by recording the analog channel then applying a threshold filter to it in postprocessing
<d1b2>
<thirtythreeforty> But still, I don't see why you couldn't combine them at the rendering layer only
<azonenberg>
which is then rendered as an overlay
<azonenberg>
anyway you do pay a cost in RAM for the extra metadata but it's sooo much more flexible
<d1b2>
<thirtythreeforty> This isn't an Arduino, make it flexible 🙂
<azonenberg>
Yeah I have 192GB of ram on my main workstation
<azonenberg>
And i have run glscopeclient up to 70GB of RAM in the past
<d1b2>
<thirtythreeforty> Hmmm well I guess it should be usable on mortals' workstations 😉
<azonenberg>
I mean, it is. My current lab machine was high end in 2014 but is more middle-of-the-road now
<azonenberg>
quad core no HT i5-4590, quadro k5200, 32GB DDR3
<azonenberg>
and you can run glscopeclient in only a gig or so of ram, you just can't have history of dozens of 50M point waveforms
<d1b2>
<thirtythreeforty> Yeah, okay, that works then. Could you page the other waveforms to disk?
<azonenberg>
You mean the ones not actively being displayed?
<azonenberg>
that is a planned future enhancement
<azonenberg>
not sure if i filed a ticket but it's on my mental roadmap
<d1b2>
<thirtythreeforty> Yes. So the user is "working with them" but optimized for ram
<azonenberg>
right now you can set a history cap beyond which waveforms are deleted
<azonenberg>
but not one to page to disk
<azonenberg>
ideally you'd have two thresholds
<azonenberg>
if disk is >= deletion then everything lives in ram
<azonenberg>
if disk is < then older ones are swapped out to disk
<azonenberg>
let me actually check if such a ticket actually exists
<azonenberg>
and if not, file it
<_whitenotifier-4>
[scopehal-apps] azonenberg opened issue #311: Swap older history waveforms out to disk - https://git.io/JYTTU
<_whitenotifier-4>
[scopehal-apps] azonenberg labeled issue #311: Swap older history waveforms out to disk - https://git.io/JYTTU
<_whitenotifier-4>
[scopehal-apps] azonenberg labeled issue #311: Swap older history waveforms out to disk - https://git.io/JYTTU
<azonenberg>
Done
electronic_eel has quit [Remote host closed the connection]
electronic_eel has joined #scopehal
bvernoux has quit [Quit: Leaving]
<_whitenotifier-4>
[scopehal-apps] ChuckM forked the repository - https://git.io/JYTzK