<Degi_>
You plaed R63 and the OP amp output is stable?
<Degi_>
Anyways you should rework some kinda rf short to ground decoupling into the path from DAC to first RF op amp, what C69 did but somehow that the DAC is stable
Degi has quit [Ping timeout: 256 seconds]
Degi_ is now known as Degi
<Degi>
(Did you get my last 2 messages? or did they get lost)
<monochroma>
17:18 -!- Degi_ [~Degi@x590eb765.dyn.telefonica.de] has joined #scopehal
<monochroma>
17:19 < Degi_> You plaed R63 and the OP amp output is stable?
<monochroma>
17:20 < Degi_> Anyways you should rework some kinda rf short to ground decoupling into the path from DAC to first RF op amp, what C69 did but somehow that the DAC is
<azonenberg>
ADC board assembled. The pin header on the right with the bodgewire is a UART header because i neglected to break out *any* GPIO from the FPGA except what the ADC needed
<Degi>
Lol is that the uart
<azonenberg>
yes
<monochroma>
oh yeah, did you have any photos of the relay rework?
<azonenberg>
It's done fairly professionally, the header is well secured to the board, bare wires on the short runs, insulated on the long ones, everything secured firmly
<azonenberg>
let me grab a pic of the relay in a bit
<azonenberg>
If we add a few ohms of resistance, i *think* that would break the feedback loop?
<azonenberg>
it would lead to loading effects on the dac output
<azonenberg>
but i think we could cal that out
<azonenberg>
Let's try 2 ohms
<azonenberg>
184 kHz with 2 ohm series resistance
<azonenberg>
this thing REALLY does not like capacitive loads
<azonenberg>
2 ohm esr is a lot
<Degi>
Is it for a op amp?
<azonenberg>
i mean for a cap
<Degi>
I think we should use a LC network or so for filtering with some big Ls at the beginning
<Degi>
Hm yeah
<azonenberg>
do you mean between dac and load?
<Degi>
yes
<azonenberg>
you want L there? that would certainly help
<Degi>
Or some op amp thats unity gain stable with capaitive loads
<Degi>
Or like a few hundred µH
<azonenberg>
Let me see what i've got
<azonenberg>
i have nothing even close to that
<azonenberg>
most i have is 2.2 uH
<azonenberg>
in 0402
<azonenberg>
Any chance that would be enough?
<Degi>
At 150 kHz thats like 2 ohms
<azonenberg>
so, no :p
<azonenberg>
the most i see available in 0402 is 15 uH
<azonenberg>
you can get up to 47 in 0603
<azonenberg>
100 uH is doable in 0805
<azonenberg>
at 150 kHz that's 94 ohms
<azonenberg>
Say 587-2048-1-ND?
<azonenberg>
A single-point test with a 75 ohm resistor on the DAC output showed no signs of instability
<azonenberg>
2 ohm oscillates, havent tried anything in between
<azonenberg>
But if we did 100 uH we'd have a fair bit of margin to be sure it won't oscillate?
<Degi>
Hmm idd guess sso? maybe use more than 0.1 µF then tho
<azonenberg>
why would we want to add more C? that makes it less stable
<Degi>
Well 0.1 µF has 15 ohms at 100 kHz
<azonenberg>
Do you think 0.1 uF will make problems on the rf ground side?
<Degi>
yeh
<azonenberg>
so in that case i should swap in a bigger C now and do a loop stability test with the 75R
<Degi>
hmhm
<azonenberg>
how much bigger do you want to go? i have 0.47 handy
<Degi>
Hm for 0.47 µF 100 µH we have maximum impedance at 23 kHz I think, that comes it to 14 ohms capacitive and 14 ohms inductive, so 7 ohms max. Vs 330 ohms that should be acceptable idk
<azonenberg>
what we know right now is that 0.1 uF oscillates with 2 ohms and not 75
<azonenberg>
We don't know how much margin we have in between
<Degi>
Use a potentiometer
<azonenberg>
if we can pick a C that won't oscillate at 75 i think if we use 100 uH we should have some safety margin for stability
<azonenberg>
I... don't actually know if i have any pots
<azonenberg>
certainly not at this low resistance range
<azonenberg>
i might have a few like 10K's
<Degi>
good night
<azonenberg>
DAC is stable with 75R -> 0.47 uF
<azonenberg>
So if we add 100 uH of L, i think we'll be OK
hlzr has joined #scopehal
hlzr has quit [Quit: Connection closed for inactivity]
_whitelogger has joined #scopehal
<_whitenotifier-3>
[starshipraider] azonenberg pushed 1 commit to master [+10/-0/±0] https://git.io/JfJ1c
<_whitenotifier-3>
[starshipraider] azonenberg 103378d - Initial "turn on LED" firmware for characterization board
<azonenberg>
ok well that took way too long to get working
<azonenberg>
but i have C++ running on the characterization board with newlib and bare metal arm gcc, no st tools involved
<azonenberg>
it doesn't DO anything yet, of course, but it turns on an LED which is a lot further than i was an hour ago
<azonenberg>
Turns out newlib is derpy on arm and if you don't specify __stack in your memory map, it does Bad Things
<azonenberg>
what confuses me is, cortex-m has an initial stack pointer in the vector table
<azonenberg>
why does newlib have to re-set the stack pointer?
<azonenberg>
does it not recognize it's a bare-metal target?
<azonenberg>
on my past stm32 experiments with a homegrown libc i just ran c++ right out of reset with a valid stack
<azonenberg>
no asm start code at all
<azonenberg>
just a for loop at the start of _start to call global ctors
<Degi>
Woo PCBs arrived
<balrog>
azonenberg: what c++ lib are you using? and is there no clang/llvm for this platform?
<azonenberg>
balrog: stm32f0, newlib. This is my first attempt at getting any libc running on stm32 without the ST library set
<azonenberg>
monochroma: lol probably for a bias t or something
<azonenberg>
the picovna i bought actually uses SMB connectors to supply power to the bias T's if you want to do s-parameters of an amplifier under bias or something
<monochroma>
yeah, but still uhhh a bit shocking to see :P
<monochroma>
i have seen places do long run USB with cat5 -_-
maartenBE has joined #scopehal
<Degi>
"What this is used for I do not have a Clue but people have asked for them so here you go."
<Degi>
If you need LAN over USB
<azonenberg>
Degi: except that isnt ethernet
<azonenberg>
it is literally usb over cat5 cabling
<Degi>
I mean it probably works the other way around too if you have an A to A cable
<azonenberg>
yes, that's what it's used for i think
<azonenberg>
also a-a cables are a whole other category of cursedness :p
<monochroma>
max distance spec on pre 3.0 USB is 15 feet but that doesn't stop people :<
<monochroma>
i had some early early linksys USB 802.11b adapters that used A-A cables (back when USB was so new companies didn't quite know to go A-B :P)
<Degi>
USB to garden hose
<Degi>
Three phase to USB to charge your phone extra fast
<azonenberg>
don't laugh, i've seen usb to just about everything
<Degi>
Hmm theres a twitter thread about that
<Degi>
There was that one PCIe to 5.25" slot but I couldnt find that anywhere
<Degi>
Like didnt you ever want to mount your GPU in a CD drive slot
<Degi>
Huh my tiny ZVS inverter board can do 50 watts without getting warm for a few seconds (because the LC circuit and my finger holding a steel object got hot)
<_whitenotifier-3>
[starshipraider] azonenberg pushed 1 commit to master [+6/-0/±6] https://git.io/JfUUa
<azonenberg>
Using 6.9K of the 32K of flash on that chip, lol
<azonenberg>
no optimization right now though for easier debugging
<azonenberg>
4.3k with -Os
<azonenberg>
Next step is going to be designing commands to change gain and offset
<electronic_eel>
nice
<electronic_eel>
been reading the chat backlog, good that you got it working so far
<electronic_eel>
one question: did you remove C70 again?
<azonenberg>
No
<azonenberg>
I still have 1000 pF on C70
<azonenberg>
C69 is 0.47 uF and the DAC is stable with a 75R output resistor
<electronic_eel>
would be interesting if the OP07 is stable with the 100nF and without C70
<azonenberg>
this is far too much DC resistance for accuracy, so i'll be adding 100 uH of series L once the inductor comes in
<electronic_eel>
I read that about the 100µH, I think it is a good idea
<azonenberg>
at the resonant frequency, 100 uH has ~90 ohms impedance so it should do the job with plenty of margin
<electronic_eel>
but I would order another OP07 as backup strategy if it doesn't help
<azonenberg>
But the 75 will be enough for me to keep the system stable and test out the DAC
<azonenberg>
even if the voltage is pulled weirdly by the high output R
<azonenberg>
anyway, then we had the output diode shorted due to excessive paste volume on the LGA-style (not wraparound) diode package
<azonenberg>
So i have an action item to shrink the paste print
<azonenberg>
then on the ADC board, i just derped and didn't put a uart header so i had to bodge one on
<azonenberg>
At this point, there are no known issues on the ADC board and the one unsolved issue on the AFE board has a planned fix i'm just waiting on parts for
<electronic_eel>
do you have a test plan or todo list or something like this for the afe and adc boards?
<azonenberg>
I don't have a formal test plan, although i'm taking notes on bugs in boards/BLONDEL/design-notes.md (not pushed yet) on test progress
<azonenberg>
my plan is essentially to build out a fully functional single channel scope
<azonenberg>
1g ethernet only, block ram based transmit/capture buffer
<azonenberg>
and only one channel
<azonenberg>
but otherwise full spec
<azonenberg>
so you'll be able to telnet to tcp 5025 and send scpi commands to set C1 gain/offset, configure trigger, etc
<azonenberg>
and then get waveform data back
<azonenberg>
Write a full scopehal driver, test it with a couple of signals
<azonenberg>
hopefully by the time all of that is done, i will have sold a bunch of the probes and be able to plow profits from those into making a complete BLONDEL prototype
<azonenberg>
if not i'll have to sink more of my limited personal cash into it
<electronic_eel>
a full 1 channel scope will be the best way to strange behavior with real-world signals I think
<azonenberg>
But i don't plan to move to a full scope until i've exhaustively tested this prototype with a variety of real world signals
<azonenberg>
And that's easily a month or more out at best
<azonenberg>
As soon as i've written a little bit more test code on the MCU, the next step will be hooking it up to the RX side of the FPGA TCP stack
<azonenberg>
so i can netcat to the FPGA and send SCPI commands, then get replies back via ftdi dongle because my TCP can't send yet
<azonenberg>
that way i'll have FPGA in the control path and can start testing larger portions of the system
<azonenberg>
Once i have gain and offset control working, next step before bringing up the ADC fully will be finishing the transmit-side TCP logic
<azonenberg>
Since i have no good way to get fast data off the ADC otherwise
<electronic_eel>
hmm, about the business plan side of things - wouldn't it make sense to have a active probe for lower-speed signals ready before BLONDEL?
<azonenberg>
Before selling them? Yes
<electronic_eel>
such a probe would also sell without BLONDEL
<azonenberg>
before building a prototype? not so sure
<electronic_eel>
but selling BLONDEL will be hard without
<azonenberg>
True
<azonenberg>
Either way though the scope is going to be a large project
<azonenberg>
probes will be done in parallel with all of it
<azonenberg>
The active probe is #3 on my list of probes
<azonenberg>
First step is the wideband passive handheld probe, then a solder-in version which should be fairly quick to build
<electronic_eel>
I know that the rest of scope won't magically appear on it's own now that the afe prototpye is there
<azonenberg>
those two will hopefully provide some extra cash to fund the rest of R&D
<azonenberg>
the active probe will require a bit more thought to design properly
<azonenberg>
but i do want to co-design it with BLONDEL, in fact i'd like to do the active probe prior to doing the final BLONDEL acquisition board so we can test the usb host side stuff
<electronic_eel>
yes, I think too that the passive probe will sell well
<azonenberg>
probably a separate board that sits next to the current AFE board
<azonenberg>
so we can test the active probe on the single channel prototype
<azonenberg>
only then will i be confident everything is tested and working, so we can move to the full acq board
<azonenberg>
also re the full BLONDEL system, i plan to actually start with the mainboard
<electronic_eel>
but maybe the active probe would sell without BLONDEL too, we just need a separate power adapter
<azonenberg>
Yes but i want to co-design them
<azonenberg>
even if it's ready sooner
<azonenberg>
anyway, my thought is that the digital board will involve writing a lot of code and also pose risks of its owwn
<azonenberg>
e.g. i've never done a SODIMM design or a 10G ethernet board
<azonenberg>
there's potential for random problems or pinout problems on any of that
<azonenberg>
the acquisition board, otoh, will be fairly low risk as it will basically be a multichannel re-layout of our already tested and validated AFE and ADC circuit
<electronic_eel>
how about CONWAY time-wise?
<Degi>
Hm how much does it cost to prototype the mainboard?
<azonenberg>
CONWAY is on hold until we figure out protection stuff
<azonenberg>
Degi: depends on how large it is and how many layers
<Degi>
Or how much did it cost to prototype the ones we did?
<azonenberg>
both are unknown right now
<azonenberg>
The AFE prototype was $97.30 for 3 boards, the ADC board was $82.90 for 3, at oshpark. No impedance control
<azonenberg>
The mainboard will be significantly larger and oshpark is unlikely to be cost effective
<Degi>
Oof
<azonenberg>
I plan to make it at a "real" fab, probably Multech (my usual chinese supplier)
<Degi>
Idk I got a gold plated PCB with impedance control for half the price at jlcpcb tho...
<azonenberg>
It will probably be six layers too, although four might be possible
<azonenberg>
Multech is not a cheap fab but they care about quality. Which is important to me
<Degi>
Hm yeah we have the signals on one side, I think 4 layer might be ok...
<miek>
jlc is not reliable enough for production
<electronic_eel>
azonenberg: do you want me to have a go at simulating the probe input for CONWAY?
<azonenberg>
They give you a full epoxy-potted board cross section and a 10+ page QA report with every order
<Degi>
Hm what problems does jlc have on larger scale?
<azonenberg>
electronic_eel: by all means
<Degi>
Nice
<azonenberg>
Degi: that's not the issue, it's how many signals we have
<azonenberg>
with all of the ADC lines and the various control signals to the AFE, we're looking at a 484 ball FPGA at minimum and i think a 676 is more likely
<azonenberg>
you cannot fan that out on two signal layers
<azonenberg>
even doing a ddr3 sodimm on 4L would be really hard
<Degi>
Hm yeah
<Degi>
I mean for the acquisition boards
<azonenberg>
The acq boards i expect to be 4L
<electronic_eel>
4l should be enough for them, but you want some impedance control there too
<azonenberg>
i'm not worried about pcb cost given how much expensive analog stuff we're putting on them
<azonenberg>
chip cost will dominate
<electronic_eel>
if we power the mcus with LT3042s, yes ;)
<azonenberg>
Lol
<azonenberg>
there wont be mcus on the acq boards, remember?
<azonenberg>
we'll just have the one big stm32f7 on the mainboard and run a zillion spi/i2c buses out to the acq boards
<azonenberg>
only reason we have a mcu on the afe board now is because i didn't want to fan out all of the controls for the various stuff there to 100 mil headers and jumper it off to an integralstick or mcu devkit
<azonenberg>
On the mainboard, we will have a single LTC3374 providing power to the FPGA, DDR3, STM32, 1G PHY, and 10G SERDES. I think (haven't run the numbers yet) we can do all of the mainboard control logic off that
<azonenberg>
then we'll just need to step down the incoming 12V to 5V since the 3374 is 5V max. But if I can find something just as good that eats 12V i might use that instead
<azonenberg>
I'm just a fan of the 3374 in general for digital supply rails because it has so many phases and outputs you can normally do a single chip PSU
<azonenberg>
that's what i use on integralstick to generate 3.3, 2.5, 1.8, 1.2, and 1.0
<azonenberg>
4 phases, 8 1A outputs (2 per phase), can parallel up to 4 for higher current
<electronic_eel>
do we need any power sequencing for the fpgas, phys and so on?
<electronic_eel>
sometimes proper power sequencing really complicates things
<electronic_eel>
especially for power down
<azonenberg>
the 3374 has an enable input for each channel
<azonenberg>
The FPGA generally doesn't care about sequencing, i have to look into ram and the 10G serdes still
<azonenberg>
the 1G phy shouldnt care either
<electronic_eel>
ok, then the enables should be enough
<electronic_eel>
I'm currently doing an oled carrier board, and that got complicated because of power sequencing required for power-down
<azonenberg>
iirc the fpga has optional sequencing to reduce inrush power during startup
<azonenberg>
but says the device won't be damaged by arbitrary sequencing as long as you stay within datasheet limits
<azonenberg>
just might use more power
<electronic_eel>
so when the power goes down I have to keep some juice in a bigger cap to power through the right poweroff sequence
<azonenberg>
But this is the sort of thing i'll double check during detailed design of the mainboard
<azonenberg>
we're still working on a block diagram level there right now