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] four0four pushed 1 commit to Siglent-WIP [+0/-0/±2] https://git.io/fjckl
<_whitenotifier-3> [scopehal] four0four 62a3963 - acquire data work
<azonenberg> whitequark: Just a FYI that your scope is offline again
<azonenberg> i'm not actively working on it
m4ssi has joined #scopehal
<_whitenotifier-3> [scopehal] azonenberg pushed 1 commit to master [+2/-0/±3] https://git.io/fjcqh
<_whitenotifier-3> [scopehal] azonenberg 1e547eb - Added DC offset decoder. Fixes #45.
<_whitenotifier-3> [scopehal] azonenberg closed issue #45: Add "DC offset" protocol decoder - https://git.io/fjcqj
<azonenberg> Also i think i just found a bug in my PLL, investigating
adamgreig has quit [Ping timeout: 264 seconds]
adamgreig has joined #scopehal
<whitequark> azonenberg: remember, it's connected to my laptop
<whitequark> if i take the laptop with me and close it, it gets offline
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<monochroma> azonenberg's test setup literally gets up and walks away! :P
<whitequark> lol
m4ssi has quit [Remote host closed the connection]
_whitelogger has joined #scopehal
bvernoux has joined #scopehal
<azonenberg> lol
<azonenberg_work> So last night i was starting to think of a framework for doing better clock recovery of bidirectional buses
<azonenberg_work> basically you need a flag that specifies which end has control of the bus
<azonenberg_work> and you sync to one clock or the other
<azonenberg_work> The eventual goal for DDRx, USB, etc would be to be able to do two separate eye patterns on the data depending on who's talking
<whitequark> oh, nice
<azonenberg_work> So my plan is to make a little extraction filter that takes a USB PCS-layer symbol stream as input and spits out a boolean flag saying which end has control of the bus
<bvernoux> ha very nice feature
<azonenberg_work> Then the clock recovery PLL will take an optional "gate" input that ignores any transitions when that signal is low
<azonenberg_work> and freezes the output during that time
<bvernoux> all is done in real-time on PC side ?
<azonenberg_work> Yes
<azonenberg_work> Well, real time as data comes off the scope
<azonenberg_work> the scope is the performance bottleneck right now wrt getting data to me fast enough
<bvernoux> or it is something which can be also "synthethized" in FPGA migen ... ?
<azonenberg_work> My current implementation is postprocessing based but that may change
maartenBE has quit [Ping timeout: 252 seconds]
<azonenberg_work> i plan to move some of it to GPU in the future
<azonenberg_work> Basically my problem right now is that i can't do eye patterns of USB
<bvernoux> yes will be amazing to do that in GPU
maartenBE has joined #scopehal
<azonenberg_work> The PLL cant slew fast enough to compensate for the phase shift as you have one end talking then the other
<azonenberg_work> while also being stably locked normally
<bvernoux> but to keep an option to use it on CPU too in case GPU is too slow
<azonenberg_work> And if i ignore that, i get massive "jitter" that isnt really jitter in the eye
<bvernoux> do you have tried some RF algorithm for that too ?
<azonenberg_work> Not yet, i'm in the middle of trying to clean up some bugs in my PLL
<azonenberg_work> I was trying to have it lock to the center of the data eye (rather than the edges) and had some bugs as a result introducing phase shifts
<bvernoux> liquidsdr has a very interesting things for that
<bvernoux> with amazing results
<bvernoux> could be interesting to integrate it maybe in future
<bvernoux> license is MIT too
<azonenberg_work> Might look into it, but right now i'm trying to learn more about how PLLs work
<azonenberg_work> so implementing it is a key goal
<bvernoux> for reference
<bvernoux> anyway it is always interesting to continue on your idea to compare after with this implementation to check what is the best/faster ...
<bvernoux> this tutorial is very interesting too http://liquidsdr.org/blog/pll-simple-howto/
<bvernoux> advantage is code is very simple
<bvernoux> for those interested I'm planning a tuto on how to tune NFC Antenna and all components with 100% open source tools ;)
<bvernoux> with concrete example using HYdraNFC v2 Antenna + Shield which will be open source KiCad scehmatic/board too
<bvernoux> using next gen NFC chipset TBD ;)
<bvernoux> I will reveal the Chipset when it will be publicly released
<bvernoux> as there is clearly a big hole in how really work NFC and how to tune it
<bvernoux> the most funny will be to have new tool to exploit NFC with buffer overflow and code injection over NFC low layer ;)
<bvernoux> as there is clearly a big hole to test anything on NFC and developer think tags are perfect mainly because of lack of real/advanced NFC Tag Emulation which does not cost > 10KUSD ...
<bvernoux> azonenberg_work, do you have tried such cheap probe https://www.dreamsourcelab.com/shop/accessories/shielded-fly-wires/ ?
<bvernoux> I plan to buy some to check them especially for LA purpose up to 100MHz
<bvernoux> will check them with my VNA also between 10KHz up to 230MHz
<azonenberg> I have not tried any such things, no
<azonenberg> This is my homebrew Z0 probe though, pretty happy with how it turned out although i think with a pcb/mechanical respin i can make the shaft a little skinnier to fit in tighter spots
<azonenberg> I also need to add more clearance at the top around the coax connector, as it stands the current connector doesn't fit without you milling down the enclosure :p
<tnt> heh, you usb probing setup is much better looking that mine :p (which is just a USB A femare directly soldered to a USB A male and 4 flying wire out of it :p.
<azonenberg> thats a better shot
<bvernoux> woo very nice probe
<bvernoux> I also need to buy those pico "bracket"
<azonenberg> I have to tweak the passive values a bit, DC coupled at 20:1 was too much load for the pullups
<azonenberg> AC coupled failed because i was dumb and did something stupid
<azonenberg> i swapped the R and C when i populated it
<azonenberg> so i need to rework it and try the right way around
<azonenberg> Right now I'm using DC coupled at 200:1 which works but has worse noise margin
<azonenberg> tnt: any time i probe some bus more than once or twice i make a custom fixture
<bvernoux> could you share the OSHPark link I will build some to characterize them
<bvernoux> ?
<azonenberg> bvernoux: which one? the usb test fixture or the point probe?
<sorear> I wonder if you could determine the signal direction by looking at the time delay in two probes ~30cm apart
<bvernoux> both
<bvernoux> in order to have same boards
<azonenberg> the kicad files are on azonenberg/starshipraider/ in the boards/ directory
<bvernoux> but if you plan to do any revision there is no any hurry I can wait
<azonenberg> usb-inline-probe and handheld-resistive-probe
<bvernoux> ha ok nice
<azonenberg> The USB probe will not change PCB, however i am tweaking passive values
<azonenberg> the point probe is getting at least one respin in addition to passive changes
<bvernoux> does the impedance is good without any RC ?
<azonenberg> The mechanical design for the point probe is being redone too
<azonenberg> The USB probe is routed differentially and then splits off to two 50-ohm legs, i havent TDR'd it but the waveforms look good at 12 Mbps
<azonenberg> I may tweak it for 480, i havent tried running that fast
<azonenberg> My focus right now is the point probe
<azonenberg> my fancy RF resistors are coming today or tomorrow then we'll see how they work instead of the cheap Yaegos
<bvernoux> I think some guarding via could improve the probe for no cost
<azonenberg> My problem right now isnt noise, it's the impedance step
<azonenberg> i havent figured out where its coming from
<bvernoux> also more via on J1 will help
<azonenberg> (on the handheld probe)
<azonenberg> Once i get that big jump figured out i can work on finer improvements
<bvernoux> with KiCad PCB Calculator it seems you have a nice 50.5 Ohms Impedance
<bvernoux> Er 3.67
<azonenberg> The physical probe i have is over-etched
<azonenberg> so the impedance is a bit high
<azonenberg> but i dont think that's the source of my troubles
<bvernoux> ha
<azonenberg> the math didnt make it seem like it was enough of a delta
<bvernoux> I will produce some the check real impedance with full S11 / Smith Charts
<azonenberg> I plan to respin it as a grounded coplanar waveguide as well
<azonenberg> (vs microstrip)
<bvernoux> I will check on 3 boards to see the differences
<azonenberg> Don't waste your time on the current PCB rev
<azonenberg> I'm not keeping it
<bvernoux> ha ok
<azonenberg> There's a reason i didnt make the oshpark project public or advertise the github url too much
<bvernoux> even the handheld-resistive-probe ?
<azonenberg> Especially that
<bvernoux> ok
<azonenberg> I dont want anyone making them until they work :p
<bvernoux> hehe
<bvernoux> will be nice to upgrade your diffprobe-calibrated-prototype to use USB Type C PD ;)
<bvernoux> like that we can generate 12VDC with it ;)
<azonenberg> That probe is going to get redone too
<azonenberg> And i wasnt targeting usb-c in the final version
<azonenberg> i was targeting lecroy ProBus
<azonenberg> Which supplies +/- 12V natively
<bvernoux> ha ok
<azonenberg> it was going to plug right into the scope and be done
<azonenberg> But the second iteration of the board had a short i never found
<azonenberg> i was just starting to debug when i bought the house
<azonenberg> and that was the end of that
<bvernoux> I use Diff Probe from Colin Oflynn
<bvernoux> it is quite nice for the price
<azonenberg> what specs?
<azonenberg> That version was targeting DC to 500 MHz but i have a GHz scope so i want to do better now
<azonenberg> mine was also 50 ohm, not high-Z
<bvernoux> not 500Mhz ;)
<bvernoux> IIRC something like 50MHz ;)
<bvernoux> ha no => Approx 20 kHz - 200 MHz Bandwidth
<azonenberg> Lol ok so not awful
<azonenberg> but yeah i want to make a diffprobe you can read SGMII with
<bvernoux> the bad things is we need to calibrate it all the time ;)
<bvernoux> there is drift
<bvernoux> but for 57USD it is really not bad
<bvernoux> Also I have a very nice power supply for current trace
<azonenberg> oh?
<azonenberg> so far i've been a fan of my HMC8042's
<bvernoux> ifi Audio iPOWER AC-DC Adaptator => 5V with 1uV RMS noise ;)
<bvernoux> for specialized things
<azonenberg> Yeah thats definitely going to have less ripple than mine - but a lot less flexibility
<bvernoux> yes it is not felxible at all
<bvernoux> it is mainly to measure current on an ultra stable power supply
<bvernoux> anyway I have not the HW to measure the 1uV noise ;)
<bvernoux> my next PSU will be https://github.com/eez-open/modular-psu ;)
<bvernoux> seems really amazing and fully open source HW/SW ...
<bvernoux> and the spec is amazing
<bvernoux> and with Ethernet ;)
<bvernoux> I doubt even R&S have so much things in their PowerSupply which cost 10x the price and are not open at all ...
<azonenberg> Rack mountable?
<bvernoux> yes IIRC it is
<monochroma> anything is rackmountable if you try hard enough
<tnt> bvernoux: do you know if someone is selling kits / assembled boards / ...
<bvernoux> tnt, it is too early for new version
<bvernoux> for old version there was a 2nd batch planned but it seems it was cancelled :(
<bvernoux> maybe because the new version is WIP
<bvernoux> previous version
<bvernoux> the guys behind are amazing all those work on a Power Supply
<bvernoux> what I have not liked is they was using Arduino ;)
<bvernoux> but in next version it will be a STM32F7 ;)
<azonenberg> Yes, as well as it looks like only internal feedback?
<bvernoux> it seems old version is abandonned in fact no update since 2017 and the guy is working hard on newer version
<bvernoux> thread on the new PSU WIP is here
<bvernoux> name is h25005
<bvernoux> USb Type C PD is amazing in fact
<bvernoux> it is like a power supply definition ;)
<bvernoux> IIRC with voltage step of 0.2V ...
<bvernoux> I will probably check that with https://www.tindie.com/products/clarahobbs/pd-buddy-sink/
<bvernoux> as now there is more and more USB PD available
<bvernoux> it is even 20mV increment ;)
<whitequark> PD is so awful
<bvernoux> yes ;)
<bvernoux> over complicated
<whitequark> "overcomplicated" doesn't even begin to describe it
<bvernoux> and lot of device will burn in flams with it ;)
<whitequark> have you seen the "fast role swap" thing it has?
<whitequark> have you seen the eye diagrams for PD data?
<whitequark> TWELVE points
<whitequark> that's for 200 kbps
<bvernoux> it is why I'm interested in how it works like the proverb say "Know your enemy and know yourself and you can fight a hundred battles without disaster." ;)
<bvernoux> ha no I have not seen it
<bvernoux> shall be funny ;)
<bvernoux> especially to deliver 100W with USB 3.0 or even worse 3.1 10Gbps ;)
<bvernoux> I suspect it shall not work ;)
<bvernoux> IIRC it is not possible to do both ...
<whitequark> bvernoux: i don't see why it wouldn't work
<whitequark> well, in theory
<bvernoux> because of noise especially with chinese power supply ;)
<whitequark> nah
<whitequark> pcie works just fine with noisy chinese power supplies
<whitequark> and usb 3 physical layer is just butchered pcie
<bvernoux> I imagine it will do so strong spurs at 100W (20V/5A) that USB 3.x 5GBps or 10GBps will have a crappy eye diagram
<bvernoux> it is just the pins are not far and also it depends on routing ...
<whitequark> also
<bvernoux> but it is interesting to check that in future
<bvernoux> as in theory it is possible
<whitequark> that noise isn't the right frequency
<whitequark> i mean, take a look at thunderbolt
<whitequark> that's 10/20 Gbps also and it coexists just fine with 100 W charging
<whitequark> there are many systems in the wild that use it
<whitequark> fun thing though
<bvernoux> with 100W ?
<whitequark> yes
<whitequark> thunderbolt docks are a popular thing
<whitequark> they do charging and thunderbolt, and they work mostly fine
<bvernoux> IIRC they consume something like 25W
<whitequark> they don't consume, they provide power
<bvernoux> but maybe yes there is 100W too now
<bvernoux> yes they provide ;)
<whitequark> thing is
<whitequark> it does not coexist with wifi
<whitequark> i got strong interference between both 2.4G and 5G WiFi and TBT
<bvernoux> yes I imagine the mess
<whitequark> ... that is, until i disassembled my laptop, threw out all of their badly placed copper tape, and wrapped it in even more metal tape myself
<whitequark> then it started working mostly ok
<whitequark> these people put wifi card right opposite the tbt chip
<whitequark> and fixed it with lots of copper foil
<whitequark> that does not adhere very well to pcbs
<whitequark> and actually isn't enough
<whitequark> wrapping the entire wifi card right up to the ufl connections helped
<bvernoux> strange how they have done the compliance ;)
<bvernoux> with such bad design
<whitequark> i think it has precisely enough copper foil to pass compliance
<whitequark> whether it works was more of an afterthought
<bvernoux> we all know how are done the test ;)
<bvernoux> I have done some in paste
<bvernoux> you add tons of ferrite in order it pass compliance
<bvernoux> then you do not add them on final product ...
<whitequark> lol
<bvernoux> I know it is like that for lot of HW :(
<bvernoux> mainly just to pass EMC
<bvernoux> big ferrite are designed to pass EMC tests ;)
<bvernoux> there is some funny story about that for car manufacturer ;)
<bvernoux> I even remember a company which was validating bluetooth dongle the test with EMC was impossible as it crashed the PC HDD ;)
<whitequark> wtf
<bvernoux> and the guy came back with a ruggerized PC and again it crashed ;)
<bvernoux> it was panic mode ;)
<bvernoux> and now they do such test in china ;)
<bvernoux> and we have tons of IoT cheat ;)
<bvernoux> I have just finished some tuning on NFC it is crazy how accurate pF is important
<bvernoux> I was sure even 10pF delta shall do not have a major impact and I was totally wrong even just for 13.56Mhz ;)
<bvernoux> as there is impact with a delta of 2pF
<bvernoux> qucs is just a must have for such advanced simulation
monochroma has quit [Ping timeout: 258 seconds]
monochroma has joined #scopehal
bvernoux has quit [Quit: Leaving]
futarisIRCcloud has joined #scopehal
<_whitenotifier-3> [scopehal] azonenberg pushed 3 commits to master [+0/-0/±4] https://git.io/fjcaz
<_whitenotifier-3> [scopehal] azonenberg 1a4a0fa - ProtocolDecoderParameter: added boolean argument support
<_whitenotifier-3> [scopehal] azonenberg 2e5f2d3 - Removed hacky workaround from EyeDecoder2
<_whitenotifier-3> [scopehal] azonenberg ab823c4 - Various tweaks to clock recovery decoder to handle lower frequency inputs better. Added support for gating when the input stops toggling.
<_whitenotifier-3> [scopehal] azonenberg pushed 1 commit to master [+2/-0/±4] https://git.io/fjcVO
<_whitenotifier-3> [scopehal] azonenberg d48bf44 - Added USB bus activity decoder
avl has joined #scopehal