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&#39;s something genuinely useful=C2=A0 for researche=
rs, students,=C2=A0 anyone.<br><br>So here&#39;s how I&#39;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&#39;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&#39=
;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 &lt;<a href=3D"mailto:[email protected]" target=
=3D"_blank" rel=3D"noreferrer">[email protected]</a>&gt; 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&#39;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&#39;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>
&gt; Hi GNU Radio community,<br>
&gt; <br>
&gt; I am Devanshi , a GSoC 2026 applicant interested in proposing a self- =
<br>
&gt; directed project.<br>
&gt; <br>
&gt; I have strong familiarity with GNSS signal generation concepts and the=
 <br>
&gt; BeiDou B1C ICD specification, with hands-on experience .<br>
&gt; <br>
&gt; Proposed idea: A GNU Radio OOT module=C2=A0 tentatively gr-beidou=C2=
=A0 <br>
&gt; implementing a BeiDou B1C software signal simulator. The module would =
cover:<br>
&gt; <br>
&gt; - B1C PRN code generation (data and pilot components, per ICD)<br>
&gt; - BOC modulation<br>
&gt; - Basic CNAV-1 navigation message framing<br>
&gt; - Baseband I/Q output usable for receiver testing and simulation<br>
&gt; <br>
&gt; The implementation would be built entirely from the public BeiDou B1C =
<br>
&gt; ICD with no hardware dependency=C2=A0 making it useful for receiver te=
sting, <br>
&gt; education, and research. I plan to model the module structure after gr=
- <br>
&gt; satellites, which sets a great precedent for clean, well-documented <b=
r>
&gt; signal-level OOT modules.<br>
&gt; <br>
&gt; This fills a genuine gap=C2=A0 no open-source GNU Radio B1C signal gen=
erator <br>
&gt; currently exists.<br>
&gt; <br>
&gt; if any mentor would be interested in supervising this, or if there is =
a <br>
&gt; better framing that fits current GNU Radio priorities.<br>
&gt; <br>
&gt; Cyberspectrum is the best spectrum.<br>
<br>
</blockquote></div>
</div></div>

--000000000000c79cb3064d635b30--