<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
<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
<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