<azonenberg>
When you get a chance can you look through the whole schematic and see if anything jumps out at you?
<azonenberg>
i'm going to start working through my review checklist shortly
<_whitenotifier-3>
[starshipraider] azonenberg pushed 1 commit to master [+1/-0/±3] https://git.io/JvHuX
<_whitenotifier-3>
[starshipraider] azonenberg db3574a - Began entry-afe-characterization design review
_whitelogger has joined #scopehal
<Degi>
azonenberg: I think for paralleling LDO's you'd need some kinda current sharing scheme
<Degi>
(Also is there a reason that the power rails are labelled with ordinary labels and not kicad power symbols?)
<Degi>
I think R42 should be 25 k because you have 200 µA flowing through it
<Degi>
R57 should be 50k
<Degi>
Also on OVERVOLTAGE_N maybe use something like 1.5 k to the 5 V rail because the LM393 doesn't pull to exactly -5 V, then the voltage at OVERVOLTAGE_N would be given by the input protection diodes of the RS flip flop.
<Degi>
(I'd also put a diode from OVERVOLTAGE_N to PB6 such that the µC can only pull it down, that in case of µC fault the circuit still works)
<Degi>
(A few additional things: 58 Ohm for R4 gives a better match to 50 ohm input, also the gain with R5-R8 being 200 ohm is -1 between pin 4 and 5 of U1 which translates to -0.2 across a 100 ohm resistor between VSHIFTED_P and VSHIFTED_N (which is in the IC) so its more like -14 dB of gain, I suggest using 50 ohm instead of 200 ohm for the output resistors.)
<Degi>
Oh oops I swapped in + and in - I think
<Degi>
Uhm I think for U6 and U1 IN_P and IN_N are swapped.
<Degi>
Also U6 seems to give -0.39 V/V differential swing across both SMA outputs relative to the output voltage of the VGA (with the 10 ohm differential output impedance included)
<Degi>
I suggest 50 ohm for R32, R33 and 215 ohm for R28, R29
<Degi>
That way the output voltage is almost exactly equal to the unloaded output voltage of the VGA.
bvernoux has joined #scopehal
<Degi>
(Also is it a problem that the input gets pulled to a voltage different than ground? Because the common mode voltage of U1 is 2.5 V, which would change the voltage VIN_FILTERED is pulled to when no signal is being input)
<electronic_eel>
about paralleling the LT3042s: in the datasheet they explicitly describe it and how to do it (= parallel the r-set, a few milliohms in series to the output)
<electronic_eel>
but I'm not sure if it is the best way to do it. If there is a load spike, even the lt3042 can't do magic and there is a small dip or bump
<Degi>
Hm if you parallel them, then the set resistance needs to be halved
<electronic_eel>
so how about this: give each ADL5205 it's own LT3042 and put the rest on a common LT3042
<Degi>
But yes I see that page in the datasheet now
<electronic_eel>
that should also work for the final 4ch version
<electronic_eel>
C50 with 47µF seems to be a typo to me, 4.7µF seems more like it
<Degi>
Hm I think I got a better design for the input stage which would make it look to the outside like a 50 ohm resistor connected to ground
<electronic_eel>
maybe a reverse protection diode after the fuse on the input?
<Degi>
On the power rail?
<Degi>
Yes that'd be nice
<electronic_eel>
yes, against accidently frying the board
<Degi>
Hm my solution saves on different parts too (+1 OP amp, but only needs 1 type of resistor)
<electronic_eel>
RELAY_EN on the STM32 must also be 5V tolerant and it currently isn't, PB1 has a TTa io structure. move it to for example PB7 which is FTf.
<electronic_eel>
idea: change the LVC1g74 from 5v to 3v3. the inputs of LVC1g are tolerant up to 5v even on lower vcc. so you can also get rid of Q1B.
<electronic_eel>
then RELAY_EN is 3v3 and you don't need to change anything on the STM32
<Degi>
(Also is it OK that the values are in the resistors or should they be besides them? I think for only 3 letters that's readable)
<electronic_eel>
the resistors for 0V9_REF should probably be precision, like 0.5%. also R47 with 6.4k seems like a nonstandard value. how about 6.2k and 200r in series?
<Degi>
I think the resistors for 0V9 REF don't matter much in this design and in the design later on, they will probably be derived from the ADC rail, but yes, precision resistors isa good idea.
<electronic_eel>
0v5_REF and N0V5_REF should be buffered with small caps. the lm393 is like an ancient steam-powered thing, has pretty high bias currents that change with output state
<Degi>
(I think the ADC actually outputs a VCM)
<electronic_eel>
ah, ok, didn't look at the adc datasheet yet
<Degi>
Hm yes it outputs a voltage VCM and the analog input common mode should be between VCM-0.1 and VCM+0.2 V
<electronic_eel>
ok, enough from me now. I think when azonenberg wakes up, he has enough on his todo ;)
<electronic_eel>
I gotta do some planting before the sun goes down
<Degi>
Hm should I rewrite what I wrote above in a better readable way?
<electronic_eel>
don't know. I think azonenberg will read through it and if there is something unclear he'll ask
<Degi>
Hm for some reason my simulation says that my circuit proposal has -58 Ohm.
<Degi>
(Also Vin offset is missing a 100 nF cap)
<Degi>
Nvm about the images I sent, it needs some work on to be within spec of the DAC and there was another error with the common mode voltage compensation
<Degi>
When the lockdown is over, I'd have access to a 3 GHz VNA too.
<azonenberg>
ok i'm awake... will look shortly
<Degi>
^^
<Error_404>
azonenberg: any reason that SendRaw data doesn't have a return value? ported my fixs to the new code last night, but w/o being able to report an error up from those functions I have to rely on checking state of the transport layer
<Error_404>
which feels janky
<Error_404>
ideally ReadReply() would write to a std::string by reference too, but that's a bigger change
<Error_404>
and just return errors rather than data
<azonenberg>
Error_404: Make a ticket for that. There's a few things regarding error handling i want to improve
<Error_404>
+1
<azonenberg>
in particular, right now we have no good way to report a failure to connect/initialize from a SCPIOscilloscope constructor
<azonenberg>
the two obvious options are to throw an exception (we're currently exception-free at the library level) or to have some kind of "is initialized" function you can call post construction
<Error_404>
a move away from unixy "return idk either error or data, implementation defined!" to "always return an error code, everything else is by reference if it requires persistence out of the call"might be good
<Error_404>
exceptions seem like the canonical form for handling constructor issues though
<azonenberg>
Yes. i like "always error code" for the most part
<azonenberg>
anyway make a ticket and we'll discuss it. There's a couple of other major refactorings pending as well
<Error_404>
ack
<azonenberg>
for example the ChannelRenderer stuff dates back to when we had a separate renderer making cairo draw calls for each waveform
<Error_404>
been something I meant to bring up but hadn't run into it as an issue
<azonenberg>
the only thing we still use is the functions for getting color/text out of protocol decodes, which i think almost make more sense to be moved into the decoder class itself
<azonenberg>
since rendering is now done in the waveformarea class / shaders
<azonenberg>
i have a ticket for ripping that all out but havent had time to sit down and work on it
<azonenberg>
right now my priority is getting some boards out so we can overlap API/software work with pcb fab latency (longer than usual these days)
<Error_404>
yes, it's not at all a coincidence I was working on it last night after pushing out some designs :p
<azonenberg>
Speaking of which you're coming into the channel at a good time today - have you followed any of the previous discussion re the scope hardware?
<Error_404>
afraid not, I can go read some backlog though
<Error_404>
siglent is currently eating up 4U for...not much more perf lol
<azonenberg>
1U, gig-e backhaul, front panel touch LCD for IP config (turned off after a minute or so of inactivity and only used for getting it on the LAN)
<Degi>
Hm what's with the 14 bit mode?
<azonenberg>
Degi: i could support that too but would need an external antialiasing filter
<azonenberg>
14 bit is more than most scope users need
<azonenberg>
and then slots for one or two 4x AFE + 1x ADC boards
<azonenberg>
so you can load 4 or 8 channels depending on your budget
<Degi>
I mean you could just say "Aliasing above 50 MHz may occur" in the GUI
<azonenberg>
anyway, right now for the purposes of testing i'm building a characterization board with a single AFE in isolation and 50 ohm SMA input -> 100 ohm differential SMA output at HMCAD1520 compatible levels
<azonenberg>
we're working on the schematic review now before i move to layout
<_whitenotifier-3>
[scopehal] four0four opened issue #103: Move toward a more consistent error/exception paradigm - https://git.io/JvH7D
<azonenberg>
The current roadmap has five scopes on it. First is this one, one HMCAD1520 per 4 channels in 1U
<azonenberg>
100 MHz bw
<Error_404>
is this the design you're getting out? :D
<azonenberg>
That AFE test board is the current priority before i move back to scopehal software side, yes
<azonenberg>
anyway once that whole scope is good, next is one HMCAD1520 per channel (always 1 Gsps / 640 Msps regardless of # enabled channels), probably 250 MHz bw
<azonenberg>
Next is a... 350 MHz maybe? scope with one LM97600 per 4 channels, so 1.25/2.5/5 Gsps 7.6 bits
<azonenberg>
followed by a... 500 MHz? 750 MHz? scope with a LM97600 per channel, always 5 Gsps
<azonenberg>
Followed by the 1-2 GHz BFS
<Degi>
I mean you could do 500 MHz on 1.25 GS/s and 2 GHz on 5 GS/s and get a sorta ok signal out
<azonenberg>
I'm not going to push these scopes to nyquist
<azonenberg>
i want some sample rate headroom
<Degi>
Nyquist would be 2.5 GHz on 5 GS/s
<azonenberg>
especially since the antialiasing filter is not a brick wall
<Degi>
Hm right
<azonenberg>
in fact, bessel-thomson has quite a slow rolloff
<azonenberg>
ok so back to design review
<azonenberg>
OVERVOLTAGE_N not being pulled to exactly -5V should be OK, i think it will still be below Vil of the mcu
<azonenberg>
the MCU never drives it
<azonenberg>
it's an input only
<Degi>
Is it below the Vil of the SR latch?
<azonenberg>
although i guess i could allow the mcu to drive it to force the input to shut down if i wanted that?
<azonenberg>
Vil is 0.35 * VCC or 1.75V
<azonenberg>
sorry 0.3x
<azonenberg>
so 1.5V
<azonenberg>
i dont think the lm393 will drive it that high with an equal pullup/down
<azonenberg>
next, i like the idea of splitting the 5V rail
<azonenberg>
we'll have one +5V lt3042 for the gain stage and one for everything else
<azonenberg>
Degi: U1 should be unity gain
<azonenberg>
the -6 dB is the attenuator on the input stage prior to VIN_FILTERED
<Degi>
Ah
<azonenberg>
hence why i'm saying "net" gain rather than gain for that stage
<azonenberg>
i'm tracking total gain from input SMA to that point
<azonenberg>
If you disagree with my math, please explain why
<azonenberg>
the *intent* is to be unity gain :)
<Degi>
Ok so at pin 4 and 5 it is unity gain but then you have the 100 ohm resistors on the output (which should be 50 ohm I think? Or left out) which reduce the gain
<Degi>
Also the input is mismatched and it isn't going against ground but against 1.25 V if VIN_OFFSET=0
<azonenberg>
the resistors are there for impedance matching, i need to crunch things a bit to double check that
<Degi>
That extra OP amp is needed for pulling it against ground.
<Degi>
For unity gain leave out the 50 ohm output resistors
<azonenberg>
look at 8.2.1.1 of the LMH6552 datasheet
<Degi>
The VGA has an input impedance of 100 ohms...
<Degi>
If you add two 100 ohm resistors like in the current design, that is an output impedance of 300 ohms for the LMH6552
<azonenberg>
i thought the 6552 had low impedance output and that's why they had the resistors
<azonenberg>
i'm looking at figure 40 now studying some of the values they have there
<Degi>
If you scroll 1 page further in the datasheet, it has 50 ohm resistors on its output, to match a 100 ohm differential impedance (but you don't need the resistors, that gives +6 dB at the cost of making any signal coming into the amplifiers output reflect back, which is not a problem if the transmission line is matched at the other end)
<azonenberg>
The ADL5205 has a 100R input terminator
<azonenberg>
on die
<azonenberg>
VSHIFTED goes straight into that
<azonenberg>
So i think i'll make R30/31 be 0R just to keep a footprint there in case we find it's needed
<Degi>
Okay
<Degi>
Also look at the image I posted, without these suggestions the input would float to 1.25 V if left unconnected which could be kind of a problem
<azonenberg>
the input of the amplifier? we have $4 pulling IN_P fairly strongly to ground
<azonenberg>
R4*
<Degi>
Okay then the input is pulled toward 0.5 +- 0.25 V
<azonenberg>
hmm but the input resistance of the 6552 is 15 ohms
<Degi>
...which is still kind of a problem when measuring DC
<Degi>
Input resistancE?
<azonenberg>
differential
<azonenberg>
it looks like pins 8-1 are 15 ohms to each toher
<azonenberg>
6552 datasheet page 5 Rin
<Degi>
Hm isn't Vin+ and Vin- at the same voltage anyways?
<Degi>
(Also you have in+ and in- swapped on the schematic, that way it isnt an amplifier but a schmitt trigger)
<azonenberg>
I'm just making an observation
<azonenberg>
IN- is 1, IN+ is 8
<Degi>
In the current schematic, IN_P is connected over 200 ohm to Q_P, it should be Q_N
<azonenberg>
Oh you're saying the feedback is to the wrong legs
<azonenberg>
Good catch
<Degi>
Also for the other LMH6552
<Degi>
Anyways this circuit https://i.imgur.com/Kq5hWYO.png would keep the input voltage at 0 V (a few mV within 0 V) and the input impedance at 50 ohm (+- 0.1 Ohm I think)
<Degi>
(Also don't forget a capacitor on the DAC output unless you want the input signal to go to it)
<azonenberg>
(bbiab call for work)
<azonenberg>
ok so... let's see
<azonenberg>
why are you running the 6552 in inverting mode instead of non-inverting?
<azonenberg>
i have mine set up as non-inverting
<Degi>
Hmm
<Degi>
You sure that that works at all?
<azonenberg>
it should? why wouldnt it
<azonenberg>
electronic_eel: C50 47 uF is not a typo
<Degi>
Like in simulation the output just saturates to a rail. Its essentially a schmitt trigger
<electronic_eel>
a monster MLCC in 1812?
<azonenberg>
i mean i have the feedback flipped
<azonenberg>
i was thinking of more like 2010
<azonenberg>
sorry i mean 1210
<Degi>
I mean Q_P is going to IN_P, right?
<electronic_eel>
why that? if you need more capacitance then use second polymer in parallel
<azonenberg>
Degi: no
<Degi>
Ah right
<azonenberg>
Q_P to IN_N, Q_N to IN_P, but VIN_FILTERED to IN_P
<Degi>
Oh oops flipped that in my schematic
<azonenberg>
electronic_eel: hmm i guess yeah i can probably get away with just the 4.7s
<azonenberg>
if i have the polymer
<electronic_eel>
I think it should be enough with 4.7µ
<azonenberg>
RELAY_EN does not need to be 5V tolerant
<azonenberg>
it's driving the gate of Q1A which is a logic level FET
<azonenberg>
... oh wait
<azonenberg>
yeah U7 is driving it too, derp
<electronic_eel>
yeah, just switch the '74 to 3v3
<azonenberg>
no i'm just swapping it with GAIN_PWRUP
<azonenberg>
so now it's on PA8 which is FT
<electronic_eel>
why do you want the '74 on 5v vcc?
<azonenberg>
For 5V input tolerance on OVERVOLTAGE_N
<electronic_eel>
it is a lvc1g - they are tolerant to 5v even with lower vcc
<azonenberg>
oh cool
<electronic_eel>
one of the things why i really like the lvc1g/2g series
<azonenberg>
but is there a benefit to doing it that way if i have a free 5v input on the stm32?
<azonenberg>
in particular, it means one less power rail to cram into the afe
<azonenberg>
this is a 4L board, it's going to be TIGHT
<electronic_eel>
you can get rid of q1b
<azonenberg>
q1 is a dual fet and i need one half already
<azonenberg>
the other half costs nothing
<electronic_eel>
ah, ok. so you are planning the final board without 3v3 rail?
<azonenberg>
Correct. it's only for the mcu subsystem - and evne on this board i am keeping 3v3 as local to the mcu as i can
<azonenberg>
i may have 3v3 near the connector with a level shifter to the fpga for 5v ouputs or something
<electronic_eel>
but you want to replace the mcu with the fpga, and the fpga is most probably not 5v tolerant
<azonenberg>
but certainly not in the afe area
<azonenberg>
basically in the dense area with all of the analog signal paths i want to have as few power pours as i can
<azonenberg>
just for routability reasons
<electronic_eel>
ok
<azonenberg>
having a 24c discovery/cal eeprom on 3v3, etc is totally fine
<azonenberg>
because its not in the critical path for routing
<azonenberg>
re the dividers, one of the items on my review checklist is verifying tolerances, voltage ratings, etc on all passives. i'm not there yet
<azonenberg>
at that point i also double check exact calculated values and round to E24 etc if needed
<azonenberg>
see schematic-checklist.md on the github repo
<azonenberg>
that is actually the next not-yet-signed-off item on the checklist :)
<azonenberg>
the 0v9 reference is only for the characterization board, i will be using the adc vcm output on the real system
<azonenberg>
i just want to get something somewhat close for the purposes of testing
<electronic_eel>
ok
<Degi>
Hmm will that OP amp thingie from my suggestion be added to pull the input to 0V?
<azonenberg>
That was the next thing i wanted to discuss with electronic_eel and get his input on :)
<Degi>
Oki ^^
<electronic_eel>
hmm, ok, I must admit I didn't read it all
<azonenberg>
electronic_eel: basically degi is concerned that the offset stage input will float to a nonzero voltage if no input is connected
<Degi>
And that the input is somewhat umatched
<azonenberg>
i guess the question is, how big a deal is this and, if it's a problem, what do we want to do about it?
<azonenberg>
everything from the SMA to VIN_FILTERED should be matched 50 ohm impedance
<azonenberg>
i calculated the filters etc to all be 50 ohm
<Degi>
The amplifier has less than 50 ohms input Z
<azonenberg>
i mean i guess one option is to DNP R4 and feed the filter output directly into the amp?
<azonenberg>
the line from the filter to the amp will be electrically short at 100 MHz
<Degi>
I think it still needs to be matched to 50 ohms?
<Degi>
Like if you use 330 ohms instead of 200 ohms and 68 ohms instead of 50 ohms and add a second 330 ohm resistor to a fixed voltage, you have almost exactly 50 ohm input
<electronic_eel>
why will the offset stage float to non-zero on an unconnected input? doesn't that depend on what you set the vin_offset to?
<Degi>
Right now it has 42 ohm input R
<Degi>
Yes the voltage that the input floats to is I think 0.25*Vin_offset + 0.5*2.5 V
<Degi>
But my circuit proposal makes the input voltage independent of Vin_offset and 2.5 V, instead making it always 0 V so that the equivalent circuit at DC looks like a 50 ohm resistor.
<Degi>
(The input still floats positive with V_offset = -2.5 V
<electronic_eel>
hmm, on the scopes I used in the past, a channel without probe connected always showed gnd. if you shift the signal around on screen, it still stayed at gnd
<electronic_eel>
I can understand if a user expects this behavior
<azonenberg>
yes agreed
<azonenberg>
and this was my intention
<Degi>
Like if you have a probe with a 50 ohm builtin impedance and you probe GND and have offset at 0 V, it shows -142.3 mV
<azonenberg>
my thought was that R4 would pull the input to ground
<Degi>
But its pretty bad at that
<azonenberg>
and you can then arbitrarily offset the signal
<azonenberg>
then once you have the ADC codes, you apply a linear transformation to multiply by the gain and remove the offset
<azonenberg>
in order to get back the voltage at the input
<Degi>
Hm I don't really like that adjusting the offset changes the input though
<azonenberg>
yes, i dont want power being driven out the input
<Degi>
Also if you probe GND you won't be able to adjust the offset such that the scope shows 0V
<azonenberg>
i wonder about maybe adding a unity gain buffer at VIN_FILTERED before R5?
<azonenberg>
and remember the goal is not to have VSHIFTED be 0V
<Degi>
Hm, that'd do roughly the same as my circuit if you put 50 ohm on its input
<azonenberg>
yes that's the idea. Keep R4
<Degi>
Vshifted should be 0 V when Vin is 0 V and V offset is 0 V, right?
<azonenberg>
then between R4 and R5 add a buffer to keep the feedback path from back-driving signal onto VIN_FILTERED
<azonenberg>
Yes
<Degi>
But it isnt with your current circuit
<Degi>
Wait a sec ill simulate that
<azonenberg>
how is it not?
<azonenberg>
we have IN_P and IN_N both held at 0
<Degi>
Try it out, input = GND, Voffset = GND results in 100 something mV on output
<Degi>
No they are not held at 0 V
<Degi>
If filtered and offset are at ground, then they are held at VCM/2
<electronic_eel>
but if you add another opamp into the signal path, it needs to be a fast & precise one. one on the offset doesn't need to be fast, just precise
<azonenberg>
so stepping back a bit i'm trying to understand exactly where this offset comes from
<Degi>
From the output common mode voltage
<azonenberg>
oh i think you might be misunderstanding how i am intending to use VIN_OFFSET
<azonenberg>
or... maybe i am
<Degi>
Hm still, is power supposed to come out at the input?
<electronic_eel>
wouldn't that be something that is better spiced?
<Degi>
I did spice it
<Degi>
That's how I came up with the new circuit
<azonenberg>
is this going to be a problem at the final gain stage too? shouldn't be, since that is fully differential?
<Degi>
Hm not sure. Probably not. U1 should isolate input from output good enough
<Degi>
My circuit gives 49.2 ohms at the input (could be done with 200 ohm resistors too, that'd need changing R5) and 0V at the input
<Degi>
If you spice it and the voltage goes off from 0 V, you notice that the input resistance becomes voltage dependent.
<Degi>
(Because the equivalent circuit becomes a voltage source in series with a resistor instead of just a resistor)
<electronic_eel>
Degi: in your circuit in the picture you posted - there is C2 directly on the opamp out. what is it for and doesn't the opamp dislike such a capacitance?
<Degi>
Hm you could add a resistor before. It is for grounding the RF
<azonenberg>
So U1 in your schematic is set up as an inverting amplifier summing VIN_OFFSET/2 and +2.5
<Degi>
Because not sure if the OP amp likes up to 100 MHz on its output lol
<Degi>
Hm Vin offset/4 and 2.5/4 yes
<Degi>
*2.5/2
<azonenberg>
well with a gain of 0.5
<Degi>
Yes
<electronic_eel>
Degi: ok, makes sense. I would probably add a resistor because lot's of opamps become unstable with a cap at the output
<azonenberg>
and you're trying to filter out all of the RF components from VSHIFTED_N feedback and just get the DC?
<Degi>
In simulation that gives an input voltage of -232 µV (that depends on OP amps and resistor precision)
<azonenberg>
i guess here's the better question... is this necessary, or can we just calibrate out this offset?
<Degi>
In where? You mean on the Vin_OFFSET? That's from the DAC and the cap there is to stop the RF from going to the DAC
<azonenberg>
Given that we're going to be applying a linear function to the ADC codes to get back to voltages anyway
<Degi>
Vshifted_N feedback is not measured in this circuit, only the offset and CM voltage
<azonenberg>
is there any reason we can't just add some fraction of 2.5V in postprocessing?
<Degi>
I mean you need that OP amp if you don't want to have some voltage on your input...
<azonenberg>
ok so your main goal is to prevent feedback out into the probe
<Degi>
Yes
<electronic_eel>
I think that is a pretty strong point, you don't want to come out anything off your scope input
<Degi>
The 100 nF caps are mostly for preventing RF from going into the DAC and OP amp outputs.
<azonenberg>
yes that i agree with
<azonenberg>
so as far as picking the amplifier, we want +/- 6V Vdd range and bandwidth basically doesnt matter, just low offset?
<azonenberg>
in fact lower bandwidth is good, in terms of filtering out RF going through?
<Degi>
Hm bandwidth should be high enough to cope with the fastest rate VIN_OFFSET changes, but I guess that's a few Hz at max?
<electronic_eel>
yes, the offset is not a function gen
<azonenberg>
VIN_OFFSET can be considered DC for all intents and purposes
<Degi>
And on the output of U1A (in my image) an inductor before the cap to prevent the OP amp from going unstable. Ideally an OP amp that's stable with capacitive loads
<Degi>
R1 and R2 can be made from the same resistor as R3 just a few in series. Or maybe a resistor network to save space/money
<electronic_eel>
Degi: how about this: the output of your U1A goes directly to the R3 feedback resistor. but not to R4 and C2. between the opamp out and C2 , R4 you add another resistor to shield off the opamp out from the cap
<azonenberg>
What do you think of the INA188?
<electronic_eel>
but something like this should probably better be spiced, with a specific opamp model
<Degi>
The problem is that R4 draws a bunch of current. And you can't just do like 200+130 ohms with a cap in the middle because then the impedance at RF is different than at DC.
<Degi>
Ahh right you can just change R3
<Degi>
Hm wait that still would have different impedance at RF than at DC
<electronic_eel>
azonenberg: the INA188 is a full instrumentation amp, not a regular opamp like in degis proposal. how would that help?
<Degi>
Hm max offset is more interesting than drift
<azonenberg>
sorry i meant offset
<Degi>
Lol full instrumentation amp. I mean that sure has low offset... Tbh if we use 0.1 % resistors, not sure how good the OP amp needs to be. Maybe 1 mV? 100 µV?
<azonenberg>
electronic_eel: i was just digikey searching opamps with wide supply range
<azonenberg>
MCP6H01T?
<azonenberg>
that has much higher offset, 0.7 mV
<Degi>
If we add a second capacitor between OP amp - and OP amp out, then it gets stable with capacitive loads (at least for the AD8040 which is some rando OP amp I chose for sim)
<azonenberg>
LT6000?
<azonenberg>
i like that more
<Degi>
Hm 1.25 V * 0.1 % = 1.25 mV, offset below that would be nice
<azonenberg>
keep in mind we can calibrate a static bias to VIN_OFFSET
<azonenberg>
driving 1 mV out the probe, after probe attenuation and the input buffer, i dont think is a huge problem
<azonenberg>
input filter*
<Degi>
Hm ok
<Degi>
Adding a capacitor between OP amp - and OP amp out results in no oscillations, even with 100 nF on the output and only 1 nF between - and out
<Degi>
Lol INA188 with 55 µV offset voltage... Yeah that'd be some overkill
<electronic_eel>
how about OP07?
<electronic_eel>
typ 60µv offset
<Degi>
Lol I have some device where almost all OP amps are OP07 G
<azonenberg>
electronic_eel: eew soic
<azonenberg>
but it's cheap
<electronic_eel>
yeah, nice and cheap
<Degi>
You can get them in 5 pin TSOT. I mean the same as SOIC but smaller
<Degi>
Hm cant find any resistor arrays that are worth it. I guess 10k 0.1 % resistors in series work too.
<azonenberg>
OPA727?
<azonenberg>
a bit pricier but 15 uV offset and DFN
<electronic_eel>
it is a lot faster, so it might oscillate faster
<azonenberg>
Fair point, low bandwidth is a plus here
<azonenberg>
ok so OP07 it is
<Degi>
Hm isnt the phase margin etc also what determines oscillation?
<Degi>
Hm my program has a OP07 model ill try
<Degi>
Wow it doesnt even need a feedback capacitor out to IN- to not oscillate with 100 nF load
<Degi>
(But add a place for that on the PCB for characterization. Maybe it does IRl)
<azonenberg>
you think a pot between the OP07 offset pins is necessary?
<azonenberg>
or is the factory offset low enough as is
<electronic_eel>
I think the factory offset is ok, the rest we have to cal out in sw
<Degi>
Hm if you add that, then you should add a pot on R1 and R2
<Degi>
Unless you get like 0.01 % resistors or something
<electronic_eel>
a pot adds lots of aging problems, can't wash them and so on
<azonenberg>
my thought exactly, i want to stick with digital cal as much as i can
<electronic_eel>
yes
<Degi>
Hmm cheap pots sometimes randomly fail lol
<Degi>
Ohh also cheap pots have some reaaaally bad temperature coefficient
<Degi>
Okay my circuit with R10, R11 = 0 ohm has an output equal to the input (in simulation very equal to like 0.1 % or so, but I simmed at 1 Hz)
<Degi>
Huh for some reason the output has 6 dB gain
<Degi>
Hm I think R10, R11 = 50 Ohm is actually good then. I think the 1 V input gets converted to 1 V output on each wire of the differential pair, yielding 2 V differential
<Degi>
Wait it has 0 dB gain lol, I measured output peak to peak against input amplitude *facepalm*
<Degi>
(So ignore the last 3 messages)
<_whitenotifier-3>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±8] https://git.io/JvHbp
<_whitenotifier-3>
[starshipraider] azonenberg 1f60af2 - Continued design review, added U18 to offset stage
<Degi>
2V5_REF and VIN_OFFSET should be hierarchical labels I think. What is R63 for?
<Degi>
Hm at first I would try with R63 solder bridged. If that makes problems, add some kinda resistor...
<azonenberg>
I can put a 0R there as well
<Degi>
(I would add a note in the schematic to solder bridge R30, R31, R63)
<electronic_eel>
I don't know if C68 will work to shield the rf behind a resistor
<azonenberg>
and we have hierarchical labels already for the inputs
<azonenberg>
you only need one label to be hierarchical, the rest don't
<Degi>
I worry about the OP amp output impedance getting higher at higher frequencies, that's why C68 is there
<Degi>
Oh neat
<azonenberg>
electronic_eel: you want R63 = 0R? and smaller C68?
<electronic_eel>
yes, that is probably better
<electronic_eel>
and as Degi suggested, a footprint for a DNP cap across R61
<azonenberg>
how small then, probably hundreds of pF?
<Degi>
I'd suggest 100 nF, the OP amp seems to be stable with that in simulation.
<azonenberg>
for C68
<electronic_eel>
yes, if Degi spiced it like this, then 100nF.
<azonenberg>
ok so if nobody has further action items at this point i'm going to continue going down the signoff checklist
<Degi>
Hm maybe add a DNP cap footprint from U18 pin 6 to U18 pin 2
<azonenberg>
Degi: already done
<Degi>
Oki ^^ (just in case its unstable, you won't need to solder some weird stuff on top heh)
<azonenberg>
If anybody is curious, BTW, my digikey cart right now is $239.35. That includes overages on some of the resistors (but i haven't picked out all of the passives yet either)
<azonenberg>
extra LM393s because they're so tiny and cheap
<azonenberg>
a st-link because i wanted to have one anyway
<Degi>
Huh can you send a screenshot or so?
<azonenberg>
not including the SMAs because i have a bunch of those in stock, but i need to inventory and see if i need to buy more
<Degi>
Lol we have 16 € of LT3042 which would be 8 € in larger quantities.
<azonenberg>
I have $28.52 of LT3042s at digikey qty 1 prices
<azonenberg>
the 3.3V one is of course not needed
<azonenberg>
then the ADL5205 is two channels and we only really are using one
<azonenberg>
so this is obviously not a predictor of what the full scope will cost, certainly not in volume
<Degi>
Some of our parts get 50% drop at higher quantities
<azonenberg>
Easily
<Degi>
Idk if we can get the AFE+ADC to 200 € that'd be neat
<azonenberg>
i expect the full scope to cost in excess of $1000 in prototype volume for an 8-channel system
<azonenberg>
maybe even for a 4
<Degi>
Idk that doesn't sound too pricy for the features it has
<azonenberg>
but i think we can get way down for higher volume
<Degi>
Especially PCBs lol
<azonenberg>
yeah. We'll see, there may be a cost-down spin at some point where we see what tolerances we can actually get away with on parts etc
<azonenberg>
right now i want to design something that works
<electronic_eel>
currently the relais will probably switch on on poweron, but if for example the -5v isn't there, the protection won't work
<electronic_eel>
I would prefer something where the relais stays off until the mcu says to switch on
<azonenberg>
none of the power rails are switched right now, they all come up as soon as power is present
<azonenberg>
the relay is open when no power is supplied
<Degi>
Hm why would the relay switch on?
<electronic_eel>
no, one rail may be shorted
<Degi>
For that to happen, INPUT_RST_N needs to be driven low, right?
<azonenberg>
There may be a glitch if U7 powers up in the Q=1 state
<Degi>
Hmh
<azonenberg>
but as soon as the MCU turns on it will drive OVERVOLTAGE_N low to turn the channel off during the startup sequence
<azonenberg>
i'm not super worried about the relay glitching momentarily to the on state during powerup. the clipping diodes can handle the current for a short time anyway even if the input is tied hard to a bad voltage
<Degi>
Maybe a pulldown on INPUT_RST?
<azonenberg>
even if 5V0_P/N are not yet stable, there are capacitors on those rails to ground that we can sink current into via the diodes
<azonenberg>
Degi: R34
<azonenberg>
already there
<electronic_eel>
Degi: there is a pulldown
<Degi>
I see
<azonenberg>
but it's on INPUT_RST
<azonenberg>
INPUT_RST_N is pulled high because of the fet level shifter
<azonenberg>
But once again, the LM393 is running immediately after powerup with no software interaction
<azonenberg>
so as soon as power rails are stable overvoltage protection is active
<Degi>
(Also there should be a warning to not apply more than 25 V ever, because the relay is only rated for 500 mA switch current)
<azonenberg>
and as long as D3 doesn't melt before the rails are stable, an out of range voltage during powerup is safe
<Degi>
I think the problem is what happens when the negative rail fails?
<azonenberg>
If your power rails are failing, we could be damaging the silicon elsewhere in the system anyway
<azonenberg>
protection not working at that point is the least of our worries
<azonenberg>
a failing LDO could be putting 7V or more into parts rated for 5.5V max
<Degi>
I mean if the -5 V rail fails to GND
<azonenberg>
Then D3 clamps input to ground instead of -5V
<azonenberg>
the LM393 will stop protecting though, but that seems like a really improbable failure mode
<azonenberg>
what if the relay fails short? etc
<Degi>
Hm I know how to fix thatI think
<azonenberg>
you cant make it fault tolerant to EVERYTHING
<azonenberg>
re 25V, i'm going to spec the input for +/- 5V operating range
<Degi>
What if you put R37 from A1/A3 to 5V and increase R53 to 10k?
<Degi>
Good point lol
<azonenberg>
any protection beyond that is a bonus, users are already violating our absolute max if they go out of range
<azonenberg>
the fact that we can survive 25V doesnt even need to be advertised :p
<Degi>
Yeah good idea
<azonenberg>
maybe we can spec +/- 5V operating range and +/- 20V absolute max or something to still have headroom
<azonenberg>
R53 needs to equal R37 so that when A3/A1 go to -5V, OVERVOLTAGE_N is zero
<azonenberg>
or at least below Vil of U7
<electronic_eel>
yes, operating range and damage level are two separate things, both belong into the datasheet
<Degi>
I mean connect R37 to A1/A3
<azonenberg>
electronic_eel: yeah i plan to publish full specs on the frontend. a lot more than you get on "real" scopes
<Degi>
That way the OP amp pulls OVERVOLTAGE_N to -5 V but the 10k resistor limits it to -0.3 V or so, I mean the things have internal diodes.
<electronic_eel>
Degi: it has a open collector output, needs a pullup
<azonenberg>
for example s-parameters of the inputs including S11 as seen by the probe
<Degi>
"I mean connect R37 to A1/A3"
<azonenberg>
as opposed to just "50 ohm input impedance"
<azonenberg>
being able to see how much power actually reflects off the afe could be handy
<Degi>
Hm maybe characterize it beyond 100 MHz
<azonenberg>
(in particular the antialiasing filter is a largely reflective filter if memory serves me right, so in the far attenuation range of the filter I expect a lot of return loss)
<electronic_eel>
Degi: what would it help to connect R37 to A1/A3?
<azonenberg>
i will probably publish s-parameters out to 500 MHz which is nyquist of the adc
<azonenberg>
at max single channel sample rate
<azonenberg>
but to do that, i need to buy a VNA with wider range. my current one has a *minimum* of about 130 MHz and can't go lower
<azonenberg>
which makes it entirely useless for testing this board :p
<Degi>
That way the voltage at A1/A3 varies between -5 V and 5 V and overvoltage N between -0.3 V and 5 V. That way the circuit works when the -5 V rail is at GND for some reason.
<azonenberg>
like i said i don't think that failure of a power rail is a circumstance we really need to worry about
<azonenberg>
This is test equipment, not life safety gear
<Degi>
Combined with input overvoltage. Well fair
<azonenberg>
if we lose a power rail the system is already nonfunctional
<azonenberg>
the board already probably has to get reworked
<Degi>
I could access one 6 kHz-3 GHz
<azonenberg>
further damage at that point is so far beyond operating specs i'm not going to worry about it
<azonenberg>
specan with built in vna? interesting
<Degi>
With COM2 option (6 kHz - 3 GHz, -103 dBc/Hz phase noise, tracking generator, VNA, signal generator, preamp and a bunch of other irrelevant stuff)
<azonenberg>
well once i've done initial testing and characterization i have no problem mailing the board around to various folks in the channel for further study
<azonenberg>
longer term i am probably going to buy myself a PicoVNA
<Degi>
But as long as schools are closed I can't access it, since that lab is in a school (and they're kinda closed because of the virus for an unforeseeable while)
<azonenberg>
ah ok
<azonenberg>
300 kHz - 7 GHz, full 2 port quad rx architecture
<azonenberg>
4205 EUR
<Degi>
That sounds okayly priced
<azonenberg>
or 4911.81 USD at tequipment with my member discount
<Degi>
Hm the noise floor for the one I have access to seems to be around -130 dB or so
<Degi>
*dBm
<Degi>
I wonder if you can make a good VNA from an ADC and a DAC, no other RF hardware... Just very fast ADC/DAC.
<azonenberg>
But i don't have 5 kUSD to spare so i don't expect to be buying it until either some of my customers recover from the virus enough ot send me more work
<azonenberg>
or until my summer bonus comes in
<azonenberg>
which probably won't be until the fall at this rate
<Degi>
Wonder if those things can make 2D plots
<Degi>
Like input frequency vs output spectrum
<Degi>
Not sure how useful that'd be for RF but I think for optics that's useful
<electronic_eel>
azonenberg: maybe add a remark to the schematics why the OP07 is needed
<Degi>
Hm yes and maybe a few other remarks if anything comes to mind; Then we don't have to figure out later on why a thing is like that (especially in cost reduction steps)
<Degi>
I do kinda wonder how fast sampling scopes work. Do they spin their own comparator chips?
<electronic_eel>
beyond a certain point: yes.
<electronic_eel>
there was a video on the signal path where Shariar visited Lecroy and checked their 100ghz scope
<Degi>
Hm I saw the one where they disassembled the 256 GS/s scope
<electronic_eel>
all custom stuff on the frontend, sampling and adc
<Degi>
With the weird signal splitters which split it into 4 64 GS/s streams
<Degi>
And the RAM too?
<electronic_eel>
no, the ram would be standard, like the fast stuff that is on gpus
<electronic_eel>
azonenberg: there was my suggestion to add a reverse protection diode on the 12v input. did you decide against it?
<azonenberg>
electronic_eel: i thought about it. given that it's a barrel jack i'm not sure how necessary it is
<Degi>
My ECP5 dev board with manufacturer supplied PSU has one for some reason
<electronic_eel>
you could also put a SMBJ12A from GND to 12V0 (after the fuse)
<Degi>
Also I have a inverted polarity 12 V supply somewhere lol
<electronic_eel>
that would protect against negative and more than 12v
<miek>
Degi: there's the reason :D
<azonenberg>
yeah that might work
<electronic_eel>
(instead of the series diode)
<electronic_eel>
I often have that on my circuits like this
<electronic_eel>
worst case the fuse and the diode burn out and have to be replaced, but the rest stays alive
<azonenberg>
yeah. it'll blow the soldered-down fuse, but that's fine for something that isnt end user facing
<azonenberg>
i.e. this is a testbed only
<azonenberg>
i'd socket the fuse if it was something i ever expected to blow in real life
<Degi>
My ECP5 dev board has a socketed 5 amp fuse on it .-. Like WTF at 5 amp everything is gonna be toast...
<electronic_eel>
Degi: a lot of power supplies also won't be able to blow such a fuse in a reasonable amount of time
<azonenberg>
electronic_eel: you're getting ahead of me, fusing/reverse protection checks at the input is like 20 lines down the checklist from where i am right now :p
<azonenberg>
(have you looked at the checklist?)
<azonenberg>
i got pulled away to work on some other stuff, i'm still on checking power/voltage/tolerance ratings on parts
<electronic_eel>
I haven't looked at your checklist, just browsing through the circuit in a non-preplanned way
<azonenberg>
i have a copy in the repo for the characterization board that i'm checking off as i go through my own signoff review
<azonenberg>
at this point i'm also picking exact components for each passive, making sure i either have them in my lab inventory or that they're in my digikey cart, drawing footprints if i don't have them yet, etc
<electronic_eel>
yeah, probably makes sense to work off such a list on a bigger project. the afe would probably still come out ok without it, but with a bigger project it is a must
<azonenberg>
I've cut my rate of respins/rework massively down by following this signoff process religiously on all of my projects
<electronic_eel>
also if you are working alone on a project and don't have an irc channel for peer review
<azonenberg>
as you can see the list is mostly targeted towards high speed digital and is light on the analog/RF but i expect mistakes made on this scope project will end up in the list :p
<azonenberg>
almost every item on that list is the result of a mistake i either made or nearly made on a board, lol
<azonenberg>
anyway the component selection is gonna take a bit as i dont currently have an online inventory tracking system, i just have a bunch of plastic antistatic bins with passives sorted by decade
<azonenberg>
so i need to paw through them and check how much of what i have :p
<Degi>
Does the list contain "check amplifier feedback polarity" yet
<electronic_eel>
yeah, I have a bunch of bags too. I have planned to change that to small containers, but didn't have the time to do it yet
<azonenberg>
degi: let me add that. Lol
<Degi>
I have something where you can put dividers in. Sorted caps and resistors in decade steps, though some caps (1,10 nF) have been getting very full.
<Degi>
I do have several cubic centimeters of 1 nF caps lol
<Degi>
Lol is that from a mistake with an electrolytic? "Polarized components specified in schematic if using electrolytic caps etc"
<azonenberg>
I think that was just best practices i wrote down from memory
<azonenberg>
i have a whole cabinet full of these bins of various sizes
<azonenberg>
i have some of the larger sizes with them split off in half with dividers
* Degi
just hopes that the ESD diodes are good enough
<azonenberg>
one decade per half of bin
<azonenberg>
so <0.1 uF, 1 uF in the first cap bin
<azonenberg>
10, 100 in the next
<azonenberg>
etc
<Degi>
Some automated storage would be neat
<azonenberg>
actually no i have <0.1 uF and 0.1 uF decades in the first bin
<Degi>
My space is somewhat limited to 18 m² (including bed, clothing shelf)
<azonenberg>
anyway then within each bin i have parts unsorted in digikey/mouser bags
<electronic_eel>
Degi: automated is hard to do for such small stuff
<azonenberg>
or reels, for larger quantities
<Degi>
electronic_eel: If you have reeled SMD parts it could be done
<Degi>
Tape cutter on a servo, networked RPi on it lol
<electronic_eel>
but will take lot's of space you don't have
<Degi>
Yes..
<Degi>
Hmm could a battery-powered wifi mainboard for the scope be useful? That'd allow ground-isolated measurements. (Like if you want to measure the current on the 2 kV rail of a laser system)
<azonenberg>
And my whole lab is... i think 37 m^2
<Degi>
Nvm the lan port has at least 2 kV of isolation anyways.
<azonenberg>
Degi: i would rather make a fiber isolated probe
<azonenberg>
for that
<Degi>
Hm yes that makes sense
<Degi>
There's like fiber-optic probes using some magnetooptic effect to sense current, like a hall sensor
<electronic_eel>
isolated probe? wouldn't a isolated channel be easier?
<azonenberg>
lots of possibilities there
<azonenberg>
Point is, its not a priority right now
<Degi>
Well if you can isolate a channel to survive a few hundred V/µs
<Degi>
Hm right
<azonenberg>
on the BFS, it will actually be easy because the channels will be basically independent of each other
<azonenberg>
and just share refclk and stream adc data over serdes
<azonenberg>
so i could have SFPs on the mainboard between the channels
<azonenberg>
and make a fully isolated scope with separate ground reference per channel
<electronic_eel>
yes, as I suggested earlier
<Degi>
Dont they have like 10 ADC streams so 4 QSFP's?
<azonenberg>
no i would have an FPGA on each channel in the isolated domain
<azonenberg>
then have 10GbE from each channel to the root fpga
<Degi>
Okay
<azonenberg>
Which would have 40 or 100G to the rest of the world
<Degi>
Hm not 10 GbE though, right? (Like ethernet doesn't make much sense between two FPGAs)
<azonenberg>
i need an fpga per channel in order to have enough io pins for the multiple sodimms of DDR3 that i would need to buffer the 120 Gbps of ADC data :p
<azonenberg>
so putting that whole fpga in an isolated domain isnt much work at that point
<Degi>
120 Gbps per channel?
<azonenberg>
12 bits * 10 Gsps
<Degi>
Hmm riight
<miek>
speaking of parts storage.. i just got a few boxes like this: https://i.imgur.com/LZXctE8.jpg - should be nice for fiddling with matching networks :)
* Degi
thinks of putting a solar cell onto a fiber-optic cable
<azonenberg>
this is a $3000 ADC and will probably be paired with like a $1K FPGA
<azonenberg>
Per channel
<Degi>
Oof ok
<azonenberg>
There's a reason i haven't even touched that project yeet
<Degi>
Lol that storage looks rly fancy
<azonenberg>
i want to make as many mistakes as i can on the entry level stuff :p
<Degi>
1 k FPGA lol, that thing gotta be reaaaly nice
<azonenberg>
well i mean i'd need 16x 10G SERDES or thereabouts
<azonenberg>
to keep up with all of the JESD204 links
<azonenberg>
So you'd be looking at probably an XC7K325T or similar
<azonenberg>
maybe bigger, depends on if i have any serdes left over for talking to the root fpga after the ADC uses a buttload of them
<azonenberg>
yeah i'd need bigger, the AD9213 has 16 JESD204 links at up to 16 Gbps
<Degi>
Hmm so the plan is a board with ADC, FPGA, RAM and SPF's?
<azonenberg>
Potentially. its too far out for me to even have a serious design yet
<azonenberg>
so it looks like if i want transceivers left over for talking to the root fpga plus the ADC
<azonenberg>
i'd be looking at more like an XCKU040
<Degi>
Kinda find it funny how all the ADC's say "low power dissipation"
<azonenberg>
Which is a $1.5 - 2.2K FPGA @ digikey qty 1 pricing depending on speed grade and package
<azonenberg>
oh, and you need full vivado to dev for it
<azonenberg>
i fully expect R&D, board spins, software, tools, and hardware for building a single prototype of that scope to cost me something in the range of 50 kUSD
<Degi>
The foss toolchain is probaby ready till then lol
<Degi>
Hm oof
<azonenberg>
obviously much less per unit if i make a bunch of them
<azonenberg>
but that's roughly what i'm expecting the initial investment to be
<azonenberg>
the plan is to not even touch it until the lower end stuff is working, debugged, and i'm selling enough of them to fund development of higher end gear
<azonenberg>
i have the resources right now to fund the entry level scope and probe out of pocket, at least for prototyping. may want to crowdfund a production run to get volume discounts
<azonenberg>
but i expect to use proceeds from sale of those units to fund development of the higher end gear
<Degi>
Hm I think I could get one entry level scope prototype with the money I have lol.
<azonenberg>
and as i'm not a fan of vaporware, i wouldn't want to launch a crowdfunding campaign until i have *working* prototypes that are fully debugged, polished, and production read
<azonenberg>
the crowdfunding would just be to get the funds to build several hundred to thousand units and get volume discounts on parts
<azonenberg>
the alternative would be to pay for the first 10 or so out of pocket, hold onto them and sell them gradually, then use the profit from that to bootstrap a larger run, etc
<azonenberg>
i'm not a businessman, i'm a scientist. i'm not good at that sort of stuff
<azonenberg>
i just know that i want everything open source and i don't want to take any kind of outside funding that would cause me to compromise the core principals or be forced to ship an incomplete system before it's ready for use
<azonenberg>
it will be done when it's done
<azonenberg>
no corner cutting, no rushing, no profit-driven design choices
<Degi>
Hmm what do you think about things like google summer of code? I kinda thought about developing the PCIe code with the help of that money, I'm not sure about restrictions they place. It mostly seems they want a right to use the software forever, but I didn't read much more.
<azonenberg>
might be plausible for protocol decodes or similar, but not hardware
<azonenberg>
i want to keep as much of that in house as possible for the moment
<Degi>
Yes only software
<azonenberg>
since part of the goal of the project is for *me*, personally, to pick up the analog skills to make higher end stuff
<Degi>
I just read that you can get 5 k from google there, as long as they don't interfere with anything else, this would be good funding for projects.
<azonenberg>
Might be worth looking at for *next* year. This summer is way too soon
<azonenberg>
i want to get a steady crew of developers, not just me, a lot more documentation and general infrastructure, more people using it, etc
<Degi>
Yes, I mean its for students only too
<azonenberg>
my point exactly
<electronic_eel>
Degi: I think you need to have a project org that is approved for GSoC first
<azonenberg>
it's not mature enough i'd be willing to turn a student loose on it yet
<Degi>
Lol I'm a student
<azonenberg>
the amount of infrastructure, code review, etc involved in supporting a full time person working on it is more than i have to spare right now
<Degi>
Anyways I didn't mean GSoC with this project. I was specifically talking about the PCIe interface thingy I wanted to do (not the part directly related to this project though, I'd do that with symbiflow)
<Degi>
Ah you mean to hire people
<electronic_eel>
ah, and symbiotic is approved for GSoc?
<azonenberg>
well a GSoC student is effectively hired full time or close to it, right? in terms of the amount of work they expect to put in?
<Degi>
Yes 30+ hours per week. Not sure if its worth it
<azonenberg>
i'm talking about how much time it would take ME, in terms of hand-holding, answering questions, reviewing commits, etc
<Degi>
Ah right
<azonenberg>
in order to keep up with that much new code being added that quickly
<azonenberg>
i can't do that
<azonenberg>
we'd need several experienced, active developers to share the load as well as some "getting started" developer documentation
<azonenberg>
we have none of that right now
<azonenberg>
dont get me wrong, i would love to get to that point
<azonenberg>
But now is not that time
<Degi>
Yes I didn't suggest putting this project to GSoC either
<azonenberg>
I think it's a good idea, longer term
<Degi>
I more of meant that I develop the PCIe interface (like getting data thru PCIe into RAM) and maybe if that works out, I can better help fund this project with the resulting money.