<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JUNeb
<_whitenotifier-f>
[scopehal-apps] azonenberg d394650 - OscilloscopeWindow: make sure we have at least one scope before entering a polling loop so we have a way to exit. Fixes #214.
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #214: glscopeclient hangs during startup when opening nonexistent file - https://git.io/JUbgx
<azonenberg>
bluecmd[m]1: there's a fix for your hang from this morning
<azonenberg>
root cause: the event timer tries to poll for new waveforms, but if you abort early enough in the file load there aren't any scopes
<azonenberg>
the loop goes while(no waveforms) poll scopes
<azonenberg>
if no scopes to poll there's no way to exit
<Bird|otherbox>
azonenberg: that is bizarre, you'd think MELF would be less good at high freq (more inductive), never mind the old Many End up Lying on the Floor problem ;)
<azonenberg>
LOL i have not heard that one yet
<azonenberg>
also more capacitive from the giant end caps
<azonenberg>
yeah i'm not sure. i thought they'd be going the opposite with printed resistors right on the pcb or something
<Bird|otherbox>
I guess the reason they're still used has to do with reliability obscura with glass vs plastic packaging and some sort of ability for the leadcaps to absorb a bit of shock?
<Bird|otherbox>
(that and power density -- they're apparently somewhat more compact than rectangular SMT chips/diode packages of equivalent power rating)
maartenBE has quit [Ping timeout: 260 seconds]
maartenBE has joined #scopehal
<azonenberg>
Bird|otherbox: yeah not sure. i mean at low freq i wouldnt be concerned
<azonenberg>
but i'm surprised to see them used in RF
<azonenberg>
that said i dont know which specific probes use them
<azonenberg>
or if the advertising copy is out of date
<azonenberg>
Power density is incidentally a problem with my own probe
<_whitenotifier-f>
[scopehal-apps] azonenberg eb412fe - WaveformArea: disable stats checkbox for digital channels. Fixes #208.
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #208: Hide/gray out statistics item in context menu for digital channels - https://git.io/JUyQq
<Bird|otherbox>
and now that I have all that out of the way, giving the clang-analyzer a whirl although integrating that will be a greater challenge
<azonenberg>
Woo
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JUNt1
<_whitenotifier-f>
[scopehal] azonenberg 067057d - TektronixOscilloscope: cache RBW between queries
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JUNty
<_whitenotifier-f>
[scopehal-apps] azonenberg a9819f1 - WaveformArea: use channel's reported RBW for specans rather than just the FFT bin size. Fixes #201.
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #201: RBW display for Tek MSO5/6 spectrum channels is wrong - https://git.io/JUMeB
<Bird|otherbox>
and, lo and behold, the clang-analyzer is finding stuff!
Degi has quit [Ping timeout: 240 seconds]
Degi has joined #scopehal
<azonenberg>
Bird|otherbox: woo
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #199: NULL transport should not be displayed in startup dialog because a lot of drivers act weird with it - https://git.io/JUNqx
electronic_eel has quit [Ping timeout: 264 seconds]
electronic_eel_ has joined #scopehal
<Bird|otherbox>
azonenberg: 21 issues from clang-analyzer, most of them in protocol decoders -- although 4 of the 5 null dereferences it found are NOT in protocol decoders (2 in the IBIS parser, 2 in UI code)
<azonenberg>
Nice. send a PR for the analyzer integration when you've got it ready
<azonenberg>
then if you've got a chance go through the analyzer results and file bug reports for the ones you can confirm are legit?
<azonenberg>
I know i've crashed glscopeclient many times and not been able to reproduce the exact failure. so if we can pick up any of those with static analysis then great
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±6] https://git.io/JUNs2
<_whitenotifier-f>
[scopehal] azonenberg 6ed1a57 - Added Oscilloscope::CanEnableChannel() and implemented for Tek/LeCroy
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±4] https://git.io/JUNsQ
<_whitenotifier-f>
[scopehal-apps] azonenberg 2f62009 - Hide channels in "add" menu that aren't usable due to resource conflicts. Fixes #195.
<_whitenotifier-f>
[scopehal-apps] azonenberg 8bc8fef - FilterDialog/TriggerPropertiesDialog: hide channels from the list that can't be enabled
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #195: "Add" menu doesn't hide channels that are unusable due to resource conflicts - https://git.io/JUa5j
_whitelogger has joined #scopehal
Kenley has quit [Read error: Connection reset by peer]
Kliment has quit [*.net *.split]
Kliment has joined #scopehal
electronic_eel_ is now known as electronic_eel
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+2/-0/±6] https://git.io/JUNzs
<azonenberg>
four analog channels, configurable sample rate and memory depth. triggering isn't implemented for now
<azonenberg>
the test signals are a 1 GHz tone on channel 1
<azonenberg>
a mix of a 1 GHz tone and a 1.1-1.5 GHz ramp on channel 2
<azonenberg>
a 10.3125 Gbps PRBS-31 on channel 3
<azonenberg>
and a 1.25 Gbps 8b/10b stream on channel 4 (sending 1000base-X idles)
<azonenberg>
all signals have 10 mV of gaussian noise added to them, and the serial data is generated as an idealized squarewave with infinitely sharp edges then fed through a 5 GHz first order lowpass filter
<azonenberg>
this isn't the most realistic option but it means i don't have to tote around realistic channel S-parameters and an IBIS model to generate test data
<bluecmd[m]1>
That looks gorgeous! Thanks! Hopefully other people find it useful as well
<azonenberg>
So if you want to play around on various platforms you have available and see what works/doesn't work rendering wise etc, that will avoid any issues wrt hardware support
<bluecmd[m]1>
azonenberg: what time zone are you in btw? Seems like you had lunch in my evening so is probably quite late wherever you are
<azonenberg>
on your native linux box it should work fine, other than the known issue where the title bars on some of the pop-up windows are messed up on some window managers
<bluecmd[m]1>
Indeed, thanks!
<azonenberg>
I'm in the Seattle area so pacific time (UTC-7 right now)
<azonenberg>
it's just after midnight for me
<azonenberg>
you?
<bluecmd[m]1>
Ah reasonable
<bluecmd[m]1>
I'm in Zurich, so Central Europe (Summer) UTC+2
<bluecmd[m]1>
(We haven't switched yet right? Have to check)
<bluecmd[m]1>
Yeah, few weeks left on summer time it seems
<azonenberg>
yeah idk about you but the US is on summer time until early november iirc
<azonenberg>
We have a lot of western european folks here, i think at least one .nl and... three Germans at least?
<azonenberg>
then probably a dozen or so americans, a brit, and i have no idea where the rest of the folks are from
<azonenberg>
oh actually i think we've got two dutch folks here not one
<bluecmd[m]1>
Yeah, at work I routinely have meetings with the US and the DST switching is always a mess for the routine meetings. For a few weeks the "5PM" meetings are at "4PM" for us until the US also switches
<azonenberg>
Lol fun
<azonenberg>
The joys of global business
<azonenberg>
$dayjob for me is a consulting firm so i bounce from customer to customer every few weeks
<azonenberg>
very often the customer isn't in the US
<azonenberg>
while we're doing little if any onsite work due to the pandemic, i still have to routinely adapt my schedule to overseas clients
<azonenberg>
one time not too long ago i did a project for a customer in Japan
<azonenberg>
that was annoying :P all of the jet lag and none of the interesting snacks to take home lol
<bluecmd[m]1>
Haha yeah I can sympathize
<azonenberg>
meanwhile a few years ago i spoke at a conference in .nl and... while i didn't have to throw out any of the clothes i brought to make room for stroopwafels in my suitcase, it was close :p
<bluecmd[m]1>
Haha! I don't know if that's a US thing to be crazed about those
<bluecmd[m]1>
I seem to hear that from our US colleagues as well
<azonenberg>
well they're hard to find in general here
<azonenberg>
sadly, i didn't have the time to explore Den Haag too much. I took my laptop to a park, sat down, and either worked on my slides for the talk or studied
<azonenberg>
because like a week after the conference i had an advanced first aid training that was split into in an online and in person component, and i had been too busy with work to do the online part lol
<azonenberg>
bluecmd[m]1: So what's your interest in glscopeclient? i seem to recall you saying something about wanting to integrate with EDA tools for spice sims etc?
<azonenberg>
or did you want to use it with actual test equipment too?
<bluecmd[m]1>
So 80% curiosity right now. I have a PicoScope that I'd love to use glscopeclient for, but I don't use it that much so that's just an extra. The ngspice and generic waveform viewer is correct, but I'm mostly feeling the waters on that one
<azonenberg>
We do not currently have picoscope support but noopwafel is working on a bridge between their SDK and our API
<bluecmd[m]1>
Mostly I've seen your tweets on the development of it so I'd thought this would be a good time as any to check it out
<azonenberg>
no ETA, it sounds like it's not a huge priority for her
<bluecmd[m]1>
Yep, I've seen the GitHub issue
<azonenberg>
We're also working on test equipment hardware and accessories, like probes
<azonenberg>
That has been a big project of mine over the past couple of months
<azonenberg>
yet another piece in the open test equipment ecosystem
<azonenberg>
anyway users are welcome, as are developers/contributors/documentation writers
<azonenberg>
VCD file import shouldn't be too difficult for someone with C++ experience to add, if you wanted to try your hand at that?
<azonenberg>
essentially what you'd do is add a class to libscopehal for parsing a VCD file, add an import menu button to glscopeclient
<azonenberg>
load the VCD, create a MockOscilloscope object just like the native file load code does
<azonenberg>
then fill out channels and waveforms within it
<azonenberg>
and then create default views for each channel
<bluecmd[m]1>
Right, I don't think any of the formats (ngspice, vcd, fst) are hard as such - I'd be more worried about other things that are non-obvious that a waveform viewer would want to have, but a live oscilloscope viewer wouldn't.
<azonenberg>
I imagine the only way to discover those things is to implement it and see what you miss :p
<bluecmd[m]1>
Like, I'm a bit worried how the UI would be with 100s of digital channels
<azonenberg>
yes that's a known scaling concern. But it will have to be addressed for MAXWELL, the 96-channel logic analyzer i'm building
<bluecmd[m]1>
That's certainly one way :-)
<azonenberg>
We can probably add density settings to the UI to shrink margins etc and allow fitting more signals in the same number of pixels
<azonenberg>
Adding scrolling wouldn't be that difficult either
<azonenberg>
One thing that we do not currently support that would be good to have is breaking buses out into individual bits
<azonenberg>
there is a filter to take channels expressed as 1-bit in hardware and concatenate them into a bus, but i don't think there's any way to do the reverse, and certainly not a simple tree view expansion button
<azonenberg>
but again that's something i want for realtime stuff too
<azonenberg>
My gut feeling is that anything you will need for a waveform viewer would also be needed for realtime access to bazillions of channels
<azonenberg>
consider the case of an FPGA ILA. That's the exact same usage scenario as a simulator except it's also realtime and interactive
<bluecmd[m]1>
Right, you certainly seem open to implement features to make it a reasonable waveform viewer, which I considered the bigger risk before speaking with you on it. The rest is just code :-)
<azonenberg>
bluecmd[m]1: My long term goal is for glscopeclient to be the undisputed leader in the general problem space of analyzing sampled data from oscilloscopes, logic analyzers, spectrum analyzers to some degree, and all manner of related simulations
<bluecmd[m]1>
Having a hierarchy of signals to choose from is going to be needed for digital stuff, and as you say grouping and ungrouping of signals ("show this 48 bit logic array as unassigned")
<azonenberg>
as well as remote control of said instruments
<azonenberg>
bluecmd[m]1: Start filing tickets :p
<bluecmd[m]1>
Sure thing!
<azonenberg>
So this means doing everything from rs232 protocol decode to ddr4 signal integrity and everything in between
<azonenberg>
it means outperforming pulseview, gtkwave, and scope vendor software
<azonenberg>
Right now we're not there yet, but i think it's already the best f/oss tool around for signal integrity work
<bluecmd[m]1>
If you want to be a leader in that area you need a more hip name that doesn't actually say what it is. "ScopeTrek Ultimate - XLP" or something
<azonenberg>
Yes, a proper name is a TODO. i think there's actually a ticket for a real name/logo
<azonenberg>
The underlying library will remain called libscopehal but i'd like a proper name for glscopeclient
<azonenberg>
But the first priority is to make the tool good :p
<bluecmd[m]1>
Noscope360
<azonenberg>
loooool no
<bluecmd[m]1>
I kind of love it :D
<azonenberg>
anyway in parallel with this the secondary goal is to release a line of high end open hardware test equipment compatible with scopehal
<azonenberg>
both instruments and probes/accessories
<azonenberg>
I'm not even going to attempt to compete with low end shops like siglent/rigol on price, they have economies of scale i can't match
<azonenberg>
I want to make open hardware that is performance competitive with midrange lecroy/keysight/tek gear
<azonenberg>
The ultra high end is all ASIC and we can't go there (for now, at least)
<azonenberg>
and the low end is all mass produced in china and it will be hard to get people interested in when a rigol is 1/10 what our scope with the same specs costs
<bluecmd[m]1>
Like EEZ Bench Box?
<azonenberg>
But i think in the 500 MHz - 5 GHz range there's room for a high end open scope to squeeze in
<azonenberg>
I'm starting with a lower end model called BLONDEL. I do not expect it to sell well if at all, i may not even offer it for sale although of course people are free to build their own off the design on github
<azonenberg>
it's primarily a prototype and a learning experience
<azonenberg>
Eight channels split into two groups of four
<bluecmd[m]1>
Is this part of the starshipraider thing?
<bluecmd[m]1>
Seems so yes
<azonenberg>
each group has a single HMCAD1520 ADC, which is basically the same ADC used in the rigol ds1000z (four 250 Msps 8-bit converters that can be interleaved 2x or 4x to get higher sampling rates) except with a lower sample rate 12 bit option too
<azonenberg>
starshipraider was originally just one board but has now morphed into the umbrella project name for all of my open hardware test equipment
<azonenberg>
Anyway so basically you get 8 channels total, with each group of 4 sharing 1 Gsps of 8-bit sample capacity or 500 Msps of 12-bit sample capacity shared among the four channels
<azonenberg>
a stm32 for control plane stuff, data plane entirely in FPGA
<azonenberg>
it may never happen but i have a roadmap lol
<bluecmd[m]1>
I wonder what they are on the scrap+desolder market
<azonenberg>
and honestly if you look at what the LeCroy WavePro HD costs - an example of a commercial scope competitive with VOLLUM/MURDOCK's proposed specs - it would actually probably not be too unreasonably priced
<azonenberg>
a 4 GHz 10-bit 20/40 Gsps HDO9404 has a sticker price of $41.6K
<bluecmd[m]1>
If it can be made modular so I can buy a two channel and then add two later when the bank approves the second mortgage then it might work
<azonenberg>
That's four channels at 20 Gsps so matching those specs would need eight of those ADCs
<azonenberg>
bluecmd[m]1: Lol
<azonenberg>
Yes, the proposed design for those two scopes calls for a 3U Eurocard form factor
<azonenberg>
with single channel cards plugged into some kind of socket
<bluecmd[m]1>
That would be sweet
<azonenberg>
you can go all the way down to one channel. Also, the same ADC is available for about 2/3 of the price in a 6 GHz speed grade
<azonenberg>
6 Gsps*
<azonenberg>
so we could save $1K or so on a prototype board and do most testing on that
<azonenberg>
But that's a long ways out
<azonenberg>
I can push the HMCAD1520 out to 500 MHz bandwidth easily i think, i'd just need to interleave a bunch of them
<bluecmd[m]1>
Very cool
<azonenberg>
So i'm planning three generations of scope built around the same frontend and adc
<bluecmd[m]1>
Have you thought of crowdfunding it?
<azonenberg>
I took kickstarter funding for the handheld probe
<azonenberg>
It was a mistake, i did it too soon, and i released it before it was ready. I've ~doubled the bandwidth since the kickstarter
<azonenberg>
I am interested in crowdfunding production runs once the design is *done*
<bluecmd[m]1>
Ah
<bluecmd[m]1>
That makes sense
<azonenberg>
but i don't want to take preorders or anything before i've got one working unit that meets all target specs in hand
<azonenberg>
dont get me wrong, the kickstarter probes met all of the original advertised specs (barely)
<azonenberg>
but the AKL-PT1B has much lower loading and double the bandwidth of the AKL-PT1 and will cost about the same, actually the BOM is slightly less
<azonenberg>
it's an objectively superior design
<azonenberg>
The AKL-PT2 (solder-in flex probe) i will probably not crowdfund either because it's comparatively cheap. I'll prototype on OSHPark then go to my usual chinese fab for a large run
<azonenberg>
the last time i did a flex board of similar specs it was something like 500 USD for 500 boards
<azonenberg>
this will be a little more since it's larger, but i can afford to buy a batch of boards and then assemble them on demand and ship out as orders come in
<azonenberg>
the protective enclosures are going to be 3d printed TPU rubber that i can order on demand from shapeways with no quantity discounts
<azonenberg>
For the scopes i might take crowdfunding for higher volume runs but again only when the design is 100% done
<bluecmd[m]1>
Impressive and cool, you seem to enjoy it and provide cool stuff so there's a lot of things to like about what you describe :-)
<azonenberg>
I'm not trying to do this as a business, i already have a job that pays more than enough to live on
<azonenberg>
i mean legally it's a business so i can pay taxes on sales of my boards
<azonenberg>
but the goal is not to make a living off it, the goal is basically to break even
<azonenberg>
i enjoy doing this and i want to make test equipment more accessible to the masses
<azonenberg>
so if i sell enough of something to make up for the money i spent out of pocket on R&D, i'm happy
<azonenberg>
if i make a profit i'll just spend it on more lab equipment so the next project can be even better
<azonenberg>
So far i think the probe was a net loss, i brought in about $4.5K from the kickstarter and while that covered the costs of the actual PCBs and components i shipped to my backers, it didn't nearly cover the... thirteen, i think? board spins i've done by this point for R&D
<azonenberg>
But i'm still advancing the field, it's the best open hardware high-speed probe out there that i know of and it's still getting better. So it's worth it
<bluecmd[m]1>
Right, after bills and paying for new toys what good is even money :-)
<azonenberg>
Exactly. quite honestly that's basically been my strategy the last year or so
<azonenberg>
once i was done with the house renovation i just kept on expanding my lab
<azonenberg>
it's proven to be a very good strategy, working from home during covid i've become indispensable at $dayjob
<bluecmd[m]1>
To show a bit what I'm doing, I've been mostly focused on making an open source mainframe disk replacement using FPGA: https://github.com/bluecmd/fejkon
<azonenberg>
because i'm the only one who can keep on doing hardware stuff lol
<azonenberg>
oooh
<bluecmd[m]1>
That's probably one of my more "famous" projects although you'd have to be in the mainframe hobbyist circuit I think to have heard about it
<azonenberg>
Re you interested in network hardware too?
<bluecmd[m]1>
Sure, although I don't do very much on those these days
<azonenberg>
one of my other projects, back burnered for probably the next year or two while i focus on scope stuff, is a 1U 24+4 port 1G copper/10G SFP+ Ethernet switch
<bluecmd[m]1>
I was involved a bit in the OpenSwitch project until it got defunctd
<azonenberg>
I have the switch fabric IP mostly written and tested on a devkit, i have the line card with the 8x SGMII PHYs designed
<azonenberg>
need to still design the switch engine card with the big fpga and sfp's
<bluecmd[m]1>
Ah very cool!
<azonenberg>
longer term i want to make a 10G/40G switch to replace my nexus 3064x but that's less important
<bluecmd[m]1>
10G/40G is stupid cheap these days
<azonenberg>
yeah the main point is open hardware not being cost competitive with cisco
<azonenberg>
but it's also a security benefit, having less junk processing packets means less attack surface
<bluecmd[m]1>
Just bought a 32x40G for $500 still supported by the vendor (Arista)
<bluecmd[m]1>
Right
<azonenberg>
Nice. yeah my nexus was still supported when i got it
<azonenberg>
48x 10G + 4x 40G
<bluecmd[m]1>
Make your switch do P4 and you're likely golden
<bluecmd[m]1>
Even if it's expensive, if you're offering a P4 switch without NDAs that's pretty damn nice
<azonenberg>
My plan for LATENTRED, the edge switch, is to do dumb layer 2 switching plus veeeery basic management
<azonenberg>
turning ports on and off, forcing speed/duplex, dumping and clearing the mac table, tdr testing on ports
<azonenberg>
port vlans, 802.1q
<azonenberg>
and... honestly that's all i really need
<azonenberg>
LATENTORANGE, the 10G/40G, is meant more as a core switch and i might add more advanced features TBD
<bluecmd[m]1>
If I'd do a new L2 I'd still do P4 - maybe just a more limited implementation but still P4
<bluecmd[m]1>
Anyway, just an idea
<bluecmd[m]1>
If it's all FPGA in the datapath it can be fan-made I guess
<azonenberg>
Yeah it could be. But it's a smallish fpga, i'm targeting an xc7k160t
<azonenberg>
the reason being that it's the biggest xilinx fpga available in the 7 series family that is supported by the free compilers (an important consideration for open hardware)
<azonenberg>
getting more gates would mean moving to the ultrascale or ultrascale+ family and those come with four digit price tags per chip evne for the smallest ones
<azonenberg>
i'm going to have to squeeze pretty hard just to get the crossbar and mac table for an 8x8 10 Gbps crossbar in there
<azonenberg>
(the plan is to have 8x 10G ports on the crossbar then TDMA the 1G ports into 1G lanes rather than having crossbar ports that never got used more than 10% of the time)
<bluecmd[m]1>
The menu is not shown since I am only recording the main window, but the most notable thing I'd say is that when I add a clock recovery to the green channel the waveform data disappears but the clock is shown
<azonenberg>
bvernoux: status update btw, oshpark flex runs are much less frequent than the 4-layer runs. the board isn't even going to fab until october 13th
<azonenberg>
so i probably won't get it until end of month or so
<bvernoux>
yes flex are very slow
<bvernoux>
less demand ..
<bvernoux>
my first commit was merged in KiCad 6.x ;)
<bvernoux>
after very very long comments on a minor 1 line modifications ;)
<bvernoux>
anyway I think It requires more accurate things ...
<bluecmd[m]1>
azonenberg: I made a bit of a collage of other waveviewers how they do mixed layout and signal hierarchy. Do you want it or do you want to keep your head free from influences from commercial tools?
<azonenberg>
bluecmd[m]1: Go ahead and post it. I study every third party tool i can
<azonenberg>
did you make a ticket on the tracker yet? if so, post them as comments there
<bluecmd[m]1>
Yes, I did
<azonenberg>
But i try to do things differently if i see a reason we can do it better. Like displaying waveforms as separate plots rather than all on one display
<bluecmd[m]1>
Sure thing
<azonenberg>
interestingly, i discovered recently whiel fooling around with the tek 6 series that they had the same idea
<azonenberg>
The default display is one waveform per plot in separate plots, rather than all stacked on one plot
<azonenberg>
although you can configure them to be stacked if you want
<azonenberg>
that is actually something glscopeclient *cannot* do right now
<azonenberg>
putting two channels on a single plot
<azonenberg>
you can put protocol decode overlays on top but you can't have two analog channels on one set of axes
<azonenberg>
i'm not sure if there's a ticket for that or not, but so far nobody's complained too much so i get the feeling that the default is probably fine for now :p
<bvernoux>
azonenberg, what is great is to have the flexibility to have separate plots and merged if possible
<bvernoux>
azonenberg, does we can test the demo mode ?
<bvernoux>
the interesting things is to check how glscopeclient work in live
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #217: Add support for "memory" traces to remember a past waveform and display for comparison - https://git.io/JUAVO
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #217: Add support for "memory" traces to remember a past waveform and display for comparison - https://git.io/JUAVO
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #217: Add support for "memory" traces to remember a past waveform and display for comparison - https://git.io/JUAVO
<bvernoux>
I'm still thinking to buy the MSO5074 ;)
<bluecmd[m]1>
Note the last null! If you select it in the dialog you have to enter something in the last field, that threw me off a bit
<bvernoux>
does some people here will be interested to hack it ?
<bvernoux>
I could plan to check if I can add native 50Ohms input ;)
<bvernoux>
and increase the BW to 2GHz ;)
<bvernoux>
so it will be a killer scope for 1KUSD ;)
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #218: Allow multiple analog waveforms to share a single WaveformArea - https://git.io/JUAVz
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #218: Allow multiple analog waveforms to share a single WaveformArea - https://git.io/JUAVz
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #218: Allow multiple analog waveforms to share a single WaveformArea - https://git.io/JUAVz
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #218: Allow multiple analog waveforms to share a single WaveformArea - https://git.io/JUAVz
<bvernoux>
until we have @azonenberg open hw scopes/LA ;)
<azonenberg>
bvernoux: well the more folks we have playing with rigol stuff the better the driver will get. I can't do much dev as i don't have one
<bvernoux>
as yes MSO5000 seems to be very slow and unstable which is clearly annoying
<bvernoux>
over ethernet ...
<bvernoux>
the most annoying is the instability of MSO5000 so far
<azonenberg>
also if we have enough folks collaborating it's possible we can get rigol to fix firmware bugs :p
<bvernoux>
as it seems to crash/freeze in 40s ;)
<bvernoux>
when used over ethernet
<azonenberg>
yeah, what about usbtmc or rs232?
<azonenberg>
There's also potential to add workarounds if we can find them. sleeps between certain calls etc
<bvernoux>
yes
<bvernoux>
to be checked ;)
<bvernoux>
so far anyway I'm locked with ultra old DS1102E and Picoscope (which will be probably never supported)
<azonenberg>
DS1102E should work
<bvernoux>
and it seems Tek does not want to make me a good offer for the Tek 6 series refurbished ;)
<azonenberg>
using the DS1000 family driver
<bvernoux>
yes but not under windoz ;)
<bvernoux>
I need to reinstall a clean XUbuntu 18.x LTS
<bvernoux>
a native one ;)
<bvernoux>
my aim is to have glscopeclient to work on Zindoz but I like Linux too
<bluecmd[m]1>
What doesn't work under windows?
<bvernoux>
bluecmd[m]1, IIRC the usbtmc shall be rewritten to be compatible with Windoz using libusb ...
<bluecmd[m]1>
I see
<bvernoux>
so far only Oscilloscope with Ethernet shall work in windows ...
<bvernoux>
I do not know if anyone have tested
<bvernoux>
it is also why I want to buy the Rigol MSO5000 it has Gigabit Ethernet
<bvernoux>
and it will replace my ultra old DS1102E ;)
<bvernoux>
azonenberg, when are you planning to add basic LA support like cheap <10USD LA ?
<bvernoux>
azonenberg, it could bring lot of interest even more if there is a live mode which does not exist on any PC software for LA
<bvernoux>
LA with basic trigger with realtime decode/view will be amazing ;)
<bvernoux>
like on a scope
<azonenberg>
bvernoux: comment an amazon link or something on the ticket for it and i'll work on it when i have time
<azonenberg>
maybe after tek6 stuff is done
<azonenberg>
or you can do it :P
<bvernoux>
you want a link on amazon to buy a cheap LA compatible ?
<bluecmd[m]1>
azonenberg: I never heard of https://www.dreamsourcelab.com/ before, maybe you have? They have a quite flashy logic analyzer UI
<bluecmd[m]1>
and is open-source
<bvernoux>
bluecmd[m]1, has their latest USB3.0 LA ;)
<bvernoux>
I have
<bvernoux>
bluecmd[m]1, it is amazing for the price even if their politic towards open source is very very discutable ...
<_whitenotifier-f>
[scopehal] bvernoux edited issue #270: Support ultra cheap Logic Analyzer USB 2.0 HS with 24MHz 8 Chan based on Cypress FX2/FX2LP chips - https://git.io/JUawb
<bvernoux>
I have added a cheap reference on Amazon ;)
<bvernoux>
they wrote it is compatible with PulseView
<bvernoux>
and they provide crapy probes ;)
<bvernoux>
anyway for <12USD ;)
<azonenberg>
bvernoux: just ordered it. I expect it's garbage but if i can get a uart signal off it i'll be happy for now :p
<bvernoux>
yes it is garbage which just works ;)
<bvernoux>
some does not have configurable voltage trigger ;)
<bvernoux>
a friend have received 5 similar
<bvernoux>
so I suspect high and low level are fixed
<azonenberg>
yeah i expect the cheap ones literally just connect the signals to the fx2
<bvernoux>
anyway that shall work with any signal 3.3V & 5V ;)
<bvernoux>
or maybe 2.5V ;)
<bvernoux>
but I doubt 2.5V works correctly
<azonenberg>
yeah i would consider them 3.3 only
<bvernoux>
yes
<bvernoux>
the surprise is does it contains FX2 or FX2LP ;)
<bvernoux>
FX2LP is better in fact
<bvernoux>
I have 2 or 3 like that but they are more advanced ;)
<bvernoux>
16chan and trigger level configurable
<bvernoux>
but it is similar crap but they work fine
<bvernoux>
what is crapy is when using SMPS > 12MHz as USB 2.0 HS does not follow
<azonenberg>
lol
<bvernoux>
or you can use 24MSPS but only with 2 or 4 chan max ;)
<azonenberg>
oh so... What do you think of WM9565-ND?
<azonenberg>
9 inch u.fl to coax lead
<azonenberg>
pre strpped
<bvernoux>
Cable Assembly Coaxial U.FL
<bvernoux>
yes nice
<azonenberg>
my thought is that we could probably solder that bare coax tip right to a tiny flex board with the 3 resistors and a solder in tip
<azonenberg>
then have a bridge from u.fl to sma or something at the other end
<bvernoux>
and the price is not crazy
<bvernoux>
compared to the crap bought on Aliexpress ;à
<bvernoux>
here it is Molex stuff so it shall be better
<bvernoux>
ha yes for a very cheap probe
<bvernoux>
UFL are often limited to 3GHz
<bvernoux>
or less
<bvernoux>
so it is clearly not to build a 5GHz probe ;)
<bvernoux>
something up to 1.5GHz maybe to be checked
<azonenberg>
molex says "up to 6 GHz"
<azonenberg>
but no idea how lossy
<bvernoux>
yes to be checked I use UFL only for HF stuff ;)
<azonenberg>
is that 3 dB at 6 GHz or what?
<azonenberg>
anyway, it's an idea
<bvernoux>
but yes there is some WiFi 5G which use that all the time
<azonenberg>
one possible concept i have is to make a MEAD input board
<bvernoux>
so it should reach 5 or 6GHz in theory to be checked
<azonenberg>
with the LSHM connector on the bottom then a bunch of u.fl's on the front
<azonenberg>
and then have tiny u.fl -> solder in flex probe assemblies
<bvernoux>
the drawback of ufl is to connect it correctly
<bvernoux>
I have even bought a tool for that
<azonenberg>
Yeah it has a short lifespan
<bvernoux>
as often we connect them badly ;)
<bvernoux>
and it is dead very quickly
<azonenberg>
But OTOH, if the cable is $3, the flex pcb is probably less than $1 at oshpark for a tiny thing, then $6 of resistors
<bvernoux>
I have a kit to check them
<bvernoux>
with my VNA
<azonenberg>
you're looking at potentially a $10-15 probe with performance to several GHz
<azonenberg>
so who care if it's only good for a couple of uses? :D
<bvernoux>
yes the aim is to does not connect the UFL too much
<bvernoux>
or just one time to a mini board to convert UFL to SMA ;)
<azonenberg>
my thought is for MAXWELL
<azonenberg>
i want to be able to get tens of probes onto a board, tiny connectors and cables are beneficial there
<bvernoux>
ha so the plan is to connect /disconnect each time ?
<bvernoux>
or to keep them connected
<azonenberg>
I expect i'd be mating and unmating them fairly frequently and just consider the probes semi disposable
<azonenberg>
these would be for density optimized applications, let's call it the AKL-PT3
<bvernoux>
as the issue is also towards the UFL male connector which has not a very long life
<azonenberg>
while the AKL-PT2 will be larger but have longer lifetime
<azonenberg>
and probably cost more like $50-75
<bvernoux>
I have bought U.FL-LP-N2
<bvernoux>
from HIROS
<bvernoux>
it can extend the lige of UFL > 10x
<bvernoux>
life
<azonenberg>
nice
<azonenberg>
but yes in general the point of u.fl would be for when size matters more than lifetime
<azonenberg>
if you're probing something ultra tiny
<bvernoux>
yes it is why I have a cal kit for that ;)
<bvernoux>
as it is very common for antenna
<bvernoux>
I have a UFL & Balanced Calibration Kit
<bvernoux>
which is very nice and work up to 6GHz
<bvernoux>
it is pretty expensive for what it is ;)
<bvernoux>
from MegiQ
<bvernoux>
but they have chosen quality cables, UFL... and we can even characterize some 1.27mm pin when UFL is too big
<bvernoux>
it is what I use for NFC but it works up to 6GHz to be checked ;)
<azonenberg>
bvernoux: I think i'm gonna design a prototype of the AKL-PT3 tonight then send it out to fab, hopefully getting on the same panel as the AKL-PT2 prototype
<azonenberg>
i can do it super cheap so i figure i'll try it, if it doesn't work then no problem
<azonenberg>
i want people to find scopehal-apps first and pull that as the primary repo to work with
<bvernoux>
yep ;)
<bvernoux>
let's try that Demo mode ;)
<bvernoux>
build in progress ;)
<bvernoux>
I really need a Ryzen9 or something like that
<bvernoux>
my other passive PC is now in the room of my daughter it was too good ;)
<bvernoux>
so I must buy a new one anyway it was not enough punchy ;)
<azonenberg>
Bird|otherbox: oh, i've got another "build improvements monkey" job for you if you're interested. Since that seems to be your niche in the project right now
<azonenberg>
I suspect the global includes scopehal.h / scopeprotocols.h have way too much stuff in them
<azonenberg>
We can probably pare those down a lot and move the per-class includes down to source files and speed compile times up a fair bit
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #297: Look into optimizing global #include's - https://git.io/JUAy9
<_whitenotifier-f>
[scopehal] azonenberg opened issue #297: Look into optimizing global #include's - https://git.io/JUAy9
<bvernoux>
woo very nice the demo
<bvernoux>
it works in realtime
<bvernoux>
with 50GS/s signals ;)
<bvernoux>
it's my dream scope hehe
<bvernoux>
glurps to setup a trigger on the scope that crash
<azonenberg>
File a bug against scopehal for that. Triggering isnt implemented on the demo scope but it shouldn't crash
<azonenberg>
you can adjust the demo scope's sample rate from 1 to 100 Gsps
<azonenberg>
bvernoux: ^
<azonenberg>
did you try running decodes and analysis on them?
<azonenberg>
the 10G signal is just a PRBS but the 1G is valid 8b10b
<bvernoux>
i tried different decode
<bvernoux>
the Clock Recovery PLL is strange on top signal
<bvernoux>
it does not respect the threshold
<bvernoux>
what decoder shall be used ?
<bvernoux>
if I try 100Mbit it crash
<bvernoux>
Ethernet 100Base-TX just crash
<azonenberg>
bvernoux: none of them should crash. If you segfault a decode file a bug for it
<azonenberg>
The CDR PLL locks to a 90 degree phase offset by default
<azonenberg>
if you run clock recovery on the top tone signal, you'd want to use a threshold of 0V and 2 Gbps as the data rate
<azonenberg>
it should lock so that you have a rising or falling edge at the top and bottom of the sinewave (so 90 degrees off from the zero crossings)
<azonenberg>
because the eye pattern and high speed serial decodes like 8b10b and 64b66b expect to sample the signal with a DDR clock centered in the data eye
<azonenberg>
there's an open ticket for allowing the lock phase to be configured to center or edge aligned, and single or double rate
<bvernoux>
azonenberg, what is the decoder which shall work in realtime ?
<bvernoux>
some are greyed
<bvernoux>
I do not understand why
<azonenberg>
Decodes are all capable of running in realtime. They're disabled if the signal you right clicked on isn't the right type
<azonenberg>
Everything is strongly typed
<azonenberg>
so if you try to threshold a digital waveform, for example, that makes no logical sense
<azonenberg>
or FFT a digital waveform
maartenBE has joined #scopehal
<azonenberg>
meanwhile doing a SPI decode on an analog waveform makes no sense, you have to threshold it first
<bvernoux>
how to convert an analog signal to digital ?
<azonenberg>
Threshold filter. Under math i think
<azonenberg>
There's an open ticket for automatically suggesting this
<bvernoux>
I was using Clock Recovery PLL for that but it is not exactly that ;)
<azonenberg>
i.e. if a filter expects a digital input and you select an analog signal, it will automatically suggest applying a 50% threshold to it
<azonenberg>
but that's not currently implemented so it just disables the filter
<azonenberg>
so for the bottom signal for example to do 8b10b decoding you'd want to both threshold and CDR PLL the analog signal
<azonenberg>
then apply the 8b10b decode on the thresholded signal
<bvernoux>
yes threshold work fine
<azonenberg>
Note that you have to right click *on the threshold signal* not the analog signal to do the 8b10b
<azonenberg>
since the context for the menu depends on the exact signal that's selected
<bvernoux>
the strange things is mesurements ;)
<bvernoux>
I expect it display only value not cruve
<bvernoux>
curve
<azonenberg>
Most measurements are instantaneous values
<azonenberg>
if you want summarized values right click the plot and turn on statistics
<bvernoux>
a must have will be to have full measurement ;)
<bvernoux>
all in one
<azonenberg>
If you want to just see the average frequency turn on a frequency plot and enable stats for that
<azonenberg>
there may eventually be a UI shortcut for it
<azonenberg>
but i've unified measurements, protocol decodes, and math functions into a single filter graph. makes things architecturally MUCH cleaner
<azonenberg>
and honestly there are a lot of times when looking at cycle-by-cycle frequency or rise time is helpful
<bvernoux>
yes each time we shall set a measurement which display a graph and we shall click in stat
<bvernoux>
but we cannot hide the graph
<azonenberg>
You can hide the graph
<bvernoux>
ha ?
<azonenberg>
just right click and go delete
<azonenberg>
however, once you do that the stats are stuck there forever
<bvernoux>
yes but that delete the mesurements stats
<azonenberg>
no it doesnt
<azonenberg>
or it shouldn't
<azonenberg>
the filter is refcounted and if you have a stat active, it should maintain a reference and not delete the graph
<azonenberg>
not delete the filter
<azonenberg>
the graph and stat both maintain references and the filter is auto deleted when both are removed
<bvernoux>
yes true measurements are not removed ;)
<azonenberg>
But once you delete the graph you can't turn the stat off
<azonenberg>
there's no UI for it yet
<azonenberg>
if the graph is still there you can uncheck stats in the context menu
<bvernoux>
yes
<azonenberg>
Everything is refcounted. you can set up a math function on a channel then delete the channel
<azonenberg>
and the math function keeps a reference open to the channel so you keep acquiring waveforms
<azonenberg>
when you then delete the math function the channel is disabled in hardware as it has no references anymore
<azonenberg>
so you're not wasting usb/ethernet bandwidth or cpu time processing it
<bvernoux>
yes very nice even on my old PC
<azonenberg>
(lots of these things should be documented, but the manual is very incomplete...)
<bvernoux>
yes anyway it is very usable
<bvernoux>
I think it will be nice to have a toolbar ;)
<bvernoux>
like Lecroy ;)
<bvernoux>
to be hidden for those who hate that
<azonenberg>
There is a toolbar up top? or is that not what you meant
<azonenberg>
with the start/stop trigger buttons, clear sweeps button, opacity adjustment, etc
<bvernoux>
a toolbar on bottom ;)
<bvernoux>
a new one
<bvernoux>
for signal/decoder
<bvernoux>
something easier to add decoder/math as right click is hard to find what we want
<azonenberg>
That only makes sense if you have a single plot area
<bvernoux>
to be checked to have faster access to math/decoders ...
<bvernoux>
I think right click shall have less things
<azonenberg>
if you have many waveform areas you have to know where to add it
<azonenberg>
I'm going to shrink the context menu, a bunch of stuff is moving to properties dialogs
<bvernoux>
yes by selecting the curve
<azonenberg>
but i plan for it to remain the primary interface for decodes and math moving forward
<azonenberg>
i think the 2-level menu is pretty fast to navigate
<bvernoux>
we shall show what is the active waveform with a special border maybe
<bvernoux>
as it is not clear sometime which waveform will be used for the right click
<azonenberg>
File a ticket for marking it more clearly
<azonenberg>
against scopehal-apps
<bvernoux>
yes to be checked how to improve that
<_whitenotifier-f>
[scopehal-apps] bvernoux opened issue #219: Optional new toolbar with shortcut on bottom (or movable) to select quickly measurement/decoder ... - https://git.io/JUAdF
<bvernoux>
I will clarify that later ;)
<bvernoux>
strange there is no horizontal cursors ?
<bvernoux>
the vertical ones is very nice
<azonenberg>
There's an open ticket for it
<azonenberg>
just havent got around to implementing it yet
<bvernoux>
ha ok
<bvernoux>
anyway it is very usable
<bvernoux>
there is nice details on GFX card now too
<bvernoux>
does it is normal we cannot change the trigger on the demo ?
<azonenberg>
Yes. Triggering is not implemented yet
<bvernoux>
like a real scope
<bvernoux>
ha ok
<azonenberg>
i banged out the demo in a couple hours last night from nothing, lol
<bvernoux>
yes it is already a very good start to check how it work in realtime
<bvernoux>
there is something strange on my PC
<bvernoux>
when I launch it it is quite fast
<bvernoux>
and over time it is slower and slower
<azonenberg>
interesting, is memory usage increasing or something?
<bvernoux>
to be checked if it is not a memory leak ;)
<bvernoux>
also my GFX card overheat ;)
<azonenberg>
the demo is brand new and not well tested, it might be leaking but who knows
<bvernoux>
but it is not the fault of glscope ;)
<azonenberg>
And lol. The demo is capped to i think 50 FPS actually to avoid burning TOO much cpu
<azonenberg>
otherwise it'd run faster
<azonenberg>
at least with the default waveform depth
<bvernoux>
GPU usage <3% ;)
<azonenberg>
yes there is room to push a lot more compute to the GPU, especially FFTs
<bvernoux>
I do not see memory leak
<bvernoux>
it is just my PC which is too hot ;)
<bvernoux>
it is old
<azonenberg>
Well you also dont have to run it in continuous trigger mode
<azonenberg>
you can grab single waveforms and stop
<azonenberg>
and still play with ffts, decodes, eye patterns, etc
<bvernoux>
yes I tested that too
<bvernoux>
ha nice with the Rigol MSO5000 there is 2 small SigGen ;)
<bvernoux>
2chan it is good up to 25MHz
<bvernoux>
200MSPS
<bvernoux>
nothing crazy but better than nothing for small signal ;)
<Bird|otherbox>
azonenberg: might as well just toss include-what-you-use at the job even :)
<azonenberg>
is that an automated tool for doing exactly this?
<_whitenotifier-f>
[scopehal] tarunik commented on issue #297: Look into optimizing global #include's - https://git.io/JUAxZ
<_whitenotifier-f>
[scopehal] azonenberg commented on issue #297: Look into optimizing global #include's - https://git.io/JUAx0
bvernoux has quit [Quit: Leaving]
<Bird|otherbox>
it indeed is
<azonenberg>
Well then go ahead and use it :)
<azonenberg>
Once the static analysis integration is done, that is
<azonenberg>
What's the status of that?
<azonenberg>
i haven't seen a PR or any bug reports from current analysis findings yet
<Bird|otherbox>
I'll be writing up tickets from the clang-analyzer findings here shortly (support for that on an ongoing basis will be complicated)
<Bird|otherbox>
also: will be adding support for finding cppcheck instead of using hardcoded paths
Katharina has joined #scopehal
<azonenberg>
Bird|otherbox: great
<azonenberg>
Yeah i dont want automated ticket creation anyway
<azonenberg>
i want just routine inspection of analysis results, identify false positives, and file bugs for legitimate issues
<azonenberg>
o/ Katharina
<Bird|otherbox>
:P autotickets would be another level of complicated anyway
<azonenberg>
Bird|otherbox: was the cppcheck run clean or did it have any findings of note?
<Katharina>
o/ all
<azonenberg>
Bird|otherbox: long term i do want to set up CI builds with automated reporting of build failures for both windows and linux, plus static analysis failures, to some kind of dashboard. But that's not a current priority
<Bird|otherbox>
AFAICT it was a clean run, I'll be doing another run once I get this initial round of clang-analyzer findings out and the executable finder integrated. say: did you want one ticket per thing found, or...?
<Bird|otherbox>
anyway -- the thing with clang-analyzer is its invoked in a way that wraps cmake
<Bird|otherbox>
well, cmake and make
<azonenberg>
One PR for the analysis integration, one ticket per static analysis finding that is confirmed to be a legitimate bug
<azonenberg>
Katharina: i see you've been commenting on tickets and reviewing PRs... have you been feeling up to doing any actual development yet or what?
<Katharina>
azonenberg: yep, I did a little improvement the other day, and feel ready to do more
<azonenberg>
the preferences system is still on hold, Bird|otherbox did some good work bringing ui-dev in sync with the current code (there have been some major refactorings since you last touched it, it's now ui-dev-new or something like that)
<Katharina>
The preferences should be top priority for me then
<Katharina>
That's Important
<Bird|otherbox>
\o/
<azonenberg>
Correct
<azonenberg>
We have like half a dozen other tickets that all depend on getting that merged to master
<azonenberg>
i keep finding new things i want to have config settings for lol
<Bird|otherbox>
yeah, look in gui-dev-new for the post-submodules-rearrangement version of the gui-dev branch
<Katharina>
You can assign me to that ticket if you'd like, I'll take care of it until Sunday
<azonenberg>
Katharina: also in case you werent aware scopehal-cmake is now defunct, we merged it with scopehal-apps
<azonenberg>
scopehal-apps is now the new top level repo which pulls in scopehal and the others
<Katharina>
azonenberg: that's a good decision
<azonenberg>
We may at some point merge scopehal and scopehal-apps but that will be a much bigger integration project
<azonenberg>
xptools and logtools will remain separate for the foreseeable future
<azonenberg>
Katharina: also not sure if you saw but we now have fairly-complete support for Tek MSO5/6 series instruments
<Katharina>
The particular reason I'm here now is that I wanted to ask whether there are any plans to change the waveform save format in the future. The whole "main file and data in subfolder" thinf
<azonenberg>
There is going to be at least one change in the nearish future, someone found that some stuff i was generating is not valid YAML although yaml-cpp accepts it
<azonenberg>
So i will definitely be fixing that although i hope to retain at least read compatibility with the older format (hopefully it will parse the same in yaml-cpp and not need any changes to the loader, just the writer)
<azonenberg>
There are no immediate plans to change the fundamental architecture of the save format at this time
<azonenberg>
i may make optimizations like supporting compression for the waveform data or something
<azonenberg>
But i think it will remain YAML metadata + binary waveforms
<Katharina>
Yep compression was what I was wondering about :) like a nice LZMA on the binary waveforms
<azonenberg>
the alternative is to create a custom file format that's basically a database
<azonenberg>
which seems like a lot of work when the OS filesystem does that for us
<azonenberg>
So i have a couple ideas. I think delta coding might work well
<azonenberg>
also, having the offset and duration values be optionally omitted for the most common case of equal-frequency samples starting at time zero
<azonenberg>
that right there is an 80% reduction in the size of an analog waveform on disk
<azonenberg>
the current format is basically a direct serialization of the in memory representation and was quick to write
<azonenberg>
If i do any kind of "standard" deflate/lzma it's going to be on top of an application specific coding scheme that takes advantage of the known characteristics of waveform data
<azonenberg>
let me make a ticket for that
<azonenberg>
it's not a priority but i want it tracked
<Katharina>
Funnily enough I implemented the virtual filesystem approach at work the last few days for our measurement data bases
<Bird|otherbox>
yeah, the thing with the clang-analyzer stuff (at least the stuff that's not just "dead variable" level, which I'm ignoring for now since that's mostly in the analyzers)
<Katharina>
That's why I got to think about it in terms of this project haha
<Bird|otherbox>
is that it's not something that I can figure out is "real" or not just by inspection -- some of the dataflow paths clang-analyzer found are pretty twisty
<Bird|otherbox>
so I'm thinking it might be best to figure out how to upload the clang-analyzer report for a given issue along with the bug
<azonenberg>
Bird|otherbox: that makes sense
<azonenberg>
Work on merging the analyzer integration first though
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #220: Figure out optional compression format for waveform data - https://git.io/JUAht
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #220: Figure out optional compression format for waveform data - https://git.io/JUAht
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #220: Figure out optional compression format for waveform data - https://git.io/JUAht
<Katharina>
azonenberg so, do you want me to make the properties dialog as pretty as possible before the merge, or rather focus on it being usable and merge asap?
<Katharina>
And then beautify it later
<azonenberg>
Focus on making it usable, merge so we can start working on all of the tickets that involve having preferences for various stuff
<azonenberg>
If possible i'd like preferences to be hierarchical
<azonenberg>
using some kind of tree so you can have things like Decode.Colors.Address = #ffff0
<azonenberg>
basically get it to the point that you dont expect to need major refactoring of code using prefs
JSharp has joined #scopehal
<Katharina>
Got it
Katharina has quit [Remote host closed the connection]
Katharina has joined #scopehal
<Katharina>
Ouff, my broadband connection doesn't like IRC anymore. I need to set up something on my VPS