<azonenberg>
normally you want fairly fast, but not more than about 4C/sec to avoid thermal stress cracking of the joints
<Degi>
Hm the dip was me trying to make the plateau for 90 seconds
<Degi>
At 150-175 C
<Degi>
Oh also add like 20 C to everything lol
<azonenberg>
Was this a high thermal mass board?
<Degi>
Hm that too but the sensor wasnt on the board which is the whole problem
<azonenberg>
soak periods are in my experience not normally needed, i prefer a ramp-to-spike profile.
<Degi>
Hm okay
<Degi>
Kinda worried about flux boiling off too fast and components moving around
<azonenberg>
soaks might make sense on a really heavy board, or if the natural ramp rate of your oven is too fast
<Degi>
But this one looks perfect, one IC looks like it misses a bit under the ground pins but I think theyre connected
<azonenberg>
but normally i've found they don't really help. ramp-to-spike is a valid process and it's generally simpler to do
<Degi>
Hm its like 110*60 cm with 2 layers of copper pour
<Degi>
Hm okay
<Degi>
Just turn it on, wait till solder melts, turn it off and then take board outside? Or leave it in the oven?
<Degi>
Hm I think my cooling may be like 10 °C/s
<azonenberg>
That's a bit too fast. How did you cool? and where is your sensor?
<Degi>
Kinda messed that up
<azonenberg>
(clearly isnt super accurate lol)
<Degi>
The sensor is floating somewhere in the oven nearby the pcb (like 5 cm away) lol
<Degi>
Well I took the pcb + grille out of the oven and maybe blew some air over it lol
<azonenberg>
what i normally do to cool is open the oven door
<Degi>
Hm yeah shouldve done that
<azonenberg>
and rely on the oven's thermal mass to provide some inertia to slow down the cooling
<azonenberg>
once solder has visibly solidified i'll pull the tray out a bit to get faster cooling
<Degi>
Also genius me thought "how cool would it be if the FPGA provided the clock for the µC" and now I cant program it till some headers arrive to connect it to the fpga
<Degi>
Ah yes
<Degi>
but I blew some air over it, of course it was solid before I moved it
<Degi>
Solderiing the SMAs to the FPGA board will be such a PITA, I think it has like 4 layers of copper fill or so
<monochroma>
pre-heater
<Degi>
0402s were so hard to place and ICs very easy
<Degi>
The 0402s didnt rly stick to the paste
<azonenberg>
i normally push them down a little bit
<Degi>
Yes I did that too
<Degi>
They kinda went sideways and then turned over
<azonenberg>
ok so, re the active probe, my thought is to have a 20:1 input divider and a 2:1 noninverting gain configuration on the amplifier
<Degi>
Well I managed them to get all crookily in place but they look very goodly aligned now
<azonenberg>
for a net 10:1 attenuation?
<Degi>
Hm yes
<azonenberg>
or do we want to do bigger on the attenuator
<Degi>
20:1 better than 10:1 in terms of loading...
<azonenberg>
say 40:1 then 2:1
<Degi>
Id prefer bigger because less loading but I guess that also makes more noise? idk
<_whitenotifier-9>
[scopehal] azonenberg 5fe8a1b - Merge pull request #104 from randomplum/sda3010 LeCroyOscilloscope: compatibility fixes for SDA3010
<_whitenotifier-9>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JfCi0
<_whitenotifier-9>
[scopehal] azonenberg c91412e - Added new "memory" category for protocol decodes
<_whitenotifier-9>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JfCiE
<_whitenotifier-9>
[scopehal-apps] azonenberg acd5045 - Added menu support for "memory" decode category
<_whitenotifier-9>
[scopehal] azonenberg opened issue #105: DDR3 decode: allow CS# to not be specified (assume chip is always selected) - https://git.io/JfCib
<_whitenotifier-9>
[scopehal] azonenberg labeled issue #105: DDR3 decode: allow CS# to not be specified (assume chip is always selected) - https://git.io/JfCib
<_whitenotifier-9>
[scopehal] azonenberg opened issue #106: DDR3 decode: support BA pins - https://git.io/JfCiA
<_whitenotifier-9>
[scopehal] azonenberg labeled issue #106: DDR3 decode: support BA pins - https://git.io/JfCiA
<_whitenotifier-9>
[scopehal] azonenberg labeled issue #107: DDR3 decode: maintain state of banks and complain when invalid activity is seen - https://git.io/JfCP0
<_whitenotifier-9>
[scopehal] azonenberg opened issue #107: DDR3 decode: maintain state of banks and complain when invalid activity is seen - https://git.io/JfCP0
<_whitenotifier-9>
[scopehal] azonenberg labeled issue #108: See if we can unify DRAM protocol decodes to enable measurement/code commonality across DDRx generations when possible - https://git.io/JfCPQ
<_whitenotifier-9>
[scopehal] azonenberg labeled issue #108: See if we can unify DRAM protocol decodes to enable measurement/code commonality across DDRx generations when possible - https://git.io/JfCPQ
<_whitenotifier-9>
[scopehal] azonenberg opened issue #108: See if we can unify DRAM protocol decodes to enable measurement/code commonality across DDRx generations when possible - https://git.io/JfCPQ
<_whitenotifier-9>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JfCPj
<_whitenotifier-9>
[scopehal-apps] azonenberg d49728b - Added menu item for protocol measurements
<_whitenotifier-9>
[scopehal] azonenberg pushed 2 commits to master [+2/-0/±5] https://git.io/JfCXe
<_whitenotifier-9>
[scopehal] azonenberg 90554cc - Added DRAM Trcd measurement
<azonenberg>
So i think i'm going to be overhauling the measurement system soonish. Starting to run into situations where i really want to unify measurements and decodes
<azonenberg>
This has been planned for a long time but i think it needs to happen sooner
<azonenberg>
in particular, proper min/max/avg/stdev statistics on measurements are dependent on having per-UI rather than per-waveform measurements
<azonenberg>
and you pretty much get the ability to plot a measurement as a waveform for free that way
<_whitenotifier-9>
[scopehal] azonenberg opened issue #109: Add some kind of DDR timing checker - https://git.io/JfC1c
<_whitenotifier-9>
[scopehal] azonenberg labeled issue #109: Add some kind of DDR timing checker - https://git.io/JfC1c
<_whitenotifier-9>
[scopehal] azonenberg pushed 1 commit to master [+2/-0/±3] https://git.io/JfC14
<_whitenotifier-9>
[scopehal] azonenberg 7630af5 - Initial version of DRAM Trfc measurement
<_whitenotifier-9>
[scopehal-apps] azonenberg 48c1635 - OscilloscopeWindow: properly catch exception when opening a nonexistent file. Fixes #83.
<_whitenotifier-9>
[scopehal-apps] azonenberg closed issue #83: glscopeclient: Crash when trying to load a scopesession that doesn't exist - https://git.io/Jvix5
<_whitenotifier-9>
[scopehal-apps] azonenberg closed issue #1: Remove legacy scopeclient app when it's fully replaced by glscopeclient - https://git.io/JfCH9
<_whitenotifier-9>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±8] https://git.io/JfCQZ
<_whitenotifier-9>
[scopehal] azonenberg d3bb8cb - Removed lots of dead functions from old Cairo rendering API. See #30.
<_whitenotifier-9>
[scopehal] azonenberg pushed 3 commits to master [+0/-2/±15] https://git.io/JfC7v
<_whitenotifier-9>
[scopehal] azonenberg b0ad2dd - Removed more unused stuff from ChannelRenderer
<_whitenotifier-9>
[scopehal] azonenberg 9c1967f - Continued removing dead ChannelRenderer code. See #30.
<_whitenotifier-9>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±4] https://git.io/JfC7F
<_whitenotifier-9>
[scopehal-apps] azonenberg cddb929 - Removed all references to obsolete AnalogRenderer class. Moved PickStepSize into WaveformArea.
<azonenberg>
wooooo it's moving
<azonenberg>
the probe dummy is in japan now
<azonenberg>
it FINALLY left shenzhen
<azonenberg>
After ten days
<azonenberg>
also at this point i've purged all of the ChannelRenderer garbage that wasn't actually being used. What remains is the TextRenderer class, so I just need to fold that back into the ProtocolDecoder class
<azonenberg>
since it's now only two functions that are intimately involved with the host class, it only makes sense to unify it
juli964 has joined #scopehal
<monochroma>
azonenberg: ah right, i seem to remember testing this before right after you made that change, but apparently didn't report any update
<monochroma>
will test again
<azonenberg>
Yeah i'm trying to go through old tickets and deal with them
<monochroma>
what i seem to remember was this was a bit of an annoying issue, in that the UI can load, but until it actually trys to setup the open GL context (aka, you must current be connected to or emulating a scope) we won't know if the system has the GL version
<azonenberg>
yeah
__builtin_trap is now known as smkz
<_whitenotifier-9>
[scopehal] azonenberg pushed 1 commit to master [+0/-32/±68] https://git.io/JfCAZ
<azonenberg>
well, that was painful and time consuming. But worth every minute
<azonenberg>
lain, monochroma: so i have some more refactoring i want to do (scopehal:3, scopehal:83) to unify protocol decodes and measurements
<azonenberg>
got a few mins to brainstorm how this will work?
<lain>
uhhh possibly
* lain
looks
<azonenberg>
So basically the idea idea, we want to be able to trend measurements over time / over the course of an acquisition
<azonenberg>
We want to be able to plot histograms of measurement values
<azonenberg>
the ideas is*
<azonenberg>
And we want to be able to collect stats
<azonenberg>
I think the best way to implement this is to define a measurement as a protocol decoder that outputs one point per UI or feature of interest in the waveform
<azonenberg>
which can either be graphed as a waveform in its own right, or displayed on the bottom via a summarization filter that converts an analog waveform to a scalar
<azonenberg>
So for example "average voltage" would simply be a summarization filter that you apply to a waveform
<azonenberg>
"rise time" would be a filter outputting one point per rising edge, which you can then either plot or apply min/max/avg/stdev filters to
<azonenberg>
The question is how to make this work cleanly in the UI
<azonenberg>
my first thought is to have all measurements output an analog waveform which is graphed (but can be hidden)
<azonenberg>
i.e. they'll just be considered protocol decodes
<azonenberg>
then have some means of displaying measurements in the bottom window
<azonenberg>
in a tabular fashion, with channels on columns and summarization filters in rows
<azonenberg>
the default will be one row, for average
<lain>
hmmm
<azonenberg>
but you can then create rows for stdev, min, max, and maybe others
<lain>
yeah
<lain>
I like that
<azonenberg>
So how would you actually trigger this in the UI?
<azonenberg>
all of the filters could be done just like a protocol decode
<azonenberg>
so let's suppose you have ch1 and rise(ch1) as two displayed channels
<azonenberg>
you want to see avg(rise(ch1)) as a scalar
<azonenberg>
What would the UI for this look like?
<azonenberg>
right click rise(ch1) and click "summarize"?
<lain>
hmmmm
<azonenberg>
if the measurement window is already visible i want you to be able to drag a channel onto it
<azonenberg>
but there's a lot of UI around channel dragging (reordering etc) i have yet to implement
<azonenberg>
So i'm thinking "summarize" will show the measurement footer at the bottom of the waveform group if it's not already visible
<azonenberg>
add a column for the channel you selected
<azonenberg>
and, if there are currently no rows, add a row for average
<lain>
I think that works, I just don't like the term "Summarize" for this
<azonenberg>
What would you call it?
<lain>
but I'm struggling to come up with a better term :P
<azonenberg>
Basically, i think in the end what we will have is two kinds of processing operations on a signal
<azonenberg>
one, currently called "protocol decode", which is a graph node that inputs one or more waveforms and outputs a waveform
<azonenberg>
where a waveform is defined as a sorted list of (time, duration, value) tuples, with the value being any complex or scalar type
<azonenberg>
and one, somewhat analogous to what we currently call a "measurement" which is a sink node that inputs one or more waveforms and outputs a scalar
<azonenberg>
"statistics"?
<lain>
Scalar Measurements?
<azonenberg>
that sounds confusing
<azonenberg>
statistics sound a lot more obvious what it means
<lain>
hm yeah
<lain>
I like statistics
<azonenberg>
and then most of the current measurement functions would go in a "measurement" category under protocol decodes
<azonenberg>
which will probably be renamed "filter" or something at some point
<azonenberg>
at least in the UI
<lain>
:3
<azonenberg>
lain: is it reasonable for a stat to only take one input all the time? and have no configuration?
<azonenberg>
i.e. you can do whatever you want to the measurement but the stat is just a reduction function on a vector of values that can't be modified
<lain>
hm
<lain>
having parameters could be handy, like if you wanted to apply a scale factor
<azonenberg>
that's a vector-to-vector transformation though
<azonenberg>
aka a filter
<azonenberg>
the only vector-to-scalar transforms i have in mind at the moment are min, max, mean, median, and stdev
<azonenberg>
at some point we will have a histogram transform too but that will be different as it's not outputting a scalar
<azonenberg>
so i think it will just be a filter that has a special display mode, like eye patterns or FFTs
maartenBE has quit [Ping timeout: 272 seconds]
maartenBE has joined #scopehal
<lain>
alright
<azonenberg>
Hmmm there seems to be a significant performance regression somewhere and i can't find it
<_whitenotifier-9>
[scopehal] azonenberg pushed 1 commit to master [+8/-0/±5] https://git.io/JfWTn
<_whitenotifier-9>
[scopehal] azonenberg b0ef1dd - Initial implementation of statistics
<_whitenotifier-9>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±6] https://git.io/JfWTW
<_whitenotifier-9>
[scopehal-apps] azonenberg 529561c - Initial support for statistics
<azonenberg>
so right now, talking to my hdo9k with all channels enabled, glscopeclient is happily churning away at ~10 WFM/s with 200k points per channel
<azonenberg>
i add an ac coupling decoder and it's still about the same speed
<azonenberg>
turn on stats for the main channel and still the same
<azonenberg>
aaand i cant reproduce
<azonenberg>
lol
<azonenberg>
or wait no, it just froze up. So it seems the app has to be open for a while
<azonenberg>
Seems like there's a memory leak. But this is made worse by the fact that glscopeclient is hanging during shutdown if i enable stats
<azonenberg>
So i can't actually see output from leaksanitizer :p
<_whitenotifier-9>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±5] https://git.io/JfWkM
<_whitenotifier-9>
[scopehal-apps] azonenberg 8f47d72 - Several bug fixes surrounding new history window. Fixed slow Cairo rendering of grid on channels with a large DC offset.
<azonenberg>
i still have to port all of the old measurements over to the new unified architecture, "period" is the only one i have so far
<azonenberg>
and right now you can't reconfigure the stats table, it always shows min/avg/max
<azonenberg>
There's no stdev or median stat, and no way to clear integrated stats (there's an API for doing it, but no UI for calling that function)
<lain>
azonenberg: looks good
<azonenberg>
the nice thing is that you will be able to do this to ALL measurements once i finish the refactoring
<azonenberg>
even things like "DRAM Trcd"
<miek>
nice
<azonenberg>
So at this point the architecture will be fully unified and protocol decodes, math functions, and measurements will have no difference whatsoever
<azonenberg>
at some point i need to sit down and update the manual, it's getting a bit out of date now
<azonenberg>
I have to figure out how to do the eye pattern measurements in the new architecture