02:22 <_whitenotifier-f> [scopehal] azonenberg pushed 1 commit to master [+0/-0/±3] https://git.io/JT0hb

02:22 <_whitenotifier-f> [scopehal] azonenberg 27a5639 - FilterParameter: added m_fileIsOutput. Fixes #303.

02:22 <_whitenotifier-f> [scopehal] azonenberg closed issue #303: FilterParameter: add hint to allow filename type to be specified as input or output - https://git.io/JTUC0

02:23 <_whitenotifier-f> [scopehal-apps] azonenberg pushed 1 commit to master [+0/-0/±2] https://git.io/JT0hA

02:23 <_whitenotifier-f> [scopehal-apps] azonenberg fba3098 - FilterDialog: check m_fileIsOutput and update UI accordingly

03:00 <azonenberg> So, i just did some additional modeling of the AKL-PT2 to see what i can do about losses

03:01 <azonenberg> Right now, the loss at 5 GHz as measured by the VNA is -4.5 dB. Using 5 GHz rather than 6 because there's some kind of resonance at around 5.8 that i'm ignoring

03:03 <azonenberg> Simulated loss for bare copper (so conductor and dielectric losses only) is 1.19 dB

03:03 <azonenberg> -1.19*

03:03 <azonenberg> and -1.79 dB with coverlay/soldermask

03:04 <azonenberg> assuming reasonably typical Er/Df values of 3.66 / 0.02

03:05 <azonenberg> Assuming no loss elsewhere in the system, the delta from bare copper to measured is -3.3 dB. The line is about 5.5 inches long so that comes out to -0.6 dB/inch of extra loss beyond simulation

03:06 <azonenberg> Some of that is probably copper roughness effects which none of my sims model, but that number does sound about the right order of magnitude for ENIG losses

03:07 <azonenberg> Assuming somewhat arbitrarily that 0.2 dB of that 0.6 dB/in is roughness and other effects i can't do much about, and 0.4 are plating losses

03:08 <azonenberg> this means we should expect about 1.1 dB more loss than simulation across the board if we use something other than ENIG

03:09 <azonenberg> This suggests that if I go with soldermask/coverlay on the flex rather than leaving it all as bare ENIG, I should expect approximately -1.79 + -1.1 = -2.89 dB of insertion loss at 5 GHz

03:10 <azonenberg> And if I go with immersion silver, I should expect roughly -1.19 + -1.1 = -2.29 dB at 5 GHz

03:10 <azonenberg> which roughly means we should expect the masked probe to be 5 GHz bandwidth and the silver version to be around 6

03:10 <azonenberg> up from the 3 GHz of the current all-ENIG prototype

03:11 <azonenberg> i've already ordered a round two enclosure for the AKL-PT2 so i think what i'm going to do now is make a few tweaks to the soldermask layout on the PT2 and send another iteration out to oshpark with soldermask and see how close performance is to these models

04:21 <_whitenotifier-f> [scopehal-apps] kench synchronize pull request #238: Add continuous integration configuration - https://git.io/JTBz6

04:26 <_whitenotifier-f> [scopehal-apps] kench synchronize pull request #238: Add continuous integration configuration - https://git.io/JTBz6

04:31 <_whitenotifier-f> [scopehal-apps] kench synchronize pull request #238: Add continuous integration configuration - https://git.io/JTBz6

04:42 <_whitenotifier-f> [scopehal-apps] kench synchronize pull request #238: Add continuous integration configuration - https://git.io/JTBz6

04:46 <_whitenotifier-f> [scopehal-apps] kench synchronize pull request #238: Add continuous integration configuration - https://git.io/JTBz6

04:47 <Kenley> Just checking first - y'all have no problems with merging and squashing my pull request when it's ready, right?

04:52 <_whitenotifier-f> [scopehal-apps] kench synchronize pull request #238: Add continuous integration configuration - https://git.io/JTBz6

04:59 <azonenberg> Kenley: Yeah I'm waiting for you to declare it finished then i'll give it a quick review and we can go merge

05:02 <Kenley> Most of the commits are me trying to figure out GitHub Actions steps, but I have Linux running and it looks like it's going to pass.

05:02 <azonenberg> Grreat. Where are you with Windows support?

05:03 <azonenberg> Also if you'd prefer, I'm OK with merging a Linux-only CI setup to master first so we can do larger scale testing with actual project commits etc as development proceeds

05:03 <azonenberg> Then you can work on windows support and merge separately when it's ready

05:03 <Kenley> Just starting Windows support now.

05:04 <Kenley> Let me clean some stuff up first.

05:04 <_whitenotifier-f> [scopehal-apps] kench synchronize pull request #238: Add continuous integration configuration - https://git.io/JTBz6

05:05 <_whitenotifier-f> [scopehal-apps] kench synchronize pull request #238: Add continuous integration configuration - https://git.io/JTBz6

05:06 <Kenley> azonenberg: Feel free to merge and squash now for Windows!

05:07 <Kenley> https://github.com/kench/scopehal-apps/actions/runs/319132648

05:08 <azonenberg> Kenley: it says "we are currently unable to download the log" when i try to view build output

05:08 <Kenley> for Linux

05:09 <Kenley> It shows for me.

05:09 <azonenberg> Hmm, permissions problem somewhere?

05:10 <Kenley> Sent you an invite as a collaborator.

05:10 <Kenley> I can summarize it as "the log output shows that glscopeclient can build successfully"

05:10 <azonenberg> Yeah, it's more "the log output should be publicly viewable and isn't"

05:11 <azonenberg> oh, derp

05:11 <Kenley> What happened?

05:11 <azonenberg> it was on my end, just had to add a noscript exception

05:11 <Kenley> LOL

05:11 <azonenberg> new subdomain i didn't have whitelisted

05:11 <azonenberg> Ok so, suppose i merge this build.yml

05:12 <azonenberg> what do i have to do on the repo to configure CI to actually execute?

05:12 <Kenley> Nothing.

05:12 <azonenberg> github does it automatically?

05:12 <Kenley> GitHub Actions is built-in.

05:12 <Kenley> Yep.

05:12 <azonenberg> Interesting

05:12 <Kenley> It's that magical.

05:13 <_whitenotifier-f> [scopehal-apps] azonenberg closed pull request #238: Add continuous integration configuration - https://git.io/JTBz6

05:13 <_whitenotifier-f> [scopehal-apps] azonenberg pushed 1 commit to master [+1/-0/±0] https://git.io/JTEYa

05:13 <_whitenotifier-f> [scopehal-apps] kench 111e088 - Add continuous integration configuration (#238) * Add initial .travis.yml file Add initial Travis CI configuration for Linux * Update Travis CI Ubuntu version. The default Ubuntu version (Xenial) used by Travis CI does not have liblxi available. * Fix build script * Add experimental Windows build * Fix syntax issue with .travis.yml * Add Linux build GitHub Action * Update

05:13 <_whitenotifier-f> linux-build.yml * Update linux-build.yml * Update linux-build.yml * Update linux-build.yml * Update linux-build.yml * Update linux-build.yml * DEBUG - Get directory listing * Fix working directory for build command * Recursively checkout submodules * Delete .travis.yml * Update and rename linux-build.yml to build.yml

05:13 <Kenley> I was very skeptical at first, but it's pretty fantastic.

05:15 <azonenberg> So now i guess i have to figure out how to push outputs to irc

05:16 <_whitenotifier-f> [scopehal-apps] kench forked the repository - https://git.io/JTBRg

05:20 <azonenberg> But that's a lower priority

05:22 <azonenberg> Kenley: so one thing i would like to do longer term is do builds with static analysis (cmake -DANALYZE=1) however this is currently very slow and also has a bunch of false positives Bird|otherbox is still working on

05:22 <azonenberg> Don't turn it on yet

05:22 <azonenberg> but just a FYI

05:30 <_whitenotifier-f> [scopehal-apps] azonenberg commented on issue #191: Channel properties dialog should allow reading/writing display names of channels on the hardware - https://git.io/JTE3q

05:30 <_whitenotifier-f> [scopehal-apps] azonenberg closed issue #191: Channel properties dialog should allow reading/writing display names of channels on the hardware - https://git.io/JUam3

05:35 <_whitenotifier-f> [scopehal-apps] azonenberg labeled issue #241: Unit testing - https://git.io/JTE3K

05:35 <_whitenotifier-f> [scopehal-apps] azonenberg opened issue #241: Unit testing - https://git.io/JTE3K

05:38 <azonenberg> Kenley: So from talking to some folks, it seems like running one action upon completion of another generally doesn't work

05:38 <azonenberg> And the easiest way to get IRC notifications from a build is to actually have the build itself run a script that pushes a notification to irc

05:39 <azonenberg> Can you look into doing that after you've got the windows build figured out?

05:39 <Kenley> Makes sense.

05:39 <Kenley> Can do.

05:39 <azonenberg> Great thanks

05:40 <azonenberg> If you want to tackle unit testing (#241) as well, that would be nice longer term. But it's not a rush, there's no point in having a test framework set up until we have something for it to run

05:41 <azonenberg> For the short term, scope drivers will not be testable offline. This isn't great, as most of libscopehal is actually hardware drivers

05:41 <azonenberg> but unless we had a huge farm of scopes dedicated to testing i don't see a viable way to do it

05:41 <Kenley> Is libscopehal a shared library?

05:41 <azonenberg> Yes

05:42 <azonenberg> as is libscopeprotocols, which is a separate so under the same repo

05:42 <azonenberg> roughly speaking scopehal is hardware drivers and base classes, scopeprotocols is filters and protocol decodes

05:42 <azonenberg> The LeCroy driver might be possible to test on a dedicated worker node if you installed MAUI Studio, which is basically LeCroy's scope firmware repackaged to run standalone

05:42 <Kenley> I think decoupling the libscopehal / libscopeprotocols build from scopehal-apps allows for better isolation and tracing of issues.

05:43 <azonenberg> Yes I think so too, but that's a longer term todo

05:43 <azonenberg> Having all of the tests and build infrastructure under scopehal-apps, while it may not be ideal, is better than no tests at all

05:43 <Kenley> True.

05:44 <azonenberg> Anyway, back to what i was saying, i do not see scopehal as being testable for the most part for the foreseeable future

05:44 <azonenberg> scopeprotocols i think we can develop a test suite for

05:44 <Kenley> Update on Windows build. The first successful build should be completing in a few minutes. :)

05:44 <azonenberg> since it can run in isolation without needing real hardware, we just need canned test vectors and/or a procedural input generator

05:45 <azonenberg> I think we should use procedural inputs whenever possible because they're a) smaller and b) easier to understand for debug

05:47 <azonenberg> basically i want to fuzz our decodes

05:47 <azonenberg> by generating plausible inputs and adding noise or occasional errors to them

05:47 <Kenley> I might need your help troubleshooting the Windows build. I'm seeing the same OOM and header issues that I saw in Travis.

05:47 <Kenley> https://github.com/kench/scopehal-apps/runs/1284991223?check_suite_focus=true

05:47 <azonenberg> And develop a framework for doing this

05:48 <azonenberg> Hmmm

05:48 <azonenberg> bvernoux: if you're around, want to look into this?

05:48 <azonenberg> have you ever seen this issue? i know you've done windows builds

05:51 <_whitenotifier-f> [scopehal] azonenberg labeled issue #313: Refactoring: pull waveform generation functions out of DemoOscilloscope and make them global - https://git.io/JTEGs

05:51 <_whitenotifier-f> [scopehal] azonenberg opened issue #313: Refactoring: pull waveform generation functions out of DemoOscilloscope and make them global - https://git.io/JTEGs

05:51 <_whitenotifier-f> [scopehal] azonenberg labeled issue #313: Refactoring: pull waveform generation functions out of DemoOscilloscope and make them global - https://git.io/JTEGs

05:56 <Kenley> I'm going to bed. Happy Tuesday.

05:58 <_whitenotifier-f> [scopehal-apps] azonenberg opened issue #242: Develop initial proof-of-concept unit test for FrequencyMeasurement filter - https://git.io/JTEGh

05:58 <_whitenotifier-f> [scopehal-apps] azonenberg labeled issue #242: Develop initial proof-of-concept unit test for FrequencyMeasurement filter - https://git.io/JTEGh

07:16 <_whitenotifier-f> [scopehal-apps] azonenberg commented on issue #239: Continuous integration setup - https://git.io/JTE8X

08:06 <_whitenotifier-f> [scopehal] azonenberg pushed 2 commits to master [+2/-0/±5] https://git.io/JTEEm

08:06 <_whitenotifier-f> [scopehal] azonenberg 7cfe661 - Refactored TestWaveformSource into a separate class. Fixes #313.

08:06 <_whitenotifier-f> [scopehal] azonenberg 771ccf8 - TestWaveformSource: noise_amplitude is now an argument

08:06 <_whitenotifier-f> [scopehal] azonenberg closed issue #313: Refactoring: pull waveform generation functions out of DemoOscilloscope and make them global - https://git.io/JTEGs

10:30 <_whitenotifier-f> [scopehal] azonenberg pushed 2 commits to master [+2/-0/±10] https://git.io/JTEX1

10:30 <_whitenotifier-f> [scopehal] azonenberg bc6b3d6 - Initial skeleton of TestCase. Refactored TestWaveformSource to take an external mt19937 object to allow deterministic seeding.

10:30 <_whitenotifier-f> [scopehal] azonenberg f6d9c69 - Various improvements to TestCase class needed for unit testing

10:31 <_whitenotifier-f> [scopehal-apps] azonenberg pushed 2 commits to master [+4/-0/±2] https://git.io/JTEXF

10:31 <_whitenotifier-f> [scopehal-apps] azonenberg 9e0de80 - Initial test case for FrequencyMeasurement filter. Fixes #242.

10:32 <_whitenotifier-f> [scopehal-apps] azonenberg cf7d9a7 - Merge branch 'master' of github.com:azonenberg/scopehal-apps

10:32 <_whitenotifier-f> [scopehal-apps] azonenberg closed issue #242: Develop initial proof-of-concept unit test for FrequencyMeasurement filter - https://git.io/JTEGh

10:35 <azonenberg> Bird|otherbox: https://www.antikernel.net/temp/testcase.png

10:36 <_whitenotifier-f> [scopehal-apps] azonenberg commented on issue #241: Unit testing - https://git.io/JTE1R

11:37 <Bird|otherbox> azonenberg: nice :)

11:38 <azonenberg> How's the static analysis stuff going?

11:38 <azonenberg> also, is it cppcheck or clang-analyzer that's being so slow?

11:38 <azonenberg> when i run analysis without -j it takes an hour or more to run

11:39 <Bird|otherbox> I need to rework my repo to get the forks out of it

11:39 <Bird|otherbox> I'm not sure, I'd have to wallclock it and find out

11:39 <azonenberg> Because i would love to get analysis running as part of the CI process

11:39 <azonenberg> but i feel like github wouldn't be happy with an 8-hour build :p

11:40 <Bird|otherbox> also: the fix for the noreturn warnings is just adding a -D__GNUC__ to the cppcheck invocation

11:40 <azonenberg> oh that's easy lol

11:41 <azonenberg> send a PR for that asap and i'll close the issue

11:42 <azonenberg> anyway, between you and Kenley hopefully we can get a much nicer build/test process going. Long term i want CI builds to include both static analysis and unit tests

11:43 <azonenberg> speaking of which, we also need people to write test cases for filters... I did this one but building tests for the entire suite of filters we support will take a long time

11:43 <azonenberg> especially more complex ones like Ethernet frames if we want to actually fuzz the decodes with random data rather than just playing back a scope waveform

11:44 <azonenberg> long term i think that's what we need for robustness though

15:12 <_whitenotifier-f> [scopehal-apps] fspadini forked the repository - https://git.io/JvRcy

22:42 <Bird|otherbox> azonenberg: re: testing: have you looked at Catch2?

23:14 <azonenberg> Bird|otherbox: No

23:15 <azonenberg> CTest is the only unit test framework i have experience with other than the homegrown one i used in my thesis for hardware-in-loop testing

23:15 <azonenberg> I dont care what we use as long as it works and is easy to configure

23:16 <Bird|otherbox> ah, I've had a good time with Catch2 @ $work -- it's pretty much the epitome of "does not need configuration" (header-only, even)

23:32 <azonenberg> Did you look at my test case?

23:33 <azonenberg> It was structured for the CTest convention - not sure what other tools do

23:33 <azonenberg> where you have one binary per test case where main() returns success or failure