<azonenberg>
yeah a proper install process for both windows and linux is still pending
<azonenberg>
if you wanna send a pr for scopehal-docs with these fixes that will be much appreciated
<d1b2>
<Attie> sure
<azonenberg>
the reason it doesnt say to use cmake for install is that "make install" probably does nothing
<azonenberg>
there is no cmake config for installation yet :p
<azonenberg>
bird|otherbox and kenley were going to work on that at some point
<d1b2>
<Attie> ah, np
<azonenberg>
attie: i'll merge your PR if you change the default to 80 column, 50 is a bit small
<azonenberg>
and 80 seems to be the universal default
<d1b2>
<Attie> sure - i actually put 80 first
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JkOiu
<_whitenotifier-f>
[scopehal] azonenberg 292d200 - Updated to latest logtools
<azonenberg>
we can work on a more fundamental fix for the problem later
<_whitenotifier-f>
[scopehal-docs] attie opened pull request #20: Update Windows install notes - https://git.io/JkOi2
<d1b2>
<Attie> yeah, i'm not actually sure what to do about that one - the handle returned by GetStdHandle(STD_OUTPUT_HANDLE) appears to be valid...
<d1b2>
<Attie> (which contradicts the error from GetConsoleScreenBufferInfo())
<azonenberg>
It might be a valid handle that's not readable or something
<azonenberg>
Try STD_INPUT_HANDLE
<azonenberg>
it's possible STD_OUTPUT_HANDLE is write only under mingw and doesnt have GENERIC_READ which is needed for GetConsoleScreenBufferInfo to work?
<azonenberg>
this will act funny if you pipe input from a file
<azonenberg>
so i think if that does work the proper course of action is to try STD_OUTPUT_HANDLE first
<azonenberg>
which should work on a standard windows terminal
<azonenberg>
if it fails, try STD_INPUT_HANDLE
<azonenberg>
and if that fails, then fall back to the 80 col default
<azonenberg>
See if STD_INPUT_HANDLE works under mingw
<d1b2>
<Attie> no joy - i updated the ticket
<d1b2>
<Attie> re the triggering buttons - i presume that start will do a single trigger, download the waveform(s), and then re-arm... while the single will not re-arm
<d1b2>
<Attie> (i.e: they both use single trigger on the scope)
<azonenberg>
Correct
<d1b2>
<Attie> cool, thanks
<azonenberg>
Actual "normal trigger" can't be used because there's no handshaking to ensure multiple channels are properly synchronized
<d1b2>
<Attie> just getting something to poke at
<azonenberg>
this is something i want to fix when i build my custom hardware
<azonenberg>
when my scope triggers i want it to immediately *push* a waveform to the socket
<d1b2>
<Attie> i presume also that you can't get the acquisition memory before it re-arms?
<azonenberg>
then, in normal mode, re-arm the trigger
<d1b2>
<Attie> ah i see, sounds good!
<azonenberg>
Most current scopes just have a command to download the current waveform from a specific channel
<azonenberg>
you have to poll until it triggers then download each channel one at a time
<d1b2>
<Attie> ahh ok, that was the missing info 🙂
<azonenberg>
in normal-trigger mode, there's a good chance it's re-armed and re-triggered at least once during that process
<d1b2>
<Attie> yip
<azonenberg>
Which is why for my scopes i plan to have two sockets
<azonenberg>
one control plane SCPI socket for setting gain/offset and configuring stuff
<azonenberg>
then a data plane binary socket that, upon triggering, pushes a waveform for every enabled channel to you
<azonenberg>
and if requested re-arms immediately
<azonenberg>
this will perform far better since it doesnt need a bazillion round trips to the scope polling stuff
<d1b2>
<Attie> sounds good
<azonenberg>
But AFAIK no commercial instrument is designed this way
<azonenberg>
So are you getting proper behavior now? in terms of getting valid waveforms off the scope that look correct, all ui features doing what you expect, etc?
<d1b2>
<Attie> looks like i need to make a decoder
<d1b2>
<Attie> (:
<d1b2>
<Attie> it's much more performant than i was expecting too - i was fully expecing the scope to take a second or two on each capture to transfer data
<azonenberg>
how fast is it actually running? and yeah 1-2 sec per capture is what we see from e.g. cheap rigols
<d1b2>
<Attie> i'm getting perhaps 3-4 Hz
<azonenberg>
my lecroys will do high tens of wfm/s at shallower memory depths
<azonenberg>
although obviously it drops off if you have say 4 channels * 20M points
<d1b2>
<Attie> yeah - this is two channels... i don't have control of sample depth so it'll be the full depth no matter what
<azonenberg>
the memory depth settings dont work in scopehal? or what
<d1b2>
<Attie> oh, possibly... i know it's not an option from the scope itself
<azonenberg>
(i dont know the state of the agilent driver, i havent touched it - i think that was miek's code mostly)
<azonenberg>
normally the way i do things in scopehal is that you set the sample rate and memory depth and it adjusts the time/div on the scope to match
<d1b2>
<Attie> should i see it here? (i double clicked the channel's label)
<azonenberg>
but in glscopeclient you can have arbitrarily many views of a waveform at different zooms so it doesnt make sense to lock them to acquisition depth
<azonenberg>
double click the timeline up top
<d1b2>
<Attie> ahh ok - those dropdown's are empty
<azonenberg>
also opened a ticket for your fpd-link decode
<d1b2>
<Attie> i see, thanks!
<d1b2>
<Attie> i need to have a rummage and figure out what's what first
<d1b2>
<Attie> but i'd really like to get that running
<azonenberg>
Well, i'll take a PR whenever you want. Do you have any thoughts on what the interface to the decode is going to look like yet?
<d1b2>
<Attie> the MIPI->LVDS bridge i'm on/off working with is behaving strangely
<azonenberg>
generally before i write any code i think about what the inputs are, what the outputs are, what datatypes things are
<azonenberg>
what configuration options i have, what is required and what's optional
<d1b2>
<Attie> i have ideas - i'd certainly like to be able to decode Clk and one Data signal - i.e: lane 2 has the syncs
<azonenberg>
for example, fpd-link is normally 3 data lanes plus clock right?
<azonenberg>
Yeah exactly
<d1b2>
<Attie> this is actually dual link, and 4 lanes on each... + clock
<azonenberg>
That's an example of what i meant. What might make sense would be to do it as a multi-layered decode similar to how i did mipi
<d1b2>
<Attie> yeah - exactly something i was going to look at
<azonenberg>
the first decode will take one data stream and clock, then you'd have a second upper layer one that takes several data streams
<azonenberg>
you can even go lower level than that, for example in the case of MIPI I have a decode for D-PHY that takes a mandatory + input and an optional - input
<azonenberg>
Since some of the low speed signaling can't be decoded without both halves
<azonenberg>
but you can decode HS mode data, plus enough of the start/stop sequences to get the job done, with only one
<d1b2>
<Attie> sounds good - FPD doesn't require both, so i guess a single-ended input and fall back on math if you want differential?
<azonenberg>
Yeah that would make sense. The only reason you'd want to take both halves to a single decode, other than the subtract math function, is for something like usb that isn't truly differential
<azonenberg>
or mipi
<azonenberg>
i.e. where a single ended 0/1 state is valid
<d1b2>
<Attie> yeah
<azonenberg>
At a high level, a decode, math function, etc is all a class derived from Filter, it would live in libscopeprotocols
<azonenberg>
call AddDecoderClass) in scopeprotocols.cpp!ScopeProtocolStaticInit to register the filter so the GUI and file i/o code know where to find it
<azonenberg>
within the filter class the main interesting functions are ValidateChannel(), which determines whether an input is legal (this is used by the GUI to filter inputs in the decode dialog, and gray out filters from the context menu that the selected trace isn't legal for)
<azonenberg>
GetProtocolName() which returns a string name for it (must be unique, used as an identified at various points)
<azonenberg>
SetDefaultName() picks a name for the decode if the user didn't specify one
<azonenberg>
IsOverlay() returns true to display the decode on top of the parent trace and false to display in a new plot
<azonenberg>
NeedsConfig() returns true if the user has to pick settings, or pick more than one input, and false if the filter is fully autonomous with one input
<azonenberg>
then Refresh() does the actual decoding magic
<azonenberg>
there's a few other methods that you may or may not need, for example GetText() and GetColor() return info for decodes with complex output types
<azonenberg>
if your filter outputs a standard scalar sample type like float/bool then the existing rendering logic can do its thing with no help
<azonenberg>
Look at any of the existing decodes for examples. You may also choose to build your filter around PacketDecoder rather than Filter, which allows you to expose packetized data for the protocol analyzer view as well as time-domain output signals
<azonenberg>
As far as the FFTS stuff goes, that is likely a problem with how your ffts install is configured on Windows. It should have been fixed to not need any changes to paths
<azonenberg>
if you exactly followed the instructions in the manual
<azonenberg>
Check .github/workflows/build.yml, which is the CI build script, and see if you did anything different from that
<d1b2>
<Attie> thanks for the pointers 🙂 - I'm going copy and hack...
<d1b2>
<Attie> re instructions: i did follow very carefully, though it's possible i didn't actually do the right thing
<azonenberg>
If it disagrees with the manual, the CI script is right and the manual is wrong. because CI builds compile without any patching of code
<d1b2>
<Attie> ha ok, i'll take a look
<azonenberg>
In general the windows build is far less mature and well tested than the linux build because we have only a handful of users on windows
<azonenberg>
i believe you're #3 lol
<azonenberg>
the other two being katharina and bvernoux
<azonenberg>
everyone else is on linux
<d1b2>
<Attie> haha
<d1b2>
<Attie> to be honest, i can't remember the last time i built anything on windows, and i do most of my work on a headless Linux system
<azonenberg>
so why not run on linux?
<azonenberg>
do you not have any non-headless linux boxes?
<d1b2>
<Attie> eh... Altium is a big one...?
<d1b2>
<Attie> i do not...
<azonenberg>
I see, lol
<d1b2>
<Attie> plenty of headless! haha
<azonenberg>
not that it's a help for you right now but libscopehal can be used headless on linux for ATE-type applications
<azonenberg>
as of now there's no GPU requirement, but that may change down the road once we start pushing protocol decodes to GPU. Which is on the long term TODO but not happening any time soon
<d1b2>
<Attie> i also find myself in a familiar environment with windows... though i am finding myself questioning it more and more
<azonenberg>
FFTs, de-embeds, and simple math functions will probably be the first to go as they're straightforward to implement
<d1b2>
<Attie> re ATE, that's very good to know!
<d1b2>
<Attie> @miek - thanks!
<azonenberg>
miek: hey now that you're here, i wanted to ping you about both agilent and usb status
<azonenberg>
just seeing if you had any updates/plans to make progress in the near future
<miek>
on my scope at least, the sample depth is reduced when i go below a certain time/div
<_whitenotifier-f>
[scopehal-docs] nshcat commented on pull request #20: Update Windows install notes - https://git.io/JkOMG
<miek>
nah, no progress lately. lots going on so no firm plans atm, only good intentions :p
<_whitenotifier-f>
[scopehal-docs] attie commented on pull request #20: Update Windows install notes - https://git.io/JkOMc
<_whitenotifier-f>
[scopehal-docs] azonenberg commented on pull request #20: Update Windows install notes - https://git.io/JkOMB
<d1b2>
<Attie> i'm heading off - thanks for the support @azonenberg ! much appreciated
<_whitenotifier-f>
[scopehal-docs] azonenberg commented on pull request #20: Update Windows install notes - https://git.io/JkOMQ
<_whitenotifier-f>
[scopehal-docs] azonenberg pushed 5 commits to master [+0/-0/±5] https://git.io/JkOM7
<_whitenotifier-f>
[scopehal-docs] attie-argentum 13a05b0 - Wrap a long line
<_whitenotifier-f>
[scopehal-docs] attie-argentum 8f86e50 - Add a note about Catch2 and unit tests for Windows builds
<_whitenotifier-f>
[scopehal-docs] attie-argentum 570e41e - Re-word Windows installation options to align with items below
<_whitenotifier-f>
[scopehal-docs] ... and 2 more commits.
Degi has quit [Ping timeout: 258 seconds]
Degi has joined #scopehal
<_whitenotifier-f>
[scopehal] azonenberg opened issue #340: Design APIs for setting resolution of instruments - https://git.io/JkO7U
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #340: Design APIs for setting resolution of instruments - https://git.io/JkO7U
alexhw has quit [Quit: No Ping reply in 180 seconds.]
alexhw has joined #scopehal
<azonenberg>
lain: ping re #340 (see above): any ideas?
<azonenberg>
monochroma, Bird|otherbox: also what about you?
<Bird|otherbox>
azonenberg: for the latter two cases, do we want to try to handle cases where the legal set of resolutions is different channel-to-channel, or channel-group to channel-group for that matter?
<azonenberg>
Bird|otherbox: I think its reasonable to assume all channels or groups are orthogonal
<Bird|otherbox>
yeah, from the sounds of things, there aren't any commercial instruments that do anything beyond a single global res setting
<azonenberg>
Yeah. I'm trying to plan ahead for the stuff we're building to be more flexible though
<Bird|otherbox>
*nods*
<Bird|otherbox>
on DUDDEL/BLONDEL, do channel numbers start from 0 or 1 for that matter?
<Bird|otherbox>
never mind, actually
<Bird|otherbox>
that's kind of a transplanted POSIX/C idiom I was thinking of :P
<Bird|otherbox>
probably better to do something more strongly typed for C++
<azonenberg>
Scopehal channel numbers are all zero based internally
<azonenberg>
and include external trigger inputs, digital channels, etc
<azonenberg>
the ID is just an index into a vector of OscilloscopeChannel* objects
<azonenberg>
Which have both a "hardware name" (what that scope calls the channel over SCPI) and a "display name" (user-chosen nickname displayed in glscopeclient and, in some scopes, below the channel name on the scope screen)
<azonenberg>
incidentally, this model causes... interesting problems... with some scopes. I believe tek mso5/6, which is otherwise very orthogonal
<azonenberg>
or was it rigol? cant remember now
<azonenberg>
but there are some spots where they use different names for the same channel depending on which command you're pushing it to
<azonenberg>
like C1 vs CH1
smkz has quit [Quit: smkz]
smkz has joined #scopehal
<azonenberg>
lain, Bird|otherbox: Proposal for API
<azonenberg>
have bank discovery work basically the same way it does for LA pods now, that seems to be fine
<azonenberg>
(function to get all banks, or the bank a given channel is in)
<azonenberg>
then have a function to get the ADC mode names for a given channel/bank
<azonenberg>
this will return a vector<string> containing arbitrary text describing the ADC modes numbered 0...N
<azonenberg>
you will then have get/set methods to access the ADC mode for a bank
<azonenberg>
there will be no machine readable interface for bit depth because i cant think of a clean way to do that
<azonenberg>
so for example, on BLONDEL/DUDDELL, the ADC modes will be "12 bit, 640 Msps max" and "8 bit, 1 Gsps max", and possibly "14 bit, 105 Msps max"
<azonenberg>
while on HDO9000 they will be "HD on" and "HD off"
<azonenberg>
and then the driver translates the numeric mode ID to whatever config the hardware requires
<azonenberg>
this will be a little awkward for ATE, but i imagine most ATE code is OK with being somewhat tied to specific hardware WRT details of ADC modes
<azonenberg>
and for GUI code it lets me easily populate a dropdown
<azonenberg>
and not have to worry about all of the complexities of what "HD on" vs "HD off" means depending on timebase config
<_whitenotifier-f>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±4] https://git.io/Jk3Ye
<_whitenotifier-f>
[scopehal] azonenberg cca8393 - Initial definition of analog bank and ADC mode APIs. Not implemented by any instruments yet, but no-op defaults are provided. Fixes #340.
<_whitenotifier-f>
[scopehal] azonenberg 98f04c9 - Implemented HD mode support for LeCroy HDO9000. Fixes #151.
<_whitenotifier-f>
[scopehal] azonenberg closed issue #340: Design APIs for setting resolution of instruments - https://git.io/JkO7U
<_whitenotifier-f>
[scopehal] azonenberg closed issue #151: Add support for configuring channel bit depth on LeCroy HDO9000 series - https://git.io/Jf5fm
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/Jk3YT
<_whitenotifier-f>
[scopehal-apps] azonenberg ddad9ed - Channel properties dialog now allows configuration of ADC bit depth on instruments that support this.
<Bird|otherbox>
btw: if you're curious azonenberg: what happened to my other PC is that the power supply's +5VSB rail was decaying/sagging and no longer could support the EC on the motherboard, leading to a noPOST
<Bird|otherbox>
worse yet, I initially misdiagnosed the issue as a faulty motherboard because the supply came on just fine when I unplugged it from the motherboard and grounded out the power-on line
<azonenberg>
Bird|otherbox: fuuun
<azonenberg>
but it only failed under load? interesting
<Bird|otherbox>
it was sagging under no-load even
<Bird|otherbox>
tested around 4.2-4.3V when I was first trying to diagnose the problem, and was down to 3.5-3.8V or so when I took a second look at it
<Bird|otherbox>
oddly enough, the only symptom I had to warn me of the issue before the noPOST incident was that I was having trouble with the system not outputting video in the correct resolution because it couldn't read the EDID data from the monitors
<azonenberg>
interesting
<azonenberg>
eeproms run on +5VSB and sagging below vddmin?
<Bird|otherbox>
that's my theory, but I don't know *why* the graphics card would want to feed +5VSB to the EDID EEPROMs instead of yanno, the regular 5V rail, its not like a turned-off PC needs to know what graphics modes to send lulz
<Bird|otherbox>
maybe it has to do with display sleep modes?
<azonenberg>
yeah that was my thought. something about the monitor knowing the pc was turned off or something and going into sleep
<azonenberg>
idk, i havent looked into exactly how power rails on pcs work
<d1b2>
<mubes> DDC specs a 5v feed for edid, and I guess other, purposes. Chances are it goes straight into a ldo which prevents downstream circuitry being too critical on the 5v, but at some point that's going to go into passthrough and then things get starved. For a guess.