<azonenberg>
also i think i bricked the MCU on the AFE board. Trying to figure out how to recover
<Degi>
Huh how does that happen
<azonenberg>
tl;dr firmware bug seems to have turned off SWD
<azonenberg>
the debug interface isn't dedicated pins
<azonenberg>
if you set the mode register wrong you can't use the debug port
<Degi>
oof
<azonenberg>
i SHOULD be able to hold it in reset and recover but for reasons not yet know that isnt worknig
<azonenberg>
maybe a problem in my debug setup
<azonenberg>
Worst case it's a cheap micro and i have more :P
<azonenberg>
ok for whatever reason openocd wasnt using the reset pin
<azonenberg>
by manually asserting SRST with a jumper, i recovered
<azonenberg>
It's alive again
<Degi>
lol
<_whitenotifier-3>
[GitHub] Speak like a human.
<Degi>
no
<_whitenotifier-3>
[stm32-cpp] azonenberg pushed 1 commit to master [+1/-0/±1] https://git.io/JfUSO
<_whitenotifier-3>
[stm32-cpp] azonenberg d4ebaff - Moved newlib stubs to their own file
<azonenberg>
ok that wokrs
<_whitenotifier-3>
[stm32-cpp] azonenberg pushed 1 commit to master [+4/-0/±3] https://git.io/JfUS3
<_whitenotifier-3>
[stm32-cpp] azonenberg 263fd00 - Continued initial implementation of RCC/UART
<azonenberg>
Kinda surprised such a library didn't exist
<azonenberg>
but from what i can see, your options for stm32 are the proprietary ST libs using their fancy gui etc, or libopencm3 which isn't permissively licensed
<electronic_eel>
azonenberg: another option would be ChibiOS HAL and OSAL, they are Apache licensed
<electronic_eel>
the RTOS parts of ChibiOS (RT and NIL) are GPL or commercial, but the HAL part (and the makefile system and so on) are free
<azonenberg>
Not C++ though, right?
<electronic_eel>
no, C
<azonenberg>
i feel like a proper OO peripheral driver library would be nice
<azonenberg>
So i think i'll keep on this path
<electronic_eel>
the next person would probably say that a proper library in rust would be nice...
<azonenberg>
it's something i'll use on other projects
<azonenberg>
electronic_eel: lol. I really want to like rust, but i can't
<electronic_eel>
make sure it doesn't suffer from the NIH syndrome, are a project of their own such libs
<azonenberg>
i want a memory-safe OO language that still allows proper low-level tasks while preventing silly mistakes
<electronic_eel>
the memory-safe part sounds like rust to me
<azonenberg>
rust is not OO, and the anti-race features (among other things) are a bit too strict for my liking
<azonenberg>
i tried it for a little while and felt like i was coding in a padded cell
<azonenberg>
I want to be able to create proper pointer-based data structures and be able to modify them from various parts of the code
<azonenberg>
while also being prevented from overrunning buffers, using freed memory, etc
<azonenberg>
basically, what i want is all the power of C++ with a little angel watching over my shoulder and saving me from bad pointers
<azonenberg>
C++ is a great language as long as you never make a mistake with memory management
<azonenberg>
So what i want is for those mistakes to be caught safely, without breaking the expressiveness of the language
<azonenberg>
A memory-safe language i can't get work in isn't going to do me any good
<electronic_eel>
bad pointers don't just come from overflows, but often from execution sequence, like unallocated mem or use-after-free
<azonenberg>
Yes
<azonenberg>
but i feel like that can be handled without the handicaps that come from rust
<azonenberg>
rather than having pointers just be integers, have them be objects that can only be created in certain ways, have free do refcounting, etc
<electronic_eel>
so to get real memory safety, you need some limitations or other means to check exec sequence
<azonenberg>
still allow pointer arithmetic, but bounds-check
<azonenberg>
i.e. p + 5 should either return a pointer to the object 5 elements after p if it exists, otherwise segfault/throw an exception
<azonenberg>
it should work just like C++ memory management until you mess up, then provide a safety net
<azonenberg>
use-after-free can be prevented by ensuring that all pointers are refcounted and "free" actually just unref's
<azonenberg>
so if a ref to that block still exists, it can't be truly freed
<electronic_eel>
no, not runtime. it should error on compile. otherwise you get the mess with testing all codepaths for this stuff again
<azonenberg>
how do you statically prove this without the level of absurdity that rust has?
<azonenberg>
if you throw a std::out_of_bounds exception when a bad pointer is accessed you can gracefully recover at any level of control flow that makes sense
<azonenberg>
no segfault, no corruption of state
<electronic_eel>
I think working with/around the borrow checker and getting errors at compile time is worth the effort against writing tons and tons of unit tests to get the runtime errors of refcounting and your safety-net
<azonenberg>
certainly a compile error makes sense if you can statically prove bounds are exceeded
<azonenberg>
but if uncertain, it makes more sense to have a runtime check rather than refusing certain data structures because you can't prove another thread doesn't do something bad
<azonenberg>
i don't see this as any different from input validation
<azonenberg>
you can't prove your input will always be valid at compile time
<azonenberg>
you need to sanity check it and gracefully recover at run time if given something that makes no sense
<electronic_eel>
sorry, interesting discussion, but unfortunately I have to go to work now
<azonenberg>
obviously crashing is bad, which my proposal prevents
<azonenberg>
Basically my view is statically error if you can prove something is unsafe, when in doubt catch errors at run time
<azonenberg>
Allowing unsafe memory accesses is bad, we both agree. I just think the default if you are unable to statically prove safety should be to allow it and error at run time rather than not allowing the code to compile
<azonenberg>
because otherwise you end up either having to solve the halting problem in the compiler, or severely limit allowed algorithms/data structures
hlzr has joined #scopehal
<azonenberg>
electronic_eel, degi: just found errata #5 on the AFE
<azonenberg>
LDAC and CS# on the DAC are swapped
<azonenberg>
the sch symbol has the right pins, i hooked them up backwards
<azonenberg>
good news is they're just GPIOs on the MCU so i can swap them in firmware trivially
<_whitenotifier-3>
[stm32-cpp] azonenberg pushed 3 commits to master [+3/-0/±6] https://git.io/JfUAZ
<_whitenotifier-3>
[stm32-cpp] azonenberg dc8c222 - Added CPU wrappers for interrupt enable/disable
<azonenberg>
Also, i hope i can fit the entire test firmware on this micro. The code is growing faster than I expected
<azonenberg>
I'm at 12 KB already out of 32 KB available flash
<agg>
azonenberg: i've just spent a lot of time doing fiddly spi on an f042 so it's all paged in to my head if you have any qs
<agg>
though i did it all in rust and think you're mischaracterising it somewhat, it's simple to make specific structures in memory and modify them from anywhere if you really want to do it, just that's how you get data races
<agg>
and I still end up with what looks a lot like an OO HAL design, albeit without inheritance (composition is better anyway :P)
<agg>
fwiw, the spi fifo is really useful for keeping the spi data flowing without interruption, but if you have a big block to transfer you should definitely use dma for it anyway
<Degi>
Does anybody know whether a zener diodes voltage decreases when its damaged?
balrog has quit [Ping timeout: 260 seconds]
balrog has joined #scopehal
elms has quit [Ping timeout: 245 seconds]
elms has joined #scopehal
<azonenberg>
agg: yeah i'm using it for setting dc offset on a channel
<azonenberg>
its not exactly a high bandwidth application
<azonenberg>
monochroma: ooooof
<azonenberg>
atof() on newlib, even with -Os, uses 15K of flash on a softfloat chip
<azonenberg>
Gonna have to write my own stripped down version like i did with printf
<sorear>
atof et al are _nasty_ to do in a standards-conformant way
<azonenberg>
yes
<azonenberg>
So i'm going to write my own restricted one that only handles %d.%d format
<azonenberg>
no scientific notation, no NaN, etc
<sorear>
because you need to cover everything from DBL_MIN to DBL_MAX with correct rounding
<agg>
just print the float as hex bits and render to decimal on a computer :p
<sorear>
%a :p
<azonenberg>
on the real system we'll have a cortex-m7 with FPU and a megabyte of flash
<azonenberg>
so i'll have no problems with using real newlib there
<azonenberg>
right now i need to fit in the test board micro
<sorear>
%d.%d doesn't help you if you still have to handle 100s of digits with correct rounding
<azonenberg>
sorear: this is for parsing a scpi command of the format C1:OFFS 3.141
<azonenberg>
There's a +/- 5V offset range into a 16-bit ADC so 0.15 mV per LSB
<azonenberg>
16-bit DAC*
<azonenberg>
as long as i can get my float parsing to less than that, errors are of no consequence
<azonenberg>
that's the nice thing about app-specific code, it doesnt have to comply with the full standard. only the subset of the standard that's relevant for this use case
<azonenberg>
also, i just ordered a SMA-to-2x-banana plug adapter on ebay lol
<azonenberg>
Will need it for hooking my DMM up to the aux dac port on the afe board
<Degi>
Hm yeah sending hexadecimal floating point would be okay i think
<Degi>
Or do people enter SCPI by hand
<azonenberg>
For debug/test i want it to be decimal able to be entered bty hand
<Degi>
Hm I mean you could theoretically just send raw DAC values
<azonenberg>
yes, but i'd really like to have dac nonlinearity/offset calibration stored in flash on the instrment
<Degi>
Hmm how would you calibrate for that anyways?
<Degi>
Test at a few points with a voltmeter?
<Degi>
Also each channel probably has a different offset
<azonenberg>
To start, test probably 10, 50, 90% scale
<azonenberg>
i expect there to be two primary errors: fixed offset of the internal 2.5V reference not being exactly 2.5V
<azonenberg>
and a DC bias on the output amplifier
<azonenberg>
nonlinearity correction would be a lot harder and require piecewise linear or even per-sample correction tables
<azonenberg>
and i suspect is overkill
<Degi>
Hm how much LSB error does it even have and hows the tempco and timeco of that anywasy
<Degi>
Maybe for the final device...
<Degi>
Apply known voltage X on the input, try to set to 0 V, measure DAC value needed for that and repeat till you get all 65k points
<sorear>
how are you going to get known voltages?
<Degi>
Something like a calibrated inverse voltmeter?
<Degi>
Or just hook up a voltmeter to a power supply and adjust the power supply till the known voltage is reacher
<Degi>
*d
<monochroma>
lol inverse voltmeter
<monochroma>
programmable power supply
<azonenberg>
sorear: I have a 5 3/4 digit DMM that is out at a cal lab now getting a nist traceable calibration
<Degi>
Yeah lol
<Degi>
A programmable power supply that should be calibrated (I think the good ones are?)
<azonenberg>
And a power supply with 1 mV resolution that, while overdue for cal, can be easily in-house cal'd with the meter
<sorear>
when are we predicting azonenberg will have a Josephson reference?
<azonenberg>
(I already ordered a bunch of big power resistors to do this)
<Degi>
Hm why the power resistors?
<Degi>
To test voltage under load?
<azonenberg>
To test accuracy of current readback
<azonenberg>
if the supply says it's putting out 2A, is it really 2.008A?
<Degi>
Hm yeah
<azonenberg>
So the idea is, set the supply to 1V with current limit as high as it will go
<Degi>
Huh till 1970 they didnt get below 1 ppm voltage uncertainty between standards laboratories
<azonenberg>
connect a resistor sized to get a 10% full scale load in series with a calibrated DMM
<azonenberg>
measure actual current (resistor tolerance is unimportant as you just want to get roughly 10%, the DMM is used as the standard for comparison)
<azonenberg>
then either adjust the PSU to show that number, or in my case just document the static offset and ensure it's within tolerance
<azonenberg>
(i dont have the service manual for this PSU so i don't know how to actually apply the cal, but a documented error i know and can refer to is good enough as long as it's not huge)
<azonenberg>
then repeat at 50% and 90% full scale
<azonenberg>
then measure no/light load voltage at 10/50/90% full scale
<azonenberg>
and maintain internal calibration records showing the date/time/environmental conditions/serial of the meter used as a transferring standard and the measured deltas
<Degi>
Hm it should be possible to make a josephson reference with a PVD device and a ~1 µm resolution photomasking device
<azonenberg>
i'm not going to be building my own standard references
<azonenberg>
i'll just use a traceably cal'd dmm
<Degi>
Hmm you could use that as an adjustable voltage source by changing the frequency...
<azonenberg>
(just got off the phone with the cal lab, meter is done and they're shipping it out to me today so i should have it tomorrow or weds)
<Degi>
Neat
<sorear>
how much will the calibration degrade in that time, and with shipping shocks?
<azonenberg>
sorear: at these levels of precision, shipping should be a non-issue. They recommend re-cal annually
<azonenberg>
Super high end stuff is powered 24/7 because a reboot can cause drift, when it needs to be re-cal'd you literally put it on a battery and hand carry it to NIST
<sorear>
brb leisurely stroll to maryland
<Degi>
Hm cant they just stick it on a vibration damped table and then drive by train or so
<azonenberg>
typically it's carry-on luggage in a pelican case of some sort
<azonenberg>
at least from what i've seen
<Degi>
Id be kinda worried about plane travel tbh
<azonenberg>
yeah i expect primarily ground transportation
<azonenberg>
to minimize pressure changes
<azonenberg>
but a plane ride might be safer than a 3000 mile drive/train trip from, say, california to NIST
<sorear>
I'm a little bit unsure about how traceability works with non-drifting/quantum systems
<Degi>
Hm you still need a precise frequency for the josephson thingie
<sorear>
how does calibration work if you own a cesium beam clock?
<azonenberg>
sorear: i think if you have something that can't be adjusted, you just compare it to a primary standard and document the delta
<sorear>
better example would be a rubidium clock
<sorear>
a rubidium clock's frequency does not define the second and has to be measured
<sorear>
but that measurement, once published, is theoretically applicable to _all_ rubidium clocks
<Degi>
I mean the quantum things shouldnt have any delta between eachother theoretically
<sorear>
they need to be compared with each other to rule out systematic errors
<Degi>
Yes
<azonenberg>
In case you guys are curious, btw, a nist traceable cal for my 5 3/4 digit DMM, plus shipping from the lab in Redmond to me, came out to $261
<Degi>
Thats pretty affordable
<azonenberg>
Yeah, although when you add it up across all of my equipment it will start to get pricey
<Degi>
Hm I guess scope cal is pricier?
<azonenberg>
They quoted $315 and $325 for my 1 and 2 GHz scopes
<Degi>
Neat
<azonenberg>
Next year i will have two DSOs, a VNA, two DMMs, and two PSU's up for cal though
<azonenberg>
Lol
<azonenberg>
oh and an active probe that's long overdue as well
<azonenberg>
at that point i will be pretty close to, if not over, the $2K minimum for on-site service
<Degi>
Inb4 lockdown
<azonenberg>
so even if i have to pay a bit extra in setup fees i'm thinking of arranging for them to send a technician out to my lab
<azonenberg>
just to avoid the hassle of shipping everything out
<monochroma>
a year from now azonenberg will have his own nist cald reference standards in house :P
<azonenberg>
lol
<azonenberg>
that sounds like overkill unless i need like 8+ significant digit measurements
<azonenberg>
at the moment, i do not :p
<Degi>
Hm is a low thermal scanner one with low thermal voltage?
<Degi>
Like a mux switch
<Degi>
Huh apparently the weston cell was used till 1990
<azonenberg>
OK so I now have Cn:OFFSet working
<azonenberg>
With a scale by 2 to reflect the 2x front end attenuation prior to the DAC (although we will eventually need to calibrate this, because the attenuator won't be exactly 2.000x)
<azonenberg>
Measuring against my other R&S DMM which does not have a currently valid traceable cal
<sorear>
absolute units, practical units, international units, conventional units
<sorear>
there are about as many volts as feet, it's wonderful
<azonenberg>
0 -> 160 μV
<azonenberg>
0.5 -> 0.49941 V
<azonenberg>
1 -> 0.99893 V
<azonenberg>
2: 1.99789 V
<Degi>
1 LSB is 1.5 mV?
<azonenberg>
16 bits into a +/- 2.5V span
<azonenberg>
so 76 μV/LSB roughly
<azonenberg>
-2 -> -1.99830 V
<azonenberg>
-1 -> -0.99933 V
<azonenberg>
2.5 (full scale) -> 2.49742 V
<azonenberg>
-2.5 (full scale) -> -2.49772 V
<azonenberg>
So this is consistent with a tiny gain error, i.e. the 2.5V internal reference on the DAC is around 3 mV low
<azonenberg>
(relative to my uncalibrated DMM, so these measurements are questionable in their own right)
<azonenberg>
let me see if the other dac channel is the same
<azonenberg>
oh that's not good, why are both channels updating?
<azonenberg>
i wonder if i have a reset bug or something, one of the dac channels had a funky value on it i didn't expect
<azonenberg>
Maybe i just wrote to it a while ago and forgot :p
<_whitenotifier-3>
[stm32-cpp] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JfT8H
<_whitenotifier-3>
[stm32-cpp] azonenberg 956ff9f - Moved ISR out of UART driver
<_whitenotifier-3>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±8] https://git.io/JfT8d
<_whitenotifier-3>
[starshipraider] azonenberg e3bc5e7 - Continued work on SCPI parsing, integrated LTC2664 driver for offset control
<azonenberg>
Anyway, at this point offset control is working. The actual AFE offset voltage is wrong though, because we have the 75R resistor there instead of the 100 nH inductor
<azonenberg>
We also have a new bug it seems?
<azonenberg>
When the board resets, channel 3's DAC bottoms out at -2.5V
<azonenberg>
no root cause yet, unsure if firmware or pcb bug
<azonenberg>
it's only channel 3 which is odd
<azonenberg>
because the power-on midspan control applies to all channels
<azonenberg>
Added some code to explicitly write all channels to 0 during startup which seems to solve it. It might still glitch low during powerup which is a bit unusual, but any in-range voltage on the dac won't break things so i'm not worried
<_whitenotifier-3>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JfT4T
<_whitenotifier-3>
[starshipraider] azonenberg 08ed05c - LTC2664: reset DAC and set all channels to 0 during startup
<azonenberg>
(the 100 uH inductors are ETA Weds)
<Degi>
Did you order some extra OP07s
<azonenberg>
No, i can throw those on the next order
<azonenberg>
i've been doing a digikey order every few days lately :p
<Degi>
How is digikey ordering costs like?
<Degi>
Like on mouser you gotta order above 50 € if you dont wanna throw almost half your money on shipment and packaging
<azonenberg>
shipping can be as little as $4.99 iirc for first class mail of a small package
<monochroma>
in country shipping ftw
_whitenotifier-3 has quit [Ping timeout: 260 seconds]
<azonenberg>
Oook so at this point, status on the AFE bringup
<azonenberg>
Protection circuit is not yet tested
<azonenberg>
relay driver not yet tested, but should be quick to do
<azonenberg>
VGA not tested
<azonenberg>
Output stage not tested
<azonenberg>
MCU is alive and well
<azonenberg>
DAC is alive and well, but we still have to test the inductor on the output
<Degi>
How is the mcu clocked
<azonenberg>
Internal 8 MHz RC osc PLL'd up to 48 MHz
<azonenberg>
precise clocking seemed kinda unnecessary for this
<Degi>
Can we clock it from the FPGA on later designs
<azonenberg>
Why? if we need stable timing we can use a crystal or something
<Degi>
Then everything can be phase locked to eachother
<azonenberg>
why would that matter? we're not doing hard realtime on the micro
<Degi>
idk
<azonenberg>
if anything, being on a separate clock seems better for power integrity
<Degi>
Less EMI you mean
<azonenberg>
so you have less stuff all switching at the same time and potentially triggering resonances etc
<Degi>
?
<Degi>
Hmh kinda
<electronic_eel>
I don't think we are gonna use some clock-tight protocol between the fpga and the mcu
<azonenberg>
Yeah. For now, it's literally going to be scpi over uart
<azonenberg>
from the fpga ip stack to the mcu
<electronic_eel>
something like uart, which does not depend on the clocks to be in exact sync, is much more likely
<azonenberg>
then if the mcu has to send config commands to the fpga it will probably be over spi, which supplies its own clock
<azonenberg>
this is going to be a pretty loosely coupled system with the mcu on the control plane and the fpga in the data plane
<azonenberg>
once you set things up there won't be waveform data or anything flowing between them constantly
<electronic_eel>
so the internal rc oscillator is ok as long as we don't push the uart over 115200
<Degi>
Hmh
<electronic_eel>
if we want more, we should add a crystal
<Degi>
No gigabaud
<azonenberg>
i intend to run the uart hotter, probably 3 Mbps or so, on the production system
<electronic_eel>
no gigabaud for degi today
<azonenberg>
but that will have an external oscillator
<Degi>
;(
<azonenberg>
there's no need for it to be the same clock source the FPGA has though
<azonenberg>
Probe shells are out for delivery expected any minute now
<electronic_eel>
how does the relay work on the afe board? is it always off until the mcu turns it on or did you see it switching on before?
<Degi>
Does it have a LED?
<electronic_eel>
no directly coupled led I think
<electronic_eel>
just the leds of the mcu
<azonenberg>
yeah but i can sense the enable line with the mcu
<azonenberg>
it's connected to a dff iirc which has an undefined power-on state
<azonenberg>
but i can make the mcu shut it off as soon as it powers up
<azonenberg>
Stencil for new probe is here
<azonenberg>
Probe shells are in
<azonenberg>
The acrylic photopolymer was expensive and actually doesnt feel that great in the hand
<azonenberg>
I like the feel of the MJF nylon, although i think i'm going to stick with the thicker material
<azonenberg>
the thinner one feels flimsy and i think is likely to break if handled carelessly
<azonenberg>
It fits the Tetris holder snugly and definitely isn't going to move around
<azonenberg>
almost too snug, but i don't feel like i'm really forcing it
<azonenberg>
the photopolymer slides in better since it's a smoother finish
<electronic_eel>
mjf nylon - is that what you had previously shown, the grey stuff with some filler in it?
<azonenberg>
Almost
<azonenberg>
Same process, but what i showed before had 40% glass bead infill
<azonenberg>
that has a thicker minimum dimension and wouldn't work with this part
<azonenberg>
so i switched to the same nylon but in a darker, more black color without any infill
<electronic_eel>
you say you want to stick with the thicker material, probably meaning the one with the infill
<azonenberg>
No
<azonenberg>
Minimum wall thickness for the glass filled nylon is 0.75 mm
<azonenberg>
Minimum for unfilled is 0.4 mm
<Degi>
Hm cant we just have a thin case and then fill the probe with some RF epoxy or something
<azonenberg>
the thinnest parts of the new shell are around 0.6 mm
<azonenberg>
I have two versions of the probe, one necks down a bit towards the tip which i felt seemed a bit flimy and one that did not which feels more solid
<azonenberg>
i made the un-necked and necked in MJF nylon with no glass filler, and the un-necked in acrylic photopolymer
<azonenberg>
un-necked nylon is what i plan to stick with
<azonenberg>
Glass fill is not possible because the section that fits into the probe holder cannot be more than about 0.6mm thick
<azonenberg>
we'd need a custom holder if we needed more height there
<azonenberg>
i already had to use the tetris holder and not the normal pmk passive probe holder
<electronic_eel>
nylon tends to flex a bit, I think the filler will usually compensate that a bit, so I'd prefer the filled one if it would fit. but won't work in this design of course
<azonenberg>
Yeah
<azonenberg>
The thicker version of the probe has no perceptible flex when i put a fair bit of force on it
<azonenberg>
it's study
<azonenberg>
the thinner one i made just to see what would happen pushing close to the shapeways design minimums
<azonenberg>
unsurprisingly, it survived the printing process but felt like it would not survive normal use
<Degi>
Hm if we found some RF epoxy, we could just cast a hull on the probe with a mold
<Degi>
(and corrected the PCB for changer e_r)
<electronic_eel>
Degi: I don't think an epoxy is as consistent as air, there are always some air bubbles, inconsistent mixing and so on
<electronic_eel>
there is a reason that rogers isn't made out of epoxy
<azonenberg>
Yeah the whole reason i designed the probe shell like this is so the coplanar waveguide is floating in air on the top
<Degi>
Hm you can prevent air bubbles with vacuuming it before and after (and during at best) pouring, though epoxy is probably bad for RF
<azonenberg>
the enclosure is far enough away to not have significant impacts on performance
<electronic_eel>
even with vacuuming you'll still have microscopic air bubbles
<Degi>
Hmh even if the vacuum is below the vapor pressure of the epoxy?