azonenberg changed the topic of #scopehal to: libscopehal, libscopeprotocols, and glscopeclient development and testing | https://github.com/azonenberg/scopehal-cmake, https://github.com/azonenberg/scopehal-apps, https://github.com/azonenberg/scopehal | Logs: https://freenode.irclog.whitequark.org/scopehal
<_whitenotifier-3> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/fjnas
<_whitenotifier-3> [scopehal] azonenberg 2e8c836 - AnalogRenderer: enlarge step size list so we can handle high voltages better
<_whitenotifier-3> [scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/fjnaG
<_whitenotifier-3> [scopehal-cmake] azonenberg f3c0c64 - Updated submodules
<azonenberg> avl: can you pull and build latest and confirm that the Y axis no longer looks all blurred out?
<azonenberg> The voltage-out-of-range bug is still there but you should see a sane looking y axis with like a +/- 100V range or so
<azonenberg> Wrong data, but correct display of the wrong data :p
<sorear> float div-by-zero are silent unless you have feenableexcept(FE_DIVBYZERO) somewhere
<azonenberg> ah ok
<azonenberg> so its probably integer then
<sorear> otherwise it just produces INF
<whitequark> azonenberg: nope, can't get your PLL to lock
<whitequark> or well, i can get it to lock just fine to extremely regular data
<whitequark> but the moment it encounters something that's not a repeating pattern it breaks
<sorear> you need different phase detectors for CDRs
<whitequark> what?
<azonenberg> How long are the run lengths in your test data?
<whitequark> azonenberg: it's an RLL(1,3) code, so at most 3 bit intervals without a transition
<azonenberg> I've tested with 8B/10B K28.5 D16.2 patterns which have fairly long periods between transitions during the commas
<whitequark> and at least one
<azonenberg> up to 5 intervals without a transition
<azonenberg> as well as a PRBS-31 random bit stream
<azonenberg> i think the bigger question is how much jitter there is in the data?
<azonenberg> You might need larger corrections if there's a lot of jitter
<whitequark> about 10-20% of bit time, I think
<whitequark> depending on medium quality
<sorear> did the testing simulate jitter, and does the frequency spectrum of jitter matter?
<azonenberg> 0.2 UI of jitter doesnt sound excessive for my PLL to lock to
<azonenberg> So, can you do this for me? Make a graph with X axis being sample number
<azonenberg> and lines for...
<azonenberg> * calculated phase error
<azonenberg> * PLL NCO period
<azonenberg> * measured actual unit interval (delta from transition to transition, divided by number of bits in that chunk of data)
<whitequark> uhh, i don't know the number of bits in that chunk of data
<whitequark> i don't have a reference decoder.
<whitequark> i know the jitter bounds because i made a histogram
<azonenberg> In that case just do the actual edge-to-edge time plotted as points (not lines)
<whitequark> ok, i can do that
<azonenberg> alternatively, find the global average bit time from the histogram
<azonenberg> and divide the UI by 2 or 3 if the edge-to-edge time is way big
<whitequark> azonenberg: so, for reference, here's a histogram https://imgur.com/a/8oSUCpz
<azonenberg> Ok, so in that case what i want to you to do is find the center of the first bin
<azonenberg> the first peak*
<azonenberg> So about what, 4.5 us or so?
<whitequark> yeah, 4.55 us
<azonenberg> Then divide the edge-to-edge time by that, round to nearest integer
<azonenberg> use that as your estimate of how many bits are in the delta
<whitequark> ok
<azonenberg> Then divide the edge-to-edge time by the number of bits
<azonenberg> and use that as your calculated "actual" length of that bit
<azonenberg> Basically the idea here is just to get some metrics to see what your PLL is doing wrt the theoretical bit clock
<whitequark> can do
<whitequark> yeah, i have some of those graphs
<whitequark> azonenberg: found one issue
<whitequark> the estimate should be using one *half* of the smallest encountered edge to edge time
<whitequark> azonenberg: here's an overview https://imgur.com/a/L8fCG7W
<whitequark> the grey line is 1 UI
<whitequark> azonenberg: oh *facedesk*
<whitequark> azonenberg: the change in phase and the change in period should have different signs
<whitequark> now it works *perfectly*
<whitequark> laser guided lock
<azonenberg> show me the graph :)
<whitequark> azonenberg: https://i.imgur.com/IWXwF5y.png
<whitequark> the middle legend should be saying "phase error" actually
<azonenberg> Very nice
<azonenberg> have you tried demodulating the data? is it actually giving you valid results?
<whitequark> not yet
<azonenberg> Given how stable the edge-to-edge time plot is, i think your could get slightly more stable wrt the error term
<azonenberg> you're peaking at like 0.35 UI of jitter
<azonenberg> and the histogram makes it look like the data doesnt actually have that much
<azonenberg> Try making smaller corrections in phase and/or frequency and see if you get less jitter
<whitequark> yeah, give me a sec
<whitequark> azonenberg: so here's one problem: https://imgur.com/a/8XYQStU
<whitequark> i have no idea why it just decided to unlock
<sorear> mfm?
<whitequark> yes
<sorear> it is very weird that the recovered data (red) is staying absolutely horizontal even after the NCO period (green) enters an instability region
<sorear> i presume, I am misinterpreting the red curve
<sorear> er, is "UI" in the red curve increments of the recovered clock or of the true clock?
<whitequark> true
<whitequark> UI is specified on command line for generating this graph
<azonenberg> It looks like your error is getting >0.5 UI
<whitequark> that axis is actually wrong
<azonenberg> And it's losing track of the sign of the error
<whitequark> let me fix it
<sorear> cute demo idea, maybe not diagnostically useful: run perturbed PLLs at regular intervals, see whether the perturbation grows or shrinks, plot Lyapunov exponent vs. time (or vs. data?)
<whitequark> azonenberg: ok, the axis IS correct
<whitequark> but only by accident
<whitequark> azonenberg: anyway, what do i do in that case?
<whitequark> azonenberg: oh yeah, i figured out *when* it happens
<whitequark> after the end of each sector there is a bunch of noise
<azonenberg> So the PLL isn't broken, it's GIGO?
<azonenberg> Best option i can think is to add a lock detector (if error magnitude exceeds some threshold for a couple UIs in a row, declare lock lost)
<azonenberg> and just ignore data if lock is lost
<azonenberg> you'll get a few bits of garbage at the end of the sector that you can hopefully ignore when upper protocol layer logic detects the sector is over
<whitequark> azonenberg: hmmm
<whitequark> that could work
<whitequark> azonenberg: there's another problem
<sorear> was "clone the algorithm used in real floppy controllers" ever an option? i forget
<whitequark> it suddenly *un*locks when it encounters the preamble
<whitequark> sorear: it's analog
<sorear> PLLs generally are, yes?
<whitequark> well what am i gonna do, write DSP code?
<sorear> but I'm not sure if PLLs were even a thing in 80s PLLs
<whitequark> sorear: the 80s FDC used a VCO but it was also tuned to work with a specific encoding
<sorear> i'm not very awake, sorry, s:2nd/PLLs/VLSI/
<sorear> mm
<whitequark> azonenberg: so i found something that might be useful
<whitequark> it looks like each phase discontiguity sends the PLL into a spiral of death
<whitequark> hm, no, not each
<sorear> something else I'm thinking about (before falling asleep): PLLs are designed to work at extremely low latency, but the floppy problem doesn't require that. is it possible to do some kind of maximum a posteriori clock recovery, given the entire flux trace and a prior for the jitter?
<whitequark> sorear: the floppy problem does require that.
<whitequark> you need low latency to write because you're looking for the sector header and switching to writing once you've found it
<sorear> ah, I thought writing to standard-format disks was out of scope
<whitequark> i don't know if i'll ever implement it
<whitequark> but i don't want to implement a shit PLL that *can't* do it
<azonenberg> whitequark: flipped sign?
monochroma has joined #scopehal
<_whitenotifier-3> [scopehal] azonenberg closed pull request #65: some changes in the upper LeCroyOscilloscope class for Siglent compat - https://git.io/fjncK
<_whitenotifier-3> [scopehal] azonenberg pushed 7 commits to master [+26/-0/±41] https://git.io/fjnwk
<_whitenotifier-3> [scopehal] azonenberg 9c196a1 - Merge pull request #65 from azonenberg/Siglent-WIP some changes in the upper LeCroyOscilloscope class for Siglent compat
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<azonenberg> Error_404: sooo some of your chances borked the base class but i'm not quite sure how
<azonenberg> getting segfaults i missed in original testing
<azonenberg> Investigating...
<Error_404> hrm, got a stack trace?
<azonenberg> num_sequences in AcquireData() is corrupted
<azonenberg> investigating
<Error_404> mk. I'll be getting some more done this evening, just finally getting around to setting up Linux on a proper desktop.
<azonenberg> actually no its not, j is
<azonenberg> Sooo that explains it
<_whitenotifier-3> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/fjnwO
<azonenberg> You somehow commented out my code to read the wavedescs
<_whitenotifier-3> [scopehal] azonenberg 3543f2d - Fixed wavedesc reads
<azonenberg> i do a batch "ask for all wavedescs" then a second loop below that reads them all
<azonenberg> Error_404: for some reason you had commented out the read so all of the subsequent logic was reading uninitialized memory :p
<monochroma> bad Error_404
<Error_404> wat
<azonenberg> Error_404: see the diff
<azonenberg> not sure how that ever worked for you...
<Error_404> yeah, just did. no idea how that snuck in.
<Error_404> the siglent class overrides acquiredata
<Error_404> glad it didn't take too long to track down..
<_whitenotifier-3> [scopehal] azonenberg closed pull request #66: Actually use the results of FindFFTS - https://git.io/fjngB
<_whitenotifier-3> [scopehal] azonenberg pushed 3 commits to master [+0/-0/±4] https://git.io/fjnwX
<_whitenotifier-3> [scopehal] whitequark 77f7471 - CMake: actually use the results of FindFFTS
<_whitenotifier-3> [scopehal] whitequark a9de049 - Use correct ffts include path
<_whitenotifier-3> [scopehal] azonenberg 5130ba1 - Merge pull request #66 from whitequark/patch-1 Actually use the results of FindFFTS
<_whitenotifier-3> [scopehal-cmake] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/fjnw1
<_whitenotifier-3> [scopehal-cmake] whitequark f294b60 - Search for libffts in ~/.local as well
<_whitenotifier-3> [scopehal-cmake] azonenberg 0bdfc51 - Merge pull request #5 from whitequark/master Search for libffts in ~/.local as well
<_whitenotifier-3> [scopehal-cmake] azonenberg closed pull request #5: Search for libffts in ~/.local as well - https://git.io/fjngY
<_whitenotifier-3> [scopehal-cmake] azonenberg closed pull request #4: README: reformat to use block code tags - https://git.io/fjngU
<_whitenotifier-3> [scopehal-cmake] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/fjnwM
<_whitenotifier-3> [scopehal-cmake] whitequark c83b1c9 - README: reformat to use block code tags Also use out-of-tree builds for scopehal.
<_whitenotifier-3> [scopehal-cmake] azonenberg f34f58b - Merge pull request #4 from whitequark/patch-2 README: reformat to use block code tags
<_whitenotifier-3> [scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/fjnwy
<_whitenotifier-3> [scopehal-cmake] azonenberg 8957a56 - Updated submodules, removed CMAKE_C_FLAGS as there's no C source code in the project
lain has joined #scopehal
<azonenberg> Error_404: did you add code to glscopeclient yet to instantiate your new class? or how are you testing it?
futarisIRCcloud has joined #scopehal
<azonenberg> whitequark: are you around?
<azonenberg> When you get a chance, can you set the scope up with some signals on other channels? ideally usb 1.x high full speed or a uart sending frequent traffic
<azonenberg> or just some signal that isnt phased to the squarewave at minimum
<azonenberg> i need to test reconfiguring triggers etc
avl_ has joined #scopehal
avl has quit [Ping timeout: 245 seconds]
bvernoux has joined #scopehal
bvernoux has quit [Quit: Leaving]
bvernoux has joined #scopehal
<bvernoux> re
<bvernoux> out of context does anyone have checked IVI 3D Printer on KS ?
<bvernoux> It really seems it is impossible to deliver such 3D printer for only 300USD
<bvernoux> or even 500USD ...
<whitequark> azonenberg: around
<azonenberg> whitequark: I just wanted you to put some other signals on the scope besides the squarewave
<azonenberg> So i can test changing config
<whitequark> azonenberg: ack, let me see
<whitequark> azonenberg: gimme a moment to eat something and i'll do that
<whitequark> azonenberg: OOOOH
<whitequark> i found something
<whitequark> i found an USB 1 *HUB*
<whitequark> and it's in DIP
<avl_> what is the frequency opf usb1 signals ?
<avl_> what is the frequency of usb1 signals ?
<whitequark> 12 Mbps
avl_ has quit [Ping timeout: 246 seconds]
avl has joined #scopehal
<avl> but in terms of frequency ?
<whitequark> i think it's just 12 MHz with their line code
<whitequark> but i may be wrong
<whitequark> azonenberg: poke
<sorear> wouldn't that be closer to 12 Mbaud / 6 MHz nyquist
<whitequark> hmm so USB is NRZI
<whitequark> that means you get transitions on both clock edges
<whitequark> but also NRZI is half the bandwidth that'd be required by a manchester encoding
<whitequark> so it's 6 MHz
<avl> can i probe them with generic probes or do i need diff probes ?
<whitequark> you can
<avl> so my scope bandwidth should be enough
<avl> 100Mhz
<whitequark> yes
<whitequark> azonenberg: i made a setup for you
bvernoux has quit [Quit: Leaving]
avl_ has joined #scopehal
avl has quit [Ping timeout: 252 seconds]
<azonenberg> whitequark: testing...
<azonenberg> No reply when i connect
<whitequark> azonenberg: one moment please
<whitequark> almost done with some upgrades
<whitequark> azonenberg: ok, scope at port 5556, UART at port 5557
<whitequark> the UART is a glasgow in loopback mode
<whitequark> so if you send it a string, expect a BULK OUT in FS mode, then a BULK IN with the same data
<whitequark> no other USB activity whatsoever
<whitequark> and by loopback mode i mean i hooked up the scope to a wire
<whitequark> CH4 is UART, CH2/CH3 are D+/D- or maybe D-/D+, i didn't look
<whitequark> CH1 is 1 kHz as usual
<azonenberg> And this is full speed mode?
<whitequark> yes, this is FS
<whitequark> glasgow cannot do LS
<azonenberg> In the middle of something right now but will test shortly
<sorear> how do you force it to FS instead of HS?
<whitequark> sorear: i plugged it into an FS hub
<whitequark> azonenberg: gonna restart my x11 session, sec
<azonenberg> whitequark: i'm doing construction right now anyway so no rush
<azonenberg> just wanted it up by later today