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
<whitequark> azonenberg: tried to use your PLL to actually extract data from the floppy
<whitequark> it's very, very bad at it
<whitequark> on the flipside, mine was significantly worse to the extent that it could recover almost nothing
<whitequark> so it's still an improvement
<whitequark> azonenberg: wow
<whitequark> I added 3 fractional bits to period and phase counters
<whitequark> the improvement is MASSIVE
<whitequark> i think i can actually read data from a floppy with this, let me get an image and mount it
<azonenberg> :)
<azonenberg> Fractional bits do help
<azonenberg> I probably got away without them in my PLL because my time units were picoseconds
<azonenberg> So i had enough resolution that i could just round to the nearest ps and be fine
<azonenberg> whitequark: scope on 5556 isnt working
<whitequark> azonenberg: yes, i was using the glasgow connected there
<whitequark> so, re PLL
<whitequark> 0 fractional bits: I: g.applet.memory.floppy: 1069/2880 sectors missing
<whitequark> 2 fractional bits: I: g.applet.memory.floppy: 23/2880 sectors missing
<whitequark> azonenberg: anyway lemme bring everything up again
<whitequark> azonenberg: oh i think i figured out how to configure it so it doesn't do the stupid zeroconf thing
<whitequark> it's an option i can turn off. i turned it off
<whitequark> azonenberg: try
<azonenberg> Nice
<azonenberg> Connected
<whitequark> azonenberg: uart at 5557 should work
<azonenberg> How long is the capture window right now?
<whitequark> and you should be able to correlate uart bits with usb bits
<whitequark> uhhh
<whitequark> 3k pts
<azonenberg> ok i'll have to play around a bit to configure it so i ca see enough to decode
<azonenberg> i did see a usb idle packet though
<azonenberg> i'm only seeing 1K points
<azonenberg> so i have to figure out why
<whitequark> azonenberg: you've only looked at USB HS so far, right?
<whitequark> or did you look at FS?
<whitequark> azonenberg: oh btw the capture is upstream of the hub
<whitequark> and the hub is plugged into another hub
<whitequark> and that hub is plugged into a thunderbolt card
<whitequark> which has a hub inside.
<monochroma> whitequark: hubs all the way down D:
<whitequark> azonenberg: yep just mounted the image, linux can read it
<azonenberg> i have *only* looked at FS
<whitequark> ahh
m4ssi has joined #scopehal
m4ssi has quit [Remote host closed the connection]
<azonenberg> whitequark: any updates re your friend who wanted my old rigol?
<whitequark> azonenberg: lemme poke her
<azonenberg_work> also my usb in-line probe arrived
<azonenberg_work> Good news and bad news :p
<azonenberg_work> Good news: it appears to not break the existing usb connection
<azonenberg_work> And the waveform edges look pretty sharp on full speed, havent tried high yet
<azonenberg_work> The bad news is, if you run it in DC coupled mode it destroys the signal and the PC wont enumerate the device
<azonenberg_work> So you have to run in AC coupled mode
<whitequark> wait what
<whitequark> how
<whitequark> isn't the probe supposed to be high impedance...
<azonenberg_work> I'm using low-Z probes with 1K impedance
<azonenberg_work> the pullups are 1.5K
<whitequark> ahh
<azonenberg_work> so the lines float at about 1.4V instead of 3.3
<azonenberg_work> i could try using much larger resistors and going for say 100:1 attenuation
<azonenberg_work> you'd lose some voltage resolution but it would work
<azonenberg_work> i have enough components to populate several of the boards so i may experiment
<azonenberg_work> Anyway, in AC coupled mode what happens is you lose the DC bias so D+ and D- both look to be zero volts
<azonenberg_work> if you apply a 3.3V bias to D+ in postprocessing, the data should demodulate just fine
<azonenberg_work> (have not tested this yet but the waveforms are super sharp)
<azonenberg_work> In any case the PCB is fine
<azonenberg_work> its a matter of tweaking component values and/or software
bvernoux has joined #scopehal
<bvernoux> hello
bvernoux1 has joined #scopehal
bvernoux has quit [Ping timeout: 264 seconds]
bvernoux1 has quit [Quit: Leaving]
bvernoux has joined #scopehal
_whitelogger_ has joined #scopehal
bvernoux has quit [Ping timeout: 248 seconds]
_whitelogger has quit [Ping timeout: 248 seconds]
bvernoux1 has quit [Quit: Leaving]
bvernoux has joined #scopehal
avl_ has quit [Ping timeout: 246 seconds]
maartenBE_ has joined #scopehal
maartenBE has quit [Ping timeout: 245 seconds]
<azonenberg> whitequark: update, i swapped the 953 ohm resistors for 10K
<azonenberg> Which gives 201:1 attenuation instead of the 20:1 i had originally
<azonenberg> the 200:1 settng on my scope is fine as the resistors are only 1% tolerance anyway
<azonenberg> In that configuration, DC coupled, it works fine
<whitequark> azonenberg: ack
<azonenberg> You just have slightly worse noise margins due to the weaker probe signal
<whitequark> azonenberg: btw i tuned your PLL so it is good enough for every floppy i have, with some minor reservations
<whitequark> i had to add proportional gain
<azonenberg> Interesting, because for high speed serial i found that bang-bang gave better results than proportional
<whitequark> it is kind of a combination of both
<azonenberg> But OTOH this is a whole area of control theory i know very little about
<azonenberg> what, proportional but with a few fixed step sizes?
<whitequark> no
<whitequark> on each data edge it shifts *somewhere*
<whitequark> by at least 4 LSB in phase
<whitequark> and the shift in frequency is phase>>1
<sorear> i'm vaguely surprised you have any noise margin at all at 200:1
<whitequark> sorry, 2 LSB in phase and frequency is phase>>1
<whitequark> i've also increased the amount of fractional bits to 6
<whitequark> the proportional gain is 1/32
<whitequark> this allows it to pull in and lock from a very low frequency to most HD and DD floppies with good data
<whitequark> if the floppies have a lot of noise the PLL tends to wander a lot
<whitequark> so i restrict it to something like ±3%
<sorear> this requires the end user to know the number of bits per track on their floppy?
<whitequark> sorear: no, it can calibrate on track 0 or something
<whitequark> maybe make sure it's an actual good track
<whitequark> worst case you look at the histogram
<bvernoux> Amiga Floppy reader was very good for that ;)
<bvernoux> more advanced than PC floppy for protection ...
<bvernoux> whitequark, what the aim of doing an USB Floppy reader just read some old floppy before they are really dead ?
* monochroma has a pile of amiga 1000 floppies to do something with one day
<whitequark> bvernoux: nope i was just looking at a floppy drive
<whitequark> and thought "well i'm going to make a floppy drive controller"
<whitequark> so i did it
<whitequark> monochroma: send me a few
<whitequark> or get a glasgow and dump them
<bvernoux> as the must have is Amiga Floppy Driver controller ;)
<bvernoux> the most clever
<whitequark> sure, whichever
<bvernoux> but interesting to do it from scratch
<bvernoux> you are reading PC floppy ? 1.44Mbytes & 720K ?
<whitequark> yes, HD and DD
<bvernoux> interesting it is fun they are not dead since the time
<whitequark> well no, open https://twitter.com/whitequark/status/1125247257970913280 and scroll down
<bvernoux> ha the PLL is done only in verilog/vhdl with FPGA ?
<bvernoux> no any hardware outside ? (except maybe few passive things like resistors/capacitor)
<whitequark> the PLL is currently entirely in python
<whitequark> and it is slow as shit
<whitequark> but it is written to be implementable in FPGA very efficiently, with only adders and constant shifts
<whitequark> about 16 bit adders so i could run it at full line rate
<bvernoux> using migen I suspect
<whitequark> yes
<bvernoux> very interesting
<whitequark> i am going to work on a better file format next
<whitequark> that can represent sampled data|modulated data|demodulated data|separate sectors
<whitequark> this way all components can be evaluated and tested separately very easily
<bvernoux> such things could be interesting to use for an other use case ;)
<bvernoux> thinking about how to defeat counter measure in SCA ...
<whitequark> SCA?
<bvernoux> Side Channel Analysis
<whitequark> oh
<whitequark> i dont do security
<bvernoux> it is very fun to recover some big AES keys ;)
<whitequark> i'm bad at it, it's boring and there are assholes everywhere
<bvernoux> check qscat on github ;)
<monochroma> very much the latter >_>
<bvernoux> done by a friend expert in security
<bvernoux> problem is lot of people thing implementing secure boot with AES128 or 256bits is unbreakable which is totally wrong
<bvernoux> thing->think
<bvernoux> what is interesting is to check with a scope and probe EM or directly the current the huge leakage during crypto ...
<bvernoux> it is why you stuff on floppy let me remember that ;) even if it is totally different
<whitequark> yeah, i get it
<whitequark> it's just i do not break things, i build things
<bvernoux> me too i try ;)
<whitequark> i'll spend 1 day figuring out how to do plls, will use that probably many times in the future
<bvernoux> but to better build it, sometimes it is good to know how to break it
<whitequark> spend 6 months figuring out how to extract a key, will never use that again because the vendors fix it
<whitequark> i'm exaggerating
<bvernoux> it is 5minutes with the good HW ;)
<bvernoux> especially good sw too
<bvernoux> and our record is breaking AES128 in 18traces ;)
<whitequark> nice
<sorear> except the things which need to be broken because they're in the way of building things mm
<bvernoux> but yes sometimes it requires thousands of traces and lot of hours/days ...
<whitequark> sorear: those are usually not technological
<bvernoux> anyway today it is good to know how to break such crypto for knowledge
<bvernoux> as too much things are hidden ...
<bvernoux> I have built a PLL recovery for that
<bvernoux> it is why I say it is not far from what you do ;)
<whitequark> ahh, interesting
<bvernoux> filter + PLL recovery in order to extract clock from noise on some system without access to clock
<whitequark> it is easier if you don't try to do it online with low latency
<bvernoux> fully HW in my case
<whitequark> which i want
<whitequark> oh, you do?
<bvernoux> I can provide the reference
<bvernoux> it was based on colin o'flynn schematic reference
<bvernoux> 100% done with KiCad ;)
<whitequark> hmmmm
<bvernoux> i'm pretty sure it will provide very good results for your floppy stuff ;)
<bvernoux> as the PLL resynch is amazing it is a SOC
<bvernoux> a specialized chip for that
<bvernoux> but quite expensive for what it is ;)
<whitequark> can it sync at 250 kHz input clock?
<sorear> how much jitter can an attack-grade PLL tolerate
<sorear> i saw a soc clock once that swung back and forth 2x in frequency every 20ns
<bvernoux> it can sync freq at more than 32MHz ;)
<bvernoux> it recover clock in fact
<bvernoux> just need to build the good bessel filter before
<bvernoux> in my case it was filtered between 16MHz to 32MHz
<bvernoux> but will be fun to check what it does at 250KHz
<whitequark> yes, more than 32 MHz is common
<whitequark> but very low clock not so much
<bvernoux> it is designed for something like 2Mhz up to 32MHz in fact
<bvernoux> so I do not know how it work < 2MHz
<whitequark> right, so it cannot do floppy :D
<bvernoux> need to check the datasheet ;)
<bvernoux> it use also a low noise amplifier
<bvernoux> so floppy freq could be also done by a upconverter ;)
<bvernoux> upconvert 250KHz => 20MHz for example
<bvernoux> let share the design if you are interested
<whitequark> by upconverting wouldn't you then be locking to baseband
<whitequark> or more like IF
<whitequark> i'm not sure how it would work
<bvernoux> the interesting frequency in your case is between DC - 250KHz ?
<whitequark> yes.
<bvernoux> with probably a very low BW like 10KHz
<whitequark> well, it needs to tune to 125 or 250 kHz
<whitequark> approximately
<bvernoux> ha ok
<bvernoux> in that case you can check that with a SDR ;)
<whitequark> oh yeah gnuradio would have prob worked
<whitequark> would not give me good gateware though
<bvernoux> my hw was to avoid any sw filter to do hardrealtime with clock recovery
<whitequark> interesting
<bvernoux> I have 2 boards here
<whitequark> i see
<whitequark> so i'm interested in gateware-only designs
<bvernoux> built at macrofab (mainly to test their assembly ;)
<bvernoux> ha ok
<bvernoux> the fun is you can do all in one with such board ;)
<bvernoux> LNA, Filter and Clock Recovery
<bvernoux> as you cannot do LAN & Filter with FPGA ;)
<whitequark> so you know why i built glasgow, right?
<bvernoux> LNA
<whitequark> too dissociated/attention deficit to do PCB design and assembly in any reasonable timeframe
<bvernoux> yes I understand the concept and I like it
<whitequark> no i mean the real reason
<bvernoux> yes to avoid to solder things ;)
<bvernoux> which is clearly too time consuming for nothing when we can do it by "SW"
<whitequark> no not solder things
<whitequark> if something has lead time over... 3 days, i swap it out
<whitequark> and it's too hard to pick up context
<bvernoux> just for details the core chipset is AD8331
<bvernoux> very funny chipset
<bvernoux> Ultralow Noise VGAs with
<bvernoux> Preamplifier and Programmable RIN
<bvernoux> Application is Ultrasound and sonar time-gain controls ;)
<bvernoux> and gain works from 100KHz to 100MHz ;)
<whitequark> hmm okay
<bvernoux> it was just funny to speak about that strange chipset
<bvernoux> even if it is more interesting to do it in FPGA like you did
<whitequark> oh yeah
<sorear> VGA threw me for a second
<bvernoux> bye
bvernoux has quit [Quit: Leaving]
adamgreig has joined #scopehal
tnt has joined #scopehal
maartenBE_ has quit [Ping timeout: 244 seconds]
maartenBE has joined #scopehal