<Bird|otherbox>
azonenberg: did you have thoughts on how #118 should look?
_whitelogger has joined #scopehal
<Bird|otherbox>
also, re: dialog modality -- I can see where you're going with things that set instrument parameters and whatnot, but I don't see a reason something like a file chooser, about box, or global prefs should be modeless
<Bird|otherbox>
one other thing: have you looked at git subtree at all?
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/JUaqm
<_whitenotifier-f>
[scopehal] azonenberg 32d9629 - Merged multiple implementations of string_base_name, renamed to BaseName to fit general project naming convention
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JUaqY
<_whitenotifier-f>
[scopehal] azonenberg opened issue #267: Add APIs for displaying channel names on instruments that support this - https://git.io/JUamY
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #267: Add APIs for displaying channel names on instruments that support this - https://git.io/JUamY
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #267: Add APIs for displaying channel names on instruments that support this - https://git.io/JUamY
Nero_ has joined #scopehal
m4ssi has joined #scopehal
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #191: Channel properties dialog should allow reading/writing display names of channels on the hardware - https://git.io/JUam3
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #191: Channel properties dialog should allow reading/writing display names of channels on the hardware - https://git.io/JUam3
Nero_ is now known as NeroTHz
<azonenberg>
NeroTHz: So i'm working on tek 5/6 series support in scopehal now. It will be nice to have another midrange scope as a flagship target for the tool rather than only lecroy
<azonenberg>
We can expand older tek support later as time/resources permit but i wanted to target a current gen model first
<NeroTHz>
okay
<azonenberg>
I have temporary remote access to a mso64 and will be renting a mso5 in a month or so for additional testing and optimization
<azonenberg>
Keysight and R&S support are still on the to-do but lower priority as the guy offered up the mso6 at a convenient time and my local rental shop has a better price for the mso5 than the comparable keysight/R&S models
<azonenberg>
and since right now glscopeclient's R&D budget is my wallet, that's an important consideration :p
<azonenberg>
Once i have 5/6 support reasonably well developed, and bvernoux has finished the windows support updates, we can start thinking about testing on more tek models and expanding the documentation to list what works and what doesn't
<azonenberg>
I'm doing dev off the 5/6 programming guide and i have no idea how similar other tek models' command sets are
<azonenberg>
LeCroy has a beautifully orthogonal SCPI API, to the point that they don't even have per model programming guides
<azonenberg>
they have one, total, for all MAUI scopes
<azonenberg>
then another one or two for their low-end non-windows scopes which are rebranded siglent/owon/whatever gear
<Degi>
I wonder if LXI is faster than SCPI for the Rigol
<azonenberg>
as a general rule, LXI is slower because it does not appear to support out of order command processing
<azonenberg>
you can't send a bunch of requests and get a bunch of responses
<Degi>
Huh, SCPI can do batches?
<azonenberg>
it's a line buffered protocol, you jsut send multiple lines in one (or several) TCP segments before waiting for a reply
<azonenberg>
pretty sure that doesn't work with LXI
<Degi>
I think sometime I might take a look again at the rigol driver. Scopehal is pretty nice but the rigol interface was relatively slow (there were suspicions that it was a hardware limit, it was suspected that samples were transferred over SPI).
<azonenberg>
looool
<azonenberg>
It would be fun to take a rigol apart and confirm this
<azonenberg>
But yes, optimization to existing drivers is certainly welcom
<azonenberg>
welcome*
<Degi>
Hm, if I had a xray machine...
<azonenberg>
My suspicion is that it's not SPI, but that the CPU is just really slow and the firmware is unoptimized
<azonenberg>
Still nothing we can control
<Degi>
Hmm... Make CFW heh
<azonenberg>
also has anyone done relative performance comparisons of DS1000Z vs MSO5000 series rigol under similar conditions?
<Degi>
I assume it does graphics on the FPGA huh
<Degi>
And then samples over lan thru the CPU
<azonenberg>
That is my understanding too
<azonenberg>
Rather than doing lan on the fpga :p
<Degi>
I think I have friends with a 1000 series one...
<azonenberg>
I'm interested in being able to put comments on the remote performance of various instruments in the manual
<azonenberg>
talking about the best WFM/s we've been able to get with various memory depths and connections
<noopwafel>
the rigol is indeed just painful :(
<noopwafel>
azonenberg: the tek commands seem like they're close enough to be worth having just one tek driver so far, but definitely no lecroy situation..
<azonenberg>
yeah. I'm dreaming of having LeCroy's level of orthogonality in our own hardware drivers eventually
<azonenberg>
but i expect early on we will have to make some breaking changes to the protocol in order to accomplish this
<Degi>
Hm, what is orthogonality here? Command set independent on device?
<azonenberg>
Yes, or more generally being able to do the same things to "whatever"
<Degi>
Maybe if a device has multiple things, then they can each have their own endpoints? For example if we make a scope + AWG combo
<azonenberg>
That is a definite thing that will happen
<azonenberg>
I hate how lecroy has only one endpoint for theirs ando nly supports one socket connection
<Degi>
At least that's how I'd make a PCIe device, heheheh (since you can have 8 virtual channels)
<azonenberg>
so basically you cant use the awg and scope from separate apps
<Degi>
Lolll
<azonenberg>
Although scope+LA will be one endpoint since in my view a LA is just a scope with a 1-bit ADC on each channel
<Degi>
Hm okay, makes sense
<Degi>
Maybe instead of making scopes we can make LAs with a scope addon which combines n channels xD
<azonenberg>
Degi: an analog acquisition pod for MAXWELL would not be beyond the realm of possibility
<Degi>
Hm, now that I think about it, for maxwell that sounds good actually.
<azonenberg>
although it would need an FPGA to convert the native data format to 8 bits of LVDS with no clock (oversampled or similar)
<Degi>
Can you supply clock?
<azonenberg>
not a big one, but an fpga
<azonenberg>
The pods have only eight LVDS pairs. We can use them as inputs or outputs arbitrarily
<Degi>
Oh neat
<azonenberg>
however i don't think most pods have clock inputs on them FPGA side
<Degi>
But limited to 1 GS/s?
<azonenberg>
The FPGA can actually do up to about 5 Gsps oversampling the LVDS. Which is enough to do clock recovery on a 1.25 Gbps 8b10b coded serial data stream
<azonenberg>
So if we were to do an analog pod for maxwell it would need to take in 12V power and UART control plus a sampling clock
<azonenberg>
and output 7 lanes of 8b10b coded sample data
<azonenberg>
at not much more than 1.25 Gbps
<azonenberg>
So that's 7 Gbps of sample data
<Degi>
Hm sure that you cant go a little higher? To like 2.5 Gbps with no aliasing?
<azonenberg>
Which would be enough to run a hmcad1520 at 500 Msps in 12 bit mode on a single channel
<azonenberg>
Degi: No. You need 4x oversampling to do clock recovery
<azonenberg>
xilinx has an appnote on this to oversample SGMII
<azonenberg>
it's about the limit of the io buffers
<Degi>
Well, do you need clock recovery? I mean isn't the whole system phase coherent?
<azonenberg>
Propagation delay through the cable is unknown and may vary as the cable is bent etc
<Degi>
hmnh
<azonenberg>
The SFF cables are not phase stable
<Degi>
Oh okay, then only short cables heh
<azonenberg>
We could squeeze a little more bandwidth out by using 64/66 instead of 8b10b
<azonenberg>
Up to 8.48 Gbps i think
m4ssi has quit [Ping timeout: 260 seconds]
<azonenberg>
down from the 8.75 with no line coding
<Degi>
Line coding is for clock recovery?
<azonenberg>
Yeah
<azonenberg>
This would be enough to run a hmcad1520 at full 640 Msps. however i feel this would be a pain because that's not an even integer divisor of the 2.5/5 Gsps the analog channels run at
<Degi>
Hm I guess you can do 64/65 maybe, since you dont need DC balance
<azonenberg>
500 is a nice round number
<Degi>
For extra fun, run it at a prime number of hertz
<azonenberg>
This would kinda be the inverse of tek's approach
<Degi>
Hmh? Whats theirs
<azonenberg>
It would be a first-class logic analyzer that with some coaxing can get a low-speed analog input replacing a bank of 8 digital channels
<azonenberg>
Tek makes scopes that you can put 8-bit LA pods onto probe ports of
<azonenberg>
Also i do want to 64/66 now that i think about it. for other reasons
<azonenberg>
that would allow 8 bit 1 Gsps mode
<azonenberg>
As well as 12 bit 500 Msps
<azonenberg>
So basically we could build a slightly more expensive but higher channel count DUDDELL out of MAXWELL plus custom acquisition pods
<azonenberg>
I do not want to replace DUDDELL as having it integrated on one board will cost less
<azonenberg>
But we could prototype parts of it as a MAXWELL pod
<Degi>
Hmmm yes
<Degi>
Kinda like the idea of being able to choose between digital and analog channels
<Degi>
Maybe a pod with 8 analong channels at 100 MS/s or so would be interesting too. Or a really big number of channels at low sample rates... heh.
<azonenberg>
Yes if we have FPGAs in the pods we could be extremely flexible
<azonenberg>
The big issue is, if we had a few extra LVDS pairs on the connector we could do clock and 8 bit data and not need an FPGA in the pod. which would greatly reduce costs
<azonenberg>
but we are limited by the connector to 8 diffpairs total
<Degi>
Hm, is a second connector an option
<Degi>
Also MAXWELL doesn't seem very hobbyist friendly
<Degi>
(Like cost wise)
<azonenberg>
It's not, that was never a design goal
<Degi>
Yes, though I guess DUDDELL will cost similarly?
<azonenberg>
It will have one big fpga instead of one big fpga plus a small one in each pod
<Degi>
Do small FPGAs add big cost?
<azonenberg>
about half the cost of a full maxwell system will be in the pods
<azonenberg>
all of the extra pcbs, assembly, enclosures, cables, etc adds up when you have 12 of them
<Degi>
Huh, doesn't the main device cost like 3 k... Heh
<Degi>
I mean it makes sense that it'd cost that much, especially when only a few are made...
<azonenberg>
The pods are $171.20 each, assembled, for the PCB. That's $2054 for a full system assuming you are building two full systems at once
<azonenberg>
Add in an estimated 25% import duty because the Dear Leader doesn't like China, throw in another $514 in taxes
<azonenberg>
Then $141 of front panel LCDs, $156 of SFF8087 cables
<azonenberg>
and... i dont have exact prices for the enclosures but CNC'd aluminum in low volume is a bit pricey. I wanna say probably about another $1-1.5K in enclosures
<Degi>
Does CNC get more cost efficient in high volumes? Or would you do that with a mold?
<azonenberg>
It gets massively more cost effective in volume
<azonenberg>
25 units is right about the crossover where it's cheaper than 3d printing, which has minimal economies of scale
<azonenberg>
(assuming high grade SLS printing rather than FDM)
<azonenberg>
If we were making a lot more MAXWELLs that would be a different story. But it wouldn't surprise me if these two are the only ones ever built
<Degi>
Why is that? I mean you have no mask (like with PCB's) etc. and theoretically the bots could be reprogrammed after each finished part...
<azonenberg>
The fixturing, CAM design, engineering review, etc
<monochroma>
Degi: setup time
<azonenberg>
monochroma: btw what do you think of this idea? building low speed single channel scope pods that can replace a digital channel on maxwell
<Degi>
Oh right, kinda forgot that they review stuff
<monochroma>
azonenberg: what's the use case?
<azonenberg>
I think we could basically fit a 4 channel 100 MHz BLONDEL acquisition system, or a single channel 250 MHz DUDDELL acquisition system, into a single maxwell pod
<azonenberg>
you'd need to stuff an FPGA in there to shuffle the native HMCAD1520 (clock in, clock out, frame out, 8 lanes data out) to 7 striped lanes of 64/66b
<azonenberg>
but that shouldnt be too hard
<azonenberg>
It would let us prototype those acqusition systems, perhaps even using the same boards as the full rackmount instruments hooked up to a tiny fpga board
<azonenberg>
It would also, more importantly, allow a single MAXWELL to have an arbitrary mix of analog and digital channels
<azonenberg>
For example, you could have four BLONDEL pods with a combined 16x 250 Msps/100 MHz/8 bit scope channels
<monochroma>
if it were me, i would give them an ethernet interface and clock in/out, and trigger
<azonenberg>
Then two DUDDELL pods with a combined 2x 250 MHz / 1 Gsps / 8 bit scope channels
<azonenberg>
and then six more 8-bit LA pods
<azonenberg>
And that has much less bandwidth. My proposed refclk in / 7-lane 1.25 Gbps 64/66b out interface gives you 8.48 Gbps from each pod to the MAXWELL
<azonenberg>
vs 1 Gbps for ethernet. Also we can do a very simple gearbox using a tiny fpga, like an xc7s15 or something
<azonenberg>
ethernet would need a lot more since we'd probably want to run IP on top of it etc
<azonenberg>
also ethernet doesnt have the bandwidth for streaming
<Degi>
Hm, I wonder if we could make DAC pods too and then do processing in the FPGA in MAXWELL
<azonenberg>
this interface would allow full streaming. it would basically just be a remote ADC+AFE pod that streams samples at full rate, all the time, to the kintex
<azonenberg>
Degi: yes i think so. there's a lot of room for extensibility
<azonenberg>
It's not going to be the most cost effective solution but will be a nice prototyping platform and great for lower end stuff
<Degi>
I wonder how hard it would be to allow to write custom gateware and then recompile the whole FPGA. Maybe the FOSS toolchain will be out soon, at least for the ECP5 it is 5-10x faster than the vendor provided one.
<monochroma>
azonenberg: ah, i was thinking 10Gig-E and you can just fire UDP packets out, no need for a full IP stack
<azonenberg>
I'm not holding my breath on a 7 series toolchain with serdes and, more importantly, multi clock support etc
<azonenberg>
monochroma: i'm thinking about interfacing something with the existing maxwell hardware
<azonenberg>
all of the serdes are in use
<azonenberg>
all you have is 8 lanes of ISERDES2/OSERDESE2, combined, for each pod
<azonenberg>
you can use one as a clock (coming from the fpga so some jitter degradation vs using a dedicated clock source)
<azonenberg>
so that leaves 7 for return data
<monochroma>
yeah, i just think some stand alone little o-scope pods that just plug into a switch would be more useful + cute (in my use case anyways)
<azonenberg>
at that point you've basically built BLONDEL
<azonenberg>
the point of these pods is to be a stripped down board that's a frontend, adc, and a tiny converter to the sff connection
<azonenberg>
with all of the ram and triggering and stuff on the kintex in maxwell
<azonenberg>
they wont even have separate power inputs
<azonenberg>
(that's something i need to do, figure out if i can fit a hmcad into the power budget of a maxwell pod)
<azonenberg>
I mean we could still make scope pods but they might have to be lower spec
<azonenberg>
Or they might need external power inputs but that would make them a lot less useful
<monochroma>
yeah
<Degi>
If we already use 8b10b, we can supply power over the diff pairs
<azonenberg>
Degi: the whole point is to not modify the existing maxwell
<Degi>
Awwh, we could get a few hundred watts over that...
<azonenberg>
that said, i did come up with a horrible idea some years ago for a chip that did exactly that
<azonenberg>
ac coupled differential serial data with phantom power by dc biasing them
<azonenberg>
but this was part of an april 1st project to design a datasheet for the most user-unfriendly chip possible
<azonenberg>
so one power rail was something like 500V phantom power biased onto 56 Gbps PAM4 data lines lol
<azonenberg>
another one was like 100 mV at 1 kA
<azonenberg>
it was multicore, but each core was a different ISA and there was a mix of endianness
<Degi>
Lolll
<azonenberg>
the package was like a 3000 ball 0.2mm WLCSP
<Degi>
"Endianness is random at startup and must be determined at runtime by checking for results of commands"
<azonenberg>
i specified some absurd tolerances on some of the rails
<azonenberg>
LOL i might have to steal that
<Degi>
Afaik PoE uses transformers to bias it
<azonenberg>
Yeah
<azonenberg>
they put power on the center tap
<azonenberg>
But again, i am not going to modify maxwell to support this idea
<azonenberg>
The tek SCPI stack is not fun to work with
<azonenberg>
sometimes if you send it unexpected input it seems to lock up and not process any commands, sending many *IDN?'s in a row eventually seems to clear it up
<azonenberg>
also it seems to persist state across connections
<azonenberg>
if you send a query and immediately disconnect, you can reconnect and get garbage sent to you from the last session
<Degi>
Lol
<azonenberg>
Not that lecroy doesn't have their own quirks. But they have much friendlier debug logging and i've only crashed the stack once or twice
<azonenberg>
i hang tek's routinely
<Degi>
Ohh they have debug logging
<azonenberg>
(in particular lecroy's VICP protocol is such that you cannot just telnet to it for debugging and send commands, you need framing around it)
<azonenberg>
lecroy allows you to log all scpi commands to a file and display that buffer in the scope GUI
<azonenberg>
and it highlights malformed ones
<azonenberg>
it's good at separating commands so one malformed command won't result in misparsing the next
<Degi>
Maybe instead of using SMA cables for ext clock, we can use SFP modules, though not sure how good they perform jitter and phase stability wise.
<azonenberg>
Hooking one of those up to a GPSDO etc would be a pain
<azonenberg>
SMA is an industry standard connector for this sort of thing. That or BNC
<Degi>
True
<Degi>
Maybe then transformer decouple SMA inputs, that'd achieve somewhat galvanic isolation too
<azonenberg>
for refclk etc I would probably just capacitor couple
<azonenberg>
triggers should be DC coupled
<Degi>
Hm that still had ground loop issues
<Degi>
Why do triggers need to be DC coupled, assuming it is a pulse?
<azonenberg>
Because you need a valid DC level when not toggling
<azonenberg>
so it knows whether it's a constant trigger or constant no-trigger
<azonenberg>
realistically your equipment should all share a common ground
<Degi>
You'd still have ground loops
<azonenberg>
If you have multiple pieces of test equipment connected to the same dut, dc coupling them isnt really practical
<azonenberg>
ac*
<Degi>
(And theoretically you could transformer couple a DC signal with fast edges and then determine from pulse polarity whether its high going or low going, the integral would be the current level heheh
<Degi>
)
<azonenberg>
yeah but again your probes are dc coupled
<azonenberg>
you already have to deal with grounding
<Degi>
Hm right
<Degi>
Unless you have differential probes
<azonenberg>
You still need to ground them
<azonenberg>
most diffprobes can only handle a few volts of common mode offset
<azonenberg>
they reject it nicely but if you have tens of volts of ground offset they'll blow out the input stage
<Degi>
Hm right, maybe isolated diff probes... Yeah that'd be a problem
<azonenberg>
So typically there's a non-signal-critical ground that's basically just a DC current path
<azonenberg>
then RF inputs for the two data lines
<Degi>
Kinda wanna have some fiber optic coupled diff probes for HV signals
<azonenberg>
yeah but you wont get GHz bandwidth out of those
<azonenberg>
"query interrupted"
<azonenberg>
so basically it looks like tek's scpi stack chokes if you send it two commands back to back??
<azonenberg>
it won't just queue up the last command
<azonenberg>
this will make it super hard to use over high latency pipes
<azonenberg>
and this goes against all of the rules for how to handle latency because literally every single command has to be a round trip
<Degi>
This is interesting, it even has a built-in printer
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #192: Remove probe attenuation menu and add attenuatio to channel properties dialog instead - https://git.io/JUaCc
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #192: Remove probe attenuation menu and add attenuatio to channel properties dialog instead - https://git.io/JUaCc
<Degi>
Hm, turns out you can calculate a sinewave by solving an equation huh
<azonenberg>
Degi: you mean y = sin(x)? :P
<azonenberg>
or a CORDIC? taylor series?
<Degi>
x = -integral(integral(x))
<Degi>
You can solve that with 1 addition, subtraction, multiplication
<Degi>
Downside is that my implementation has DC bias, depending on the time scale factor and on the initial value (the bigger the value, the less the relative bias, with floats there is no bias but I used ints here, since I thought about implementing it in an FPGA)
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #193: Remove bandwidth limit from context menu and move to channel properties dialog - https://git.io/JUalG
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #193: Remove bandwidth limit from context menu and move to channel properties dialog - https://git.io/JUalG
<_whitenotifier-f>
[scopehal] azonenberg opened issue #268: Add APIs for querying available bandwidth limits on an instrument - https://git.io/JUal4
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #268: Add APIs for querying available bandwidth limits on an instrument - https://git.io/JUal4
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #268: Add APIs for querying available bandwidth limits on an instrument - https://git.io/JUal4
<_whitenotifier-f>
[scopehal] azonenberg pushed 4 commits to master [+0/-0/±8] https://git.io/JUa8J
<_whitenotifier-f>
[scopehal] azonenberg 78adddc - Continued Tek 5/6 support. Moved AcquireData to a separate function for MSO5/6. See #13.
<_whitenotifier-f>
[scopehal] azonenberg c85ed23 - Prefetch optimization to AcquireDataMSO56. See #13.
<_whitenotifier-f>
[scopehal] azonenberg 380bb58 - TektronixOscilloscope: implemented Get/SetChannelAttenuation(). See #13.
<_whitenotifier-f>
[scopehal] azonenberg 5da1abc - TektronixOscilloscop: Implemented Get/SetChannelBandwidthLimit for 5/6 series. See #13.
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JUa8I
<_whitenotifier-f>
[scopehal-apps] azonenberg 4c05c14 - Updated submodules. Fixed a few compile warnings.
<azonenberg>
welp, it's rapidly getting more and more usable
<azonenberg>
Setting channel gain/offset are next on my list
<azonenberg>
i havent touched any triggers other than the basic edge yet
<azonenberg>
Then i have to do all of the sample rate/depth configuration, trigger offset, etc
<azonenberg>
honestly it's progressing faster than i expected
<azonenberg>
I might be ready for hands-on with a scope in the next week or two
<azonenberg>
although budget probably wont be available until mid month given my construction
<sorear>
[random endian] "it's an erratum. there's a strap, but they forgot to bond it out and there's no pull, so it just samples analog noise at reset"
<azonenberg>
lolol
m4ssi has quit [Ping timeout: 246 seconds]
m4ssi has joined #scopehal
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #194: Add some means to copy protocol decodes to triggers when supported - https://git.io/JUa0T
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #194: Add some means to copy protocol decodes to triggers when supported - https://git.io/JUa0T
<_whitenotifier-f>
[scopehal] azonenberg pushed 3 commits to master [+0/-0/±3] https://git.io/JUaEo
<_whitenotifier-f>
[scopehal] azonenberg 7c8d12a - TektronixOscilloscope: Implemented setters for gain, offset, and bandwidth limit. See #13.
<_whitenotifier-f>
[scopehal] azonenberg ed06fdd - Unit: Sample rates now get printed without extra trailing zeroes
<_whitenotifier-f>
[scopehal] azonenberg 299e602 - TektronixOscilloscope: fixed rounding error in sample rate calculation. Added tables for sample rates/depths. See #13.
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 3 commits to master [+0/-0/±3] https://git.io/JUaEP
<_whitenotifier-f>
[scopehal-apps] azonenberg c2b0fbc - WaveformArea: redraw view when adjusting trace Y axis
<_whitenotifier-f>
[scopehal-apps] azonenberg 9b597e0 - WaveformArea: use Unit class instead of homegrown conversion code for pretty printing sample rates
<_whitenotifier-f>
[scopehal] azonenberg opened issue #269: Support for Tek 5/6 series spectrum channels, if possible - https://git.io/JUaaE
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #269: Support for Tek 5/6 series spectrum channels, if possible - https://git.io/JUaaE
<Degi>
I think I want to try the S/H circuit I tried a while ago with some slower transistors and bigger capacitors as a proof of concept, if that works maybe make a PCB with fast transistors.
bvernoux has joined #scopehal
juli965 has joined #scopehal
<azonenberg>
I'm looking forward to seeing how fast the tek driver will be on systems without insane latency
<azonenberg>
right now i have multiple round trips to the instrument to download waveforms and so over the internet it's like 3-4 seconds per waveform
<bvernoux>
ha yes nice
<tnt>
that's my local experience :/
<bvernoux>
it is great if you can "bench" the link/command/data speed
<bvernoux>
as for example some scope are ultra slow
<bvernoux>
like old Rigol, or some Lecroy ;)
<Degi>
I wonder what the purpose of that kind of interface is when its very slow
<Degi>
I wonder how Rigol web UI works. If it just frame grabs...
<miek>
tnt: does it become more usable with smaller capture sizes/fewer channels?
<bvernoux>
Also I do not see any Issue (feature) related to ultra cheap 8Chan 24MHz with fx2 chipset ?
<tnt>
Degi: well for doing stuff like DPA I didn't mind at all the speed of the interface, the thing just run for a few hours in the background grabbing traces. (and the data grab is only a fraction of cycle time anyway).
<bvernoux>
It will be amazing to support that
<Degi>
DPA?
<azonenberg>
bvernoux: file one. linke a specific hardware platform you want to look at
<azonenberg>
link*
<tnt>
Degi: differential power attacks.
<bvernoux>
azonenberg, ok great let's add an "issue" about that
<tnt>
basically anything that's not "real time" signal browsing but more post analysis doesn't mind too much any latency.
<Degi>
Ehh theres a difference doing a few DPAs per second vs waiting 10 seconds between each because of a slow as hell interface
<tnt>
miek: yes, I reduce channel to just what I need.
<tnt>
Degi: but in a DPA the cycle time is not limited by that ... it's often rebooting the DUT to a known state that takes several seconds.
<Degi>
Hmm yeah then it doesnt matter
<azonenberg>
I'm still aiming to optimize as much as i can
<tnt>
miek: but the capture size is pretty much fixed, don't think I can change it.
<azonenberg>
But really the best performance is to not need round trip times
<azonenberg>
have all commands be write only
<azonenberg>
then have the instrument push waveforms to you
<miek>
it reduces as i reduce the timebase on the scope here
<_whitenotifier-f>
[scopehal] bvernoux opened issue #270: Support ultra cheap Logic Analyzer USB 2.0 HS with 24MHz SMSP 8 Chan based on Cypress FX2/FX2LP chips - https://git.io/JUawb
<_whitenotifier-f>
[scopehal] bvernoux edited issue #270: Support ultra cheap Logic Analyzer USB 2.0 HS with 24MHz 8 Chan based on Cypress FX2/FX2LP chips - https://git.io/JUawb
<bvernoux>
azonenberg, do you have a hint to test glscopeclient without any instrument connected ?
<bvernoux>
as When I launch the windows version it start with a nice display but after it freeze
<bvernoux>
like it search something when I select an instrument like rigol or other
<bvernoux>
which is not connected ...
<azonenberg>
bvernoux: scopehal-apps:#118
<azonenberg>
If you want to run with no instrument connected, right now the only supported flow is to specify a .scopesession file on the command line as an argument
<bvernoux>
ha interesting
<azonenberg>
I can send you a few for testing if you want?
<azonenberg>
I've been busy with backend work lately and there are a ton of UI improvements needed
<bvernoux>
could you provide an example of .scopesession ?
<bvernoux>
yes will be nice
<bvernoux>
to check it works on windoz ;)
<bvernoux>
there is tons of issue with uint64 anyway to fix
<bvernoux>
which are not portable between Linux & Windoz
<bvernoux>
I'm not sure MSYS2 MINGW64 support the %lld too ...
<azonenberg>
yeah as i write new code i'm using C++ width conversion functions that handle this better
<bvernoux>
ha great
<bvernoux>
tell me what you plan to do for that
<bvernoux>
as it is not trivial to find the good solution to replace %lld by something portable
<bvernoux>
especially for 64bits signed/unsigned types for other types up to 32bits there is no problem
<azonenberg>
bvernoux: For reasons i'm still working out, there are OpenMP issues with the default environment
<azonenberg>
Try setting OMP_WAIT_POLICY=PASSIVE
<bvernoux>
ha ok
<azonenberg>
and see if that works better. at least on linux idle CPU is a lot lower that way
<azonenberg>
bvernoux: that's a spi flash capture of my Zybo booting up
<bvernoux>
nice
<azonenberg>
(or well the beginnings of it, it's only a few ms of data. I've done multi-second captures for work before)
<bvernoux>
I need to check where to set this flag OMP_WAIT_POLICY
<bvernoux>
in CMakeFile
<bvernoux>
or somewhere ;)
<azonenberg>
It's an environment variable
<azonenberg>
OpenMP is derpy and at least on linux there is no way to set a default wait policy via a C++ API or anything
<azonenberg>
it has to come from the environment, and the default is braindead
<azonenberg>
(busy waiting all the time rather than using synchronizer objects)
<bvernoux>
ok
<azonenberg>
i'm almost to the point that i want to dig into libgomp
<azonenberg>
and try to find whatever global variable is involved and just set it manually :p
<azonenberg>
i havent looked at the internals
<bvernoux>
without that you have the main windows frozen too ?
<azonenberg>
I have huge amounts of CPU used
<azonenberg>
and i think frequent hangs
<azonenberg>
it should print a warning to stdout if the setting is wrong
<bvernoux>
still frozen on windoz
<bvernoux>
so I suspect there is other things
<azonenberg>
ah ok, well go debug and let me know if you find anything
<bvernoux>
I need to find a good dev/debug env for all that mess ;)
<bvernoux>
which support Cmake
<bvernoux>
and of course set debug flags ...
<azonenberg>
So at this point... remaining missing APIs for full basic functionality on Tek 5/6 series are SetSampleDepth/Rate and Get/SetTriggerOffset
<azonenberg>
at that point the full scopehal API will be implemented, however only edge triggers will work (none of the advanced trigger types)
<bvernoux>
so Tek5/6 are basically working ?
<azonenberg>
I need another couple horus of work and 6 series should be at a usable level. 5 series needs the table of legal sample rates and mem depths added but should otherwise work
<azonenberg>
Oh
<azonenberg>
and also Get/SetDeskewForChannel
<azonenberg>
So far i have not seen any scpi commands for the specan function so i'm not sure if i can do that or if i have to do my own fft's
<bvernoux>
it will be great to retrieve the internal FFT from the TEk ;)
<bvernoux>
as all is done in HW ultra fast ;)
<azonenberg>
Yeah. So far no luck getting it though. But i havent tried too hard
<bvernoux>
and not correlated to sampling rate too ;)
<azonenberg>
i have an open ticket but it may not be possible
<azonenberg>
anyway, so i need to do this handful of APIs that should be done today
<azonenberg>
then i have to implement more trigger types
<bvernoux>
you are testing that remotely on the Tek 5 ?
<azonenberg>
it's mso64 that i'm testing remotely
<azonenberg>
the one i am renting will be a 5 series
<bvernoux>
ha ok
<bvernoux>
i mixed ;)
<azonenberg>
so i'll get to verify both
<Degi>
Hm, if you sample a signal at a random time and have a trigger event and measure the time between trigger and sample, could you make a sampling scope out of that?
<miek>
yup
<Degi>
Hmmm...
<azonenberg>
Degi: That's called "random interleaved sampling"
<Degi>
Assuming I can sync the event to be measured with a trigger signal would spare the comparator
<azonenberg>
it's how the equivalent time on lecroy scopes works
<azonenberg>
basically they use the existing TDC they use for trigger alignment
<Degi>
I think most scopes work like that
<azonenberg>
record a bunch of samples at fixed time offsets then record delta from trigger to the sampling clock
<azonenberg>
and merge them all together
<bvernoux>
azonenberg, do you have checked that the latest code I have modified work fine ?
<Degi>
And that would make for a real cheap sampling oscilloscope... Hmm, 2 GHz sampling oscilloscope with no trigger (essentially a S/H with ADC lol)
<azonenberg>
As opposed to something like FREESAMPLE which, if and when i ever get to it, will be sweep based sampling
<bvernoux>
azonenberg, I hope I have not done regression even on such simple code as I have no way to test so far
<miek>
so things have escalated, i'm now throwing a sat solver at this stupid flash dump
<bvernoux>
I discovered a very nice VNA project today
<bvernoux>
I'm not sure it is updated I have not compared with the PCB/SChematic
<bvernoux>
yes I suspect the mixers are natively 50ohms
<bvernoux>
to be checked
<bvernoux>
LTC5510 is very good IIRC I checked it years ago
<bvernoux>
The ADC are quite limited it seems they are only 10bits
<bvernoux>
MCP33131D-10
<bvernoux>
ha no it is 16bits SAR ADC
<bvernoux>
1MSPS
<Degi>
Would increasing ADC BW help?
<bvernoux>
yes it can
<bvernoux>
for faster sweep
<Degi>
Like if you have 100 MS/s and correlate the output with a 300 kHz sine / cosine that should give better SNR than an equivalent 1 MS/s ADC
<bvernoux>
some VNA can go up to 4MHz IIRC ;)
<bvernoux>
or more maybe
<bvernoux>
the most important is to have ultra clean chain
<tnt>
There are some comments that the reduced size caused some performance degradation (too much crosstalk), so might be beneficial to review the pcb and separate things a bit.
<bvernoux>
yes clearly there is some improvement to do
<bvernoux>
for cross talk
<Degi>
Maybe vias in the silvered areas and some kind of conductive rubber would help
<bvernoux>
are you sure it is silver ?
<Degi>
I think its tin
<bvernoux>
I hope it is ;)
<bvernoux>
i was thinking the PCB was bad quality and using HASL ;)
<miek>
the shielding seems odd to me - a lot of effort there, but it doesn't actually break the links between each block?
<bvernoux>
as it look very ugly
<Degi>
break the links?
<bvernoux>
yes the shielding is far from perfect it shall be checked with a great VNA ;)
<bvernoux>
but the guy has nothing to check
<miek>
as in, everything is in one big cavity - not separated
<Degi>
I suspent that contact resistance between aluminium and HASL is rather high (due to unevenness of HASL and oxidation layer)
<bvernoux>
so it is a very nice HW with no tools
<Degi>
Hm not that much of a cavity, like its modes would be 10+ GHz
<bvernoux>
also an other limitation is max 0dB for each port
<bvernoux>
it willbe great to have something like +30dBm ;)
<bvernoux>
like we have with lot of VNA
<bvernoux>
(expensive ones)
<bvernoux>
with DC protection ;)
<bvernoux>
for BiasTee ...
<Degi>
Huh
<Degi>
Why not +60 dBm and a calorimeter to measure power
<bvernoux>
ha yes more is better ;)
<bvernoux>
so the FPGA shall be changed too ;)
<bvernoux>
with an ECP5-5G ;)
<Degi>
Yes, definitely
<bvernoux>
with GigabitEthernet & USB ;)
<bvernoux>
ok GigabitEthernet is not mandatory for a VNA and just 100Mbit is good
<Degi>
USB 3 is currently being worked on
<bvernoux>
I doubt it bring something ;)
<bvernoux>
whta is hard is to avoid some spurs everywhere ;)
<Degi>
Oh and a better oscillator with < 1 ppm (like the thing azonenberg used somewhere)
<bvernoux>
with 5GHz USB 3.0 it could be harder to filter vs USB 2.0 HS ;)
<bvernoux>
0.5ppm ;)
<Degi>
Hm, USB 3 should work at 2.5 GHz
<bvernoux>
the one on AirSpy is perfect for the price
<Degi>
But yes, good point. And put FPGA far away from the analog stuff because afaik its relatively noisy
<bvernoux>
I prefer to do not say how much we pay for it ;)
<bvernoux>
anyway external 10MHz clock is a must
<bvernoux>
the guy has mad a good choice with SI5351C
<bvernoux>
it is a must have for that
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #270: Support ultra cheap Logic Analyzer USB 2.0 HS with 24MHz 8 Chan based on Cypress FX2/FX2LP chips - https://git.io/JUawb
<bvernoux>
maybe not the best for clean clock but very good for the price
<Degi>
I think thats the chip on my PCIe adapter board haha
<bvernoux>
yes when it is well configured it work very nicely
<azonenberg>
bvernoux: for most of my test equipment projects
<azonenberg>
i plan to use 535-12623-ND
<bvernoux>
it is tricky to use correctly the divisor inside and required a SA to check ;)
<bvernoux>
ha yes 535-12623-ND seems very nice on paper
<Degi>
Huh, that thing has 8 ppt/s over 100 seconds
<bvernoux>
+/-25ppb ;)
<azonenberg>
bvernoux: +/- 0.5 ppm at time of shipment absolute freq accuracy, +/- 1 ppm after reflow
<azonenberg>
Then +/- 25 ppb stability on top of that
<bvernoux>
yes but the power consumption are always high on OCXO
<azonenberg>
If i really wanted ultra good time i'd use a VCOCXO and add a DAC to pull it as close to 10.000000 MHz as i could. but for what i'm doing i care more about stability than being 1 ppm off nominal
<bvernoux>
but this one is very nice and compact/small compared to normal (old) OCXO
<azonenberg>
And look at the phase noise specs on page 2: -123 dBc/Hz at 100 Hz
<azonenberg>
-142 at 1 kHz
<bvernoux>
will be interesting to characterize it with long duration to see the drift ...
<bvernoux>
and also to check the phase noise ;)
<bvernoux>
I have nothing for that
<azonenberg>
bvernoux: they say +/- 1 ppm aging over 1 year, +/- 3 ppm over 20 years
<bvernoux>
yes the aging seems quite standard for such good OCXO
<azonenberg>
But yeah i figure it should be a good general purpose reference clock source, and if i need more accuracy i'll use a GPSDO
<bvernoux>
GPSDO is a must have as external option with 10MHz in all case
<azonenberg>
Yeah
<azonenberg>
And PPS
<bvernoux>
just a warning
<bvernoux>
SI5351C does not support officially 10Mhz on both input ;)
<bvernoux>
even if that work
<azonenberg>
I'm using the LMK0480x for my stuff
<bvernoux>
1 input shall be 25 to 27MHz
<azonenberg>
as the clock synthesizer
<bvernoux>
ha ok
<azonenberg>
And my plan is for all of my instruments to use NTP as default time reference, then optional PPS to get much tighter lock to the second boundary if needed
<bvernoux>
do you have checked how it works ?
<azonenberg>
This should allow you to timestamp trigger events with accuracy of +/- a few ns
<bvernoux>
especially there is lot of tricky stuff with some very ugly spurs when not configured correctly with divisor ...
<azonenberg>
I've used that PLL before on another project and had good results, but i just did the firmware for it, not the board
<azonenberg>
but we'll see. I have it on MAXWELL which is digital and thus less sensitive to timebase jitter
<azonenberg>
woo email from oshpark, v1.2 probe board is received
<azonenberg>
should ship out today and be here monday ish
<azonenberg>
conveniently that's also when all of the MEAD boards are coming
<monochroma>
ooo i wonder if that's one that runs HP-UX on a PA-RISC
<azonenberg>
miek: yeah effective rate / bw is what i was more curious about
<azonenberg>
not realtime
<miek>
no PA-RISC (it's an mc68020), not sure about the OS yet
<azonenberg>
Also i just got off the phone with Jon over at LeCroy sales
<miek>
i think 50GHz samplers exist for this too, but i doubt one will ever turn up for reasonable money
<azonenberg>
He's going to hold the 4 GHz active diff probe i was drooling over for me until november
<miek>
hah
<monochroma>
miek: ah, HP-UX only ran on PA and IA64
m4ssi has quit [Quit: Leaving]
<azonenberg>
So that should come in handy for me doing higher speed SI measurements on MAXWELL etc
<azonenberg>
I obviously want to do as much work as i can on AKL-PT1's but having one known good third party probe for comparison will be nice
<miek>
aha. we did have one of their logic analysers running HP-UX at the hackerspace for a while, but eventually gave it away to someone likely to actually use it :)
<monochroma>
i liked the black and white ones, you could remote-X the LA application, and the default color scheme was some eye sore XD
<miek>
lol
<azonenberg>
lool
<bvernoux>
finally I can rebuild scopehal-apps on my Xubuntu 18.4LTS VM ;)
<bvernoux>
it was a mess with github ;)
<bvernoux>
to add SSL Key
<bvernoux>
else I cannot clone the repo ...
<bvernoux>
azonenberg, it seems you have missed one step for linux build
<bvernoux>
sudo make install
<bvernoux>
at end
Nero_ has joined #scopehal
<monochroma>
last i knew we were not supporting install yet
<bvernoux>
yes so it shall be done by hand ;)
<bvernoux>
until it is implemented in CMake...
<monochroma>
since it's in development i think most everyone just runs it out of the build directory
<bvernoux>
yes
<bvernoux>
what are you using to debug it ?
<bvernoux>
I hate to do debug with cmd line ;)
<monochroma>
i do everything cli
<bvernoux>
ha ok ;)
<bvernoux>
doing C++ by cli is awfull ;)
<bvernoux>
for that Eclipse is good with integrated parser ...
NeroTHz has quit [Ping timeout: 272 seconds]
<azonenberg>
bvernoux: yeah i do all of my dev in the CLI with gdb
<bvernoux>
glurps ;)
<azonenberg>
and yes, there is no install support yet
<bvernoux>
will try with ddd ;)
<azonenberg>
it's not yet stable enough anyone *should* be installing it systemwide yet :p
<bvernoux>
it is ugly but with a gui ;)
<bvernoux>
i'm ultra late on my dev on NFC too ;)
<bvernoux>
some contributors are waiting some features with transparent/stream mode which is amazing ;)
<bvernoux>
I'm even more late on my RF stuff ;)
<bvernoux>
need to populate my TRL offered by OSHPark
<bvernoux>
I know the main issue before was those Southwest Microwave connectors
<bvernoux>
which clearly does not work like expected when not soldered ...
<bvernoux>
now I have the RF capacitor too ;)
<bvernoux>
RF resistor ;)
<azonenberg>
I have my new VNA cables now btw, looking forward to using them to test the probe
<bvernoux>
ha interesting
<azonenberg>
Better phase stability, lower loss, AND thinner
<bvernoux>
does PicoVNA have updated their ugly tools ?
<azonenberg>
No
<azonenberg>
I doubt they ever will
<bvernoux>
I saw they offer a new PicoVNA up to 8GHz or something like that
<azonenberg>
I'd like to get a nicer VNA at some point, but I need other things more
<azonenberg>
--trace DEBUG isn't necessary, neither is verbose
<azonenberg>
just --debug is all you need
<bvernoux>
ok and i need to redirect to a file too
<bvernoux>
as all windows are frozen
<azonenberg>
It logs to stdout. if you want to log to a file do --logfile foo.txt
<bvernoux>
there is nothing in stdout ;)
Nero__ has joined #scopehal
<bvernoux>
the same when redirected to a file
<bvernoux>
file empty ...
<bvernoux>
it seems to be frozen at very start just after creation of windows
<bvernoux>
I see the buttons anyway
<bvernoux>
with the image ;)
Nero_ has quit [Ping timeout: 272 seconds]
<azonenberg>
bvernoux: and you set that environment variable i mentioned?
<bvernoux>
yes
<bvernoux>
export OMP_WAIT_POLICY=PASSIVE
<bvernoux>
do the tricks in msys2 mingw64
<bvernoux>
as it is a mix between linux and windows shell ;)
<azonenberg>
Yeah lol
<azonenberg>
Maybe one day we can try and get a more complete native windows build with visual studio
<azonenberg>
But that isnt a short term priority
<bvernoux>
gdb works under mingw64 ;)
<bvernoux>
so let's do it in cli ;)
<bvernoux>
I will try Visual Studio Code ;)
<bvernoux>
it seems to natively support it
<bvernoux>
it use gdb ...
<azonenberg>
So the mso6 has an AWG on it
<azonenberg>
And one of the output waveforms is "cardiac"
<azonenberg>
But there's no restrictions on frequency, since it's just another waveform type they can DDS
<azonenberg>
So here i am looking at a 1 kHz heartbeat :P
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #195: "Add" menu doesn't hide channels that are unusable due to resource conflicts - https://git.io/JUa5j
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #195: "Add" menu doesn't hide channels that are unusable due to resource conflicts - https://git.io/JUa5j
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JUadT
<_whitenotifier-f>
[scopehal] azonenberg c9a6997 - TektronixOscilloscope:: Can now query memory depth and sample rate. Digital probes are detected, and the corresponding analog channels disabled, but can't actually be used yet. See #13. See #264.
<_whitenotifier-f>
[scopehal] azonenberg opened issue #271: Support for Tek 6 series AWG - https://git.io/JUadO
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #271: Support for Tek 6 series AWG - https://git.io/JUadO
bvernoux has quit [Read error: Connection reset by peer]
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JUaFa
<_whitenotifier-f>
[scopehal-apps] azonenberg 06db80a - Timebase formatting now uses Unit
<_whitenotifier-f>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JUaFV
<_whitenotifier-f>
[scopehal] azonenberg cf73c5a - TektronixOscilloscope: implemented setting sample rate and depth. Fixed some errors in sample rate table. See #13.
<_whitenotifier-f>
[scopehal] azonenberg 7073816 - Unit: Truncate extra significant digits by default
<azonenberg>
woo, ok... four more APIs to do and i'll be at basic feature completeness for MSO5/6
<azonenberg>
No advanced triggers, no AWG support, no digital channel support. But the basic analog use case will be functional
<Degi>
Hm, how do I make a 1 Ghz high impedance signal stronger? Like can I just put some kinda buffer on it?
<monochroma>
you mean like an amplifier?
<Degi>
Yes
<monochroma>
use an amplifier :D
<Degi>
Well yes, something that doesn't load much (it is a 1 pF source which should not be significantly discharged in 1 ns) and has high bandwidth (650 MHz unity gain with no distortion, 1:1 replicating the input)
<Degi>
And low input C (especially low variance over voltage)
<Degi>
So no differential amps with resistor feedback to input
<Degi>
If I have a 1 GS/s analog, somewhat discrete signal, is 650 MHz BW enough I wonder
<azonenberg>
a 1 pF source that you want to not discharge
<azonenberg>
have fun
<Degi>
I think up to 1 mA drain is OK
<azonenberg>
You're gonna have to run it through some kind of very high impedance resistor divider or something i think
<Degi>
Well its the sampling capacitor of a SH
<azonenberg>
Yeah well i'm thinking
<azonenberg>
the input capacitance of most fet amplifiers is nontrivial compared to 1 pF
<Degi>
If we can figure that out, we might be able to use HMCAD beyond 650 MHz
<azonenberg>
i'm more inclined to just use a faster ADC and some RF splitters and no external S&H
<azonenberg>
50 ohm input path, 50 ohm splitter
<Degi>
Hm but cost
<azonenberg>
And just add some gain to compensate for splitter losses
<Degi>
The SH would cost a few € per channel and increase BW to 5+ GHz according to simulations
<azonenberg>
well the other issue to consider is just how many HMCADs we'd need
<Degi>
Like 10 or 20
<azonenberg>
and the difficulty of phasing that many clocks, pcb layout, number of pins, etc
<Degi>
I mean 20 HMCAD is 1k
<azonenberg>
Yes, but it's not just the ADCs
<Degi>
Well, the 1511 variant
<azonenberg>
each one has i think ten lvds pairs (8 data, sync, clock) plus an input clock
<Degi>
A few can be managed with an FPGA each which has some RAM
<azonenberg>
So that's 200 LVDS pairs, at 24 per bank that's 8.3 io banks worth of pins
<azonenberg>
For a single "ADC"
<azonenberg>
then you need super tight phasing of clocks from a LOT of different outputs
<Degi>
I think an ECP5 should be able to do 4 of them, for approx 5-50 € of cost
<azonenberg>
most plls and clock distribution buffers don't have that many outputs
<Degi>
Hm yes, the ADC, the SH needs 2 slightly offset clocks
<Degi>
Well you can use delay lines and splittesr
<azonenberg>
Yes, but that adds complexity and cost
<azonenberg>
also keep in mind the hmcad is already four interleaved adcs
<Degi>
Yes, then you can have 80 interleaved ADC!
<azonenberg>
so you're talking 80 different ADCs that have to be all tuned and calibrated wrt each other to avoid interleaving spurs
<Degi>
Would be comparable to 6400 € of AD9213
<azonenberg>
I'm not just thinking BOM cost
<Degi>
Hm, time domain or frequency domain spurs
<azonenberg>
Frequency
<azonenberg>
but time too obviously. harmonics of the sampling frequency basically
<azonenberg>
from slighty gain mismatches
<Degi>
Ah yes
<azonenberg>
Then i'm thinking pcb engineering, assembly, too
<Degi>
Yeah I guess that can be calibrated by feeding it a sinewave
<azonenberg>
it would be a much more complex board and MUCH more effort on layout and assembly
<Degi>
Yes, PCB engineering will be hard and materials too if you wanna get beyond 2 GHz
<Degi>
Well I have time for thta
<azonenberg>
Four interleaved hmcad's for ZENNECK is doable
<azonenberg>
That is about the upper end of where i think is sane to take the hmcad
<azonenberg>
If you want to look for something cheaper than the ad9213, great
<azonenberg>
But i don't think dozens of hmcad's is the way to go
<Degi>
Yes, I want it to be relatively cheap
<Degi>
Also you could adjust the bandwidth by tuning a filter for the SH pulse hehe
<Degi>
I think I will try to build one SH buffer sometime and then test it with some fast scope to see if its worth pursuing.
<Degi>
Shouldn't it be possible to calibrate out spurs by feeding in a known sinewave?
<Degi>
Or any wave for that matter
<azonenberg>
i think you just need gain cal for each adc
<azonenberg>
but cal time isn't free either
<Degi>
(Also a problem is with frequencies being of 0.5 f_s + n * f_s causing high changes between two samples in an ADC and when its bandwidth is too low, these signals might be a bit attenuated.)
<Degi>
Hm, cal time costs money?
<Degi>
I guess if you wanna done it professionally
<azonenberg>
Or even your own time, that's not free either. but i'm thinking about if i were building these by the dozen
<Degi>
I mean it just needs a good sinewave, like from a magnetron or bandpass filtered RF generator
<azonenberg>
It's either a lot of lab time in the factory somewhere, or a lot of my time
<azonenberg>
not a sine, it needs constant levels for gain and offset on each adc
<azonenberg>
and a bunch of math
<Degi>
Hm, thought about it more as a one-off, wouldn't run a pcb factory in my bedroom lol
<azonenberg>
yeah see i'm thinking about thing i can hopefully get at least a few people to use
<Degi>
Actually you could put the calibration waveform generator on the board heh
<azonenberg>
because i don't want to spend a year of my life on something nobody will ever use
<Degi>
Hm, I guess other people can replicate it if they want? Like it'd basically be a budget 1+ GHz scope
<azonenberg>
What about the ADC07D1520
<azonenberg>
7 bit, dual 1.5 Gsps / single 3 Gsps
<Degi>
Can I get that in MOQ 1?
<azonenberg>
2 GHz analog bandwidth, parallel LVDS interface, $168 at digikey
<azonenberg>
in qty 1
<Degi>
That actually sounds good
<Degi>
Is the output at 0.75 Gbit/s/lane?
<Degi>
7 bit is kinda meh but I guess thats ok
<azonenberg>
ADC08D1520 is quite a bit more expensive but8 bit
<azonenberg>
i suspect they're pin compatible
<Degi>
Huh that sounds pretty neat, at least for 2 GHz
<azonenberg>
Yeah. But I will continue to have the AD9213 as my target for high speed. It's $2119 in the 6 Gsps speed grade and $3865 in the 10 Gsps
<azonenberg>
So i can do dev and frontend testing on the "low cost" version
<azonenberg>
then switch to the full version once i'm sure i have it right
<Degi>
Its 1.87 k$ on mouser
<azonenberg>
Even better. I'm just using digikey prices for reference
<azonenberg>
but i have a LOT of design to do on the BLONDEL/DUDDELL/ZENNECK stuff before i touch it
<Degi>
And 3.41 k$. Wonder why digikey is so pricy there, the price for the thing you just linked is pretty similar on both
<azonenberg>
Good question
<Degi>
The ADC07D1520 is real cheap for a TI part heh. I wonder why it has 1520 in the name.