<monochroma>
pretzel4ever4 did not like your latest update :<
<azonenberg>
lol
<azonenberg>
monochroma: starting to look pretty good i think
<azonenberg>
cant wait till i get started on the big FPGA, that's going to be the fun part
<monochroma>
idk why but looking at the ratsnest, all i can think of is the scene in war games where all of the missile trajectory lines are overlaid ontop of each other XD
<azonenberg>
lol
<monochroma>
yeah looks like you are pretty close
<azonenberg>
Close to starting the FPGA, or close to done? :p
<monochroma>
starting the FPGA
<azonenberg>
Yeah
<azonenberg>
I am concerned about running out of horizontal routing channels though
<azonenberg>
this is the bottom left corner around the stm32
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #scopehal
<azonenberg>
monochroma: also, just got and paid the final invoice for the new toolbar icons. Should be getting the image files shortly, then i can figure out how to use them
smkz has quit [Quit: ~]
smkz has joined #scopehal
<monochroma>
:D
electronic_eel_ has joined #scopehal
electronic_eel has quit [Ping timeout: 272 seconds]
<azonenberg>
Also if anybody is curious i have 45.8 GB of video footage of the layout process
<azonenberg>
4K video, even at 1 FPS, gets big fast
<monochroma>
lol
<_whitenotifier-b>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JJqAs
<_whitenotifier-b>
[starshipraider] azonenberg bfd15d5 - Finished routing of main power supply area
<_whitenotifier-b>
[scopehal-apps] azonenberg pushed 1 commit to master [+20/-2/±3] https://git.io/JJqpw
<_whitenotifier-b>
[scopehal-apps] azonenberg 68e4a1e - Initial setup of new custom icon theme. Fixes #60.
<_whitenotifier-b>
[scopehal-apps] azonenberg opened issue #130: Digital channels display protocol decodes in the right margin area where analog channels have Y axis text - https://git.io/JJqpo
<_whitenotifier-b>
[scopehal-apps] azonenberg labeled issue #130: Digital channels display protocol decodes in the right margin area where analog channels have Y axis text - https://git.io/JJqpo
<_whitenotifier-b>
[scopehal-apps] azonenberg labeled issue #130: Digital channels display protocol decodes in the right margin area where analog channels have Y axis text - https://git.io/JJqpo
<monochroma>
text labels under would be nice, but i guess the current style is to use tooltips
<azonenberg>
that is actually a GTK preference you can change freely
<azonenberg>
if memory serves me right
<azonenberg>
although i might have to add the text since it seems like i didn't specify that. Easy enough to fix though
<_whitenotifier-b>
[scopehal-apps] azonenberg opened issue #131: Add 48x48 renders of toolbar icons, and preference setting to use 24x24 or 48x48 - https://git.io/JJqpP
<_whitenotifier-b>
[scopehal-apps] azonenberg labeled issue #131: Add 48x48 renders of toolbar icons, and preference setting to use 24x24 or 48x48 - https://git.io/JJqpP
<azonenberg>
hmm seems like there is something up with that preference not working on my other apps
<azonenberg>
wonder if its a gtk2 vs gtk3 thing
<azonenberg>
in general i wanted to avoid text labels though because they take up a lot of space
<azonenberg>
and the goal here is for persistent UI elements to be as minimal as possible so as to not waste screen space you could use for waveforms
<azonenberg>
So one fun annoyance is that the southwest corner of the big FPGA is the 3.3V bank for the flash plus all signals from mcu to fpga
<azonenberg>
The north center and east are the RAM interface
<azonenberg>
then the east center is the QSFP+ interface and the southeast is the 10G inputs
<azonenberg>
and then northwest/north center and south center are the 1G inputs
<azonenberg>
This is going to lead to some fun hoops to jump through. Like the RGMII having to come out of the southwest corner of the FPGA, cross under an entire 50-pin bank of 1G I/O to the pods, go up north and hook around the top of the sodimm
<_whitenotifier-b>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±19] https://git.io/JJmLV
<_whitenotifier-b>
[starshipraider] azonenberg 54b951a - Fully routed right half of pod FPGA
<_whitenotifier-b>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JJmLQ
<_whitenotifier-b>
[starshipraider] azonenberg 41bda82 - Pod FPGA: updated pinout constraints for signals which are routed on PCB, confirmed everything is good from the vivado side
<_whitenotifier-b>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JJmtO
<_whitenotifier-b>
[starshipraider] azonenberg 306edda - More layout on rightmost pods. Moved main FPGA+RAM to (hopefully) final placement.
pepijndevos has joined #scopehal
<_whitenotifier-b>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JJmqe
<_whitenotifier-b>
[starshipraider] azonenberg 684a5e5 - Initial power/ground hookups to main FPGA and SODIMM
<azonenberg>
I think i'm done for the night though
<monochroma>
oh come onnnnn it's only ~1k nets!
<azonenberg>
have a few things to do then hopefully a bit of sleep before a call with a customer in six hours :p
<azonenberg>
lol
<pepijndevos>
azonenberg, how would you add immediate trigger to scopehal?
<pepijndevos>
oh lol, good night then
<azonenberg>
no i mean done with board layout
<azonenberg>
not going to sleep yet
<azonenberg>
pepijndevos: So there's a bunch of things that have to be done
<pepijndevos>
I found a triggertype enum, so I guess you "just" implement that in every SetTriggerType and update the UI?
<azonenberg>
Not exactly
<azonenberg>
That's for the condition of a trigger
<azonenberg>
in normal mode
<azonenberg>
There would need to be a new API similar to StartSingleTrigger()
<azonenberg>
Which would then have to be implemented in each derived class to send the proper scpi command to the instrument
<azonenberg>
then there would need to be a new toolbar button added in the OscilloscopeWindow class
<azonenberg>
And someone would have to come up with $50 to pay the artist i used to draw another icon
<pepijndevos>
lol
<azonenberg>
once the trigger is armed in 'force trigger' mode the same downloading of waveforms and other code paths should work without any modification
<azonenberg>
Also, thinking about it a bit more
<azonenberg>
I think a "fake auto trigger" mode is doable
<azonenberg>
So, by way of background, internally scopehal always uses one-shot trigger mode to avoid the race conditions i mentioned previously
<azonenberg>
I fake 'normal' trigger mode by arming a one shot trigger, downloading the waveform, then re-arming again
<azonenberg>
i think you could fake auto trigger by just sending a force-trigger command after each waveform
<pepijndevos>
Right
<azonenberg>
it would be a dumb auto trigger that doesn't make any attempt to lock to the waveform in any way shape or form. But realistically, who uses auto trigger for anything but "see what the signal looks like so i can design a proper trigger for it"?
<azonenberg>
let me file a few tickets on the tracker for this...
<_whitenotifier-b>
[scopehal-apps] azonenberg opened issue #133: Commission toolbar icons for "auto trigger" and "force trigger" - https://git.io/JJmqH
<_whitenotifier-b>
[scopehal-apps] azonenberg labeled issue #133: Commission toolbar icons for "auto trigger" and "force trigger" - https://git.io/JJmqH
<_whitenotifier-b>
[scopehal] azonenberg opened issue #173: Add "force trigger" API to Oscilloscope - https://git.io/JJmq7
<_whitenotifier-b>
[scopehal] azonenberg labeled issue #173: Add "force trigger" API to Oscilloscope - https://git.io/JJmq7
<Degi>
Hmh, the FPGA has less than 1k nets?
<pepijndevos>
I'm just trying to understand how single trigger/forced trigger works at all
<azonenberg>
Degi: 676 balls, some are power/ground which i have routed already
<Degi>
Oh I see. Barely visible thru the spider web
<_whitenotifier-b>
[scopehal] azonenberg opened issue #174: Add "start auto trigger" API to Oscilloscope class - https://git.io/JJmqd
<_whitenotifier-b>
[scopehal] azonenberg labeled issue #174: Add "start auto trigger" API to Oscilloscope class - https://git.io/JJmqd
<azonenberg>
pepijndevos: so at a high level what's going on is there's conceptually three threads of execution
<Degi>
Huge test pads heh
<azonenberg>
the first is the instrument itself
<azonenberg>
the second is the glscopeclient UI
<azonenberg>
and the third is the ScopeThread (one per instrument if you have several connected at once) in glscopeclient/main.cpp
<azonenberg>
ScopeThread is constantly calling PollTrigger() on its attached instrument, checking to see if a waveform is ready
<azonenberg>
when found, it downloads the data and pushes it into a fifo
<azonenberg>
meanwhile, every timer tick glscopeclient checks that fifo for new waveforms
<azonenberg>
when every instrument (if you have more than one has a pending waveform, it refreshes the filter graph and redraws the waveforms in the UI
<azonenberg>
So when you arm the trigger all you're doing is instructing the instrument to start looking for trigger events
<pepijndevos>
Ah, I finally found the Rigol SCPI manual. So basically there isn't an "immediate" trigger mode, you have to send the TFORce command.
<azonenberg>
(incidentally the lack of this sort of developer documentation is one of the things holding back the project... but end user documentation is the higher priority)
<azonenberg>
Yeah
<azonenberg>
that sounds right
<azonenberg>
The other wrinkle is, when you add a new API to Oscilloscope that means *every* supported instrument driver has to at least implement a no-op version of that API
<azonenberg>
but preferably, actually a functional version
<pepijndevos>
Right
<azonenberg>
So there's lots of reading of documentation from every supported device family, testing, etc
<azonenberg>
Generally speaking LeCroyOscilloscope is the "flagship" driver that implements every API or close to it
<azonenberg>
since my lab is a lecroy shop and that's what i do all of my development on
<azonenberg>
most other drivers are lagging behind in support for at least some stuff
<pepijndevos>
Do you have a giant stack of scopes somewhere, or do other contributors do the other scopes?
<Degi>
I've done the Rigol MSO5
<azonenberg>
I have a HDO9204 and a WaveRunner 8104-MS, which i plan to sell/trade in shortly to get an 8404-MS
<azonenberg>
I wrote the original Rigol driver off of a DS1000Z somebody in Russia gave me VPN access to, i never had my hands on it
<azonenberg>
then Degi took over
<Degi>
VPN access? Lol
<azonenberg>
well actually i think it was just open to the internet :p
<azonenberg>
i did the same with a R&S scope in Germany somewhere, that driver is currently abandoned-ish because nobody with a R&S scope has taken over maintainership and i don't have access to one
<azonenberg>
then... miek, i think, is doing agilent/keysight stuff and tverbeuere contributed a preliminary tek driver
<azonenberg>
This project has gained a lot of momentum over the past few months - at the start of the year there was no manual and it was basically just me
<azonenberg>
oh and noopwafel was interested in doing a Pico driver but i dont think there's been progress on that yet
<azonenberg>
and tverbeuere / Error_404 did a lot of work on siglent stuff
<pepijndevos>
Sweet
<azonenberg>
(you have looked at the manual, right?)
<pepijndevos>
Actually I haven't done much of anything. I just compiled the thing and tried to connect to my scope.
<pepijndevos>
Somewhere these days I plan to do some actual project with it
<azonenberg>
94 pages although a fair number of them towards the end are just headings with no content
<pepijndevos>
The fact it has a manual is already quite exceptional for an open source project hehe
<azonenberg>
I'm trying to fix the test equipment industry, doing that requires a serious, professional-grade tool
<azonenberg>
It's not there yet but documentation is a key requirement
<pepijndevos>
I'm not intimately familiar with this industry. Did you write a long rant somewhere about all its faults?
<azonenberg>
No, i've just been fed up with both the available hardware and software for a long time
<azonenberg>
overpriced, unreliable, bulky
<azonenberg>
So i'm planning a two pronged attack... on one side, glscopeclient and libscopehal, allowing you to ignore most of the awfulness of vendor scope UIs and get a single unified user interface for any instrument(s) you want, with no stupid limitations on capabilities
<azonenberg>
want to decode usb 1.1 on a 70 MHz rigol? go right ahead
<azonenberg>
but in parallel with that, designing my own instrumentation intended for headless operation with glscopeclient as the sole UI
<pepijndevos>
That's the MAXWELL/MEAD/probe stuff I've seen passing by?
<azonenberg>
Yeah. There's actually 4 different active projects going on right now in that realm
<azonenberg>
First is the probe (internally codenamed HALL but i basically don't use that name as the final part number AKL-PT1 has already been announced)
<azonenberg>
that's almost ready to ship... the kickstarter was funded, i did a few more board iterations, ordered what is hopefully the final version, ordered the hopefully final enclosure, tips/grounds are already here, and now i'm just waiting on stuff to come in
<azonenberg>
need to order a few passives from digikey for the production run but that's easy enough
<azonenberg>
i just need to get the final PCB rev and do some characterization so i can finalize the manual with actual specs
<azonenberg>
Next is the logic analyzer pod. This is a family of three interface-compatible pods
<azonenberg>
MEAD is the 50 ohm MMCX version which is just about done. Firmware is complete, there needs to be one board spin that moves a connector by a mm or two for mechanical reasons and adds a header for the LCD backlight but the prototype does work
<azonenberg>
The (hopefully) final 3d printed plastic prototype of the enclosure shipped and should be at my lab friday, if i like it i'll try and come up with some budget to make a CNC'd aluminum one which is what i intend to do for production units
<azonenberg>
CONWAY and the third (no codename assigned yet) are siblings with 100 mil high-Z and (connector TBD) 100 ohm differential inputs
<azonenberg>
to be precise firmware isn't DONE, i didn't implement a runtime update mode to reflash it yet. But all of the key features needed to *use* it are done
<azonenberg>
Then the next project is BLONDEL, the first in my line of oscilloscopes. It uses the same ADC family probably in your rigol
<azonenberg>
It's a 1U headless scope with eight 50 ohm SMA inputs divided into two groups
<azonenberg>
each group of 4 shares a single 1 Gsps 8-bit ADC and you can split the sample rate across one, two, or all four channels
<azonenberg>
you can also run the ADC at 500 Msps in 12 bit mode
<pepijndevos>
hah
<azonenberg>
So you have six different sample rate/bit depth configurations you can choose between at run time depending on your application
<azonenberg>
100 MHz bandwidth, although in 4-channel 12-bit mode you're below Nyquist so i swap in a 50 MHz antialiasing filter
<azonenberg>
then a sodimm of ddr3 for capture buffer, a front panel status LCD for setting the IP and such, and 1G copper / 10G fiber ethernet to the host
<azonenberg>
The analog front end is designed and prototyped, we found some bugs in the board but reworked the prototype enough to do testing
<azonenberg>
I need to characterize it more completely but overall it performs as expected
<azonenberg>
we have a test board for the ADC that is working well as well
<azonenberg>
The final analog board with four AFEs plus an ADC still has to be designed, there's two blockers on that
<azonenberg>
first, which einthecorgi2 said he was going to look into but i havent heard anything from so i need to poke him about, is the active probe interface
<azonenberg>
we plan on using USB-C to provide power and data connections to not-yet-designed active probes
<azonenberg>
then standard SMA for the RF signal
<azonenberg>
this avoids the need for expensive custom cables and works with entirely COTS cabling (you can of course ziptie/velcro/tape a SMA and USB cable together to reduce bench clutter if you want)
<azonenberg>
But we need to actually work out details of the alternate mode to supply +/- 7V power to the probe heads
<azonenberg>
The second blocker is more complete measurements of the frontend's performance to see if we want to make any other changes
<azonenberg>
e.g. s-parameters at each gain step
<azonenberg>
BLONDEL will also have two 8-bit logic analyzer inputs, which will run at 1.25 Gsps and be able to support any of the LA pods I've designed
<pepijndevos>
oooh
<azonenberg>
So in total you get 8 analog and 16 digital channels in 1U
<azonenberg>
And then the final ongoing project is MAXWELL, which is a pure logic analyzer with no analog inputs
<azonenberg>
but has *twelve* 8-bit LA inputs
<azonenberg>
for a total of 96 channels, 92 at 1.25 Gsps and the last four at 10 Gsps
<pepijndevos>
whoa intense
<azonenberg>
In 1U. Then a SODIMM of DDR3 as capture buffer and 1G/40G ethernet to the host
<azonenberg>
It's my biggest electronic design project ever, by a huge margin
<azonenberg>
in case you can't tell scale from the twitter screenshots, the motherboard is about the size of a sheet of A4 paper
<azonenberg>
eight layers of RO4350B with via-in-pad, nearly a thousand components, two FPGAs and a STM32F7
<azonenberg>
i think the final count was seventeen power rails?
<pepijndevos>
quite huge
<azonenberg>
Yeah
<azonenberg>
anyway, those are the projects with active engineering going on
<azonenberg>
There are several more on the roadmap with nothing but a list of target specs
<azonenberg>
DUDDELL is a successor to BLONDEL that has an ADC dedicated to each channel, so you don't lose sample rate when enabling more channels
<azonenberg>
Same frontend but a 250 MHz antialiasing filter, 1 Gsps all the time in 8-bit mode or 500 Msps in 12 bit, switchable per channel
<azonenberg>
ZENNECK is a successor to that which interleaves four of the same ADCs per channel, 500 MHz bandwidth, 4 Gsps 8-bit or 2 Gsps 12-bit
<pepijndevos>
lol, when high end is not high enough
<azonenberg>
all of these are 12 channels, although ZENNECK may have to be 2U instead of 1U due to board space limitations
<azonenberg>
then VOLLUM will be a completely new architecture using a different ADC, the AD9213 (12 bit 10 Gsps with a JESD204B interface)
<pepijndevos>
Are scopes with more than 12 bits a thing at all?
<azonenberg>
eight 10 Gsps channels, 1-2 GHz bandwidth, and a price tag on par with a decent car
<azonenberg>
(the ADC is $3500 at digikey for one unit. And we'll probably need an FPGA and a sodimm of DDR4 per channel to keep up with the 120 Gbps of waveform data coming off it)
<pepijndevos>
oof
<azonenberg>
Hopefulyl i can get discounts for buying a bunch, but we'll see. That's a long ways out
<azonenberg>
then finally, MURDOCK, the "I can dream" scope with a price tag on par with a cheap house
<azonenberg>
Four interleaved AD9213s per channel, 40 Gsps on 8 channels, 6 GHz bandwidth
<azonenberg>
it would probably be 4U or so with a substantial blade per channel containing a couple of FPGAs and quad channel DDR4
<azonenberg>
total of 32 sodimms of memory and 16-32 ultrascale fpgas
<azonenberg>
It will probably never happen, but is the end goal on the roadmap :p
<azonenberg>
And yes, higher bit depth scopes exist, but they're pretty specialized
<azonenberg>
The ADC i'm using in BLONDEL/DUDDELL/ZENNECK actually supports a 105 Msps 14-bit mode although i don't plan to implement that in my firmware
<azonenberg>
i think keysight makes a 16-bit line
<pepijndevos>
Mostly audio probably... my MyDAQ had 16 bits, with a 20khz bandwidth.
<azonenberg>
anyway so yeah, that's the roadmap. Still a ton of work to do on all of them
<_whitenotifier-b>
[scopehal-apps] whitequark opened issue #134: Hang if I don't give oscilloscope a nickname - https://git.io/JJmYA
<azonenberg>
Everything is open source although i plan to sell assembled units to recoup R&D expenses
<azonenberg>
Power supply, one full channel plus part of a second (gain stage only, no offset/filter, since the gain stage is a dual channel amplifier) plus a bunch of test points and such
<_whitenotifier-b>
[scopehal-apps] whitequark opened issue #135: Crash with Rigol DS1104Z connected via USBTMC - https://git.io/JJmOm
<_whitenotifier-b>
[scopehal] whitequark opened issue #175: Crash with Rigol DS1104Z connected via USBTMC - https://git.io/JJmOc
<_whitenotifier-b>
[scopehal] azonenberg commented on issue #175: Crash with Rigol DS1104Z connected via USBTMC - https://git.io/JJmOC
<_whitenotifier-b>
[scopehal] azonenberg labeled issue #175: Crash with Rigol DS1104Z connected via USBTMC - https://git.io/JJmOc
<_whitenotifier-b>
[scopehal] pepijndevos forked the repository - https://git.io/v6jSq
StM_ has joined #scopehal
<_whitenotifier-b>
[scopehal] pepijndevos opened pull request #176: Add force trigger API - https://git.io/JJmsp
<_whitenotifier-b>
[scopehal-apps] pepijndevos forked the repository - https://git.io/v6jSq
<_whitenotifier-b>
[scopehal-apps] pepijndevos opened pull request #136: Add force trigger button to UI - https://git.io/JJmZQ
<_whitenotifier-b>
[scopehal] pepijndevos commented on pull request #176: Add force trigger API - https://git.io/JJmZA
<pepijndevos>
azonenberg, heheee, I actually have force trigger working on my rigol :))))
juli964 has joined #scopehal
maartenBE has quit [Ping timeout: 256 seconds]
maartenBE has joined #scopehal
kc8apf_ has joined #scopehal
kc8apf has quit [*.net *.split]
lukego has quit [*.net *.split]
kc8apf_ is now known as kc8apf
promach3 has quit [Write error: Connection reset by peer]
lukego has joined #scopehal
promach3 has joined #scopehal
<azonenberg>
pepijndevos: awesome. I need to start thinking about what the toolbar icons should look like
<azonenberg>
so i can have the artist draw them
<pepijndevos>
azonenberg, haha yea, I struggled a bit with thinking what a "force" icon should look like, and even more with editing the icon in Inkscape.
<pepijndevos>
I guess I took inspiration from VIM, taking :q! and making a >! run --force kinda icon hehe
<pepijndevos>
For auto mode I'd go for a triangle with a "recycle" arrow or something maybe.
m4ssi has joined #scopehal
m4ssi has quit [Remote host closed the connection]