<_whitenotifier-f>
[scopehal] azonenberg closed issue #280: Allow sample rate/memory depth of SignalGeneratorOscilloscope to be changed - https://git.io/JUPVO
Degi has quit [Ping timeout: 272 seconds]
Degi has joined #scopehal
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±6] https://git.io/JTUi4
<_whitenotifier-f>
[scopehal-apps] azonenberg 7ba0cd6 - When deleting a channel or closing a protocol analyzer window, destroy the analyzer window if there are no other references. Fixes #177.
<_whitenotifier-f>
[scopehal-apps] azonenberg closed issue #177: Protocol analyzer window keeps reference open to attached decoder even when hidden - https://git.io/JUEul
<_whitenotifier-f>
[scopehal] azonenberg commented on issue #151: Add support for configuring channel bit depth on LeCroy HDO9000 series - https://git.io/JTUiE
electronic_eel has quit [Ping timeout: 256 seconds]
electronic_eel has joined #scopehal
<azonenberg>
https://www.antikernel.net/temp/sata2.png SATA 6 Gbps through an AKL-PT1 v1.2. Link remained up with no obvious issues and the 8b10b seems to look right
<azonenberg>
havent actually tried writing a decode for it yet
JSharp has quit [Ping timeout: 240 seconds]
JSharp has joined #scopehal
StM_ has joined #scopehal
StM has quit [Ping timeout: 240 seconds]
_whitelogger has joined #scopehal
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JTUp9
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JTUp5
<_whitenotifier-f>
[scopehal-apps] azonenberg 792b33d - WaveformArea: now use Unit framework for pretty printing UIs and bit rate in eye pattern infobox
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JTTYM
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JTTOO
<_whitenotifier-f>
[scopehal] azonenberg 1b6bd46 - FlowGraphNode: fixed bug where calling SetInput() with the current input could free a filter we were still using
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #224: Figure out how to have units in FilterParameter's that change type based on the input - https://git.io/JTTZo
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #224: Figure out how to have units in FilterParameter's that change type based on the input - https://git.io/JTTZo
<azonenberg>
usb-sata dongle opened up and mated to a SSD i had lying around, i think from my old laptop
<azonenberg>
rev 1.2 AKL-PT1 probe going from... RX, I think, data+ to the adjacent ground, then a DC block, then 6 feet of cdint RG188 to the scope
<azonenberg>
The eye you see is with the probe and cable de-embedded
<lain>
:D
<azonenberg>
And the link didn't drop or see any obvious issues
<bvernoux>
woo sata with 1.2 AKL-PT1 is very not bad
<bvernoux>
Do you have checked if it can be decoded ?
<bvernoux>
IIRC there is no decoder for that today I think
<bvernoux>
It is quite good to pick that as it is natively differential signal and here you are using singled ended probe
<azonenberg>
bvernoux: there is not a sata decoder, i actually have the sata spec up on another monitor so i can start working on it after i do some other stuff
<azonenberg>
however the line coding is 8b10b and it appears to be decoding plausibly
<azonenberg>
no disparity errors or invalid characters
<azonenberg>
also my LeCroy WL-PBUS just shipped from Tel Aviv. Should be here around the end of this month
<azonenberg>
i'm ordering the first of the two 4 GHz active diff probes i'm buying a week from monday (just waiting till i get paid lol)
<azonenberg>
i plan to do some side by side tests on 1000base-X, 10Gbase-R, and 6 Gbps SATA of my current probes, the 4 GHz differential probes, and the AKL-PT1
<azonenberg>
By the time the diff probes come in, i should have AKL-PT1 v1.3 as well which is hopefully going to be even better than 1.2
<azonenberg>
shifting the tip resonance up another 0.75 GHz or so
<bvernoux>
yes nice
<bvernoux>
on my side I'm planning to buy stuff on batronix ;)
<bvernoux>
I'm checking that TekBox TBPS01-TBWA2/40dB
<azonenberg>
oh and then the first experimental solder in probes are at oshpark hopefully shipping late this month too
<bvernoux>
it is good for EMC Precompliance up to 6GHz
<azonenberg>
the AKL-PT2 and PT3
<azonenberg>
will probably test them out on the sata dongle too
<bvernoux>
ha yes very good to test on a "real"
<bvernoux>
3GHZ signal 6Gbps
<azonenberg>
maybe use one for tx and the lecroy probe for rx and see how they compare or something
<bvernoux>
USB 3.0 signal could be nice also
<azonenberg>
I can only do so many things at once :)
<bvernoux>
needs a "breakout" for USB 3.x ;)
<azonenberg>
I have several test fixtures planned
<azonenberg>
i have a usb2 fixture that needs a total revamp
<azonenberg>
i also want to improve the ethernet one for higher performance too
<azonenberg>
and once i upgrade sonnet more i want to do full s-parameter de-embed calibration on the fixtures
<azonenberg>
i should be able to simulate the response of the channel from the tip of the integrated probe to the sma launch
<azonenberg>
then de-embed that plus the cable from the measured waveform
<bvernoux>
or maybe wait a bit to try OpenEMS ;)
<bvernoux>
lot of nice stuff are planned in Qucs-RFlayout
<bvernoux>
which could be on par with Sonnet for some stuff
<azonenberg>
maybe in a few years, i dont think it's ready yet
<bvernoux>
anyway at end the simulation is never enough accurate and requires few prototypes to adjust things ...
<bvernoux>
I'm confident qucs-rflayout shall be very usable soon
<bvernoux>
also tapper is planned
<bvernoux>
main issue with Sonnet is you shall buy more and more from them without any warranty it answer your problematic
<electronic_eel>
bvernoux: about the tekbox near field probes. I have the probes themselves, and they work well and are good quality
<electronic_eel>
bvernoux: but I didn't get the preamp from them. I have a preamp on my spectrum analyzer and their preamp seems quite expensive for what it is
juli965 has joined #scopehal
bluecmd[m] has quit [*.net *.split]
smkz has quit [*.net *.split]
smkz has joined #scopehal
bluecmd[m] has joined #scopehal
bluecmd[m] has quit [Ping timeout: 244 seconds]
jevinskie[m] has quit [Ping timeout: 260 seconds]
maartenBE has quit [Ping timeout: 246 seconds]
maartenBE has joined #scopehal
<bvernoux>
electronic_eel, yes I was also planning to buy only the probes
bluecmd[m] has joined #scopehal
jevinskie[m] has joined #scopehal
katharina has joined #scopehal
<katharina>
azonenberg: you think we should make the preferences manager object a global singleton?
<azonenberg>
katharina: hmmm
<azonenberg>
Yes, probably
<azonenberg>
having preferences scoped to the window or something else doesn't really make sense IMO
<azonenberg>
the only other meaningful alternative is a singleton and those are just another way to represent globals
<katharina>
yea global i just said since thats the effect, ill use a singleton
<katharina>
can you give me some examples to populate the settings tree to test my dialog?
<katharina>
like what kinds of nested categories youd like
<azonenberg>
Let me go through some of my ntoes and tickets
<azonenberg>
oh, we should also have support for preferences that don't show in the dialog
<azonenberg>
Things like recently used files, or the current trace opacity setting
<azonenberg>
they should be silently remembered when you close glscopeclient but there's no reason a user would want to change the preference explicitly as there's another UI for it
<azonenberg>
ok so... Protocol decode field colors will be under Display.Colors.Decode.x
<azonenberg>
Bools for Privacy.SaveScopePathInFiles, Privacy.SaveScopeMakeAndModelInFiles, Privacy.SaveScopeSerialInFiles
<_whitenotifier-f>
[scopehal-apps] nshcat opened issue #225: Preferences system should support "hidden" settings - https://git.io/JTktc
<_whitenotifier-f>
[scopehal-apps] nshcat assigned issue #225: Preferences system should support "hidden" settings - https://git.io/JTktc
<_whitenotifier-f>
[scopehal-apps] nshcat labeled issue #225: Preferences system should support "hidden" settings - https://git.io/JTktc
<azonenberg>
Enum for Privacy.ShowScopeSerialInTitleBar (legal values = hide, show full, show only last 2 digits)
<azonenberg>
Hidden vector<string> for General.File.RecentlyUsed (this will probably just be like ten separate sequentially numbered prefs unless you want to add array support)
<azonenberg>
Hidden float for Display.Waveform.Opacity
<azonenberg>
(oh, also hide tree nodes if all prefs under the node are hidden)
<azonenberg>
We should also have a recently used list for instruments to connect to but i haven't figured out the details of that
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #226: Add preferences, menu item, etc for "recent instruments" list - https://git.io/JTktj
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #226: Add preferences, menu item, etc for "recent instruments" list - https://git.io/JTktj
<azonenberg>
Enum for Display.Toolbar.IconSize (values = 24x24 and 48x48 for now)
<azonenberg>
Enum for Display.Toolbar.ButtonStyle (TextOnly, TextAndIcon, Icon)
<azonenberg>
a bunch of stuff under Display.Colors.Cursor
<azonenberg>
Hidden vector<string> for General.Instruments.RecentlyUsed
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #227: Preference system should support Pango::FontDescription's - https://git.io/JTkqa
<_whitenotifier-f>
[scopehal-apps] azonenberg labeled issue #227: Preference system should support Pango::FontDescription's - https://git.io/JTkqa
<katharina>
gotcha
<azonenberg>
Fonts for Display.Text.AxisLabelFont, Display.Text.InfoBoxFont, Display.Text.CursorLabelFont, Display.Text.DecodeOverlayFont
<katharina>
ill definitely PR this before implementing vectors and fonts etc
<katharina>
so we finally have something in master
<azonenberg>
Yeah i'm thinking ahead
<katharina>
thats fine
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #228: Add preference for WaveformArea::m_*Font - https://git.io/JTkqX
<Degi>
Is there something like the INA293 but it can measure currents in both directions?
<azonenberg>
I believe the INA226 can measure positive or negative differentials at the shunt (but that's got an integrated ADC)
<Degi>
Hmh their ADC is kinda slow
<azonenberg>
Yeah its meant for power rail monitoring
<azonenberg>
The INA199 is single supply so that wont work
<azonenberg>
(so is the 226 but i guess they have internal virtual grounds or something)
<Degi>
Hmm, the INA199 looks fine, besides that it can't do 100 V (I think my design goal is about 60 V, but some headroom would be good since there are a bunch of unknowns)
<Degi>
Oh, the INA240 looks perfect.
<katharina>
Ouff, for some reason storing pointers in a treemodel just always results in nullptr being retrieved, thats so odd
<katharina>
i must be doing something wrong, thats not right at all
<azonenberg>
Huh
bvernoux has quit [Quit: Leaving]
<azonenberg>
I can't say i've ever tried, but i see no reason why it would fail
<katharina>
the funny part is that this isnt some weird race condition - storing the pointer and immediately retrieving it already yields nullptr
<azonenberg>
Weeeird. did you not add the column to the model or something?
<azonenberg>
Also why would you need to do that? my thought was to have the left side tree just store the strings themselves, then traverse the tree path to figure out the hierarchical location
<azonenberg>
so you can decide how to populate the main dialog area
<azonenberg>
but i'm not sure how your pref system is structured internally
<katharina>
well the problem was between display and keyboard ;P not added it to the model.
<katharina>
not completely up to my game yet haha
<azonenberg>
lol
<azonenberg>
That would do it
<Bird|otherbox>
katharina, I'd be more inclined to make it a global instead of a singleton
<katharina>
Bird|otherbox: Any reason for that opinion? im curious why
<Bird|otherbox>
basically, it's a lot easier to deal with code if its not trying to enforce its own...one-ness, that invariant is better maintained externally
<Bird|otherbox>
(i.e. singletons interfere with testability and whatnot)
<Bird|otherbox>
if there's some big application object, for that matter, one could put the preferences there (not sure how Gtkmm apps do it tho)
<katharina>
interesting
<azonenberg>
Bird|otherbox: yes there is an application object, although i'd be more inclined to do it as a pure-play global just to avoid having to type "g_app->" constantly when accessing preferences
<azonenberg>
Bird|otherbox: btw since you're here, how's the static analysis stuff going?
<Bird|otherbox>
azonenberg: trying to figure out a spurious warning from g++ with the way I have clang-analyzer rigged
<azonenberg>
How far are you from being able to merge at least cppcheck support?
katharina has quit [Quit: Lost terminal]
<Bird|otherbox>
I could PR what I have now if you don't mind the compiler complaining about ignoring a linker input file since it isn't linking
<azonenberg>
if it doesn't break the current build, then go for it
<azonenberg>
My general rule with contributions is that the net functionality of the system should be the same or greater after a merge than before
<azonenberg>
i.e. it's OK to add new code that doesn't quite work as long as nothing previously working broke
<azonenberg>
This may change once we get to the point of approaching a stable release, where we want to avoid things that silently fail or act confusing to new users etc
<azonenberg>
But at this stage of maturity, i'm not worried about that
<azonenberg>
i'd rather have stuff accessible to all developers sooner rather than later
<_whitenotifier-f>
[scopehal-apps] tarunik opened pull request #229: Add static analyzer support (CPPCheck and clang-analyzer, at the moment) for #180 - https://git.io/JTkCS
<azonenberg>
Bird|otherbox: and you plan to keep the ticket open until you've fixed this warning? any other problems pending? or other analyzers you want to add?
<Bird|otherbox>
clang-tidy's the other analyzer I'd want to add
<Bird|otherbox>
and yeah, I'm thinking I'll keep the ticket open until the warning's fixed
<_whitenotifier-f>
[scopehal-apps] azonenberg closed pull request #229: Add static analyzer support (CPPCheck and clang-analyzer, at the moment) for #180 - https://git.io/JTkCS
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 6 commits to master [+0/-0/±6] https://git.io/JTkWI
<_whitenotifier-f>
[scopehal-apps] tarunik 6aad56b - Add initial support for cmake -DANALYZE=true for #180. This currently works with cppcheck on Linux using CMake's built-in support.
<_whitenotifier-f>
[scopehal-apps] tarunik 826926d - Enable warnings and add detection support for CPPCheck to -DANALYZE=true for #180.
<_whitenotifier-f>
[scopehal-apps] tarunik 03eedf1 - Configure cppcheck to suppress messages from libsigc++ headers for #180.
<_whitenotifier-f>
[scopehal-apps] ... and 3 more commits.
<azonenberg>
Looks good so far, it detects cppcheck and not clang-analyzer. which is good because i didn't have it installed
<_whitenotifier-f>
[scopehal-apps] azonenberg opened issue #230: Figure out CMake libgl/libglvnd warning - https://git.io/JTkWz
<_whitenotifier-f>
[scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JTkRN
<_whitenotifier-f>
[scopehal-apps] azonenberg 28cd36e - Added -q option to cppcheck to suppress "checking file" messages
Pretzel4Ever has joined #scopehal
Pretzel4Life has quit [Quit: Leaving...]
<azonenberg>
o/ Pretzel4Ever
<azonenberg>
Bird|otherbox: hmm, getting cppcheck warnings related to calling virtual functions in Socket/UART from the constructor
<azonenberg>
makes me wonder why those functions are virtual at all?
<azonenberg>
nothing i know of derives from them
<azonenberg>
I think i'm gonna un-virtual them, will solve the warning and also make socket calls a tiny bit faster
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JTkEW
<_whitenotifier-f>
[scopehal] azonenberg 31f5270 - Updated to latest xptools
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±1] https://git.io/JTkuO
<_whitenotifier-f>
[scopehal] azonenberg 8f30ba8 - Updated xptools again
<azonenberg>
So i guess the plan is i'm gonna go through the current analysis results, fix the low-hanging fruit, file tickets for harder stuff, maybe add suppressions for false positives
<azonenberg>
then probably work on adding bandwidth limits to the Tek MSO driver and then probably adding support for more trigger types
<_whitenotifier-f>
[scopehal] azonenberg opened issue #305: Add "auto zero" method to zero differential probes - https://git.io/JTkzg
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #305: Add "auto zero" method to zero differential probes - https://git.io/JTkzg
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #305: Add "auto zero" method to zero differential probes - https://git.io/JTkzg
alexhw_ has joined #scopehal
alexhw has quit [Ping timeout: 260 seconds]
<azonenberg>
interesting observations between LeCroy and Tek protocol offerings: they seem to have about the same set of decodes
<azonenberg>
Tek cannot trigger on I3C, while LeCroy can
<azonenberg>
LeCroy cannot trigger on 10/100 Ethernet, Tek can
<azonenberg>
Tek can trigger on SENT, LeCroy cannot
<azonenberg>
Tek can trigger on ARINC 429, LeCroy cannot
<azonenberg>
Neither can trigger on SpaceWire
<azonenberg>
Neither can trigger on 100base-T1 aka BroadR-Reach aka Automotive Ethernet
<azonenberg>
So basically tek has triggers for more protocols, but if you need to trigger on I3C LeCroy is the way to go
<_whitenotifier-f>
[scopehal] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JTkao
<_whitenotifier-f>
[scopehal] azonenberg 5779248 - TektronixOscilloscope: improved parsing of option codes for MSO5/6 series. Implemented GetChannelBandwidthLimiters() for MSO5/6
<Bird|otherbox>
good catch on the glibmm headers, didn't notice those
<Bird|otherbox>
also? I3C? are you referring to I2C?
<_whitenotifier-f>
[scopehal] azonenberg opened issue #306: Pass args to SCPITransport ctor by const ref - https://git.io/JTkrO
<_whitenotifier-f>
[scopehal] azonenberg labeled issue #306: Pass args to SCPITransport ctor by const ref - https://git.io/JTkrO