<joshua_>
I also have a bunch of coding style stuff to clean up there, and I try not to jump into other people's projects and complain about coding style no matter how distasteful I find it ;), but I do have to kvetch about the following: "The * in a pointer declaration is part of the type, not the variable. For example int* foo, not int *foo"
<joshua_>
this is, I think, an error in the way the language is specified, and if I had my way, I would not do it this way, but since the language is the way that it is, the * really ought not be grouped with the type
<azonenberg>
yes i consider that a bug in the spec. and one of many reasons i avoid multiple declarations in a single statement
<joshua_>
anyway, this is a start for this UI change, and if I have more time in the near future, I will continue to explore this some if you do not find it too distasteful
<azonenberg>
I'll review when i get a chance. Have family visiting for the weekend so may be a little bit
<azonenberg>
one thing i do want to avoid is having too many ways to do the same thing
<azonenberg>
that are slightly different and confusing
<joshua_>
yeah, I definitely do not think it is ready for code review (though the code changes are quite simple), but I did provide a screenshot of the UI that I propose
<azonenberg>
and/or have duplicated code paths
<azonenberg>
Yeah
<azonenberg>
One possible example: make right click on the stream browser spawn a popup ChannelPropertiesDialog like the filter graph editor does
<azonenberg>
this would literally be the same code
<azonenberg>
thus no duplicated code and identical UI semantics to other ways of accessing the same dialog
<joshua_>
yes, though I think the reason I intend to render it in addition to spawning a popup ChannelPropertiesDialog is because the information is important for *viewing* and needs to be on screen
<azonenberg>
So maybe rather than having it be a popup have it be embedded in the treeview. imgui lets you do that kind of thing
<azonenberg>
we may have to make some changes or add flags to ChannelPropertiesDialog
<azonenberg>
but if we do go down this route, i want common code
<joshua_>
yes, this is what I do for the timebase status indication in the StreamBrowserDialog :)
<joshua_>
there could be a ChannelPropertiesDialog "lite mode" but I suspect that the desired renderings ("summary read-only view with affordancds to launch the real editor" vs. "editable view with all the gory details") are different enough that it may nto make much sense
<azonenberg>
yeah this might end up being an agenda item for the dev call
<azonenberg>
Perhaps it makes sense to have common code for a subset of settings that both dialogs invoke, idk
<azonenberg>
i just want to keep things common as much as possible
<azonenberg>
i've been doing a lot of refactoring lately removing specializations of e.g. "connect to instrument" dialogs that were ten classes each differing in a handful of lines
<joshua_>
well, feel free to think about it, and maybe to look at the code; you will see that there is not much of it
<azonenberg>
Yeah
<azonenberg>
just saying from a high level design perspective
<azonenberg>
i want to avoid both code bloat and two apparently identical bits of ui acting slightly differently
<joshua_>
it is not a bad principle to have at all, I think I just am not convinced that it applies in this case :)
<azonenberg>
Yeah
<azonenberg>
We'll see when i've had a cahnce to review
<azonenberg>
i will say, in general, the stream browser is in its infancy and i think has a lot of room to grow and be a more core piece of UI
<azonenberg>
One of the other things i am in the process of beginning to do, and hope to finish before v0.1 but might not, is making all of the other types of instrument properties dialog have semantics more closely matching scope channels
<azonenberg>
e.g. dont have a "power supply dialog"
<azonenberg>
you have properties for each channel
<azonenberg>
and then a separate dialog, details tbd, for things like a global on/off
<joshua_>
I will probably hack on it a little more while I'm waiting for my brain to engage on real work stuff tomorrow to see if I can get it to meet my needs a little better
<joshua_>
if it ends up being mergeable in the end, great, if not, well, I got to learn patterns around ImGui some
<azonenberg>
We do desperately need an additional GUI dev
<azonenberg>
As of now, almost every third party contribution in recent times has been back end (drivers and filters)
<azonenberg>
with only trivial frontend things like adding a preference setting to enable some setting the backend needed configured
<azonenberg>
Long term, i can't be the only person working heavily on the gui
<joshua_>
I am not sure I am a whole GUI dev but I am happy to submit patches to fix rough edges that bother my OCD
<azonenberg>
1.5 gui devs beats 1
<azonenberg>
:p
<joshua_>
I have been really nitpicky about the UI for X1Plus and I think that like ten people use that in total, so I would be happy to be nitpicky in higher impact ways
<joshua_>
but for now, apparently my alarm is set for 6:15, so I should probably eject from my terminal
<joshua_>
oh, ok, one other thing: I would be interested if you could record like 15 minutes of screen capture of how you use ngscopeclient on any particular day. no need to talk over it or explain anything, I just want to see what you're clicking on and what flow you take through it to set up an experiment and run it
<azonenberg>
I'll see if I can throw something together that isn't work related or active dev
<azonenberg>
a lot of what i've been doing recently has either been work or "click a few things, notice the thing i just wrote doesn't do what i want, maybe save the session maybe revert, close, change something, recompile"
<azonenberg>
:p
<azonenberg>
Which is probably not what you want to see
_sgstair has joined #scopehal
sgstair_ has quit [Ping timeout: 260 seconds]
bvernoux has joined #scopehal
pirate has joined #scopehal
<pirate>
power went out yesterday evening, oop
<d1b2>
<chille0417> Yay! Finally got my Hantek 365B USB multimeter. Seems to work without a problem with the reverse engineered open source software. Time to start coding a driver for scopehal!
<azonenberg>
pirate: oh noes, back up now?
<d1b2>
<azonenberg> Yay, more multimeter drivers will certianly be welcome
<azonenberg>
joshua_: btw, one of the things this might be good for is things like the global on/off setting of a power supply which doesnt have a great place to live once i refactor out the existing power supply dialog
<azonenberg>
having a global on/off under the instrument might actually work really well
<joshua_>
sure, or separating instrument types in general, power supplies, then scopes, then ...
<azonenberg>
So i am actually trying to move away from that because of how many multi-function instruments there are
<azonenberg>
instead i prefer to have instruments advertise their capabilities and the GUI will dynamically adapt what stuff to show based on the properties of a given channel
<azonenberg>
especially with the analog discovery class, or entry level DSO, instruments
<azonenberg>
its not uncommon to have scope, function generator, multimeter, PSU, etc all in one instrument
<joshua_>
a shower thought of the day, by the way, while I was thinking of 'UI metaphors in general' is that, although I think of my scope on my desk as a tool, I think of my computer on my desk as a notebook, and I wonder if forcing ngscopeclient to be "like a measurement instrument" rather than "like a recording device for research and science" is the wrong way to think about it
<azonenberg>
Can you explain in general? I see ngscopeclient very much as a tool for exploring and navigating and manipulating data
<azonenberg>
some of which is live and some prerecorded
<joshua_>
i.e., I was brainstorming the concept of what it would mean to have richer lab notes (being able to refer to specific captures in the past, for which my current flow is "screenshot and paste to slack/discord"), and instead have a lab notes where I could have a diary of "I did x experiment, and got the following result, click to go back to exploring it again"
<joshua_>
almost ipython/jupyter-style
<d1b2>
<david.rysk> oh I see what you mean... yeah I was going to mention, ipython/jupiter is popular for that reason and we have whole systems (e.g. ChipWhisperer) built around that
<azonenberg>
that's one of the things the history feature is intended for
<azonenberg>
Allowing you to save e.g. before/after data of some rework
<azonenberg>
and then tweak the filter graph to perform new analysis ex post facto on the old waveforms
<azonenberg>
Easy linking to specific points in time or something from different sessions is certainly something to think about although idk how it would work ui wise
<azonenberg>
We already have a general "lab notes" field within the application plus the ability to name waveforms. I'm not opposed to the idea of allwoing you to attach arbitrarily complex markdown to a single acquisition to give more detailed hierarchical notes or something
<azonenberg>
i think the flow can certainly be made more powerful
<joshua_>
I think mostly my mental model is that I want to linearly write about an experiment (and, sometimes, nonlinearly, but I don't know of any other UI metaphors that describe this), both textually, with code (or other specifications of how I configure a system), or with graphics / results
<azonenberg>
Yeah. I like the high level concept but I don't yet have concrete ideas for how it would be implemented
<azonenberg>
if you wanna file a ticket just for brainstorming go for it
<joshua_>
I could imagine, for instance, the 'lite' version of this being ngscopeclient generating or outputting to a jupyter notebook and naming capture variables
<azonenberg>
the "lab notes" feature is certainly minimalistic
<azonenberg>
and could be exapnded a lot
<joshua_>
I could imagine the 'full fat' version of this being ngscopeclient being completely controlled by a jupyter notebook; i.e., to do a capture in ngscopeclient, I actually completely configure it from python, and then run a cell with code `dho4000.trigger()\nnoise_100mA = dho4000.acquire()` or something
<azonenberg>
Yeah. There's certainly a lot of potential for scripting integration long term
<azonenberg>
not a v0.1 feature certainly :p
<joshua_>
yeah
<azonenberg>
But also, things like in-app annotations and such will be good
<azonenberg>
Being able to make navigable, marked-up waveforms that include not just data but higher level analysis of said data
<azonenberg>
maybe even referencing photos of an experimental setup or circuit diagrams idk
<joshua_>
right
<joshua_>
ok I will file a ticket for this. I think the instinct that I have is 'don't reinvent the wheel: do this with jupyter, it's really good at it, and people love it'
<azonenberg>
i mean, i hate python so i'd do literally anything else :p
<joshua_>
it is your project and you would have the right to do that!
<azonenberg>
but i'm not opposed to someone adding the integration eventually if people find it useful
<azonenberg>
Not every feature is for me
<joshua_>
as someone who also dislikes python and spent many years doing Advent of Code in Lua and C largely out of spite, I get where you are coming from!
<azonenberg>
i once had a class assignment where the prof said we could use any language we wanted
<azonenberg>
I did it in x86 asm
<gurki>
i think you need to decide whether you want to be labview, a universal tool frontend or the main tool behind large scripted meassurements
<azonenberg>
all of the above? :p
<gurki>
trying to be good at all three might make you bad at all of them
<gurki>
thats why i saif that ;)
<gurki>
said*
<azonenberg>
I think we will probably want to build dedicated ATE-specific flows around libscopehal and libscopeprotocols
<azonenberg>
that don't necessarily use ngscopeclient
<gurki>
for me libs i cannot call from python just ... wont be used since i typically have a ton of involved equipment
<gurki>
ya id love that :3
<azonenberg>
Yeah I am not opposed to someone else adding python or something wrappers eventually
<azonenberg>
but personally, i will happily design all of my automated test flows in C++ :p
<gurki>
(no criticism, just providing a pov)
<azonenberg>
Yeah. Anyway, any kind of scripting API beyond the native C++ is a >> v0.1 issue
<azonenberg>
I'm all for filing tickets of things we want to have eventually
<azonenberg>
but the near term focus is on getting something reasonably polished with the current feature set we can put in front of the thunderscope early users
<azonenberg>
that will install and run reliably without crashing on all of our supported platforms, without users having to compile it themselves
<azonenberg>
and with sufficient docuemntation that they can figure out how to do most stuff
<azonenberg>
That influx of new users, if things go well, will hopefully bring with it new developers
<joshua_>
I think having thunderscope act as a scope first is a good idea
<pirate>
azonenberg: it is
<azonenberg>
pirate: so are you available/ready for more icon work now?
<azonenberg>
or were you busy today too? cant remember
<pirate>
i'm available :)
<pirate>
apologies for all the doctor shit this week
<azonenberg>
No worries
<azonenberg>
Our other artist has been dealing with health issues too, i know how it goes
<azonenberg>
OK so... next set of icons: let's start with a vertical usb A connector for the usb 2.0 series decodes, with blank space on the right for us to put in some text or other icon depicting the specific function of the block
<pirate>
aye aye
<azonenberg>
also a chibified PCIe card. What do you think about kind of a back angled view for this? like, looking at the bracket end, angled so you can see the card but it's skinny
<azonenberg>
or maybe just a really short card like some of the low profile gig-e nics, idk
<azonenberg>
fool around with some concepts. i'm picturing roughly like the SD card layout
<azonenberg>
with pcie card on one side then {whatever} to the right
<d1b2>
<chille0417> I think a good start would be to write a Python module for scopehal. In that way we can at least interface with things like multimeters, power supplies etc for automated testing that will not need the filters. I have never written a Pyhton module before, but my experience from other similar things tells me it should only be a few hours of work and easy to maintain.
<azonenberg>
So where things get trickier is interfacing with protocol data and stuff
<azonenberg>
In general, though, this seems like something we'll want to do after some of the upcoming refactorings are done
<joshua_>
"I have never [x, but] it should only be a few hours of work and easy to maintain" is the sort of statement that strikes fear in one's heart :)
<azonenberg>
since there will be major back end object model changes
<azonenberg>
(and that too)
<d1b2>
<chille0417> Haha, yeah I see how it looks... 😄 But I have actually written modules for other scripting languages. Usually it's just a 1:1 mapping as long as you ignore advanced data types and other stuff that could be tricky to implement.
<joshua_>
I cannot speak for azonenberg, but I probably would not accept into my project first-party bindings that are not native-feeling in their target language and/or that lock one into maintaining an unpleasant API
<azonenberg>
Yeah i definietly do not want to add any external language bindings with our internal APIs in their current state
<azonenberg>
because of how rapidly things are changing
<pirate>
azonenberg: i have a nice smol nic i can use as an example for the pcie card
<azonenberg>
e.g. the fact that we're about to move channels to be std::shared_ptr's and completely redoing the ownership model
<azonenberg>
pirate: perfect thats exactly what i was thinking
<azonenberg>
chibify it a bit and try to fit into a roughly square aspect ratio in the left half of the icon space
<pirate>
need to figure out how to include a shark icon
<azonenberg>
for what, pcap import?
<azonenberg>
(and soon pcap export, there's some bitrotted code around that which i need to resurrect)
<azonenberg>
I will laugh hard if our wireshark integrations use an icon that looks like a blahaj
<azonenberg>
(and promptly merge it)
<pirate>
!
cyrozap_ has joined #scopehal
<d1b2>
<chille0417> And the CANbus icon should be a car, lol.
<azonenberg>
He doesn't normally live in here though, for ESD reasons. I was actually talking to a friend a while back, you can get blue-gray ESD fabric meant for cleanroom gowns and stuff
<azonenberg>
i dont think it would be *that* difficult for a skilled fabric arts person to make an esd-safe blahaj. it would be silky smooth carbon-doped polyester, not plush, but hey :p
<d1b2>
<chille0417> Are you using double sided tape to anchor the fasteeners for the cables? Or do you have magnets or something?
<d1b2>
<azonenberg> Both
<d1b2>
<azonenberg> The cross shaped white things are attached to magnetic disks. The tabletop is actually steel, but given the standoff distance through the ESD mat they don't stick securely enough
<d1b2>
<azonenberg> so i taped the little metal plates on so they'd stick better
<d1b2>
<azonenberg> I also have some recloseable zip tie type fasteners that are attached by double sided tape directly to the mat
<d1b2>
<chille0417> Ah, okay. Does the PCBite PCB holders work through the ESD mat? I was thinking about placing a sheet of steel under mine.
<d1b2>
<azonenberg> then the orbtraces are attached by tape, and the green board by the microscope is using the PCBite holders directly to the tabletop through the mat (no extra steel plate)
<d1b2>
<azonenberg> the pcbite magnets are bigger and stronger than the ones on the little cross cable holders
<d1b2>
<azonenberg> so they have adequate holding force despite the mat
<d1b2>
<azonenberg> Definitely not nearly as strong as right onto a steel plate, but adequate retention for my purposes
<d1b2>
<azonenberg> So yeah i use all three options (magnet through mat, magnet to metal plate taped to mat, tape onto mat) depending on the specific thing i'm holding and how often i need to reposition it etc
<d1b2>
<azonenberg> Some of my prototypes get magnetic standoffs in the corners which i then stick to magnetic plates on the mat
<d1b2>
<azonenberg> so the board stays put then i can pick it up to do rework and snap it back down
<d1b2>
<chille0417> For the past 15 years I've been thinking about making "trays" in steel with ESD mat. In that way I could attach things with magnets to the tray and then put them away in a rack when I need the table space. Then I can have a rack of 50 trays with 45 of them being there for over a year and in unknown condition, lol.
<d1b2>
<azonenberg> I've heard of people trying that concept. not sure how well it worked out. some folks were looking at using commercial cookie sheets and bakery racks
<d1b2>
<azonenberg> My lab is set up with ESD plastic shelf bins that i have covering most spaces that aren't used for something else, and i use those for not-active project storage, component inventory, etc
<d1b2>
<azonenberg> while trying to reserve bench space for things that are powered up and in active use
<d1b2>
<chille0417> What does this "spaces that aren't used for something else" mean? I never heard of such a thing before. I have started mounting things in the ceiling and storing stuff in my bedroom lol.
<d1b2>
<azonenberg> ah, a fellow member of the submarine school of interior design
<d1b2>
<azonenberg> that's pretty much my setup. when i set up the lab i taped out 3-foot-wide aisles for walking through
<d1b2>
<azonenberg> and have storage or equipment basically floor to ceiling on most of the remaining space
<d1b2>
<azonenberg> If i ever had space that wasn't being usd i usually mounted a rack to it and hung storage bins from the rack
<d1b2>
<chille0417> Yeah, thats what I have right now. I have been thinking about getting a bigger place. But it kind of nice to have the workshop in same building as I live in and not need to drive anywhere. But I should probably rent a werehouse somewhere nearby and store stuff that I don't use regularly.
<d1b2>
<azonenberg> (which reminds me there are about two square feet of wall space above the ultrasonic cleaner and below the HVAC unit that i should probably put a cabinet or bin rack on)
<d1b2>
<azonenberg> lol
<pirate>
azonenberg: how hard is it for you to generate that image w all the current filter icons?
<d1b2>
<azonenberg> Trivial, although i have to be at my desk rather than in the lab
<d1b2>
<azonenberg> (i need a 4k display to fit them all)
<azonenberg>
pirate: with 1080p you can only see about half to 2/3 at once
<pirate>
ah
<azonenberg>
it's just the standard "filter palette" dialog that's normally docked on the right side of the filter graph maximized to fill the whole window
<d1b2>
<chille0417> Btw, that Hantek 365B have almost as good frontend as you can expect for a <100€ USB multimeter. When it's unconnected the voltage initially increases about 4mV/minute. Now after ~5 hours I'm up tp 372 mV. It goes down to ~0mV if I short the inputs. Too bad there is nothing in between super cheap and super expensive. We need an open source DMM!
<d1b2>
<azonenberg> Lol. Be careful who you ask...
* azonenberg
pictures you asking in the xdevs channel
<azonenberg>
and a few years later somebody comes out with a $20K open hardware multimeter with eight significant digits
<azonenberg>
with each unit calibrated directly by nist's JVS
<d1b2>
<chille0417> Haha
<azonenberg>
actually 20k would probably be a bargain for a 3458a competitor
<d1b2>
<macaba> I know someone working on exactly that…
<azonenberg>
Lol. i mean, i'm sure everyone at xdevs would be all over that
<d1b2>
<azonenberg> I took these pics at Ilya's lab when i visited a couple years ago
<azonenberg>
So if anybody seriously wants to work on an open source meter with that level of accuracy, they should get in touch with him WRT calibration and accuracy measurements etc
<d1b2>
<chille0417> Okay, I'm going to close my eyes now. Can someone ping me when @azonenberg is done posting pictures and they are way back in the history?
<d1b2>
<macaba> Too many digits of resolution?
<azonenberg>
lol
<d1b2>
<duskwuff> "A man with a watch knows what time it is. A man with two watches is never sure."
<azonenberg>
And a man with three 3458A's can probably put a three-sigma bound on the uncertainty :p
<azonenberg>
anyway yeah ilya would be my go-to if i ever needed to make high precision DC measurements, that's kinda his thing
<azonenberg>
My 5 3/4 digit meters are more than enough for my use cases
<d1b2>
<macaba> IMO, the biggest issue is safety, and the corresponding CAT rating. An open source DMM design is problematic here, in both design validation (which is surmountable) and build validation & test (impossible).
<azonenberg>
It depends on what you're using it for. Not everything needs to be usable for line voltages
<azonenberg>
like, an open hardware DMM that's only rated for SELV applications would still be extremely useful to me if i had sufficient accuracy
<d1b2>
<macaba> It needs to survive line voltage, and not injure users.
<azonenberg>
That's my point though. Not everything needs to be designed to be usable for line voltage. especially if a bench rather than handheld form factor
<azonenberg>
i guarantee the saleae won't like mains on the inputs for example
<d1b2>
<chille0417> I agree to that. It would be even worse if someone decides to build one themself, instead of buying a pre built one.
<d1b2>
<macaba> It’s mandatory otherwise it’s not a DMM, it’s just a national instruments DAQ device.
<d1b2>
<macaba> Nobody buys a DMM expecting it to fail if connected to 240V
<d1b2>
<chille0417> Well, I just bought a bunch of 4mm lab cables from china. So I'm probably going to die anyway. 🙃
<azonenberg>
i would not expect a harbor freight dmm to be safe to use for 240v no matter how it's rated :p
<d1b2>
<duskwuff> And I'd argue in particular that you're probably not going to want to hook line voltage up to your 8.5-digit meter, whether it's supposed to be able to handle that or not
<azonenberg>
anyway, realistically i would be very happy with an open hardware meter that had high accuracy and was specced for say +/- 30V CAT 1 only
<d1b2>
<macaba> It’s very common to hook line voltage to 8.5d DMMs 😅
<d1b2>
<chille0417> I had a cheap multimeter where both tips of the probes exploded and completely disappeared. There was like 5cm of a PCB trace missing when I opened the multimeter. I would prefer to not do that again.
<d1b2>
<macaba> This is just a DAQ device though.
<azonenberg>
actually, what I *really* want is a high precision open hardware SMU
<azonenberg>
i.e. a full 4 quadrant device
<d1b2>
<macaba> That’s on my bench at the moment but suffers even worse from the open source user safety conundrum
<azonenberg>
to which i would again say, i'd be fine with one that could handle a few tens of volts. if it does 48V that would be optimal
<azonenberg>
but other than my 48V IBC everything i do would be happy with +/- 12 operating range
<d1b2>
<macaba> Not only does it need to survive things, it needs a hardware safety interlock connector for sourcing modes
<azonenberg>
(I design my bigger projects to run on 48V specifically so i don't have to have mains anywhere on my bench0
<azonenberg>
I'd be fine with softer interlocks if it can't generate anything above SELV either
<azonenberg>
If i am actually planning to probe mains, i'm using my Fluke
<d1b2>
<chille0417> I would prefer to at least have as high voltage rating as you could work with without being dangerous. When I went to school they told me that there is not a single documented death with a voltage less than 100V, except for a few really stupid cases.
<azonenberg>
Yeah. The exact definition of "touch safe" varies by jurisdiction and SOPs etc
<azonenberg>
In my lab, 48V is the most i'm willing to have open unprotected on a bench, and i usually still cover the 48V terminals if i plan to be working in close proximity
<azonenberg>
more for equipment safety than my own though
<d1b2>
<azonenberg> Tangentially related: have you seen any of my discussion of the high bit depth scope i wanted to build eventually?
<d1b2>
<macaba> Good for you, you are missing the point entirely. An open source design should be safe for all users, not the ones with brain cells
<d1b2>
<azonenberg> There's always a higher voltage
<d1b2>
<azonenberg> you can't make a meter with an infinite CAT 1 rating
<d1b2>
<azonenberg> somebody will try to probe a MOT or neon sign transformer with it eventually
<d1b2>
<azonenberg> If i wanted to provide mains tolerance for safety in a worst case scenario i'd probably put an in-line fuse with like an 80V zener clamp or something
<d1b2>
<azonenberg> that would blow the fuse and isolate the input if you ever fed too much voltage to the input
<d1b2>
<miek__> i'm not sure that this is necessarily bad, i see similar behaviour on my keithley and agilent bench DMMs. my assumption is that their input impedance is so high that they're not draining away any stray charge that builds up on the terminals
<d1b2>
<chille0417> If I remember correctly there is at least one person that have died by using a DMM or a similar device. I think he did something stupid like sticking the probes under his skin and then probably set it to like a low impedance continous testing or maybe an isolation testing mode.
<d1b2>
<josHua> only render a badge if there's enough space for it! shorten it, if there's a reasonable shortening, otherwise, don't render it at all.
<d1b2>
<azonenberg> i mean my fluke 1503 has 1 kV output in insulation test mode
<d1b2>
<azonenberg> you could absolutely electrocute yourself with that
<d1b2>
<david.rysk> Well the other issue is use for line voltage AC without proper CAT rating and proper precautions
<d1b2>
<azonenberg> Exactly. If you clearly label the meter as no CAT rating and 30V max or similar, you can't stop someone from using it outside the ratings
<d1b2>
<chille0417> Maybe not. I have not seen this behavior before. But my experience from any DMM > 300€ is basically zero. It's not really a problem, becuase If I connect it to something I get a stable reading within a second. I'm thinking about adding a 1Mohm resistor in parallell and see what happens.
<d1b2>
<azonenberg> oooh looking good. I definitely do like coloring the channel names
<d1b2>
<josHua> I have fixed the alignment since, as well
<d1b2>
<chille0417> Can you really? I always thought the current was limited to something safe. But I have not tried touching the outputs while using my isolation tester. However I have learnt the hard way that cables can act as an capacitor and store some of the energy, haha.
<d1b2>
<josHua> the code should make it easy to add other colored 'badges', including a downloading progress bar 'badge'
<d1b2>
<azonenberg> Yeah that's exactly what i meant. The current is limited, but to "won't start a fire" levels
<d1b2>
<azonenberg> not "won't zap you" levels
<d1b2>
<azonenberg> adding in cable capacitance and i'm sure there are ways to get a dangerous shock from it
<d1b2>
<azonenberg> is it likely to kill you? probably not. but it's absolutely at a level that could
<d1b2>
<azonenberg> idk what yours puts out but mine does 1 kV on the highest setting
<d1b2>
<azonenberg> Yeah i like the concept, its ust a question of not making it too busy. Deciding which stuff to show and which not will take care
<d1b2>
<miek__> sounds like a good plan. for what it's worth, on mine it doesn't do it when set to 10 Mohm mode, but in Hi-Z mode (> 10 Gohm) it's counting at maybe -100 mV per second
<d1b2>
<azonenberg> @josHua in parallel with the other stuff i think i'm gonna work on defining "waveform download progress" APIs at some point
<d1b2>
<chille0417> Yes, mine does 1000V as well. I have never seen anyone doing isolation tester with anything else, even is there is lower voltage settings.
<d1b2>
<david.rysk> 5kV is common. 25kV and 100 exist but are less common
<d1b2>
<johnsel> Did you check performance of cairo vs the new library?
<d1b2>
<david.rysk> The performance isn’t critical once we optimized for redraw
<d1b2>
<david.rysk> At the moment, the concern is accuracy
<d1b2>
<david.rysk> But the existing implementation is not necessarily tested either
<d1b2>
<johnsel> well, it certainly was several orders of magnitude faster
<d1b2>
<david.rysk> Yeah but the only item in the hot path is the eye mask calculation not the render itself
<d1b2>
<johnsel> not sure, all I know is the same setup ran <fps with new the new lib and 40-60fps with the old lib
<d1b2>
<johnsel> I saw a lot of time being put into constructing the context every frame but still
<d1b2>
<johnsel> I think the short answer then is, no clue?
<d1b2>
<johnsel> is it merged yet?
<d1b2>
<johnsel> I can take a look at least @david.rysk
<d1b2>
<david.rysk> Yeah I optimized this out, see my draft pr
<d1b2>
<david.rysk> Not yet because @azonenberg is busy
<d1b2>
<johnsel> PR, that's fine
<d1b2>
<johnsel> I can check that out too
<d1b2>
<yeskinger> They do have a C SDK. I'm just wondering how the specs look compared to the price.
<d1b2>
<johnsel> but I have to work first
<d1b2>
<johnsel> sets timer to go off in 8 hours
<d1b2>
<johnsel> ehh, 4 hours
<d1b2>
<johnsel> it'll be my break time activity
<d1b2>
<johnsel> stretch my legs a little using ngscopeclient
<d1b2>
<david.rysk> It’s fast but gives different results than upstream
<d1b2>
<johnsel> that's how that works right?
<d1b2>
<david.rysk> But we have no idea if upstream is correct
<d1b2>
<johnsel> yeah I saw some weird stuff with the window size affecting things too
<d1b2>
<johnsel> could be (nvisible) bordering and the like)
<d1b2>
<chille0417> I don't think so. What bit depth are you aiming for?
<d1b2>
<johnsel> but if what you're saying is I'd know if it's correct before we spend time on performance
<d1b2>
<johnsel> I can look at that too
<d1b2>
<johnsel> @david.rysk just have to tell me what to do
<d1b2>
<johnsel> I'll only have 15 mins or so though
<d1b2>
<david.rysk> Just compile and try it
<d1b2>
<david.rysk> As usual
<d1b2>
<azonenberg> I plan to write a test case with synthetic data that generates known mask hit rates
<d1b2>
<azonenberg> then evaluate the existing and new implementations against it
<d1b2>
<chille0417> @azonenberg Btw, do you have any preferences on about what USB library do use in scopehal? I can't see any being included now. I'm on Linux and it seems that libusb is the most common library. It does also seem to be cross platform.
<d1b2>
<azonenberg> But with family in town this weekend it may be a few days before i get to that
<d1b2>
<azonenberg> So generally speaking, what we've done to date has not been "raw" USB but working with vendor SDKs for USB scopes like Pico and Digilent
<d1b2>
<azonenberg> For these, we've normally made a bridge server that provides network transparency and a license / API boundary layer
<d1b2>
<chille0417> Hmm... okay
<d1b2>
<azonenberg> in particular, we want to keep ngscopeclient and libscopehal generic and compatible with all scopes, but not force you to install the pico SDK if you don't have a picoscope
<d1b2>
<azonenberg> so the conecpt was, the client side part of the driver is always there
<d1b2>
<azonenberg> and the server side part (scopehal-pico-bridge for example) would be installed on an as needed basis
<d1b2>
<chille0417> The problem is when you look at all the low end stuff there is no vendor supported SDK.
<d1b2>
<azonenberg> For scopes that have an open, documented USB interface, it's plausible to do raw libusb accesses. the tradeoff is that you still lose network transparency
<d1b2>
<azonenberg> (or a reverse engineered usb interface)
<d1b2>
<david.rysk> Some have an RE’d sdk / interface
<d1b2>
<azonenberg> so my inclination would still be to make a bridge server because remoting is such a key component of the feature set, at least for me
<d1b2>
<azonenberg> like, probably 80-90% of the time i'm using my picoscope it's not from the computer it's plugged into
<d1b2>
<chille0417> Yeah, I agree that remoting is a nice feature. Havn't even thought about that. Then maybe a better option would be to just make a completely stand alone application that bridges between the device and an SCPI interface.
<d1b2>
<azonenberg> Correct. That's what we do for picoscopes and the analog discovery now
<d1b2>
<chille0417> I'm a bit sceptical to solutions like that, but you usually ending up having 20 different applications that needs to communicate. But as long as everything is well documented and packaged correctly it really shouldn't be a problem.
<d1b2>
<azonenberg> the de facto standard for this is a RemoteBridgeOscilloscope-derived client driver
<d1b2>
<azonenberg> and a server using scpi-server-tools
<d1b2>
<azonenberg> we use the "twinlan" transport on a pair of adjacent tcp ports
<d1b2>
<azonenberg> one for scpi control plane, the other for raw binary waveform data
<d1b2>
<chille0417> Would the winlan transport still be used for something that does not need transfer of raw binary data, like a DMM or a PSU?
<d1b2>
<azonenberg> No. That could use the lan transport and just be a single scpi server
<d1b2>
<azonenberg> the point of twinlan is to allow a push based protocol
<d1b2>
<chille0417> Ah, okay.
<d1b2>
<azonenberg> where the scope pushes a waveform to you as soon as it triggers, without any polling, and immediately re-arms the trigger
<d1b2>
<azonenberg> this avoids excessive network round trips and especially when using the scope over wifi or a VPN massively improves performance
<d1b2>
<azonenberg> My benchmark for this was using a Lecroy WaveRunner and a PicoScope 6000 series
<d1b2>
<azonenberg> while physically at LeCroy's offices in New York, with both scopes in my lab near Seattle
<d1b2>
<azonenberg> over an LTE VPN
<d1b2>
<azonenberg> The WaveRunner was pushing maybe 1 WFM/s while the PicoScope was pushing 60 at the same (shallow) memory depth
<d1b2>
<azonenberg> bottlenecked on latency
<d1b2>
<azonenberg> (the waverunner using lecroy's native scpi protocol, the picoscope using our twinlan bridge)
<d1b2>
<chille0417> So how would something like a DMM send data to ngscopeclient? Will ngscopeclient poll it or should the polling be handled in the bridge and then sent to ngscopeclient?
<d1b2>
<azonenberg> Meters update slow enough polling is probably fine
<d1b2>
<azonenberg> you're probably not going to care about getting tens or hundreds of updates a second off the meter right?
<dingwat>
i paid for 100 sps and by god I'm gonna use all of them
<d1b2>
<chille0417> Well, the 365B only gives like 2 readings per second or something. The problem is it does seem to act weird if the next polling is too close to a result being returned. So some kind of rate limiting needs to be done in the bridge I think.
<dingwat>
the 34470A can apparently do 50k rdgs/s, dunno wtf you'd do with that but it's funny
<d1b2>
<chille0417> I think 50k could be useful. You should be able to catch a glitch that is only there for a short while. Somewhat like an oscilloscope. Or maybe you can get a feeling for how much noise there is on a DC bus.
<dingwat>
yeah, that makes sense. kinda in the weird in-between realm of scope and DMM
<d1b2>
<azonenberg> For faster instruments, yeah we might start having it act more like a scope
<d1b2>
<azonenberg> It's a bit of a gray area
<d1b2>
<azonenberg> Perhaps the best option there is to have the bridge always poll at 2 Hz
<d1b2>
<azonenberg> then have the query-latest-reading command from the client just return the most recent result?
<d1b2>
<chille0417> Yeah, that sounds like a good plan.
<dingwat>
especially with the more capable meters having more sophisticated triggers. I imagine there's also some weird gray area stuff with respect to DAQs, high channel count, high bit depth, "middlin" sample rates
<azonenberg>
Yes, there is
<azonenberg>
I have an instrument on the drawing board now that will be 16-28 channels
<azonenberg>
with 16 bit depth
<azonenberg>
100 Msps or so
<d1b2>
<chille0417> I would love to have a DMM with a build in scope that actually uses the analog frontend of the multimeter. I would be fine with 1 MSPS. Now I have a handheld combined scope and DMM, but to use the scope I need to connect a passive probe via a BNC connector. Like 99% of the times I use a scope it is to something really low frequency like checking SPI, I2C, PWM or noise on a power rail.
<azonenberg>
the goal there is something you can use to look at power rails and simultaneously see ripple and ramp rate and timing behavior
<azonenberg>
imagine being able to look at a dozen power rails on some complex mixed signal device
<azonenberg>
and simultaneously see each one ramping up from off to nominal operating voltage
<d1b2>
<chille0417> @azonenberg go build it!
<azonenberg>
load transients, overshoot, smps ripple, highish frequency noise
<azonenberg>
all at once
<azonenberg>
It's next on my list of instruments to build after the bert and trigger crossbar
<azonenberg>
i need to get the crossbar finished and racked then start psuhing hard on the bert which is the first one i plan to make in any kind of quantity
<azonenberg>
this is the next in the line after that
<dingwat>
chille0417, isn't 1Msps far too slow for those things you mentioned though?
<dingwat>
azonenberg: this design I'm working on now has at least 23 rails :( definitely would be cool to have something like that for power sequence quals
<azonenberg>
dingwat: yep that is the exact use case
<azonenberg>
i want to validate sequencing, turn-on and turn-off transients, load transients, and ripple all at once
<d1b2>
<chille0417> For decoding actual data, then yes, a bit more would probably be required. But I use it mostly to troubleshoot and it would be nice to be able to see if there is digital data on an unkown line. I want more like a DMM that I could put on a random terminal and it can tell me "this looks like a PWM signal". Now I have to do multiple separate measurements.
<azonenberg>
it wont see the multi hundred MHz ripple
<azonenberg>
but it'll be good enough for a lot of applications
<azonenberg>
the upper end i'm looking at is 28 rails potentially for the design
<azonenberg>
(7x ad9656)
<dingwat>
chille0417, hmm ok
<dingwat>
jesus those ain't cheap
<azonenberg>
dingwat: we're talkign a 28 channel scope lol
<azonenberg>
its gonna be expensive
<azonenberg>
with *16 bit* vertical resolution
<dingwat>
true true
<azonenberg>
the frontend for that kind of dynamic range is going to be an adventure
<dingwat>
do you have a target for max input voltage?
<azonenberg>
12 minimum, ideally 48. tentative plan is to just have a mechanical step attenuator in the frontend
<azonenberg>
highest dynamic range would be like <5V full scale or something meant for looking at typical digital vcore rails with sub millivolt resolution
<d1b2>
<chille0417> I like the idea of having a lot of input channels. I would probably be happy with a few MSPS and a something like 10 channels.
<azonenberg>
This would be scalable
<azonenberg>
you'd have the main FPGA board and cabled modules each containing an ADC and four socketed frontends
<azonenberg>
with a refclk, some slow control GPIOs, a trigger signal. and a JESD204 lane from the adc board to the fpga board
<azonenberg>
So you could buy a cheap base unit with only four channels initially and scale up to 28
<azonenberg>
replace frontends yourself if you blow one
<azonenberg>
etc
<dingwat>
Seems pretty reasonable
<azonenberg>
Overall format would be 1U rackmount with SMAs all over the front panel for probe inputs (smaller than BNCs)
<dingwat>
chille0417, have you used a Saleae Logic Pro? It will do 50Msps analog, input voltage isn't stellar but it can be pretty awesome for debugging
<azonenberg>
back side would have 48V DC power in, SMA 10 MHz ext ref in, SMA trig in, SMA trig out, rs232 debug console, 1000baseT RJ45 as fallback for people without fiber, and 10G SFP+ or 25G SFP28 as the main data uplink
<d1b2>
<chille0417> I have a product right now where I have to do measurements on a real device as it is almost impossible to simulate. First I bought a whole bunch of Fluke 101 multimeters. Then I figure out those couldn't mesure current. Then I bought a Bus Pirate and was going to build some measurement jig, but the Bus Pirate din't give me the voltage with more than one decimal. Now I have a crappy USB DMM that I could hopefully buy a whole bunch of if they
<d1b2>
end up working nice.
<azonenberg>
And probably a LRDIMM of DDR4 for capture memory buffer or something
<dingwat>
gigabit ethernet as a fallback for the poors lmaooo
<azonenberg>
Its cheap to throw on there for use during dev or something
<azonenberg>
but the intent is for the SFP to be the main pc interface
<dingwat>
chille0417, the Saleae's have 5MHz analog BW and +/-10Vin. Input impedance isn't great if you're measuring sensitive analog stuff but for looking at dumb analog problems on digital interfaces (e.g. I2C level shifters being shit), it's great
<d1b2>
<chille0417> I have looked at them. But they still kind of expensive compared to the cheaper options. But it would probably do the things I need directly, instead of buying tons of other gear and figure out i wont to what i need lol.
<dingwat>
definitely a little expensive, but the software is nice (you can write your own analyzers very easily) and going to a DAQ or something similar is gonna be a lot more expensive
<dingwat>
Kinda wish dreamsourcelab would make something to compete, their logic analyzers are fine but they don't do analog, and their scope is only 2ch
<dingwat>
DSLogic probe design is miles ahead of Saleae though
<d1b2>
<chille0417> The Saleae Logic 8 isn't that expensive actually.
<dingwat>
If you can stomach it, the upgrade to the Pro 8 is well worth it IMO, significantly more BW both analog and digital
<dingwat>
there's a logic pro 8 on eBay for 675 O.O tempting
<dingwat>
I promised myself I will not buy any more test equipment this year...
<d1b2>
<chille0417> Haha
<azonenberg>
Lol. I have a long wishlist, which greatly exceeds my budget
<azonenberg>
One of the things i really want to get soon is a mechanical polisher though
<dingwat>
spent $45 on a set of Tek probes this morning, but that surely doesn't count
<azonenberg>
Buehler has a really cool one that has like a 3 inch wheel or something like that
<azonenberg>
its so smol and cute
<dingwat>
ah so not like the thing that you buff your car with
<d1b2>
<chille0417> And I promised myselft I will write software to try get the most out of the equipment I already have. The only things I would like to buy is a few more USB DMM's and a ThunderScope.
<azonenberg>
pirate: skimming your draft PR, feedback so far
<azonenberg>
the convention for direction arrows is always to point down and right
<azonenberg>
so for export don't make the arrow point left, put the shork on the right side of the image and point at it
<azonenberg>
the "gate" i have to think about, since the point of that filter is to be like a clock gate specifically
<d1b2>
<chille0417> My wishlist is also a bit problematic. In another way... I have the money, but I can't find the equipment I want.
<azonenberg>
for pcie data link, since it's a differential serial signal i dont think the parallel bus depiction next to the card is good
<azonenberg>
how about having it be a single abstract "bus activity" depiction like you see in timing diagrams?
<d1b2>
<chille0417> Btw, do anyone have some good resources about SCPI that could be useful when writing a SCPI bridge for scopehal? I could of course just google some random guide. But as I have to implement both the server and the client it's easy to mess things up and not follow best practices, even if the communication between the server and client works perfectly. I would assume that most guides online will only focus on how to communicate with a device
<d1b2>
<chille0417> Well, okay, that was too easy, haha.
<azonenberg>
its almost like i've been so cranky at instrument vendors doing stupid things that i had to write up a list of all the things not to do
<azonenberg>
in hopes of getting some of them to pay attention :p
<d1b2>
<chille0417> Maybe the GitHub Wiki should be linked from ngscopelient.com
<azonenberg>
There isnt much on the GH wiki at the moment
<azonenberg>
it's more been a place to throw random notes that didnt go anywhere else
<azonenberg>
long term i want everything on the website
<azonenberg>
(also its .org not .com)
<d1b2>
<chille0417> Ah, okau.
<d1b2>
<chille0417> I have thouht about writing a similar guide for DMX512. The original standard is from 1990, and still the biggest manufacturers make crappy equipment that does not properly implement the protocol.
<d1b2>
<chille0417> (And I have also thought about writing a DMX decoder for ngscopeclient.... some day...)
<dingwat>
while you're at it, you should design DMX2.0 because DMX sucks but also I don't want to have to use Artnet ;)
<d1b2>
<chille0417> I agree, DMX sucks. Bit it would at least suck a little bit less if receivers would actually check the start code and discard data they do not understand. And it would suck a lot less if everything had a working RDM implementation.
<dingwat>
this is true
<d1b2>
<chille0417> I also prefer to not use ArtNet. sACN is usually a better option to send DMX data over ethernet.
<dingwat>
DMX is a great example of how designing a protocol and going "well, 512 light fixtures is an insane number of light fixtures, that's plenty good" is maybe not the most future-looking attitude
<dingwat>
because now we have fixtures that take up huge chunks of that 512, and suddenly you need a shitton of universes to do anything cool
<d1b2>
<chille0417> And another update that would make DMX suck even less was if we could get a synchronized frame rate over all devices. A DMX output should set the framerate, and then everything should process the data in that speed and not resample the data. The audio guys learnt to not resample data in bad ways over 50 years ago. The lighting guys have not even understood the problem yet.
<dingwat>
yarp
<d1b2>
<chille0417> But to be honest I think DMX is a thousand times better than some of the new fancy equipment with ethernet ports. Some equipment from Elation have ethernet implementation that are even worse than how bad it would even be possible to fuck it up on a regular DMX line.
<d1b2>
<azonenberg> @fredzo_72653 what was wrong with the UART code we had using xptools to do uart on windows?
<d1b2>
<azonenberg> i thought uart already worked on windows?
<d1b2>
<azonenberg> IMO if the existing uart code is broken on windows, we shoiuld fix that. Not add an additional dependency on libserialport that we don't already have
<d1b2>
<fredzo_72653> Mmmhh unless I missed something there was not: the code was like : //TODO implement this on Windows m_fd = INVALID_HANDLE_VALUE; LogError("Windows UART stuff not implemented");
<d1b2>
<azonenberg> ah ok it does look incomplete. My point stands though, this is simple enough i'd rather not pull in an external dependency if we can avoid it
<d1b2>
<azonenberg> windows has halfway decent native serial APIs
<d1b2>
<azonenberg> (and i think the linux versions should work on macos but aren't tested there afaik)
<d1b2>
<azonenberg> @david.rysk since you seem to be looking at windows packaging somewhat, thoughts?
<d1b2>
<david.rysk> I’ll take a look at it
<d1b2>
<azonenberg> related: we do not currently have any usbtmc support on windows either
<azonenberg>
But i dont know what the state of OS driver support there is