electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #scopehal
Degi has quit [Ping timeout: 260 seconds]
Degi has joined #scopehal
<azonenberg>
LeoBodnar: Hey, what are the specs on the 10 MHz output from your NTP server?
<azonenberg>
Sine or square wave? Does it act as a full GPSDO or is it not that stable?
<azonenberg>
And in PPS mode what's the voltage range, and what's the phase error/jitter from true second to pulse?
_whitelogger has joined #scopehal
_whitelogger has joined #scopehal
Ekho has quit [Ping timeout: 268 seconds]
Ekho has joined #scopehal
<LeoBodnar>
NTP server is not as good as GPSDO, it only has good long term stability. Good enough if you PPL it (like most ext reference instrumentation inputs do.) It has 10ns rms jitter in 1PPS mode
_whitelogger has joined #scopehal
bvernoux has joined #scopehal
juli966 has joined #scopehal
<azonenberg>
LeoBodnar: So what i'm thinking about doing is setting up an instrument where I use PPS from the NTP server plus 10 MHz from a GPSDO
<codysseus>
I ran into the issue where atkmmconfig.h is missing in atkmm/component.h and found this issue in gnome.
<azonenberg>
Interesting
<azonenberg>
If you install atkmm from source does it fix it?
<codysseus>
I haven't attempted that, but I will give that a try.
<codysseus>
That was more of a rabbit hole than I expected. I didn't end up installing atkmm from scratch, but now I am off on a walk. Are you able to recompile on your machine?
<azonenberg>
I'm able to build glscopeclient just fine on my debian boxes, but that's because I use the debian packaged atkmm versino
<azonenberg>
which is not the latest bleeding edge
<azonenberg>
as far as active cables go, is there a good way to detect that a cable is active?
<d1b2>
<david.lenfesty> I think so
<azonenberg>
My thought was to weakly pull SSTX P/N to a DC voltage
<d1b2>
<david.lenfesty> need to check the spec again but there's a process so you can decide whether or not to provide VCONN
<azonenberg>
then see if we see that on the probe
<azonenberg>
but it can probably be detected via the PD channel too
<azonenberg>
I guess the bigger question is, is this turning out to be too much work?
<azonenberg>
Should we consider something other than usb-c?
<azonenberg>
I am open to other options if you think that's the better choice
<d1b2>
<david.lenfesty> Idk what else to use.
<d1b2>
<david.lenfesty> Assuming a big driver is not making custom cables
<azonenberg>
Yes avoiding custom cables is a strong goal
<azonenberg>
micro HDMI is a potential option
<d1b2>
<david.lenfesty> I feel like that's even worse
<d1b2>
<david.lenfesty> Although we can directly detect active cables
<d1b2>
<david.lenfesty> and just ignore them
<azonenberg>
It provides I2C, 5V power, presence detect, then four diffpairs we could use for power
<azonenberg>
why do you say it's worse?
<azonenberg>
does hdmi do active cables too? and can you detect them?
<d1b2>
<david.lenfesty> I meant from a user perspective
<d1b2>
<david.lenfesty> although I guess plugging an HDMI port into your scope front-end is more suspect, so less likely to do something funky than with USB C
<azonenberg>
yeah
<azonenberg>
Thinking about other connector options... RJ45/RJ11 are huge
<azonenberg>
LEMO makes some nice stuff but it's $$$$
<d1b2>
<Hardkrash> How much power over the wires? Micro HDMI cables are in the 32AWG range.
<azonenberg>
Point of reference: the AKL-AD1 prototype uses the ADL5565, which has standby current of 80 mA, probably a little bit higher when switching
<d1b2>
<Hardkrash> HDMI does offer active cables, it’s what the 5V was meant for.
<azonenberg>
I thought the 5V is for powering the EDID eeprom
<d1b2>
<david.lenfesty> I think the advantage of HDMI active cables is they're marked as directional
<d1b2>
<david.lenfesty> so easier to spot than USB
<d1b2>
<Hardkrash> HDMI to $X dongles too.
<azonenberg>
Let me browse some of digikey's cable and connector inventory and see what else might be worth thinking about
<azonenberg>
Digikey stocks the base, the 10, and the 11
<azonenberg>
We need four addresses
<azonenberg>
So i guess let's just stick with the base one and have four buses
<azonenberg>
it's not the end of the world
<azonenberg>
although it does mean i'll need eight i2c channels on the system control MCU
<LeoBodnar>
azonenberg: dual port GPSDO outputs 1PPS on second output if you disable it
<azonenberg>
unless we add an i2c mux or something
<azonenberg>
LeoBodnar: oh, so it's possible to get 10 MHz + PPS from it?
<azonenberg>
Great
<LeoBodnar>
yeah
<LeoBodnar>
only on OUT2 though
<azonenberg>
That's convenient because i have my ntp server racked on the other side of the lab from where i'd need the frequency standard anyway
<azonenberg>
So i can just leave that on the LAN and keep it totally separate
<azonenberg>
david.lenfesty: but the stm32f777 has a max of 4 i2c interfaces
<azonenberg>
So... hmm
<d1b2>
<david.lenfesty> yeah we'll need a mux
<azonenberg>
Yeah i am not thrilled about needing one. i hate i2c muxes
<d1b2>
<david.lenfesty> or use a micro lower down as a mux
<azonenberg>
That might be a better option. having it be higher level
<d1b2>
<david.lenfesty> I was initially thinking of putting down another STM32 as a SPI peripheral
<agg>
if you don't need to use them simultaneously you could use two I2C1 pin assignments as two I2C buses
<agg>
and configure the GPIO mapping to disable one or the other
<azonenberg>
hide all of the PD complexity
<azonenberg>
and present an abstracted, higher level interface to the main mcu
<azonenberg>
via spi, another i2c bus, or whatever else we want
<agg>
at that point can you just use the stm32g0 on the host side instead of the fusb?
<azonenberg>
Let's step back for a little bit and think about what we actually need on the acquisition board
<agg>
could share a bunch of firmware with the probe g0 that way
<d1b2>
<david.lenfesty> yeah, but it's also cheaper to do an f0 w/ multiple fusb
<azonenberg>
So, on the BLONDEL frontend
<agg>
you can also get gpio-controlled i2c switches/muxes rather than an i2c-addressable-mux, which is a bit less hateful
<azonenberg>
We have five main subsystems
<azonenberg>
First is the input stage. This needs three GPIOs per channel (input reset, relay enable, and overload alert)
<azonenberg>
Second is the offset stage, which doesn't need any control directly
<azonenberg>
Then we have the gain stage. This uses the ADL5205 variable gain amplifier, which is a two channel device
<azonenberg>
It has a SPI device interface with a separate chip select for each channel, plus a power-up GPIO for each channel, and a chip wide "performance mode" strap
<azonenberg>
Then the common mode shift stage is a fixed gain block with no configuration
<azonenberg>
finally we have the four channel DAC which generates the offset voltages for all channels. This has a SPI device interface with a single chip select, and a reset GPIO
<azonenberg>
so in total for all four frontends we need 4*3 = 12 GPIOs for the input stages, a SPI channel plus 4*{CSN, powerup} plus 2{perfmode} for the gain stage, and a SPI channel plus {CSN, RST} for the DAC
<azonenberg>
This comes out to one channel of SPI and 24 GPIOs for the entire frontend, assuming we split out all of the resets and mode straps to be separate (probably best)
<azonenberg>
and assuming we use one spi bus for the gain stage and DAC (should be OK as we'll be clocking it pretty slowly, we can use low-slew drivers and not expect major SI issues)
<azonenberg>
Then we need a second SPI channel for talking to the main digital board
<azonenberg>
four channels of I2C, i guess, for talking to the PD PHYs
<azonenberg>
and four GPIOs for enabling power to each of the four probe ports
<azonenberg>
Addign that up we're now looking at two channels of SPI, four of I2C, and 28 GPIOs?
<azonenberg>
And probably a uart for debug console
<d1b2>
<david.lenfesty> And what does the main controller do exactly? It manages the frontends, does power bringup for the capturing FPGA and what else?
<azonenberg>
It will also run the SCPI interface
<azonenberg>
and the front panel config/status LCD
<azonenberg>
The FPGA datapath will handle waveform-to-LAN processing
<azonenberg>
but it won't be processing SCPI. there will be two sockets
<d1b2>
<david.lenfesty> oh and we'll need interrupt pins for each of the PD PHYs
<d1b2>
<david.lenfesty> "need"
<azonenberg>
so 32 GPIOs + 2x SPI + 4x I2C
<agg>
david.lenfesty: could you use one shared pin like smbus?
<azonenberg>
I'm thinking STM32F413ZGJ6
<d1b2>
<david.lenfesty> it is open drain
<azonenberg>
The "4x i2c" really drives you up to bigger MCU territory
<azonenberg>
But going to a smaller mcu plus an i2c mux will probably cost almost as much
<azonenberg>
and make software more complex
<d1b2>
<david.lenfesty> or just use an i2c mux
<d1b2>
<david.lenfesty> *instead of extra mcu + mux
<azonenberg>
We need a mcu on the frontend board anyway. there's too many things to twiddle and buses to interface with
<azonenberg>
we'd need a massive number of gpios on the connector to the digital board otherwise
<azonenberg>
or a big i2c io expander, etc
<azonenberg>
i feel like pushing some intelligence to the frontend board will simplify things a lot
<azonenberg>
It will also make it simpler to split up responsibilities when it comes to writing firmware
<d1b2>
<david.lenfesty> Yeah I think we can also get away with not using an I2C mux and just relying on alternate mode support
<azonenberg>
I mean we could cut the i2c requirement in half if we wanted
<d1b2>
<david.lenfesty> then we only need two I2C peripherals on that MCU which opens things up a lot
<azonenberg>
by using two on one address and two on the other
<d1b2>
<david.lenfesty> that too
<azonenberg>
digikey has three of the four address options in stock
<azonenberg>
So, supposing we do that
<azonenberg>
32 GPIO + 2x SPI + 2x I2C
<azonenberg>
And a uart
<d1b2>
<david.lenfesty> and you wouldn't mind doing LQFP100?
<azonenberg>
Say STM32F103 in LFBGA100 package... USART2, SPI1, SPI2, I2C1, I2C2 can all be used simultaneously with no pin conflicts
<agg>
f103 is 12 years old at this point and the GPIO is quite annoying, it's probably cheaper and easier to use something a bit more modern
<azonenberg>
Ok let's see what else we can do then
<agg>
for simple i2c/uart/spi/gpio without doing any maths/processing you can get 100 pin f0s which will be cheap and have simple peripherals
<agg>
if you wanted more commonality with the probe there's also 64 pin g0 but might not quite be enough pins
<d1b2>
<david.lenfesty> yeah I was looking at the F071
<azonenberg>
STM32F091VB
<azonenberg>
just to get a bit more ram/flash in case we need it
<d1b2>
<david.lenfesty> ooooh out of stock
<d1b2>
<david.lenfesty> although we can just buy a VC chip until it gets back in
<azonenberg>
stm32f091vch6?
<azonenberg>
$5.75 @ digikey qty 1
<d1b2>
<david.lenfesty> I always forget how bad CAD -> USD is and am shocked at the price difference.
<d1b2>
<david.lenfesty> But yeah that sounds good
<azonenberg>
That's 0.5mm pitch which is a little annoying for hand assembly, i prefer 0.8
<azonenberg>
but LQFP100 is huge, and i *hate* QFP
<d1b2>
<david.lenfesty> Oh, BGA
<azonenberg>
It has a LQFP100 package option. We could prototype with that if you prefer
<agg>
nothing in F0 has better than 0.5 BGA AFAIK
<azonenberg>
then just re-layout the design in 0.5 bga
<d1b2>
<david.lenfesty> Currently I'm more comfortable with LQFP100 but that's just because I've never done BGA before
<agg>
BGA is great, you'll love it
<d1b2>
<david.lenfesty> I have a board with 0.8mm bga sitting next to me
<azonenberg>
agg: yes but 0.5 is a little fine pitch for a first timer
<d1b2>
<david.lenfesty> just working up the courage to solder it
<azonenberg>
0.8 or 1 mm is no biggie
<azonenberg>
i can do 0.5, i just dont enjoy it as much :p
<d1b2>
<david.lenfesty> and I've been doing LQFP for years w/o a hot air gun even so I'm fine with that
<agg>
mostly because 0.5 won't work with most cheap board houses
<agg>
but yea, 0.8mm bga is where it's at :p
<agg>
there are 0.8mm bga stm32f4 which are similarly priced iirc
<azonenberg>
let me look at those then
<agg>
slightly older peripheral set but not troublesome
<agg>
stm32f429 perhaps
<azonenberg>
It's an oscilloscope, the analog stuff uses so much power a slightly leaky MCU is of no consequence
<azonenberg>
to say nothing of the fpga
<azonenberg>
They have 0.8mm BGA but only in the TFBGA216 package
<azonenberg>
which is... overkill
<agg>
yea that is a bit extreme
<azonenberg>
I'm using that for the F777 on the digital board
<azonenberg>
but for the frontend it's overkill for sure
<azonenberg>
And back to STM32F103ZD which has a 100 ball 0.8mm LFBGA package
<agg>
looks like your choices for 64 or 100 pin 0.8mm BGA is F1, F7, H7, L0, and G4
<agg>
G4 might be compelling but it's somewhat newer
<agg>
eg stm32g473vc
<azonenberg>
Wait no not ZD, VD is the 100 pin
<d1b2>
<david.lenfesty> I don't mind dealing with the f103's janky GPIO stuff
<d1b2>
<david.lenfesty> I have a recent f107 project
<azonenberg>
from a quick skim of the package tables it appears both spi and i2c and at least one uart can be used without pin conflicts
<agg>
the i2c peripheral on the f1 is kinda janky too but it should work
<azonenberg>
you have a total of 80 GPIOs in the 100 pin package, which should be more than enough
<agg>
shame there's not much more modern in a sensible package until you get to F7/H7 which is probably pricier and more complex than needed for this
<azonenberg>
Yes. I'm tentatively using a F7 on the digital board next to the FPGA
<azonenberg>
the main thing i wanted horsepower for was running the GUI on the front panel LCD
<azonenberg>
for setting IP address etc
<azonenberg>
honestly i could probably get away with a f4 for that
<agg>
it might be worth at least looking at the H7 options, a lot are pin compatible but get you a lot more CPU and RAM for the same price (smaller process node)
<agg>
sometimes cheaper too
<d1b2>
<david.lenfesty> still sad about no FPGA project but I'll be saving a lot of money in capacitors at least
<azonenberg>
lol
<d1b2>
<j4cbo> the f7/h7 "value line" parts (64k flash) are pretty cheap
<azonenberg>
j4cbo: we're talking about an auxiliary processor for the acquisition board though, i feel like a m7 is massive overkill
<d1b2>
<j4cbo> for sure, but if it has the right i/o...
<azonenberg>
I guess the real question is, is there any reason we'd need more than 64 KB flash, 20 KB RAM, and a 72 MHz M3 for controlling a bunch of low speed peripherals (basically only doing something when you twiddle channel gain/offset)?
<azonenberg>
I don't think so
<azonenberg>
it's cheap, it has the IOs
<d1b2>
<Hardkrash> is this board the one with the PD connection?
<azonenberg>
hardkrash: So the overall architecture of BLONDEL is going to be three different boards
<azonenberg>
There's the digital board with an FPGA, probably a stm32f7, RAM, and Ethernet
<azonenberg>
then there's two identical analog boards, one of which can be DNP'd to reduce system cost
<azonenberg>
each one will have a HMCAD1520 ADC, four identical frontends, and four channels worth of this PD stuff
<d1b2>
<TiltMeSenpai> oh no looks like there was a change of plan and a lot of context lol
<d1b2>
<david.lenfesty> not suuuper much for your side
<d1b2>
<david.lenfesty> People were recommending PD vs. UART over SBU
<azonenberg>
hardkrash: The early prototype of the frontend used a stm32f031
<d1b2>
<david.lenfesty> and we need PD to detect active cables
<d1b2>
<TiltMeSenpai> maybe this makes my life easier? Routing both SBU pins was actually sort of awkward
<d1b2>
<david.lenfesty> aaand an STM32G071 has a PD transceiver built in
<azonenberg>
but that was for one frontend with no active probe interface
<d1b2>
<TiltMeSenpai> will an active cable complain about the +/-7v on the SS pins?
<azonenberg>
What we're proposing is merging four copies of that plus the probe control stuff into a single bigger mcu
<d1b2>
<david.lenfesty> yeah because there could be signal conditioners
<azonenberg>
well...
<d1b2>
<david.lenfesty> we need to reject active cables
<azonenberg>
they should be AC coupled
<d1b2>
<TiltMeSenpai> oh I see
<azonenberg>
so it probably won't *hurt* it
<azonenberg>
(probably
<azonenberg>
But it won't work
<d1b2>
<TiltMeSenpai> ok yeah, sounds good
<azonenberg>
safer to detect before turning power on
<d1b2>
<Hardkrash> Also most cables do not route SBU, as it is for alternate modes like type-c to DP cables.
<d1b2>
<david.lenfesty> yeah you can at least warn the user about it
<azonenberg>
Most cheap C-C cables are not active, right?
<d1b2>
<TiltMeSenpai> most cables aren't active I think
<d1b2>
<TiltMeSenpai> I don't know if I've ever seen an active cable personally
<azonenberg>
(i dont want to end up in a position where we can't find cables that do what we need)
<d1b2>
<Hardkrash> yes, but most C-C cables only route VBUS at 3A, USB 2.0, CC, and GND
<d1b2>
<TiltMeSenpai> hmm for the mcu for the gui, I wonder if we could use a raspberry pi cm4 compatible carrier board
<d1b2>
<david.lenfesty> Well we can at least specify USB 3.1 gen1 or whatever the hell the naming scheme is
<d1b2>
<TiltMeSenpai> that way if you wanted a more standalone unit, there would be an upgrade path (though the software would be a different matter)
<azonenberg>
No
<d1b2>
<TiltMeSenpai> lol fair
<azonenberg>
The display is a tiny little like 480x120 lcd
<d1b2>
<TiltMeSenpai> oh ok
<azonenberg>
it's just going to have a mode to enter the ip address basically
<azonenberg>
it's 1U by about 4" wide
<d1b2>
<TiltMeSenpai> yeah no that wouldn't be pleasant to work with
<azonenberg>
and it's parallel RGB24 not MIPI
<azonenberg>
hardkrash: your'e saying most c-c cables don't route SSTX/SSRX?
<d1b2>
<Hardkrash> As david.lenfesty said, need to specify a cable with a high enough spec.
<azonenberg>
Yeah we need a usb SS capable cable for sure
<azonenberg>
tiltmesenpai: re the LCD, there's not even any connection between waveform data and that mcu
<azonenberg>
The MCU's main job is to run the scpi control plane interface
<azonenberg>
the LCD is just a means of getting it on the network the first time
<d1b2>
<TiltMeSenpai> ah, ok
<agg>
hmm, A-C 3.0 cables are way cheaper than C-C 3.0 cables, at least here
<d1b2>
<Hardkrash> do you need all 4 lanes?
<azonenberg>
hardkrash: I was proposing both SSTX for one power rail and both SSRX for the other
<azonenberg>
four wires in parallel = more current handling capacity
<agg>
looking at $35 for c-c 3.0, vs $10 for a-c 3.0 and $8 for c-c 2.0
<azonenberg>
given that they're tiny wires
<agg>
probably just not finding the right cables though
<azonenberg>
A on the scope side is not completely implausible
<agg>
will you have 5v on vbus for people wanting to charge their phones while in the lab? :p
<azonenberg>
agg: There will be 5V on vbus because that's what the mcu runs on
<azonenberg>
that's the digital power rail
<azonenberg>
then sstx/ssrx will be the analog rails
<azonenberg>
the mcu will need to be powered up via vbus in order to negotiate the +/-7V
<agg>
found some cheaper c-c 3.0, so they do exist
<d1b2>
<TiltMeSenpai> does 3.0 type A have the cc lines?
<d1b2>
<daveshah> Nope
<azonenberg>
well, there goes that idea
<agg>
quite chunky cables for the conductors, but I guess there's a bunch of dielectric for all that micro coax/twinax
<azonenberg>
So i guess we're back to c-c
<azonenberg>
and it has to be ss capable
<agg>
oh, yea, USB PD over type A is a bit awful
<d1b2>
<Hardkrash> That specification was dropped. as it AC coupled the data onto VBUS
<azonenberg>
lol
<azonenberg>
oh THAT spec
<azonenberg>
i remember whitequark ranting about it a while back
<azonenberg>
Just ordered an updated rev of the MMCX input board for MEAD
<azonenberg>
the version i had before had some mechanical fit issues
<azonenberg>
and needed to be sanded/milled in order to work
<d1b2>
<david.lenfesty> azonenberg: would you mind me using libopencm3 vs. extending your library, or even Rust instead for the firmware?
<azonenberg>
libopencm3 is LGPLv3. Normally I'm ok with LGPL for libraries, but on a MCU normally the firmware ends up being statically linked
<azonenberg>
Which results in the entire firmware being copyleft, which is no bueno
<azonenberg>
My library was created in part for that reason
<azonenberg>
there was no good permissively licensed support library
<azonenberg>
As far as rust, I strongly prefer to keep everything OO. Rust looks like a great memory safe C replacement, i'm still waiting for a viable C++ replacement
<d1b2>
<j4cbo> what are D+/D- going to be used for?
<azonenberg>
At this time, nothing
<d1b2>
<j4cbo> the +/-7v enable could be done in-band over D+/D- used as regular USB, though that would require a host controller on the scope side
<d1b2>
<Hardkrash> I'm digging through the specs, and reading about the cables. 5A cables require e-markers, and they have super speed signal bits, in the passive cable VDO, The VDO is defined in Table 6-38 of the PD spec. Bits 12...11 are for detecting if the cable is active or passive. Bits 2...0 will give the USB highest speed support.
<azonenberg>
j4cbo: we discussed this a while back
bvernoux has quit [Read error: Connection reset by peer]
<azonenberg>
that was the original plan actually. usb 2.0 signaling and then running both probe data comms and the power enable over it
<azonenberg>
seems the consensus is that the PD channel is better for this
<d1b2>
<j4cbo> ah, gotcha 🙃
<d1b2>
<TiltMeSenpai> I also think USB would be tricky to maintain the whole "you can plug about anything in without anything unexpected happening" deal
<d1b2>
<TiltMeSenpai> not sure how I feel about PD still but it's better than trying to implement a whole USB host stack
<azonenberg>
Yeah
<azonenberg>
But that's why we're prototyping this in isolation
<azonenberg>
before we throw several hundred dollars of components on the board with the muc
<d1b2>
<david.lenfesty> Makes sense, although I do disagree that Rust isn't a viable C++ replacement (barring OO, which I have opinions about), keeping things consistent is preferable.
<azonenberg>
mcu*
<d1b2>
<david.lenfesty> also how do you handle differing peripherals in stm32-cpp?
<d1b2>
<david.lenfesty> I don't see a mechanism for e.g. the different IO types
<azonenberg>
I never got that far :P
<azonenberg>
i've only used it on the f031 so far i think?
<d1b2>
<david.lenfesty> that's all I see
<d1b2>
<david.lenfesty> a conversation for later
<azonenberg>
basically i looked around and saw the vendor libraries were awful, libopencm3 was copyleft, and there didn't seem to be anything else available
<d1b2>
<david.lenfesty> And as far as supporting USB PD, It doesn't look too complicated because we only have to implement the bare minimum of the spec
<d1b2>
<david.lenfesty> the ChibiOS HAL is pretty decent, it has funky licensing though
<d1b2>
<david.lenfesty> we can just say "nope we don't support more power profiles" and then just listen for our vendor messages
<d1b2>
<david.lenfesty> ah, it's apache 2.0
<d1b2>
<david.lenfesty> I don't mind expanding your library though either, I'd be implementing SPI, I2C, UART, and GPIO, which are pretty simple
<azonenberg>
Yeah I think expanding stm32-cpp is probably a good starting point. I was planning to use it as the core for all of this ecosystem
<d1b2>
<Hardkrash> I would at least use the support for cable discovery as active cables are required to state that they are active to get power.
<d1b2>
<david.lenfesty> yeah that's the plan.
<d1b2>
<david.lenfesty> I'll double check to make sure the cable isn't active
<d1b2>
<Hardkrash> might need to have the power switches for each of the data lanes, so that you can detect if the lanes are present.
<d1b2>
<david.lenfesty> we're putting that probe side. So the probe will report back if it doesn't get the power
<azonenberg>
Yeah there will be switches host side and then sensing probe side
<azonenberg>
to close the loop
<azonenberg>
If the probe reports no power after say 250ms of the host switching it on, the host will assume an incompatible or damaged cable, kill power, and report a fault back to the main processor
<azonenberg>
and maybe light up some kind of fault LED on the front panel
<azonenberg>
I'm thinking we will probably want polyfuses on the host side too?
<d1b2>
<david.lenfesty> I did one for VBUS but not for +-7V
<azonenberg>
yeah i'd suggest adding them there
<azonenberg>
If there's too much ESR we can just bump the voltage up more
<d1b2>
<david.lenfesty> ostensibly because I didn't know what the final power scheme would be but that doesn't make sense now that I have sleep
<azonenberg>
7V was a first guesstimate of how much we'd want
<d1b2>
<david.lenfesty> Is the same 500mA PTC fine?
<azonenberg>
Yeah that will work fine
<azonenberg>
basically i just want to avoid a shorted probe from damaging the scope
<azonenberg>
as far as 7V ultimately what we need is "enough for LDO headroom" on top of whatever vdd the probe amplifier needs
<azonenberg>
after voltage drop in the usb cable
<azonenberg>
Also later today I'm planning on filming a short demo video of glscopeclient with my waverunner and the borrowed mso64
<azonenberg>
i've tuned the mso6 driver as much as i can, it's not great but it kinda-sorta works
<azonenberg>
For the purposes of demonstrating multi scope sync, it will do