carl0s has quit [Remote host closed the connection]
Degi has quit [Ping timeout: 256 seconds]
Degi has joined #scopehal
_whitelogger has joined #scopehal
_whitelogger has joined #scopehal
<azonenberg>
totally unrelated but i tried my hand at designing a 2.45 GHz parallel-coupled-lines bandpass filter. any idea why my return loss is so massive?
<_whitenotifier-3>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/Jv5Bj
<_whitenotifier-3>
[starshipraider] azonenberg 3521523 - Finished power plane layout, ready for layout review
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<Degi>
azonenberg: Oof it reflects more than it passes at 2.5 GHz...
<azonenberg>
Degi: yes, lol. I'm just playing around, this isn't for anything useful
<Degi>
Maybe they need to be spaced a bit more apart and be wider? Idk
<azonenberg>
Wider spacing changes impedance, which is bad
<Degi>
Wait you're driving it at 1? With a current or a voltage?
<azonenberg>
sorry wider lines*
<azonenberg>
Wider spacing gives a narrower bandwidth but even worse return loss
<azonenberg>
i.e. S21 curve gets skinnier but also goes down
<azonenberg>
i'm doing one more sim and then going to scrap this layout
<Degi>
Oh
<azonenberg>
I'm going to move back to the oshpark 4-layer stackup for the next design, instead of 2 layer 0.8 mm
<Degi>
Hm I mean if you're driving 1 with a current, could it be that the first element doesnt even resonate? Also maybe try making the first element 3/4 wave
<azonenberg>
and try doing vertical coupling
<azonenberg>
i.e. alternating elements on layers 1 and 2, not side by side in the same layer
<azonenberg>
this way instead of having 70 microns of edge coupling you have the whole width of the resonator to couple
<Degi>
Hm maybe making the strips 1 wavelength long could work better?
<azonenberg>
all of my reading suggests 0.5*lambda is the usual way to do this
<Degi>
Hm my argument for 1 lambda is that the current and voltage nodes would be matched up
<Degi>
I need to clean my desk...
<Degi>
Maybe the element at 1 and 2 could be 3/4 or 1/4 lambda instead
<azonenberg>
let me try the in plane version first
<azonenberg>
well, the first test (just two elements coupling at an arbitrary length, not remotely impedance matched) is ugly
<azonenberg>
It doesn't filter at all
<azonenberg>
But it transmits more than it reflects. Which is progress
<Degi>
Hmh I mean the simplest filter would be like a low Z transmission line 1/2 lambda long right?
<azonenberg>
simplest i think is just a stub at a multiple/fraction of the target wavelength sticking out the side of a matched line
<azonenberg>
But i'm just starting to learn this stuff
<azonenberg>
the whole goal of this little experiment is to expand my knowledge of analog/microwave/RF stuff. No specific end goal, but it's a gap i recognize and wish to correct
<azonenberg>
and since i have downtime at $dayjob right now it seems a good time
<azonenberg>
(it's a consultancy and i'm between clients, been writing some internal training slides but otherwise am a bit idle)
futarisIRCcloud has joined #scopehal
carl0s has joined #scopehal
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
bvernoux has joined #scopehal
<bvernoux>
so after more inspection my issue on some board not booting is probably related to crystal time to stabilize with STM32F405 ROM USB DFU
<bvernoux>
It is crazy as a better SMD crystal (10ppm) take more time that an old through hole 50ppm crystal ...
<bvernoux>
I will check that with my Picoscope to be sure
<bvernoux>
the crazy things is that appear on very limited number of boards
<bvernoux>
and only with Boot ROM USB DFU
<electronic_eel>
bvernoux: are you using the system rom bootloader that is flashed during production at ST or your own one?
<bvernoux>
the BootROM so the one from ST
<bvernoux>
I have just checked with scope that the new crystal is more sensible than the old through hole crystal
<electronic_eel>
maybe they hardcoded a too short time interval for the crystal to swing stable?
<bvernoux>
when I put the Picoscope Probe it fail to boot on USB DFU
<bvernoux>
as it add some pF
<bvernoux>
if I remove the probe it works ;)
<bvernoux>
but on some board it does not work at all
<electronic_eel>
I would suggest to use a H field probe with a spectrum analyzer or good scope to analyze this
<electronic_eel>
with the h field probe you don't need to touch the circuit and don't add pfs
<Degi>
Can we get H field probes on the 100 MHz scope?
<bvernoux>
yes my last option is to use H field probe
<bvernoux>
I have few ;)
<electronic_eel>
Degi: with an external preamplifier maybe
<electronic_eel>
otherwise I don't think the gain is high enough
<bvernoux>
anyway it was interesting to check that even board working fine when I put probe on XTAL out the XTAL does not start
<Degi>
Could you simply use a hall sensor and some LNA?
<bvernoux>
picoscope probe in 10x mode are something like 10pF to be checked
<electronic_eel>
bvernoux: did you check the surrunding circuit to match the recommendation from st? they have a appnote for crystals
<bvernoux>
yes I have followed everything
<bvernoux>
and computed accurately the capacitor & res to drive the crystal
<electronic_eel>
for some crystals you have to reduce the drive strength
<bvernoux>
and this one have same caracteristics especially it is better 10ppm and SMD
<bvernoux>
but the drive strength is definitely not the same ;)
<bvernoux>
i have tried to remove the 220ohms res (replaced by 0 Ohms) and it is the same on board which never work
<bvernoux>
maybe the board which never work have a defective XTAL too ...
<electronic_eel>
calculations aside - did you try to reduce the capacitance by soldering on new capacitors?
<electronic_eel>
if adding the cap from the probe kills it, maybe it helps to reduce
<bvernoux>
nope for the moment I have just remove resistor
<bvernoux>
it is on my todo list to change the capacitor in/out
<bvernoux>
it's 27pF capacitor
<bvernoux>
so they are already quite low
<Degi>
How many MHz is it?
<bvernoux>
8Mhz
<Degi>
Hm depending on the crystal, less might help, idk. So 1x 27 pF on each leg?
<electronic_eel>
8 mhz is unusually slow for small smd crystals. they are much harder to get and more expensive
<electronic_eel>
I usually use 12 or 16 mhz because of this now
<electronic_eel>
3225 form factor usually
<bvernoux>
for STM32F405RGT the best is 8MHz especially for BootROM USB DFU
<bvernoux>
and also after to configure it to a clean 168MHz
<Degi>
Hm maybe a capacitive probe could be made too, which could just be placed on a trace or so
<electronic_eel>
frequency multiple of 1 MHz and ranging
<electronic_eel>
from 4 MHz to 26 MHz.
<electronic_eel>
to quote an2606 in the f40x section: The external clock must provide a
<electronic_eel>
so 12 mhz would work well
<bvernoux>
with XTAL 8Mhz with a Load Cap of 20pF
<bvernoux>
cwith CS estimated to 5pF
<bvernoux>
C1=C2=30
<bvernoux>
so I use 27pF
<bvernoux>
using formula Oscillator_design_guide_for_ST_MCU_CD00221665.pdf
<bvernoux>
it worked fine until now with hundred of boards produced without any issue
<bvernoux>
but recently I changed this old XTAL through hole to XTAL SMD with same characteristics ;)
<electronic_eel>
yeah, but since it isn't working as calculated, I'd try to find an easy fix. I'd try something substentially lower, like 20pF
<bvernoux>
yes I will try lower value
<bvernoux>
so far it affect something like 6boards out of 40 produced
<electronic_eel>
6 boards is a very manageble number, imagine it were 600 or 6000...
<Degi>
Hmm, would GMR resistors from HDDs be usable for a magnetic probe
<bvernoux>
electronic_eel, I have still 160 other to test ;)
<electronic_eel>
even if you get it to work with some tweaks on these 6 boards, I'd probably change all 40 - they might be just working very marginally and fail soon when the customer has them
<bvernoux>
I need to find the root cause
<bvernoux>
In worst case it will be solved by changing the 2 capacitor I think
<electronic_eel>
there is few things I hate more than large-scale product recalls...
<bvernoux>
my scope probe add just 9.5pF so about 10pF ;)
<bvernoux>
so I think I'm border of the margin
<bvernoux>
28pF is probably already 10pF too high
<Degi>
Attach the probe with a 10k resistor to the driving output of the IC maybe
<electronic_eel>
I would call changing the caps more like "best case". worst case would be changing the crystal to another freq and to adapt the firmware
<bvernoux>
it is hard to characterize that in fact
<bvernoux>
doing hot/cold boot to check but it is not enough
<bvernoux>
to know what is the margin between theory (datasheet AN from ST) and reality ;)
<bvernoux>
especially here for the Boot ROM USB DFU which is "considered" buggy as it does not wait correctly(or not enough) the XTAL is stable ...
<bvernoux>
as it check different boot mode so it switch quickly to other boot mode SPI, UART ...
<electronic_eel>
yeah, they support lot's of stuff in the bootloader, support different crystal speeds and so on. I think they cycle through that and don't want to wait too long
<electronic_eel>
just last week I was searching for fets and saw a datasheet from a chinese manufacturer that was looking very suspicious
<monochroma>
data^Waspiration sheets
<electronic_eel>
they had copied all the graphs and most values directly from ao semi
<bvernoux>
but YXC are not beginner for XTAL stuff
<electronic_eel>
as I have looked at this specific datasheet just minutes ago, I instantly recognized the fonts and everything
<bvernoux>
hehe ;)
<bvernoux>
so the XTAL are crap ;)
<bvernoux>
I could check them with my VNA
<electronic_eel>
yeah, looking at the data with a vna could help
<bvernoux>
especially one which does not boot USB DFU vs one which works ;)
<bvernoux>
glurps an Agilent E4404B has been sold for 876.66USD on EBAY !!
<bvernoux>
I have lost it ...
<bvernoux>
an other one => HP AGILENT E4405B E7404A 9KHz-13.2GHz SPECTRUM ANALYZER EMC TG PREAMP
<bvernoux>
This one can be pushed to 26.5GHz without any HW modification
<bvernoux>
I suspect also the 6.7GHz ;)
<bvernoux>
as Agilent have exactly same HW and it is only SW option
<bvernoux>
after the hard part is to calibrate it with an other instrument better ...
<electronic_eel>
I haven't looked how hackable these options on older agilent gear is
<bvernoux>
they are
<bvernoux>
I have fully reversed the FW ;)
<electronic_eel>
I heard for example lecroy should be extremely hard to hack
<bvernoux>
good old 68040EC ;)
<bvernoux>
ha really or maybe no one has tried
<bvernoux>
It was funny to reverse Agilent as I have never seen anything about to hack them especially SW ;)
<bvernoux>
with Time I Think Lecroy can be hacked too the hard part is to have some dump from different CPU/DSP they have
<bvernoux>
and guys buying such instrument for more than 10kUSD do not try to hack them ;)
<electronic_eel>
I think they have some code to detect hacking attempts and then instantly kill all cal data and other eeprom
<electronic_eel>
but I don't know if that is true or just some lore I heard
<bvernoux>
yes anyway they can see it and for such high cost instrument you need to calibrate them each 1year or 2years so you are locked
<bvernoux>
if they detect something you have everything to loose
<bvernoux>
I clearly doubt they are so paranoid for security
<bvernoux>
they all have same type of security KeyGen
<electronic_eel>
others like Rigol and Siglent use the hacking as business model: students and hackers get a discount, businesses pay more
<bvernoux>
they are 99.99% based on FlexLM stuff ;)
<bvernoux>
yes Rigol & Siglent play the game to sell tons of HW
<bvernoux>
and they became better and better with time
<bvernoux>
especially Siglent Spectrum Analyzer / VNA are really amazing for the price
<Degi>
Once I saw a turbomolecular pump with front magnetic bearing I was bidding on be sold for like 100 € on the last second to somebody else
<electronic_eel>
they really play a good game with the hacking. they require some effort to keep the crowd entertained, but not too much so that only experts can do it
<electronic_eel>
I once tried to bid on a nice psu (worth about 400), it was at 120 or so. but the bid was declined because I haven't linked my ebay account to my paypal account (for security reasons)
<bvernoux>
I'm really interested to test the Rigol MSO5000 but the FW seems to be crappy ;)
<electronic_eel>
and the seller limited bidding to people with paypal link only :(
<bvernoux>
8GSPS for <1Keuros is totally amazing
<Degi>
oof
<bvernoux>
with 200MSPS
<Degi>
Hm yes what kinda ADC do they use?
<bvernoux>
you cannot find that in any other scope for that price
<bvernoux>
they use a custom ADC
<bvernoux>
ASIC/ADC all in one
<Degi>
Maybe its 8 GS/s equivalent time sampling rate?
<Degi>
Hm okay
<bvernoux>
no it is real 8GSPS
<electronic_eel>
no, the 8gss are real
<bvernoux>
the string thing is the max BW is only 350MHZ ;)
<bvernoux>
it is SW limited I think
<electronic_eel>
I'm not sure. it could also be the afe design
<Degi>
Hm I think a 650 MHz 8 GS/s scope should be possible for 750 € or so... Not sure. ADCs cost 440 €
<bvernoux>
as 8GSPS can have 500MHz or even 1GHz BW
<bvernoux>
I was interested by 500MHz ;)
<electronic_eel>
at this price point they have to cut corners somewhere
<bvernoux>
mainly for USB HS and anything up to 500MHz ;)
<Degi>
USB HS?
<bvernoux>
yes to check Eye Diagram and other stuff like that ;)
<bvernoux>
it is 480MHz
<Degi>
Is that 8 GS/s distributed over 4 channels or 8 GS/s per channel?
<Degi>
Its 480 MBit/s
<bvernoux>
it is over 4 channels ;)
<Degi>
Thats like 240 MHz right?
<Degi>
Hm I think it should be possible to build that from HMCADs tbh...
<bvernoux>
Degi, but you need 500MHz to capture it correctly
<bvernoux>
I count always 10x GSPS to have something nice
<Degi>
Well yes at 240 MHz you'll see very round eyes
<bvernoux>
so 500Mhz => 5GSPS min
<bvernoux>
so with 8GSPS there is a little margin to have a nice 500MHz scope ;)
<electronic_eel>
isn't it more like digital signals at 480MBit/s, so you want harmonics much higher up to see what is really going on?
<bvernoux>
the fun is the version at <1Keuros is 70MHz with 8GSPS ;)
<bvernoux>
totally overkill
<Degi>
240 MHz is enough to capture the data itself
<bvernoux>
Degi, in my case I want to check the signal
<Degi>
Hm yes and 480 MHz is the first harmonic
<bvernoux>
especially Jitter/Eye Diagram ...
<Degi>
Yeh something with > 1 GHz would be neat...
<electronic_eel>
yeah, so you are more looking at something lik >2.5 GHz...
<Degi>
(But tbh I think a sampling scope would be better for that... There are cheapish ones on ebay from HP or so with 24 GHz or so)
<bvernoux>
yes Sampling Scope will be nice for Eye Diagram
<electronic_eel>
unfortunately we have to wait until azonenberg offers some nice scopes in this range...
<bvernoux>
at lower cost than a true 500MHz BW scope ;)
<Degi>
Hm I mean stacking 8 HMCAD1511s in parallel should be feasible... Maybe I could make a prototype design when I got abunch of money
<bvernoux>
as after 500Mhz it is hard to have good probe too
<bvernoux>
and they are crazy expensive
<bvernoux>
more expensive than the scope for probe > 1.5GHz ;)
<Degi>
Lol
<electronic_eel>
that at least seems to be something that azonenberg has nearly solved, I think he posted some probe comparisons up to 2 GHz with his passive design
<Degi>
Well 50 € per piece. You'd need to do your own analog phase shifting though since they sample simultaneously I think. Like feed half the ADC with 1 ns delay
<bvernoux>
It is hard to compete against Rigol or others as they design their own ASIC with ADC/Decimation ...
<bvernoux>
AD/TI are so expensive for High Speed ADC
<bvernoux>
it is really a shame
<bvernoux>
even some ADC > 40MSPS with 12bits are crazy expensive for what it is
<electronic_eel>
just desolder the rigol ics, reverse engineer them and put them on your own board ;)
<Degi>
Doing that in commercial mass production could make copyright issues or so lol. And the scopes are kinda pricy
<bvernoux>
for Info Rigol MSO5000 is identical to MSO7000 ;)
<Degi>
Like the ADC08DL502 is 50 € / GS/s similar to HMCAD1511 and has more BW
<bvernoux>
MSO7000 is also 8GSPS
<electronic_eel>
just resell the scopes with adcs ripped out as "for parts only" on ebay ;)
<bvernoux>
but 500MHz BW
<bvernoux>
ha no it is 10GSPS
<Degi>
lol
<Degi>
Yeah that ADC has 2 GHz FPBW
<electronic_eel>
I guess they use the same asics for mso5000, 6000 and 7000. they just software-limited it to 8gsps on the 5000
<bvernoux>
yes I think too ;)
<bvernoux>
it is fun that DS4000 is 4GSPS but BW up to 500MHz ;)
<bvernoux>
DS6000 5GSPS and BW 600Mhz to 1GHz ;)
<electronic_eel>
yes, it is an older design. I think they didn't use asics back then
<bvernoux>
so I really think MSO5000 with 8GSPS could have more than 500MHz BW ;)
<bvernoux>
even if they have limited the max to 350MHz to avoid to enter in conflict with their MSO7000 / 8000 probably
<Degi>
Lol 4 bit ADCs...
<bvernoux>
also the amazing stuff is MSO5000 or more can do 1Mpts FFT
<bvernoux>
I do not know at which speed ;)
<Degi>
.-. kinda sad that some scopes still cant do that
<bvernoux>
especially when you see that on PC with 10MHz IQ 64Kpts FFT take about 10% CPU on CoreI7 ;)
<Degi>
Lol
<Degi>
Hmmm if the PCIe thingie works, we could do FFT on a GPU in realtime at a GS/s loll
<bvernoux>
yes
<bvernoux>
GPU shall help a lot for that
<Degi>
Like perfect for fft
<Degi>
You have x operations you can do in parallel...
<bvernoux>
their website is so bad to compare things ....
<bvernoux>
ha there is ENOB column in fact ;)
<Degi>
Kinda cant find any better at 1 GSPS
<Degi>
On mouser at least
<Degi>
They have like 11 bits too at best
<Degi>
Sometimes 8
ggonzalez has joined #scopehal
<ggonzalez>
hellow
<azonenberg>
o/ ggonzalez
<ggonzalez>
: D
<ggonzalez>
looking at your repo right now
<ggonzalez>
repos
<azonenberg>
anyway, yeah the rigol driver is not super well tested on my end but some of the other folks here have submitted additional code to it. If you encounter any problems by all means let me know
<azonenberg>
i'd suggest starting by just trying to get glscopeclient to connect and view waveforms, then worry about any kind of scripting/automation
<ggonzalez>
ok, thx for the advice. I will share my progress : D
<azonenberg>
Changing of the timebase is one big thing i do not have supported in the API. We have tickets open for it, but there are so many different ways scope timebases work that I need to make sure i design an object model that is sane
<azonenberg>
and doesn't lock us into either not working with, or not using all of the features of, some instruments
<ggonzalez>
does it work on macos or better try on a linux machine?
<azonenberg>
It's never been tested on non-linux to my knowledge
<azonenberg>
i know a few things in the GUI are currently posix specific
<azonenberg>
so definitely wont build on windows
<azonenberg>
But i do have all-3-platform support as a longer term goal
<azonenberg>
if you try on mac, i'd love to know how it goes
<azonenberg>
but you're on your own :p
<kc8apf>
hell, I'm trying to _build_ glscopeclient
<kc8apf>
azonenberg: why do you put cmake stuff in a separate repo?
<kc8apf>
for both jtaghal and scopehal this seems to lead to the cmake dependencies being very out of date
<azonenberg>
kc8apf: this dates back to when jtaghal and scopehal were submodules of antikernel
<azonenberg>
and antikernel used a unified google-style build system for everything, using Splash
<azonenberg>
which was my own in house equivalent for Blaze before Bazel was a thing, with distributed compiles, caching, etc
<azonenberg>
The cmake repo was basically a "for everyone not me, here's a convenience wrapper so you don't have to install my whole build system"
<azonenberg>
mind you originally most of this was in a private subversion server
<azonenberg>
things gradually migrated to github and over time the cmake became the primary build system
<azonenberg>
but by this point there were so many issues on the various sub-repos etc that merging them would be a nightmare
bvernoux has quit [Quit: Leaving]
<kc8apf>
I barely managed to get jtaghal building due to quirks with assumptions about header files locations due to submodules
<azonenberg>
Basically the original flow was, you clone antikernel including all submodules
<kc8apf>
A clone of ffts doesn't build as the last 2 commits introduced bugs
<azonenberg>
it was effectively a monorepo, but the sub-repos were split out so other projects/non-antikernel stuff could use them
<azonenberg>
i had a fully up to date splash build.yml file i used, and a cmake script i'd occasionally bring into sync
<azonenberg>
and all you'd do was "splash build jtaghal" etc to get stuff
<kc8apf>
migrating github issues is a not-so-fun but doable thing
<azonenberg>
We can start looking into cleaning some of this up down the road
<azonenberg>
Now that they're projects of their own right it probably makes sense
<azonenberg>
originally they were all just pc-side utilities for antikernel development
<kc8apf>
I can throw some time into this
<kc8apf>
I understand why log and xptool are separate
<kc8apf>
how they are integrated into other projects is awkward
<azonenberg>
yeah those are used all over the place and not intended to be standalone libs since they're so tiny
<azonenberg>
xptools actually used to have threading, mutex, etc libraries but now that c++... 11 i think? is a thing, that got removed
<kc8apf>
header-only libraries are fine
<azonenberg>
once c++ integrates a socket library, which i expect to happen, xptools will die entirely
<azonenberg>
maybe in C++ '30 or so
<azonenberg>
anyway
<kc8apf>
or use bits of boost,e tc
<azonenberg>
(eew boost)
<azonenberg>
i'm all for some build system cleanup. We've had issues already where an issue was flagged on one repo and the fix was in another
<azonenberg>
and github commit message parsing ended up closing the wrong issue by accident :p
<azonenberg>
So at this point i think being separate probably does more harm than good. If you look at the copyright message this codebase dates back to when i was in like the first year of the phd program
<azonenberg>
automating waveform downloads from an ILA core on my FPGAs that i wrote because ise didn't include chipscope free
<azonenberg>
jtaghal and scopehal originally had a lot of cross-dependencies with both each other and antikernel
* kc8apf
is trying to figure out the best way to start hacking on this
<azonenberg>
there was originally a scopehal driver for the antikernel logic analyzer, which used jtaghal to talk to the antikernel NoC
<azonenberg>
and all of this, plus jtaghal itself, used my cross-language enumeration codegen system to ensure that protocol constants in C++ and verilog were kept in sync, etc
<azonenberg>
refactoring all of that out was already a herculean task to get the libraries to the point somebody other than me could compile them
<azonenberg>
so it's not perfect but it's come a long way from the original organically grown spaghetti :p
<kc8apf>
i've been there so many times
<azonenberg>
i imagine forking internal google tools out to be open source was similar
<kc8apf>
well, they had automated tools to help with that
<azonenberg>
i've spent a lot of time reverse engineering [redacted] which uses it though :p
<azonenberg>
But for now i dont want to add more dependencies and xptools is not exactly heavyweight
<kc8apf>
xptools doesn't build on windows
<azonenberg>
Merging the cmake+hal+apps repo i think does make sense long term though
<azonenberg>
what?
<azonenberg>
the whole point of xptools was to abstract away windows-posix platform differences
<azonenberg>
of course i haven't tested on windows in years so it may have bitrotted
<azonenberg>
but literally that is the sole reason it exists
<kc8apf>
it has
<azonenberg>
it was a wrapper around pthreads vs windows threads and winsock vs bsd sockets
<kc8apf>
and using something like boost or poco is to avoid bitrot as others do the upkeep
ggonzalez has quit [Read error: No route to host]
<Degi>
Is it possible to have a brick wall filter with flat group delay?
<Degi>
(Hm maybe putting a second 100 MHz filter directly before the ADC would help with attenuating noise above the nyquist frequency)
<Degi>
Could diodes be used on the input protection to provide a peak detector or would that cause too much load and distortion? Because the current circuit can only detect near DC overload... On the other hand, I guess its kinda user fault when you connect a microwave to it? idk
<azonenberg>
The protection diodes will handle momentary overload
<azonenberg>
I'm mostly concerned about low speed overloads like touching a power rail anyway
<azonenberg>
If you managed to hook your 50 ohm input to a high power RF antenna output, the switch node of a SMPS without using an attenuating probe, etc
<azonenberg>
you're reeeeally screwing up bad
<azonenberg>
this is beyond ordinary carelessness and well into the realm of sheer stupidity
<azonenberg>
designing an instrument to be indestructible isn't possible and there's always a tradeoff between performance and robustness
<Degi>
Okay
<azonenberg>
This is intended to be used with either an active probe or a 10:1 transmission line probe, both of which will protect the scope and afe against anything you'll find on a wallwart powered device
<azonenberg>
if you arent touching mains or something with a big boost converter, you basically can't get enough voltage through a 10:1 probe to fry the input
<azonenberg>
and if you are hooking a SMA directly to the scope you are hopefully doing low voltage 50 ohm stuff like a SERDES output or antenna etc
* Degi
charges 5 kJ capacitor with a wall wart
<Degi>
Hm I think active probes (maybe which directly screw on top of the SMA port) which convert to BNC 1 MOhm would be neat for compatibility with ordinary probes
<azonenberg>
There would have to be a short cable because i don't think you could make such a thing physically small enough for the 25mm probe spacing i'm targeting
<azonenberg>
there's an inherent tradeoff for having 8+ channels in a single row, you have to make them closer
<azonenberg>
my plan was for active probes to have the amplifier box hanging off a sma stub goign to the scope
<Degi>
Hm I mean it only needs some RF buffer inside
<azonenberg>
not directly mounted to the scope. Also SMA has much less mechanical support than BNC
<Degi>
Hm right
<Degi>
SMA go bendy
<azonenberg>
these are cable connections only
futarisIRCcloud has joined #scopehal
<azonenberg>
maybe a DC block, but that's about it
<Degi>
I also thought about an active high Z RF probe where the active circuitry is in the probe itself, that'd be useful for measuring HV RF (maybe using coaxial caps), which ordinary scopes can do rather badly... Or some kinda E field probe. (ice9 built a 300 kV probe with coaxial caps and HV resistors)
<azonenberg>
I do plan to build an active probe with the buffer in the probe itself
<azonenberg>
i also am contemplating making a *solder in* active probe
<azonenberg>
i think i can make one simple/cheap enough to do on a flex pcb with a short pigtail that solders right to the dut
<Degi>
Hm yes
<Degi>
Maybe a probe like the DC/DC negative rail generator we've been using?
<azonenberg>
i was actually thinking about maybe using the LMH6552 as a probe tip buffer by itself
<azonenberg>
$6.28 is pretty cheap, we could set it up for fairly low or unity gain, maybe a resistive divider at the input to minimize loading at the dut side
<azonenberg>
then some minimal power conversion
<azonenberg>
and then we'd just have to figure out how to convert the differential output to single ended to feed to the scope
<Degi>
Arent there any fast unity gain buffers with a higher input impedance?
<azonenberg>
I havent looked into it yet. this is just a concept, not a seriously engineered design
<Degi>
You could just leave one differential output unconnected
<azonenberg>
That is one of several possibilities
<azonenberg>
But i think that would lead to a -6 dB gain
<azonenberg>
also, you'd need to correct for any common mode offset on the output
<azonenberg>
i forget if the 6552 can do Vcm = 0
<azonenberg>
right now that's way down my roadmap
<azonenberg>
My priority right now is to build a single channel prototype with my current passive probe -> this testbed board -> hmcad1520 breakout -> existing fpga devkit
<azonenberg>
then bridge that to scopehal probably over udp to get something working quickly
<azonenberg>
Then build out from there
<Degi>
Hm hmcad1520 breakout the official one?
<azonenberg>
no i'd build one with the same q-strip that integralstick uses
<Degi>
Hm yes
<azonenberg>
i have nine lvds data inputs and one lvds clock input
<azonenberg>
the frame "clock" off the 1520 is slow enough i should be able to just sample it and consider it a sync signal, i don't see it being useful as a clock
<azonenberg>
the bit clock will go to the clock input
<azonenberg>
then i have adequate lvcmos18 outputs to configure it
<Degi>
The frame clock is for syncing the bytes
<azonenberg>
yes, that.s my point - it doesnt have to go to an fpga clock input
<azonenberg>
as i wouldn't actually clock anything off it
<azonenberg>
i'd just use it as a start-of-byte signal
<Degi>
Like in my "fake HMCAD1511 emulated in gateware" implementation I have an 8 bit barrel shifter which rotates till the frame clock byte is 00001111 or 11110000 (dont remember which)
<Degi>
And the clock is a clock input to a DDC interface, the frameclk is just a further datastream for me
<azonenberg>
Yeah
<Degi>
*DDR not DDC
<azonenberg>
my plan is to use the iserdes on the 7-series input buffers for sampling the data
<Degi>
Huh
<azonenberg>
(not full transceivers, just shift registers with some fancy features - no cdr etc)
<Degi>
On the ECP5 the DDR primitives should be sufficient. They go to like 1.6 gBit
<azonenberg>
go down by maybe 4:1 or so, then bitslip/barrel shift until things are aligned the way i want
<azonenberg>
the issue with ddr is now you need 800 MHz fabric clock
<azonenberg>
with a higher serialization rate you can run the in-fpga logic much slower
<Degi>
?
<Degi>
Ah yes
<azonenberg>
so making timing is a lot easier
<Degi>
But the HMCAD only outputs at 500 MHz
<azonenberg>
so i'd do 4:1 or even 8:1
<Degi>
Yes in mine the DDR primitive gears down to 1:4 too
<azonenberg>
oh i thought it was at the data clock rate
<azonenberg>
its half rate?
<Degi>
So I have 125 MHz for the data thingie
<Degi>
I think you can configure that
<azonenberg>
So it's not just ddr
<azonenberg>
it is a full serdes
<Degi>
Maybe the edge clock on the ECP5 can do more than 900 MHz. The fabric works at 900 somewhat
<Degi>
Well it is a DDR with 1:4 output gearing
<Degi>
And then I sample two of the 4 bits, have a byte and then rotate that around
<azonenberg>
anyway details of that come later
<azonenberg>
Point is, short term the goal is to spin all of the boards
<azonenberg>
then start thinking about firmware while the boards are at fab
<azonenberg>
there will probably be extended lead time for parts + components due to all this
<Degi>
(The ECP5 fabric is definitely not rated for 900 MHz, its for 300 MHz max or something lol but the PLL can make 900)
<Degi>
LTC6253 looks fun... < 1 µA leakage, 2 GHz unity gain BW, 350 µV offset max... That's a neat part. (Sadly it costs like 6 bucks otherwise it'd be fun to have around in large amounts)