Re:Self-proposed idea: BeiDou B1C Signal Simulator OOT Module
Devanshi B <[email protected]> Thu, 19 Mar 2026 22:19:44 +0530
| Newsgroups | gmane.comp.gnu.radio.general |
|---|---|
| Message-ID | <CAJPa+Oqc-qd0H_Uo1vHOdF6XK_PZSEfZuHwOWfeCLZDPF5qO3A@mail.gmail.com> |
--000000000000c79cb3064d635b30 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [GSoC 2026] Self-proposed idea: BeiDou B1C Signal Simulator OOT Module Hello Sir, The constellation simulator direction makes much more sense. If the output can actually give a software receiver enough to compute a real PVT fix, that's something genuinely useful for researchers, students, anyone. So here's how I'm thinking about the expanded scope now - multi-constellation , with Doppler shifts and time-of-flight delays that match what a receiver at a given location and time would actually see - Generate proper navigation messages so a receiver can extract ephemeris and compute a position fix - Validate everything using GNSS-SDR as a software receiver feed the generated I/Q straight in and check if it produces a valid PVT solution. No hardware needed. One thing I'm unsure about: is it better to do BeiDou B1C really well and completely, or to cover B1C + GPS L1C + Galileo E1 at a slightly shallower level? Since all three share 1575.42 MHz I can see the appeal of multi-constellation.Would love your take on this. I'll start working on a proper week-by-week draft and share it here soon for feedback. Best, Devanshi. On Thu, Mar 19, 2026 at 12:50=E2=80=AFAM Daniel Est=C3=A9vez <daniel@destev= ez.net> wrote: > Hi Devanshi, > > Thanks for sharing this idea. Here is some quick feedback. > > You don't say explicitly, but my understanding from what you wrote is > that your idea is to generate a single B1C signal with nominal chip rate > and no Doppler. This does not seem enough work even for a small (90 > hour) project, specially if you are already strongly familiar with GNSS > signal generation and the B1C signal. Such kind of simulator is of > fairly limited use, since it only allows to test that a receiver is > capable of acquiring and tracking a single signal in these conditions. > It is more common to have constellation simulators, which are capable of > simulating signals from multiple satellites whose times of flight and > Dopplers are consistent with the signals that a receiver in a given > location would see. A constellation simulator, if well planned out, > might be reasonable for a GSoC project (probably more on the larger side > of the project size spectrum). Constellation simulators can be used to > obtain a PVT solution with a receiver, and test it in reasonably > realistic conditions. > > You should detail in your proposal how you plan to test this. It is fine > that the tool itself generates baseband IQ and does not require any > hardware, but you will need to test somehow that the signals you are > generating are correct. Ideally you would use a hardware receiver and an > SDR to transmit your baseband IQ, but this requires you to already have > this hardware. If you don't have the required hardware, using a software > receiver is a good alternative, but you will need to identify such a > software receiver that allows you to check all you generate. > > Another way in which you could increase the scope of your proposal and > make it more attractive is by including open service signals from other > constellations (GPS, Galileo, etc.), all of which have ICDs which are > publicly accessible. > > Best, > Daniel. > > On 18/03/2026 19:22, Devanshi B wrote: > > Hi GNU Radio community, > > > > I am Devanshi , a GSoC 2026 applicant interested in proposing a self- > > directed project. > > > > I have strong familiarity with GNSS signal generation concepts and the > > BeiDou B1C ICD specification, with hands-on experience . > > > > Proposed idea: A GNU Radio OOT module tentatively gr-beidou > > implementing a BeiDou B1C software signal simulator. The module would > cover: > > > > - B1C PRN code generation (data and pilot components, per ICD) > > - BOC modulation > > - Basic CNAV-1 navigation message framing > > - Baseband I/Q output usable for receiver testing and simulation > > > > The implementation would be built entirely from the public BeiDou B1C > > ICD with no hardware dependency making it useful for receiver testing, > > education, and research. I plan to model the module structure after gr- > > satellites, which sets a great precedent for clean, well-documented > > signal-level OOT modules. > > > > This fills a genuine gap no open-source GNU Radio B1C signal generator > > currently exists. > > > > if any mentor would be interested in supervising this, or if there is a > > better framing that fits current GNU Radio priorities. > > > > Cyberspectrum is the best spectrum. > > --000000000000c79cb3064d635b30 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"auto"><div class=3D"gmail_quote gmail_quote_container" dir=3D"a= uto"><div dir=3D"ltr" class=3D"gmail_attr">Subject: Re: [GSoC 2026] Self-pr= oposed idea: BeiDou B1C Signal Simulator OOT Module</div><div dir=3D"ltr"><= br>Hello Sir,<br><br>The constellation simulator direction makes much more = sense. If the output can actually give a software receiver enough to comput= e a real PVT fix, that's something genuinely useful=C2=A0 for researche= rs, students,=C2=A0 anyone.<br><br>So here's how I'm thinking about= the expanded scope now<br><br>- multi-constellation=C2=A0 , with Doppler s= hifts and time-of-flight delays that match what a receiver at a given locat= ion and time would actually see<br>- Generate proper navigation messages=C2= =A0 so a receiver can extract ephemeris and compute a position fix<br>- Val= idate everything using GNSS-SDR as a software receiver=C2=A0 feed the gener= ated I/Q straight in and check if it produces a valid PVT solution. No hard= ware needed.<br><br>One thing I'm unsure about: is it better to do BeiD= ou B1C really well and completely, or to cover B1C + GPS L1C + Galileo E1 a= t a slightly shallower level? Since all three share 1575.42 MHz I can see t= he appeal of multi-constellation.Would love your take on this.<br><br>I'= ;ll start working on a proper week-by-week draft and share it here soon for= feedback.<br><br>Best,<br>Devanshi.<br></div><br><div class=3D"gmail_quote= "><div dir=3D"ltr" class=3D"gmail_attr">On Thu, Mar 19, 2026 at 12:50=E2=80= =AFAM Daniel Est=C3=A9vez <<a href=3D"mailto:[email protected]" target= =3D"_blank" rel=3D"noreferrer">[email protected]</a>> wrote:<br></div>= <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-= left:1px solid rgb(204,204,204);padding-left:1ex">Hi Devanshi,<br> <br> Thanks for sharing this idea. Here is some quick feedback.<br> <br> You don't say explicitly, but my understanding from what you wrote is <= br> that your idea is to generate a single B1C signal with nominal chip rate <b= r> and no Doppler. This does not seem enough work even for a small (90 <br> hour) project, specially if you are already strongly familiar with GNSS <br= > signal generation and the B1C signal. Such kind of simulator is of <br> fairly limited use, since it only allows to test that a receiver is <br> capable of acquiring and tracking a single signal in these conditions. <br> It is more common to have constellation simulators, which are capable of <b= r> simulating signals from multiple satellites whose times of flight and <br> Dopplers are consistent with the signals that a receiver in a given <br> location would see. A constellation simulator, if well planned out, <br> might be reasonable for a GSoC project (probably more on the larger side <b= r> of the project size spectrum). Constellation simulators can be used to <br> obtain a PVT solution with a receiver, and test it in reasonably <br> realistic conditions.<br> <br> You should detail in your proposal how you plan to test this. It is fine <b= r> that the tool itself generates baseband IQ and does not require any <br> hardware, but you will need to test somehow that the signals you are <br> generating are correct. Ideally you would use a hardware receiver and an <b= r> SDR to transmit your baseband IQ, but this requires you to already have <br= > this hardware. If you don't have the required hardware, using a softwar= e <br> receiver is a good alternative, but you will need to identify such a <br> software receiver that allows you to check all you generate.<br> <br> Another way in which you could increase the scope of your proposal and <br> make it more attractive is by including open service signals from other <br= > constellations (GPS, Galileo, etc.), all of which have ICDs which are <br> publicly accessible.<br> <br> Best,<br> Daniel.<br> <br> On 18/03/2026 19:22, Devanshi B wrote:<br> > Hi GNU Radio community,<br> > <br> > I am Devanshi , a GSoC 2026 applicant interested in proposing a self- = <br> > directed project.<br> > <br> > I have strong familiarity with GNSS signal generation concepts and the= <br> > BeiDou B1C ICD specification, with hands-on experience .<br> > <br> > Proposed idea: A GNU Radio OOT module=C2=A0 tentatively gr-beidou=C2= =A0 <br> > implementing a BeiDou B1C software signal simulator. The module would = cover:<br> > <br> > - B1C PRN code generation (data and pilot components, per ICD)<br> > - BOC modulation<br> > - Basic CNAV-1 navigation message framing<br> > - Baseband I/Q output usable for receiver testing and simulation<br> > <br> > The implementation would be built entirely from the public BeiDou B1C = <br> > ICD with no hardware dependency=C2=A0 making it useful for receiver te= sting, <br> > education, and research. I plan to model the module structure after gr= - <br> > satellites, which sets a great precedent for clean, well-documented <b= r> > signal-level OOT modules.<br> > <br> > This fills a genuine gap=C2=A0 no open-source GNU Radio B1C signal gen= erator <br> > currently exists.<br> > <br> > if any mentor would be interested in supervising this, or if there is = a <br> > better framing that fits current GNU Radio priorities.<br> > <br> > Cyberspectrum is the best spectrum.<br> <br> </blockquote></div> </div></div> --000000000000c79cb3064d635b30--