<_whitenotifier-1>
[stm32-cpp] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/J1y8n
<_whitenotifier-1>
[stm32-cpp] azonenberg b2170cd - Initial flash memory controller support for STM32F031. Fixed regression causing compile failure on STM32F031.
Degi_ has joined #scopehal
Degi has quit [Ping timeout: 268 seconds]
Degi_ is now known as Degi
someone-else has joined #scopehal
someone-else has quit [Quit: Connection closed]
someone-else has joined #scopehal
<someone-else>
azonenberg: re: probe deembedding and trigger
<someone-else>
I think it should be possible to correct trigger jitter caused by trigger/main channel response mismatch in glscopeclient even if the scope itself doesn't support probe deembedding
<someone-else>
provided that acquired waveform extends far enought in both directions from the trigger point, difference in time where it crosses the trigger threshold could be calculated (provided it's less than the input signal period) and the (deembedded) waveform shifted accordingly
<someone-else>
* difference in time between source and deembedded waveforms
<electronic_eel>
someone-else: i think that could work. but only under the premise that both the deembedded waveform and the output of the probe hit the same trigger points
<electronic_eel>
if you only want to capture signals with a strong overshoot, you set the trigger level into the strong overshoot region. if you now got a weak overshoot signal, the probe amplifies that frequency then the raw signal could trigger while the deembedded signal wouldn't
<electronic_eel>
the other way round would be even more problematic of course
<someone-else>
I agree
<someone-else>
though I was thinking more about gigabit serial data links where you would typically trigger at zero or something
<someone-else>
also, if serial data pattern is a prbs, a proper pattern trigger would also solve this
<someone-else>
but not all scopes have it
<someone-else>
although maybe not - we don't have to adjust timing at the specific trigger level, choosing an arbitrary level present in both waveforms might be enough
<someone-else>
since we just aim to reduce the deterministic jitter
<electronic_eel>
how do pattern triggers work? do they trigger on a specific chain of analog windows that the signal must hit into? or is it a traditional level trigger followed by something like a digital protocol trigger?
<someone-else>
I imagined a trigger which always triggers at the same point in the PRBS
<someone-else>
this would reduce deterministic trigger jitter
<electronic_eel>
with "same point" you mean bit position within the prbs sequence, and then ontop of that, at a precise voltage level in the transition from the previous value of the prbs sequence to the next, right?
<someone-else>
bit position
<electronic_eel>
so this could be done by a level trigger followed by a prbs protocol trigger
<someone-else>
I think so, yes
<someone-else>
though if protocol decoding is done after acquiring a waveform and not a part of the hardware trigger, a lot of waveforms would have to be discarded
<azonenberg>
someone-else: Yes. i want to implement better post-triggering to do things like "trigger on all pcie tlp's but then only display ones with a bad checksum"
<azonenberg>
as far as reducing jitter, the pico driver actually already implements sub-sample trigger interpolation
<azonenberg>
just simple linear but it greatly improved results
<electronic_eel>
azonenberg: you showed calibrating the voltage regulator of your openram test jig on twitter. did you also try it with some load on it, like 100mA or so to see if it is also stable under load?
<azonenberg>
It's not a voltage regulator, it's a DAC driving a power opamp in unity gain configuration
<azonenberg>
This was with no chip connected, the actual test chip will probably pull single digit mA
<azonenberg>
I will be doing tests with the chip connected next
<azonenberg>
As well as using the RP4030 to measure noise on the rail while it's running
<electronic_eel>
ah, ok, if you expect just single-digit currents then i guess it won't matter much. with more current stuff like heating and internal resistances could shift the values a bit
<azonenberg>
Yeah
<azonenberg>
The test chip is a... 256 x 32 bit, I think? SRAM of which 24 bits are tied off to constants and 8 are broken out to I/O pads
<azonenberg>
I/O is a separate 3.3V rail
<azonenberg>
the variable rail is only powering the 1.8V digital core
<azonenberg>
The goal is to test timing and data retention across voltage corners
sorear has quit [Remote host closed the connection]
_florent_ has quit [Remote host closed the connection]
mxshift has quit [Ping timeout: 246 seconds]
esden has quit [Ping timeout: 246 seconds]
elms has quit [Ping timeout: 250 seconds]
JSharp has quit [Ping timeout: 250 seconds]
Famine_ has joined #scopehal
Famine- has quit [Ping timeout: 256 seconds]
_florent_ has joined #scopehal
sorear has joined #scopehal
mxshift has joined #scopehal
JSharp has joined #scopehal
esden has joined #scopehal
elms has joined #scopehal
<_whitenotifier-1>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±8] https://git.io/J1QbB
<_whitenotifier-1>
[scopehal-apps] azonenberg 9bf3455 - Initial implementation of OpenCL renderer now produces a dummy fill pattern on screen
<_whitenotifier-1>
[scopehal-apps] azonenberg 4397e6f - OpenCL renderer now takes all arguments needed to render a dense packed analog waveform. Doesn't display anything useful.
<azonenberg>
Soo I think i've found some potential bad pointers in the renderer thanks to oclgrind
<azonenberg>
With any luck i can port the fixes back to the compute shader renderer and fix some of the hangs/crashes we've been having