bluezinc has quit [Quit: Do not go gentle into that good night.]
bluezinc has joined #scopehal
<Famine>
azonenberg, you around ?
<azonenberg>
Famine: yep
<Famine>
funny question for you, if i was to offer you a 6 pack of your favorite beer and the shipping cost, would you mind reshipping something for me ?
<azonenberg>
No, because I don't drink beer :p
<azonenberg>
what do you need and why do you need it reshipped?
<Famine>
laser module, us seller on ebay only does conus shipping
<azonenberg>
Hmmmmm i don't know what the export controls on lasers are like
<azonenberg>
Probably not an issue but i'd want to read up on that first
<Famine>
its a commercial 808nm non-ITAR
<azonenberg>
Could still be on the CCL
<azonenberg>
not saying it is, just that i'd want to do the due diligence first
<Famine>
ah true
<azonenberg>
most likely it would be no license required to EU (you're in Germany iirc?)
<azonenberg>
but i have my nose in enough places i need to keep it clean
<Famine>
yea, i don't want you getting is shit for export violations. i'm in canada
<azonenberg>
oh even more likely to be a non issue
<azonenberg>
What's the output power?
<Famine>
30w, its a FAP800-30W-808
<azonenberg>
yeesh, that gets sketchier re FDA regulations etc. I'd rather not
<azonenberg>
i was thinking like 5 mW or something
<Famine>
haha yea not a low power laser
<Famine>
azonenberg, no worries, thanks for even considering it. i tend to forget how many export controls the US has and i just think ITAR/CCL
Degi has quit [Ping timeout: 265 seconds]
bvernoux has quit [Quit: Leaving]
Degi has joined #scopehal
<azonenberg>
oshpark just sent the afe board out to fab, eta 13th
<azonenberg>
now working on the hmcad1520 board, its not that complicated. Hope to finish schematic tonight
<azonenberg>
lain: so how much have you looked at the hmcad1520 power scheme
<azonenberg>
any idea why there are two analog power domains?
<azonenberg>
avdd2/avss2 and avdd/avss
<azonenberg>
both are 1v8, is there any reason to use separate power supplies?
<azonenberg>
they arent even mentioned in the datasheet other than in the pinout table, so i assume it's safe to tie them together
<lain>
azonenberg: yes, they are the same internally
<_whitenotifier-3>
[starshipraider] azonenberg pushed 3 commits to master [+9/-0/±2] https://git.io/JvFyc
<azonenberg>
using the same clock buffer as freesample, breaking out all four adc channels to SMAs (although only one is usable at a time via the AFE we have now, unless i build several of those test boards
<azonenberg>
then just hangs off the left side of an integralstick using the joycon on the right for power
<lain>
what's the 625 MHz clock for?
<lain>
oh right isn't that the limit when doing 12bit or something
<lain>
looks good
<azonenberg>
the actual lmit is 640
<azonenberg>
i couldnt find any 640 MHz oscs
<azonenberg>
and didn't feel like throwing a pll on this board
<azonenberg>
the mux was a quick and dirty way to get things working
<azonenberg>
the goal here is mostly to verify that the afe plays well with the hmcad and test the afe. as soon as we have that verified, then moving on to the integrated 4x afe + adc board
<azonenberg>
So i guess once this board is done the next priority will be the probe respin, as soon as the new resistors come in so i can experiment with the bom change
SingularitySurf has joined #scopehal
<SingularitySurf>
Hey, where could I find an example .scopesession file with some waveform data for the glscopeclient?
<SingularitySurf>
Had a look in the curvetracer examples etc. but they just throm errors when I try to start them
<SingularitySurf>
throw*
<SingularitySurf>
I would like to play around with the GUI and context menues but they seem to not work without waveform data..
<azonenberg>
SingularitySurf: Yes. i uploaded a few recently, gimme a sec to find the url
<azonenberg>
the examples you were looking at are examples for how to use the scopehal C++ library
<azonenberg>
that was an example of how to build a curve tracer out of a particular R&S power supply and multimeter
<azonenberg>
sample ethernet and usb captures, with protocol decodes etc already set up
<SingularitySurf>
:D I already wondered how this curvetracer is gonna work
<SingularitySurf>
thank you!
<SingularitySurf>
Oh and btw to help people build the thing you could put the PDF in without having to build it with Tex first. Then you could look at the instructions on Git etc.
<azonenberg>
we don't have a project website or anything yet, but i have an unofficial and sometimes out of date mirror of the PDF on my server
<azonenberg>
I'm not linking it on the repo because my pipe can't handle a huge amount of traffic
<SingularitySurf>
why not just put the PDF in the repo?
<azonenberg>
I don't like putting generated files in repos because they clog up the history and make the repo large
<azonenberg>
you quickly get to massive clone times
<SingularitySurf>
makes sense..
<azonenberg>
having it be in a separate github.io website for the project, say, might make sense
<azonenberg>
kc8apf has been talking about unifying the scopehal-cmake, -apps, and scopehal repos at some point too
<azonenberg>
the multi-repo setup dates back to 10 years ago when i was working on my phd and using a custom in house build system and then made a parallel cmake build chain for people outside my lab to use
<azonenberg>
over time the cmake became the official build system but the multi repo setup was pretty entrenched by then
<SingularitySurf>
uii the ethernet looks cool :D
<SingularitySurf>
yeah, I think its not too bad as long as you have some instructions ;)
<azonenberg>
I mean this project has taken off a lot in the past few months
<azonenberg>
six months ago, i don't think anybody but me had even managed to compile it
<azonenberg>
and the documentation consisted of comments in the source code, there was no user-facing documentation whatsoever
<azonenberg>
no file load/save support
<azonenberg>
the old rendering engine was much slower and less nice looking
<SingularitySurf>
Wow it's a lot nicer than I thought at first :D
<SingularitySurf>
Without data you can't do anything and the top menu looks kinda empty
<azonenberg>
well without data or a scope, what did you expect to be able to do? :P
<SingularitySurf>
klick things
<azonenberg>
and i'm trying to keep the UI as simple and context-driven as possible. I want your attention to be on the waveforms and data
<SingularitySurf>
and scroll menus
<azonenberg>
my view is, UI chrome should stay out of your way and not be noticed until needed
<SingularitySurf>
yeah i like it!
<azonenberg>
if you've used Teledyne LeCroy scopes, my design goal was basically to keep the same clean, context-based "feel" as MAUI
<SingularitySurf>
can I change the vertical on a chanel?
<azonenberg>
except optimized for mouse/keyboard instead of touchscreen
<azonenberg>
so no giant gel buttons etc
<azonenberg>
Yes, you can. Use the scroll wheel on your mouse over the Y axis for the channel
<azonenberg>
I'm not sure if it does anything when in offline mode though
<azonenberg>
the mock scope for most part is a snapshot of what the real scope was doing at that point in time, so most set functions are no-ops
<azonenberg>
you will eventually be able to click and drag the y axis to change offset, but that's not implemented yet in the UI
<SingularitySurf>
ah tried that already but it seems to be a bit glitchy and only work on some chanels
<azonenberg>
By way of background, glscopeclient thinks it's still connected to a scope
<azonenberg>
But the mock driver returns constant values, never triggers, and generally doesn't do anything other than pretend to be whatever that scope was at that point in time
<azonenberg>
it implements all of the same APIs though
<azonenberg>
Have you tried it on a real scope yet? i forget what scope you had / had access to
<SingularitySurf>
exactly none right now xD
<SingularitySurf>
I also have some at my Uni but thats not a thing right now..
<azonenberg>
yeah :p
<azonenberg>
There's still room to test offline mode etc. And even write protocol decodes
<azonenberg>
if there's a protocol on the wishlist that you'd like to take a crack at i'll gladly send you a recording if i have hardware on hand that speaks it
<SingularitySurf>
yeah I mean as I said i just wanted to do clickyscrolly and try that ;)
<SingularitySurf>
theres probaply no way yet to get CSV data in?
<azonenberg>
No, i'm not even sure if there's a ticket for that. why/how would that be needed?
<azonenberg>
*export* to csv is a planned feature
<azonenberg>
the native scopesession format is YAML metadata then raw binary waveforms
<azonenberg>
The other thing there's room for is contributing to hardware development projects
<SingularitySurf>
ok, digilent waveforms lets you do that and that way I could have gotten other data in
<azonenberg>
The big thing is that you'd need to be able to handle all of the other metadata glscopeclient needs to work
<azonenberg>
or at least invent reasonable defaults for all that
<azonenberg>
exporting to a lossy format is easier than importing from one missing info you need
<SingularitySurf>
yeah thats not a priority ofc
<azonenberg>
anyway not sure if you know but we're also doing hardware development projects in this channel
<azonenberg>
both probes and oscilloscopes
<azonenberg>
i have a 10:1 passive probe in the final stages of development now that is easily capable of 2+ GHz bandwidth and i suspect closer to 5-10, but i don't have instruments capable of measuring that far
<azonenberg>
a prototype analog front end for a 100 MHz scope just went to fab, and i'm just about to start layout on an ADC test board for that scope now
<azonenberg>
after we test the ADC and AFE both separately and together, i'll spin a board with them combined and then a mating FPGA board
<azonenberg>
At which point we can start thinking about shipping out a handful of beta units to testers willing to buy them (I'll charge BOM cost only - no profit, but no guarantees it works although i will help debug if problems are encountered)
<azonenberg>
i hope to send the final probe design to fab by mid april and have beta units ready to send out to testers by early may
<SingularitySurf>
Yeah, I've been following anlong :)
<SingularitySurf>
along
<azonenberg>
the scope is a ways back in the pipeline as i'll have to do all of the fpga-side firmware and spin two additional boards after boards that i ordered this week are back from fab and tested
<azonenberg>
Hoping by end of this week i will have both the adc and afe board at fab and components/stencils ordered, then boards back from fab and assembled by late april
<azonenberg>
then i will need a while to test, characterize, debug, and write proof-of-concept firmware to make sure things work
<azonenberg>
and start designing the integrated 4x afe+adc and fpga boards, hopefully getting those ordered by mid to late may
<azonenberg>
so first assembled prototype probably some time in june, then firmware development will take a while. Hopefully mid to late june i can get first light off a prototype
<azonenberg>
then some time to test and polish, probably will be ready to order parts for a couple of beta units by late summer and send them out to people... early fall?
<SingularitySurf>
wow thats some quick cycle times..
<azonenberg>
not THAT quick, it's going to be a lot of work
<azonenberg>
but the boards shouldn't take a huge amount of time because most of the hard engineering was done in the AFE prototype
<azonenberg>
the probe, meanwhile, is on i think version 0.6 or 0.7 right now and i'm still optimizing it lol
<azonenberg>
multi-GHz performance is a lot harder than 100 MHz
<SingularitySurf>
I can only imagine xD
<azonenberg>
i'm working in the fun microwave realms where the exact choice of resistors you put in series to achieve a given value makes a HUGE difference
<azonenberg>
because the frequency response varies :p
<azonenberg>
lain: there's no input termination on the hmcad1520 right?
<azonenberg>
i'm adding resistors to be safe, can always DNP them
<lain>
azonenberg: not that I'm aware of, but it's been a while since I read the docs in depth
<lain>
yeah, couldn't hurt
<_whitenotifier-3>
[starshipraider] azonenberg pushed 1 commit to master [+1/-0/±3] https://git.io/JvF7v
<_whitenotifier-3>
[starshipraider] azonenberg 697b03a - finished schematic review on hmcad-characterization, ready to start layout
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<azonenberg>
hmm, this adc test board is going to be fairly large just because of all the SMAs
<azonenberg>
and minimum space between each one
<azonenberg>
but i don't feel like moving to MMCX and getting all of the adapters etc just for a test board
* Degi
thinks about writing an audio input driver for the PCIe card
<Degi>
Lol the HMCAD1520 jitter is like around 100 fs... that's goood
<azonenberg>
well that's within the adc itself presumably
<Degi>
Well sampling aperture jitter
<azonenberg>
yeah
<azonenberg>
then you have to add in jitter from the clock etc
<Degi>
If you connect the OP amp nearby and directly to the HMCAD1520 termination should be unnecessary. Try to keep the traces short, it has up to 11 pF capacitance
<Degi>
I mean yes the clock is probably worse than the ADC
<azonenberg>
for the characterization board there will be sma cables between them
<azonenberg>
so i do need termination
<azonenberg>
max phase jitter of the 1 GHz clock source i'm using on the test board is 1.8 ps, typical 1.0
<Degi>
There will probably be some reflection from the 11 pF termination, but yes in the final board design that shouldnt be needed. (I'd recommend terminating the driver, I think it already is?)
<azonenberg>
the clock mux adds another 50 fs
<azonenberg>
yeah pretty sure i have termination on the driver
<azonenberg>
on the final board all of those links will be electrically short
<azonenberg>
i may still provide a flow-through 0201 resistor footprint
<Degi>
(Technically if the driver a<nd sma is well matched you wont need termination on the ADC board because reflections would be terminated by the driver haha
<azonenberg>
it will be easy to DNP if not needed, or populate if required
<Degi>
Yes good idea
<Degi>
I have some TS391SNL paste now, heh. Should be able to test SMD assembly soon when PCB arrives
<Degi>
Huh interesting... Moisture in IC can damage IC when heated
<azonenberg>
Yeah, it's called popcorning because of the sound it makes during reflow. That's why they're packaged in moisture barrier bags
<azonenberg>
if you've had chips sitting around for a while outside a bag, it's good practice to bake them at an elevated temperature for a while to drive off moisture
<azonenberg>
i dont usualy have to worry about this as most of my semiconductors are bought when needed and not in excess, i normally only maintain inventory of passives
<azonenberg>
and the humidity in my lab, at least this time of year, is super low
<azonenberg>
like 30% or so
<azonenberg>
it's even dropped into the 20s at times
<azonenberg>
which means ESD precautions are quite important, moisture less so
<azonenberg>
which has one q-strip on each side, left is 5V power in plus FPGA I/Os and right is ethernet, MCU I/Os, and JTAG
<azonenberg>
my early breakout for testing was two small oshpark boards, one on each side
<azonenberg>
i nicknamed the "joycons" because it looked like a nintendo switch when assembled
<azonenberg>
them*
<Degi>
Will the connectors be arranged such that the host board can choose which height of connector it uses?
<azonenberg>
so this board is meant to mate with the left side only and the joycon on the right
<azonenberg>
for eth/jtag
<Degi>
Lol
<azonenberg>
i saw no reason to make a bigger host board with both connectors since this is a one-off test
<azonenberg>
and all i'd be doing was duplicating the jtag and ethernet fanout the joycon already has
<azonenberg>
I've always used 5mm mating height connectors
<azonenberg>
they have best signal integrity and, more importantly, are most readily available at distributors
<azonenberg>
my thought is to just use 5mm taller standoffs for the afe board
<azonenberg>
and mount both to the chassis independently
<Degi>
Hm I mean one connector side is fixed height and the other one is varaible height, right?
<azonenberg>
i could be wrong
<azonenberg>
but my understanding is the mating height is a function of both halves
<Degi>
Oh
<azonenberg>
you can't mate them arbitrarily
<Degi>
They were QTH-030/060 right?
<azonenberg>
otherwise they wouldn't both have unique part numbers
<azonenberg>
for both genders
<Degi>
Hm yes that makes sense
<azonenberg>
The integralstick has QTH, the adc test board has QSH
<azonenberg>
qsh mates with qth
<azonenberg>
integralstick has -060, we may be able to fit all of the signals we need for the afe+adc into an -030. I won't know until i actually sit down and design a pinout
<Degi>
Does QSH come in anything other than 01?
<azonenberg>
Yes
<azonenberg>
both are available in 01 to 05, 07, 09
<azonenberg>
6 and 8 do not appear to exist as valid mated heights
<Degi>
Digikey cant find any QSH-030-02 to 4, only 01
<azonenberg>
they're special order parts i believe. Or maybe only available in the higher pin count sizes, or both
<azonenberg>
i know the others exist because they're in the datasheet, but i've never seen them
<azonenberg>
anyway high level design of the interface specification, as well as some mechanical design for budgeting max size of the analog and digital boards, is something like item #3 on my todo for the project
<azonenberg>
top priority is to finish layout of the adc test board, complete the design review, and send it out for manufacture asap
<Degi>
And duckduckgo cant find any either, maybe the listing on the bottom corner in the datasheet is a mistake? The QTH connector datasheet looks like it just has some kinda expansion below which makes it higher...
<Degi>
Hm yes
<azonenberg>
next priority is to, when my 75 ohm resistors come in, evaluate their performance on the probe and make a final decision as to what resistors i'm using on the respin
<azonenberg>
then do mechanical and electrical design of the respin and enclosure for it
<Degi>
Of the 5 GHz probe?
<azonenberg>
Yes
<azonenberg>
after that, begin high level specification work on the afe and digital boards for the 100 mhz scope. I don't want to waste any time on schematic/layout until the prototypes are back from fab and tested in case any major changes are needed
<azonenberg>
but i feel like the list of signals required, and approximate dimensions, should be safe to figure out in advance
<Degi>
The QTH connector has a big GND plane in the middle, right?
<azonenberg>
Yes, and QSH has mating equivalents
<azonenberg>
Generally i use that as signal and power ground, then divide signals into groups of 2 single ended / 1 differential
<azonenberg>
and put power between them as a spacer
<Degi>
Yeah that sounds good
<azonenberg>
so p-s-s-p-s-s-p along the outside of the connector with solid ground in the middle
<azonenberg>
one of the other reasons i don't use -DP qstrips, then i need something else to supply power :p
<Degi>
Heh you could use a few diff pairs :P
<azonenberg>
yeah but then it would be bigger
<azonenberg>
this way also works out nicely if i use power as a reference plane for signals
<Degi>
Hm I guess at 1 gigabit, vias on diff pair isnt too bad?
<azonenberg>
i can just put a cap from power to ground right by the q-strip and be good
<Degi>
Yes -DP only has 20 pairs...
<azonenberg>
Vias are ok much faster than that. they just require careful design
<Degi>
Instead of 40 pins
<Degi>
*60
<azonenberg>
for example, a via from front to back is better than via from front to middle
<azonenberg>
because no unterminated stub at the back of the via
<Degi>
Oh yes
<azonenberg>
(this isn't a big issue until tens of Gbps, but is something to be aware of)
<azonenberg>
at 1 Gbps i wont even bother with fancy engineering of the vias
<Degi>
Oh
<azonenberg>
The only thing i do want to do is make sure that at least the DEBUG_CLK sma is properly matched
<azonenberg>
the inputs i'm less worried about as those are only 100 MHz, but DEBUG_CLK is a 1 GHz reference out in case i need it for debug
<azonenberg>
(the clock mux i use for switching between the 8-bit and 12-bit clocks is also a fanout buffer, so i figured i'd use one of the otherwise wasted channels and break it out)
<Degi>
Where will you get the 1 GHz crystal from?
<azonenberg>
Abracon. 535-12632-ND
<azonenberg>
U1 in my schematic
<Degi>
Ah I see mouser has 2 on stock, digikey just had 0
<azonenberg>
LVDS output too, super nice
<azonenberg>
wait what? digikey has 38
<Degi>
Oh hmm I checked some different part hten with the same number
<Degi>
Oh the -T version, which is probably on tape heh
<azonenberg>
That would make sense, they can't sell you a full reel because they don't have one
<Degi>
That HMCAD is very small compared to the 250 MS/s ADCs in the TDS520 lol... And probably doesn't even need a dedicated heatsink. Technology sure has come a way
<azonenberg>
Yeah i might put one on to be safe. but likely not needed
<Degi>
I mean it dissipates nearly a watt, maybe the thing from a raspi? Just put a big ground plane below lol
<azonenberg>
yeah thats what i was thinking. pi sized heatsink
<azonenberg>
Thermal calcs are a layout review task
<azonenberg>
unless i think a fan is needed, then i do it earlier
<Degi>
As long as you stay below 30 °C/W from part to air it should be fine
<azonenberg>
let me do some rough calcs here
<azonenberg>
on the characterization board, the only two major heat sources are the LDO and the ADC
<Degi>
HMCAD1511 has 29°C/W Rth
<azonenberg>
the 1520 takes 190 mA on the analog rail (digital rail uses the 1.8V SMPS on the integralstick)
<azonenberg>
190 mA from 3.3V down to 1.8 is 1.5V * 190 mA = 285 mW on the LDO, at 36C/W that's a 10.2C rise
<Degi>
5V0 supplies INTEGRALSTICK?
<azonenberg>
Yes. Which has a LT3374 based multiphase buck converter that generates 3.3, 2.5, 1.8, 1.2, and 1.0 for onboard logic
<Degi>
Fancy
<azonenberg>
but there's enough margin on those rails to supply small external stuff
<azonenberg>
LTC3374*
<azonenberg>
so i use it here rather than putting my own smps on the characterization board
<azonenberg>
anyway, the hmcad1520 says 342 mW analog, 148 digital, 490 mW total power
<Degi>
I mean yes the final design probably has these voltages from the mainboard available too
<Degi>
490 mW at 640 MS/s!
<azonenberg>
At 1 Gsps :D
<Degi>
710 mW at 1 GS/s?
<azonenberg>
oh wait am i looking at the wrong table?
<azonenberg>
sec
<Degi>
Look in HMCAD1511 datasheet for 8 bit 1 GS/s mode
<azonenberg>
i'm looking at the 1520
<Degi>
"HMCAD1520 is pin compatible and can be config-ured to operate as HMCAD1511 and HMCAD1510, with functionality and performance as described in HMCAD1511 and HMCAD1510 datasheets"
<azonenberg>
that explains why i didnt see 8 bit power consumption in the table
<azonenberg>
hmmmm
<azonenberg>
ok i have to fix something on the test board then
<azonenberg>
270 mA is too much for one LT3042
<azonenberg>
i need to parallel it
<Degi>
That is good to have noticed...
<azonenberg>
i mean it still would have worked, just only in 12-bit mode
<azonenberg>
:p
<Degi>
Lol does LDO have OCP or what
<azonenberg>
Also, the resistor on Rset *does* need to change if you parallel multiple lt3042's
<azonenberg>
they use 16.5K for 3.3V instead of 33K in figure 7
<Degi>
Yes you need to half it because you have double the current
<azonenberg>
so to parallel two for 1.8V i need to use 9K ohms
<Degi>
Yes
<azonenberg>
and another catch that escaped my initial skim of the schematic: i had 33K for 3.3V as the ref resistor
<azonenberg>
:p
<azonenberg>
On the A1v8 rail
<Degi>
OhI see
<Degi>
Lol that would be kinda expensive
<Degi>
(For some reason I forgot to check that resistor)
<azonenberg>
let's see. 9.09K should be ok right?
<azonenberg>
that would be 1.818V
<Degi>
If its 0.1%?
<Degi>
HMCAD tolerates 2 V
<Degi>
You have like 10% upwards headroom from 1.8 V
<azonenberg>
yeah honestly i could probably get away with more than 0.1% if i want to cut costs
<Degi>
Judging by the number of 1V8 pins on the connector, there is probably less than 0.1 V drop from the INTEGRALSTICK to the HMCAD?
<azonenberg>
i dont care about the absolute voltage, i just care about noise
<Degi>
Noiseless resistor haha
<azonenberg>
yes for sure. but that's a smps-derived rail for the digital side
<azonenberg>
i'm regulating analog down from 3v3
<azonenberg>
with an ldo on the test board
<Degi>
I mean V_DVDD also has min. 1.7 V
<azonenberg>
oh. yeah no way is there 100 mV drop there
<Degi>
Yes I think 9.09 k is fine for the analog rail
<Degi>
Well you need to supply 125 mA, as long as the trace from V digital to integralstick SMPS is less than an ohm it should be fine (which it is)
<azonenberg>
yeah
<Degi>
Hm I should probably build a temperature regulated reflow solderer now
<Degi>
With 3.4 kW lol
<azonenberg>
ok so with the second lt3042 on the adc rail we have plenty of headroom
<azonenberg>
for the real board, though, we may want to think about something beefier and cheaper, rather than burning $14 on LDOs
<Degi>
Oh damn
<Degi>
Yeah maybe thats a good idea
<azonenberg>
LT3042 is $7.13 @ qty 1 on digikey lol
<Degi>
We could add a damped LC filter after the LDO on the analog rail
<Degi>
LT3042 is 6 $ for IMSE and 14 $ for MPDD, whats the difference?
<Degi>
And like 2.79 $ for 500
<azonenberg>
by way of reference, the AFE characterization board has four LT3042s ($28.52) and two LT3093s ($12.48) so that's $41 of LDOs lol
<azonenberg>
now, we don't need that much for every channel
<azonenberg>
but it's still expensive :p
<azonenberg>
i'm fine with using 3042's / 3093's for rails that dont need a lot of current
<azonenberg>
but if we need >200 mA i'd want to look at alternatives vs paralleling 3042s until we run out of money
<azonenberg>
:p
<Degi>
Hm :/
<Degi>
Maybe we can feed the op amps 5 V? :P
<Degi>
We could use LDOs with a tiny bit more noise?
<Degi>
The LDOs are like half the price for 500 tho
<azonenberg>
anyway, these are engineering considerations for the final design
<azonenberg>
well all of the parts drop in price in bulk :p
<Degi>
*puts 7805 on it*
<azonenberg>
Right now, dual 3042s is a quick, safe way of making the adc test board work
<Degi>
Yes
<azonenberg>
we can re-evaluate that later
<Degi>
Hm is 12.5*25 cm enough for a reflow oven?
<azonenberg>
how big are your boards? :p
<azonenberg>
i could totally see making a board bigger than 125mm on a side
<azonenberg>
heck, our adc+afe board might be that big
<Degi>
Hm currently 115*86 mm
<azonenberg>
my current reflow oven's interior is... let me see
<Degi>
Will the adc+afe board be less than 10 cm from left to right?
<azonenberg>
Approximately 10.5 x 12.5 inches, or 26.6 x 31.7 cm
<azonenberg>
I have no idea :)
<azonenberg>
i haven't even drawn up requirements, much less started layout
<azonenberg>
As a lower bound, there will be four SMAs on the front at 15mm spacing center to center
<Degi>
Hm below 11 cm would be neat cause then it is within the PCIe specs lol, but most cases are bigger anyways
<Degi>
Maybe I can make the hotplate 25*50 cm but then the heating would be uneven...
<azonenberg>
(minimum 15 mm spacing)
<azonenberg>
So the board cannot be smaller than about 5.5cm wide or the connectors won't fit
<azonenberg>
you also will not be able to hot plate reflow this board, it will have parts on both sides
<Degi>
I mean I could just place the part side on the hotplate and add oil?
<azonenberg>
what's wrong with getting a cheap toaster oven like i did?
<azonenberg>
out of stock. but i kid you not, this is what i do all my boards in
<Degi>
Do I need the air thingie?
<Degi>
*air circulation
<azonenberg>
unmodified. i put it on the "cookies" setting, turn temp to 450F, leave it ~15 sec after all solder melts, turn it off, wait 10 sec more, open the door
<Degi>
Huh it has no fan
<azonenberg>
the actual temp gets to significantly above 450F based on the pt100 sensor i ran through, but that is the highest setting on the thermostat so i use it
<azonenberg>
Mine has a convection fan
<azonenberg>
i consider that quite important for getting good results
<azonenberg>
my old oven had a single heating element with no convection fan and you could actually see scorch marks on the board sometimes right under it from overheating
<azonenberg>
while stuff on the edges wouldnt have even reflowed fully
<Degi>
Oh
<azonenberg>
with the fan temps are very uniform. slightly cooler toward the front of the oven because of radiative losses out the door
<Degi>
Hmm I mean the hotplate would have the upside of better temperature control and more even heat...
<azonenberg>
how much better / even do you want than this?
<azonenberg>
this is a pt100 sensor ran through that oven on the cookies setting
<azonenberg>
other than the slow cooldown (could be improved with a fan blowing on the board once i open the oven up) this is a textbook ramp to spike profile with a peak temp and TAL right in the middle of the sac305 process window
<azonenberg>
this is actual measured data, not a profile target
<Degi>
Hm I wanted to stick a PT100 to an aluminium plate with carbon fiber heating element and then use phase control to control the temperature so I can just type in the temperature profile from the datasheet and be done with it
<azonenberg>
i used scopehal with my r&s multimeter and the pt100 setting
<azonenberg>
this is literally heating at max rate with the element on all the time until i hit peak
<Degi>
I think I already have software for a temperature profile controller somewhere
<azonenberg>
no fancy feedback controls needed, the thermal mass of the oven was enough
<azonenberg>
there is no feedback
<azonenberg>
it just works
<Degi>
Hm okay
<azonenberg>
"cookies" is "all elements heating, fan on"
<Degi>
(My solder datasheet says 0.5 °C/s for 90 secs
<azonenberg>
are you targeting ramp-soak-spike or ramp-to-spike profiles?
<azonenberg>
i prefer ramp-to-spike for most stuff
<azonenberg>
aaanyway
<azonenberg>
going back to before we got distracted by all of this, thermal calculations on the hmcad1511 numbers
<azonenberg>
i'm talking about the adc only for now
<Degi>
Okay
<Degi>
And it has 29°C/W Rth (To casing I think??)
<azonenberg>
thermal resistance 29C/W, that's interesting it doesnt specify to what
<azonenberg>
i usually see \theta j_a or j_c
<Degi>
Kinda seems a bit low to ambient
<azonenberg>
well, i can cheat a bit
<azonenberg>
this is a 48qfn package
<Degi>
Oh wait that could be
<azonenberg>
let me look up some other 48qfn's and see what those look like
<Degi>
For example TO220 has 19 °C/W
<azonenberg>
KSZ9031 is also a 7x7mm 48qfn
<Degi>
Hmm 29°C/W seems a bit high to casing
<azonenberg>
The datasheet there claims 9.47 C/W to case and 36.34 to ambient
<azonenberg>
So 29 sounds like to ambient
<Degi>
Oh well
<azonenberg>
At 0.71W, we're looking at a 21C rise
<Degi>
I guess no heatsink then. Especially with the vias you have theere
<azonenberg>
now, there will be some other heating from the LDOs nearby
<azonenberg>
but absolute worst case let's say 30C rise
<azonenberg>
i will probably heatsink the final board since the afe's will be putting out heat too, and it will be in a somewhat confined space
<azonenberg>
but for the testbed? totally unnecessary
<Degi>
Maybe we should have a tiny I2C temp sensor or so on the final PCB near the ADC
<azonenberg>
The final pcb will be loaded with instrumentation
<Degi>
Nice!
<azonenberg>
maybe some ina226s too
<Degi>
Some kinda way to keep temperature constant or check it is very good
<azonenberg>
we can DNP them in production units to save bom cost
<azonenberg>
if it turns out not needed
<azonenberg>
but on prototypes i want temperature, voltage, and maybe current sensing at various important points
<Degi>
Lol...
<azonenberg>
maybe not every rail but at least total current for major subsystems like "all AFEs positive, all AFEs negative, ADC" or some breakdown like that
<Degi>
16 Bit current and voltage sensor
<azonenberg>
it's a little pricey but i love them
<Degi>
Hm I mean being able to say "shit's on fire" should be good
<azonenberg>
has the adc integrated and everything
<azonenberg>
then the FPGA already has a temp sensor on it, as well as voltage monitoring for the digital core rails (i dont think vccio is included, but i could easily fan that out to extra adc channels on the fpga - yes, 7 series has a basic adc)
<azonenberg>
i will probably use a ltc3374 for the digital subsystem power like i do on integralstick, that has a thermal diode on it too we can hook up to a monitor
<Degi>
I think the ECP5 also has a temp sensor, not sure
<azonenberg>
there's a thermal sensor on the offset DAC too
<Degi>
Oh neat
<azonenberg>
we may want to do cal vs temperature on some stuff too, so that isnt bad to have
<azonenberg>
ooh dfn and not tsop? (i hate packages with pins)
<azonenberg>
only 11 bit resolution though
<azonenberg>
but that is probably fine for this purpose
<Degi>
I mean if you wanna check which channel just lit on fire? Or general power usage lol
<Degi>
Maybe I should make a list of stuff instead of posting everything into chat
<azonenberg>
yeah if you have any chips like this that seem interesting for the full system i'll definitely take it into account
<azonenberg>
in particular if you find anything that can do negative rail current monitoring
<Degi>
Hm I have a few other general suggestions too
<azonenberg>
because i'd like to instrument those too
<azonenberg>
if not i'll have to just measure total current into all negative rails at the input of the inverter
<Degi>
Huh now mouser sorts things by german name actually
<Degi>
Hm :/ maybe a current sense amp and then feed to an ADC
<azonenberg>
i've used the INA99 for that in the past
<azonenberg>
INA199*
<Degi>
Hmm maybe being able to adjust the voltage of the HMCAD lol for overclocking
<azonenberg>
Lol now you're just looking for a kitchen sink to throw in there
<Degi>
Can we add RGB LEDs
<Degi>
Hm if you have 4 precision resistors, you could use ina226 (and probably the one I linked) for low side sensing too
<Degi>
Like just voltage dividerize it to a positive voltage
<azonenberg>
There will be an RGB LED on each channel actually
<azonenberg>
off when the channel is disabled, when the channel is enabled it will show the color of the channel
<Degi>
But like on the PCB where nowhere sees them
<Degi>
Ooh can we have a transparent casing
<azonenberg>
and if the channel is error-disabled due to overvoltage it will blink red
<Degi>
Maybe a beeper for overvoltage too
<azonenberg>
the relay clicking and the channel turning off should be obvious enough
<Degi>
I'd hope so? Idk
<Degi>
But its a reed relay, you probably can barely hear it
<azonenberg>
i can add some sort of indication for channel error status in glscopeclient and the API too
<Degi>
Hm by supplying 3.3 V to OVDD we can put all devices on the same SPI bus
<azonenberg>
No, if anything i'd rather have each device on their own bus and run entirely point to point
<Degi>
Hm OK
<azonenberg>
only reason i didnt do that on the AFE test was lack of pins on the mcu
<azonenberg>
i have no idea how fast i might want to reconfigure channels in the future
<azonenberg>
i don't want to have SI or overhead preventing me from doing that
<azonenberg>
the fpga has no problem running 20+ spi masters
<Degi>
Well cause we'd probably need 60 pin connector then
<azonenberg>
The first step will be drawing up a block diagram or similar of the whole analog board
<azonenberg>
including sensors etc we plan to put on it
<Degi>
Hm oh I think the -030 already has 60 pins nevermind
* Degi
wonders if it is possible to gold plate solder
<_whitenotifier-3>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JvbfV
<_whitenotifier-3>
[starshipraider] azonenberg eb4d282 - Preliminary layout. Still have to do low speed control lines, power/ground planes, and transitions at SMAs.
<azonenberg>
ok i'm taking a break for a bit. should be able to finish this later today
<azonenberg>
in other news it's 0700 and i've been awake since about 1530, and i have to give a training for $dayjob at 1500
<azonenberg>
want to ruin your sleep schedule? a plague is the perfect way
<Degi>
Oof, take care of yourself! good night
<Degi>
Yes
<Degi>
I kinda got my sleep back from 5 AM to 2 AM lol
<azonenberg>
In pre-apocalyptic times i was anchored by going into the office once or twice a week and getting up at a set time to make my ferry
<azonenberg>
but lately i've been starting to drift since i lack that
<azonenberg>
good news is i dont have to be tooo awake for the training since it's super intro level. teaching new folks about the basics of i2c, spi, and uart protocols
<azonenberg>
as well as a quick intro to using protocol decoders on the scope in the lab. Whenever we actually get people TO the lab in meatspace...
<Degi>
Oh neat, do you like teach people at a company? Or students?
<Degi>
Lol I found a "Korona Toastofen" on ebay... how fitting
futarisIRCcloud has joined #scopehal
<azonenberg>
Internal training
<azonenberg>
every friday we have a (currently virtual) lab meeting followed by some kind of group activity
<Degi>
Neat
<azonenberg>
either we pick some random device and hack on it for a while, or one of us gives a training on some topic of interest tothe group
<azonenberg>
i have one on lab safety in the works, this one on embedded serial protocols, one on the fine points of ARM jtag
<Degi>
Ah yes, lab safety... Good thing my bedroom probably doesnt count as a lab
bvernoux has joined #scopehal
<electronic_eel>
azonenberg: had a short look at your adc board
<electronic_eel>
re the dual ldos: there is the LT3045. it is nearly as good as the LT3042, but goes up to 500mA
<electronic_eel>
so using one of those might be a cheaper option than to parallel a lot of '42ers
<electronic_eel>
but I don't know about the power for the osciallator and the clock mux
<electronic_eel>
this seems to come right from some switchers, with other digital stuff on the rail.
<electronic_eel>
I don't like that, because a non-clean power will usually increase your jitter in a measurable way
<electronic_eel>
and jitter on an adc clock will usually directly affect your adc performance
<electronic_eel>
so my suggestion is to take an ldo from 5v0 to the 3v3 for both osciallators and the clock mux
<electronic_eel>
lt3042 would be best, or at least some cheaper ldo if you really care about costs now
<Degi>
Yes it quite significantly affects ADC performance, the datasheet has a few words about that
<Degi>
20*log(2*pi*f_in*rms jitter in seconds)
<Degi>
Is jitter SNR
<Degi>
" It is of utmost importance to avoid cross-talk between the ADC output bits and the clock and between the analog input signal and the clock since such crosstalk often results in harmonic distortion."
<Degi>
"the jitter performance is improved with reduced rise and fall times of the input clock. Hence, optimum jitter performance is obtained with LvDs or LvPeCL clock with fast edges." Ok nice
<azonenberg>
Degi: yeah well this has fast edges :p
<azonenberg>
the buffer quotes 40-90 ps output rise time
<Degi>
Huh already done with sleep? :P
<Degi>
Neat
<azonenberg>
electronic_eel: I already dropped the 42 down on this board, but the 45 is probably a good choice for the actual analog board for the scope
<azonenberg>
didn't think about PSRR on the clock, i'll make a clean 3v3 rail for that
<Degi>
Hm do you have a way to feed V_CM from HMCAD to AFE?
<azonenberg>
Not on this board. AFE test board derives its own 900 mV common mode reference
<electronic_eel>
sorry to chime in that late, but there was a lot of work for me the last days and I didn't have the time to look at it earlier
<Degi>
OK as long as you measure TP1
<azonenberg>
there will be a bit of dc offset between them, and i accept it since this is a prototype
<azonenberg>
the actual board will drive the vcm of the final output stage of the afe from the hmcad
<electronic_eel>
a small dc offset at this point should be easy to cal out in software
<Degi>
It probably wont show up since its a common mode offset?
<Degi>
Like itll make distortion worse probably
<Degi>
As long as the VCM is within 0.1 V of the HMCAD VCM you should be fine
<electronic_eel>
I don't think a offset of something like <50mv should affect performance in a meaningful way
<Degi>
Well you'd probably get some distortion at a few hundred mV
<electronic_eel>
and the ref or the resistors for the 0v9ref aren't that bad
<azonenberg>
yeah but more to the point this is a testbed anyway and absolute performance isnt super critical on that front
<Degi>
Hm if the 1.8 V is fine enough that should be ok
<azonenberg>
it's mostly "make sure they play well together"
<azonenberg>
and allow me to do some initial fpga code for the hmcad before the final adc+afe board is done
<electronic_eel>
but I guess you also want to do stuff like a thd measurement to see if the afe distorts the signal
<electronic_eel>
or the adc
<electronic_eel>
so proper performance of the adc is important
<Degi>
Hm datasheet says its specified to V_CM_ADC -0.1 to +0.2
<Degi>
As long as everything is within 1 % we should be fine
<azonenberg>
electronic_eel: yeah. worst case i can solder a jumper from that test point to the adc board
<Degi>
Lol
<azonenberg>
thats one of the reasons i put the test point there
<Degi>
Hm now I do have 2000 resistors and not sure what to do
<electronic_eel>
azonenberg: another schematics idea: maybe add a jumper cap, dnp, between the debug clock out smas and the adc clock
<electronic_eel>
if the need arises to input a clock signal from the outside, this would allow to easily patch this in just by soldering in/out some caps
<Degi>
Hm also I'm in the process of building a 25*50 cm hot plate now
<electronic_eel>
Degi: use your resistors to heat the hotplate
<azonenberg>
electronic_eel: if i needed to do that i'd rework the board after pulling one of the two caps
<azonenberg>
one of the two oscillators*
<azonenberg>
also ooh i have two digikey boxes on my front porch
<electronic_eel>
but then you can't go easily back and forth, like for comparing adc performance with different clocks
<azonenberg>
havent opened them up yet since i have a call in a couple of minutes
<Degi>
They just put stuff on your front porch?
<azonenberg>
but i suspect one is my 75R resistors
<azonenberg>
Degi: what are they going to do, make me sign for it during a plague?
<Degi>
Hm idk apparently they still do that round here
<electronic_eel>
DHL also doesn't take signatures anymore here
<azonenberg>
electronic_eel: my clocks here are super stable (~1ps jitter) and the mux adds 50fs of rms jitter
<azonenberg>
i'm not worried about them causing issues
<electronic_eel>
isn't that something you want to verify with this board?
<azonenberg>
my plan is to use a lmk04806 based pll for clock synthesis on the actual system. Probably on the FPGA board, so i can use the same timebase for both AFEs and tweak phase separately for each ADC to get simultaneous sampling despite mismatched wire length etc
<azonenberg>
prototyping that would ~double the size of this board and more importantly won't affect the afe/adc board since the clock is coming from off board
<Degi>
1 ps gives you -44 dB SNR
<electronic_eel>
for example if you have some board with lmk04806 - you could hook that in via sma
<azonenberg>
I do not
<azonenberg>
that's the point
<electronic_eel>
eval board?
<azonenberg>
It's a $352 devkit
<electronic_eel>
urg
<azonenberg>
the FPGA board will basically be an artix7, lmk04806, a buck converter for the fpga and ldo for the pll, and a ksz9031
<electronic_eel>
ok, next revision
<azonenberg>
at that point it doesnt make sense, i'll put everything on the fpga board and if i have problems i'll respin it
<azonenberg>
the lmk04806 gives an even better clock than this board does if properly set up
<azonenberg>
(123 fs rms jitter)
<Degi>
Hm I guess LMK04806 is only 1 PLL, right?
<azonenberg>
Degi: it's dual plls actually, the first one is used for jitter cleaning and the second for clock synthesis
<Degi>
Huh
<electronic_eel>
hmm, let's say you do the fpga board with the pll and ethernet next - it does not have the adc on it. so you could then feed the clock from the new fpga board into the adc board you are doing now
<azonenberg>
i will be designing both simultaneously
<azonenberg>
to allow for pinout changes to flow across the connector for routability
<Degi>
In the final version, could we have all the ADC diff pairs on one side of a connector? I mean 30/3 = 10 (and there'd be one pin which doesn't have power on both sides, but if thats frame clk or so that shouldnt be too bad) and that way its probably easier to route them in-plane
<azonenberg>
And then ordering both at once
<azonenberg>
given all of the lead times i want to pipeline as much as possible
<azonenberg>
if one is ordered first, it will be by a day or two
<electronic_eel>
hmm, does adding these two cap footprints hurt performance or is it a layout nightmare?
<azonenberg>
i'm not going to wait 3 weeks for boards to come back from fab to start designing the other one
<azonenberg>
possibly both? i would need to DNP the mux at that point too
<azonenberg>
it would be extensive rework
<electronic_eel>
hmm, maybe there is some misunderstanding
<azonenberg>
it sounds like you want the debug clock SMA to change from an output to an input
<electronic_eel>
yes, exactly
<azonenberg>
if i had to do that i'd desolder the buffer chip
<electronic_eel>
just remove the coulping caps between the mux and the debug out
<azonenberg>
and just run jumpers across the qfn thermal pad
<electronic_eel>
so the debug out is floating
<azonenberg>
drop some kapton tape and run two parallel wires over the pad
<azonenberg>
and then short one of the coupling cap footprints with 0R's
<azonenberg>
also i would probably use the LMK04803 thinking more. the '806 is 2.3 - 2.6 GHz VCO
<azonenberg>
the 803 is 1.84 - 2.03 GHz which would let me use a nice round integer 2 GHz VCO to get the 1 GHz ADC clock
<electronic_eel>
as I said, this rework is certainly doable, but is no easy back and forth
<azonenberg>
~2.5 GHz doesn't divide cleanly
<electronic_eel>
just using the debug out as input would allow to change back and forth just by switching capacitors
<azonenberg>
layout nightmare
<electronic_eel>
ok, I haven't looked at your layout or the pinout yet
<electronic_eel>
Degi: in your etherpad, what do yo mean by "Measure low side voltage by using a precision voltage divider to turn it into a high side voltage"
<azonenberg>
electronic_eel: he's suggesting something that would work for voltage but probably not current
<Degi>
You can put a voltage divider from each of the low side resistor pins to the VCC rail
<Degi>
*she
<azonenberg>
have a voltage divider with one resistor to say -5V and one to +6 or something
<Degi>
But yes, the problem is that the shunt resistor has very low voltage drop and the divider error even with 0.1% is probably awful
<azonenberg>
no, if we want to actually do current monitoring on the low side i'd want to either use a negative capable shunt monitor, or a hall sensor that doesnt care about dc bias
<azonenberg>
also Degi == she? TIL
<electronic_eel>
ok, so this is about the PAC1720 current/voltage monitors, correct?
<Degi>
Hm it should say that in my twitter lol
<azonenberg>
originally ina226
<azonenberg>
just musing about something equivalent for negative rails
<azonenberg>
Degi: ah i cant remember what your twitter is
<Degi>
Could we just put the sensor onto the negative rail and level shift the I2C?
<azonenberg>
so many people use different irc and twitter handles its hard to keep straight
<azonenberg>
Yeah possibly. I'm not worried about it now
<azonenberg>
this is a problem to worry about in a couple of weeks once the test boards are back
<azonenberg>
i will not be starting design of the afe+adc board until then, except for high level approximate pinout spec and dimensional requirements
<electronic_eel>
hmm, there is a whole lot of voltage rails to monitor. maybe not use a fully integrated solution, but a adc with integrated mux and some opamps?
<electronic_eel>
the fully integrated solution is nice for a few rails and standard stuff like positive
<azonenberg>
ina199 is an option for shunt monitoring, or we could use hall sensors
<electronic_eel>
hall sensors for the small currents we have?
<monochroma>
<3 hall sensors
<electronic_eel>
just cheap lm324, a few shunt resistors and one i2c adc with a lot of mux-inputs should do it
<electronic_eel>
not that we need 24 bit resolution for power monitoring
<azonenberg>
Yeah we'll figure that out when the time comes
<azonenberg>
main thing is, i do want current monitoring on as many rails as possible for diagnostics especially on prototypes, we can DNP in production builds if we judge it's not necessary and just leave the shunt there
<azonenberg>
and i want temp monitoring for sure as that may affect cal
<azonenberg>
and temp is much less controlled than voltage
* Degi
adds peltiers everywhere
<electronic_eel>
yes, temp monitoring makes sense. but this isn't a 8.5 digit dmm, temp doesn't need to be precise to 0.1°K for cal
<electronic_eel>
so we could just sprinkle some ntcs in 0603 over the board and use a i2c adc with a lot of mux channels to read them
<azonenberg>
i like the i2c temp sensors like the mcp9801
<azonenberg>
not specifically that one but something along those lines
<azonenberg>
probably lower noise than running thermistor traces everywhere on a board full of other signals
<electronic_eel>
yes, I use those too if I just need one or two points
<azonenberg>
there will be i2c all over the place anyway
<azonenberg>
and spi
<electronic_eel>
but if you want some more, it gets too expensive for my liking, also needs several i2c busses because of limited number of addresses
<azonenberg>
fair. Although a few i2c buses on an fpga board is hardly a dealbreaker
<azonenberg>
its not like i have a mcu with one or two i2c channels
<azonenberg>
throwing down five is no big deal
<azonenberg>
Anyway, like i said engineering decisions to be made once we have rough requirements drawn up
<azonenberg>
AFE test board parts are here. but the other digikey box was some backordered smt mmcx connectors from months ago i had forgotten were even coming
<azonenberg>
not the 75R's i was waiting on :(
<azonenberg>
those, apparently, havent even shipped yet
<Degi>
Oof
bvernoux has quit [Quit: Leaving]
<Degi>
Okay I almost finished the TDC TAC part... Only misses ADC and OP amp and S/H maybe
<electronic_eel>
hmm, if your distributor changes your part to moq 800 and "only on special order" a few days after you ordered - that is a bad sign, right?
<Degi>
Is 15 mm between two SMA centers enough to be screwable?
<electronic_eel>
15mm is tight
<electronic_eel>
my torque wrench has 14mm od
<electronic_eel>
but you don't want to just fit it in, but also turn it...
<Degi>
Huh torque wrench?
<electronic_eel>
for properly tightening sma to spec?
<Degi>
Hm okay
<electronic_eel>
now I got it on ebay and didn't send it to cal, but still...
<Degi>
Hmm
<Degi>
I do wonder if this circuit works at all or if something oscillates lol
<electronic_eel>
hehe, the spice will often not show you as the models often aren't good enough