<Degi>
I mean there's a bunch of free space up there but they locked the door for some reason lol
<electronic_eel>
maybe ask nicely?
<Degi>
Hm maybe
<electronic_eel>
I got the permission to use part of a room in the basement as workshop
<Degi>
I could put a server room up there lol
<Degi>
On the other hand everything is out of wood up there so I better have some good fire extinguishers
<electronic_eel>
some smoke alarm which automatically trips the circuit breaker?
<Degi>
Hm probaby something like a CO2 extinguisher system or so
<electronic_eel>
forget it, those cost > 20 kEUR
<electronic_eel>
I got some quotes for the server room at work
<azonenberg>
i am planning to build one myself for the lab, at least for everything fed by UPS
<Degi>
Lol I can just mount a CO2 bottle over it and when it burns it bursts
<azonenberg>
if a smoke alarm goes off (in the lab only, not the rest of the house)
<azonenberg>
it will hit the EPO relay
<Degi>
I mean you could plug copper tubes with low melting solder and above a certain temperature it'd just melt off and release thegas
<azonenberg>
this can be done entirely with ul listed COTS parts
<azonenberg>
Degi: they make fire suppression systems like that using more human safe agents like FM-200
<azonenberg>
basically a sprinkler head mounted to a bottle of agent that goes on a wall
<azonenberg>
seriously planning to get one or two for my lab
<electronic_eel>
you need some mechanism to vent the pressure afterwards, also some safetey if humans are in the room
<Degi>
Maybe argon. That is better for the enviroment. Our university uses that.
<azonenberg>
vastly chepaer than a professionally engineered sprinkler system
<Degi>
The roof blows up lol
<azonenberg>
FM-200 is human safe at extinguishing concentrations
<azonenberg>
Which is why i was planning to use it
<Degi>
FM-200 is a fluorinated organic compound, in a fire that may release bad stuff and its probably very bad for the environment
<Degi>
In terms of GWP
<azonenberg>
Yes but how much CO2 does your house burning down emit? :p
<Degi>
Argon is perfectly safe (besides suffocating you)
<Degi>
Hm idk not sure how good bricks burn, besides the roof
<azonenberg>
it's better than halon
<azonenberg>
ok yeah my house is wood frame :p
<Degi>
Why not argon lol
<azonenberg>
Because i want to survive the thing going off?
<Degi>
Why is FM-200 better than argon?
<Degi>
I mean both take away the oxygen
<azonenberg>
there's a reason codes ban argon/co2 type agents in occupied spaces
<azonenberg>
no
<azonenberg>
fm-200 produces both a cooling action and chemically interferes with combustion
<Degi>
Ah in occupied spaces
<Degi>
Hmh interesting
<Degi>
I mean the server rooms all have argon or CO2
<azonenberg>
it does not function by oxygen displacement
<azonenberg>
yes, because they're not meant to be occupied
<Degi>
Suffocation versus "At high temperatures, heptafluoropropane will decompose and produce hydrogen fluoride" heh
<azonenberg>
they probably also have an alarm go off with like a 30 second timeout before the agent is released
<azonenberg>
To give you time to evacuate
<electronic_eel>
even if they are not occupied, there are often techs working in there
<sorear>
Degi: halon-ish chemicals suppress fires at 1% concentration
<Degi>
Oh neat
<azonenberg>
And unless your agent tank gets hit by an RPG (this is a real concern) the smoke will kill you long before the HF does
<sorear>
they can be toxic, but they don't displace a material amount of oxygen
<azonenberg>
yes, i read a case study in a medical journal about that
<Degi>
Lol probably not put that stash of RPG's near the tank then
<azonenberg>
tl;dr if a military vehicle has an RPG hit the fire extinguisher, assume HF poisoning in all occupants even if not visibly injured
<azonenberg>
and the prognosis will greatly improve if you treat before symptoms show up
<sorear>
got a stash of calcium supplements somewhere near the evac path? :p
<azonenberg>
I looked at Inergen which has lower GWP than FM-200 but is not available in pre-engineered systems
<azonenberg>
that does function by oxygen displacement, but is carefully titrated rather than flooding to zero% O2
<azonenberg>
so you need careful calculations to get uniform agent concentration throughout the space
<azonenberg>
basically the goal is to get oxygen concentration low enough that most common materials won't support combustion, or will only smolder until the fire dept gets there
<azonenberg>
but keep it high enough that occupants won't suffocate
<Degi>
What if you make your room airtight and vacuum proof and just have a bunch of really fast vacuum pumps...
<azonenberg>
there is a narrow process window but it's there
<electronic_eel>
that seems to be difficult if there is stuff in the room preventing an equal flow of the gas
<azonenberg>
Yes. You need a lot of heads and careful modeling of mixing
<azonenberg>
sometimes even test discharges with somebody walking around in an scba with an o2 meter
<Degi>
I think argon with 3% CO2 would be nice, that should make you feel suffocating. That's better than not feeling that you're suffocating and just dying at least
<azonenberg>
Degi: that's basically what inergen is
<azonenberg>
just at less than total flood concentration
<azonenberg>
it's essentially the waste product of making LOX spiked with extra CO2
<electronic_eel>
Degi: do you feel CO2 poisoning that fast? I thought it takes some time till you feel it
<Degi>
Hm not sure
<Degi>
At least you feel it?
<electronic_eel>
and then it is too late with these high concentrations
<azonenberg>
Inergen is designed to have a little bit of extra co2 to cause you to breathe harder
<azonenberg>
and compensate for the reduced o2 level
<azonenberg>
it's actually quite a clever design
<sorear>
last time I got a faceful of 100% CO2 It took a small fraction of a second to feel like someone was choking me
<sorear>
I'm not sure what the concentration threshold for that effect is - I know people can be affected by ~1000 ppm CO2 without noticing
<electronic_eel>
sorear: how did you get CO2 blasted?
<sorear>
don't recall, should probably try again under controlled circumstances
<Degi>
Hm I have some funny things that'd probably react with FM-200 and CO2 lol
* Degi
pours rubidium into a server
<azonenberg>
That's not how you make a tier 1 NTP server, you know
<azonenberg>
stratum 1*
<Degi>
Idk, those fancy new servers with an isotope centrifuge and unfilled atomic clock inside them...
Degi has quit [Ping timeout: 250 seconds]
Degi has joined #scopehal
<_whitenotifier-3>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±10] https://git.io/JvQeC
<_whitenotifier-3>
[starshipraider] azonenberg 27851e9 - Continued design review, began assigning footprints to sch symbols
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<_whitenotifier-3>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±7] https://git.io/JvQTO
<_whitenotifier-3>
[starshipraider] azonenberg c5ea6f3 - Continued assigning footprints
<azonenberg>
ok at this point i have everything but the IC footprints done
<azonenberg>
and all passives picked out
<azonenberg>
currently pushed schematic has actual values for all passives with tolerances if necessary, ro
<azonenberg>
rounded to nearest standard values, etc
<_whitenotifier-3>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JvQTZ
<_whitenotifier-3>
[starshipraider] azonenberg b825fb7 - Continued pre-layout design review, checked off completed tasks
<azonenberg>
electronic_eel: btw, how far do you think we can push this AFE design?
<azonenberg>
i think it will work all the way up to the midrange 500 MHz scope with minimal modifications
<azonenberg>
The LMH6552 has 1.25 GHz bandwidth at unity gain
<azonenberg>
the ADL5205 is good out to 1.7 GHz
<azonenberg>
So for a 1-2 GHz scope (the BFS, for lack of a proper name) i will probably want more headroom on bandwidth, but i think this same design should work for ~everything up to that point
<_whitenotifier-3>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±10] https://git.io/JvQIq
<_whitenotifier-3>
[starshipraider] azonenberg f7cc4dc - Continued schematic review. Done with everything but test point/ground insertion.
<azonenberg>
oh lovely, the UFQFPN28 stm32 package requires angled pads in order to not short at the corners
<_whitenotifier-3>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±10] https://git.io/JvQLW
<azonenberg>
ok, that's everything for schematic. now to start layout floorplanning
<electronic_eel>
azonenberg: I think 500 MHz will probably work
<electronic_eel>
the other scope vendors usually seem to have one design <200 MHz and then 500 MHz
<electronic_eel>
or <= 350 MHz
<electronic_eel>
azonenberg: I still suggest to add caps to 05V_REF and N05V_REF. 100nF or so.
<electronic_eel>
if you don't like them, just add at least the footprints so that they can be added later if necessary
<azonenberg>
I have caps at point of load for each
<azonenberg>
i thought
<electronic_eel>
did I miss them? don't see em
<azonenberg>
No, i did :p
<azonenberg>
i'll add 'em. good catch
<azonenberg>
and basically my thought is, this AFE is a bit overkill for 100 MHz but if we can reuse the engineering on the faster scopes, it's worth it
<electronic_eel>
I have been bitten by changing bias currents on LM393 in the past
<azonenberg>
i'm not going to try and ultra cost optimize the entry level unit at this point since, from my perspective, the goal of the entry level scope is to learn the skills needed to make a faster one
<electronic_eel>
so these caps are on my (virtual) checklist
<electronic_eel>
yeah, I consider the 100 MHz scope as a bit of a training ground
<azonenberg>
We can always make a second low-end scope that cuts more corners later on if this one is too expensive to sell well :p
<azonenberg>
but my goal has never been to be the f/oss rigol competitor
<azonenberg>
i want to be competing with keysight and lecroy
<electronic_eel>
if you look at the rigol 1054z and similar, they will be hard to beat price-wise. and beginners usually start really price sensitive (because they are students or similar)
<azonenberg>
There's no way to match their price without their volume
<azonenberg>
so i'm not even trying
<electronic_eel>
yeah, wise choice
<electronic_eel>
but when the scopehal sw works well with the entry scopes, they'll see what they are missing
<azonenberg>
Exactly :)
<azonenberg>
when they see the 1 WFM/s update rates because it's maxing out the ds1054z's CPU... :p
<azonenberg>
and then our slightly more expensive one pushing way more than that
<electronic_eel>
the whole design of these scopes is built to display the wfms on the screen, not to send them out to ethernet
<electronic_eel>
or usb
<azonenberg>
Yes, i know
<azonenberg>
and they fail horribly when you try to do that :p
<azonenberg>
even lecroy stuff, while usable, is not nearly as fast in scopehal as on local console
<azonenberg>
also i'm not aware of *any* low-end scope with 8 channels
<azonenberg>
some niche users will want that for sure
<azonenberg>
lecroy doesn't start offering 8 channels until the waverunner 8000HD series, or HDO8000A series
<azonenberg>
Which start at $28300 and $26600 MSRP respectively for the 350 MHz version
<electronic_eel>
8 channels is niche. there is one higher model from tek that has 8ch from the start
<azonenberg>
meanwhile, the ds1104z is $439 for 100 MHz 4ch 1 Gsps
<electronic_eel>
or maybe the hardware is there but you have to buy a license for it or so
<azonenberg>
Which is ~the performance i'm targeting, except we'll have 12 bit mode, optional 8 channels, 50 ohm inputs, etc
<azonenberg>
and of course it's all open source
<electronic_eel>
but don't you usually buy the lowest rigol of a series and use a keygen?
<electronic_eel>
that is at least what I did with my rigol and siglent stuff
<azonenberg>
the 70 MHz ds1054z is $403.92
<azonenberg>
on tequipment
<azonenberg>
so not really significantly cheaper
<azonenberg>
if it was me, i'd buy the 100 MHz version, skip pizza that week, and know the scope was actually tested to full bandwidth :p
<electronic_eel>
on this range of scopes I don't think there is any cal difference between 70 and 100mhz
<electronic_eel>
the difference is lost in the noise the scope always has
<azonenberg>
Fair point
<azonenberg>
anyway like i said, i'm not trying to displace rigol's market
<azonenberg>
so being price competitive isn't necessary :)
<azonenberg>
also, this afe is going to be quite long if laid out in a nice linear fashion
<azonenberg>
i think i may end up in some kind of S-curve layout, not sure yet
<azonenberg>
Both the relay and filter/attenuator bank are super long and skinny
<electronic_eel>
long and thin will suit rack cases well
<azonenberg>
well more to the point, we have to space out the SMAs in order to avoid hitting adjacent probes etc
<azonenberg>
so i want to use the space between them efficiently
<azonenberg>
I also am not going to be targeting a super deep case for this, i want it 2-post friendly
<sorear>
is crosstalk a concern if you have several physically extended AFEs closer to each other than their own length?
<azonenberg>
Tentative target is Hammond RM1U1908VBK
<azonenberg>
sorear: only trace to trace spacing matters
<electronic_eel>
I think the higher end models will need separate shield cages over the afes
<azonenberg>
i'm using oshpark for the prototype, but the final 4x AFE + ADC board will probably be custom stackup. And that is certainly a possibility
<azonenberg>
i'm not sure how big a deal it will be on the 100 MHz version
<azonenberg>
electronic_eel: anyway that case is only 203 mm deep, and i need some space for the fpga board
<azonenberg>
so i would really like if the afe+adc board wasn't much more than 100mm deep
<azonenberg>
Right now my WIP layout is 66 mm from SMA edge launch to the far side of the offset stage
<azonenberg>
but i think i'm going to fold that around into an S-curve so the filter bank is parallel to the relay running back towards the front of the case, then the offset stage going around to the back
<azonenberg>
after that, i think the rest will fit well
<electronic_eel>
maybe the fpga can fit over/under the afe board. if there are shields around the afes I don't see a problem noise wise
<azonenberg>
That's a possibility too. But how close do we really plan to smoosh the channels?
<azonenberg>
gimme a sec here to do some math
<azonenberg>
So the body of a 19" rackmount case is on the order of 410mm wide on the inside, not counting ears and wall thickness etc
<azonenberg>
Suppose I have 130mm at left reserved for a touchscreen LCD (635-112-ND) on the front panel, and the mains-to-12V power supply brick inside the chassis
<azonenberg>
This leaves 280mm wide x ~200mm deep for the scope proper
<electronic_eel>
do you want the mains supply inside the case? external is way cheaper in my experience
<electronic_eel>
the only thing might be the mains trigger
<azonenberg>
something like the TDK-Lambda LS200-12 but smaller
<azonenberg>
is what i was envisioning
<azonenberg>
anyway, we can always go wallwart but i'm trying to reserve the space at this point in engineering
<azonenberg>
If we reserve 100mm at the back for the FPGA subsystem and rear connectors (ethernet, refclk in, refclk out, maybe trigger out) that leaves us roughly 280mm wide x 100mm deep for two acquisition boards, or 140 mm x 100 mm for each
<electronic_eel>
at work we wanted to have the mains supply inside a device too, but then we did the math and it was not worth it
<azonenberg>
each board needs 4 input channels so we can space the probe connectors as far as 35 mm pitch if needed
<azonenberg>
i want to target 20-25 mm pitch for the AFEs
<azonenberg>
so we have front panel space free for external trigger input etc
<electronic_eel>
for stuff <100w there is a huge price difference. also all the extra safety stuff you have to do for ce
<azonenberg>
either way we need the front panel space reserved for the LCD
<electronic_eel>
(don't know about ul or other regulations)
<azonenberg>
if we don't put a psu there it can be empty, or fpga board, or something else
<azonenberg>
Roughly speaking, i think we'll be in good shape if we can have the AFEs 25mm wide x 75mm deep
<azonenberg>
that leaves 25 mm at the back of the acquisition board for the ADC itself, and maybe the power supply. I don't think we'll need 100mm for the FPGA board so we can steal some of that depth for the PSU too probably
<azonenberg>
~15 mm is a reasonably dense spacing for SMAs but 25 mm should be comfortable to access
<azonenberg>
that's significantly denser than most COTS scopes, all of the 8 channel lecroys i've seen have two rows of four probe connectors because of how big probus is (and probably their AFE is bigger)
<azonenberg>
They actually have two 4 channel acq boards, one horizontal and one vertical
<electronic_eel>
25mm pitch between the channels is a lot denser than other scopes, yes
<electronic_eel>
if you expect the users to stick to sma than I don't see an issue with it
<azonenberg>
like we've discussed, SMA is much denser but more importantly it sends the message that this is not like other scopes in its class
<electronic_eel>
if someone wants to use bnc to sma adapters and then put another active probe with big case on, then it will become tight
<azonenberg>
if you see BNC on test equipment you assume 1M
<azonenberg>
if you see SMA or N or something like that, you assume 50 ohm
<azonenberg>
and my thought is that our active probes will have most of the stuff either in the probe tip, or in a mid-span body
<electronic_eel>
but the long adapter chains will also be a mechanical problem with torque
<azonenberg>
with a single 50 ohm SMA going back to the scope, and possibly a separate power cable
<azonenberg>
i am not planning to hang boxes off the front of the scope
<azonenberg>
Very different design philosophy
<electronic_eel>
i am not thinking about the stuff you offer, but someone using a probe they already have
<electronic_eel>
or some highend stuff you don't offer
<azonenberg>
my response will be, use a sma cable and put the box on your bench
<azonenberg>
we can include a caution to that effect in the manual
<azonenberg>
bonus: spacing the channels tight prevents such idiocy :p
<electronic_eel>
yes, i think that is reasonable. so we just need sma and power/data with a respective plug
<azonenberg>
Yes
<azonenberg>
We'll define the plug and pinout later
<electronic_eel>
I was thinking about this smart probe / plug interface a bit
<azonenberg>
maybe some kind of mini din?
<electronic_eel>
custom coax cables are unreasonable without big numbers
<electronic_eel>
so it will be two cables, the coax and a data cable to the probe
<azonenberg>
correct
<azonenberg>
which i dont think is a huge problem
<electronic_eel>
we need a plug for the data cable that is convenient to plug in, reliable and cheap
<electronic_eel>
also small would be a benefit
<azonenberg>
Yes
<electronic_eel>
how about usb-c?
<azonenberg>
i was actually just thinking that. but would it be nonstandard?
<electronic_eel>
put a mcu in the probe instead of just eeprom i2c
<azonenberg>
or actual usb
<electronic_eel>
let the mcu handle actual usb
<azonenberg>
So actual usb c?
<electronic_eel>
actual usb c on the usb 2 lines
<electronic_eel>
and cc
<azonenberg>
Would be very inexpensive, dense, save us the trouble of making cables, give it a nice modern look
<electronic_eel>
if the scope sees a custom protocol, it uses the usb 3 lines for providing higher voltages
<azonenberg>
or we could do usb pd? :p
<electronic_eel>
no!
<azonenberg>
Lol
<azonenberg>
5V might even be ok, we'd just need a boost converter in the active probes
<electronic_eel>
also we want negative voltages which isn't in pd
<azonenberg>
2.5W for an active probe i think is doable, no?
<electronic_eel>
I'd like to avoid the booster in the probe, because of the additional noise filtering required
<azonenberg>
we can even go over the usb current limit
<electronic_eel>
makes the probes bigger
<azonenberg>
so you want something like +/- 7V that we can use to LDO directly?
<electronic_eel>
yes, something like that
<azonenberg>
We can give this more thought later. it's a possibility
<azonenberg>
Idea: have the power be using both legs on the high speed diffpairs, s.t. differential voltage on each pair is zero
<azonenberg>
minimizes the chances of damage if something goes wrong and you plug in a "normal" usb device
<azonenberg>
since the high speed lines are normally capacitively coupled on the device
<azonenberg>
kinda like how PoE works
<azonenberg>
only use the common mode
<electronic_eel>
good idea.
<electronic_eel>
but I think we have to work a bit on the details, to make sure the usb-c stays pluggable in both directions
<azonenberg>
Yes
<azonenberg>
if we use the diagonally opposite data lines for +7 and -7 and use ground as ground, it could work
<azonenberg>
do a 180 and the data is still data
<azonenberg>
the power is still power*
<azonenberg>
This would be bizarre enough that it would probably not pass usb-if certification
<azonenberg>
but i'm fine with that as we're not going to care about using USB logos
<azonenberg>
and are not even attempting to use third party usb devices
<electronic_eel>
don't know how these usb certification tests work in detail
<electronic_eel>
I think the trick is that we only enable the +-7v on the scope if we know that a probe is connected
<electronic_eel>
have only the regular 5v and usb2, talk to the mcu on the probe, and enable the +-7v if the probe wants it
<electronic_eel>
that way we can be sure that no harm is done if the user plugs in any other usb devide
<electronic_eel>
device
<azonenberg>
my point is more, i think using the pins for anything but high speed data would be a usb spec violation
<azonenberg>
unless we were to implement it as an "alternate function"
<azonenberg>
which would first involve defining said AF
<azonenberg>
and getting it approved by usb-if, etc
<electronic_eel>
but we don't advertise to provide high speed data, so the pins could also be floating
<azonenberg>
I'm not saying we cant do it, i'm just saying we probably pass certification tests and use usb trademarks on the system
<azonenberg>
Which is totally not a big deal IMO
<electronic_eel>
yeah, no big deal
<azonenberg>
Re layout, my plan is to have all of the diffpairs routed loosely coupled as 50 ohm length matched single ended lines
<azonenberg>
keeps impedance calculations simple, and the way some of the parts are structured it just doesn't make sense to try and closely couple
<azonenberg>
here's what we have right now. input protection relay, attenuator, antialiasing filter, and offset stage laid out
<azonenberg>
the white silkscreen rectangle is the 25x75 mm area target for one channel's AFE (power supply excluded)
<azonenberg>
oh and DAC excluded, as that's not part of any one channel
<azonenberg>
and of course the MCU
<azonenberg>
the two traces coming off TP6/7 are VIN_OFFSET. not final layout, just allocating space for where it's gonna go
<_whitenotifier-3>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±5] https://git.io/JvQqd
<_whitenotifier-3>
[starshipraider] azonenberg ff42642 - Began work on layout
<electronic_eel>
you are thorough in creating your footprints as you include the 3d models
<electronic_eel>
I often are too lazy for it
<azonenberg>
that's one of the ways i cross-check the footprint is right
<azonenberg>
sometimes i can't find a step, but it's a free bug-check if i can get one
<electronic_eel>
I often found that the 3d models provided are buggy
<azonenberg>
well if there's a discrepancy i investigate and resolve it
<azonenberg>
in this case, the model provided is for a 4-pin relay not a 6
<electronic_eel>
in the end I try to have all parts in hands before sending off the pcbs to manufacturing
<azonenberg>
(this is a 50 ohm RF relay with coax shield)
<electronic_eel>
then I print out the final design and put the parts on to see if it matches
<electronic_eel>
of course only for the stuff I haven't used often before
<azonenberg>
anyway so i think this layout is probably the way to go. Big S-curve left, parallel to the relay, for the attenuator and filter, then the offset stage going back to the right
<azonenberg>
gain stage will go just south of D3/R1
<azonenberg>
in a multichannel system, we'd mirror alternate channels as close as possible, so that we can share a gain stage between them
<azonenberg>
since it's a 2-channel part
<electronic_eel>
ah, correct
<azonenberg>
and then split back apart again for the final 2 dB and common mode adjustment
<azonenberg>
then merge again, along with the other two, going into the ADC
<azonenberg>
(making this work with emi cans might be fun... to start i want to try just in-plane guard rings/via fences and see if that is good enough)
<electronic_eel>
I'd also put the lt3042 next to it's power hungy ADL5205
<azonenberg>
so that's an option, but i was thinking of splitting them apart a fair bit for thermal reasons
<azonenberg>
i dont want the hottest ldo right next to the most power hungry chip
<electronic_eel>
the chip yes, but will the ldo get hot? it's in dfn and will only burn a volt
<azonenberg>
My thermal calculations say about a 12C rise. So, not scorching but not nothing
<azonenberg>
and it's 2V
<azonenberg>
adl5205 is a 5V part fed off the 7V rail
<azonenberg>
it's also the highest current of our lt3042s
<electronic_eel>
ah, right
<azonenberg>
about 340 mW burned in the LDO if memory serves me right
<electronic_eel>
yeah, so 12C seems about right
<azonenberg>
then another 875 mW in the ADL5205
<azonenberg>
seems reasonable to space them out, no>
<azonenberg>
?
<azonenberg>
perhaps put the lt3042 in the bottom left corner of the AFE which is currently unoccupied?
<electronic_eel>
yes, that would be an option
<azonenberg>
(the multichannel system will have a mcu and usb-c connector there, but also probably be a mostly new layout anyway because different stackup, design rules, etc)
<electronic_eel>
I think the layout matters a bit for performance, but this test board is mostly not for measuring that, but for testing the overall afe design
<azonenberg>
Correct. There will be significant additional testing on the final-ish layout
<azonenberg>
i mean, for the BFS i will have sonnet gold and probably do full field solver modeling of everything including crosstalk etc :p
<azonenberg>
But for a 100 MHz AFE i think this is overkill
<electronic_eel>
yes, the 100mhz should be doable without
<azonenberg>
well i mean i have sonnet basic. Just too crippled ram/layer count wise to model a sizeable chunk of the afe
<azonenberg>
anyway i'm fairly confident i can make this layout work in the space available for the AFE. not sure on actual final board size yet
<azonenberg>
but i think we can definitely fit 8 channels side by side in 1U x 75 mm with enough space on the left for the LCD and on the right for the external trigger input
<azonenberg>
(probably a panel mount connector with a SMA pigtail into a comparator+DAC mounted on the FPGA board)
<Degi>
x75 mm means 75 mm deep?
<azonenberg>
yes
<azonenberg>
i'm targeting the entry level scope fitting in a Hammond RM1U1908VBK enclosure
<azonenberg>
one fpga board and two AFE boards plus the config LCD
<azonenberg>
two AFE+ADC*
<Degi>
Hmm
<Degi>
Ahh right we have 4 channels
<azonenberg>
each channel is going to be roughly 25 x 75 mm, the whole afe+adc board will be around 100x100 including power supply, dac, and adc
<Degi>
Maybe we could even fit 16 channels, space-wise...
<azonenberg>
No. 8 is going to be relatively tight width wise
<Degi>
Oky
<azonenberg>
moving to more than 8 channels would require going to a vertical blade-style form factor
<azonenberg>
Which i plan to do for at least the high end and possibly the midrange units
<Degi>
I just thought because in 40 cm, 2.5 cm fits 16 times
<azonenberg>
yes, except we need space for the LCD, space between boards, the external trigger input, etc
<azonenberg>
and i may not fit in 25 mm
<Degi>
Hmm fine
<azonenberg>
35 mm is the space i calculated i had available per channel
<azonenberg>
i'm aiming for 25
<azonenberg>
(also we may need space between channels for an EMI can, not included in that 25)
<azonenberg>
i can't rule out 12 but even that would be tight. 8 is already double what any competing entry level scope has
<electronic_eel>
if someone wants 16 channels, i suggest to use 2 scopes and some clever way to link them
<Degi>
I mean you could mount the trigger and LCD above/below the input SMAs. Also will the backside get a refclk input/output?
<electronic_eel>
I'd say refclk in/out and trigger out on the back
<Degi>
Hm would refclk out be a PLL output? That way you could compensate for phase shift in the cabling (and allow for adjustable frequency on there)
<electronic_eel>
I think these features make more sense on the input than on the output
<Degi>
Okay
<electronic_eel>
because if you have a "dumb" lab reference, you can use that for all your scopes
<Degi>
I'd add caps to ground nearby D3
<electronic_eel>
higher end scopes tend to have a higher freq oscillator too, I think 100mhz is common
<electronic_eel>
while the refclks are usually 10mhz
<electronic_eel>
so the input needs a pll for that
<Degi>
I took a closer look at the QTH connectors and found the -D-DP variant, maybe something like the QTH-020-02-L-D-DP-A which has 20 differential pairs (we need 11) leaving 18 pins for power and data (1 A per contact, I'd not do more than 0.5 A, because 1 A leads to 30 C temperature rise). You can configure it here https://www.samtec.com/products/qth-dp though it says for heights larger than -01 that its a nonstandard option, digikey still has them.
<Degi>
We have probably like 10 data pins and 8 pins for power should be more than enough (+-7 V 1 A, maybe 3.3 V 0.5 A which gets regulated to 2x 1.8 V onboard, the HMCAD can do 3.3 V for the CMOS inputs too but needs 1.8 +- 0.1 V otherwise, which should be done onboard)
<Degi>
If we have a trigger out on the back, we could have a trigger in too, that'd allow synching the triggers of multiple scopes (without needing to wire trig out from the back to ext trig in on the front panel)
<electronic_eel>
Degi: the LT6014 is ten times the price of the OPA07. it has nower noise and is nicer of course. but I'm not convinced that it would help much in the place we are using it
<Degi>
Hm okay. Well, it's mostly smaller.
<electronic_eel>
yes, but I'm not sure we are that space constrained that it matter that much
<electronic_eel>
about the trigger in: azonenberg explicitly said something about having a external trigger on the front
<Degi>
I mean a second trigger in on the back
<electronic_eel>
why a second one?
<Degi>
To synchronize the trigger of multiple scopes
<electronic_eel>
but can't you use the one on the front for that too?
<Degi>
Hm then you'd have to put a cable from the back of one unit to the front of another...
<Degi>
Kinda wonder if its possible to sync that over the network
<electronic_eel>
ah, convenient cabling. yes.
<electronic_eel>
there is ieee1588 (if i get the number right)
<electronic_eel>
but that is not nearly good enough for scope triggering
<Degi>
Pretty sure network switches have some jitter
<electronic_eel>
it is more designed for multimeter triggering and similar
<electronic_eel>
yes, network switches have lot's of jitter
<electronic_eel>
there are better ones which measure the time difference between packet in and out and put it in the outgoing packet
<electronic_eel>
but this is usually only done on switches designed for multimedia broadcasting and similar
<electronic_eel>
also $$$
<Degi>
I think just sharing trigger and clock signal should be enough, since that provides a fixed time delay which can be calibrated out.
<electronic_eel>
yes, that is the traditional way of doing it
<electronic_eel>
one could also think of more complex triggers, like multiple conditions having to be met for the trigger to go off
<electronic_eel>
so the trigger signals could go both ways between scopes
<electronic_eel>
but if one scope already has an easy way to get 8ch, I think that a very large percentage of usecases is already handeled
<electronic_eel>
my first scope was 2ch. that was often very limiting
<electronic_eel>
I now have 4ch with logic analyzer and that works for most things
<electronic_eel>
so when we offer 8ch, that should be good for most usecases
<electronic_eel>
so I think having a regular trigger in / out should be enough
<Degi>
Hm maybe the in/out on the backside can directly go to the FPGA and there custom conditions can be applied.
<electronic_eel>
just one thing azonenberg should consider in his size calculations: some space for a logic analyzer in
<Degi>
Can't you just put that below the SMA connectors?
<Degi>
What connectors do good logic analyzers use nowadays?
<electronic_eel>
the ones on my rigol use a pcie connector for 8 probes. that works quite well
<Degi>
I think we can then just lead the PCIe connector straight to the FPGA
<electronic_eel>
from the pci connector you have a cable going to a small box, and there you plug in the probes or wires
<electronic_eel>
I wouldn't go "directly" as without any buffering or protection
<Degi>
Hm okay maybe some ESD diodes yeah
<electronic_eel>
fpga ios are very sensitive to esd and stuff
<Degi>
The good thing about going directly is that for example the ECP5 has switchable termination resistors and the IO bank voltage can be controlled too.
<electronic_eel>
maybe better to use some lvds line drivers or similar and have a matching driver in front of the fpga
<Degi>
You mean in the box?
<electronic_eel>
yeah, in the box you have fast comparators and from there you go to the line drivers
<electronic_eel>
on the scope you have matching line drivers as inputs and go to the fpga from there
<Degi>
Hm ECP5 is rated >1000 V class 1C (not sure what the class is)
<electronic_eel>
but i haven't looked at the different options and driving standards yet
<electronic_eel>
hbm?
<Degi>
Yes
<electronic_eel>
that is very very low
<Degi>
Yeh kinda
<electronic_eel>
something that is pluggable from the outside shoud be >= 8kv hbm
<Degi>
Usually they have like 2000
<Degi>
Hm really
<Degi>
I mean I guess adding low Z ESD diodes with low Z caps to ground would fix that
<electronic_eel>
otherwise you should just use it on a esd protected bench
<Degi>
And 500 V charged device model, besides for the serdes which is 250 V
<Degi>
Do people touch PCIe pins with more than 250 V charged devices?
<electronic_eel>
"charged device" is something like a paperclip or screw driver
<electronic_eel>
not some fancy spark generator
* Degi
side-eyes the capacitor bank
<electronic_eel>
yeah
<Degi>
Well that thing blows holes into glass at less than 100 V... huh
<Degi>
Hm I hope I didn't damag the serdes of the dev boards. I usually keep it in an antistatic bag and before I touch the board I try to touch GND or antistatic bag.
<electronic_eel>
esd damages don't happen that often. but they are often hard to diagnose and lead to strange problems afterwards
<electronic_eel>
because debugging these is so time consuming, the industry takes esd seriously
<electronic_eel>
so if you have a cap bank, did you try to use it with some protective devices yet?
<electronic_eel>
like if a spark plug can save something from damage?
<electronic_eel>
no I mean gas discharge tube
<electronic_eel>
some friends and family had their vdsl modems killed by lightning
<electronic_eel>
so I'm currently developing a protection device for that
<electronic_eel>
got it working in a way that it doesn't affect the vdsl signal
<electronic_eel>
even 250mbit/s works without problems
<electronic_eel>
I just don't have the proper equipment to test lightning surges
maartenBE has quit [Ping timeout: 264 seconds]
maartenBE has joined #scopehal
<electronic_eel>
azonenberg: had an idea: how about breaking out at least one (if not all) of the unused dac output channels to smas
<electronic_eel>
this could come in handy for testing Degis time to digital circuit
<electronic_eel>
smas because of shielding and keeping it low noise
<azonenberg>
ok so... awake now lol
<azonenberg>
the LCD in question is almost 1U high including bezel. You can't mount anything above/below it
<azonenberg>
There will be refclk in/out and trigger out on the back, yes. Everything is going to be fed into a PLL
<azonenberg>
The low cost option is to use an artix7 FPGA PLL, but i'd get much less jitter with an external PLL. The BFS will use an LMK04806 and i may use that on the lower end scopes even if 123 fs RMS jitter is overkill, just for commonality of design
<azonenberg>
as far as QTH stuff goes, I would be more inclined to use a QTH-030 or QTH-060. The -DP are a unique part that's very hard to find and costs more, the regular parts work just as well if you put grounds between the signal pairs
<azonenberg>
Secondary trigger in on the back for cable convenience would work nicely
<azonenberg>
i have no problem breaking out one of the dac outputs but unsure how it would help test a TDC?
<azonenberg>
as far as logic analyzer stuff goes, that is very much something i was interested in but i havent gone far enough to figure out the exact design yet. It won't use the AFE, it will just be a slow cheap dac plus a bank of comparators
<azonenberg>
scopehal already supports connection to multiple instruments if you want to do multi-scope setups. So far you have to set up external trigger, calibrate out trigger delay, etc manually
<azonenberg>
but eventually there will be a wizard where you touch one probe from each scope to a common reference point with a clock, fast edge, etc on it
<azonenberg>
and scopehal will do the rest
<sorear>
What goes on the LCD?
<azonenberg>
DHCP/IP configuration info
<azonenberg>
if you touch the screen it'll turn on and show the current ip, plus let you jump into a menu to select static or dhcp
<azonenberg>
after a minute or so of disuse it will shut down
<azonenberg>
won't be used during normal operation, it's just a more noob friendly alternative to a cisco-style rs232 port for initial setup before you get it on the lan
<azonenberg>
i may still provide a serial port to aid in factory test or something, TBD
<electronic_eel>
about the dac output: when you want to test a TDC, you need to be able to set a reference point for the comparator to compare against. you need a dac for that
<azonenberg>
ah fair enough
<sorear>
no good way to just make it discoverable by serial number over the network?
<azonenberg>
sorear: by default it will DHCP and there will be some kind of discovry protocol
<azonenberg>
but what if your network only has static IPs and no dhcp server?
<azonenberg>
there needs to be a fallback for manual config even if it's not used often
<azonenberg>
electronic_eel: yeah i have no problem with pinning out an unused channel or two
<sorear>
is that a reasonable case to support?
<azonenberg>
sorear: my SCADA network at home has no DHCP, so static ip support is mandatory for it to even work in my test environment
<azonenberg>
DHCP is the part i'm doing for other people's convenience :p
<electronic_eel>
I'm not fully convinced that the lcd+touch with all the space, frontpanel hole and so on is worth the trouble
<electronic_eel>
how about a usb with a ftdi chip (or similar) on it to reach a simple cli?
<azonenberg>
electronic_eel: a serial port is always an option if we're super space constrained. i just think that a nice graphical menu would be a modern, user friendly option
<azonenberg>
i'm not going to make the final decision until we know how big the adc+afe card is
<azonenberg>
it will be as big as it is, and we'll see how much panel space we have left over
<azonenberg>
But i'm setting design targets assuming we have the lcd
<electronic_eel>
if I'd have to decide between MSO / digital channels and lcd...
<azonenberg>
MSO can be in a second row above the SMAs if needed
<azonenberg>
i'm not worried about it taking up too much space
<electronic_eel>
wouldn't the usb-c's for the smart probes be in the 2nd row above/below the smas?
<azonenberg>
heck, we could have another usb-c port for mso if we want :p i was planning on having an active head with comparators converting to LVDS anyway
<azonenberg>
no i was thinking side by side
<azonenberg>
sma is edge launch and the AFE area has space to the right of the sma in the current layout
<azonenberg>
could easily fit a usb-c and a tiny bottom-side qfn mcu
<azonenberg>
plus a few fets for switching the power
<electronic_eel>
ok, we'll have to see if that is enough space there
<azonenberg>
this avoids the need to run cables to a second row of stuff
<azonenberg>
anyway i was planning on having the lcd be a standard feature for all of my hardware
<azonenberg>
a reusable component i could just drop in and have IP config happen magically with no new per-project code
<azonenberg>
the clock distribution system was the original platform i picked it out for
<azonenberg>
but i realized it would be super convenient for a scope too
<azonenberg>
anyway like i said its a non-issue for the characterization board
<azonenberg>
So we'll figure this out later. I'd just rather design with a pessimistic estimate of space and expand if needed, rather than do a nice spacious layout and realize the lcd wont fit but we want it
<azonenberg>
electronic_eel: btw regarding the probe mode for usb-c ports
<azonenberg>
thoughts on using the standard usb-c alternate mode negotiation?
<azonenberg>
apparently you can define proprietary modes, and this would allow an actually standards compliant implementation if we want
<Degi>
azonenberg: You can find -DP parts on digikey I found
<azonenberg>
degi: both genders? as standard stocking parts?
<electronic_eel>
I don't know if the wires usually used for alternate mode are thick enough, so I though paralleling several wires (like the ss lines)
<Degi>
Oh
<Degi>
Whats the other mating part called=
<azonenberg>
electronic_eel: no i meant using the SS lines for power still
<Degi>
Hm I guess the not D parts are enough for the data rates were dealing with
<azonenberg>
but using alternate mode to negotiate isntead of the PD
<azonenberg>
Degi: yes, and more importantly they give us more single ended IOs
<azonenberg>
electronic_eel: instead of the usb2 i mean*
<electronic_eel>
I think I have to read up on the alternate mode stuff first
<azonenberg>
negotiating via the alt mode channel
<azonenberg>
it uses the PD signaling if memory serves me right which is ugly, but i think you can buy asics that do it for you
<Degi>
Ah yes 60 vs 20
<electronic_eel>
but the solution with usb2 is completely easy to do, just pick a mcu with usb support, like stm32f042 in 4x4 qfn
<azonenberg>
degi: QTH mates with QSH
<electronic_eel>
pd signaling is more complex
<azonenberg>
My thought right now is TX1/TX2 = +7V, RX1/RX2 = -7V so the power pinout remains symmetric
<azonenberg>
then usb2 signaling over D+/D-
<azonenberg>
actually, for that matter
<azonenberg>
we could use the SBU pins as I2C :p
<azonenberg>
then *only* use PD signaling over CC1/CC2 to enable alt mode. no usb mode at all
<Degi>
Hm is USB TX/RX capacitively coupled?
<azonenberg>
USB3 is, usb2 is DC coupled
<azonenberg>
But we would only enable power once we had negotiated our alt mode
<Degi>
I mean if we put 7 V on the TX RX that it doesnt damage ordinary USB devices if plugged in
<Degi>
Okay
<azonenberg>
so a) no chance of putting power into a normal usb device and more importantly b) the caps can survive 7V so it wont hurt them
<azonenberg>
lain: ping, you know more about usbc alt modes than me
<electronic_eel>
couldn't we also misuse cc and sbu for more paralleling of the voltage?
<electronic_eel>
I'm really concerned about voltage drop
<azonenberg>
electronic_eel: i would be more inclined to use a higher intermediate voltage if that is a concern, say 8V
<azonenberg>
or even 12 like lecroy does in probus
<electronic_eel>
we probably won't have really old-school opamps that need +-15v on the probes
<azonenberg>
or alternatively use usb pd to negotiate a high voltage on the power pins and then put a smps in the probe
<electronic_eel>
and if one really wants one, they'd need to use a stepup
<azonenberg>
this will allow drawing much less current
<electronic_eel>
so in the end the stuff on the probe would want +-6v like on the afe with a ldo in front
<electronic_eel>
the question is how much current is realistic for most probes?
<azonenberg>
Exactly. I dont have an answer yet
<Degi>
Probably what two of our diff op amps use?
<azonenberg>
degi: consider the case of a ~4 GHz active diff probe with gain and offset in hardware
<azonenberg>
that is probably the upper bound of what we'd ever want to do
<Degi>
Hm right
<azonenberg>
it would be pretty much a full AFE
<azonenberg>
electronic_eel: you can buy usb pd chips that allow configuration of user alt modes
<azonenberg>
TPS6598x for example
<azonenberg>
we wouldnt even need a mcu in that case
<electronic_eel>
yes, but you don't find anything like that for the scope side, you need to implement it yourself
<electronic_eel>
also you want some id thing on the probe
<azonenberg>
i2c eeprom with serial number
<azonenberg>
once you're in the alt mode
<azonenberg>
on the sbu pins
<electronic_eel>
hmm, with all that we are more usb compliant, but at the expense of a lot of work (=understanding all the pd spec and similar)
<azonenberg>
Yes
<azonenberg>
more importantly it would open the door to more advanced usb stuff in the future if the need arises
<electronic_eel>
the alternative with a simple usb capable mcu seems much easier to me
<azonenberg>
(consider the case of some of lecroy's high end LAs that connect to the scope via usb3)
<Degi>
I mean isnt there like PD controllers
<azonenberg>
There are
<Degi>
Hm actually dont USB cables have like a bunch of bandwidth and diff pairs, we could attach whole probes over that on higher end models
<azonenberg>
i wouldnt want to run analog signals over them necessarily. But a LA is doable
<Degi>
Whats LA?
<azonenberg>
logic analyzer
<azonenberg>
basically we'd put an fpga with serdes and a bunch of comparators in an external probe pod
<electronic_eel>
the usb3 la would need a dedicated ss capable port on the scope. so there is no problem doing the basic usb2 thing on the regular probe ports
<azonenberg>
well the other option is to have that be an alt mode
<electronic_eel>
yes, that would also be possible
<azonenberg>
use 2 ss pairs for data to scope, one for refclk to probe, one for trigger out from probe
<Degi>
Maybe we could use a SERDES as a logic analyzer
<azonenberg>
or trigger in, tbd
<azonenberg>
Degi: already ahead of you on that
<Degi>
Nice
<azonenberg>
i plan to build something similar to the lecroy hda125
<azonenberg>
i reverse engineered their architecture and want to build something based on that. tl;dr you use one serdes in a quad as a sync input to calibrate out the unknown phase between refclk and serdes word clock
<azonenberg>
then 3 as high speed oversampling inputs
<azonenberg>
xilinx serdes at least, unsure about lattice, allow you to turn off the CDR block and get constant phase on the input
<azonenberg>
presumably for exactly this purpos
<electronic_eel>
we don't block our way for future compatibility with the simple usb2 thing, but we don't need to invest lot's of time into learning all the stuff about pd
<electronic_eel>
and can get a basic interface out sooner
<electronic_eel>
on the first entry level scope
<azonenberg>
what i want to avoid is making high end probes not work on the basic scope
<azonenberg>
i want to define a unified futureproof interface
<azonenberg>
that can potentially be improved with firmware/bitstream updates
<azonenberg>
but won't require hardware changes
<electronic_eel>
the la things don't go into the regular analog channels of the scope, right?
<azonenberg>
No. The LA will be entirely a digital interface
<azonenberg>
but i want a control channel that will support all current and future active probes with no hardware mods
<electronic_eel>
yes, so you have dedicated ports for the la on the scope
<electronic_eel>
these ports are more traditional usb-c ports with ss used as ss and so on
<electronic_eel>
the ports on the analog channels won't need fast data capability, even for high end probes
<electronic_eel>
just power and slower data, like reading eeproms, setting some bias voltage and so on
<azonenberg>
Yes. So the altmode will be power on ss and i2c over sbu
<azonenberg>
that much is certain
<azonenberg>
the only uncertain part is if we use CC or usb2 data to negotiate that mode
<azonenberg>
the latter being easier potentially, but less standard
<electronic_eel>
it is fully standard, as you could plug a probe into your pc and talk to the mcu
<electronic_eel>
like for firmware updates and so on
<azonenberg>
Good point on that
<electronic_eel>
I would just implement a cdc-acm serial interface
<electronic_eel>
then you can talk to the probe
<electronic_eel>
you could have the scope forward the probe serial over tcp
<azonenberg>
i would still want to at least provision support for the pd signals on both ends
<azonenberg>
s.t. future firmware can support it
<electronic_eel>
you'd need a mcu with cc / pd capability on the probes then
<azonenberg>
Correct
<electronic_eel>
currently that really limits your options mcu wise
<azonenberg>
or just throw a pd controller asic footprint on there?
<electronic_eel>
for example stm32g0 have cc/pd, but no regular usb
<azonenberg>
we can always dnp
<electronic_eel>
the model with regular usb will come out end of this year
<azonenberg>
there will be a stm32 with cc/pd and usb?
<Degi>
We could stick that into the FPGA maybe
<electronic_eel>
yes, that is what I read. a bigger model of the stm32g0
<azonenberg>
might make sense to just hold off on doing an active probe until then. given all of the virus issues slowing things down that likely will be a non issue
<azonenberg>
as long as we provision the host to support both
<azonenberg>
we can call the port "reserved for future expansion" and release a new firmware later on
<azonenberg>
all that matters is that the host side hardware can do it
<Degi>
We could put some expansion connectors on the main PCB too
<electronic_eel>
yes, but that requires some pd capable phy for the fpga
<Degi>
Hmm do we have one usb port for each probe?
<electronic_eel>
I still don't get the advantage of using standard pd. the probes and scope hardware are made for each other. If in the future we want more power or probe controlled voltages, we could always do the signaling over our serial channel on usb2
<electronic_eel>
but pd complicates things and makes it more expensive
<Degi>
Hm I mean as long as we have a mechanism to detect that there is definitely a probe and then enable power afterwards, that should be fine. And that the port should not be damaged when connected to a USB PD compliant power supply maybe
<electronic_eel>
yes, exactly. but usb pd psus don't enable anything else than the 5v unless they used the complicated pd protocol to negotiate with the other side
<electronic_eel>
so I think if we use basic good engineering there should be no damage
<Degi>
Lol we could make it power able over USB PD and able to charge phones... haha.
<electronic_eel>
very important feature!
<electronic_eel>
4GS/s, 500 MHz, 2A charging
<Degi>
"And if you find no other use for it, you can use it as a 4 port USB hub"
<azonenberg>
lol
<lain>
azonenberg: tl;dr of the usb alt mode stuff you're considering?
<azonenberg>
lain: so tl;dr is that we need a data+power connection in parallel with the SMA cable for active probes
<azonenberg>
usb-c is a commonly available cable we can get COTS
<azonenberg>
my proposal is to not support normal usb at all, negotiate an alt mode in which the SS TX lines are +7V DC, SS RX are -7V DC, and SBU pins provide I2C for management
<azonenberg>
electronic_eel is pushing for the same power scheme, but enabled after negotiating via the usb2 data channel, and using the usb2 data lines for management
<azonenberg>
the latter being much easier to implement with off the shelf mcus, but less standard compliant
<lain>
hrm
<monochroma>
i would probably just send 8-12VDC down USB and generate the voltages on the probe itself
<lain>
I'm not sure how good power integrity will be using the data lines as power fwiw, but I'm guessing these are low current rails?
<azonenberg>
lain: that was why i also considered using actual PD to bump Vbus up to higher voltage and run an inverting buck-boost on the probe
<azonenberg>
electronic_eel was worried about smps noise on the probes and wanted to be able to run the probes with just LDOs
<electronic_eel>
we would use these voltages for low power. if a probe really needs higher power, it would have to include a converter and use the regular power rails
<azonenberg>
basically i want to avoid making design choices on the entry level scope that come back and bite us later on when we build more advanced accessories
<electronic_eel>
make the basic stuff easy and cheap to implement, but leave options open for more complicated stuff
<azonenberg>
and result in things that are incompatible or worse yet fry each other
* monochroma
wonders how bad the USB-C 3.1 cables would be for sending a differential analog signal ;)
<lain>
that would be interesting
* electronic_eel
plugs his active probes into his phone
<lain>
should be fine as long as you use alt mode properly
<monochroma>
should be fine if you follow the USB-C spec (the one that no one ever follows >.>)
<lain>
yeahhhh
<lain>
just don't plug it into a Nintendo Switch
<azonenberg>
lol oh?
<electronic_eel>
what is nintendo doing?
<azonenberg>
i remember hearing stories about switch PD being borked but cant remember specifics
<lain>
the Switch's PD is broken, and the AC adapter for the Switch is broken in a symmetrical way such that it cancels out
<electronic_eel>
hehe
<lain>
there were several bugs, some were fixed in firmware iirc, but one I don't think they *can* fix in fw, which is they have too much capacitance on the VBUS rail right at the port, it's supposed to be able to disconnect the bulk of its capacitance in a very very short time to meet usb spec, with any remaining charge dissipating in a short time as well
<lain>
soooo if you unplug the Switch from its dock or adapter, its usb-c port's VBUS pins will be sitting up at like 9V for ***a long time***
<lain>
and if you plug something into them that can't handle 9V
<lain>
pop.
<lain>
it was popping 5V-only chargers that didn't have overvolt protection on their outputs
<azonenberg>
wait, it doesn't drain that power ~instantaneously by consuming it?
<azonenberg>
i would have expected until VBUS dropped below 5V it would keep on eating power from the caps
<lain>
iirc it properly disconnects its input capacitance from the internal system, per spec
<lain>
but doesn't discharge it
<lain>
which is a spec violation
<azonenberg>
lol
<electronic_eel>
does the switch work as power supply in non-docked mode?
<lain>
electronic_eel: yes
<azonenberg>
i would have disconnected the caps from the port
<lain>
actually hm
<lain>
it might not
<azonenberg>
and left the caps feeding the internal logic
<lain>
azonenberg: some capacitance is often required to counteract cable inductance
<lain>
which can be significant when users find out that 12+ ft cables exist
<lain>
what's really fun is to look at the inductive kick a device can receive when disconnecting a usb cable that is consuming max current :D
<lain>
OVP everything.
<lain>
USB-IF has some documents about this
<electronic_eel>
a regular beefy tvs diode (SMBJxxA) should work well for this
<lain>
yeah
<electronic_eel>
I haven't tested this exact case, but use them often in my projects and haven't had a fault like this
<electronic_eel>
you can't use them on data lines of course, they have too much capacitance for that
<electronic_eel>
but we would just use the usb2 (or cc) lines for data, so could put such diodes on everything else
<azonenberg>
well that could be a concern if we used the data lines if our AF puts power on the ss data lines :p
<azonenberg>
but i guess we can diode them as they're not data for us
<electronic_eel>
yes, exactly
<electronic_eel>
there are smaller tvs diode arrays for data lines available
<electronic_eel>
if it is just usb2 or cc this is easy and cheap