Hi everyone, *(Apologies to Cyrille for the double email in your inbox—I accidentally hit 'Reply' instead of 'Reply All' on my first attempt! Posting my response here for the community.)*
Thank you *Cyrille * for taking the time to read the proposal and for the specific, actionable feedback it made the revision much cleaner. I have updated the proposal to address both points directly: *On the integration test complexity:* The test scenarios are now structured as a three-tier progressive complexity ladder. Tier 1 (UHD streaming stability no RF link, no synchronisation blocks) enters CI first and independently. Tier 2 (BER loopback, FM) follows once Tier 1 is stable. Tier 3 (OFDM, multi-node, advanced sync) is explicitly scoped as stretch goals that do not block the project's core CI deliverable. The timeline milestones reflect this CI integration is never waiting on the most complex tests. *On labgrid vs. Minus:* I have added a dedicated section that answers precisely where labgrid adds capability Minus does not natively provide for automated CI: (1) a blocking reservation queue so concurrent PR jobs don't collide, (2) crash-safe orphan detection via heartbeat so a killed runner doesn't hold a node locked indefinitely, and (3) hardware-agnostic YAML environment files so test scripts aren't coupled to CorteXlab node identifiers. The proposed architecture layers labgrid on top of Minus .Minus continues to handle CorteXlab's native scheduling, while labgrid handles the CI-side locking and queuing. I've also noted that I'll assess the exact Minus integration points during Community Bonding and will fall back to a thin custom shim if the labgrid exporter integration proves more complex than expected. I'm attaching the revised proposal: Hardware in the Loop CI <https://drive.google.com/file/d/1-MeOUqJjFajEY3WxGaCTRGH5u5tcyMLY/view?usp=sharing> Please let me know if there is anything else you'd like clarified before the deadline. Best regards, Joseph P George On Mon, 30 Mar 2026 at 14:46, Cyrille Morin <[email protected]> wrote: > Hello Joseph, > > I read trough your document. > Overall, it looks good, it appears to have everything required of the > proposal document. > > A couple of thoughts: > > The proposed integrated tests look good and feel like what we would like > to head towards, but being integration tests, they involve a lot of moving > parts, so they might require a lot of tweaking and debugging time to work > reliably, which might push back the integration into the CI pipeline. > > I've never used Labgrid so I don't know much about what it can or cannot > help with. But it does sound in your proposal to perform many task already > done by the platform's systems (booking, health check, ...) You might want > to detail where specifically Labgrid would offer new and required > capabilities > > Best > *Cyrille MORIN* > *Ingénieur SED* > *Équipe MARACAS* > > [image: Logo Inria] > Centre Inria de Lyon > > Laboratoire CITI > Campus La Doua - Villeurbanne > 6 avenue des Arts > F-69621 Villeurbanne > > https://team.inria.fr/maracas/ > Le 28/03/2026 à 14:49, Joseph George a écrit : > > Hi Cyrille, > > I have completed the first draft of my GSoC 2026 proposal for the > "Hardware in the Loop CI" project. > > Draft : Hardware in the Loop CI > <https://drive.google.com/file/d/1ATLOxq_bvPpG7fizTQtZK-8w_BwadVeF/view?usp=drive_link> > > A huge thank you to Larry and Philip for the insights. I have explicitly > integrated the LBNL Node Health Check paradigm to isolate hardware failures > from software regressions, and I've adopted Labgrid as the core hardware > orchestration layer to manage the CorteXlab USRPs. > > I would greatly appreciate any feedback from the community, > > Thanks for your time and guidance! > > Best, Joseph George > > On Thu, 26 Mar 2026 at 22:23, Cyrille Morin <[email protected]> > wrote: > >> Hi Joseph, >> >> Welcome! >> >> Feel free to share your draft here on the mailing list, for feedback by >> members of the community, that's the right place >> >> I don't have a specific format for the tests scenarios, choose what you >> think is best/more readable/most relevant. >> But do look at the GSoC Student info on the wiki if you haven't already: >> https://wiki.gnuradio.org/index.php?title=GSoCStudentInfo >> <https://wiki.gnuradio.org/index.php?title=GSoCStudentInfo> >> *Cyrille MORIN* >> Le 26/03/2026 à 15:56, Joseph George a écrit : >> >> Hi Cyrille, >> I’m Joseph, an ECE student and the Chair of the IEEE Signal Processing >> Society at my college. I’m putting together a GSoC proposal for the >> "Hardware in the loop CI" project and wanted to quickly say hello. >> >> I have a strong background in bridging DSP theory with physical hardware. >> I recently placed 7th globally in the ICASSP 2026 ALS challenge by building >> domain-driven acoustic biomarker pipelines, and I regularly build hardware >> projects (like ESP32 navigation systems using Kalman filtering for sensor >> fusion). I'd love to help bring GNU Radio's CI tests out of software only >> simulation and onto the physical CorteXlab hardware. >> >> I am drafting my 12-week timeline right now. Is there a specific format >> you prefer for the test scenarios, or a good place to drop a link to my >> draft for a quick sanity check before Tuesday's deadline? >> >>
