<_whitenotifier-c>
[scopehal-apps] azonenberg 29a5860 - ProtocolDecoderDialog: ported to Gtk::Grid, allowed changing of colors. Fixes #104.
<_whitenotifier-c>
[scopehal-apps] azonenberg closed issue #104: Allow changing color of protocol decodes - https://git.io/JfaMo
<_whitenotifier-c>
[scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JfaSk
<_whitenotifier-c>
[scopehal-cmake] azonenberg 1b14685 - Updated submodules with GTK 3.22 compatibility fixes and some new UI features
<_whitenotifier-c>
[scopehal-cmake] azonenberg commented on issue #10: Top of tree build is broken - https://git.io/JfaSt
Kliment has joined #scopehal
<azonenberg>
Kliment: continuing our convo from the other chan
<Kliment>
Why am I not surprised at half the members of this channel
<azonenberg>
Lol
<azonenberg>
the next one up, DUDDELL, will be the same frontend but the antialiasing filter bumped up to 250 Msps and one ADC per channel instead of one per 4
<azonenberg>
so you get 1 Gsps / 500 Msps 8/12 bit on each of 8 channels
<azonenberg>
individually switchable, 250 MHz bandwidth with an optional 100 MHz band limiting filter for the 12-bit mode
<Kliment>
and I expect you can mix and match frontends
<azonenberg>
They will be ~the same layout, but not the same board
<azonenberg>
BLONDEL will have one board w/ 4x AFE + 1x ADC per channel group
<azonenberg>
DUDDELL will have 1x ADC + 1x AFE on a board
<azonenberg>
DUDDELL may also move from an artix7 to a kintex7 for native 10GbE and faster ram capability
<azonenberg>
essentially copy pasted schematic, but a re-layout on the frontend board
<azonenberg>
just some filter passives changed
<azonenberg>
while it would in principle be possible to put the 250 MHz filter on BLONDEL you'd only be able to use one channel at a time before hitting aliasing problems
<azonenberg>
the different filter isnt a market segmentation ploy, it's Nyquist
<Kliment>
Yeah I get it
<azonenberg>
anyway, then ZENNECK will interleave four of the same ADCs on the same frontend, at 500 MHz bandwidth
<azonenberg>
4 Gsps 8-bit / 2 Gsps 12-bit
<azonenberg>
that will likely be taller, maybe 2-3U with vertical channel "blades" due to board layout constraints
<azonenberg>
and that is about the limit of where we can go with the HMCAD1520
<azonenberg>
VOLLUM, the next scope in the line, will move to the AD9213 which is 10 Gsps 12 bit on 16 JESD204B links
<azonenberg>
It's also a $3500 ADC
<Kliment>
Is that what your waverunner uses?
<azonenberg>
No idea, never opened it up
<Kliment>
specs sound similar
<azonenberg>
actually no definitely not
<azonenberg>
the waverunner is 8 bit
<Kliment>
ah
<azonenberg>
It's very likely the lecroy hdo8000A series, which is 12 bit, uses it
<azonenberg>
VOLLUM is intended to be a direct competitor to the hdo8108a
<azonenberg>
1-2 GHz bandwidth, 10 Gsps, 8 channels, 12 bit
<azonenberg>
but you're looking at 128x 10G SERDES to talk to all the adcs, at least 8-channel ddr4, and $30K (at digikey prices) of ADCs
<azonenberg>
So if it ever happens it will need some serious funding and, well, let's just say you probably aren't going to be putting them up on crowdsupply or indiegogo
<azonenberg>
MURDOCK, the end of the roadmap, interleaves four AD9213s per channel to get 6 GHz bandwidth and 40 Gsps bandwidth on 8 channels
<azonenberg>
performance on par with a lecroy wavepro hd and a price tag on the order of a cheap house
<Kliment>
azonenberg: start a cryptocoin craze that requires high speed ADCs to mine, wait for it to inflate until the market it flood it, wait for the bubble to pop, build scope
<azonenberg>
Lolol
<azonenberg>
AFE board in the foreground, ADC in the background, then an INTEGRALSTICK for FPGA
<azonenberg>
the ribbon cable between the two is a uart
<azonenberg>
the fpga runs a tcp offload engine that listens on two sockets
<azonenberg>
tcp 5025 bridges to a uart on the afe board's stm32 and runs scpi commands to configure gain/offset etc
<azonenberg>
then a high port, i forget what it is, is used for waveform data on a pub/sub model
<azonenberg>
basically say "i want channel 1" and every time the scope triggers you get a block of raw adc samples
<azonenberg>
eventually with framing around it for trigger timestamp, length, etc metadata
<Kliment>
that looks awesome
<Kliment>
And I guess it works with your new probes
<azonenberg>
Yes
<azonenberg>
this is a single channel prototype, and a lot of work is needed to move to the full system
<azonenberg>
right now the first todo is building the MSO pod
<Kliment>
single channel is already useful imo
<azonenberg>
all of these scopes will have around two 8-channel MSO input ports using SFF-8087 cables
<azonenberg>
sample rate determined by the scope side, the pod is just a bunch of comparators and an 8-lane DAC for setting reference voltage
<azonenberg>
with 8 lanes of LVDS to the scope
<azonenberg>
and i2c for configuring the dac
<azonenberg>
note that we will have threshold adjustable per channel, not per pod
<azonenberg>
so you can mix 3.3 and 1.8v logic on one pod, etc
<Kliment>
I wonder if you can abuse some display cable for this
<azonenberg>
We're going to use SAS cables
<azonenberg>
four lane SAS, SFF-8087, with all lanes from pod to scope instead of four tx and four rx
<azonenberg>
and the out-of-band signals being used for power and i2c
<azonenberg>
anyway there will be two interface compatible LA pods, MEAD and CONWAY (figured out our naming scheme yet? lol)
<Kliment>
They're references I don't get
<azonenberg>
both will be the same comparator and DAC, only difference is that MEAD will have 50 ohm MMCX inputs for use with transmission line probes while CONWAY will have high-Z inputs on 100 mil headers for use with e-z hooks etc
<azonenberg>
BLONDEL will sample them at 1.25 Gsps but other scopes might go faster
<azonenberg>
the comparator is good out to about 3 Gbps data rate so plenty of headroom
<azonenberg>
All of them are named after famous electrical engineers
<azonenberg>
Andre-Eugene Blondel invented the electromechanical oscillograph (basically an electromagnet moving a pen over a moving sheet of paper)
<Kliment>
Who is VOLLUM named after?
<azonenberg>
William Duddel invented the moving-coil mirror oscillograph
<azonenberg>
Jonathan Zenneck invented the CRT oscilloscope
<Kliment>
The others sound vaguely familiar
<_whitenotifier-c>
[scopehal-cmake] tomverbeure commented on issue #10: Top of tree build is broken - https://git.io/JfaS9
<_whitenotifier-c>
[scopehal-cmake] tomverbeure closed issue #10: Top of tree build is broken - https://git.io/Jfaie
<azonenberg>
Howard Vollum and Melvin Murdock were co-inventors of the triggered-sweep oscilloscope
<Kliment>
Ah :)
<azonenberg>
Mead and Conway were co-authors of a famous VLSI textbook, i forget their first names
<azonenberg>
other projects under the umbrella: Maxwell is a 1U logic analyzer that will host up to ten MEAD or CONWAY pods for 80 bits of LA at 1.25 Gsps
<Kliment>
What's the probe called?
<azonenberg>
DENNARD is a low channel count LA, probably 1-2 MEAD/CONWAY pods, using Kintex-7 GTXs for sampling at 12.5 Gsps
<Kliment>
I note HALL has not yet been used :)
<azonenberg>
the passive probe doesnt actually have a codename as it started out separate, it's just the AKL-PT1
<monochroma>
has azonenberg caught a new worker bee? ;)
<azonenberg>
BRAUN, after the inventor of the phased array (Karl Ferdinand Braun) is a planned low bandwidth active probe
<azonenberg>
Anyway, right now most of these projects are just ideas on a roadmap
<Kliment>
monochroma: not really, but I'm happy to orbit the hive
<azonenberg>
BLONDEL has the prototype you saw, which works and is integrated with scopehal end to end as a single channel system, but the tcp offload engine is somewhat simplistic and doesn't handle windows filling up or dropped packets yet
<azonenberg>
MEAD has a ~50% complete schematic
<Kliment>
azonenberg: So let's call the probe HALL
<monochroma>
lol
<azonenberg>
the passive probe? Sure, we didn't use him yet
<Kliment>
CAMENZIND is also currently unused
<azonenberg>
Kliment: so right now the active work going on is... general glscopeclient development
<azonenberg>
there is a SMA characterization board for a new connector at oshpark to test some improvements that looked good in sonnet sim but havent been tested on a real board yet
<azonenberg>
as well as a respin of HALL with that connector and some stackup changes to match
<azonenberg>
i need to find time to finish the schematic for MEAD, then send it out to fab
<Kliment>
oh fun, gtkmm
<Kliment>
my third-least-favorite UI toolkit
<azonenberg>
Yes, although all of the rendering etc is GL or custom cairo stuff
<azonenberg>
lol what do you like?
<Kliment>
nothing
<azonenberg>
(hey, it's not MFC :p)
<Kliment>
Qt is kinda nice except it's controlled by assholes
<azonenberg>
anyway then we need to make enough progress on BRAUN to define the active probe interface on the BLONDEL acquisition board. We don't need the actual probe to be done
<azonenberg>
just enough to make sure we can talk to it
<azonenberg>
the plan is for active probes to have a SMA connection for data and then USB-C for control and power
<Kliment>
but in general UI frameworks are all trashfires
<azonenberg>
using a custom alternate mode that uses the high speed TX/RX pairs to supply +/- 7VDC power for the probe frontend (since USB-PD can only supply one voltage and we want to avoid SMPSes in the probes for noise reasons, so we need LDO-compatible voltages)
<azonenberg>
then either using the usb2 data channel or i2c over one of the alt mode pins for setting gain/offset etc
<azonenberg>
so we need to pick out MCUs and USB PD controllers etc and at least prototype the voltage negotiation and verify we can pass data before i do the full 4x AFE + ADC board
<azonenberg>
since that same board also will host the active probe usb-c ports
<azonenberg>
(the front panel will be SMA-USBC alternating for each of 8 channels, then ext trig etc at the far right)
<azonenberg>
additionally, we need to build a bringup test board for MEAD
<Kliment>
hmm we are going to need a mux that can handle +-7V
<azonenberg>
yes, but those usb ports will not be SS data capable
<azonenberg>
it will just be a high-side pfet or similar
<Kliment>
Right, what's on the other pair?
<azonenberg>
those ports will be usb 2.0 only, the only reason for the negotiation is to ensure we don't fry an actual usb device plugged in by accident :p
<azonenberg>
the mcu will run off vbus to handle the negotiation
<azonenberg>
other pair?
<Kliment>
There are two hs pairs
<azonenberg>
there's four SS data pairs, my plan was to use all TX pairs for +7 and all RX for -7
<azonenberg>
since they're tiny wires and i wanted a decent bit of current capacity
<Kliment>
no, there are two pairs
<Kliment>
in a normal cable
<azonenberg>
not if it's a C-C afaik
<Kliment>
I thought the four-pair variants were just for TB
<azonenberg>
anyway i'll hook up all tx pins to +7 and all rx to -7 and whatever the cable has gets used
<azonenberg>
Then at some point we need to build a bringup testing board for MEAD, basically a board that mates with an INTEGRALSTICK and just hooks up the SFF-8087 connector to power and the FPGA's LVDS I/Os
<azonenberg>
it should just be a barrel jack, a DC-DC to step 12V down to 5V, a SFF-8087, and a Q-strip
<azonenberg>
the final scope wont use an integralstick but its a convenient form factor for testing
<azonenberg>
Once all of the pieces are tested in isolation, we can start work on integrating them into the full system
<azonenberg>
doing final board layouts etc
<azonenberg>
We're thinking of using the FUSB302B for the USB PD stuff
<Kliment>
azonenberg: Ah, you're right, usb3.2 spec requires four diffpairs
<azonenberg>
yeah. so if you use a non-3.2 cable you might get higher I*R losses
<Kliment>
and the TB cables have repeaters
<Kliment>
so we have to make sure to not use those because we'll fry the repeaters
<azonenberg>
Correct. That's where the PD chip comes in, afaik it can detect active cables
<azonenberg>
and we can display an error
<Kliment>
We can detect electronically marked cables
<Kliment>
but most of those don't have active repeaters
<azonenberg>
The other option would be to supply a low DC voltage first
<azonenberg>
something that won't break the AC coupling caps on a cable
<azonenberg>
and if we see voltage flow, then turn it on full blast
<azonenberg>
just like a voltage divider with 10K or so ohm impedance pulling one line high and one low
<Kliment>
I'd rather have actual negotiation in place
<electronic_eel>
I've been browsing through the FUSB302B datasheet and I don't think it will make life easier for defining a custom alternate mode. You have to create your own packets, write them into a buffer and so on. A MCU with integrated PD, like the STM32G0, will be about the same effort I guess
<Kliment>
Because people will totally want to charge their phone with it
<azonenberg>
electronic_eel: ok that could work too
<azonenberg>
Kliment: the basic goal is to reuse a commonly available connector (usb-c) and not destroy the probe if plugged into a normal usb host
<electronic_eel>
But I'm still not convinced that going the PD alternate mode route is worth it
<azonenberg>
or a normal usb device if plugged into the probe socket
<azonenberg>
electronic_eel was pushing for a proprietary alt-mode negotiation via the usb2 data channel
<azonenberg>
and not supporting PD at all
<azonenberg>
i.e. send some sequenec of packets to a certain endpoint to turn on the power
<azonenberg>
i wanted to go the more standard compliant route if possible
<azonenberg>
i do not intend to support full PD as in Vbus > 5V
<electronic_eel>
I was thinking about a regular usb cdc serial over usb hs
<Kliment>
azonenberg: I'm not saying we should support it, I'm saying people will totally plug a usb-c cable hanging around on their bench into their phone
<electronic_eel>
sorry, usb fs (12 mbit)
<electronic_eel>
of course they are plugging in their phone there
<electronic_eel>
in both scenarios the scope will not see the probe it expects and not switch on the higher voltages
<azonenberg>
Yeah
<azonenberg>
my primary goal is harm reduction, secondary goal is standards compliance to the extent practical without a lot of extra work
<azonenberg>
i do not intend to go for usb logo compliance here
<azonenberg>
advertising our product as usb compatible is completely unnecessary
<Kliment>
also USB-IF are assholes and we don't want to support them
<azonenberg>
i'm reusing a commonly available connector and taking reasonable precautions to ensure non-destruction of both devices if mated to real usb devices
<azonenberg>
that's it
<azonenberg>
if you have ideas on an alternative to usb-c for this i'd use that too
<Kliment>
displayport!
<azonenberg>
it just looks like the best choice for power and data on a small connector with commonly available cables
<Kliment>
Or HDMI
<Kliment>
They have better shielding too
<electronic_eel>
the cables for dp or micro-hdmi are much thicker and can't be plugged in in either direction
<azonenberg>
Non issue, this is a power/control cable
<azonenberg>
it's in parallel with a SMA for the RF link
<Kliment>
eSATA is sadly unobtainium now, it would have been ideal
<electronic_eel>
eSATA sucks as it doesn't properly latch
<azonenberg>
since i dont have tek/lecroy/keysight's clout to do custom multiconductor cables with coax surrounded by control lines
<Kliment>
Anything wrong with ethernet?
<electronic_eel>
yeah, a custom probe interface with one connector is the competition
<azonenberg>
Kliment: massively larger
<azonenberg>
PoE probes would be cool though :P
<electronic_eel>
so needing two connectors already is a downside
<Kliment>
There were some display connectors on HP workstations back in the day with full serial and three coaxes (RGB) in the same connector
<Kliment>
early 90s
<azonenberg>
SGI had some similar stuff IIRC
<Kliment>
Yeah
<azonenberg>
i feel like i saw something on an onxy built like that
<azonenberg>
onyx*
<Kliment>
the SGI was display only though
<Kliment>
The HPs had the keyboard on the same cable
<electronic_eel>
hehe, those were the days with these thick connectors
<monochroma>
SGI, Sun, and HP (depending on the workstations) used 13w3 connectors for their displays
<electronic_eel>
and fully custom crts for these workstations, you couldn't just hook on a standard vga bnc there
<monochroma>
electronic_eel: sure you could, the monitor just needed to support Sync-on-Green
<Kliment>
azonenberg: lockable, single connector, enough pins, has coax, nobody will try to pluga a phone in it
<electronic_eel>
I tried it once with a old sgi workstation and vga monitor with bnc inputs. it didn't work. but this was like 25 years ago and I didn't know much about electronics back then
<monochroma>
electronic_eel: hehe, yeah the it used to be a pain trying to find a VGA monitor that supported SoG
* monochroma
has a large collection of SGI/sun/hp workstations and servers
<electronic_eel>
the vga monitor was a better one, with lot's of options and dip switches and stuff, but I don't remember all the details
<Kliment>
monochroma: You wouldn't happen to be familiar with domainOS
<monochroma>
Kliment: unfortunately i never had a chance to get the hardware to play with it
<Kliment>
monochroma: Where are you based?
<Kliment>
monochroma: I know a site where it's still in active use
<monochroma>
us/washington
<Kliment>
aww, too bad, wrong continent
<monochroma>
is it a government installation? that and industrial applications seem to keep a lot of old systems around
<Kliment>
No, it's an electronics CAM workstation
<Kliment>
Installed in 1991, still operational
<monochroma>
heh!
<Kliment>
Including the manufacturing hardware attached to it
<Kliment>
monochroma: It's the weirdest arch
<Kliment>
monochroma: Normal HP 400 series workstation with a graphics and io accelerator card
<Kliment>
the accelerator card has a 386 on it
<Kliment>
yes, an intel chip
<monochroma>
heh!
<Kliment>
the hardware is attached directly to the intel's i/o bus via a dual-port memory implemented with discrete logic
<Kliment>
in a box that's bigger than the workstation
<monochroma>
o.o
<Kliment>
Really exciting setup, best experienced in person
<Kliment>
then it speaks to a photoplotter via 4 coax cables
<Kliment>
driven by a serdes implemented in discrete logic
<Kliment>
the photoplotter end has a PLL implemented in discrete logic on many boards attached to a backplane bus
<electronic_eel>
and what does it do? plot film for pcb manufacturing?
<Kliment>
Yeah
<electronic_eel>
is it at a pcb house or some small in-house prototype plant?
<Kliment>
it's a pcb house
<electronic_eel>
hmm, seems like they didn't invest in new gear for some time. do they keep up well with the chinese competition?
<Kliment>
They have newer gear but this works
juli964 has joined #scopehal
<_whitenotifier-c>
[scopehal] azonenberg pushed 3 commits to master [+6/-9/±17] https://git.io/Jfado
<_whitenotifier-c>
[scopehal] azonenberg 46dcb36 - Ported overshoot measurement to unified model
<_whitenotifier-c>
[scopehal] azonenberg 429dd58 - Ported undershoot measurement to new unified framework
<_whitenotifier-c>
[scopehal] azonenberg db4d095 - Moved peak-to-peak measurement over to new unified framework. Fixes #83.
<_whitenotifier-c>
[scopehal] azonenberg closed issue #83: Allow measurements to return one value per UI instead of just one for the whole waveform - https://git.io/JeQQs
<_whitenotifier-c>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/Jfad6
<_whitenotifier-c>
[scopehal-apps] azonenberg 1824351 - glscopeclient: removed all references to libscopemeasurements as it no longer exists
<_whitenotifier-c>
[scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/Jfadi
<_whitenotifier-c>
[scopehal-cmake] azonenberg 825ce3b - Removed remainder of libscopemeasurements as it no longer exists
<_whitenotifier-c>
[scopehal] azonenberg opened issue #117: Remove Measurement class and fold all remaining helper functions into ProtocolDecoder - https://git.io/JfadX
<_whitenotifier-c>
[scopehal] azonenberg labeled issue #117: Remove Measurement class and fold all remaining helper functions into ProtocolDecoder - https://git.io/JfadX
<_whitenotifier-c>
[scopehal] azonenberg labeled issue #117: Remove Measurement class and fold all remaining helper functions into ProtocolDecoder - https://git.io/JfadX
<_whitenotifier-c>
[scopehal] azonenberg pushed 1 commit to master [+0/-2/±17] https://git.io/JfaFI
<_whitenotifier-c>
[scopehal] azonenberg ef8cc7c - Refactoring: folded last vestiges of Measurement class into ProtocolDecoder. Fixes #117.
<_whitenotifier-c>
[scopehal] azonenberg closed issue #117: Remove Measurement class and fold all remaining helper functions into ProtocolDecoder - https://git.io/JfadX
<_whitenotifier-c>
[scopehal-cmake] x44203 forked the repository - https://git.io/JfaFA
<_whitenotifier-c>
[scopehal-cmake] x44203 opened pull request #11: Readme with installation instructions - https://git.io/Jfabs
<miek>
azonenberg: no, i've not touched it. i might've mentioned that there's one at the hackerspace, but i won't have access to that for a long while now
<azonenberg>
miek: let me see who it was then
<miek>
degi just got a rigol?
<azonenberg>
oh maybe thats who i was thinking of
<Degi>
Hm yes I should start working on that sometime
<azonenberg>
yes rigol support i would say is actually fairly high priority, because so many hobbyists have them
<Degi>
Rigol has some nice docs for the command set I think. Maybe next weekend or so...
<Degi>
Oh yes
<azonenberg>
if anything more important than lecroy
<azonenberg>
in terms of number of people it will help
<azonenberg>
let's see, 24c eeprom
<azonenberg>
i should just grab a random devkit with one and bang that out quickly
<_whitenotifier-c>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JfaAJ
<_whitenotifier-c>
[scopehal] azonenberg 5b91e7c - LeCroyOscilloscope: disable channel interleaving on startup until we can properly detect/handle interleaved channels. Fixes #76.
<_whitenotifier-c>
[scopehal] azonenberg closed issue #76: Disabling channel 1 or 4 on WaveRunner 8000 series causes a hang when in 20 Gsps mode - https://git.io/Je1ZL
<azonenberg>
monochroma: and scopehal-apps:#66, system requirements check on startup
<azonenberg>
where do we stand on that?
<monochroma>
have not had time to look at yet
<azonenberg>
OK
<_whitenotifier-c>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JfaAZ
<_whitenotifier-c>
[scopehal-apps] azonenberg 17aff52 - OscilloscopeWindow: recreate a waveform group before adding a channel if we don't have any groups. Fixes #68.
<_whitenotifier-c>
[scopehal-apps] azonenberg closed issue #68: When all waveform views are closed, adding new channel fails because there's no views to add them to - https://git.io/JvuOH
bvernoux has joined #scopehal
<Kliment>
Degi: about rigol stuff, poke apo
einthecorgi2 has joined #scopehal
<einthecorgi2>
Hey All, just introducing myself. Im @einthecorgi2 on twitter. My name is Reiner. I do embedded systems development work in RF and communications systems. Currently im working on a FOSS spectrum analyser (or at least the IF and sampling side of things). Although not directly related to scopehal yet I may be able to contribute to the sampling side of things for custom hardware later on.
<electronic_eel>
einthecorgi2: Hi
<electronic_eel>
so you are interested in helping with scope hw development?
<einthecorgi2>
yes :)
<einthecorgi2>
I have pretty good prototype and test gear and should be able to do embedded debugging
<electronic_eel>
also there is a prototpye for the hmcad adc, one directory level up
<electronic_eel>
current state is that he has input from the scope, digitizing and streaming out into scopehal working
<electronic_eel>
but there are some smallish issues with the afe board
<electronic_eel>
the scope will also have a logic analyzer input (MSO)
<electronic_eel>
you'll be able to plug in two different, but similar, kinds of logic pods into it, called MEAD and CONWAY
<electronic_eel>
one is high-z for grabber probes, the other for 50 ohms probes
<electronic_eel>
the logic analyzer side is where the current focus is
<einthecorgi2>
very cool. I am sure a lot has already been done for the logic heads but It might be cool to pull from the OSHW Rigol MSO5000 logic head.
<einthecorgi2>
okay
<electronic_eel>
the logic pods will have comparators and send the output of them over diff lines to the fpga on the scope
<electronic_eel>
this is very similar to the rigol pods
<electronic_eel>
we have seen the reverse engineering of the rigol pods on the eevblog forum
<electronic_eel>
the high-z frontend for the logic pods is not developed yet, we were thinking about a rc-divider, but haven't done much design work
<einthecorgi2>
very cool. I forget the comparator they used but I think it was capable of 300Mhz or so. But thats good to hear. I will keep my eye on the chat and get to know the project a bit better and then find a place to jump in.
<electronic_eel>
the plan was to get the 50 ohms input pod to work first, because the frontend should be easier
<electronic_eel>
there are full logs of the chat available, see channel topic
<einthecorgi2>
thank.
<einthecorgi2>
thanks*
<electronic_eel>
the comparator we plan to use on the pods is LMH7322, I think it is the same as in the rigol pods
<electronic_eel>
einthecorgi2: do you have experience with high-z la frontends?
<electronic_eel>
but I didn't continue the work yet. the values were just guessed and I think next step would be to build a test setup and do some measurements to get an idea if the values go in the right direction
<electronic_eel>
oh, shouldn't have muted the quits :/
<electronic_eel>
now I hope I didn't scare them
<monochroma>
lol probably not, they timed out
<Degi>
Hm maybe replace R2 and R3 with something smaller like 50 ohms, C1 with like 500 fF and C2 with idk 5 pF?
<Degi>
Idk why they put such large capacitors there
<electronic_eel>
Degi: my plan was to simulate first what rigol were doing, then improve upon that
<electronic_eel>
I think they chose the larger capacitors because of parasitic capacitances and they didn't want them to have too much of an influence
<Degi>
Hmh I think it should be possible to design around that
<Degi>
But that may require individually shielding channels...
<electronic_eel>
you mean by improving pcb layout?
<Degi>
yes
<Degi>
Heck we could use the PCB as a capacitor even
<Degi>
Good on 4 layer board with 0.1 or 0.2 mm top layer
<Degi>
I mean it doesnt need to be super precise
<Degi>
Maybe on a 4 layer stackup which is like 0.1 mm, 1 mm, 0.1 mm you could use layer 1 to 3 as the input and 3 to 4 as the output capacitor
<Degi>
Or even 1 to 4 as input and 4 to 3 as output, that way you can have ground on layer 3 with a cutout and dont need any vias
<electronic_eel>
I think a big improvement can be made by not doing a 10:1 division, but 4:1 or similar. that should be enough to give us ample voltage range
<Degi>
yeah that too
<Degi>
But I'd really consider PCB capacitors for this one, especially since that saves on parts and should be sufficiently stable and repeatable
<Degi>
And it has less parasitic inductance
<Degi>
But requires some vias, for the one resistor
<electronic_eel>
the question is where to put this circuit. I think the top part (R2, R3, R4, C1) could be on a very small pcb, directly plugged into the grabber
<Degi>
Ah
<electronic_eel>
this will reduce the load and mismatch added to the dut
<Degi>
Hmh
<Degi>
We could use a coax cable as a capcaitor
<Degi>
Not sure, maybe we should use coax with grounded outer side to prevent EMI. Triax would be ideal but probably pricy
<electronic_eel>
don't think too fancy, we want to build this thing easily and cheap
<Degi>
Hmh wont this version have 2.54 mm headers?
<electronic_eel>
I think we should try to start with regular jumper wire and measure how it performs and where exactly problems come from
<electronic_eel>
yes, 2.54mm headers
<Degi>
Not sure if it makes much sense to put components into the grabber then, that'd be a lot of extra work
<electronic_eel>
we could use the same mill max connector azonenberg plans for the passive probe. that can be soldered on a pcb and also goes onto the ez hook probes
<electronic_eel>
the output would either be wire, directly soldered on, or a regular pin header
<electronic_eel>
yes, these probes, but design a very small pcb with just the few passives on it and protected by a bit of heatshrink tube
<Degi>
And then glue that onto the probe?
<electronic_eel>
glue or plug, tbd
<electronic_eel>
or solder
<Degi>
Hmm, how bad is a wire tho
<electronic_eel>
you don't want like 25cm wire added to the dut
<electronic_eel>
gives reflections
<Degi>
Hm yes but less than 15 cm should be fine
<electronic_eel>
you already have like 5 with the grabber itself and then you want to leave the dut board and go into the la pod
<Degi>
hmm
<electronic_eel>
don't think 10cm will be enough for that
<Degi>
We can just add like a 300 ohm series resistor right after the probe
<Degi>
That should stop reflections
<electronic_eel>
that would be the other option
<Degi>
And one at the pod side
<Degi>
Maybe just one at the pod side might be sufficient
<electronic_eel>
I think we have to build some kind testbed which shows the problems we expect, then try the different versions and see how it performs
bvernoux has quit [Quit: Leaving]
tverbeure has joined #scopehal
<tverbeure>
Andrew, I have a bunch of questions about intended behavior of SCPITransport.
<tverbeure>
(I assume that this is the right forum for that?) My Siglent SDS2304X does not support a raw socket. It only supports VXI-11. So I'm trying to use liblxi (https://github.com/lxi-tools/liblxi) and create a SCPILxiTransport.
<tverbeure>
Getting glscopeclient to connect to the scope using SCPILxiTransport was easy. However, later one it gets into all kinds of issues. From reading the code, it seems that SCPISocketTransport can burst multiple SendCommands, and then burst issue their respective ReadReplies (See LeCroyOscilloscope::BulkCheckChannelEnableState()). I'm pretty sure VXI-11 doesn't allow this, and liblxi definitely doesn't.
<monochroma>
last i knew there were quirks added to the drivers for each scope
<tverbeure>
Since scopehal has refactored the transports into a separate SCPITransport class, I think SCPIDevices will need to get feedback from SCPITransport whether or not bulk send and replies are supported? It also means that all SCPIDevices should at the minimum support synchronous send/reply operations, and bulk send/reply only as a performance optimization.
<_whitenotifier-c>
[scopehal] tomverbeure commented on issue #118: Add LXI VXI-11 SCPITransport class - https://git.io/JfVm9
<_whitenotifier-c>
[scopehal] tomverbeure edited a comment on issue #118: Add LXI VXI-11 SCPITransport class - https://git.io/JfVm9
<azonenberg>
tverbeure: hey sorry just got up, was working late debugging
<azonenberg>
Hmmmm
<azonenberg>
What i want to avoid is adding TOO much complexity to the various drivers
<azonenberg>
the lecroy driver in particular is pretty heavily optimized at this point and i want to avoid doing TOO much modification to
<azonenberg>
As a start, how about we add a new method IsCommandBatchingSupported() to SCPITransport that returns true in all current implementations and false for LXI?
<tverbeure>
Yes. That was my thought as well. I'll see how far I can get with that.
<azonenberg>
the Siglent driver is derived from the LeCroy driver but overrides a lot of functions due to various quirks of siglent's implementations
<tverbeure>
Do you have any guess how much batching is used in general?
<azonenberg>
Error_404 wrote it and was mostly targeting SDS3000 series IIRC
<azonenberg>
My expectation is that the siglent driver has a small amount because it was based on the lecroy
<azonenberg>
most other drivers should not have much or any
<azonenberg>
because they were all "minimal viable product" level drivers that weren't optimized much
<azonenberg>
I use the lecroy driver on a daily basis and spent a lot of time tuning it
<azonenberg>
So you're going to find a lot more optimization there
<tverbeure>
Right now, I'm just trying to get anything to work at all with my scope. After that, I think there will need to be some refactoring or separation between Siglent and LeCroy: whatever changes I make for Siglent may break the LeCroy. It might be better to duplicate some code.
<azonenberg>
The siglent driver overrides some of lecroy's virtual functions laready