<azonenberg>
masks can now be loaded and displayed, but there's no measurement of hit rate yet
<azonenberg>
that's the next step
<monochroma>
:o
<azonenberg>
this is after applying 2:1 probe gain to compensate for the splitters in the fixture
<azonenberg>
but not full s-parameter correction for losses in the fixture or non-flat response of it
<azonenberg>
no cable de-embedding either
<azonenberg>
I still have to work out why my eyes are horizontally offset too
<azonenberg>
there are definitely still multiple bugs in the eye filter
<_whitenotifier-b>
[scopehal] azonenberg pushed 1 commit to master [+2/-0/±4] https://git.io/JJK1u
<_whitenotifier-b>
[scopehal] azonenberg f3be005 - Initial work on eye mask testing. Can load eye mask files and display them, but not check for collisions. See #56.
<_whitenotifier-b>
[scopehal-apps] azonenberg pushed 1 commit to master [+1/-0/±3] https://git.io/JJK1z
<_whitenotifier-b>
[scopehal-apps] azonenberg 69137e0 - Initial work on eye pattern masks
<azonenberg>
Unsurprisingly it's failing the mask test due to insufficient bandwidth
<azonenberg>
Interestingly these fs modules seem to have very high drive strength by default and are actually failing the mask test by hitting the top of the window too
<azonenberg>
they are variable drive and i guess default to max
<azonenberg>
my fixture doesn't have a MCU on it to configure them
<azonenberg>
but it would be fun to hook up some test points and play with it
<azonenberg>
i'm gonna try doing some 1G stuff later on and see how that compares
<azonenberg>
those should pass easily, as will 10/100 ethernet probably
electronic_eel has quit [Ping timeout: 246 seconds]
electronic_eel has joined #scopehal
electronic_eel has quit [Ping timeout: 240 seconds]
electronic_eel has joined #scopehal
<Bird|otherbox>
azonenberg: I use 63/37 for prototyping, although SnAgCu works well enough for mass produced boards AIUI
<Bird|otherbox>
my understanding is that if you have decent fume extraction (my setup isn't *great*, but running the kitchen fan at full bore is at least better than nothing I reckon), heavy metal fumes aren't a *terribly* huge deal? but I suppose that there is something of a safety benefit to not having to worry about that to begin with
<monochroma>
iirc at the soldering temperatures involved the lead alloys do not vaporize any of the metals, so the concern with the fumes is just the flux
<azonenberg>
Correct
<azonenberg>
the concern with lead is ingestion of particulates/residue on your hands/clothes
<azonenberg>
not vapors
<azonenberg>
Solder fumes are bad for you, but it's because of the flux and not the metal
<azonenberg>
the vapor pressure of any of the metals involved at soldering temps is ~zero
<Bird|otherbox>
yeah, I do make sure to wash my hands after I solder
<azonenberg>
But IMO if kids are involved that alone is enough of a reason to go RoHS
<Bird|otherbox>
which is fair
<sorear>
doesn't this depend on the kind of flux?
<sorear>
it's just organic acids right? I wonder if you could make food-safe solder flux
<Bird|otherbox>
I think part of the issue is the stuff the flux picks up as well
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #scopehal
m4ssi has joined #scopehal
m4ssi has quit [Remote host closed the connection]
<azonenberg>
It previously used slightly different math for converting from time to pixel coordinates than the waveform display, which caused different rounding behavior
<azonenberg>
also, i now... antialias? dither? not sure what the correct term is
juli964 has joined #scopehal
<azonenberg>
i jitter pixel x positions by +/- 500 fs, since most of the sampling math works at 1ps precision
<azonenberg>
this completely eliminates the vertical black bars, which were caused by rounding happening to work such that some x pixel coordinates just never got hit
<azonenberg>
i also now render eyes at full resolution, vs previously they were at 1/4 resolution in the x axis to work around the rounding issues
<azonenberg>
masks are displayed correctly, and now actually line up properly-ish with the waveform
<azonenberg>
however mask violations are not yet detected
<azonenberg>
Also all production AKL-PT1s are soldered and assembled, however i had problems where the UV cure polyurethane i used to attach them to the enclosure was not sufficient to provide a good bond
<azonenberg>
several of the probe PCBs fell out of the enclosure as we were inserting probe tips to do characterization
<azonenberg>
So i need to play around a bit and find a better adhesive. I have plenty of glue sitting around the lab, just have to figure out which is most suitable
m4ssi has joined #scopehal
<pepijndevos>
azonenberg, I remember we had some discussion about what scope frontends do and why they are special ASICs, which made me wonder... how are you implementing your frontend? Do you pick a jellybean opamp, harvest them from cheap scopes, commission an ASIC, something else?
<NeroTHz>
I think youĺl needa do some funding runs to get a budget for a custom ASIC ;p
<monochroma>
pepijndevos: everything is off the shelf parts at this stage
<monochroma>
ASICs (especially analog) are certainly within the realm of possibility, but not at this point in time
<pepijndevos>
heh, I might be interested in underselling myself to try and make a scope frontend in the open source skywater pdk, it sounds like a fun and useful learning experience
<NeroTHz>
afaik the skywater pdk is only digital
<monochroma>
not sure what skywater is geared towards, anlog and digital silicon fab are fairly different
<NeroTHz>
depends, most high-speed mixed signal stuff is done in 40/28/16nm CMOS
<pepijndevos>
They are still transistors right...
<NeroTHz>
dedicated stuff like what Keysight use for their ADCs is a combo of SiGe-BiCMOS frontend, with afaik 22nm ST used for the actual ADCs
<NeroTHz>
pepijndevos, sure, but you can´t model anything, you don´thave analog models
<NeroTHz>
you just have digital gate-level models I think
<azonenberg>
I'm not sure how much analog characterization info the PDK gives out
<azonenberg>
i havent looked into it but i swear i saw somebody doing spice modeling of a full custom cell
<azonenberg>
based on extractions of gds geometry
<monochroma>
the actual analog fabs are relatively cheap to do a run on though
<NeroTHz>
I´m not sure. I haven´t looked at it in depth myself, I just know a colleague of mine checked it out
<NeroTHz>
yeah, but those old baseband analog techs aren´t going to outperform off-the-shelf high-speed ADCs and frontends
<pepijndevos>
monochroma, so what are the differences, besides available models? I'm about to finish my master in IC design so I have basically zero pratical experience haha
<NeroTHz>
pepijndevos, where are you finishing your masters in IC design
<NeroTHz>
delft?
<pepijndevos>
Enschede
<NeroTHz>
twente right?
<pepijndevos>
yea
<NeroTHz>
kewl
<pepijndevos>
I've definitely heard people discuss analog components for the skywater stuff, but as I understand it'll be released in phases, so it might be that the spice models or gds or whatever are not there yet.
<NeroTHz>
But yeah, if you want to make a front-end ASIC, you might be able to do that in some older analog flavour, or SiGe-BiCMOS, but if you want the mixed-signal parts, you pretty much need to go to one of the younger flavours I think. Though I´m by no means an expert on baseband things
<pepijndevos>
What mixed signal parts does a frontend do? Does it include the ADC? Or just some control logic?
<azonenberg>
pepijndevos: frontend is everything from probe to, but not including, adc
<azonenberg>
so basically esd protection, termination, offset, and gain
<NeroTHz>
when I say front-end, I meanly just mean gain/filtering/matching/buffers
<azonenberg>
and yes, an antialiasing filter
<pepijndevos>
Right, so I assume the high-speed signal path is all analog, and mostly constrained by noise and power and such, and the mixed signal parts don't need to be high speed or anything.
<monochroma>
pepijndevos: primarily the known and characterized analog cells that the fab is familiar and confident in their process. digital CMOS transistors tend to be designed and characterized for use as switches instead of running them in the linear region etc
<NeroTHz>
Right! Bram Nauta is from twente!
<pepijndevos>
NeroTHz, hes the supervisor of my thesis :)))
<NeroTHz>
Kewl
<NeroTHz>
monochroma, do you work in analog IC design?
<monochroma>
no
<monochroma>
worked with some people who did, and studied on my own
<NeroTHz>
From my understanding, modern nm-cmos tends to have good analog models, as there is also a lot of mixed-signal stuff. They are usually released after digital models though
<NeroTHz>
I mean, I´m sure they have analog models, as you need analog models to understand power/clocking behaviour too
<NeroTHz>
it´s just that I thought the open PDK didn´t have them yet, but I´m not sure
<monochroma>
yeah, the core of what i'm trying to get across i guess is, afaik the open process design kit that was released for skywater, i believe is only digital CMOS cells
<NeroTHz>
That lines up with what I heard about it, monochroma
<monochroma>
i know some fabs specialize in digital only processes, but the larger process nodes/older fabs tend to have some mixed signal capabilities. the cool thing about the older process nodes is, they have already paid for themselves many times over, so they can keep fine tuning their process and add new capabilities, and improve performance over time
<_whitenotifier-b>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±6] https://git.io/JJ6kq
<_whitenotifier-b>
[scopehal] azonenberg 02cd779 - EyeDecoder2: various optimizations and fixes to eye pattern rendering
<azonenberg>
Unsurprisingly the 10G link on a 4 GHz scope failst the XFI mask test
<azonenberg>
on the same test fixture, a 1000base-X link works just fine if i tell the scope it's 1x attenuation (it's actually 2x since some of the signal goes back out to the TX)
<azonenberg>
I think this is because the SFP defaults to max drive strength, which is unnecessary on short range links. So if i told it over i2c to lower the drive it would work
<azonenberg>
for the moment all i wanted to do was get a screenshot of a passing mask test, which i did
<azonenberg>
next step will be to add masks for more protocols, right now all i have is XFI
<azonenberg>
NeroTHz, monochroma: how's the infobox and mask rendering look?
<monochroma>
azonenberg: looks good! :D
<NeroTHz>
Seems good. I´m not that familiar with mask testing since I never do it, so can´t really comment on that
<NeroTHz>
also please for the love of god add an option to hide the infobox, that is the single most frustrating thing about the Inffiinium eye diagram tool
<NeroTHz>
you always have that fucking ifnobox in the way
<monochroma>
azonenberg: what is the mask data stored as?
<azonenberg>
monochroma: YAML
<azonenberg>
src/glscopeclient/masks/xfi.yml is the one i have so far
<azonenberg>
NeroTHz: so the issue is, the infobox is also what you double click on to change properties of the channel
<azonenberg>
I could allow you to hide it but i'd need to provide another way to get to that dialog
<NeroTHz>
I´m sure you can figure out a way around that :p
<azonenberg>
File a ticket against scopehal-apps and we can discuss
<NeroTHz>
haha I think you have much higher priorities right now, I was only half-serious about it
<monochroma>
i think, naturally i would expect right clicking on a channel having a context menu pop up for that channel only would make the most sense. instead of click anywhere and get the global menu of doom we currently have
<NeroTHz>
that does sound logical, monochroma
<azonenberg>
monochroma: it's not a global menu of doom
<azonenberg>
everything on it is context driven
<azonenberg>
and applies to the channel you right clicked on
<pepijndevos>
[scopehal] pepijndevos opened PR #415 Rename context menu to global menu of doom
<azonenberg>
Lol
<monochroma>
azonenberg: mm am i crazy or did change at some point?
<azonenberg>
monochroma: it's been like this from day one?
<noopwafel>
azonenberg: do you/someone have a video somewhere of just a bit of normal glscopeclient usage?
<azonenberg>
it shows the list of decodes, yes, but that's all filtered to stuff that applies to the channel you clicked on
<noopwafel>
oh I guess your latest youtube maybe
<azonenberg>
noopwafel: look at my youtube
<azonenberg>
note that the look and feel are evolving over time
<azonenberg>
so many of the older vids demonstrate features that still exist, but have changed
<azonenberg>
or the UI has
<monochroma>
azonenberg: ahhh right
<azonenberg>
literally everything on that menu does something *to the channel you right clicked on*
<NeroTHz>
Personally, not having used the software, but having used a lot of higher-end scopes, my ´expected behavior´ would be that right-clicking on a window gives me the options for only that ´section´ of the window. If I want global settings, I would imagine having to use some more classical ´file - edit - window - view´ bar at the top
<azonenberg>
now, some of them might make more sense in a properties dialog rather than a context menu
<azonenberg>
and i'm willing to debate that
<azonenberg>
but there are no global settings in the right click menu
<azonenberg>
all of those are on the top menu bar
<noopwafel>
azonenberg: just trying to work out what is driver issues :)
<noopwafel>
I ran into real problems the other day trying to get the correct period of time into view
<azonenberg>
noopwafel: general user interface for timebase navigation: mouse wheel zooms the viewport in and ou
<azonenberg>
click and drag on the top time bar pans the viewport left and right
<azonenberg>
zoom-to-center with the mouse wheel is planned but not implemented yet
<noopwafel>
yeah, it was being very buggy for me and eventually stopped letting me zoom, I should have connected gdb :/
<azonenberg>
there is currently no UI for setting the position of the trigger within the timebase
<azonenberg>
not sure if we have an API for it or not, but there's definitely no UI for it
<azonenberg>
noopwafel: did you zoom in extremely far? if you hit a floating point epsilon or something it's possible that could be a problem
<azonenberg>
right now we set the UI timescale by multiplying or dividing the current timescale by a small value, i think 1.1 or something, each scroll wheel click
<NeroTHz>
are you considering touch-screen support?
<azonenberg>
NeroTHz: Yes
<NeroTHz>
okay
<azonenberg>
I want to be able to run it natively on scopes
<noopwafel>
azonenberg: no, I was actually zoomed out quite a bit, which is the weird part :)
<azonenberg>
But that has not been a priority because we only got windows support ilke 2 months ago
<noopwafel>
but sorry, I don't mean to ask for blind-debug
<NeroTHz>
yeah, I can understand that it is not priority, was just curious
<azonenberg>
and then katharina, our sole windows user afaik, got covid and disappeared
<azonenberg>
(she did all of the porting work)
<noopwafel>
re WAIT in Oscilloscope.h: many scopes use this for the 'copying into RAM' step
<NeroTHz>
Well, I can do windows testing myself too
<NeroTHz>
after ISSCC deadline though
<azonenberg>
noopwafel: No clue
<azonenberg>
i may delete that
<azonenberg>
and consider it the same as "waiting for trigger"
<noopwafel>
I was about to ask
<NeroTHz>
I was just thinking about how cool it would be to remote-desktop from my surface to the scopes, and use the touchscreen and so on
<azonenberg>
i.e. i dont care if you're waiting for a trigger or copying to ram
<NeroTHz>
just have a portable touch-screen interface, that would be amazin
<azonenberg>
i just care "is a waveform ready to download"
<azonenberg>
NeroTHz: yeah
<azonenberg>
The other cool thing would be a portable usb or lan attached box with some knobs and encoders
<noopwafel>
for the slower scopes it's nice to have UI feedback, maybe
<azonenberg>
for controlling glscopeclient via a more traditional UI if you have a headless or remote scope
<azonenberg>
imagine being at your desk at home twiddling time/div on a physical knob when VPN'd into the lab
<azonenberg>
NeroTHz: anyway she's out of the hospital and recovering at home but apparently not quite at 100% yet. last time she was here she was talking about wanting to fix some windows portability issues that arose since the last time anyone used the windows build
<azonenberg>
i never saw a PR so i guess she wasn't quite up to fixing that yet
<noopwafel>
but meh, it can always be added back later
<noopwafel>
less complexity in the scope interface is likely better
<NeroTHz>
For my use-case I almost never touch physical nobs, but that is just my way of using. And I wish her the a good recovery!
<noopwafel>
what is your use case? :)
<azonenberg>
NeroTHz: before i have too many people trying to use the windows build i want to streamline the build process more
<azonenberg>
it's still a bit hacky
<NeroTHz>
noopwafel, high-speed serial eye-diagrams, or using the scope as a SDR for doing high-bandwidth IQ demodulation/analysis
<noopwafel>
I kinda like the knobs for navigation
* monochroma
just leaves a mouse and keyboard plugged into her lecroy at all times >.>
<noopwafel>
during the initial setup stage
<azonenberg>
monochroma: so my problem is that rackmounting the scope blocks the side ports from easy access
<azonenberg>
so i only have easy access to the one front panel usb port
<NeroTHz>
yeah, same, we also always have mouse/keyboard plugged in. Esp mouse
<azonenberg>
which means i can do a mouse, keyboard, or thumbdrive
<azonenberg>
more than that means a hub
<azonenberg>
So generally i have a thumbdrive in for screenshots
<azonenberg>
and use the front panel + ethernet as my primary UI
<azonenberg>
and only plug in a kbd/mouse for administration type tasks
<monochroma>
azonenberg: you can put port extenders to the back usb ports maybe side i suppose
<azonenberg>
monochroma: yeah although i might need right angle
<azonenberg>
it's pretty tight
<monochroma>
hehe
<azonenberg>
there are no back usb ports
<azonenberg>
not on the waverunner 8k
<monochroma>
ah
<azonenberg>
the whole ATX mobo "back" is on the right side of the scope
<azonenberg>
oriented vertically
<azonenberg>
NeroTHz: and i/q demodulation and constellation diagrams are on the longer term glscopeclient to-do list
<azonenberg>
generally i add PHY support as i either work on a project that uses it, or build a test fixture for somebody else who needs one
<azonenberg>
and right now i don't have any projects in mind using, say, QAM
<azonenberg>
and no RF siggen to use as a test source
<azonenberg>
my VNA can output pure tones from a few kHz to 6 GHz, but no modulation
* monochroma
will probably need that in the near-ish future >.>
<NeroTHz>
noopwafel, this is an example use case (I can´t show full setup yet because NDA shit :p https://imgur.com/RvojdSw)
<monochroma>
NeroTHz: don't worry, i have signed NDAs, you can show me ! ;)
<noopwafel>
right, I can see why remote knobs less useful here :p
<NeroTHz>
hahaha I´m not quiet sure that that is how that works, monochroma
<monochroma>
can't just be any ol NDA huh? :P
<azonenberg>
Lol
<NeroTHz>
usually we would set that eye-diagram up, and then just play with our circuit settings while hitting the ´Clear display´ button now and then. To the point that I´ve considered figureing out the input the ´clear display´ button gives so I can make a USB-button that sends that signal
<noopwafel>
footpedal :D
<NeroTHz>
(I have wired up a footswtich to the VNA external trigger before for that exact reason)
<azonenberg>
NeroTHz: well you can almost certainly have a little script that sends the scpi command, if nothing else
<monochroma>
azonenberg: do any of your scopes come in a version with the detachable wireless front panels?
<azonenberg>
monochroma: no
<monochroma>
awww
<azonenberg>
that was i think the 6xxx series
<azonenberg>
NeroTHz: also is that... NRZ?
<azonenberg>
i cant even tell if it's NRZ or PAM4 it's so closed :p
<NeroTHz>
It´s NRZ
<azonenberg>
lol
<azonenberg>
so those upper and lower holes aren't actual data eyes
<NeroTHz>
nah
<azonenberg>
Couldn't tell
<monochroma>
i don't use the knobs a lot, but i always thought that was a cute feature
<azonenberg>
this is a more complex mask i made to see how hard it was
<azonenberg>
the hardest part was finding the right spec and measuring coordinates off of a bitmap image, because the FDDI standard doesn't actually specify x/y values
<azonenberg>
just drawn on a grid
<azonenberg>
so i had to extract values for each point lol
<azonenberg>
oh and yes you have to read the fddi spec even though it's ethernet, because they stole the phy from fibre channel
<monochroma>
i miss fiber channel :<
<lukego>
are these nice eye patterns supported on rigol/siglent or only lecroy? docs seem to suggest a lot of hardware is supported but I've been seeing some comments on twitter etc about certain things being only debugged on lecroy?
Nero_ has joined #scopehal
Nero_ is now known as NeroTHz
<lukego>
Hey major n00b alert but could anyone suggest a budget 'scope that would be aligned with glscopeclient (now or foreseeable future) and would also be suitable for checking XGMII PCBs for design faults (e.g. bad signal integrity, diverging differential pairs, etc)? I know that's 156.25MHz DDR but I'm not quite sure what scope features/specs will be needed
<miek>
they'll work for any scope, doesn't matter where the samples come from :)
<NeroTHz>
UXR 110
<NeroTHz>
(this is the correct answer to any question of the format ´Could anybody suggest a scope´
<NeroTHz>
azonenberg, have you guys tested it with R&S scopes?
<lukego>
UXR 110 looks nice :-). I'm more imagining a cheap and cheerful scope that could be stretched to this particular applications, and then perhaps replaced when ambitions expand
<lukego>
I'm seeing some Rigol/Siglent 200MHz scopes for ~$600 but I'm not sure how suitable they really are for this application and/or use with glscopeclient
<NeroTHz>
I know, I was just being a jerk :p it´s easier to hide my lack of knowledge about 99% of scopes by just throwing unobtainium at people
<lukego>
np it's nice to see how the other half lives :)
<azonenberg>
NeroTHz: We have indeed tested with R&S scopes
<azonenberg>
i developed a very basic driver on a RTM3000 about a year ago
<azonenberg>
then lost contact with the guy whose scope i was borrowing over VPN
<lukego>
I suppose I'm also mischaracterizing the problem e.g. XGMII isn't using differential pairs but sets of traces that need to be length matched and I'm guessing/assuming that one application of a scope would be checking relative delays on signals
<azonenberg>
and never implemented all of the full features
<azonenberg>
lukego: yes. For that, sample rate matters more than bandwidth
<azonenberg>
as you care about phase resolution
<lukego>
I've read that rule of thumb is you want sample rate 5x the frequency - does that sound right for this situation?
<azonenberg>
lukego: it completely depends on the application
<lukego>
and maybe relevant is the sample rate when using two channels at once? or would I probably just use one at a time?
<NeroTHz>
That is one of those things you hear people say a lot but is just a bad thing they repeat
<azonenberg>
per Nyquist you need a minimum of 2x the max frequency
<azonenberg>
Anything beyond that will give you a nicer looking waveform, better oversampling of asynchronous waveforms, better phase resolution when comparing multiple signals
<NeroTHz>
(Allow me to be nitpicky and say that nyquist says you need 2x bandwidth, but since scopes go down to DC, that indeed happens to be your max frequency)
<NeroTHz>
(I will now shut up)
<azonenberg>
NeroTHz: fair enough
<azonenberg>
lukego: and honestly how many channels you use depends totally on the application
<lukego>
azonenberg: Application here is that I'll be a total electronics n00b designing a board with XGMII bus and I want to be able to find and quantify my mistakes once the boards come back from jlcpcb
<NeroTHz>
Sorry for that random nitpicky-ness, it´s just that I had to explain that distinction to 4 different people in the last few weeks so I´ve gotten in the habit of pointing it out
<azonenberg>
i've done experiments where i had two different scopes synchronized
<azonenberg>
pulling 8 channels off one board
<azonenberg>
reading an entire RGMII bus *analog*, i.e. not using the LA probe
<lukego>
So I suppose that checking signal integrity only requires one channel at a time, but then two channels to check if delay between related traces is within tolerance?
<azonenberg>
Correct
<azonenberg>
Although realistically you will want a 4 channel scope for general debug purposes
<azonenberg>
almost no non-ultra-entry-level scopes are 2ch anyway
<azonenberg>
many of the higher end ones, like the LeCroy HDO8000A series, are 8ch
<lukego>
I'm thinking ballpark $1000 here
<azonenberg>
Yeah. You can get a decent 4ch scope for that
<azonenberg>
not high end, but decent
<azonenberg>
If you're willing to go secondhand, you can get quite a bit nicer
<lukego>
ebay?
<NeroTHz>
I was always told that the 8-channel stuff mostly came from people neeidng it for motor controllers
<NeroTHz>
and DC/DC
<lukego>
I'm not in a hurry so second hand would be a decent choice
<azonenberg>
NeroTHz: yes. LeCroy's MDA platform is basically an 8 channel HDO with custom software for 3-phase motor analysis on it
<azonenberg>
lukego: anyway, so fundamentally there are a bunch of things in the digital world you'd want to use a scope for
<lukego>
yeah I'm just imagining the XGMII will be the hardest application i'm likely to try on equipment from the current budget
<lukego>
I suppose maybe DDR<n>
<azonenberg>
Signal integrity of a single-ended signal: you mostly want bandwidth sufficient to see the harmonics in your signals, but only need one channel. Sample rate doesn't matter a ton because you can integrate a lot of acquisitions and do equivalent time sampling etc
<azonenberg>
Differential signal integrity - same thing but you need 2 channels
<azonenberg>
Phase measurements - you really only *need* bandwidth for the fundamental of your signal, but you need sufficient sample rate to see however much phase error you care about
<azonenberg>
and of course you need at least 2 channels to measure differences
<azonenberg>
Data recovery / protocol decoding - you likely need a lot more channels, even SPI needs 4
<azonenberg>
RGMII needs 6 for one direction
<azonenberg>
and forget XGMII without something like maxwell :p
<azonenberg>
If you're primarily an FPGA guy, a LA probe on the scope is less critical because you can just stick an ILA on the FPGA and see all of the digital signals that way
<azonenberg>
If you do more work with MCUs and such, you will definitely want a scope with mixed signal capability to see all of the digital I/Os without wasting one of your precious few analog probes on them
<lukego>
I will do mostly fpga
<azonenberg>
XGMII is 156.25 MHz / 312.5 MT/s so 3.2 ns per UI
<noopwafel>
syncing my scope and a separate LA in the same GUI is definitely something I would love
<azonenberg>
noopwafel: yes that is something we already kinda-sorta support
<azonenberg>
but it needs more work specifically for syncing to a LA vs a second scope
<azonenberg>
see my demo of the waverunner + HDO sniffing RGMII on youtube
<azonenberg>
lukego: anyway the skew tolerance depends on timing parameters of the tx and rx, but let's say just for the sake of discussion that you want phase resolution of at least 0.1 UI
<azonenberg>
Which gives you 3.125 Gsps as the minimum sample rate to see 320ps of skew between channels
<azonenberg>
Realistically, I wouldn't be too concerned about skew. 320ps is a *lot* of trace length mismatch
<azonenberg>
to give you an idea, the rule-of-thumb average propagation delay for PCB traces (generally outer layer is a bit faster and inner a bit slower) on FR-4 is 6 inches per ns
<azonenberg>
so you'd need nearly TWO INCHES of trace length mismatch to give you 320ps of skew
<azonenberg>
if you match +/- a quarter of an inch - still a very easy tolerance to meet - you'd be +/- 32ps of skew
<azonenberg>
these numbers are approximate but that would be 1/100 UI of skew
<azonenberg>
which i can all but guarantee is total overkill
<lukego>
Siglent SDS1204X-E is 200MHz, 4 channel, 1GS/s (2 ADC). Sounds promising except perhaps too low samples/sec?
<lukego>
(for ~$650)
<azonenberg>
If you actually want to know how much skew you can get away with, you'll want to do a full timing analysis of the link
<azonenberg>
are you familiar with the concepts of setup and hold time?
<lukego>
I have heard the terms but no :)
<azonenberg>
Basically, a flipflop doesn't sample the input instantly on the clock edge, it's an analog circuit and signals have finite switching rates
<azonenberg>
the signal must be stable for at least Tsetup before the clock edge and Thold after the edge
<azonenberg>
then from that point until Tsetup before the next edge, you can set the new bit value
<NeroTHz>
another problem of length mismatch in the case of differential transmission lines is that it is essentially a diffential-mode-to-common-mode conversion, which can give mismatch and offset issues sometimes
<azonenberg>
NeroTHz: yeah but that doesnt apply here in the case of single ended lines
<NeroTHz>
Ineed
<azonenberg>
lukego: So what you need to do is figure out the min/max possible skew between clock and data at the TX side of the link, including clock jitter etc
<lukego>
I'm also not really sure what problems I should be looking for. I'm just imagining that I'll design a board with XGMII, assemble it, and then either (a) doesn't work and need to understand why or (b) does work but need to understand if that's a fluke :)
<azonenberg>
then add up those uncertainties and whatever remains can be allocated to pcb skew. Althoguh obviously good engineering practice dictates that you don't use all of it if you can avoid it :p
<lukego>
ok so the scope needs to be measuring Tsetup and Thold and that's where you need a lot of samples beyond the main freq?
<azonenberg>
you're not measuring setup/hold time directly
<azonenberg>
let's work through an example with RGMII
<azonenberg>
Pull up the KSZ9031 datasheet
<azonenberg>
Then look at table 7-1 on page 58
<azonenberg>
Let's pretend for the sake of discussion that we're looping TX to RX on this same chip
<azonenberg>
follow so far?
<lukego>
yes
<azonenberg>
Ok
<azonenberg>
So using the numbers for integrated delay (the PHY has a couple of different modes it can work in WRT phase of clock and data)
<azonenberg>
We have a minimum of 1.2 ns of data-to-clock time at the transmitter, and 1.2ns of clock-to-data hold
<azonenberg>
What this is saying is that the data is guaranteed to be valid for at least 1.2ns before and 1.2ns after the clock edge
<azonenberg>
then going down to setup/hold at the receiver, there is a minimum of 1ns of setup and hold time. In other words, the data must be valid for at least 1ns before and 1ns after the clock as seen by the reciever
<azonenberg>
Since you have 1.2ns at the TX and 1ns at the RX in both directions, this will function correctly assuming a perfectly matched PCB
<azonenberg>
and, since 1.2 - 1 ns = 200 ps, you can get away with up to +/- 200ps of skew on the PCB
<azonenberg>
Divide that by the propagation velocity for your trace geometry and you get the max allowable length mismatch
<azonenberg>
realistically i'd want to build in some safety margin so i'd probably use +/- 100ps as my design tolerance in this example
<azonenberg>
Make sense?
<lukego>
ok. that leaves us with the problem of 100ps being a relatively short space of time :)
<azonenberg>
Yes. Without a higher end scope it's not going to be super practical to measure, you'd need at least 10 Gsps to see that
<lukego>
also -- aside -- how relevant is it to empirically measure the delay mismatch verses modeling it?
<azonenberg>
I have no idea what the tolerances on XGMII are
<azonenberg>
You should not need to measurer on the PCB unless you're fine tuning with fpga delay lines or something
<azonenberg>
it should be possible to get close enough for your purpose with design time calculations
<azonenberg>
100ps at 6 inches a nanosecond is 0.6 inches
<azonenberg>
But again this is just an example and 6"/ns is a rule of thumb, so you'll want to run the actual numbers for your design
<lukego>
ok. So supposing length matching is checked analytically or in simulation at design time. What does that leave us with to do with the scope? signal integrity "eye patterns" I suppose - more too?
<azonenberg>
Yeah
<azonenberg>
one common thing i'll use a scope for on digital traces is playing with FPGA drive strength or termination
<azonenberg>
to see what gives the nicest looking waveform
<lukego>
Is 200MHz, 4ch, 1GS/s (2 ADC) sounding like plausible specs for these kind of things?
<azonenberg>
200 MHz sounds a bit light for XGMII. Your 156.25 MHz signals will look almost like sinewaves
<azonenberg>
i'd want a minimum of 500 MHz and 1G would be preferable. But that's not happening at your budget
<azonenberg>
realistically, you buy the best equipment you can afford and hope you can get enough data out of it
<azonenberg>
i did amazing things with a 100 MHz 2ch rigol ds1102d :p
<lukego>
I guess an alternative is also to rent or hire third party help
<lukego>
but tricky if the testing will be done on stuff that's sitting on my workbench assembled by hand
<azonenberg>
You can also rent equipment
<azonenberg>
TRS-RenTelCo is a company i've had good experiences with in the past at work if we needed some oddball protocol analyzer for a week or two
<azonenberg>
i've also bought two scopes from them that they were retiring from their fleet, at steep discounts (~50% of MSRP)
<lukego>
So if you can't afford the right specs what would you sacrifice first -- channels, bandwidth, or samples?
<azonenberg>
I dont think i've ever seen a 2ch scope beyond like 100 MHz bandwidth
<azonenberg>
and for the most part bandwidth and sample rate correlate
<lukego>
Rigol DS2302A is 300MHz 2GS/s for $650
<lukego>
2ch
<miek>
there are a few around, i know keysight's mid-range scopes usually have a 2-channel option going up the whole range
<miek>
i wouldn't get it.. but it's there :p
<NeroTHz>
It´s there mostly for ATE and education
<NeroTHz>
ie, test systems where you know ahead of time you only need 1/2 channels, or when you can just have students get annoyed by the lack of channels and it is not your problem
<miek>
another thing to consider is probing. a lot of the cheaper-end scopes don't have 50ohm terminations, so you're very limited on good probing options
<azonenberg>
Yeah
<azonenberg>
I would not want to be doing SI work with a 1M ohm probe
<NeroTHz>
but you can always get 50 ohm passthroughs - performance is poor compared to built-in 50ohm, but if you are already happy with a lower end scope, I´m not sure the reduced performance will be that much of an issue
<azonenberg>
yeah i used those on my rigol
<azonenberg>
The 200 MHz siglent is likely a good general purpose first scope
<azonenberg>
XGMII will be hard to see much on
<lukego>
200 MHz 4ch better choice than 300MHz 2ch for same money?
<azonenberg>
IMO the marginal benefits of going from 200 to 300 are pretty small. You won't be gaining a lot of capabilities
<azonenberg>
2 to 4 channels is a big jump
<azonenberg>
For reference i went from a 100 MHz scope to a 350, then to a 1G, a 2G, and a 4G
<lukego>
Just imagining if I get an XGMII board that's giving me lots of intermittent failures which option would let me actually debug it
<azonenberg>
if you actually needed to do that, i'd say rent a "real" scope
<azonenberg>
Nothing in your price range will be adequate for xgmii signal integrity work IMO
<lukego>
and I guess I'm more interesting in prototyping than anything else i.e. I want to make it work properly for my own test/devel purposes, can treat it as a separate problem to optimize it and get it Right
<lukego>
ok that's good to know thanks
<azonenberg>
But for most slower stuff you'd be better served by the 4ch scope i think
<azonenberg>
Roughly speaking you'll want to see a couple of harmonics when doing SI
<azonenberg>
so a 200 MHz scope would probably be a reasonable choice for SI work out to ~50 MHz clock rates (so 100 MT/s)
<azonenberg>
And it will be barely sufficient for data recovery out to 400 MT/s
<azonenberg>
your signal will look like a sinewave but you'll probably be able to distinguish ones from zeroes
<lukego>
ok so maybe I should set an ebay alert on fire sales of 500MHz/1GHz scopes :)
<miek>
azonenberg: how much is known about scpi performance on the siglents?
<azonenberg>
miek: tverbeuere and Error_404 are the ones to talk to about that. AFAIK it was usefully fast, ust had some bugs
<lukego>
or otherwise just get something cheap and cheerful and not waste money on upgrades that won't help me
<azonenberg>
they basically implemented almost the lecroy command set, but it was just different enough we had to add quirks to the driver
<azonenberg>
and would occasionally derp and drop a command? or was that only rigol? cant remember
<lukego>
Or I could reconsider my budget of course. have to look at what the better scopes cost.
<miek>
i just watch ebay like a hawk and expand my lab as good deals come up :p
<azonenberg>
miek: yeah i kinda do that too, i just watch the higher end of ebay :p
<azonenberg>
and i know sales reps i can skip the middleman with
<azonenberg>
lukego: So, point of reference.. for 312 MT/s / 156.25 MHz, a 500 MHz scope will let you see the 3rd harmonic and a 1 GHz scope will let you see the 6th
<lukego>
looks like ~$6k for a 1GHz 4ch scope but guessing rental / outsourcing makes more sense for me at this stage
<azonenberg>
on the low/old end, monochroma paid something like $2K for a 5 GHz lecroy (only 10 Gsps though, it samples exactly at nyquist lol) from the windows xp + floppy drive era on ebay
<azonenberg>
and it worked fine
<azonenberg>
on the higher end, i paid about $12K for a 1 GHz lecroy that was just under 3 years old, retired rental fleet unit, and still had a few months left on the factory warranty plus a 1-year warranty from the seller
<azonenberg>
Less fancy brands like rigol will cost less, but be less nice (lower WFM/s, worse PC interface, etc)
<miek>
hmm, trying to get the agilent to speak in sample rate/depth is a pain. it doesn't look like there's any good way to set the depth
<azonenberg>
miek: yes i generally find i have to convert to time/div and do lots of ugly math
<azonenberg>
lukego: anyway re eye patterns and such
<azonenberg>
glscopeclient can do any analysis we have on any instrument you can hook up to it
<azonenberg>
it doesnt care what the data came from, it's just sample data
<azonenberg>
you could do eye patterns on rs232 with a waveform collected by a pc sound card if you wanted :p
<azonenberg>
you could decode 10baseT on a 50 MHz rigol
<azonenberg>
All of the screenshots i'm tweeting are on lecroy gear because thats what i have in my lab
NeroTHz has quit [Read error: Connection reset by peer]
Nero_ has joined #scopehal
Nero_ is now known as NeroTHz
<lukego>
thanks for all the great info :)
<lukego>
maybe I should buy a cheapo 4ch 100MHz/200MHz scope for day to day and set an alert on an ultra basic 1GHz scope (1ch e.g.) for SI testing faster links just in case a deal comes along
<lukego>
good to know that glscopeclient is dealing with raw samples, does make it easier to think about compat issues
<azonenberg>
That's basically what i did. I had a rigol ds1102d (2ch + 16 digital) because i was super tight on cash (undergraduate) and couldnt even afford an entry level 4ch
<azonenberg>
then bought my 350 MHz lecroy after i had a real job
<azonenberg>
then jumped on the 1 GHz when i found a rental company retiring it for a good price
<lukego>
could also see if anyone local e.g. at the university has a good scope I could barter access to
<azonenberg>
Fundamentally, libscopehal presents an abstraction of an oscilloscope
<azonenberg>
it's a C++ API that gives you a vector of channels, settings for each, ability to request a waveform object from each one, etc
<azonenberg>
then you can create a filter graph sourcing data from any number of instrument channels and doing arbitrary transformations on them
<azonenberg>
just like gnuradio or VTK
<azonenberg>
Any filter can take input from a scope channel or another filter, since at the API level a filter is just another scope channel
<azonenberg>
so you can chain them arbitrarily
<azonenberg>
and a channel object, while it has a pointer to the attached scope, can be used relatively standalone
<azonenberg>
so it's even possible to have one filter working on waveforms from multiple instrments
<azonenberg>
e.g. you could rig up a usb uart to scopehal bridge for the LA on your FPGA, set up a GPIO as a trigger out from the LA to the scope
<azonenberg>
then probe analog signals with the scope to see what happens outside the fpga when some state machine hits a certain state etc
<azonenberg>
Anyway, then glscopeclient is just the user interface to all this
<azonenberg>
libscopehal / libscopeprotocols are all a C++ API under the hood and you can write custom test tools that call the API directly
<NeroTHz>
why does it seem like my NAS is slowly shitting the bed
<azonenberg>
I built a curve tracer with a power supply and a multimeter and a hundred lines of code
<azonenberg>
NeroTHz: maybe it is? what's wrong with it
<NeroTHz>
well, everything on my desktop was griding to a halt
<azonenberg>
oh lovely
<NeroTHz>
and I thought at first something was wrong with the desktop, but now I realize it´s the NAS being slow (and since a shittonne of files that every program uses are on the NAS, they all act strange
<azonenberg>
Yerah
<NeroTHz>
the main issue is that my nas is really expensive and I don´t want to replace it
<azonenberg>
I have that happen sometimes when i saturate the gig-e link from my workstation to my file server
<NeroTHz>
(I didn´t pay lots of money for it, but a new NAS has a big hole to fill :p )
<azonenberg>
anything else using the filesystem hangs :p
<azonenberg>
I have a 10g pipe from my workstation to the core switch but the nas only has 1g
<azonenberg>
I'm planning on replacing it with an all-flash 10G/40G ethernet Ceph cluster, probably 3 nodes full of as many nvme drives as i can cram into them
<NeroTHz>
Ohh but after a forcefull reboot of the NAS (by going to the basement and yanking out power cords and plugging them back in), I now just got a message on my desktop that a bunch network isccsi mounts have been re-mounted
<NeroTHz>
yes everything smooth again now
<azonenberg>
what kind of nas is it? can you find logs etc?
<NeroTHz>
EMC2 storcenter 350r? I think?
<azonenberg>
... oh. you were not kidding when you said really expensive :p
<NeroTHz>
I got it second for real cheap
<azonenberg>
Lol
<NeroTHz>
came out of a test-lab of a big company, had 300h runtime on it, 200 bucks
<azonenberg>
WTF
<NeroTHz>
list price for this setup is like 17k
<azonenberg>
$200???
<azonenberg>
that's missing several zeros lol
<NeroTHz>
well, 200 euros, but tomatos-tomats
<azonenberg>
Yeah
<azonenberg>
My current storage box is a 2U linux server with an i5 and a pair of 4T hdd's and i paid a lot more than $200 for that :p
<NeroTHz>
I also have a 2xhex core xeon server with 64gig ram that I got for 170 euros
<azonenberg>
lol nice
<NeroTHz>
keeping an eye on local auctions is a great way to score cheap stuff
<azonenberg>
My main workstation now is dual skylake xeons, only 8 cores but stupidly fast for a xeon, i think 3.4 GHz with turbo to 4.2?
<NeroTHz>
but I´m actually genuinly thinking of replacing this EMC2 nas for cost-reasons
<azonenberg>
and 192gb ram
<NeroTHz>
now it´s in my parents basement, and they don´t care about the cost of electricity
<azonenberg>
it cost somebody else about $12K
<azonenberg>
I didnt pay a dime for it :p
<NeroTHz>
but I at some point need to pay for my own power, and I´ve done the math that a cheaper, more modern ARM nas without the enterprise-bells-n-whistles would pay back in like 2 years in power savings
<azonenberg>
Makes sense
<azonenberg>
yeah i dont need any enterprise fluff either
<NeroTHz>
but ideally I want something with 10gbe, but that often puts you in a way higher price braket
<azonenberg>
what i need is a relatively small amount of storage that's stupidly fast
<azonenberg>
Consider a DIY build
<azonenberg>
just an i5 or xeon, depending on if you want ecc ram (I'm going ecc for all future builds that are important), a bog-standard mobo and 10g nic
<azonenberg>
and a bunch of pcie-to-nvme adapter cards
<azonenberg>
you can get pcie cards that fit several nvme drives on a single pcie slot using either bifurcation on the host, or a pcie switch asic
<azonenberg>
I've been eyeing the seagate nytro 5000 series (i think that's the model) which seems to be a good compromise between price and performance for an enterprise ssd
<NeroTHz>
yeah, but NVME drives are a bit more expensive than I want to go
<azonenberg>
priced almost like a consumer drive
<azonenberg>
IMO there is no point in going 10g unless you also move to flash
<azonenberg>
i thought about putting a 10g card on my current nas then realized i'd only get like a 20% speedup before i maxed out the drives
<NeroTHz>
nah, with the right raid cards you can get a lot of speed out of spinning rust, esp for big thransfers
<NeroTHz>
and I might add a SSD cache for writing
<NeroTHz>
I might not get the full 10g sustained, but you can do a lot better with spinning-rust than 1G offers
<azonenberg>
yeah in my case i only had 2 drives in raid1
<NeroTHz>
the alternative is that I just step away from the NAS idea for now
<azonenberg>
but i want to be able to do things like compiles on networked storage
<NeroTHz>
and go back to bunch-of-disks in my dekstop
<azonenberg>
and move vm hard drives there
<azonenberg>
(i want to consolidate a bit and get rid of the bulk drives on my xen server)
<azonenberg>
so i think flash is definitely the way to go. and if i only need single digit TB it shouldnt be that expensive
<lukego>
Just realized that the 200MHz Siglent should do a really satisfying job of RGMII. I'll do that as a warm-up to XGMII. So if I get that then I'll be able to make some cool eye diagrams of my own anyway :)
<azonenberg>
It should work decently for RGMII, it's 250 MT/s so 125 MHz DDR
<azonenberg>
will probably still look somewhat sinusoidal
<NeroTHz>
lol this IMS presentation. ´Motivation for studying load-varying PA design´
<NeroTHz>
presenter gives the following applications: Microwave cooking with solid state power amplifiers
<azonenberg>
forget turntables, just steer nulls toward overheating parts of your meal and more beam power toward cold spots
<NeroTHz>
afaik high-end microwaves already do something crazy with their matching/feed to achieve something simliar, so they don´t need a turntable
<NeroTHz>
(I mean, sweeping it, they don´t do it in a targeted way, just to avoid a null on a single location)
<azonenberg>
Yeah I'm talking about 1.5 kW PESA + FLIR camera
<azonenberg>
I dont think that hs been done yet
<NeroTHz>
but the dialog is supposed to be the first commercial applianance that uses solid-state amplifiers and load-modulation to do what you suggest (it´s not really beamforming because it´s in the near-field)
<azonenberg>
True i guess it would be hard to beamform at such short range with that wavelength
<NeroTHz>
beamforming requires beams, which implies far-field :p
<azonenberg>
(can you cook with other wavelengths too? what else is absorbed well by common foodstuffs? never actually hooked a VNA up to my dinner)
<azonenberg>
i know 2.4G is absorbed strongly by water
<NeroTHz>
yeah. People often incorectly say something like ´2.4G is the resonance of water´ or something
<NeroTHz>
but water is just a shitty dielectric at any frequency, really
<NeroTHz>
that´s why submarines can´t use RF ;p
<azonenberg>
I mean you know why 2.4 GHz is an ISM band, right?
<azonenberg>
because it was considered useless for serious communication
<azonenberg>
Since atmospheric moisture attenuated it so much
<azonenberg>
Submarines can use RF just fine
<azonenberg>
30 kHz is RF :P
<NeroTHz>
It´s a common argument why 2.4 GHz is ISM but I have never seen any data to back it up I think
<NeroTHz>
if you look at atmospheric absorbtion plots you usually have the first peak at 60 GHz due to O2
<NeroTHz>
small peak around 30-something I think because of H2O
<azonenberg>
So ~30 kHz would be useful for cooking too?
<azonenberg>
30 GHz*
<NeroTHz>
yeah
<NeroTHz>
actually I guess not
<NeroTHz>
you don´t want extreme resonant absorbtion
<NeroTHz>
if anything, you would rather have a lower absorbtion, because it would give you deeper penetration of the fields
<NeroTHz>
so better ´cooking from the inside´
<azonenberg>
multi wavelength then
<azonenberg>
30 GHz for crisping the surface, 2.4 for getting deep
<NeroTHz>
afaik, 2.4 GHz was just the frequency at whcih the first microwaves were built
<monochroma>
iirc microwave ovens operate on the power of being in the near H field of the transmitter, the molecules being forced to rotate at the frequency, generating heat
<NeroTHz>
monochroma, yes, but that is how all dielectric loss works
<NeroTHz>
dielectric loss is because molecules (or electron clouds) try to align with the E-field. This is what causes the dielectric constant - they ´counter´ the external E-field. The loss from rotating/moving around is what causes this dielectric loss. It´s also why you have peaks of loss at certain frequency, that is where you just happen to hit a mechanical resonance frequency of the molecule, and it is much mo
<NeroTHz>
re happy to absorb all those external fields
<NeroTHz>
This graph shows why it´s a ´myth´ that they work at 2.4 Ghz for some magical absorbtion reason - Water would be better absorbed if you used higher frequencies.
<NeroTHz>
would be a better absorber*
<NeroTHz>
I think industrial microwaves often work at other bands too, like the 915 MHz band
<azonenberg>
i know 13.56 is common for induction heaters
<azonenberg>
and plasma generation
<NeroTHz>
but you need a much bigger microwave for that to work at home, or you have much bigger nulls
<NeroTHz>
possible, I´m not that familiar with all this :p
<monochroma>
yeah from experience 2.4GHz propagates very well in atmosphere, no issues
<monochroma>
now... 60GHz is an ISM band because it was mostly considered useless for terrestrial comms due to being in an oxygen absorption peak
<NeroTHz>
indeed, 60 GHz is a absorbtion peak
<NeroTHz>
rain is mostly an issue at higher frequencies, I believe. At 2.4 GHz and so on, rain-drops are ´too small´ to really provide lots of scattering/fading issues. Is an issue with point-to-point millimeter-wave links
<monochroma>
towards 70GHz it's a little less useless, and is currently the new hotness in unlicensed high bandwidth microwave radios :P
<monochroma>
24GHz has some fairly bad rain fade issues
<NeroTHz>
70 Ghz is old news, all interesting research is at D-band (110-170) or above :p
<NeroTHz>
but yeah, there is a lot of E-band (70 GHz) backhaul popping up
<NeroTHz>
Erricson recenetly showed a 100 Gbit/s link over 2 km afaik
<NeroTHz>
I may or may not know a few of the people working on that
<NeroTHz>
(though I have no professional relationship with the project)
<NeroTHz>
but those arrays have crazy gain. like >55 dB antenna gain and shit. Need to actively beam-steer to compensate for the pole the module is attached to swaying in the wind
<monochroma>
oh cool
<monochroma>
and i'm just happy when my backhaul radios are modulating high enough to push >800Mbit :P
<NeroTHz>
you work in backhaul?
<monochroma>
i do some consulting for an ISP
<NeroTHz>
right now, the bottleneck tends to actually be baseband
<NeroTHz>
it´s all well and good that you can do crazy highspeed e-band ICs, but getting 20 GHz bandwidth at 77 GHz is almost ´trivial´, geting DC-20 GHz I and Q data into your chip, on the other hand....
<NeroTHz>
(not to mention generating that I and Q signal in the first place)
<azonenberg>
NeroTHz: you just need a beefy virtex and lots of jesd204
<azonenberg>
And some DACs that cost more than my house
<NeroTHz>
Those DACs are the issue :op
<monochroma>
i would assume you would have to split the baseband up into chunks and run them into many multiple ADCs (for Rx) and keep phase state, similar to the high end 100GHz lecroys
<azonenberg>
Yeah that's how i'd imagine
<azonenberg>
realistically you probably wont have one 20 GHz channel anyway
<azonenberg>
you'll be doing OFDM
<azonenberg>
So just do a bunch of 2 GHz channels or so
<azonenberg>
and you dont need phase coherence between them
<NeroTHz>
It´s one approach, that some people are now switching to because it´s just a nightmare otherwise. But splitting that up at high frequencies is also hard. You need good isolation between channels because you will be load-modulating the output for the other channels
<NeroTHz>
and in general, it´s more efficient to do 1x20 GHz than 5x4 GHz, for example
<NeroTHz>
at least so I´m told, baseband is not my problem usually, that is for other people to solve :p
<monochroma>
heh
<NeroTHz>
and yeah, for backhaul you don´t have 20 GHz channels (yet, but in D-band there are some pretty huge channels available). But people are also looking at millimeter-wave communications for wired/waveguide systems as alternative to optical
<monochroma>
NeroTHz: which problems do you tend to solve?
<NeroTHz>
My main focus, on paper, is the entire ´getting-the-100-GHz-off-the-chip´ part
<NeroTHz>
but in practice I´m more just the microwave guru of my team
<NeroTHz>
so I don´t design the transitor-level stuff, but I help out a lot with system-level considerations, architectures, etc
<monochroma>
:D
<NeroTHz>
(I´m also unnoficial lab-manager of our high-frequency lab)
<monochroma>
sounds like lots of fun toys to play with :3
<NeroTHz>
Yes, it does have some perks ;p
<lukego>
Hey sorry to keep piping up but on Ebay I see a Tektronix TDS784C (4ch, 1GHz, 4GS/s) that's right at the edge of my budget. Jump on it?
<monochroma>
no good data interface for export. GPIB on modern machines is no fun
<monochroma>
yeah, just not great for interfacing to scopehal
<lukego>
thanks for the sanity check :-) probably better off with something modern/small/quiet.
<Degi>
Ah yes, they're competitive with rigol on noise...
<Degi>
Well, it has RS232. Maybe that can do SCPI?
<Degi>
And these scopes have very limited sample depth
<monochroma>
but it's more fun when your expensive test equipment investment sounds like a jet engine
alexhw has quit [Read error: Connection reset by peer]
<Degi>
And uses like half a kW
<monochroma>
is it really on if the lights don't dim?
<NeroTHz>
We can actually clearly tell by the load of our AC system when a high-speed ADC is being tested, because the PARBERT systems they use heat up the room so much
<monochroma>
XD
<Degi>
Is that some kinda digital recorder?
<NeroTHz>
PARBERT is a parallel bit-error-rate tester, but those guys use it as very high-speed, parallel sources/detectors
<NeroTHz>
say they have a 30 gigasample/second ADC that works by using 30 12 bit ADCs, each ADC having a single differential NRZ output. They use those PARBERTs as 30-channel, 12 Gbit/s receivers that are internally coherent
<NeroTHz>
some guys use 3 of these machines at the same time for their tests
<Degi>
Heh
<NeroTHz>
(the guys making DACs do the same, but then just the other way round, the PARBERT works as a huge, parallel high-speed signal generator)
<Degi>
Hmh
<Degi>
I wonder if you could use a serdes as a counter for a max. frequency slightly below the serdes frequency / 2
<Degi>
I mean for single events like PMT outputs... For a sinewave, serdes freq / 2 should be doable
alexhw has joined #scopehal
<lukego>
(I ordered the 4ch/200MHz Siglent to put myself out of my misery of indecision...)
<lukego>
looking forward to trying glscopeclient &such :)
m4ssi has quit [Remote host closed the connection]
<Degi>
Can we add to the LEDs on BLONDEL tiny 7 segment displays?
<Degi>
Do MSL 3 LEDs really care about moisture or is that more of a suggestion?
NeroTHz has quit [Read error: Connection reset by peer]
<miek>
MSL ratings aren't just made up :p
bvernoux has joined #scopehal
smkz has quit [Quit: smkz]
smkz has joined #scopehal
bvernoux has quit [Quit: Leaving]
<_whitenotifier-b>
[scopehal] azonenberg labeled issue #220: Eye pattern: allow clock to be specified as rising, falling, or both edges - https://git.io/JJ673
<_whitenotifier-b>
[scopehal] azonenberg opened issue #220: Eye pattern: allow clock to be specified as rising, falling, or both edges - https://git.io/JJ673
<Degi>
Does it have a big power resistor somewhere.
<Bird|otherbox>
Degi: all that high speed logic is going to suck the power :P
<Degi>
Why does it still run in STOP?
<Degi>
Does it mine bitcoins
<noopwafel>
I think you may be somewhat overestimating their engineering there :p
<Degi>
Does it have linear regulators for the FPGA from the 12 V rails?
<azonenberg>
Degi: lol
<azonenberg>
70W does seem like a lot for a scope in that performance class
<Degi>
What does a hmcad use? 1 W?
<azonenberg>
710 mW it looks
<Degi>
hmm
<azonenberg>
At 8 Gsps the mso5000 isnt gonna be using a hmcad though
<azonenberg>
is that one of their asics?
<Degi>
yes
<azonenberg>
So lets see, 70W total, let's say max of 10W for the soc and display, 10W for the FPGA (these are very high estimates just for discussion)
<azonenberg>
that leaves 50W or 12.5W for each channel
<Degi>
I'd give 20 W on the display
<Degi>
But would they continue sampling when in STOP mode?
<azonenberg>
ok so 10W of soc+ram, 10W display, 10W FPGA = 40W for channels or 10W per channel
<azonenberg>
very possibly? analog stuff tends to be leaky and clock gating is a pain
<Degi>
Maybe they have linear regulators for the ADC rails from 12 V?
<azonenberg>
it's quite likely they keep the adcs running nonstop and just ignore the outputs when not in use
<azonenberg>
i would hope its a 2-stage smps + ldo