<cyrozap>
Hi, all! I was looking into ngscopeclient recently since I preordered a Thunderscope, and I just thought I'd let you know that https://www.ngscopeclient.org/ is missing links to the GitHub org and repos, as well as links to download prebuilt binaries (assuming they exist).
<azonenberg>
cyrozap: there should be links to the code in a couple spots
<azonenberg>
we can make them more obvious
<azonenberg>
There are no prebuilt binary download links right now. Some platforms have binaries available as CI artifacts if you're logged into github
<azonenberg>
We're in the process of ripping out some annoying dependencies that make packaging annoying
<azonenberg>
and going on a documentation and stability rampage so that when the influx of new users from shipping thunderscopes comes, they'll actually be able to use them
<cyrozap>
Oh, I see now, it's the "Open source" text that has the link
<azonenberg>
At some point in that process we'll end up with binaries. Goal is to have at minimum deb, rpm, msi, and whatever macos needs
<azonenberg>
But everyone is stretched pretty thin, if you wanna help out we're always looking for devs lol
<cyrozap>
What repo is that webpage generated from? I'm happy to submit PRs to improve docs.
<azonenberg>
So we have docs in a couple different spots
<azonenberg>
The end user docs need a major refresh because we've changed a bunch of things about the UI recently to make it easier to navigate
<azonenberg>
there are also some issues with the generated HTML documentation not being as navigable as i'd like
<azonenberg>
i've been going into the office a lot for work the last few weeks and not had much time to work on the project but i've tried to at least add doxygen API documentation to one or two classes each bus or ferry ride
<azonenberg>
cyrozap: anyway, if you want to work on improving either the website or documentation let me know, i'll take PRs or i can direct you at specific things i know need doing
<azonenberg>
pirate: ok so... for all the ddr icons, why is the chip purple? undersides of BGAs are usually green (i assume we're depicting the chip here not the pcb footprint?)
<azonenberg>
i'm not sure why the bga row and column pitches aren't equal
<azonenberg>
The displayport connector icon looks good, maybe add "AUX" text to the right to make it clear we're decoding the aux channel rather than the video channel (we plan to add a decode for the video but haven't implemented it yet)
<azonenberg>
but they'll be separate blocks
<azonenberg>
The DRAM clocks filter outputs two clocks, not one. basically it generates a gated clock that toggles when reading or writing
<azonenberg>
So dram chip plus two clock outputs that do not activate at the same time
<azonenberg>
a few toggles on one, then a few on the other
<azonenberg>
spectrogram looks good as is
<azonenberg>
for FSK, why is the arrow pointing to the left? this is a decoder not an encoder
<azonenberg>
also you forgot the keepout in the left pixel column, you can see some leakage into the right side of the icon when rendered
<azonenberg>
for Trcd and Trfc I think maybe removing the waveforms and just having the name of the parameter would make the most sense
<azonenberg>
because i can't think of any way to depict refresh-to-refresh or row-to-column timing parameters graphically in that small a space
<d1b2>
<josHua> I kidn of woudl be tempted to represent "DRAM" as a 1T DRAM cell rather than 'a BGA of some kind' and indeed use text
<joshua_>
gosh, the transposition errors are getting bad this time of night.
<azonenberg>
joshua_: The intended audience here is mostly board designers not silicon designers
<azonenberg>
you or i would recognize a 1t dram cell schematic, sure
<azonenberg>
but how many folks laying out dram would
<azonenberg>
i'm the kind of guy who has t-shirts with reverse engineered 180nm standard cells on them :p
<azonenberg>
in any case, i think we're all in agreement the timing parameters should be represented as text
<azonenberg>
And as i mentioned before any icon, as long as it's not *wrong*, is better than none
<joshua_>
well, two things: 1) even if an icon does not have inherent meaning to a user, it is still useful if it is unique and identifiable by eye ("why do all the DRAM tracers have a transistor and a capacitor? well whatever"); and 2) I think that board designers designing in a DRAM probably do understand it :)
<azonenberg>
i think you overestimate the skill level of the *average* board designer
<azonenberg>
you should see some of the design reviews i've done for folks
<joshua_>
(if you put a stack of BGA DRAMs on my desk and a stack of BGA NAND flashes, ball side up, I'm not sure I could tell you which was which)
<azonenberg>
lol i could probably tell them apart by touch
<azonenberg>
without even looking
<azonenberg>
the way i always distinguish them is that ddr has two strips of balls with a gap between them
<azonenberg>
no other bga looks like that
<azonenberg>
(because they're wirebonded down the centerline of the die rather than the perimeter)
<joshua_>
(I kind of wonder percentile distribution professional PCB designers lie along.)
<azonenberg>
Good question lol
<azonenberg>
pirate: anyway let's play with joshua_'s concept too. try drawing an alternate version of one of the dram icons with a dram bitcell schematic (probably in blue) instead of the bga footprint
<azonenberg>
and we'll see how we like it
<joshua_>
generally my claim on board design is that if someone is paying me to do it, they are wasting their money on low-skill board design and whatever their other options are must be truly dire, but *also*, I have seen a lot of truly dire situations that I have been involved in
<azonenberg>
anyway, i have to go into the office early again tomorrow so i'm gonna hit the hay in hopes of possibly getting a whole six hours of sleep today
<joshua_>
that's fine with me too. the "WL" and "BL" nets in the other diagram are nice to have to show the context but not necessary, I would get the message from that FET + capacitor one too
<joshua_>
seems like a good plan
* azonenberg
stares at editor with dozens of open files while nomming breakfast
<_whitenotifier>
[scopehal] azonenberg 4253e09 - Added Doxygen comments to AlignedAllocator
<_whitenotifier>
[scopehal] azonenberg bb70f93 - Partial Doxygen coverage of AgilentOscilloscope, not complete yet but better than nothing
<dingwat>
speaking of the competency of layout engineers, I had to explain the difference between an oscillator and a crystal to a layout team yesterday because they put guard traces around an XO and justified it by saying "Intel says so!"
<azonenberg>
lolol
<azonenberg>
at least they didnt try to put load caps on it?
<dingwat>
no load caps, but trying to get them to fix via stubs has been like pulling teeth, despite intel being very explicit with limits on total via stub length
<_whitenotifier>
[scopehal-apps] azonenberg 9a28d9f - Merge branch 'master' of github.com:ngscopeclient/scopehal-apps
<_whitenotifier>
[scopehal-apps] azonenberg 982bba2 - Updated to latest scopehal
<azonenberg>
dingwat: enjoy. i did a design recently for a friend who contracted out some stuff that had the worst PDN i've ever seen
<azonenberg>
a design review*
<azonenberg>
long skinny inductive tracks on an inner layer providing power to a pcie switch
<dingwat>
oh this also has a totally fucked PDN. Every single thing has its own rail, with either a load switch or a pile of ferrites in between, so there's basically no opportunity for any significant plane capacitance, and the power layers are just completely hacked up
<dingwat>
azonenberg: ok, so ya know how I said there was no diff pair routing on I2C? well, that's still true, but this board has length matching on I2C :(
<joshua_>
haha are there meanders?
<dingwat>
yeah. not stoked about that
<dingwat>
like yeah sure it will work. but goddamnit why
<joshua_>
well it's always good to make sure that there isn't too much setup time skew on a 400 kHz clock
<dingwat>
exactly lol
<joshua_>
and, hey, adding a little extra capacitance to an I2C bus is *usually* fine
<dingwat>
this is a dense board, and it's just adding extra routing pressure. grrrr
<joshua_>
sounds like a dense designer too
<dingwat>
lmao
<joshua_>
I will /msg you with a review that I did in April that I wish I had gotten to do *before* the board was sent to me to bring up
<joshua_>
(I saved this review because it is probably the single worst board I have ever seen in my life)
<_whitenotifier>
[scopehal-apps] dizzystem 2673d6d - a few new icons, edited a lot of old icons to prevent the visual glitch from pixels touching the edge of the image
<_whitenotifier>
[scopehal-apps] azonenberg 5baf780 - Added render integrations for new icons from tetrikitty
<azonenberg>
Ok that's all of the pending icons from tetrikitty. some will need some rework but it sounds like she isnt gonna have the time to work on those
<azonenberg>
pirate: when you're back (no rush): the "prbs checker" icon as drawn has a random analog signal in the background, that should change to a random-looking digital bit sequence
<azonenberg>
Still plenty more to do, some of the existing icons need rework and there's 118 filters with no icon at all. plus the toolbar is still in the queue for a revamp before v0.1 too
<azonenberg>
One of those 118 is the "scale" filter which i think is redundant, it can be replaced by the "multiply" filter now that the multiply filter supports scalar-times-vector stuff
<azonenberg>
let me file a ticket for deprecating it
<d1b2>
<duskwuff> "We paid good money for that length-matching button, and by heck we're going to get our money's worth out of it."
<azonenberg>
loool
<joshua_>
hm, I want to use ngscopeclient later to do an FFT of the power supply on this board (since the Rigol's onboard fft is truly miserable, especially with large captures), and I realize that one sad thing is that libscopehal only downloads 8bit samples from the scope
<azonenberg>
Which scope is this?
<joshua_>
Rigol DHO4xxx
<azonenberg>
And that's a 12 bit scope?
<joshua_>
it is a 12-bit scope, though I don't know if it is > 8 ENOB...
<azonenberg>
File a ticket. If the scope has high bit depth ADC capability, we should support downloading full resolution captures (with an option to cut back to 8 bit to improve update rates at the cost of accuracy)
<azonenberg>
i personally don't think i will have time to work on it
<azonenberg>
but i'll help anyone else wanting to help implement that
<joshua_>
the scope is having an extremely bad time trying to do an FFT on a 500 Mpoint capture
<azonenberg>
Lol
<joshua_>
the first 'F' is sort of in question at the moment
<azonenberg>
To be fair, that is a LOT of work and even in ngscopeclient it's going to be somewhat slow
<azonenberg>
You may run into issues with gpu driver timeouts or memory exhaustion with that big a dataset
<azonenberg>
off the top of my head 500M points is 2GB roughly. and you need that much for the raw input, the windowed data going into the FFT, the complex FFT output, and the real output so that's four copies of the waveform
<azonenberg>
So you're looking at needing 8GB of VRAM at minimum
<joshua_>
well, M2 Pro go brr. but also indeed I think I am asking it to do something unreasonable
<azonenberg>
yeah apple silicon is actually what i would reach for on this problem just because of the huge amounts of unified ram
<joshua_>
it appears to not actually do the FFT on the whole 500 Mpt capture, either. it seems to do it on some subresolution of what is in the waveform window
<azonenberg>
but you may also still run into issues with vulkan timeouts giving a devicelost error. i don't know how well vkfft handles really enormous datasets like this
<azonenberg>
its not the most common use case, most folks work with less data lol
<azonenberg>
(that said i absolutely want to support "big T&M" to the extent practical)
<joshua_>
so it just takes forever to load the capture, decimate the capture, and then do a crappy FFT
<azonenberg>
like, tens of megapoint FFTs is just another day at the office
<azonenberg>
ah ok yeah
<azonenberg>
scopehal will actually do it full res unless you explicitly add a decimation block
<joshua_>
yes I think this is not 'big T&M', I think this is 'a novice is using a tool in a way that it is not meant to be used'
<azonenberg>
Lol fair enough
<azonenberg>
i'm used to actually working on problems using enormous datasets
<azonenberg>
like, tracing every clock cycle of activity on a QSPI bus for the time it takes an embedded gizmo to boot
<azonenberg>
so you get not just a flash dump but an instruction / data bus trace (modulo caching)
<azonenberg>
with timing
<joshua_>
I have never tried to measure the spectrum of a power supply before, and my instinct was 'grab as big of a capture as you can, and analyze it, and then you can see it all in one go'
<azonenberg>
You only need the absurdly long captures if you want to see very low frequencies or pulsed noise that doesnt occur constantly
<azonenberg>
i normally do power integrity work with a few tens of megapoints
<joshua_>
there are big pulses of noise happening here to be sure
<d1b2>
<josHua> this seems to be not a bad setup to measure this with in the end, having the scope average samples also seems to have taken some noise down