Re: GSoC 2026 Proposal - Hardware in the loop CI
Joseph George <[email protected]> Wed, 1 Apr 2026 20:06:44 +0530
| Newsgroups | gmane.comp.gnu.radio.general |
|---|---|
| Message-ID | <CAGv1_4Xv90oS6jCcBxD1kVuMDQinhveOYH=yOLH8TYq5qNEL6g@mail.gmail.com> |
--0000000000001ee9ac064e67044c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Marcus, =E2=80=8BThanks for the reality check! You make a great point about the Git= Hub runner essentially acting as its own queue, treating it as a 1:1 runner-to-node-pair mapping cuts out a massive amount of unnecessary orchestration logic. I will definitely take your advice to avoid the Labgrid and keep the architecture as lean and native as possible. Thanks again for the sanity check and the practical insights! Best, Joseph On Wed, 1 Apr, 2026, 18:59 Marcus M=C3=BCller, <[email protected]> wrot= e: > Hey Joseph, > > I'm relieved if you've already been discussing things with Cyrille. Don't > get rabbithole'd > early on :) > > I'm not sure what Labgrid brings to the table in terms of making sure tha= t > concurrent PR > jobs don't collide; the usual paradigm here, and how for example the > github runner > interface (but also other CI runners) handle this is that there's a daemo= n > that accepts a > job, and only when it's done starts the next. The CI runner you need to > have running to > accept the job coming from the forge (Github) already does that! > > > =E2=80=8BCrash-safe orphan detection > > Not a bad thing to have, but since any test needs to fail after a timeout > has happened, > I'd assume the timing-out and yielding the node would be included in what > you run on the > nodes themselves. > > Other than that, I'd feel fairly confident that in case the controller > crashes, you have a > complete system failure, at which point you can just automatically stop > all jobs you're > running, and start fresh. > > > =E2=80=8BHardware-agnostic YAML environments: Keeps test scripts decou= pled from > CorteXlab's > > specific node identifiers. > > Not a bad motive! Yes, but it locks you into the specific format of a > different specific > software, and it's just a few YAML files, so while I think this is a good > argument, not > one that is super urgent! > > > I noted in the proposal that the plan is to assess this during > Community Bonding > > Very fair! > > Best regards, > Marcus > > On 2026-04-01 1:12 PM, Joseph George wrote: > > Hi Marcus, > > =E2=80=8BThanks for taking a look and for the feedback! > > =E2=80=8BI completely agree that CorteXlab's native Minus API is fantas= tic for > handling the core > > node management and scheduling. > > =E2=80=8BAfter discussing the architecture with Cyrille on the list ear= lier this > week, I actually > > updated the final proposal to clarify this exact relationship. > > > > My main reason for exploring Labgrid was actually to fill a few specifi= c > CI orchestration > > gaps that I wasn't sure CorteXlab's Minus API handled natively for > unattended runners. > > Specifically: > > > > * =E2=80=8BBlocking reservation queue: Ensures concurrent PR jobs don= 't > collide. > > * =E2=80=8BCrash-safe orphan detection: Uses a heartbeat so a killed = runner > doesn't hold a node > > locked indefinitely. > > * =E2=80=8BHardware-agnostic YAML environments: Keeps test scripts de= coupled > from CorteXlab's > > specific node identifiers. > > > > > > *=E2=80=8BI noted in the proposal that the plan is to assess this durin= g > Community Bonding. If > > introducing Labgrid is too heavy or the wrong fit for the GNU Radio CI > ecosystem, I am > > 100% on board with dropping it and just building a lightweight custom > shim around the > > Minus API to handle the queueing and heartbeats.* > > * > > * > > =E2=80=8BReally appreciate you taking the time to review the concept! I= 'd love > to hear your > > thoughts on this layered approach. > > =E2=80=8BBest, > > Joseph > > > > On Wed, 1 Apr, 2026, 16:20 Marcus M=C3=BCller, <[email protected] > > <mailto:[email protected]>> wrote: > > > > 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 don= e > 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=C3=A9nieur SED/ > > >> /=C3=89quipe 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/ <https://team.inria.fr/maracas/> > > >> Le 28/03/2026 =C3=A0 14:49, Joseph George a =C3=A9crit : > > >>> > > >>> 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= / > <https:// > > drive.google.com/file/> > > >>> d/1ATLOxq_bvPpG7fizTQtZK-8w_BwadVeF/view?usp=3Ddrive_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] > > <mailto:[email protected]>> wrote: > > >>> > > >>> Hi Joseph, > > >>> > > >>> Welcome! > > >>> > > >>> Feel free to share your draft here on the mailing list, fo= r > > >>> feedback by members of the community, that's the right pla= ce > > >>> > > >>> 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=3DGSoCStudentInfo <https:// > > wiki.gnuradio.org/index.php?title=3DGSoCStudentInfo> > > >>> <https://wiki.gnuradio.org/index.php?title=3DGSoCStudentIn= fo > <https:// > > wiki.gnuradio.org/index.php?title=3DGSoCStudentInfo>> > > >>> > > >>> *Cyrille MORIN* > > >>> Le 26/03/2026 =C3=A0 15:56, Joseph George a =C3=A9crit : > > >>>> Hi Cyrille, > > >>>> I=E2=80=99m Joseph, an ECE student and the Chair of the I= EEE Signal > > >>>> Processing Society at my college. I=E2=80=99m putting tog= ether 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? > > >>> > > > > > > > > > > > > --0000000000001ee9ac064e67044c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div dir=3D"auto">Hi Marcus,</div><div dir=3D"auto">=E2= =80=8BThanks for the reality check! You make a great point about the GitHub= runner essentially acting as its own queue, treating it as a 1:1 runner-to= -node-pair mapping cuts out a massive amount of unnecessary orchestration l= ogic.</div><div dir=3D"auto"><br></div><div dir=3D"auto">I will definitely = take your advice to avoid the Labgrid and keep the architecture as lean and= native as possible.</div><div dir=3D"auto">Thanks again for the sanity che= ck and the practical insights!</div><div dir=3D"auto"><br></div><div dir=3D= "auto">Best,</div><div dir=3D"auto">Joseph</div></div><br><div class=3D"gma= il_quote gmail_quote_container"><div dir=3D"ltr" class=3D"gmail_attr">On We= d, 1 Apr, 2026, 18:59 Marcus M=C3=BCller, <<a href=3D"mailto:mmueller@gn= uradio.org">[email protected]</a>> wrote:<br></div><blockquote class= =3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd= ing-left:1ex">Hey Joseph,<br> <br> I'm relieved if you've already been discussing things with Cyrille.= Don't get rabbithole'd <br> early on :)<br> <br> I'm not sure what Labgrid brings to the table in terms of making sure t= hat concurrent PR <br> jobs don't collide; the usual paradigm here, and how for example the gi= thub runner <br> interface (but also other CI runners) handle this is that there's a dae= mon that accepts a <br> job, and only when it's done starts the next. The CI runner you need to= have running to <br> accept the job coming from the forge (Github) already does that!<br> <br> =C2=A0> =E2=80=8BCrash-safe orphan detection<br> <br> Not a bad thing to have, but since any test needs to fail after a timeout h= as happened, <br> I'd assume the timing-out and yielding the node would be included in wh= at you run on the <br> nodes themselves.<br> <br> Other than that, I'd feel fairly confident that in case the controller = crashes, you have a <br> complete system failure, at which point you can just automatically stop all= jobs you're <br> running, and start fresh.<br> <br> =C2=A0> =E2=80=8BHardware-agnostic YAML environments: Keeps test scripts= decoupled from CorteXlab's<br> =C2=A0>=C2=A0 =C2=A0 =C2=A0specific node identifiers.<br> <br> Not a bad motive! Yes, but it locks you into the specific format of a diffe= rent specific <br> software, and it's just a few YAML files, so while I think this is a go= od argument, not <br> one that is super urgent!<br> <br> =C2=A0> I noted in the proposal that the plan is to assess this during C= ommunity Bonding<br> <br> Very fair!<br> <br> Best regards,<br> Marcus<br> <br> On 2026-04-01 1:12 PM, Joseph George wrote:<br> > Hi Marcus,<br> > =E2=80=8BThanks for taking a look and for the feedback!<br> > =E2=80=8BI completely agree that CorteXlab's native Minus API is f= antastic for handling the core <br> > node management and scheduling.<br> > =E2=80=8BAfter discussing the architecture with Cyrille on the list ea= rlier this week, I actually <br> > updated the final proposal to clarify this exact relationship.<br> > <br> > My main reason for exploring Labgrid was actually to fill a few specif= ic CI orchestration <br> > gaps that I wasn't sure CorteXlab's Minus API handled natively= for unattended runners. <br> > Specifically:<br> > <br> >=C2=A0 =C2=A0* =E2=80=8BBlocking reservation queue: Ensures concurrent = PR jobs don't collide.<br> >=C2=A0 =C2=A0* =E2=80=8BCrash-safe orphan detection: Uses a heartbeat s= o a killed runner doesn't hold a node<br> >=C2=A0 =C2=A0 =C2=A0locked indefinitely.<br> >=C2=A0 =C2=A0* =E2=80=8BHardware-agnostic YAML environments: Keeps test= scripts decoupled from CorteXlab's<br> >=C2=A0 =C2=A0 =C2=A0specific node identifiers. <br> > <br> > <br> > *=E2=80=8BI noted in the proposal that the plan is to assess this duri= ng Community Bonding. If <br> > introducing Labgrid is too heavy or the wrong fit for the GNU Radio CI= ecosystem, I am <br> > 100% on board with dropping it and just building a lightweight custom = shim around the <br> > Minus API to handle the queueing and heartbeats.*<br> > *<br> > *<br> > =E2=80=8BReally appreciate you taking the time to review the concept! = I'd love to hear your <br> > thoughts on this layered approach.<br> > =E2=80=8BBest,<br> > Joseph<br> > <br> > On Wed, 1 Apr, 2026, 16:20 Marcus M=C3=BCller, <<a href=3D"mailto:m= [email protected]" target=3D"_blank" rel=3D"noreferrer">mmueller@gnuradi= o.org</a> <br> > <mailto:<a href=3D"mailto:[email protected]" target=3D"_blank" = rel=3D"noreferrer">[email protected]</a>>> wrote:<br> > <br> >=C2=A0 =C2=A0 =C2=A0Don't think labgrid is the kind of thing that h= elps here, much.<br> > <br> >=C2=A0 =C2=A0 =C2=A0On 2026-03-31 2:09 PM, Philip Balister wrote:<br> >=C2=A0 =C2=A0 =C2=A0 > On 3/30/26 4:16 AM, Cyrille Morin wrote:<br> >=C2=A0 =C2=A0 =C2=A0 >> Hello Joseph,<br> >=C2=A0 =C2=A0 =C2=A0 >><br> >=C2=A0 =C2=A0 =C2=A0 >> I read trough your document.<br> >=C2=A0 =C2=A0 =C2=A0 >> Overall, it looks good, it appears to hav= e everything required of the proposal<br> >=C2=A0 =C2=A0 =C2=A0document.<br> >=C2=A0 =C2=A0 =C2=A0 >><br> >=C2=A0 =C2=A0 =C2=A0 >> A couple of thoughts:<br> >=C2=A0 =C2=A0 =C2=A0 >><br> >=C2=A0 =C2=A0 =C2=A0 >> The proposed integrated tests look good a= nd feel like what we would like to head<br> >=C2=A0 =C2=A0 =C2=A0 >> towards, but being integration tests, the= y involve a lot of moving parts, so they<br> >=C2=A0 =C2=A0 =C2=A0might<br> >=C2=A0 =C2=A0 =C2=A0 >> require a lot of tweaking and debugging t= ime to work reliably, which might push<br> >=C2=A0 =C2=A0 =C2=A0back the<br> >=C2=A0 =C2=A0 =C2=A0 >> integration into the CI pipeline.<br> >=C2=A0 =C2=A0 =C2=A0 >><br> >=C2=A0 =C2=A0 =C2=A0 >> I've never used Labgrid so I don'= t know much about what it can or cannot help<br> >=C2=A0 =C2=A0 =C2=A0with. But<br> >=C2=A0 =C2=A0 =C2=A0 >> it does sound in your proposal to perform= many task already done by the platform's<br> >=C2=A0 =C2=A0 =C2=A0 >> systems (booking, health check, ...) You = might want to detail where specifically<br> >=C2=A0 =C2=A0 =C2=A0Labgrid<br> >=C2=A0 =C2=A0 =C2=A0 >> would offer new and required capabilities= <br> >=C2=A0 =C2=A0 =C2=A0 ><br> >=C2=A0 =C2=A0 =C2=A0 > Labgrid would offer a general API to the hard= ware so the work could extend beyond<br> >=C2=A0 =C2=A0 =C2=A0 > CorteXlab. It is certainly worth a look to se= e if it is straight forward to<br> >=C2=A0 =C2=A0 =C2=A0abstract the<br> >=C2=A0 =C2=A0 =C2=A0 > interface to the underlying hardware.<br> >=C2=A0 =C2=A0 =C2=A0 ><br> >=C2=A0 =C2=A0 =C2=A0 > Philip<br> >=C2=A0 =C2=A0 =C2=A0 ><br> >=C2=A0 =C2=A0 =C2=A0 ><br> >=C2=A0 =C2=A0 =C2=A0 >><br> >=C2=A0 =C2=A0 =C2=A0 >> Best<br> >=C2=A0 =C2=A0 =C2=A0 >><br> >=C2=A0 =C2=A0 =C2=A0 >> *Cyrille MORIN*<br> >=C2=A0 =C2=A0 =C2=A0 >> /Ing=C3=A9nieur SED/<br> >=C2=A0 =C2=A0 =C2=A0 >> /=C3=89quipe MARACAS/<br> >=C2=A0 =C2=A0 =C2=A0 >><br> >=C2=A0 =C2=A0 =C2=A0 >> Logo Inria<br> >=C2=A0 =C2=A0 =C2=A0 >> Centre Inria de Lyon<br> >=C2=A0 =C2=A0 =C2=A0 >><br> >=C2=A0 =C2=A0 =C2=A0 >> Laboratoire CITI<br> >=C2=A0 =C2=A0 =C2=A0 >> Campus La Doua - Villeurbanne<br> >=C2=A0 =C2=A0 =C2=A0 >> 6 avenue des Arts<br> >=C2=A0 =C2=A0 =C2=A0 >> F-69621 Villeurbanne<br> >=C2=A0 =C2=A0 =C2=A0 >><br> >=C2=A0 =C2=A0 =C2=A0 >> <a href=3D"https://team.inria.fr/maracas/= " rel=3D"noreferrer noreferrer" target=3D"_blank">https://team.inria.fr/mar= acas/</a> <<a href=3D"https://team.inria.fr/maracas/" rel=3D"noreferrer = noreferrer" target=3D"_blank">https://team.inria.fr/maracas/</a>><br> >=C2=A0 =C2=A0 =C2=A0 >> Le 28/03/2026 =C3=A0 14:49, Joseph George= a =C3=A9crit=C2=A0:<br> >=C2=A0 =C2=A0 =C2=A0 >>><br> >=C2=A0 =C2=A0 =C2=A0 >>> Hi Cyrille,<br> >=C2=A0 =C2=A0 =C2=A0 >>><br> >=C2=A0 =C2=A0 =C2=A0 >>> I have completed the first draft of m= y GSoC 2026 proposal for the "Hardware in<br> >=C2=A0 =C2=A0 =C2=A0the Loop<br> >=C2=A0 =C2=A0 =C2=A0 >>> CI" project.<br> >=C2=A0 =C2=A0 =C2=A0 >>><br> >=C2=A0 =C2=A0 =C2=A0 >>> Draft : Hardware in the Loop CI <<= a href=3D"https://drive.google.com/file/" rel=3D"noreferrer noreferrer" tar= get=3D"_blank">https://drive.google.com/file/</a> <https://<br> >=C2=A0 =C2=A0 =C2=A0<a href=3D"http://drive.google.com/file/" rel=3D"no= referrer noreferrer" target=3D"_blank">drive.google.com/file/</a>><br> >=C2=A0 =C2=A0 =C2=A0 >>> d/1ATLOxq_bvPpG7fizTQtZK-8w_BwadVeF/v= iew?usp=3Ddrive_link><br> >=C2=A0 =C2=A0 =C2=A0 >>><br> >=C2=A0 =C2=A0 =C2=A0 >>> A huge thank you to Larry and Philip = for the insights. I have explicitly<br> >=C2=A0 =C2=A0 =C2=A0integrated the<br> >=C2=A0 =C2=A0 =C2=A0 >>> LBNL Node Health Check paradigm to is= olate hardware failures from software<br> >=C2=A0 =C2=A0 =C2=A0regressions,<br> >=C2=A0 =C2=A0 =C2=A0 >>> and I've adopted Labgrid as the c= ore hardware orchestration layer to manage the<br> >=C2=A0 =C2=A0 =C2=A0 >>> CorteXlab USRPs.<br> >=C2=A0 =C2=A0 =C2=A0 >>><br> >=C2=A0 =C2=A0 =C2=A0 >>> I would greatly appreciate any feedba= ck from the community,<br> >=C2=A0 =C2=A0 =C2=A0 >>><br> >=C2=A0 =C2=A0 =C2=A0 >>> Thanks for your time and guidance!<br= > >=C2=A0 =C2=A0 =C2=A0 >>><br> >=C2=A0 =C2=A0 =C2=A0 >>> Best, Joseph George<br> >=C2=A0 =C2=A0 =C2=A0 >>><br> >=C2=A0 =C2=A0 =C2=A0 >>><br> >=C2=A0 =C2=A0 =C2=A0 >>> On Thu, 26 Mar 2026 at 22:23, Cyrille= Morin <<a href=3D"mailto:[email protected]" target=3D"_blank" rel= =3D"noreferrer">[email protected]</a><br> >=C2=A0 =C2=A0 =C2=A0<mailto:<a href=3D"mailto:[email protected]= " target=3D"_blank" rel=3D"noreferrer">[email protected]</a>>> w= rote:<br> >=C2=A0 =C2=A0 =C2=A0 >>><br> >=C2=A0 =C2=A0 =C2=A0 >>> =C2=A0=C2=A0=C2=A0 Hi Joseph,<br> >=C2=A0 =C2=A0 =C2=A0 >>><br> >=C2=A0 =C2=A0 =C2=A0 >>> =C2=A0=C2=A0=C2=A0 Welcome!<br> >=C2=A0 =C2=A0 =C2=A0 >>><br> >=C2=A0 =C2=A0 =C2=A0 >>> =C2=A0=C2=A0=C2=A0 Feel free to share= your draft here on the mailing list, for<br> >=C2=A0 =C2=A0 =C2=A0 >>> =C2=A0=C2=A0=C2=A0 feedback by member= s of the community, that's the right place<br> >=C2=A0 =C2=A0 =C2=A0 >>><br> >=C2=A0 =C2=A0 =C2=A0 >>> =C2=A0=C2=A0=C2=A0 I don't have a= specific format for the tests scenarios, choose<br> >=C2=A0 =C2=A0 =C2=A0 >>> =C2=A0=C2=A0=C2=A0 what you think is = best/more readable/most relevant.<br> >=C2=A0 =C2=A0 =C2=A0 >>> =C2=A0=C2=A0=C2=A0 But do look at the= GSoC Student info on the wiki if you haven't<br> >=C2=A0 =C2=A0 =C2=A0 >>> =C2=A0=C2=A0=C2=A0 already: <a href= =3D"https://wiki.gnuradio.org/index.php?title=3DGSoCStudentInfo" rel=3D"nor= eferrer noreferrer" target=3D"_blank">https://wiki.gnuradio.org/index.php?t= itle=3DGSoCStudentInfo</a> <https://<br> >=C2=A0 =C2=A0 =C2=A0<a href=3D"http://wiki.gnuradio.org/index.php?title= =3DGSoCStudentInfo" rel=3D"noreferrer noreferrer" target=3D"_blank">wiki.gn= uradio.org/index.php?title=3DGSoCStudentInfo</a>><br> >=C2=A0 =C2=A0 =C2=A0 >>> =C2=A0=C2=A0=C2=A0 <<a href=3D"htt= ps://wiki.gnuradio.org/index.php?title=3DGSoCStudentInfo" rel=3D"noreferrer= noreferrer" target=3D"_blank">https://wiki.gnuradio.org/index.php?title=3D= GSoCStudentInfo</a> <https://<br> >=C2=A0 =C2=A0 =C2=A0<a href=3D"http://wiki.gnuradio.org/index.php?title= =3DGSoCStudentInfo" rel=3D"noreferrer noreferrer" target=3D"_blank">wiki.gn= uradio.org/index.php?title=3DGSoCStudentInfo</a>>><br> >=C2=A0 =C2=A0 =C2=A0 >>><br> >=C2=A0 =C2=A0 =C2=A0 >>> =C2=A0=C2=A0=C2=A0 *Cyrille MORIN*<br= > >=C2=A0 =C2=A0 =C2=A0 >>> =C2=A0=C2=A0=C2=A0 Le 26/03/2026 =C3= =A0 15:56, Joseph George a =C3=A9crit=C2=A0:<br> >=C2=A0 =C2=A0 =C2=A0 >>>> =C2=A0=C2=A0=C2=A0 Hi Cyrille,<br= > >=C2=A0 =C2=A0 =C2=A0 >>>> =C2=A0=C2=A0=C2=A0 I=E2=80=99m Jo= seph, an ECE student and the Chair of the IEEE Signal<br> >=C2=A0 =C2=A0 =C2=A0 >>>> =C2=A0=C2=A0=C2=A0 Processing Soc= iety at my college. I=E2=80=99m putting together a GSoC<br> >=C2=A0 =C2=A0 =C2=A0 >>>> =C2=A0=C2=A0=C2=A0 proposal for t= he "Hardware in the loop CI" project and wanted to<br> >=C2=A0 =C2=A0 =C2=A0 >>>> =C2=A0=C2=A0=C2=A0 quickly say he= llo.<br> >=C2=A0 =C2=A0 =C2=A0 >>>><br> >=C2=A0 =C2=A0 =C2=A0 >>>> =C2=A0=C2=A0=C2=A0 I have a stron= g background in bridging DSP theory with physical<br> >=C2=A0 =C2=A0 =C2=A0 >>>> =C2=A0=C2=A0=C2=A0 hardware. I re= cently placed 7th globally in the ICASSP 2026 ALS<br> >=C2=A0 =C2=A0 =C2=A0 >>>> =C2=A0=C2=A0=C2=A0 challenge by b= uilding domain-driven acoustic biomarker pipelines,<br> >=C2=A0 =C2=A0 =C2=A0 >>>> =C2=A0=C2=A0=C2=A0 and I regularl= y build hardware projects (like ESP32 navigation<br> >=C2=A0 =C2=A0 =C2=A0 >>>> =C2=A0=C2=A0=C2=A0 systems using = Kalman filtering for sensor fusion). I'd love to<br> >=C2=A0 =C2=A0 =C2=A0 >>>> =C2=A0=C2=A0=C2=A0 help bring GNU= Radio's CI tests out of software only simulation<br> >=C2=A0 =C2=A0 =C2=A0 >>>> =C2=A0=C2=A0=C2=A0 and onto the p= hysical CorteXlab hardware.<br> >=C2=A0 =C2=A0 =C2=A0 >>>><br> >=C2=A0 =C2=A0 =C2=A0 >>>> =C2=A0=C2=A0=C2=A0 I am drafting = my 12-week timeline right now. Is there a specific<br> >=C2=A0 =C2=A0 =C2=A0 >>>> =C2=A0=C2=A0=C2=A0 format you pre= fer for the test scenarios, or a good place to drop<br> >=C2=A0 =C2=A0 =C2=A0 >>>> =C2=A0=C2=A0=C2=A0 a link to my d= raft for a quick sanity check before Tuesday's<br> >=C2=A0 =C2=A0 =C2=A0 >>>> =C2=A0=C2=A0=C2=A0 deadline?<br> >=C2=A0 =C2=A0 =C2=A0 >>><br> >=C2=A0 =C2=A0 =C2=A0 ><br> >=C2=A0 =C2=A0 =C2=A0 ><br> > <br> > <br> <br> </blockquote></div> --0000000000001ee9ac064e67044c--