<xzcvczx>
azonenberg: it was just a cheap hantek 6022bl
<xzcvczx>
what am i getting when?
<xzcvczx>
much better, thank you
<azonenberg>
you said you'll get a better scope soon
<azonenberg>
i was wondering what you were planning to replace it with
<xzcvczx>
ah no idea yet, need ot figure that out
<azonenberg>
also if the hantek has any kind of PC interface we can make a scopehal driver for it
<xzcvczx>
its a usb scope
<xzcvczx>
it has no other interface
<azonenberg>
Perfect, so yeah it should be doable then. is the usb protocol documented / is there a documented API?
<azonenberg>
if you wanted to make a driver it should be straightforward. but you'd have to do most of the legwork as it's hard to write a driver for a scope you can't get your hands on
<xzcvczx>
yeah fair enough
<azonenberg>
we actually have a pending ticket for some other hantek scope i think
<azonenberg>
that has been gathering dust on github for over a year because none of the devs had one to test with :p
<xzcvczx>
yeah the 5024 i think it is
<xzcvczx>
i assume one of the devs has access to the salae logic/clone of?
<azonenberg>
Work has several saleae units
<azonenberg>
I just havent had time to touch them
<azonenberg>
the big challenge is that they need a firmware download to run
<azonenberg>
And we can't distribute their blob
<azonenberg>
so we either have to rely on you having their firmware some other way, like by installing their blob and we just grab the file off the filesystem
<xzcvczx>
can you download the oss one thats available?
<azonenberg>
or we can write a f/oss replacement for the blob which would involve reversing the pcb to figure out the pinout
<azonenberg>
For the pro i don't think one exists
<azonenberg>
for the basic fx2 based ones, i also have a super cheap clone
<xzcvczx>
oh probably not for the pro, but yeah for hte basic fx2
<azonenberg>
so it would likely be possible
<azonenberg>
that was the route i planned to use for the basic
<azonenberg>
fx2la i think it's called
<xzcvczx>
thats hte one
<azonenberg>
yeah there's a ticket for that and i have one of the cheap clones
<xzcvczx>
the 6022bl has both digital and analog
<xzcvczx>
it uses fx2la for digital
<azonenberg>
Just haven't had time. That's been the blocker for most of my work
<xzcvczx>
oh i missed that
<azonenberg>
Which is why i've been trying to recruit more devs :p
<azonenberg>
i now have something like five different instruments that i either bought or was given for the sole purpose of making scopehal drivers
<azonenberg>
and not enough time to do anything but the picoscope
<azonenberg>
and *that* i havent touched for a couple of weeks because i've been working on other stuff like the application core and protocol decodes lol
<xzcvczx>
well as i am sure you have seen the 6022bl output isn't great but it does the job for what i am using it for at least
<azonenberg>
Yeah
<xzcvczx>
lol i can reproducibly make glscopeclient bring this computer to its knees
<xzcvczx>
to the point i need to kill glscopeclient
<xzcvczx>
probably wouldn't be an issue on your beast though
<xzcvczx>
re the hantek 6022 though i think it might either need to be clean roomed from the gpl or re-reverse engineered from the original driver
<azonenberg>
if there's a sigrok driver easiest option would probably be for somebody to read that and write a protocol spec from it
<azonenberg>
then we can cleanroom implement it off that
<xzcvczx>
well i would consider that whole process cleanroom but okay
Degi_ has joined #scopehal
<azonenberg>
yeah that would be
Degi has quit [Ping timeout: 240 seconds]
Degi_ is now known as Degi
<xzcvczx>
it would be nice if those who did gpl drivers for stuff would release a protocol spec for others to implement
<xzcvczx>
hmmm there is a bit of information on the sigrok wiki
<xzcvczx>
how to set voltage range/set sampling rate/trigger/set number of channels
<azonenberg>
If it's on the wiki then that should be fair game for us to code off of
<xzcvczx>
yeah i think you would have a lot of trouble trying to plead copyright infringement for that
<xzcvczx>
otherwise i am sure everything in existance would be documented
<azonenberg>
Yeah lol
<xzcvczx>
hazaa glscopeclient should run 1billion% better now as i finally have opencl stuff
<xzcvczx>
there is fx2lafw for the scopes as well as LAs
<azonenberg>
ok hmmmm
<azonenberg>
So I know exactly what's causing the crash in #405
<azonenberg>
What I don't know is how to solve it
<azonenberg>
So the basic issue is, when an Oscilloscope object is destroyed, the destructor deletes the trigger object
<azonenberg>
When the trigger is deleted, it frees everything it has open references to
<azonenberg>
When it frees the last dangling reference to the channel you're triggering on, that channel tries to turn off
<azonenberg>
So it calls OscilloscopeChannel::Disable()
<azonenberg>
Which by this point is a pure virtual because you're in the Oscilloscope class destructor, and thus the vtable points to Oscilloscope
<azonenberg>
and there's no way to know what derived class you were any more
<azonenberg>
Ideally, the trigger would always be deleted prior to the Oscilloscope object being destroyed
<azonenberg>
and thus the references would be cleaned up and the trigger would be null by the time the destructor is hit
<azonenberg>
I can add some code to ScopeApp::ShutDownSession() to do exactly that
<azonenberg>
but this will not clean up state in headless apps using libscopehal
<azonenberg>
and thus they'll crash if they don't set the trigger to null prior to deleting a scope object or having it go out of scope
<azonenberg>
Which is not ideal
<azonenberg>
another option is to add a "don't free references" flag to the trigger object that i can set prior to deleting it in the destructor
<azonenberg>
ugly, but would work
<azonenberg>
and could lead to channels not being shut down properly when glscopeclient exits
<azonenberg>
this could then be combined with selecting a null trigger in ScopeApp::ShutDownSession
<azonenberg>
so that it only becomes a problem for headless code
<azonenberg>
monochroma, lain: thoughts?
<Bird|ghosted>
azonenberg: does anything guarantee that the channel would already be off by the time you hit that?
<azonenberg>
Bird|ghosted: No
<azonenberg>
in fact it's guaranteed to not be off
<azonenberg>
because the trigger maintains an open ref
<azonenberg>
and i only disable channels when refcount hits zero
<azonenberg>
the problem is by the time you are deleting the trigger the scope driver is already shut down
<azonenberg>
The short term workaround i have now is to add a detach function that never frees that last reference
<azonenberg>
the channel object gets deleted when the scope is destroyed so it doesnt leak memory
<azonenberg>
but the dangling reference prevents the channel from being shut down when glscopeclient exts
<azonenberg>
Not the worst problem
<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JOHl8
<_whitenotifier-3>
[scopehal] azonenberg 9c2e7d2 - Oscilloscope: don't try dereferencing trigger inputs in destructor as this can lead to a pure virtual function call. Fixes #405.
<_whitenotifier-3>
[scopehal] azonenberg closed issue #405: Crash with pure virtual called during destructor when oscilloscope object is destroyed - https://git.io/JOeZZ
<azonenberg>
woop, looks like we're goingto be getting some ARINC 429 test data shortly
<Bird|ghosted>
woot! :)
<azonenberg>
I already have some MIL-STD-1553 waveforms but have not had the time to actually write a decode
<azonenberg>
So if somebody wants to do that, let me know
<azonenberg>
Bird|ghosted: btw do you have any time to do some more work on build/infra stuff?
<Bird|ghosted>
things are kinda discombobulated here so no -- I have to figure out how to get a bit more focused here myself b/c I need to do taxes still
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JOHBf
<Degi>
"Oh neat, Intel has FPGAs with integrated ADCs and DACs" "Wait a second, why are almost all the quotes from weapons manufacturers?"
<Degi>
Though the 64 GS/s / 25 GHz BW ADCs sound pretty neat for oscilloscopes
<d1b2>
<theorbtwo> That is ... quite an adc.
<d1b2>
<theorbtwo> Random question, btw? Does glscopeclient do xy mode yet? Have been pondering making myself a nice curve tracer rig. Would also be potentially useful as a building block for things like constellation chart or Smith chart.
<miek>
azonenberg: for SetSampleRate, will it only ever be called with values from the GetSampleRates[Non]Interleaved lists? or does it need to handle any number?
<Degi>
Afaik it doesn't yet
<Degi>
(@theorbtwo)
<azonenberg>
miek: the GUI will only ever call it from that list
<azonenberg>
it should at least not choke given an illegal value
<azonenberg>
theorbtwo: no, there's no XY mode yet
<azonenberg>
the current rendering code for waveforms has a pretty hard dependency on the waveform being a function of the x axis value
<azonenberg>
i.e. you cannot have >1 y value per x axis point
<azonenberg>
So it's going to have to be special cased like eye patterns
<azonenberg>
The other thing is that X axis units are int64 and Y axis units are fp32
<azonenberg>
so you can't just draw volts on the x axis or you'll only have 1V resolution
<azonenberg>
these are both architectural decisions from the early days that may have to be revisited but it will be challenging
<azonenberg>
in particular the timebase being int64 is necessary to provide sufficient resolution to not have round-off errors at the end of a very long waveform
<azonenberg>
where even fp64 might start running into epsilon problems
<azonenberg>
So i might have to have some kind of alternate code path for xy/constellation where we have increased dynamic range at the cost of not being able to scroll super far
<miek>
this scope is such a pain to configure with sample rate/depth
<azonenberg>
yeah for a lot of stuff i find myself having to calculate samples/div and scaling etc
<azonenberg>
But sample rate/depth is just so much more of a useful interface for something like glscopeclient where you can zoom freely
<miek>
part of the problem here is that they're too closely related, you can't set one without affecting the other as they both change with the timebase setting
<azonenberg>
Yeah
<azonenberg>
With lecroy, at least, you have the ability to set either "fixed sample rate" or "fixed memory depth" mode
<azonenberg>
and have the other change when you adjust time/div
<azonenberg>
So you can set one directly and have to calculate the other and convert to time/div
<miek>
it might make sense to merge it into one api call that sets both rate/depth?
<azonenberg>
if you have to do that internally, do it. but at the user facing level i want them separate
<azonenberg>
i.e. you might have to fetch the current rate from a variable in the cache then set it and the depth at the same time
<azonenberg>
or at least set depth with knowledge of the rate
<GenTooMan>
azonenberg, silly question what happens if the device returns 2 lines from an SCPI command? the reply string is then just the first line correct?
<azonenberg>
GenTooMan: by default ReadReply() terminates on either a \n or a semicolon
<azonenberg>
f you expect a second line, you have to call it again
<azonenberg>
ReadRawData() is used to read non-ascii data like waveforms
<azonenberg>
I believe there's also a helper function that reads a SCPI formatted blob with #9000000001<raw data> formatted binary data
<GenTooMan>
I'm trying to figure out what to do with this response from the scope Siglent Technologies,SDS1104X-E,SDSMMEBD3R7102,8.1.6.1.33\n,IDN-SGLT-PRI SDS1000X-E
<azonenberg>
I'd call ReadReply() a second time to eat that response
<azonenberg>
but only if you see a 1000X-E part number in the first *IDN? reply
<azonenberg>
incidentally, SCPIOscilloscope's constructor will already send *IDN? and then call Read Reply() expecting a single line
<azonenberg>
so in the siglent driver you could probably call ReadReply() without even sending anything to the scope
<azonenberg>
(again, only if the model number matches a 1000X-E series)
<azonenberg>
then ignore the return value as we already have the model number from the previous line
<GenTooMan>
perhaps the SCPI class needs a way to check if more data is available in the reply?
<GenTooMan>
then it would be easy to just do another read reply because "you know" there is more to read.
<azonenberg>
That's... not trivial
<azonenberg>
for starters, how do you know how long to wait for more data to show up?
<azonenberg>
consider the case of accessing the scope via rs232 or a laggy vpn connection
<azonenberg>
that second line might show up a significant time later
<azonenberg>
is there a \n after the second IDN line btw?
<azonenberg>
(If not, it gets even messier)
<GenTooMan>
A good question siglent allows you to issue commands directly to the instrument through a web interface, that's what I was getting in the web interface. The TCP connection would be a different matter likely.
<azonenberg>
Yeah I'd connect via netcat to 5025 and issue the commands directly (not the shell on 5024)
<azonenberg>
then use wireshark or something to look at the exact bytes coming back
<azonenberg>
These little details matter a lot
* GenTooMan
has wireshark setup because of his protocol habit, "Still in with drawl though", :D "putty with logging enabled perhaps?"
<GenTooMan>
looks like that is just extra stuff dumped into the local session from the web interface
<GenTooMan>
so I suppose "don't bother" is a better answer.
<azonenberg>
Lol oh
<azonenberg>
that makes it easier
<GenTooMan>
yes and no yes it's easier for the software end of things, but no it's harder because that means one can't use the web interface for "real" results
<azonenberg>
Yeah i always use netcat to see what the scope is really sending
<GenTooMan>
yeah wireshark seems to be what is left to use.
<GenTooMan>
I wonder if I should send a few bug reports into siglent, One bug is sending "DI:SW ON" behaves differently than pressing the digital button when it's not lit, and shows the digital menu (but disabled) instead.
<azonenberg>
If you want to collect a bunch of them, we've got contacts we can send them to all at once
<azonenberg>
me and mubes have been in pretty regular contact w/ a couple of siglent people
<GenTooMan>
that's cool, generally people want their stuff to work right, so I can see that happening.
<azonenberg>
also either you or mubes had an undocumented command related to DI:SW that worked on a family it wasn't supposed to? I'd like to get that documented (or an explanation of why it's not supported, maybe it's buggy or something)
<azonenberg>
So yeah make a list of all of those issues and i can collect them and send 'em along
<azonenberg>
also i wanted to get them to support *OPT?
<GenTooMan>
hmm if I gave you the method I found for detecting the digital interface is enabled or plugged in would that help? It has side affects which I just described.
<azonenberg>
Make a list of everything you think is relevant and send it on to me. best email for this purpose is sales at antikernel.net
<GenTooMan>
sounds like a better plan than I had.
<azonenberg>
I'll combine with our other feedback and send it along
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JO7jb
<_whitenotifier-3>
[scopehal-apps] azonenberg 2cc76dd - WaveformArea: average color of protocol samples that overlap
<d1b2>
<mubes> Only skimmed this preceding messages but I find the easiest way to see what the scope will return is just to telnet xxxx 5025 and then cut/paste text into it. Biggest issue is there's no NAK response to commands :-(
<_whitenotifier-3>
[scopehal] azonenberg opened issue #429: CSV import: parse timestamps out of Digilent WaveForms CSV headers - https://git.io/JO5vz
<_whitenotifier-3>
[scopehal] azonenberg assigned issue #429: CSV import: parse timestamps out of Digilent WaveForms CSV headers - https://git.io/JO5vz
<_whitenotifier-3>
[scopehal] azonenberg labeled issue #429: CSV import: parse timestamps out of Digilent WaveForms CSV headers - https://git.io/JO5vz
<kc8apf>
Since it's been stuck in my brain for a day, here's a name suggestion: remoteoscope
* azonenberg
slaps people who forget that time zones are a thing
<azonenberg>
PDT vs PST are different but well defined zones
<xzcvczx>
true, but when to use them is a pita
<azonenberg>
with known UTC offsets
<azonenberg>
Yeah thats a different story
<azonenberg>
but for example, that CSV I'm trying to parse has a timestamp to nanosecond resolution
<xzcvczx>
i also find it funny how many mcus just ignore the 100/400 leap year rules
<azonenberg>
but it could represent one of 24+ possible actual points in time
<azonenberg>
(since there's at least one 30 minute time zone and i think one is on a 15)
<xzcvczx>
damn australia
<xzcvczx>
(aussie has a 15)
<azonenberg>
The one I hate most is LeCroy's waveform header
<azonenberg>
which specifies time in nanoseconds since midnight of January 1 2000
<azonenberg>
... in instrument local time with no DST offset
<azonenberg>
since there's no scpi command to query instrument time i have to assume the scope is in the same time zone as the glscopeclient session
<azonenberg>
then i have to shift the epoch by an hour if the glscopeclient session is in DST because the scope doesn't handle that
<azonenberg>
at least "no time zone offset specified" isn't quite THAT broken
<xzcvczx>
haha and what happens at 3am on the shift back date?
<azonenberg>
I dont want to know, lol
<azonenberg>
but for example right now, my scope reports timestamps since midnight jan 1 2000 - pacific *daylight* time
<xzcvczx>
lol
<azonenberg>
yes, a time in january using daylight time
<azonenberg>
because it's currently DST and it doesn't understand that january was not
<xzcvczx>
course it was
<xzcvczx>
every civilised nation has summer in january
<azonenberg>
lol
<azonenberg>
Considering lecroy is headquartered in new york, i doubt that was their thought process
<azonenberg>
Anyway, compared to that idiocy a timestamp that simply doesn't specify the time zone is slightly less braindead
<xzcvczx>
dangit stop bring logic into this
<Bird|ghosted>
xzcvczx, yeah, you'd think having 2 century bits on your RTC wouldn't cost *that* much more
<xzcvczx>
ikr
<xzcvczx>
i am sure there will be a number of electronic devices still in use in 400 years
<xzcvczx>
(from today)
<d1b2>
<zyp> but how much engineering effort is it really worth spending on exceptions that only occur once every 100 years? considering the last one was in 1900 and the next one is in 2100 we're in the middle of a 200 year period where it won't be an issue
<xzcvczx>
but banks, and the military will still be using stuff from today in 2100
<GenTooMan>
This reminds me of my medical compliant device that now says it's dec 31 2020, 23:59:59 because the mentally challenged programmer thought "no one would use it more than 10 years"
<d1b2>
<zyp> the 2038 problem is probably gonna have a lot more impact
<GenTooMan>
yeah that is going to be a problem of sort using a signed int like that.
<azonenberg>
Yeah 2038 is going to be fun
<xzcvczx>
then again the idea of 1970 being the origin as a great idea.....
<azonenberg>
i expect there's a good chance lots of 32-bit stuff will still be in use
<xzcvczx>
origin/epoch
<azonenberg>
Off the top of my head i know of different computer system formats with epochs of 1900 (struct tm), 1970 (unix time), 2000 (lecroy and likely others)
<d1b2>
<mubes> I doubt 2038 will be that much of an issue. Linux fixed it a while back and it'll be totally pervasive for embedded systems by then. Of course it's not the only game in town but we certainly grabbed that nettle earlier than Y2K!
<azonenberg>
Don't some filesystems like... ext2? still use 32 bit timestamps?
<xzcvczx>
azonenberg: i know one which is 1996 :)
<d1b2>
<zyp> I think 2000 is fairly common, I've also encountered it a couple of times
<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JO5Uh
<_whitenotifier-3>
[scopehal] azonenberg closed issue #429: CSV import: parse timestamps out of Digilent WaveForms CSV headers - https://git.io/JO5vz
Tost has joined #scopehal
<GenTooMan>
I normally follow an ISO time number so I use full century I have no idea why people make assumptions to save "hardware" when the majority of programmers waste 10x the hardware with lazy software design.
* xzcvczx
glares at americans for thinking mm/dd/yyyy is a thing
<Degi>
Re XY view: But y isn't necessarily fp32, right? Like you can have y be a protocol decode etc.
<Degi>
For XY you could have y be an int, though yes the no two y values for one x value might be a problem
<azonenberg>
Well there's a bunch of problems
<azonenberg>
xzcvczx: I use yyyy-mm-dd and 24-hour time and i'm from the US so...
<azonenberg>
Degi: as of right now, Y is always fp32 on any analog waveform
<xzcvczx>
you are one of the good ones then
<Degi>
Hmm oh
<azonenberg>
Digital waveforms are boolean obviously, and "complex" data like protocol decodes are fixed height with no Y coordinates per se
<azonenberg>
just color and text fields
<Degi>
How are eye diagrams handled, like its a special renderer, right?
<azonenberg>
Yeah it's software integrated to a 2D fp32 texture
<azonenberg>
then a shader just splats that into the viewport and applies the color ramp
<GenTooMan>
xzcvczx, their is no "good" or "bad" there is however "trying to make things clear" people who don't bother to make things clear are busily doing what they aren't supposed to be doing (aka being lazy)
<azonenberg>
anyway, then X being int is problematic because right now we have units for volts and femtoseconds among others
<Degi>
Couldn't that be done for xy? Like you have two inputs and then make an output like that and a shader renders it based on the x,y data and previous frame
<azonenberg>
int femtoseconds is fine (we had to switch from ps due to lack of resolution at 10+ Gbps data rates)
<azonenberg>
but int volts is a no-no
<Degi>
Hm why though?
<azonenberg>
And yes, a completely separate renderer is totally possible
<azonenberg>
That may be the cleanest route
<Degi>
Like ADCs to have discrete output levels...
<Degi>
Yes
<azonenberg>
why are Xs ints or why are Ys floats?
<Degi>
Why are Y floats
<azonenberg>
because volts are a natural unit to work with, they're directly comparable across instruments
<azonenberg>
they have more dynamic range for things like math processing and FFTs
<Degi>
Hmm yes, but you could also have ints in femtovolts
<Degi>
But yeah floats do make sense...
<azonenberg>
Yes, converting to integer fractions is a possibility but now you're doing fixed point math all over the place which GPUs are not good at
<Degi>
Oh really?
<azonenberg>
GPUs and AVX are all built around floating point
<Degi>
Huh, good to know
<azonenberg>
they have a lot less integer units
<xzcvczx>
azonenberg: maybe you should be using avx-512 instructions i hear intel cpus are great at those
<azonenberg>
As of now I make reasonably heavy use of AVX2
<Degi>
I think for XY a custom renderer would be ideal, then you can do time dependent fading etc. and can use pixels for X and Y unit (or yes voltage, maybe the x axis needs a unit field heh)
<azonenberg>
X has a unit field
<Degi>
Oh good
<azonenberg>
it's just that some units don't make sense because of the integer resolution
<Degi>
Hm yes, if you want XY display in log mode that'd be a bit of a problem
<azonenberg>
at least with the current renderer
<azonenberg>
I think a separate renderer is going to be needed
<azonenberg>
the current one really relies on monotonic sorting of samples with increasing X coordinates
<Degi>
Hm yeah
<azonenberg>
and does things like storing min/max y values for the line if you have a vertical segment
<azonenberg>
We have multiple rendering paths already
<azonenberg>
one more isnt the end of the world
<Degi>
Couldn't something like the eye diagram renderer be done?
<azonenberg>
Yes, although i'd prefer to GPU accelerate the whole thing
<azonenberg>
the eye is in software because it's inherently pretty serial
<Degi>
Yeah, GPU renderer would be good, especially for fading etc.
<Degi>
I think it should be pretty doable as a GPU renderer, like the X, Y data taken from two traces can be used as vertex points for a line and then a wireframe renderer on that
<xzcvczx>
azonenberg: are there any thoughts as to using newer opengl versions/features currently or are you pretty satisfied with just what you use now?
<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JO5Ii
<_whitenotifier-3>
[scopehal] azonenberg 3817297 - Fixed typo and accidentally disabled optimization from previous testing
<azonenberg>
xzcvczx: I'm trying hard not to depend on anything newer than GL 4.2 + compute shaders for the widest support of platforms
<azonenberg>
adding new optional stuff is a lot of work
<azonenberg>
direct state access would be nice but not a huge deal
<azonenberg>
really, a lot of the more fun rendering is done in compute shaders anyway
<azonenberg>
There's almost no actual GL triangle geometry
<xzcvczx>
cool :)
<azonenberg>
most of the viewports are just two textured triangles
<azonenberg>
with a couple of passes using different textures created via a mix of Cairo and compute shaders
<azonenberg>
way back, waveforms actually used GL_LINES, then i switched to tesselated triangles
<azonenberg>
both had problems
<azonenberg>
so now it's actually software rasterized on the GPU, one thread per X coordinate
<xzcvczx>
is ther ecurrently a way to change the coloUr of the waveforms?
<azonenberg>
Yeah. Just double click the channel infobox at the bottom left of the plot and pick a new color
<azonenberg>
It defaults to the vendor's color scheme for real scopes and for CSV it uses some generic color
<Degi>
Btw it is very nice that this software has a PDF documentation (really, any in-depth documentation at all *eyes OpenEMS*)
<azonenberg>
Yeah I need to improve that and actually host it somewhere more official
<azonenberg>
not my "temp" directory :p
<xzcvczx>
dangit i am sure i tried that yesterday and it didn't do naything
<Degi>
Hm, could you just put the last build into the git repository in the folder where it is usually built?
<Degi>
(If the user recompiles then it'll get updated too)
<azonenberg>
I don't like committing generated files
<Degi>
Yes, I thought that was the reason...
<azonenberg>
also the manual is decently large and would bloat the repo severely
<Degi>
Oh
<azonenberg>
1.5 MB right now
<azonenberg>
and as we add more screenshots of decodes etc it's only going to grow
<Degi>
Very nice that you actually care about storage usage
<xzcvczx>
azonenberg: btw something which sorta irks me..... when your time scale is in for eg ms, 0 still shows as femtoseconds
<azonenberg>
Yes. That's a low priority thing i'd like to fix one day
<azonenberg>
what's happening is that it calls Unit::PrettyPrint() passing the number
<azonenberg>
and there's no way to specify the overall range of numbers being printed along with it
<xzcvczx>
ah ok
<azonenberg>
So if it sees something <1ps it displays in fs resolution
<azonenberg>
if <1ns it uses ps resolution
<azonenberg>
etc
<azonenberg>
you'll see the same thing with e.g. 990 ns -> 1 us
<xzcvczx>
ah ok
<azonenberg>
Longer term I plan to make PrettyPrint() take an optional second argument for "full scale range"
<azonenberg>
and it will try to use consistent units for everything up to that
<xzcvczx>
azonenberg: also would it not make sense to make the initial view the whole loaded waveform when loaded with a waveform?
<azonenberg>
Yeah i will probably set up autoscaling at some point. it's been one of those low priority things that i never bothered to code up because i had too much else on my plate
<azonenberg>
This is what happens when i'm really the only front-end developer :p
<xzcvczx>
fair enoguh
<azonenberg>
We've got a bunch of folks like miek and mubes contributing on the driver and decode side but since katharina went dark i've been the only one doing anything on the gui at all
<azonenberg>
although i actually just talked to her the other day and she sounds interested in coming back
<xzcvczx>
it may not help the number of people who are both opengl exeperienced and tool experienced as opposed to games is proabbly quite limited
<azonenberg>
Well a fair bit of the frontend code doesn't actually involve messing with GL
<azonenberg>
there's lots of stuff to do around dialogs, menus, and other things which are just generic GTK
<azonenberg>
waveform rendering itself is a comparatively small portion of the overall codebase
<xzcvczx>
oh my bad
<azonenberg>
So, hard numbers: the entire project is 107,639 lines including whitespace and comments
<azonenberg>
Of that, 34,278 is libscopehal (instrument drivers, transports, and base classes for decodes, but no actual protocol processing)
Tost has quit [Ping timeout: 265 seconds]
<azonenberg>
44,958 is libscopeprotocols (all of the decodes, math functions, etc)
<azonenberg>
and 22,897 is glscopeclient itself. The remainder is miscellaneous support libraries, example apps, unit tests, etc
<azonenberg>
Of that 22,897, total lines 2,117 is in WaveformArea_cairo.cpp and WaveformArea_rendering.cpp, plus another 504 in shaders
<xzcvczx>
oh wow, very very few
<azonenberg>
then there's a few dozen lines in WaveformArea.cpp that do some setup
<azonenberg>
and then there's a few more classes that do support stuff that's GL related
<azonenberg>
e.g. providing a C++ OO wrapper around a GL texture object
<azonenberg>
but that's pretty core code that doesn't change much if ever
<azonenberg>
the actual rendering is not very large at ll
<azonenberg>
It's among the more heavily optimized code in the whole project, but it's not a ton of lines
<azonenberg>
So there's a ton of room for contributions elsewhere in all of the dialogs, menu/mouse/keyboard event handling, etc
<xzcvczx>
like middle click and drag in the wave form area for those without a horizontal scroll :P
Tost has joined #scopehal
<Degi>
Isn't that usually shift + scroll?
<xzcvczx>
yeah but single hand is nice
<azonenberg>
yeah shift-scroll works now
<xzcvczx>
anyone know a better use for middle click+drag?
<xzcvczx>
oh weird it already does it
<xzcvczx>
nvm then
<xzcvczx>
for some reason i didn't think it did on my actual mouse
<xzcvczx>
but now i am using a the lenovo touchpoint thing
<GenTooMan>
It seems like it would be a good idea to collect response messages from SCPI scopes for "*IDN?" The great thing about this strings is the (it is assumed) they identify the model of the scope fairly clearly.
<xzcvczx>
GenTooMan: lol, fun story, i know of a few products that are produced by a company who have their own usb vid but they use the usb serial number to differentiate the different models
<xzcvczx>
(unrelated to scops but good for a laugh)
<azonenberg>
I worked on a silicon project once where the company was too cheap to go to jedec to buy their own vendor ID
<azonenberg>
since the jtag interface was for factory test only and not pinned out anywhere customer facing
<azonenberg>
So they squatted a defunct company's ID
<azonenberg>
somehow a full leading-edge tapeout was within budget but a couple hundred bucks to jedec was not :p
<Degi>
Lmao
<Degi>
Does JTAG have an ID similar to USB?
<xzcvczx>
pfffft nothing wrong with squatting on a dead company
<azonenberg>
Degi: the IDCODE instruction has a unique ID output
<azonenberg>
including both a vendor ID and a part number
<xzcvczx>
vendor id size?
<azonenberg>
its not huge, i forget - 12 bits or something like that
<Degi>
Lol thats worse than USB
<Degi>
Whats up with "consortiums" cheaping out on bist
<Degi>
*bits
<azonenberg>
look up JEP106 if you want to see some fun
<azonenberg>
they have some crazy "next page" ID schemes
<Degi>
Like why not make the USB IDs 128 bits while you're at it
<xzcvczx>
better hope that custom jtag on fpgas doesn't become a thing otherwise 12-bits may prove to be rather insufficient
<Degi>
Multipage ID scheme?
<azonenberg>
most FPGAs have custom instructions
<azonenberg>
that go to fabric
<azonenberg>
but you're still using the vendor TAP with the same idcode
<xzcvczx>
but you could implement a jtag in fpga for a softcore or something
<azonenberg>
yes you couldi
<azonenberg>
i've done it
<Degi>
So 10/16 JTAG banks are already almost full?
<azonenberg>
Sounds about right
<azonenberg>
And i made an interface-compatible softcore implementation of the xc2c32a CPLD
<Degi>
Why is it always shit like this aah
<azonenberg>
It runs on a bigger xilinx fpga and runs unmodified coolrunner-2 bitstreams
<Degi>
Its not like 64 bits of storage cells cost big money...
<azonenberg>
and can be programmed with the xilinx jtag dongle
<Degi>
Nice xD
<xzcvczx>
azonenberg: coolrunner-2 bitstreams? does that mean it crashes near the bottom?
<azonenberg>
lol no
<azonenberg>
Degi: that was the final step in my reversing of the xc2c32a
<Degi>
Did you reverse engineer the bitstream format for that?
<Degi>
Nice :D
<azonenberg>
a full reimplementation of the chip
<azonenberg>
that ran their bitstreams with identical behavior
<azonenberg>
to prove that i actually understood it fully
<Degi>
Huh neat
<azonenberg>
and yeah i did a REcon talk on it in 2015
<azonenberg>
this was a while ago ;p
<xzcvczx>
reimplementation is fun
<azonenberg>
i mean the new version was massive
<azonenberg>
but i was trying to be architecturally similar to the real CPLD
<azonenberg>
if i wanted to be efficient i'd have made something that JIT compiled the AND/OR array configs into LUT equations
<azonenberg>
(Which I seriously considered just for the lulz)
Tost has joined #scopehal
<xzcvczx>
i am rather surprised that more micros dont have some sort of programmable io yet
<Degi>
Yeah like FPGAs have such an array of IO features on each pin like damn
<azonenberg>
Yeah i think we will start seeing more of that
<Degi>
For example the ECP5 can use most IO pairs as analog comparators
<Degi>
(Well, its called LVDS, but it is an analog comparator really)
<azonenberg>
GenTooMan: back to your original comment yes, it would be nice to have a database of IDN values
<azonenberg>
Degi: yeah you heard about TRAGICLASER right?
<Degi>
Hm, not yet I think
<azonenberg>
It w as a couple years ago
<azonenberg>
i built a 100baseTX PHY out of a spartan6 and a couple of resistors
<Degi>
Nice xD
<azonenberg>
on the TX side I implemented the 3-level analog modulation by using a pair of push-pull FPGA outputs as an H-bridge to drive +1 or -1V, with resistors across the line to control swing
<azonenberg>
and a second set for pre-emphasis (yes, i had variable drive lol)
<xzcvczx>
with how overkill you normally are i would more expect a 1000000000BaseTx out of you azonenberg
<Degi>
I once made a delta sigma ADC (and DAC) with that a few months ago, but only 100 or 200 MHz clock, though 1600 MHz should be possible on the ordinary diff pair IO
<azonenberg>
on the RX side, i used a resistor ladder and two LVDS inputs to produce a 500 Msps 1.5 bit flash ADC
<Degi>
Hm
<azonenberg>
which i used to oversample the 125 Mbaud serial data stream and recover a clock from it
<azonenberg>
as well as distinguishing the -1, 0, and +1 states
<Degi>
The 381 ECP5 package has like uhh I think at least 70 actual diff pairs, could make a neat flash ADC
<Degi>
(Actually a HMCAD1511 would have better performance and be cheaper)
<azonenberg>
well yeah it wasnt meant to be practical
<azonenberg>
it was me trying to one-up cnlohr bitbanging 10baset on an attiny
<azonenberg>
i had never seen anyone bitbang 100mbit
Tost has quit [Ping timeout: 252 seconds]
<Degi>
Hmm why not, for 1.5 bits it should be plenty
<Degi>
(as in it doesnt require any external ICs)
<azonenberg>
and well the main problem was fixed thresholding
<azonenberg>
so it didnt handle weak signals or baseline wander well
<Degi>
Oh, does it need to be variable?
<Degi>
Hmm
<azonenberg>
i doubt it would have worked over a 100m long cable
<azonenberg>
too much attenuation
<azonenberg>
but the TX appeared to meet the full IEEE eye mask
<Degi>
Yeah... I guess you could put the thresholds relatively close and with an OP amp remove the DC component with a resistor divider or so
<Degi>
neat
<azonenberg>
i cheated re DC bias
<azonenberg>
i used a resistor ladder to bias the center tap of the transformer to vdd/2
<azonenberg>
on the rx pair
<Degi>
Yeah lol
<azonenberg>
then i just set thresholds slightly above and below and looked at one half
<Degi>
How was the ESD performance? xD
<azonenberg>
with the other leg terminated
<azonenberg>
i'm sure it was atrocious, this was for a poc||gtfo article
<azonenberg>
not a serious use case
<azonenberg>
Ok hmmmm this is interesting
<xzcvczx>
was it in one of the published books?
<Degi>
Somebody should make HVDS from an IGBT H bridge feeding into a 1 ohm coax
<azonenberg>
xzcvczx: poc||gtfo 17:05 iirc
<azonenberg>
not sure if that's made it to hardcopy or if it's too new
<azonenberg>
probably has
<azonenberg>
Also on topic... i almost have multiple CSV import working
<azonenberg>
but for some reason the second one is showing up as blank so i'm investigating still
* xzcvczx
gives azonenberg a cookie
<xzcvczx>
well half a cookie
* azonenberg
blocks it because it's a third party cookie
<xzcvczx>
lol
<Degi>
Third party biscuits
<xzcvczx>
omg azonenberg is a FLoC fan
<azonenberg>
Hmmmm
<azonenberg>
So it seems the other waveform is *not* blank
<azonenberg>
it just has a huge timebase offset
<azonenberg>
I'm not sure what to think of that
<azonenberg>
I don't like the idea of throwing away timebase info from the original CSV
<azonenberg>
but i also dont ilke the idea of waveforms showing up hundreds of us offset from other ones
<Degi>
Have an option!
<_whitenotifier-3>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JO5Gp
<_whitenotifier-3>
[scopehal] azonenberg 4963db8 - MockOscilloscope: when importing CSVs with column headers, don't add a newline to the end of the last channel's name
<_whitenotifier-3>
[scopehal] azonenberg 474ad03 - MockOscilloscope: discard offsets of imported CSVs so they all start at time zero (might change this later)
<_whitenotifier-3>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±6] https://git.io/JO5Zf
<_whitenotifier-3>
[scopehal-apps] azonenberg 4f931ac - Allow multiple CSV files to be imported into a single session. Fixes #313.
<_whitenotifier-3>
[scopehal-apps] azonenberg closed issue #313: Allow importing of multiple CSV files into a session, or adding CSVs to an existing session - https://git.io/JOsM8
<azonenberg>
yeah i will probably make that configurable longer term
<azonenberg>
right now i just need to get data into glscopeclient so i can start work on the MIL-STD-1553 decoder
Tost has joined #scopehal
<d1b2>
<theorbtwo> Huh. Planes and spaceships. Sounds like fun times.
<Bird|ghosted>
I wonder what databusses military ground vehicles use?
<Bird|ghosted>
1553? CAN, much like civilian vehicles? something else?
<azonenberg>
Good question
<azonenberg>
incidentally i will be doing an ARINC 429 decode soon too
<azonenberg>
somebody has promised me some waveform captures
<azonenberg>
just waiting for them to arrive
<d1b2>
<GenTooMan> @mubes regarding the state of the siglent driver, I have "written some code" I'm going to test, but let me know what you may have done with the SiglentSCPIOscilloscope module so I don't make a mess.
<d1b2>
<mubes> If you're digging into this family I might be able to get hold of some Spacewire traces...let me know if that's handy
<d1b2>
<mubes> @GenTooMan the Siglent driver is 'as submitted' for now. Probably won't get back to it until later this week. How different does it end up being?
<azonenberg>
mubes: There is an open ticket for spacewire debug
<azonenberg>
decode*
<azonenberg>
If you have any traces to share that I can test on, send 'em my way or better yet attach them to the ticket in scopehal format
<azonenberg>
I don't know if the spacewire spec is public, that might be the hardest part
<azonenberg>
we might have to find somebody with a copy of it
<d1b2>
<mubes> If it's hugely different then it will probably be best to keep it separate and we'll just instantiate the correct class from a wrapper that picks up the IDN, if it's only slightly different then I guess we could accommodate that in the same object....but that probably introduces fragility.
<d1b2>
<mubes> @azonenberg I'll ask around...
<azonenberg>
yeah feature flags within the same driver class is usually how i've done it in the past
<azonenberg>
for e.g. different lecroy models with different features
<d1b2>
<mubes> If it's a closed spec that'll be a problem to implement on an open platform, but if it's just that you need to spend money to get it that can probably be dealt with.
<azonenberg>
Yeah
<Bird|ghosted>
I'm pretty sure SW is a non-proprietary thing
<d1b2>
<mubes> I think it might be best to not worry about keeping comparability with the 2000x+ for now and then let's see how different it ends up being
<azonenberg>
I would much rather put in feature detect flags from the start
<azonenberg>
rather than trying to merge two different drivers
<Degi>
At least you can find a lot of pdf results when searching for "spacewire specification"
<azonenberg>
Bird|ghosted: yeah in most cases the specs are copyrighted and can't be reproduced wihtout buying a copy
<azonenberg>
but nothing stops you from using the content of the spec to write open code
<Degi>
There is even a version from 2013 on the ESA page spacewire.esa.int/WG/SpaceWire/SpW-WG-Mtg20-Proceedings/4Links-SpaceWire-Handbook-Draft-20130410.pdf
<d1b2>
<mubes> My worry is that it's not just feature differences but whole verb changes....that will get messy, unless the wavedesc and data are the same.
<azonenberg>
Well right now i've got my hands full with 1553 and some other stuff
<azonenberg>
But if somebody else wants to try writing a spacewire decode and mubes can find us some data, go for it
<d1b2>
<GenTooMan> @mubes In SiglentSCPIOscilloscope I rewrote certain sections namely enum Model SiglentSCPIOscilloscope::DisableChannelSiglentSCPIOscilloscope::EnableChannel SiglentSCPIOscilloscope::IsChannelEnabled SiglentSCPIOscilloscope::AddDigitalChannels SiglentSCPIOscilloscope::DetectOptions SiglentSCPIOscilloscope::IdentifyHardware
<d1b2>
<mubes> Discovery will take a while anyway.
<d1b2>
<mubes> @GenTooMan a fair few of those are minimal in 2000x+ at the moment anyway. I'd suggest you just modify as you see fit for now and then we can jointly work through a PR to decide the cleanest way to deal with it.
<azonenberg>
Yeah if the two of you can come up with a driver that works on 1000x-e and 2000x+ i don't really care who does what parts :) just make it work
<d1b2>
<mubes> Ditto! I ain't proud :-)
<d1b2>
<mubes> There's plenty more stuff to be done!
<d1b2>
<GenTooMan> I expanded the enum a bit so you have an idea of how many models have theoretically been add (in theory only reality is different as they say) enum Model { MODEL_SIGLENT_SDS2000XP, MODEL_SIGLENT_SDS5000X, MODEL_SIGLENT_SDS1000X, MODEL_SIGLENT_SDS2000X, MODEL_SIGLENT_SDS1000X_E, MODEL_SIGLENT_SDS2000X_E, MODEL_UNKNOWN }; I'm hoping to support the SDS1000X/SDS1000X+ the
<d1b2>
SDS1000X does not have the MSO the X_E has it as an optional part.
<azonenberg>
i doubt these have any kind of PC interface but... wow
<azonenberg>
that's more scopes than shahriar has :p
<miek>
alas, not one of them useful :p
<azonenberg>
lol
<GenTooMan>
those look like they were from a schools engineering lab
<azonenberg>
The AN/ prefix makes it pretty clear they're ex military
<azonenberg>
some quick googling suggests this was a custom build tek did for the us gov decades ago
<azonenberg>
they've probably been gathering dust in some warehouse for years and finally got disposed of
<GenTooMan>
Yeah... that does appear to be about 3 decade old stuff and the military needs test equipment like that so it makes sense.
<Degi>
Pretty sure they're analog xD
<azonenberg>
well duh
<azonenberg>
That's just the first time i've seen a literal pallet of oscilloscopes
<Degi>
I bet it'd be nice for some art installation
<monochroma>
at the e-waste recycler i used to go to, they used to have gaylords overflowing with classic HP/Tek 60s era tube scopes and other test equipment. and pallets of more modern test equipment
<GenTooMan>
up until the last 20 years most places weren't sure what to do with all that scrape now that E-waste places exist a lot of the junk sitting in the back of buildings is probably coming out.
<monochroma>
yeah, dda5005a is either windows 2000 or windows XP
<azonenberg>
This looks interesting. $2700 for 2 GHz 10 Gsps. but a bit light on details and i've seen stuff go a little cheaper if you wait long enough
<azonenberg>
The DDAs and SDAs are generally built on a wavepro or wavemaster chassis
<azonenberg>
possibly with some additional hardware, like the CDR trigger for the SDAs
<monochroma>
Degi: yeah the DDAs are just a wavepro with with HDD analysis software installed
<Degi>
Huh wow, a 6 GHz scope for 1125 $
<Degi>
Well, with only one working channel
<azonenberg>
My SDA816Zi is a wavemaster 8Zi chassis plus the serdes trigger board
<azonenberg>
and lol
<azonenberg>
yeah if you're willing to get stuff with dead channels you can probably get good deals too
<miek>
just a bit risky if you're wanting to fix those channels, there's not much simple stuff to go wrong
<Degi>
Ah, I think its a sampling scope, has 14 bits
<Degi>
There seems to be a certain era of scopes where BW equalled sample rate, probably because ADCs cost money back then
<monochroma>
lecroys are fairly modular though, the frontends, ADCs and memory storage buffer ASIC are individual parts, buuuuuut finding the correct replacements show up cheaply on ebay is difficult (and then getting them calibrated ....)
<monochroma>
lecroys use custom ASICs for most everything, custom frontend ASIC, custom ADC, custom SRAM
<Degi>
Lol, custom SRAM
<Degi>
At least TEK used some chips from IDT in the scope which I halfway fixed and then after a bit of storage it now refuses to boot up
<monochroma>
aww
<Degi>
(The one with the first gen SMD electrolytics and for some reason goddamn battery-backed SRAM with 5 years lifetime)
<Degi>
I think both are at fault in a way, though I cleaned the electrolyte pretty good I think
<Degi>
How bad on the list is "Missing HDD" and "Front bezel missing" that they still ask for 3000 $ shipping and about that much for the scope... O.o
<monochroma>
windows based lecroys you can actually get all the software for them from their website and do a fresh install of everything
<Degi>
Oh neat
<monochroma>
the touchscreen drivers are a little weird though
<monochroma>
there are some eevblog threads going over such things
Tost has quit [Ping timeout: 260 seconds]
<_whitenotifier-3>
[scopehal-docs] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JO5rF
<_whitenotifier-3>
[scopehal-docs] azonenberg d68e800 - Added doc skeleton for MIL-STD-1553
<_whitenotifier-3>
[scopehal] azonenberg pushed 1 commit to master [+2/-0/±3] https://git.io/JO5rA
<_whitenotifier-3>
[scopehal] azonenberg 8a2882e - Initial work on MIL-STD-1553 decode. Decodes command word only, can't do data. no protocol analyzer view. See #286.
* GenTooMan
wonders if LeCroy toys eMMC flash wears out like on older Tesla cars
<azonenberg>
I am not aware of any lecroy stuff with eMMC. maybe their really cheapest models? but i think those are microSD
<azonenberg>
the arm ones like the wavesurfer 3000 series
<azonenberg>
all of the x86 ones are IDE hard drives (older) or SATA SSDs (newer)
<azonenberg>
maybe NVMe on the latest ones
<GenTooMan>
so their older stuff is more durable huh.
<monochroma>
iirc they used Maxtor drives so... no >.>
<Degi>
Hmm
<Degi>
If you already pay 100 k for a scope it should have MRAM drives
<Degi>
Well, FRAm
<Degi>
MRAM has data retention problems... 3 months at 85 °C
<monochroma>
Degi: oh yeah? idk much about mrams, have a source for that? :o
<GenTooMan>
that is somewhat ironic. I switched from maxtor to seagate then to western digital. Thus far WD drives haven't failed like the former 2.
<Degi>
I think I never had a HDD > 1 TB fail (only one 200 GB HDD, some IC went up in smoke and a SSD) despite having two seagates (I think) with > 10 kHrs each
<GenTooMan>
FRAM is tricky stuff and has limited size.
<GenTooMan>
the biggest advantage it has is 1T write ratings. unfortunately that includes reads, because if you read FRAM you have to rewrite the device.
<GenTooMan>
Degi I had 2 "high end" seagates fail exactly the same 1.5T drives (biggest I could get at the time) I replaced them with 2T WD drives which, have never had a problem and they are now 4 times older.
<azonenberg>
Degi: I had a 1TB WD fail on me not too long ago
<azonenberg>
admittedly it had like six years on it
<azonenberg>
Everything i really care about now is on ceph so i've got N+2 redundancy and i'm a lot less worried
<Degi>
Yeah, mine have like that much too
<Degi>
This PC is from 2015 and the HDDs are older
<Degi>
I should probably do proper backups sometime, where I don't have to piece everything together from half-assedly copied files
<azonenberg>
Yeah i have two layers of protection now
<Degi>
Like the most important stuff is in the cloud or copied on multiple devices... Well, the cloud is under my bed lol
<azonenberg>
the main storage array is on ceph so I can lose two out of any three physical disks in the cluster storing replicas of the data without catastrophic failure
<azonenberg>
then on top of that, the more important stuff from that array is also backed up nightly off site
<GenTooMan>
hmm an NAS might be a more local and accessible method.
<azonenberg>
So far I'm a big fan of ceph because of both scalability and reliability. It seems like zfs done better
<azonenberg>
the one problem is it does use a fairly significant amount of ram on the nodes
<d1b2>
<mubes> After this weekend, my comfort in zfs is unbounded :-)
<azonenberg>
oh? saved you from a drive failure?
<azonenberg>
With ceph i've gone so far as to shut down one of the three nodes in the cluster, install more ram, then turn it back on. and it not only doesn't lose data, it maintains availability the whole time :D
<azonenberg>
it just has only two replicas instead of three, then recovers from the degraded state once the node comes back