<azonenberg>
lain: when you get a chance can you pull latest scopehal and test if eye rendering looks better?
<lain>
kk, probably won't be tonight
Bird|ghosted has quit [Read error: Connection reset by peer]
Bird|otherbox has joined #scopehal
_whitelogger has joined #scopehal
Nero_ has joined #scopehal
Nero_ is now known as Guest95162
Guest95162 is now known as NeroTHz
_whitelogger has joined #scopehal
<azonenberg>
So i've decided to give an upgrade to my kickstarter backers who got the probes including cables
<azonenberg>
rather than the RG-316 cable i was originally planning to do, i'll be shipping a nice mini-circuits cable
<azonenberg>
it's only like $5 more
_whitelogger has joined #scopehal
Famine- has joined #scopehal
Famine has quit [Ping timeout: 260 seconds]
<Degi>
Do the RF plots of the probes include the cables
<NeroTHz>
I´m gonna guess no since azonenberg said he deembedded them
<monochroma>
he only added de-embeddeing withing the last few days, so anything before that will include the cable
<NeroTHz>
yeah but that is deembedding in the scope client, the RF probe measurements use the picoprobe software that includes it, I think? but I m not sure. He sent me measurements both with and without deembedding I think
<pepijndevos>
What's the difference between reading data form the screen vs from memory? (Rigol MSO5k)
<noopwafel>
screen data is much smaller
<noopwafel>
pepijndevos: did you see my comments above btw? it looks like it's just sloow doing the transfers and there's not much to do about it other than wait :/
<pepijndevos>
reading logs now...
<_whitenotifier-b>
[scopehal] noopwafel commented on issue #132: Consider removing support for non-queued acquisition mode in Oscilloscope::AcquireData() - https://git.io/JJE2H
<noopwafel>
unfortunately I don't have a mso to play with, but I will PR a tidied-up version of the random junk I have locally
<pepijndevos>
noopwafel, so you added a test to detect empty replies and just keep trying?
<pepijndevos>
Or did you do the 500ms delay Rigol suggested?
<noopwafel>
uhm, so I encountered several issues
<noopwafel>
one of which is that the code is not checking npoints at all
<pepijndevos>
I hope you added copious comments in case anyone ever needs to touch anything
<pepijndevos>
npoints?
<noopwafel>
I think it needs rewrite and I got a bit demotivated after remembering how slow it is
<noopwafel>
let me .. I guess I can just commit the entire tree
<pepijndevos>
heh, yea, it's starting to dawn on me how unusably slow it will be in the best case and... it's not very motivating.
<noopwafel>
I don't have time to tidy it until later (no scope here)
<noopwafel>
so it's not so bad if you just want a scope frontend and you're willing to handle low (screen-size) sample counts
<noopwafel>
it also helps a lot to reduce the #channels in use (modify the enabled array in AcquireData, for now)
* monochroma
wonders if it could be made to go any faster via hacks to the embedded OS shell >.>
<pepijndevos>
IME it just takes ages to arm and respond, transmitting the data is actually not the bottleneck for anything under 100k
<_whitenotifier-b>
[scopehal] noopwafel synchronize pull request #191: [WIP] fix support for Rigol DS1000D/E scopes - https://git.io/JJ0Id
<Degi>
Hmh can u still access the embedded OS shell?
<Degi>
At least on my MSO5000 there doesnt seem to be ssh open anywhere
<noopwafel>
pepijndevos: yes it probably doesn't help that I just default to wanting at least 250k points
<pepijndevos>
There is a single-shot SSH "upgrade"
<pepijndevos>
which will hang the scope but give you a ssh server
<noopwafel>
but I don't have an mso to play with, so I'm going by asking other people to test :P
<Degi>
How does that work
<noopwafel>
and on the lower-end rigols the transmit speed is a killer
<noopwafel>
on the tek I was playing with, the arm speed is somehow *also* absurdly slow
<pepijndevos>
On mine it just takes half a second between SING and the next scope reply
<noopwafel>
but I suspect I'm doing something wrong there
<noopwafel>
meanwhile my real scope can do thousands of triggers a second :(
<pepijndevos>
It seems that arming and triggering is actually not slow, but then it spends half a second copying the data to CPU memory and getting ready to send, during which time it basically doesn't respond it seems
<noopwafel>
yes
<noopwafel>
the tek I was playing with actually exposes this
<noopwafel>
you get 'trigger' when it saw a trigger and then 'save' once it did the copy
<noopwafel>
meanwhile rigol.. :P
<noopwafel>
but uh
<noopwafel>
maybe I ask some dumb questions
<noopwafel>
did you try reducing the memory depth? in acquire I mean
<pepijndevos>
Yea, I have it at 1k for my testing
<noopwafel>
ugh
<noopwafel>
well so definitely test my PR if you can easily do it
<noopwafel>
(maybe better after I split out the useful changes)
<pepijndevos>
yea, currently quite busy, so take your time and ping me later
<noopwafel>
did you add the GetSampleDepth stuff?
<noopwafel>
ah great :)
<pepijndevos>
Maybe it'd be interesting to see if screen mode is much faster.
<pepijndevos>
Then you could split between fast "I just want to see stuff" and semi-offline "decode all the data" action
<noopwafel>
not hopeful but would love to know if it works :(
<monochroma>
clearly someone needs to RE the rigols enough to write new firmware and gateware to make them fast as thowing waveforms out the ethernet and not the LCD :P
<pepijndevos>
Another stupid idea if arming is actually slow: set a really high holdoff time, so you can just poll the trigger state and fetch all the data before the holdoff is over.
<pepijndevos>
monochroma, assuming this is possible... if the ethernet is connected to the CPU and there is just a really low bandwidth connecting between the acquisition and CPU...
<noopwafel>
right, but moving ~1k points should be trivial either way
<pepijndevos>
that is very true...
<monochroma>
pepijndevos: yeah, hopefully there is a high speed DMA interface and not a slow SPI link or something
<monochroma>
or something horrible like the OWON oscilloscope that the FPGA is attached to the DRAM bus lol
<Degi>
Hmh I wonder what they mean by running a "fake upgrade" to enable the ssh daemon on the rigol
<monochroma>
Degi: probably pushing a software upgrade that somehow enables the sshd again
<Degi>
Should try that sometime
<noopwafel>
I like how the mso5k also supports *WAI but simply ignores it
<Degi>
What is that
<noopwafel>
wait for pending operations (like the arming)
<Degi>
Heh
<monochroma>
Degi: if i owned one i would find the UART that just has a root shell (usually) sitting on it and break it out :P
<noopwafel>
the ds1054z just seems to kind of sulk and give you broken crap if you arm too fast
<Degi>
Hmm
<noopwafel>
I'm impressed at how it manages to be more broken than the ds1000d/e
<Degi>
That sounds like screwing it open...
<noopwafel>
which already set a high bar
<monochroma>
Degi: generally yes
* monochroma
notices what appears to be 4 lines going from the spartan6 towards the SoC
<monochroma>
but who knows what's on the inner layers
<Degi>
yeah
<monochroma>
that 3pin header footprint in the upper left next to the fan connector looks interesting
<monochroma>
closer to the FPGA than the SoC though. kinda looks like the center pin is running towards the FPGA as well, so might not be super interesting. probably one of those unpopulated headers closer to the SoC (GoldFinger perhaps)
<pepijndevos>
Are you suggesting those 4 wires are MISO, MOSI, SCK, CS???
<monochroma>
pepijndevos: as an off the cuff guess? yes :P
<pepijndevos>
What's under those giant heat sinks? Are those the ADCs? Or are those already in the tin cans at the bottom?
<pepijndevos>
I have no idea about the general architecture actually...
<Degi>
Maybe FPGAs?
<monochroma>
the usual architecture is, cans are the frontends, under the big heatsinks are likely the ADCs that are directly attached to the DRAMs next to them, and the FPGA reads the DRAMs out and renders the traces to the LCD (or to a frame buffer for the SoC to render or some such)
<pepijndevos>
So the ADCs and the FPGA both have direct access to the RAM chips on the left, and the FPGA renders those to the CPU RAM chips on the right?
<Degi>
I think the ADCs go thru the FPGA to the DRAM?
<pepijndevos>
That would make sense, but I see a bunch of wires directly going into the big heat sinks, while the spartan is up there on its own. Odd
<Degi>
I think there are multiple FPGAs
<pepijndevos>
That would also makes sense I guess
<pepijndevos>
I guess bottom heatsink=ADC, top=BIG FPGA
<Degi>
I mean all the DRAM wires come from upper heatsink and all the analog diff pairs go to the lower heat sink, at least on the top layer
<pepijndevos>
agree
<monochroma>
higher end ADCs tend to be directly attached to the DRAMs and the FPGA is basically just there for realtime DSP and glue. in several systems i have seen the SoC is just there to draw the UI but does /NOT/ draw the waveforms, and the LCD is attached to the FPGA, and the display output from the SoC passes through the FPGA, and the FPGA overlays the waveforms
<pepijndevos>
That one also has a bunch of wires going into the direction of the CPU
<Degi>
Hmh ADC directly to SRAM?
<Degi>
*DRAM
<pepijndevos>
Iiiinteresting
<monochroma>
correct. i don't know what ADCs they are using here though.
<monochroma>
that's the architecture for the lecroy scopes. but instead of DRAMs they have custom multiport SRAMs that are attached to their custom ADCs
<monochroma>
hmmmm
<monochroma>
though the price for this scope is a bit low for that tier ADC
<monochroma>
and me paying closer attention to the PCB, yeah i'm starting to think the top heatsink may be an FPGA
<monochroma>
or, something.
<monochroma>
could be a DSP, but fpga seems more likely
<monochroma>
yeah, so ignore me when i'm quickly glancing over PCB shots :P
<monochroma>
Degi: go pull the heatsinks off yours and solve the mystery! ;)
<monochroma>
guessing that spartan LX9 is lower end house keeping and glue
<monochroma>
the SoC is a Zynq, the spartan6, and a kintex
<monochroma>
4
<monochroma>
lol, and then the front panel has an actel/microsemi proasic just to switch things up a bit XD
<Degi>
lol
<monochroma>
so looks pretty hackable, just have to RE the frontend and the ADC as they appear to be unknown
<Degi>
Afaik custom rigol parts
<monochroma>
just have to sniff the control interfaces to them and figure out the commands
<Degi>
Which probs are on inner layers
<monochroma>
hmm there are some test points on the back side
<monochroma>
and looks like nearly all the BGA pads have vias going through to the back side, that's always nice
<pepijndevos>
Really curious what's going on in that ADC. I took a masters course on ADCs but nothing prepared me for such a giant monster.
<pepijndevos>
Well, except one graph they loved to beat over our heads about bits/frequency/power. Which was actually from a receivers course to show why you need downsampling to not use megawats in the ADC.
<Degi>
Heh
<pepijndevos>
So given the resolution and bandwidth of this thing, I guess it's not actually surprising it needs a heatsink
<Degi>
I think it has 8 bits and 4 ADCs?
<pepijndevos>
But the amount of transistors doesn't fundamentally change with how much power you use. So I guess they are just really big for low noise and thermal properties, but big sucks for speed I'd assume.
<pepijndevos>
8 bits is not even... like... high, maybe it's just a flash ADC. Resistor ladder with 300W through it for linearity lol
<Degi>
Does that help with linearity?
<pepijndevos>
Ehhh kinda? Maybe that was resistor DACs I'm thinking of. When you load the ladder it forms a very odd voltage divider. But if it's just a comparator loading it capacitively maybe it's fine? Just has to be enough that the noise is OK and the paracitics don't cause trouble. 300W is excessive for sure.
<pepijndevos>
Probably the comparators is where all the power goes
<pepijndevos>
Although... at gigasamples the kickback could actually very well be very problematic indeed, so who knows... I've just never designed or even considered in depth such a thing
<Degi>
Add a capacitor string parallel to resistor string
<pepijndevos>
And use the huge caps as heatsinks for the transistors, yea sounds great
<pepijndevos>
lol
<Degi>
I mean on-chip caps xD
<pepijndevos>
I know. Seems like a nice thing thermally if the metal layers above the transistors are nice solid planes
<Degi>
Heh yes
<Degi>
Or just make it out of aluminium oxide and cool it down to near 0K
<Degi>
* 0 K
<pepijndevos>
Yea little problem with that is... how can something be semiconducting when everything is superconducting?
<Degi>
Hmh at least the aluminium oxide has extremely high thermal conductivity when cold
<pepijndevos>
I'm half joking, but a few friends of mine do stuff at CERN and quantum computing and making ICs work at absolute zero is... challenging.
<pepijndevos>
Usually they run wires through the cryogenic chamber, which is a problem in itself, and then run the ICs outside.
<pepijndevos>
But they are actually trying to design an amplifier that works at cryogenic temperatures...
<Degi>
TWT!
<Degi>
Hmm
<Degi>
TWT but it uses the particle beam from CERN
* pepijndevos
procrastinating from thesis writing
<pepijndevos>
What does a scope frontend actually do? Is that just a fancy opamp to do the gain and offset bits?
<Degi>
ye
<Degi>
And coupling
<Degi>
And BW limit
<Degi>
Oh not sure, that might be on FPGA side actually
<pepijndevos>
Pretty crazy when even your opamps need a heatsink
<Degi>
Theres some that can do some 100 W linearly
<pepijndevos>
Ah can't use any of that AB-class nonsense of course...
<sorear>
does anyone float the ADC instead of doing an analog offset
<pepijndevos>
Why are they custom built ICs? Just because nobody makes opamps that are fast and linear enough, or because an "opamp" is a gross oversimplification of what's going on inside?
<pepijndevos>
sorear, I imagine at theses speeds you'd have to float the whole FPGA and DRAM along with it to get the data out.
<pepijndevos>
Maybe for very small offsets you could not actually truly float the ADC, but make a differential one, but what do I know...
<pepijndevos>
Basically, you could control Vref rather than use an opamp to add the offset, but I guess linearity may suffer.
<NeroTHz>
> Degi> Oh not sure, that might be on FPGA side actually
<NeroTHz>
That depends, usually you want to have hardware bandwidth limitations in the frontend so you can lower your ADC sample rate without aliasing
<NeroTHz>
I should keep a better eye on this channel, seems like some interesting discussions that I missed out on
<NeroTHz>
<pepijndevos> Why are they custom built ICs? Just because nobody makes opamps that are fast and linear enough, or because an "opamp" is a gross oversimplification of what's going on inside? - I think it´s because a classic opamp is made to have extremely high input impedance, very high open-loop gain, and (usually) voltage-mode output, and high CMRR on the input, but if you go really high speed, you might switch
<NeroTHz>
to it being open-loop, or not as high gain, with fixed input bias voltages, etc
<pepijndevos>
Yea, it's probably more like an LNA than a generic opamp
<NeroTHz>
not just that. It´s just that an opamp is a more low-speed block, at least with discrete components. Another advantage of putting everything on a single chip instead of multiple blocks on a PCB is that the load capacitance of a PCB will be much larger than that of a on-chip interconnect (you can get ´opamps´ with many, many GHz UGBW in modern CMOS, and even more in dedicated analog technologies like SiGe-BiCMOS)
<NeroTHz>
but I´m no expert in low-speed CMOS
<NeroTHz>
Or rather, high-resolution baseband CMOS
<azonenberg>
NeroTHz: my VNA measures DC for you :P
<azonenberg>
mine in red, commercial 1.5 GHz in blue
Pretzel4Ever has joined #scopehal
<NeroTHz>
well, most of what you see here I think is the linelength between the VNA calibration plane and your probetips
<azonenberg>
Yeah i didn't de-embed the coupler (a few mm of near-ideal 50 ohm line)
<azonenberg>
this was a quick measurement
<NeroTHz>
yeah but that I guess is also why you see the low impedance - you are just rotating around the smithchart, and as you do, you transform your high impedance to a low one. Which is also why the picoprobe one acts similar
<azonenberg>
So you think if i de-embed the coupler i will see different values?
<azonenberg>
Worth a try
<azonenberg>
i assumed it was a near-ideal line and wouldn't matter
<azonenberg>
but if you think the electrical length itself matters, i ca ntry
<NeroTHz>
that is why I wanted you to look at the smith-chart. But rotating clockwise, as it seems to be doing, corresponds to just moving further away (in wavelengths) from the generator, which is what you are doing here
* azonenberg
still doesn't quite grok smith charts
<azonenberg>
S-parameters make sense to me
<NeroTHz>
like, as you go up in frequency, the bit between your cal-plane and your probe, gets more fractions of a wavelength long.
<NeroTHz>
what you really want to do is that that fixture where you could put a 50 ohm/short/open at the end, maybe use that as cal, and then probe the open-version
<NeroTHz>
(I´m also by no means an expert on the smithchart)
<azonenberg>
ok there seems to be something else going on, it's not that
<azonenberg>
note the big rolloff in S21 seems to track the impedance increasing, and the little dip past 3 GHz is in both traces
<azonenberg>
but S21 keeps falling when impedance falls off again
<NeroTHz>
brb, dinner
<NeroTHz>
I´m gonna think about this
<azonenberg>
meanwhile i'm gonna throw together a quick test board with the attenuator on a GCPW with SMA at both ends
<azonenberg>
as well as an alternate design with less resistors
<azonenberg>
will be 2-3 weeks before i get it back, but might as well get that going
<NeroTHz>
perhaps also do a single resistor. Do they offer a 0-ohm version? could be interesting to measure a short? Or have the footprint, and connect the two pads with a transmissionlin on PCB just to check what that added cap does
<azonenberg>
Yeah i'm gonna do a few variants
<azonenberg>
They do not have a 0R in that package
<azonenberg>
it's standard 0402 footprint, but flip chip
<azonenberg>
no wraparound terminals
<NeroTHz>
what series?
<azonenberg>
Vishay FC0402
<azonenberg>
You've probably used them :p
<NeroTHz>
nah, 0402 is like multiple wavelengths long for me
<NeroTHz>
just to 40 GHz
<azonenberg>
lol
<NeroTHz>
¨Noise <-35 dB¨ Dafuck is that supposed to mean Vishay
<azonenberg>
out of curiosity, have you ever had problems with a single transistor being electrically long?
<NeroTHz>
dBUnicorns? dBtrainstation?
<azonenberg>
i.e. channel length is a nontrivial fraction of lambda
<NeroTHz>
azonenberg, on chip? All the time. It´s one of the limitations we have actually for speed. The gate itself becomes electrically long and you get a R-C kind thing
<azonenberg>
innnteresting
<NeroTHz>
but mostly the PA guys struggle with this
<azonenberg>
yeah thats what i figured, output stages would be the big issue
<NeroTHz>
keep in mind that you have a very high permittivity due to silicon, so your wavelength is tiny
<azonenberg>
I have no idea what the stats for semiconductor transmission lines and dielectrics look like
<azonenberg>
i think high-k gate oxides can be up in the double digits, like tantalum pentoxide
<azonenberg>
but all of my silicon work has either been gate-level RE of somebody else's design (i.e. i don't care about timing and only want to understand the logic) or RTL design with somebody else handling the physical design
<azonenberg>
I used to be a pure digital guy, i'm getting into analog because i pulled a Sonic "gotta go fast"
<azonenberg>
And now my 1s and 0s are analog :p
<azonenberg>
i'm being dragged kicking and screaming away from my nice clean timing diagrams full of squarewaves and into the hard reality of parasitics and transmission lines and jitter
<NeroTHz>
most digital, even up to high speeds, is still very ´classic digital´, because you also use tiny transistors
<azonenberg>
Yeah i'm talking more about at the pcb level
<azonenberg>
i can no longer assume my wires transmit my signal unchanged in zero time, etc
<NeroTHz>
ah yeah
<NeroTHz>
to be honest, though, baseband is much, much harder for us
<NeroTHz>
it´s waaay easier to make a transmitter with 50 GHz bandwidth at 130 GHz carrier, than it is to make a 25 GHz baseband in the same technology
<NeroTHz>
(ofcourse, with all of these things it also depends on what kind of transmitter, making a 256 QAM transmitter with 50 GHz bandwidth is gonna be a pita)
<azonenberg>
i'm curious if/when we will see higher order modulations adopted by on-pcb SERDES
<azonenberg>
we started out with NRZ, now they're moving to PAM4
<azonenberg>
what's the next step gonna be, PAM8? QAM16?
<NeroTHz>
unsure, to be honest
<NeroTHz>
I´ve seen some publications on PAM8
<sorear>
does QAM make sense at baseband?
<azonenberg>
sorear: no
<NeroTHz>
but there is also interest in RF-sollutions and optical. What wins will depend mostly on which tech can become financially viable first
<NeroTHz>
I mean you can have a 50 GHz QAM signal around a 25.1 GHz carrier, in theory
<azonenberg>
Exactly
<azonenberg>
all you need is a small offset
<azonenberg>
maybe not quite that small
<azonenberg>
reminds me of what lecroy was talking about in their labmaster signalpath video
<NeroTHz>
but it´s likely easier to use a 150 GHz carrier then, because your relative bandwidth is lower, and for local interconnect, you don´t need a lot of power
<azonenberg>
"We take our 66-100 GHz signal and shift it down basically to DC, so it's 1-34 GHz"
<azonenberg>
NeroTHz: yeah i think in package optics will be really cool if they become practical
<NeroTHz>
yeah, but I still think (but biased, ofcourse) that millimeter-wave dielectric waveguide might be a cheaper solution since it has less mechanical tolerances, and some types can be integrated in an almost-standard PCB process
<NeroTHz>
seems good to me
<azonenberg>
this is the same footprint and unchanged launch as the original test coupon i used to validate the GCPW and SMA launch on this same pcb process
<azonenberg>
only change is addition of the resistors. So by diffing the response we should be able to isolate the contribution from the resistors
<NeroTHz>
so is the total length the same, or did you split the length of transmission line in two and add that on each side?
<azonenberg>
Total length is the same
<azonenberg>
same number of vias and everything
<NeroTHz>
okay
<azonenberg>
i'm not trying to de embed the launch, the match was good enough it should be insignificant
<azonenberg>
and this is mostly a S21 test anyway
<_whitenotifier-b>
[starshipraider] azonenberg pushed 1 commit to master [+6/-0/±0] https://git.io/JJufH
<_whitenotifier-b>
[starshipraider] azonenberg 2a6a928 - Initial version of attenuator-test board
<azonenberg>
$7.10 for 3 boards, i love oshpark for this kind of work
<NeroTHz>
damn
<NeroTHz>
practically for free
<azonenberg>
they're a batch service and charge by unit area
<azonenberg>
2 layer is $5/in^2, 4 is $10/in^2
<azonenberg>
that includes amortized setup fees over the panel and standard shipping
<azonenberg>
i did one ultra tiny board (mini USB, FT232R, tx/rx activity LEDs, decoupling caps, and four-pin 0.1" header) for under a dollar shipped
<azonenberg>
For three units
<azonenberg>
It gets expensive for larger designs but for small stuff they're hard to beat. my one complaint for RF/high speed is that it's fr408hr. But honestly that's still a lot better than standard fr4
<azonenberg>
and i'm sure it wouldn't be so cheap if it was done on megtron 6 or something instead :p
<NeroTHz>
meg6 is an absolute pain for prototyping
<NeroTHz>
because the prepreg materials have like a 2 month shelflife or something
<azonenberg>
Yeah you mentioned
<NeroTHz>
I-Tera is a much better substratre
<azonenberg>
ok fine ro4350b :p
<azonenberg>
Which remains my current preferred low loss material
<NeroTHz>
it is a very good low-loss material
<Degi>
What is the PCB you posted?
<azonenberg>
Degi: Test board for optimizing my probe design further
<azonenberg>
I'm already approaching the promised ship date for the kickstarter, and my design does meet the advertised bandwidth spec. So i am delivering the current board rev to my backers
<azonenberg>
But i plan to continue tuning further
<azonenberg>
And see how much better i can make it
<miek>
it's a probe but with a really well-characterised tip :p
<Degi>
Hmh isnt one side of it umatched though?
<azonenberg>
miek: lol
<azonenberg>
Degi: yes. I expect ~90% of incident power to be reflected off the left port
<azonenberg>
Which is totally fine
<Degi>
Ah yes
<azonenberg>
s/left/driving/
<Degi>
As long as the source swallows that back up
<azonenberg>
Yeah the VNA should be well terminated
<azonenberg>
I can easily solder a terminator across the GCPW though
<azonenberg>
if that becomes a problme
alexhw has quit [Remote host closed the connection]
alexhw has joined #scopehal
<NeroTHz>
I would consider using two 100ohms instead of one 50 ohm for symmetry
<NeroTHz>
that´s the main thing I dislike about GCPW, you have a much larger asyymetry as some microstrip designs would have (because of the length of the current going from one top-ground to the other top-ground)
NeroTHz has quit [Read error: Connection reset by peer]