<azonenberg>
it seems like 18.04's build of liblxi is broken in multiple ways
<azonenberg>
miek: looping you in on this too
<azonenberg>
What are your thoughts on defining liblxi 1.13 as the supported minimum version
<azonenberg>
and saying if you're on an older OS like 18.04 that you need to build liblxi from source? That would let us revert the const changes which i think we can all agree are ugly
<tverbeure2>
I'm find with that.
<tverbeure2>
BTW: right now, the master of docs build fails.
<_whitenotifier-f>
[scopehal-cmake] azonenberg commented on issue #13: Build fails to link. - https://git.io/JfPsf
<azonenberg>
tverbeure2: on it, after i fix some of the other things i'm dealing with
<tverbeure2>
Found it: {llx} needs to be {lllX} in the Siglent section.
<_whitenotifier-f>
[scopehal-cmake] markrages commented on issue #13: Build fails to link. - https://git.io/JfPsB
<_whitenotifier-f>
[scopehal-cmake] markrages commented on issue #13: Build fails to link. - https://git.io/JfPsb
<azonenberg>
tverbeure2: you had more pending changes to the lxi transport code right?
<azonenberg>
see the #13 issue thread, add an extern "C" {} wrapper around lxi.h and we can now build against 1.8
maartenBE has joined #scopehal
<azonenberg>
we'll leave your const changes for now then revert them in a year or two when 18.04 goes EOL
<azonenberg>
I think that's the best path forward at this point
<tverbeure2>
Can you nest extern "C" {} ?
<azonenberg>
tverbeure2: yes. The standard says the innermost wins if nested
<tverbeure2>
Good!
<azonenberg>
Are you going to send a PR with that change or should I? If you have more comprehensive refactoring coming i'll temporarily fix this in master myself
<azonenberg>
just to avoid having the build be broken longer than necessary
<tverbeure2>
Go ahead
<miek>
i guess the clue was that the 'undefined reference' errors included arguments, not just the symbol name alone
<tverbeure2>
I wasted hours on that. I'm more familiar with Verilog...
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JfPsj
<_whitenotifier-f>
[scopehal] azonenberg 40da7cd - Added extern "C" linkage specifier around lxi.h for compatibility with pre-1.13 liblxi versions
<_whitenotifier-f>
[scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JfPGe
<_whitenotifier-f>
[scopehal-cmake] azonenberg 4128e07 - Updated submodules with liblxi fixes.
<_whitenotifier-f>
[scopehal-cmake] azonenberg commented on issue #13: Build fails to link. - https://git.io/JfPGv
<miek>
yeah, i couldn't see it at all either
<azonenberg>
I missed it too
<miek>
would be nice if it through a more helpful error
<azonenberg>
Yeah
<azonenberg>
Anyway, glad to finally have a root cause identified
<miek>
"oh, i'm looking for lxi_init() but lxi_init exists. maybe i could give a hint? nah"
<azonenberg>
lol
<_whitenotifier-f>
[scopehal-cmake] markrages commented on issue #13: Build fails to link. - https://git.io/JfPGY
<_whitenotifier-f>
[scopehal] tomverbeure opened pull request #134: Support for USBTMC - https://git.io/JfPGo
<azonenberg>
tverbeure2: reviewing the PR now. Do you have one for updating scopehal-docs to match?
<tverbeure2>
I'm working on that.
<azonenberg>
You can put yourself as the @author in SCPITMCTransport.* (and LXI if you didn't do that already). The intent of that is "who to talk to about the code", it's separate from the copyright notice up top
<tverbeure2>
So, right now, for ReceiveReply, it's doing the same as for Lxi: fetch everything, then return piecemeal.
<tverbeure2>
But that will break fetching a buffer larger than 150M.
<azonenberg>
That seems like a lot of data for a single fetch. Probably OK for the time being
<tverbeure2>
The urgency to fix that depends on whether or not fetching these large of a buffer is a valid use case.
<tverbeure2>
Does it work on your LeCroy scope? On the Siglent scopes, it just doesn't work, so it's not a valid case.
<tverbeure2>
Due to timeouts.
<azonenberg>
Right now I think the deepest memory any of my scopes supports is 64M points on the HDO9204? let me check
<tverbeure2>
I could also simply reallocate the staging buffer if there's ever a request for a larger one. :-)
<azonenberg>
Yeah that's a potential future improvement if needed
<azonenberg>
So i just tested on my HDO9204
<azonenberg>
over ethernet
<azonenberg>
With 64M points * 4 channels the UI gets a little bit laggy
<azonenberg>
and the update rate is 0.13 WFM/s. Or about 7.6 seconds to download and process each waveform
<azonenberg>
i'm sure there's room to optimize, most of my profiling was done on 5M point waveforms because at the time that was already pushing performance limits
<azonenberg>
now it's pretty comfortable
<_whitenotifier-f>
[scopehal] azonenberg closed issue #84: Add SCPITransport based class for USBTMC - https://git.io/JeQQ4
<_whitenotifier-f>
[scopehal] azonenberg closed pull request #134: Support for USBTMC - https://git.io/JfPGo
<_whitenotifier-f>
[scopehal] azonenberg pushed 2 commits to master [+4/-0/±6] https://git.io/JfPZk
<_whitenotifier-f>
[scopehal] tomverbeure 03118d7 - Support for USBTMC.
<_whitenotifier-f>
[scopehal] azonenberg f790a73 - Merge pull request #134 from tomverbeure/usbtmc Support for USBTMC
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #80: glscopeclient has short hang with high CPU during startup. Investigate to see if this can be fixed - https://git.io/Jv6Ni
<_whitenotifier-f>
[scopehal-apps] azonenberg commented on issue #80: glscopeclient has short hang with high CPU during startup. Investigate to see if this can be fixed - https://git.io/JfPZG
<azonenberg>
I havent tested usb to the lecroy scopes yet, but i might find time for that later in the week
<azonenberg>
Would have to crawl behind the rack and run some cables so it's nontrivial
<azonenberg>
i need to run fiber back there anyway though soon so i might hook up a usb cable when i do that
<monochroma>
hehe mine only has USB host
<azonenberg>
monochroma: you can work on your agilent scope now that we have a usbtmc driver though
<azonenberg>
it might just work with miek's improvements?
<monochroma>
:o
<azonenberg>
tverbeure2 sent in a usbtmc class and miek has an agilent driver
<_whitenotifier-f>
[scopehal-docs] tomverbeure opened pull request #8: Add section about USBTMC support. - https://git.io/JfPnf
<azonenberg>
miek: fyi i'm about to go to bed so won't be able to review your PR now. If you can get the #108 fix by the morning i'll review it when i'm up
Degi has joined #scopehal
<_whitenotifier-f>
[scopehal] tomverbeure opened pull request #135: Move lxi_init() to where it belongs - https://git.io/JfPWd
juli965 has joined #scopehal
<_whitenotifier-f>
[scopehal-apps] tomverbeure forked the repository - https://git.io/Je54v
<_whitenotifier-f>
[scopehal-apps] tomverbeure opened pull request #111: Print help message with '--help' on command line. - https://git.io/JfP4I
<_whitenotifier-f>
[scopehal-apps] tomverbeure synchronize pull request #111: Print help message with '--help' on command line. - https://git.io/JfP4I
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<_whitenotifier-f>
[scopehal] tomverbeure opened pull request #136: Add captured waveforms to m_pendingWaveforms when in toQueue mode. - https://git.io/JfPRp
<_whitenotifier-f>
[scopehal] tomverbeure opened pull request #137: Siglent: Retrigger after waveforms have been captured - https://git.io/JfP0G
<_whitenotifier-f>
[scopehal] tomverbeure commented on pull request #136: Add captured waveforms to m_pendingWaveforms when in toQueue mode. - https://git.io/JfP0n
<_whitenotifier-f>
[scopehal] tomverbeure commented on pull request #137: Siglent: Retrigger after waveforms have been captured - https://git.io/JfP0A
<_whitenotifier-f>
[scopehal] tomverbeure synchronize pull request #137: Siglent: Retrigger after waveforms have been captured - https://git.io/JfP0G
<_whitenotifier-f>
[scopehal] tomverbeure commented on pull request #137: Siglent: Retrigger after waveforms have been captured - https://git.io/JfPE3
<azonenberg>
PR #135 has a variable named m_lxi_initialized, the proper name according to convention is m_lxiInitialized
<azonenberg>
I'll still merge what you submitted as this is a trivial issue, but keep in mind for future work (and feel free to fix this in a future PR, don't bother sending one just for that)
<_whitenotifier-f>
[scopehal] azonenberg closed pull request #135: Move lxi_init() to where it belongs - https://git.io/JfPWd
<_whitenotifier-f>
[scopehal] azonenberg pushed 3 commits to master [+0/-0/±9] https://git.io/JfPrN
<_whitenotifier-f>
[scopehal] tomverbeure 375c8d0 - Move lxi_init() to where it belongs.
<_whitenotifier-f>
[scopehal] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JfPoq
<_whitenotifier-f>
[scopehal] tomverbeure c93326e - Add captured waveforms to m_pendingWaveforms whe in toQueue mode.
<_whitenotifier-f>
[scopehal] azonenberg 2a7a303 - Merge pull request #136 from tomverbeure/siglent_toQueue Add captured waveforms to m_pendingWaveforms when in toQueue mode.
<_whitenotifier-f>
[scopehal] azonenberg closed pull request #136: Add captured waveforms to m_pendingWaveforms when in toQueue mode. - https://git.io/JfPRp
<_whitenotifier-f>
[scopehal] azonenberg commented on pull request #137: Siglent: Retrigger after waveforms have been captured - https://git.io/JfPoO
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JfPoZ
<_whitenotifier-f>
[scopehal] azonenberg edited a comment on pull request #137: Siglent: Retrigger after waveforms have been captured - https://git.io/JfPoO
<_whitenotifier-f>
[scopehal] azonenberg closed pull request #137: Siglent: Retrigger after waveforms have been captured - https://git.io/JfP0G
<_whitenotifier-f>
[scopehal] azonenberg pushed 3 commits to master [+0/-0/±3] https://git.io/JfPoC
<_whitenotifier-f>
[scopehal] tomverbeure e879d6f - Retrigger when acquisition is complete. In addition to retriggering, I also reduced the scope of lock(m_mutex) to just the acquisition phase, just as it is done for the LeCroy scope. This increases the responsiveness of the STOP button such that it reacts immediately to the event. Without it, there are 4 or more AcquireData calls before the STOP button event kicks in.
<_whitenotifier-f>
During that time, the LeCroyOscilloscope::Stop() is stalled at the lock(m_mutex) phase.
<_whitenotifier-f>
[scopehal] tomverbeure 87c242c - Regrab m_mutex to retrigger.
<_whitenotifier-f>
[scopehal] azonenberg c45d7b5 - Merge pull request #137 from tomverbeure/retrigger Siglent: Retrigger after waveforms have been captured
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #108: Only up to 10 waveforms are loaded from a saved scope session - https://git.io/JfPeV
<_whitenotifier-f>
[scopehal-apps] azonenberg closed pull request #109: OscilloscopeWindow: set max waveform count before loading waveforms - https://git.io/JfPf0
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 2 commits to master [+0/-0/±2] https://git.io/JfPoB
<_whitenotifier-f>
[scopehal-apps] miek aca7166 - OscilloscopeWindow: set max waveform count before loading waveforms
<_whitenotifier-f>
[scopehal-apps] azonenberg 58fe532 - Merge pull request #109 from miek/load_all_the_waveforms OscilloscopeWindow: set max waveform count before loading waveforms
<_whitenotifier-f>
[scopehal-apps] azonenberg closed pull request #111: Print help message with '--help' on command line. - https://git.io/JfP4I
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 3 commits to master [+0/-0/±3] https://git.io/JfPog
<_whitenotifier-f>
[scopehal-apps] tomverbeure a75305e - Print help message with '--help' on command line.
<_whitenotifier-f>
[scopehal-apps] tomverbeure 31257ca - Fix version help message.
<_whitenotifier-f>
[scopehal-apps] azonenberg 0d4291f - Merge pull request #111 from tomverbeure/help_message Print help message with '--help' on command line.
<_whitenotifier-f>
[scopehal-cmake] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JfPoM
<_whitenotifier-f>
[scopehal-cmake] azonenberg 2fff18e - Updated submoudles with Siglent bugfixes and more
<azonenberg>
Well that was a busy evening of development by people other than me
<azonenberg>
Nice to see folks getting code in
<azonenberg>
Soo going back to hardware... one of the annoying things about the MMCX footprint i currently have is that it has holes drilled at the corners to provide a nice square corner
<azonenberg>
these holes give DRC errors if not marked as connected to ground because "floating" copper is touching grounded copper
<azonenberg>
but if they ARE marked as connected to ground, i get unconnected-pad warnings in DRC
<azonenberg>
because there isn't a trace terminating at the center of the hole
<azonenberg>
and there can't be, because the center of the hole is on or over the edge of the pcb :p
<azonenberg>
if i were to put a trace there after temporarily disabling DRC, i'd get drc errors about traces hitting the pcb edge
<azonenberg>
i'm not currently aware of a solution so for the time being i have to live with two unconnected-net warnings in the DRC for every MMCX on a board
<azonenberg>
and manually inspect them during the signoff review to make sure they're the ONLY unconnected nets
<_whitenotifier-f>
[starshipraider] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JfP1Z
<_whitenotifier-f>
[starshipraider] azonenberg d9d8b8b - Final version of la-pod-mmcx after layout review
<miek>
🚨 azonenberg: please push scopehal-apps 🚨
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JfPDZ
<_whitenotifier-f>
[scopehal-apps] azonenberg 2506679 - glscopeclient: expanded --help text
<azonenberg>
i ran git [push lol
<azonenberg>
and didnt notice
<miek>
hah
<azonenberg>
ok so at this point the mmcx board is done pending any changes for mechanical reasons
<azonenberg>
i2c eeprom. May or may not end up actually using it for anything
<Degi>
neat
<azonenberg>
but i might want to be able to determine what probe board is plugged in for one reason or another
<azonenberg>
i figure the footprint costs nothing
<Degi>
Hmm and the holes are aligned with the ones on the board below? nice
<azonenberg>
the mating board does not yet have holes for those screw holes
<azonenberg>
that's actually my next todo item
<Degi>
Ah
<Degi>
Huh, MMCX looks neat
<azonenberg>
It's a push on coax connector that's way smaller than SMA, doesnt need a torque wrench, etc. Really nice, but only good to 6 GHz max
<Degi>
Maybe sprinkle some more vias around the MMCX
<azonenberg>
there's via fencing all over the place
<azonenberg>
I'm not worried about it not being well grounded :p
<Degi>
Heh OK
<azonenberg>
Anyway so my plan is to do the mounting holes on MEAD in a few minutes (still finishing breakfast) then hold off on all of the plane routing etc for a bit
<azonenberg>
i need to sit down and think about the enclosure design
<azonenberg>
So actually i think i can make the holes line up with the MEAD board
<azonenberg>
just need a few mins to retool the bridge
<_whitenotifier-f>
[starshipraider] azonenberg pushed 2 commits to master [+1/-0/±2] https://git.io/JfPSi
<azonenberg>
gotta get to work but here's where i'm leaving off
<azonenberg>
the big slot provides access to all the front panel MMCX's, we can experiment with a tighter design with drilled holes later
<azonenberg>
the ring around the perimeter makes contact with the shield ring
<azonenberg>
The standoffs are predrilled with pilot holes suitable for a #4-40 UNF screw, we can tap them or use self-tapping screws as appropriate
<electronic_eel>
is it better to use the same holes as for board mounting or use different ones?
<azonenberg>
(refresh, accidentally uploaded an old version with too-big standoffs)
<electronic_eel>
if you use nylon standoffs between the boards, using the same ones might work
<azonenberg>
electronic_eel: you mean for top board to bottom one?
<azonenberg>
i was going to use metal standoffs for grounding
<electronic_eel>
yes
<electronic_eel>
or metal standoffs
<azonenberg>
my plan was to have the bottom board sit on the integral standoffs
<electronic_eel>
yes
<azonenberg>
put screws in the holes, slide a metal spacer onto them, then screw it down through the holes in the first board and into the integral standoffs
<azonenberg>
in the holes of the top board*
<azonenberg>
(after screwing the back side of the bottom board down so it doesn't wiggle around while you're doing this)
<azonenberg>
as of now i don't have any means to attach the lid to the box, i am probably going to make the left/right walls a little thicker and add tapped holes in the walls for a solid plate (with cutout for the LCD)
<electronic_eel>
but these are self tapping screws into plastic, right?
<azonenberg>
i havent put the hole in the back for the SFF connector either
<azonenberg>
Plastic or metal. Initial prototype will be nylon
<azonenberg>
but i'm thinking of aluminum for longer term
<electronic_eel>
can you put threaded inserts into the nylon version?
<azonenberg>
i mean i guess i could, but why? i'd be using coarse thread screws meant to go into plastic
<azonenberg>
this is a very common assembly technique
<azonenberg>
the 4-40 thread assumes we tap into aluminum
<electronic_eel>
yes, but only for stuff that is screwed once and never touched again
<azonenberg>
That is the intent here, at least for the time being
<azonenberg>
the adapter boards arent meant to be swapped
<electronic_eel>
with a threaded insert like M3 you can easily screw it in and out again
<azonenberg>
they're meant to be an alternative to two pcb designs
<electronic_eel>
the first development and beta boards will be rescrewed several times I think
<azonenberg>
the enclosure might need a redesign for, say, SMA inputs or something like that
<Degi>
Hmh I think you can rescrew self tapping screws a few times
<azonenberg>
yes, you can
<azonenberg>
i'm not too worried about it
<azonenberg>
3d printed enclosures are cheap and i dont plan to screw it down until i'm pretty sure it's good
<Degi>
In plastic they kinda loose holding force till they fall out after a few times though
<azonenberg>
nothing a bit of loctite or something wont fix. Or drilling out the hole and putting a threaded insert in, worst case
<Degi>
Tbh I've threaded a M5 hole into copper with a steel screw and a lot of force before lol.
<azonenberg>
it just seems like a lot of work for something not intended to be screwed often
<Degi>
Filling the hole with epoxy and drilling a new hole haha
<Degi>
Hm yes
<azonenberg>
That would work too lol
<electronic_eel>
we want them to hold tight, because otherwise the force from plugging/unplugging the mmcxs goes onto the sensitive connector
<azonenberg>
Hmm, good point
<Degi>
If we recess the PCB a bit, we could use the casing to support the PCB at the front too heh
<azonenberg>
But i still am targeting metal as the final enclosure material and plastic just as a cheap prototype
<Degi>
Like that only the MMCX stick out
<electronic_eel>
Degi: to hold the pcb, the case would need something to grab onto
<azonenberg>
Degi: the mmcx's will be flush with the inside wall of the box
<azonenberg>
electronic_eel: so i was thinking about that
<azonenberg>
the pcb will be almost touching the inside of the box - about 125 μm of clearance is my design target
<azonenberg>
so if you pull when unmating, the connector will flex slightly then the pcb will start touching the box and take up the load
<Degi>
For pushing you could add little nubs into the housing
<azonenberg>
that was exactly my thought
<electronic_eel>
so some design element on the case that goes behind the mmcx connectors?
<azonenberg>
it would go behind the whole PCB
<azonenberg>
the upper pcb
<electronic_eel>
ah, yeah
<azonenberg>
i could even make them be separate pieces you'd slide into place then screw down into a threaded hole on the side of the enclosure, to prevent any manufacturing issues from protrusions
<azonenberg>
and allow you to snug them up once the board is in
<electronic_eel>
or maybe something that goes onto the screw holes and could be screwed down too?
<electronic_eel>
it is 3d printed after all
<azonenberg>
Hmm, so a kind of hold-down bracket? yeah i'll think about it a bit and see what i can come up with
<azonenberg>
one of the problems i'm dealing with is that solvespace cannot import step or idf models generated by kicad
<azonenberg>
so i can't get the pcb directly into it
<azonenberg>
at least not in the version i'm using which is a little old
<electronic_eel>
hmm, that is unfortunate
<azonenberg>
i'm going to try updating at some point
<azonenberg>
i'm using version 2.3 which i think is a bit old
<azonenberg>
that's the december 2016 release :p
<azonenberg>
there has not been a stable release since but i suspect current git head has a lot of nice features
<electronic_eel>
3d modeling is something I haven't worked with yet, because freecad felt a bit cumbersome when trying and had some missing features
<electronic_eel>
and fusion360 is cloud only and doesn't run on linux
<electronic_eel>
the first could probably be hacked somehow
<azonenberg>
there's zero chance of me using some fancy cloud subscription software
<electronic_eel>
but I didn't investigate yet
<electronic_eel>
me too, just considering it if it can be hacked to run local only
<Degi>
Hmm theres OpenSCAD too
<electronic_eel>
ok, I'm going mountainbiking a bit until it gets dark
futarisIRCcloud has quit [Quit: Connection closed for inactivity]
<azonenberg>
Yeah that is a bug added when i converted from array-of-structs to struct-of-arrays format
<azonenberg>
i never tested usb after that
<miek>
ahh yeah, i see the commit now. oopsie
<miek>
i guess some automated regression tests on decoders would be a nice long term goal. useful for dev too, if they could be run standalone on a chunk of samples
<Degi>
Hmm are there plans for math functions yet?
<miek>
there are math functions!
<Degi>
Like integral and derivative?
<azonenberg>
Degi: we already have a few of them, more can be added. They're just nodes in the filter graph. No int/derivative but we could certainly implement that, file tickets against scopehal for each separately
<Degi>
Hmm I should take a look again later..
<azonenberg>
right now i think we only have waveform+scalar and waveform-waveform
<Degi>
And xy plotting?
<azonenberg>
as well as moving average
<azonenberg>
xy is an open ticket right now
<Degi>
Nice!
<azonenberg>
havent had time to work on it
<Degi>
Because then you coudl display hysteresis curves
<azonenberg>
the challenge to work out is that right now the x axis scale is an integer, not a float
<Degi>
For all plot types?
<azonenberg>
y axis is a float but x is currently int64 picoseconds to avoid roundoff errors in really long traces
<Degi>
Even like the CDR plots?
<azonenberg>
or int64 Hz for frequency domain
<azonenberg>
So e.g. we cannot display fractional Hz resolution FFTs
<Degi>
Oh
<azonenberg>
Yes, for all types. This is something that will likely have to be revisited when we do x-y plots
<Degi>
Why not int64 mHz or µHz or something like that. Though a float scalar would be nice
<Degi>
Like multiply the int value by the scalar to get the actual value
<azonenberg>
I could, i just chose Hz as the unit when i implemented the FFT filter
<azonenberg>
we could do dirty tricks or think about a more permanent solution
<azonenberg>
it's nontrivial and hasn't been enough of a priority for me to sit down and think about how to do it
<azonenberg>
as far as math functions in general go they're just nodes in the filter graph
<Degi>
I think the X and Y axis could both be ints with a float scalar
<Degi>
Hm okay
<miek>
azonenberg: on USB, the sync logic will have to change a bit. HS has 15 JK pairs then KK, but it's also valid for hubs to drop some of the JK pairs so the length is variable
<tverbeure2>
Do you have a DP Aux decoder laying around by any chance?
<_whitenotifier-f>
[scopehal] x44203 opened issue #138: Integral math function - https://git.io/JfP7i
<azonenberg>
tverbeure2: No, but that would be good to have
<_whitenotifier-f>
[scopehal] azonenberg opened issue #139: Add displayport aux channel protocol decode - https://git.io/JfP7M
<azonenberg>
I have one for ethernet as well as a less-nice one for usb that needs some revamping
<azonenberg>
building one for displayport is on my list but hasn't happened yet
<Degi>
How does it get the signal? A transmission line coupler?
<azonenberg>
Integrated 10:1 or 20:1, i cant recall which, resistive probe. With AC coupling IIRC
<azonenberg>
i also built the HDMI one before buying Sonnet so the impedance matching on the connectors isn't perfect. Up to 720p60 you can't see any issues on the eye patterns
<Degi>
Can it do 4k60? heh
<azonenberg>
but i suspect at 1080p or 4k it would start to degrade the signal. I plan to respin all of these fixtures
<azonenberg>
i dont know
<azonenberg>
my scope doesnt have the bandwidth to see that
<azonenberg>
when i have a 4 GHz scope i might be able to :p
<Degi>
Hmm a decode which decoes to an image would be fun
<azonenberg>
I have that for DVI already
<Degi>
Huh is 4k60 that fast
<azonenberg>
modulo the ram capacity of your scope
<Degi>
Nice
<azonenberg>
you can only grab a couple of scanlines with typical memory depths
<azonenberg>
depending on how much you oversample, you need to sample quite a bit fastr than the bit rate to do CDR
<Degi>
Huh yeah
<azonenberg>
4Kp60 is 0.53 Gpix/s
<tverbeure2>
I think I have some DP passthru breakout board somewhere. But I've never used it...
<azonenberg>
at 8 bit color depth that's 4.24 Gbps assuming zero line coding overhead and zero protocol overhead
<Degi>
Well then theoretically 2 GHz bandwidth could be maybe enough even, if you have like 8 GS/s or so
<azonenberg>
5.3 Gbps after the TMDS overhead, and more after blanking periods etc. 4kp60 is probably running in excess of 6 Gbps
<azonenberg>
So to do data recovery you'd need a 3 GHz scope minimum
<azonenberg>
to do SI you'd need quite a bit more
<Degi>
Well for SI you can use a sampling scope
<azonenberg>
Right now I have a waverunner 8104-ms which is 4ch 10 Gsps, interleavable to 2ch 20 Gsps, 1 GHz bandwidth, 200 Gsps equivalent time
<azonenberg>
and a hdo9204 which is 4ch 20 Gsps, interleavable to 2ch 40 Gsps, 2 GHz bandwidth
<Degi>
The HDO9204 may work
<azonenberg>
i've also negotiated but not closed on a deal to trade the waverunner plus a fair bit of cash for a waverunner 8404m-ms which is 4ch 20 Gsps, interleavable to 2ch 40 Gsps, 4 GHz bw
<Degi>
Maybe add an emphasis circuit for higher frequency omponents heh
tverbeure2 has quit [Quit: Leaving]
bvernoux has joined #scopehal
<miek>
huh, just found a weird quirk on my scope - it can only do maths on ch1 & ch2, or ch3 & ch4
<azonenberg>
miek: interesting
<azonenberg>
in general i dont use scope math functions in scopehal because ours tend to be faster
<miek>
i think they're all done in agilent's magic asic on this one, so they're fast - but i guess that's why they're quirky too :)
<azonenberg>
lol
<miek>
i _really_ need to get my desktop PC set up again, my laptop is not super happy about all this work. currently streaming sdr samples in at 128mbit & displaying it, while also probing the usb with glscopeclient
<azonenberg>
Lol
<azonenberg>
Yes, laptops are not meant for this kind of workload
<miek>
doesn't help that it's running two 1440p external monitors too, poor thing
<tnt>
miek: the agilent doesn't have equivalent time sampling at all right ? Or at least didn't find it on my 3000x.
<Degi>
Usu
<miek>
tnt: pretty sure mine doesn't
<Degi>
*Usually its somewhere under the timebase settings, though I've never used an agilent scope
<miek>
tnt: oh, huh! it does
<tnt>
At least the 3000-x doesn't. Just found FAQ: "Is there an equivalent time mode?" "No, there is not an equivalent time mode. The oscilloscope samples more than enough for the specified front end bandwidths."
<azonenberg>
can somebody file a ticket against scopehal for equivalent time sampling support at the API level? give it the "api" tag in the bug tracker
<Degi>
How do I give a tag?
<_whitenotifier-f>
[scopehal] x44203 opened issue #141: Equivalent time support at the API Level - https://git.io/JfPAu
<miek>
if you're not seeing the option on the right, you probably can't - it's usually limited to users with write access
<Degi>
Oof I forgot to add "sampling" is that bad?
<azonenberg>
ah ok i guess users w/o push access can't tag issues
<_whitenotifier-f>
[scopehal] x44203 edited issue #141: Equivalent time support at the API Level - https://git.io/JfPAu
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #141: Equivalent time support at the API Level - https://git.io/JfPAu
<_whitenotifier-f>
[scopehal] miek opened pull request #142: USB decoder fixes - https://git.io/JfPA9
<miek>
hmm, the 'count = 1' might be another casualty of the Waveform port - it feels out of place in that commit
<azonenberg>
let me see
<azonenberg>
on 207 in the version on master? pretty sure that's intentional, it's counting cycles since the start of a sync
<miek>
the problem i found was it was set to 1, then incremented before use in RefreshIterationSync so it ends up expecting the wrong symbol
<azonenberg>
hmm
<azonenberg>
so should be set to 0?
<azonenberg>
test on full speed to be sure
<miek>
that's what i've got in my hacks at the moment, but yeah i wasn't sure if full speed might depend on that or not
<azonenberg>
also yeowch
<miek>
?
<azonenberg>
Just got hit with a $250 customs bill from UPS for the last round of probe PCBs
<miek>
oof
<azonenberg>
that... was not priced into the original KS budget
<azonenberg>
lol
<azonenberg>
apparently now chinese PCBs have a 25% import tax
<miek>
ouuch
<azonenberg>
plus processing fees from UPS for it
<azonenberg>
still cheaper than buying them in the US but... yeah
<electronic_eel>
ouch
<electronic_eel>
did you give them a free pass to process the customs fee for you?
<azonenberg>
that's how UPS does things in general
<azonenberg>
they pay the import fees then send you a bill
<electronic_eel>
here in Germany the express shippers collect customs fees like this too, but they aren't allowed to collect it if they don't have an ok from you for it
<electronic_eel>
if you didn't give them an ok, you can just tell them to f** off
<azonenberg>
i had to give them my name and mailing address etc but they didnt tell me the amount of the fees in advance
<azonenberg>
also as far as i can tell i have to pay by two checks, one to UPS and one to customs
<azonenberg>
there does not appear to be any means of paying electronically
<electronic_eel>
here they don't give you the amount in advance too, but they have to get an ok that they should process it and bill you later
<electronic_eel>
theoretically you can also tell them to hand it over to another customs broker selected by you
<electronic_eel>
but they take a fee for that too, so nobody does it
balrog has joined #scopehal
<azonenberg>
Also i have a new favorite tip socket for the probe
<azonenberg>
ED11310-ND
<azonenberg>
seems to fit everything i've tried super snug
<monochroma>
azonenberg: oh?
<monochroma>
azonenberg: how does it compare to the official one?
<azonenberg>
i's super snug and doesnt wobble at all in my quick test. Not soldered on though, just testing in my hand under the microscope
<monochroma>
:D!
<monochroma>
shouldn't need to epoxy the tip now?
<azonenberg>
yeah
<monochroma>
cool!
bvernoux has quit [Quit: Leaving]
<electronic_eel>
0.635-0.94mm leads accepted, that is good. but it looks super short in the ds
<azonenberg>
It is short
<azonenberg>
The tip sticks out by 100um or so but i dont think that will hurt anything
<azonenberg>
i have a deeper one i'll use for the grounds
<electronic_eel>
won't soldering it on close the end?
<azonenberg>
It shouldn't. But i'll test
<azonenberg>
i have like six different sockets here i'm evaluating
<azonenberg>
this one just came in and looks promising but isnt fully tested yet
<electronic_eel>
if you can stick stuff through, then the length shouldn't be an issue
<azonenberg>
You can stick stuff through. it's an open back
<electronic_eel>
probably just have to be careful not putting on too much solder paste
<azonenberg>
The problem is that there are three different shapes of tip/ground
<azonenberg>
round 0.76 mm, square (i forget the size), and a kind of barbed shape
<azonenberg>
i need to fit all 3 well
<azonenberg>
many sockets work great with one or two
tverbeure has joined #scopehal
<azonenberg>
electronic_eel: the one concern i have with that socket right now is that i had trouble getting the wide blade ground out of it. the barbed back end kinda stuck
<azonenberg>
so i need to do more testing. i might make it a tip socket only and use something else for the grounds?
<azonenberg>
or use the very similar, deeper socket i'm also considering
<electronic_eel>
I received the millmax pins and sockets I ordered to do some testing with bare wires and solder-on plugs
<electronic_eel>
will have to do some testing with those too