<azonenberg>
The offset circuit works, aside from the voltage droop caused by the 75R series resistor
<azonenberg>
The relay works as well, i haven't tested the overvoltage protection yet but i can command it on and off
<azonenberg>
and it switches as it should
<azonenberg>
There's what looks like about half a volt of offset error, most likely caused by the resistor, but if i set C1:OFFS -0.55 it nulls it out nicely and i get a good looking squarewave centered at zero
_whitenotifier-9 has joined #scopehal
<_whitenotifier-9>
[stm32-cpp] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JfTVr
<_whitenotifier-9>
[stm32-cpp] azonenberg 6745b0b - Added Get function to GPIO class
<_whitenotifier-9>
[starshipraider] azonenberg pushed 1 commit to master [+2/-0/±4] https://git.io/JfTVo
<_whitenotifier-9>
[starshipraider] azonenberg e1978c1 - Initial implementation of InputProtectionRelay. Can turn channels on/off and query overload status via SCPI.
<Degi>
Can you hear the resistor
<Degi>
And do you probe the outputs differentially?
<Degi>
*relay lol
<azonenberg>
I can hear the relay
<azonenberg>
and i'm probing the outputs single ended and subtracting in post
<azonenberg>
pink = test signal at SMA, yellow/blue = outputs from first stage offset amplifier. The ringing is mostly due to the long ground leads i suspect
<azonenberg>
using a spring ground on pink but the long clip on the others
<azonenberg>
amplitude being ~50% is expected because of the input attenuator
<azonenberg>
there is a known crash where backspacing in the scpi input will sometimes lead to a hard fault, i haven't tracked down the cause of that yet
<azonenberg>
i have bounds checking, or at least i'm supposed to
<Degi>
Ah yes you're probing the signal after the first amplifier
<azonenberg>
Yeah. and with a 75R series resistor on the DAC output
<azonenberg>
so there's some offset error because of that
<azonenberg>
(to keep it from oscillating)
<azonenberg>
once i fix that with a proper inductor i expect the error to almost disappear
<Degi>
Hm maybe in the final design we should think about what we wanna do about that, if just an inductor is sufficient or a second OP07... idk
<Degi>
The waveform on the scope looks pretty nice
<azonenberg>
Orange is the differential measurement
<azonenberg>
subtracting blue from yellow
<azonenberg>
Pink is the stimulus
<Degi>
So thats a 5 MHz square wave right
<azonenberg>
it's the "fast edge" output from my scope
<azonenberg>
not sure of frequency, i didnt bother to measure
<azonenberg>
i just needed a signal source and it was conveniently available
<azonenberg>
directly into the 50 ohm input, no probe
<Degi>
Hm yeah you can see that the LPF works, can you zoom in on the rising or falling edge?
<Degi>
Well it looks ike 5 MHz
<azonenberg>
I will in a bit
<azonenberg>
i do see some slowdowns on the edges which is to be expected
<azonenberg>
and a bit of noise and ringing, which at the moment i think is mostly my scope's fault / the long probe grounds
<Degi>
I mean the rising should be limited to a few nanosecs
<azonenberg>
i'll try to get a better measurement with a tetris and a short ground later on
<azonenberg>
this was meant more as a basic "is it alive" test
<Degi>
The probes oscillate differently, I guess different ground lead inductance heh
<azonenberg>
and to confirm the relay was even opening/closing
<azonenberg>
as well as to verify i had control of dc offset
<Degi>
Hm common mode voltage is 2.5 V right?
<azonenberg>
Which i do, although like i said there's a ~550 mV error at DC
<azonenberg>
because of the resistor making things go weird
<Degi>
Hm yes
<azonenberg>
Yes, there's a 2.5V common mode on the first stage amp output
<Degi>
Hm it looks like a few 10 mV above 2.5 V
<azonenberg>
A little bit of drift on that reference isn't really a huge deal
<Degi>
Hm idk yeah
<azonenberg>
Since it's differential
<azonenberg>
having the common mode a little high or low is fine
<Degi>
For the HMCAD it is, but I think that supplies its own reference anyways
<azonenberg>
a huge amount is a problem, because we'd clip too soon if the whole signal was a volt above or below where it should
<azonenberg>
but a few mV is a non issue
<Degi>
I think it gets nonlinear and stuff or so
<Degi>
Hm yeah below 50 mV should be ok enough even for the hmcad
<azonenberg>
for the HMCAD yeah. The test board supplies its own 0.9V reference which is pretty close
<azonenberg>
the final board will use the hmcad's reference output
<azonenberg>
so they'll be well matched
<azonenberg>
anyway i guess the next step is going to be firing up the gain stage
<Degi>
And then doing a VNA scan maybe
<Degi>
(You did verify the output VCM before sticking it to the HMCAD board right?)
<azonenberg>
Yes
<Degi>
Niec
<Degi>
*Nice
<azonenberg>
I'll be doing VNA tests once the picovna comes in
<Degi>
Generally nice work!
<azonenberg>
the xaVNA has a *lower* limit of 130 MHz
<azonenberg>
so for a DC to 100 MHz design it's as useful as a brick
<Degi>
Lol
<azonenberg>
Speaking of which, if anyone here is in the US (international shipping is annoying) and wants a cheap VNA...
<azonenberg>
as soon as the picovna comes in i'll be retiring the xavna
<azonenberg>
(expected to ship in a week so i'll probably have it in 1.5-2 weeks depedning on how slow fedex etc are)
<kc8apf>
I do not need more test gear. I do not need more test gear.
<azonenberg>
kc8apf: yes you do
<azonenberg>
Everyone always needs more test equipment
<kc8apf>
I mean yes. I did just buy a truck though
<azonenberg>
Well the xaVNA is only $285, and since it's used i'd be willing to let it go for a fair bit less
<azonenberg>
(also interesting apparently my model might work down to 35 MHz, so i might try it on the AFE later on if i finish bringup before the picovna comes in. Only first gen ones were limited to 140 MHz?)
<azonenberg>
Degi: when the picovna comes in, i want to see how good the SOLT's on the xaVNA cal kit actually are
<azonenberg>
also ooh vna shipped already?
<azonenberg>
eta friday
<azonenberg>
Starting work on the gain stage driver, but this might take a little while because i have to stop and assemble some boards for a customer
<azonenberg>
ok yeah i'm not getting any firmware dev done tonight
<azonenberg>
Found another bug in the AFE
<azonenberg>
ADL5205 datasheet says Vcm needs to be decoupled with 0.1 uF to ground
<azonenberg>
We don't have that
<azonenberg>
There's lots of easy spots to bodge a cap on there though
<azonenberg>
also, can anybody see any mention in the ADL5205 datasheet of how long to wait after powering up a channel before you can configure it / before the output is stable?
<azonenberg>
figure 39 seems to suggest the output starts being driven ~15 ns after powerup is asserted, but there's no mention of the spi interface timing. So I *think* i can begin configuring it immediately aftr power is turned on
<azonenberg>
to the channel
maartenBE has quit [Ping timeout: 256 seconds]
maartenBE has joined #scopehal
marcos has joined #scopehal
marcos is now known as Guest46170
Guest46170 has quit [Client Quit]
marcos_ has joined #scopehal
marcos_ has quit [Client Quit]
wbraun has quit [Ping timeout: 256 seconds]
wbraun has joined #scopehal
elms has quit [Ping timeout: 265 seconds]
wbraun has quit [Ping timeout: 252 seconds]
elms has joined #scopehal
wbraun has joined #scopehal
<azonenberg>
degi, electronic_eel: sooo
<azonenberg>
given that 2V5_REF is supposed to be decoupled at the ADL5205
<azonenberg>
but it also oscillates if we have C15 populated...
<azonenberg>
i wonder about just adding a resistor? we don't need *exactly* 2.5V common mode on the amp, and VCM has ~2.6K ohms input resistance
<azonenberg>
so say a 10 ohm resistor should lead to less than a 1% error
<azonenberg>
but on the real board we definitely should use a reference that is stable with capacitive loads
<azonenberg>
Like the LT6660
<Degi>
I think thats just the enable signal
<Degi>
Or more OP07
<Degi>
Or just a lowpass filter which shunts RF
<Degi>
But yes the LT6660 sounds usable too
<Degi>
Not sure if it really needs 0.1 µF, we could try without and you try to measure voltage on 2V5 for any RF with an active probe
<Degi>
xavna before sometime 2019 seems to be 140 MHz
<Degi>
How come VNAs and SDRs in the cheap price range have such a high lower bound anyways
<Degi>
Hm if you mean with "enabling a channel" that the enable pin goes on, I think that might just be an internal switch? You could maybe even configure gain before enable
<azonenberg>
Yeah thats the point, it's not specified
<azonenberg>
it says "power down"
<azonenberg>
they have separate chip selects
<azonenberg>
that leads me to believe it's two separate circuits that live on one die and share a few pins
<azonenberg>
so power down might literally power-gate half the die and lose all spi config state
<azonenberg>
or maybe it only shuts down the analog stuff
<azonenberg>
We don't know
<Degi>
Idk try it out
<Degi>
Try reading SPI while powered down
<azonenberg>
ok rework complete
<azonenberg>
we now have a 24R resistor between 2V5_REF and the ADL5205, and 100 nF on each Vcm pin
<azonenberg>
the MCP1501 seems to be stable under this config although it's of course not ideal
<Degi>
Hmm I wonder if you can use A5 as SDIo
<azonenberg>
lol
<azonenberg>
it would be funny if it turned out to literally be the same circuit mirrored
<Degi>
The left side of the chip has probably a circuit which isnt mirrored with a MUX for the mode pins
<azonenberg>
Yeah thats what i figured
<azonenberg>
its probably two copies of the same tile with a pad ring and a few other things added around it
<azonenberg>
100 uH inductors got here. Ahead of schedule actually i think
<electronic_eel>
hmm, that we didn't spot the cap loading problem of the MCP1501 beforehand really was an oversight
<electronic_eel>
but when looking at the prices, I'm not sure the LT6660 is the better solution
<electronic_eel>
MCP1501 + OP07 costs about a third of an LT6660
<electronic_eel>
and buffering a reference with an opamp is usually the better solution than a more powerful ref
<electronic_eel>
only downside is that the op07 takes some board space with it's huge SO-8 package
<azonenberg>
electronic_eel: want to maybe try and find an alternative to the op07 for this that's available in a small DFN or similar?
<azonenberg>
so we could do mcp1501 + ???
<azonenberg>
then i can bang up a quick 2-layer oshpark board to verify performance and stability
<Degi>
Yes just thought about that
<azonenberg>
Since i really want this circuit board proven before we do the final board
<azonenberg>
in fact i'd like to replace the op07 in the current afe but that's a lower priority
<Degi>
What are the requirements for the input OP amp? What was the lsb of the DAC? 150 µV?
<electronic_eel>
do we want it just for the ref or also to replace the op on the offset stage?
<azonenberg>
For buffering the MCP1501, we just want low offset and stability with a fair bit (say 0.5 - 1 uF total across the various endpoints) of capacitance
<azonenberg>
as a minimum right now we have three loads that each should have 0.1 uF or so
<azonenberg>
but in the final AFE we will have four ADL5205s so that means 0.8 uF of total decoupling assuming we have a shared reference for everything
<azonenberg>
plus a bit more in the front end amplifiers
<Degi>
Hm and we need +- 5 V (so total 10 V) supply range for the opamp right
<azonenberg>
Yes
<electronic_eel>
since the ref doesn't change, it is an advantage if the op is slow, as it will have a lower noise then
<azonenberg>
Yes
<Degi>
Wont we have 2 of ADL?
<azonenberg>
For the reference we want low bandwidth, low offset, and a small package
<azonenberg>
Degi: oh wait yeah we only have two since the other two are on another board with their own MCP1501
<Degi>
For the input offset voltage it should have somewhat high bandwidth
<azonenberg>
I'm fine with the op07 for th einput offset
<azonenberg>
but for the mcp1501 i want to go small
<electronic_eel>
we could use a small dual-opamp to power several ADL5205s
<azonenberg>
so mcp1501 forked off into a dual amp, each driving one adl5205?
<azonenberg>
what's the benefit of that, less capacitance on each driver?
<electronic_eel>
yes, less capacitance
<azonenberg>
Find an opamp you like and let's think about that
<electronic_eel>
but most opamps come in single/dual/quad options, so we could test it out with larger capacitance and go to dual if we need it
<Degi>
Hmm
<Degi>
We should buffer the output from the DAC
<azonenberg>
yeah that would help
<azonenberg>
i'm almost wondering if we should just respin this whole afe board before going to the quad board?
<Degi>
Something that can source 30 mA or so... idk I need to calculate this more preciseli
<azonenberg>
since it seems like we're gonna have a lot of changes
<electronic_eel>
the opa187 looks nice spec-wise, but is quite a bit more expensive at about 2 bucks
<Degi>
Oops
<Degi>
Looked it up at 3k apparently
<Degi>
Range from VIN_OFFSET is +-5 V?
<azonenberg>
VIN_OFFSET is +/- 2.5
<azonenberg>
since input is divided by 2 by that point
<Degi>
At the node VIN_OFFSET?
<electronic_eel>
azonenberg: you could also build small bodge-boards that you solder onto the afe board. I do it like that sometimes if there aren't too may changes.
<Degi>
Ah yes the power divider is before
<electronic_eel>
I usually use my 1.27mm pitch protoboard for that, so I don't have to wait for pcbs to arrive
<electronic_eel>
but it takes time to solder and bodge, so it isn't time efficient for too many changes
<azonenberg>
well its more that we have a lot of small changes
<azonenberg>
and i'm worried about something getting missed
<electronic_eel>
hmm, but the world will not stop turning if we need a 2nd revision of the 4ch afe board
<azonenberg>
No, but it will cost a lot more to redo
<azonenberg>
idk, we'll decide once we've found all of the bugs in this one
<azonenberg>
which i dont think we have yet :p
<electronic_eel>
will you butcher the current afe board for parts or take new ones?
<azonenberg>
I don't like pulling analog parts. Too much chance of adding drift by overheating from too many thermal cycles etc
<azonenberg>
i dont even like pulling digital if i can avoid it
<electronic_eel>
then redoing the current afe board will also cost something, so I'm not sure it is worth it
<azonenberg>
True
<electronic_eel>
stuff like adding an opamp after the ref should be doable with a small bodge board
<electronic_eel>
also it will start looking like a true dev board, not so clean and perfect like it currently looks ;)
<Degi>
What is the maximum swing we'll see at VSHIFTED_P?
<Degi>
No, at the node before R30
<Degi>
Buffer at VIN_OFFSET should be able to do at least 15 mA
<electronic_eel>
really looks like the psu is a bit on the slow side
<Degi>
Maybe it has a biig capacitor
<azonenberg>
i mean there's probably some capacitance and inductance on the cables etc
<electronic_eel>
but a fuse usually needs like double or quadruple the rated amps to instantly blow
<Degi>
Lol I dont think that the cable capacitance and inductance matters for a fuse.
<Degi>
Unless its like an active fuse or so
<electronic_eel>
and a proper OCP circuit in the psu should be fast enough to switch off before
<azonenberg>
let me see if it specifies shutdown speed
<electronic_eel>
maybe they had some customers complain that the OCP triggered on inrush current, so they made it slower
<azonenberg>
actually no
<azonenberg>
the OCP on this psu routinely triggers on inrush if i don't have soft start enabled
<azonenberg>
Which i do
<azonenberg>
it's fairly fast
<azonenberg>
the PSU's OCP did blow, but so did the fuse
<azonenberg>
the PSU has support for 10ms - 10 sec of delay to prevent false triggers, i had it at zero
<electronic_eel>
hmm, does 0 delay mean 10ms ?
<azonenberg>
no 10ms is the first tick beyond 0
<electronic_eel>
the question is what 0 means for them...
<azonenberg>
Yeah :p
<azonenberg>
i havent scoped it shutting down
<azonenberg>
The fuse is rated for 200ms blow time @ 300% rated load
<azonenberg>
the psu should have shut off in << 200 ms so we easily got >3x the rated load
<Degi>
Lol once I connected my PC PSU to a broken mainboard and the mainboard catched on fire without hitting the OCP limit
<azonenberg>
actually according to the curve, a 1A fuse will blow in 10ms at 2.5A
<azonenberg>
and in 1ms at 4.5A
<azonenberg>
My guess is there's a small capacitor on the psu output
<azonenberg>
and we blew off the cap after the supply itself had shut down
<Degi>
Hm I think the op amp electronic_eel linked should be sufficient, though it has a somewhat high offset (more than a LSB) but not sure if that matters at all
<electronic_eel>
oh, pc psus are not well behaved on OCP, that is just a feature that is often half-assed
<azonenberg>
Anyway new fuse installed, board is set up agian
<Degi>
Well it had 74 A of OCP and the broken component was a bunch of VRMs
<electronic_eel>
Degi: the drift is more important I think, static offset can be cal'ed out
<Degi>
It says 5 µs with 25 nF, I guess it is stable with more C too?
<electronic_eel>
that is something we should try out, where the stabiltiy margin is and so on
<Degi>
It has flat phase till 2 MHz at 90 degrees and drops to 60 and below afterwards
<electronic_eel>
opamps often have better spice models, so we could try to spice it and have some hope that it matches reality
<azonenberg>
ok confirmed the ADL5205 can be turned on and off now via scpi command
<Degi>
It likely could be stable
<azonenberg>
and it is outputting an attenuated version of the input. Not sure what the adl5205 default gain is at powerup
<azonenberg>
ok reset results in the minimum gain code
<Degi>
What does RISO mean
<electronic_eel>
in context of cap stability?
<Degi>
Yeh
<azonenberg>
raster in slave out? :p
* azonenberg
hides
<Degi>
According to page 16 a small riso is bad
<Degi>
lol
<electronic_eel>
R to isolate the cap from the output I'd say
<azonenberg>
ok i have to do some stuff for $dayjob. back in a bit
<Degi>
Does a resistor parallel to the cap help prevent oscillations
<electronic_eel>
hmm, it would act as a static load
<azonenberg>
VIN_OFFSET is stable with the inductor btw
<electronic_eel>
cool, so the inductor solution worked as planned. but I still think buffering the dac with an opamp is the better solution
<Degi>
Hm yes maybe we can stick an inductor with low R (< 0.1 ohms, less than tolerance of the other resistors at least) after the OP amps too, with a rather small L, that the resonance freq is a bit lower than the GBP of the op amp
<electronic_eel>
Degi: do you want to try to spice that? I currently don't have the time
<Degi>
For that I would need to find an unstable op amp in spice first heh
<electronic_eel>
looks like ti has a pspice model for the OPA202
<electronic_eel>
you should be able to load that into ltspice
<electronic_eel>
you can increase the cap to insane values, it will begin to oscillate at some point
<electronic_eel>
then try to counter that
<electronic_eel>
in the end azonenberg will have to try it out on a small bodge board and try out how much margin we have
<azonenberg>
ok i kept poking at this just a little longer
<azonenberg>
set up a nicer tee so i could scope the input at the source without needing to have a probe near the 12V on the relay which was kinda precarious to begin with
<azonenberg>
At the output of the offset amplifier (left pad of R13 etc) i measure 185 mV p-p on a 339 mV input
<azonenberg>
which makes sense because i see a little bit of noise and ringing from the long probe grounds (not worried about that at this point)
<azonenberg>
but the actual peak looks about where it should
<electronic_eel>
how do you feed in the test signal? is that through your passive probe already?
<azonenberg>
No. fast edge output on my scope, 50 ohm sma right into the afe
<azonenberg>
trying to minimize variables right now
<azonenberg>
its a ~300 mv p-p squarewave with fast edges
<azonenberg>
anyway there is a slight offset error, mean of the input is -1.4 mV but mean of VGAIN_P - VGAIN_N is -29 mV
<azonenberg>
When i apply -60 mV of offset i null that out almost perfectly (again, doubling because VIN_OFFSET is applied after the attenuator so the dac voltage is scaled to compensate)
<azonenberg>
sorry i meant mean of VGAIN_P - VGAIN_N is +29 mV. I flipped the probes
<azonenberg>
When i apply -0.26V of offset i see 100 mV of offset on the output, which makes sense
<Degi>
Idk maybe check the offset specs of the components
<azonenberg>
So basically at this point i am happy with performance of the first amplifier. We'll have to calibrate out the offset error as well as dac gain error
<azonenberg>
But that shouldn't be a huge deal
<Degi>
I think we should keep the OP07 or better for the input, depending on how good the resistors are...
<Degi>
Can you measure the input voltage with no signal?
<Degi>
Like disconnect the input and probe the SMA
<Degi>
With voffset=0V and somethign else
<azonenberg>
One thing at a time. I'm focusing on basic bringup right now
<azonenberg>
only correcting fatal flaws
<azonenberg>
once i have the whole signal chain working, then we can start identifying sources of small errors and noise and correcting them
<azonenberg>
at this point it appears the ADL5205 is alive and can be turned on and off but we dont have any code to set the gain
<azonenberg>
so that will be the next step
<Degi>
We have up to 40 mV offset because of the RF amps
<Degi>
So the 29 mV is fine
<azonenberg>
more to the point, it's a dc offset we can fix with the dac
<azonenberg>
we just need to know the value
<electronic_eel>
nice thing is we have the relay at the input, so we can switch the input off and run a self-cal
<Degi>
Hmh yeah
<Degi>
(Also we should sometime check the difference between relay open voltage and input shorted to GND voltage)
<electronic_eel>
isn't there the termination after the relay? that should shunt pretty much any noise and small currents away
<Degi>
That way we would know how much the resistor and OP07 error is in reality
<electronic_eel>
wouldn't the VNA be the better test for this? it should directly show Z relative to freq
<azonenberg>
VNA will be here friday
<Degi>
I dont mean the Z I mean DC offset
<Degi>
VNA is good for finding out if the values are roughly correct
<azonenberg>
For DC offset yes, we can do a self cal of offset by opening it
<electronic_eel>
ok, testing that there is no dc voltage leaking out of the scope should be done too. but I think azonenberg does it the right order
<azonenberg>
First step is get the whole AFE end to end working
<azonenberg>
then start trying to cal and fine tune it
<azonenberg>
figure out what errors we have and how to eliminate them
<electronic_eel>
lol, there was a warning here not to drink hand sanitizer solution
<Degi>
???
<electronic_eel>
on some news site
<Degi>
Idk could be fun if its ethanol based
<Degi>
Why would you drink that tho lol
<electronic_eel>
will kill coronavirus inside you?
<Degi>
lol
<azonenberg>
lol well most sanitizers contain things besides ethanol that are... not suitable for human consumption :p
<Degi>
At unity gain the OPA202 doesnt seem to overshoot at >= 25 nF
<electronic_eel>
the ethanol in sanitizers is denaturated usually, don't think that is healthy
<Degi>
At 1 nF it just oscillates
<Degi>
At 0 nF the simulation progresses extremely slowly
<Degi>
Hand sanitizer challenge
<azonenberg>
electronic_eel: meanwhile, i disinfect my incoming mail/packages etc with fully food grade 140 proof ethanol
<azonenberg>
everclear diluted down to 70% v/v
<electronic_eel>
isn't non-denaturated ethanol expensive because of the taxes?
<azonenberg>
Somewhat so, yes. But e.g. IPA is impossible to find last time i checked
<Degi>
oof
<electronic_eel>
that is why I use isopropyl for all cleaning and desinfectin purposes
<azonenberg>
anything labeled "disinfectant" was sold out
<Degi>
Is all IPA sold for disinfecting tjo
<azonenberg>
and i had only a small amount of ACS reagent grade IPA that i wanted to keep for stuff where purity mattered
<azonenberg>
booze, on the other hand, was readily available
<azonenberg>
it was $20+ for a 750ml bottle, so not exactly cheap
<azonenberg>
but a bottle lasts me most of a month at the rate i've been going through it
<electronic_eel>
yeah, it is sold out. luckily I have the 5 l canister (which is about half full) from before corona
<Degi>
On german amazon theres IPA at leat
<Degi>
But for .com its sold out
<azonenberg>
electronic_eel: i normally stock 1-2 475 ml bottles of 99.8% ACS reagent / USP grade IPA in my lab
<azonenberg>
i try not to have huge volumes of flammable solvents for safety reasons, and my flammables cabinet has limited capacity
<azonenberg>
ditto for acetone
<Degi>
Huh you can buy chlorohexidine gluconate solution
<azonenberg>
right now i have only one bottle because i got rid of one that was starting to peroxide-ify
<azonenberg>
Degi: is that surprising?
<Degi>
Huh flammables cabinet...
<azonenberg>
electronic_eel: so i've been using food grade ethanol for disinfection because i have a ready source
<Degi>
I mean yeah for mouth cleansing but I didnt know that pure is available too
<azonenberg>
actually interesting to note my usual lab supplier has 3 bottles of IPA back
<azonenberg>
for $18.95
<electronic_eel>
yeah, if the IPA get's oldish, it can start to build peroxides
<Degi>
Hm interesting
<azonenberg>
i had one moderately old bottle that was approaching 100 ppm
<electronic_eel>
is there an easy way to test for peroxide concentration?
<Degi>
How do you measure that
<azonenberg>
but i had one really old bottle that i think had gotten forgotten before i moved out here
<azonenberg>
it pegged the test strip at >400 ppm and smelled funny
<Degi>
Does exposure to oxygen accelerate that?
<azonenberg>
i was... cautious... disposing of that
<Degi>
Lol
<azonenberg>
yes
<azonenberg>
worst case is a 90% empty bottle, frequently used a few drops at a time, with lots of air getting in and out of the headspace every time you open it
<azonenberg>
and slowly evaporating / being consumed over the course of years
<Degi>
Does ethanol do that too? I thought it was ethers or something that did that...
<azonenberg>
Which is exactly what i had
<Degi>
oof
<azonenberg>
I believe only secondary alcohols, not primary like ethanol
<azonenberg>
Ethers are far worse
<Degi>
I think the evaporating makes it worse lol
<azonenberg>
I'm not aware of any cases in which IPA has reached explosive levels during normal lab handling
<Degi>
Once I read a story about people finding an old bottle with a very big crystal inside
<azonenberg>
i.e. only when distilled is it likely to be hazardous
<azonenberg>
but i wasnt about to find out
<Degi>
Can it explode in solution?
<azonenberg>
Not sure, but micro crystals can form in threads of caps etc with ether
<azonenberg>
You can buy test strips that look just like pH strips
<azonenberg>
Which is what i use for this purpose
<azonenberg>
i label solvent bottles with date of opening and if any are more than a few months old i start testing them monthly
<Degi>
Hm can acetone do that with air?
<azonenberg>
i don't think acetone will form peroxides spontaneously, i think it needs a bit of a kick to form you-know-what
<azonenberg>
But i still test it to be safe
<Degi>
According to the link I posted, distillation can form diisopropyl ether which can form peroxides if vented once every 2 months
<azonenberg>
yeah i dont distill my IPA, i just clean stuff with it
<Degi>
Well somebody probably distilled it before you got it
<azonenberg>
but stock bottles sit around and get old because i only use maybe 100 μl or so at a time when de-fluxing boards
<Degi>
Hm yeah and constantly get new air
<electronic_eel>
I usually refill from the 5l canister to a pump spray bottle and use that to clean the boards. so I only open the canister seldomly
<azonenberg>
Same here
<azonenberg>
but the stock bottles also sit around for years
<azonenberg>
with the solvent in that bottle slowly reacting with the air in the headspace
<azonenberg>
this is also one of the reasons i've been using small stock bottles and not huge jugs
<azonenberg>
also the gain codes in the ADL5205 are... interesting
<azonenberg>
code zero is actually the highest gain
<azonenberg>
not the lowest
<electronic_eel>
maybe the implement it internally as always max gain first, then attenuate as programmed
<azonenberg>
the internal implementation is a 0-23 dB attenuator followed by a 14-26 dB VGA
<azonenberg>
AIUI max gain is no attenuation + max gain, then they dial the gain down, then when the gain hits minimum they start attenuating
<electronic_eel>
do you control them separately?
<azonenberg>
No
<azonenberg>
there's a single six-bit code to specify the 35 possible gain values
<azonenberg>
electronic_eel, degi: so for the SCPI commands to the AFE
<azonenberg>
right now offset is in un-attenuated volts (i.e. actual dac voltage is half what you ask for, plus any calibration scaling we might do later)
<Degi>
Hm is any onboard flash planned for calibration storage?
<azonenberg>
The MCU can self-write its flash
<azonenberg>
So i'll probably use the last sector or two of flash for cal data in the final system. Although in the prototype AFE i'm not sure i've got enough flash for that
<azonenberg>
so i will probably hard code the cal coefficients for my board
<Degi>
It kinda depends on how the cal is done tbh
<Degi>
Like if we cal for each point of the DAC with each setting of the VGA thats a megabyte or so
<azonenberg>
well i mean more like, i've got 32 KB of flash
<azonenberg>
And i'm using ~half of that now, and i still have a fair bit more functionality to add
<azonenberg>
the flash is, iirc, 4KB sectors
<azonenberg>
if i need more than 28KB for code i cannot use a sector for cal data :p
<Degi>
Welp
<azonenberg>
To start, the cal data will be fairly simple. I'm thinking a float for frontend offset and a float for DAC reference error
<azonenberg>
then something for gain once we get there
<azonenberg>
aaaaanyway, going back to my original question
<azonenberg>
The native gain units of the front end are integer dB
<azonenberg>
We do not currently have any fine gain control
<Degi>
Hm the problem is the offset of the input amplifier and the VGA is changed by the VGA
<azonenberg>
I expect we'll have to cal offset for each VGA setting
<azonenberg>
as well as store the actual gain of the VGA somewhere
<azonenberg>
and use that to scale sample data somehow
<azonenberg>
anyway so my question was, should the scpi commands set gain in dB"?
<azonenberg>
dB? *
<azonenberg>
or should we specify with something more like full-scale voltage range, and have it pick the closest dB value internally?
<azonenberg>
"full scale range" is iirc the scopehal native unit
<azonenberg>
Basically, how much of the conversion from scopehal API to native hardware units do we want to do in firmware vs host side on the driver?
<Degi>
That depends on how low level it is gonna be
<Degi>
Because with FSR we could adjust the HMCAD gain too
<Degi>
Hmm tbh I'd leave that to the drivers but could be done in FW too
<azonenberg>
hmm yes, fine gain in the ADC might help to correct for fractions-of-a-dB gain error
<azonenberg>
we'll have to play with that once we get the whole signal chain working i think
<Degi>
I think for now we can have raw ADC setting?
<Degi>
Is it much work to change later?
<Degi>
*raw VGA setting
<azonenberg>
Not yet
<azonenberg>
yes raw vga settings will certainly be the initial interface
<Degi>
Tbh I'd try to get a minimum interface working with raw interfacing cause we wanna test stuff
<azonenberg>
Exactly
<azonenberg>
My priority all along has been getting a minimum working scopehal driver up
<Degi>
I think raw value makes most sense then
<azonenberg>
OK setting gain appears to work now
<azonenberg>
there's a bit of ringing or oscillation on the output that i haven't tracked down the source of
<azonenberg>
not worried yet
<azonenberg>
trying to get full acquisition working first
<_whitenotifier-9>
[starshipraider] azonenberg pushed 1 commit to master [+2/-0/±3] https://git.io/JfklO