Re: GSoC 2026 Proposal - Hardware in the loop CI

Don't think labgrid is the kind of thing that helps here, much.

On 2026-03-31 2:09 PM, Philip Balister wrote:
> On 3/30/26 4:16 AM, Cyrille Morin 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
> 
> Labgrid would offer a general API to the hardware so the work could extend beyond 
> CorteXlab. It is certainly worth a look to see if it is straight forward to abstract the 
> interface to the underlying hardware.
> 
> Philip
> 
> 
>>
>> Best
>>
>> *Cyrille MORIN*
>> /Ingénieur SED/
>> /Équipe MARACAS/
>>
>> 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?
>>>
> 
>