Geniux (GNSS-SDR for Embedded GNU/Linux) is a customized GNU/Linux distribution for developing and running GNSS-SDR on embedded devices, based on the Yocto Project. This Operating System includes a specific set of popular tools, libraries, and device drivers tailored for supporting an extended range of Software Defined Radio applications, helping to bring them to production-ready deployments with an approach widely adopted throughout the embedded/IoT industry.
The Geniux distribution comes in different version names, following those of the Yocto Project, being Rocko the oldest supported version. Each version name is tagged with a timestamp, so Geniux versions can evolve in time, but tagged versions can be reproduced at any time in the future. In addition, each version and each time tag can be built for a particular board or machine. This is expressed in the figure below:
Geniux keeps the pace of the software ecosystem evolution, but older versions are still reproducible. Virtualization technology allows reproducing images regardless of the software stack running at the host system building it.
Those names (Rocko, Sumo, Thud, Warrior, Zeus, etc.) represent major Geniux
versions. Then, each named version can have time tags (in the figure above,
20.09
and 20.10
). All versions have a latest
tag pointing to the latest
commit. Each named version with a time tag can be built for different
boards or machines (in the figure above, zedboard-zynq7
and rasperrypi3
).
The Geniux distribution follows the versioning format
VERSION_NAME-MANIFEST_DATE.CONF_NUMBER
, where:
rocko
, sumo
, thud
, warrior
, zeus
, dunfell
, gatesgarth
,
hardknott
, honister
, kirkstone
, langdale
, mickledore
, nanbield
.latest
always exists for each version name, and points to the
latest release.
20.09
, 21.02
, …, 21.08
, 22.02
, 22.06
, 23.04
, 24.02
, latest
.0
, 1
, …Example of version name: rocko-24.02.0
.
The generation of images and SDKs for a given Geniux version, time tag, and machine in a virtualized environment is automated by the yocto-geniux repository. With Docker already installed and running on your system, clone the Git repository and go to its base path:
$ git clone https://github.com/carlesfernandez/yocto-geniux
$ cd yocto-geniux
Now you are ready to build Geniux images for the release you want with a single
command, by using the geniux-builder.sh
script. Taking a look at its help
message:
$ ./geniux-builder.sh --help
You should get:
This script builds and stores Geniux images.
Usage:
./geniux-builder.sh [version] [manifest] [machine] (--image-only / -i)
Options:
version Geniux version (from oldest to most recent):
rocko, sumo, thud, warrior, zeus, dunfell, gatesgarth,
hardknott, honister, kirkstone, langdale, mickledore, nanbield. Default: dunfell
Check available branches at https://github.com/carlesfernandez/meta-gnss-sdr
manifest Geniux version manifest: 21.02, 21.08, 22.02, 22.06, 23.04, 24.04, latest. Default: latest
Dated manifests available at https://github.com/carlesfernandez/oe-gnss-sdr-manifest/tags
machine Specify your (list of) MACHINE here. By default, zedboard-zynq7 and raspberrypi3 are built.
If more than one, surround it with quotes, e.g.: "raspberrypi4-64 intel-corei7-64"
--image-only / -i (optional) Build the image but do not execute the container.
Environment variables that affect behavior:
GENIUX_MIRROR_PATH Base path to local mirror. Only used if set.
e.g.: 'export GENIUX_MIRROR_PATH=/home/carlesfernandez/mirror'
The mirror is expected to be at '$GENIUX_MIRROR_PATH/sources/$version'
GENIUX_STORE_PATH Path in which products will be stored. Only used if set.
e.g.: 'export GENIUX_STORE_PATH=/home/carlesfernandez/geniux-releases'
GENIUX_STORE_REQUIRES_SUDO If set, the script will ask for super-user privileges to write in the store.
You will be asked only once at the beginning. The password will not be revealed.
e.g.: 'export GENIUX_STORE_REQUIRES_SUDO=1'
You can find specific examples of how to use this script below. For more advanced usage modes (e.g., an interactive mode that allows you to make changes and experiment), check the instructions here.
The building process takes several hours and requires a powerful host system
with at least 120 GB of free space in the hard disk and 32 GB of RAM. When
finished, you will get your products in the output/
folder (or wherever the
GENIUX_STORE_PATH
environment variable points to). Among others:
wic.xz
and wic.bmap
image files ready to de
deployed on an SD card.Please note that if the automated building process fails for some reason
(failing network connection, misconfiguration, disappeared source repositories,
shortage of free hard disk space, RAM memory or CPU resources, etc.) before it
finishes, the running container will be deleted and you will lose everything, so
you will need to start over again. For a safer procedure, you can use the
interactive
mode
of the Docker image, which allows you to make changes, retry after a failure,
build other images, and save your products to /home/geniux/yocto/output/
when
done, so outside the Docker container. The container itself will be deleted at
exit.
pip3
.meta-xilinx-bsp
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.meta-gnss-sdr
layer is compatible with Xilinx PetaLinux Tools v2018.3.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh rocko 24.02 zedboard-zynq7
$ ./geniux-builder.sh rocko 24.02 zcu102-zynqmp
$ ./geniux-builder.sh rocko 24.02 raspberrypi3
$ ./geniux-builder.sh rocko 24.02 intel-corei7-64
$ ./geniux-builder.sh rocko 24.02 qemuarm
You can replace 24.02
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh sumo 24.02 zedboard-zynq7
$ ./geniux-builder.sh sumo 24.02 raspberrypi3
$ ./geniux-builder.sh sumo 24.02 intel-corei7-64
$ ./geniux-builder.sh sumo 24.02 qemuarm64
You can replace 24.02
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.
meta-xilinx
layer points to the rel-v2019.2
branch.meta-gnss-sdr
layer is compatible with Xilinx PetaLinux Tools v2019.2.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh thud 24.02 zedboard-zynq7
$ ./geniux-builder.sh thud 24.02 zcu102-zynqmp
$ ./geniux-builder.sh thud 24.02 raspberrypi3
$ ./geniux-builder.sh thud 24.02 intel-corei7-64
$ ./geniux-builder.sh thud 24.02 qemuarm64
You can replace 24.02
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh warrior 24.02 zedboard-zynq7
$ ./geniux-builder.sh warrior 24.02 raspberrypi4-64
$ ./geniux-builder.sh warrior 24.02 intel-corei7-64
$ ./geniux-builder.sh warrior 24.02 qemuarm64
You can replace 24.02
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.
meta-xilinx
layer points to rel-v2020.3
branch.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh zeus 24.02 zedboard-zynq7
$ ./geniux-builder.sh zeus 24.02 raspberrypi4-64
$ ./geniux-builder.sh zeus 24.02 intel-skylake-64
$ ./geniux-builder.sh zeus 24.02 qemuarm64
You can replace 24.02
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh dunfell 24.02 zedboard-zynq7
$ ./geniux-builder.sh dunfell 24.02 raspberrypi4-64
$ ./geniux-builder.sh dunfell 24.02 intel-corei7-64
$ ./geniux-builder.sh dunfell 24.02 qemuarm64
You can replace 24.02
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.
meta-xilinx
layer points to the rel-v2021.2
branch.linux-xlnx
kernel for zedboard-zynq7
machine, based on Linux kernel
5.10.meta-gnss-sdr
layer is compatible with Xilinx PetaLinux Tools v2021.2.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh gatesgarth 24.02 zedboard-zynq7
$ ./geniux-builder.sh gatesgarth 24.02 zc706-zynq7
$ ./geniux-builder.sh gatesgarth 24.02 raspberrypi4-64
$ ./geniux-builder.sh gatesgarth 24.02 intel-skylake-64
$ ./geniux-builder.sh gatesgarth 24.02 qemuarm64
You can replace 24.02
by latest
in order to get the latest developments.
pip3
.meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh hardknott 24.02 intel-corei7-64
$ ./geniux-builder.sh hardknott 24.02 raspberrypi4-64
$ ./geniux-builder.sh hardknott 24.02 qemuarm64
You can replace 24.02
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-xilinx-vendor
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.
meta-xilinx
layer points to the rel-v2022.2
branch.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh honister 24.02 intel-corei7-64
$ ./geniux-builder.sh honister 24.02 raspberrypi4-64
$ ./geniux-builder.sh honister 24.02 zedboard-zynq7
$ ./geniux-builder.sh honister 24.02 zc706-zynq7
$ ./geniux-builder.sh honister 24.02 zcu102-zynqmp
$ ./geniux-builder.sh honister 24.02 zcu208-zynqmp
You can replace 24.02
by latest
in order to get the latest developments.
pip3
.meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh kirkstone 24.02 intel-corei7-64
$ ./geniux-builder.sh kirkstone 24.02 raspberrypi4-64
You can replace 24.02
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-xilinx-vendor
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh langdale 24.02 intel-corei7-64
$ ./geniux-builder.sh langdale 24.02 raspberrypi4-64
$ ./geniux-builder.sh langdale 24.02 zedboard-zynq7
$ ./geniux-builder.sh langdale 24.02 zcu208-zynqmp
You can replace 24.02
by latest
in order to get the latest developments.
pip3
.meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh mickledore 24.02 intel-corei7-64
$ ./geniux-builder.sh mickledore 24.02 raspberrypi4-64
You can replace 24.02
by latest
in order to get the latest developments.
pip3
.meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh nanbield 24.02 intel-corei7-64
$ ./geniux-builder.sh nanbield 24.02 raspberrypi4-64
You can replace 24.02
by latest
in order to get the latest developments.
Starting from Geniux Zeus 21.08, the geniux-builder.sh
script produces .wic
images that can be flashed on an SD card and your device will be ready to go.
For image flashing, we recommend using a software tool such as Balena
Etcher. Just pick up the
gnss-sdr-demo-image-$MACHINE-yyyymmddHHMMSS.rootfs.wic.xz
file, flash your SD
card, insert it in your device, and it will be ready to boot and run gnss-sdr
.
Other flashing options here.
All the required information for building a Geniux release is contained in three public repositories:
rocko
, sumo
,
thud
, warrior
, zeus
, dunfell
, gatesgarth
, hardknott
, honister
,
kirkstone
, langdale
, mickledore
, nanbield
. Those branches are
updated as we learn more about the Yocto Project usage, so they evolve in
time.rocko
, sumo
,
thud
, warrior
, zeus
, dunfell
, gatesgarth
, hardknott
, honister
,
kirkstone
, langdale
, mickledore
, nanbield
.meta-gnss-sdr
has been pinned to a specific commit. This allows
fully-reproducible buildings in the future since it defines a
fully-specified software system set. Examples: rocko-24.02
, sumo-24.02
,
thud-24.02
, etc.MANIFEST_DATE
is set to latest
, all the
layers are pinned to a specific commit but except the meta-gnss-sdr
layer,
which points to whatever it is in the corresponding branch of that layer at
that point of time.If you miss any feature on Geniux, or have an idea on how to make it better, pull requests and issues are welcome on those repositories. Their contents are released under the MIT License.
Yocto Project and all related marks and logos are trademarks of The Linux Foundation. This website is not, in any way, endorsed by the Yocto Project or The Linux Foundation.
Enjoy Geniux!
]]>If you are an eligible and interested contributor, read through the list and note the projects you are interested in. You, as the contributor programmer, then submit a proposal to Google, using the GSoC 2024 website. The application form for contributors will be open from March 18, 18:00 UTC, until April 2 at 19:00 UTC. We recommend you to submit your application early. By doing so, it will be given a greater share of attention than is possible for applications submitted at the last minute.
You might submit a proposal following the guidelines below, or you might want to adapt them to your needs. Changes to the proposal could include:
You think the project as suggested is too large and you can only feasibly complete part of it; if so, make sure your proposal covers a reasonable subset of the functionality (that is, something which is useful without the rest of the project being implemented).
You think the project as suggested is too small; in this case, you might want to extend the idea, combine projects, etc.
You like the basic idea of the project but it is not such a good fit for the skills that you have; in this case please feel free to suggest an alternative, but try to remember that the idea is for the software to be useful for its existing and potential users.
Your proposal should include the following: your project proposal, why you would like to execute on this particular project, and the reason you are the best individual to do so. Your proposal should also include details of your academic, industry, and/or open-source development experience, and other details as you see fit. An explanation of your development methodology and schedule is a good idea, as well. It is always helpful to include your contact information, as it will not be automatically shared with your would-be mentors as part of the proposal process.
Hereafter we list, in no particular order, some proposals for projects to be carried out by the contributors participating in GSoC 2024. This is by no means a closed list, so the contributors can feel free to propose alternative activities related to GNSS-SDR. Original topics for proposals are especially welcome and use to be highly ranked.
Large-sized project (350 h)
This Google Summer of Code (GSoC) project focuses on advancing the functionalities of GNSS receiver related to EGNOS (European Geostationary Navigation Overlay Service).
The primary goal for the summer is to provide a working implementation of a GNSS receiver working with EGNOS/WAAS signals: Signal acquisition and tracking algorithms for their specific signals. The outcome should be a robust GNSS receiver capable of delivering RINEX files and real-time navigation solutions.
Implement acquisition and tracking algorithms for EGNOS/WAAS signals, following the examples already implemented for other GNSS signals. This would facilitate research on the ionosphere, precise positioning and drone-related activities working with real signals. Demodulation of the navigation message, opening the door to open innovation in multi-constellation receivers. Integration of EGNOS/WAAS observables into the PVT position.
Basic knowledge of digital signal processing and proficiency in C++ programming are essential. Familiarity with the GNU Radio framework or GNSS-SDR is considered a valuable plus.
Miguel Ángel Gómez, Luis Esteve, Javier Arribas.
Large-sized project (350 h)
This Google Summer of Code initiative focuses on advancing sensor fusion capabilities between GNSS (Global Navigation Satellite System) and INS (Inertial Navigation System). The objective is to develop a functional implementation of a GNSS receiver capable of introducing another sensor information in the GNSS receiver architecture, delivering RINEX files and enabling on-the-fly navigation solutions, encompassing real-time computation of position, velocity, and time. This data (new sensors and GNSS signal) would be fused using state of the art methods, based in AI (i.e., ANN and VAE for dimensionality reduction). This would facilitate research on sensor fusion, precise positioning and urban cannon, working with real signals.
The addition of sensors to the receiver is a cornerstone in the development of new receivers, opening the door to open innovation in multi-constellation receivers and addressing topics such as integrity, reliability, robustness, enhanced coverage, and high-accuracy positioning.
Applicants should possess a fundamental understanding of digital signal processing and demonstrate proficiency in C++ programming. Knowledge of GNSS principles and prior experience with sensor fusion, particularly between GNSS and INS, will be advantageous.
Miguel Ángel Gómez.
Large-sized project (350 h)
In recent years, Software Defined Radio (SDR) has gained significant momentum. For the first time, there are fully functional commercial solutions for various SDR systems in the fields of communications and positioning systems based entirely on signal processing in a general-purpose Central Processing Unit (CPU). The use of a direct conversion analog front-end (zero IF) to receive the RF signal is still the most common solution to feed the SDR receiver with the digitized baseband signal. The future of SDR involves a direct sampling of the RF signal with extremely fast ADC converters (in the order of Giga Samples per second) integrated into a System-on-Chip (SoC). This SoC consists of an FPGA tightly coupled with a multi-core ARM CPU. The project proposed here aims to explore the capabilities of an SDR system based on the Xilinx Zynq UltraScale+ RFSoC chip kit [1] with an innovative programming environment that blends Python and synthesizable C++ modules on the FPGA using Xilinx’s intelligent compiler (Vitis_hls). The contributor work has a substantial practical component with the RFSoC 4x2 board installed at the Telecommunications Technological Center of Catalonia (CTTC) on the PMT campus in Castelldefels, capable of being operated remotely.
The contributor will begin by familiarizing themselves with the Python environment for RFSoC, C++ processing modules, and GNURadio. They will conduct tests with real RF signals using available code examples. Once this is achieved, the final objective of the project will be to achieve the reception and processing of multi-band Global Navigation Satellite Systems (GNSS) signals with the open-source GNSS-SDR software, taking the digital baseband from the RFSoC. This is a research project with the potential to generate publishable results in scientific conferences or journals. More information about the RFSoC Software environment can be found here: http://www.rfsoc-pynq.io/
[1] https://www.xilinx.com/support/university/xup-boards/RFSoC4x2.html
Javier Arribas.
Medium-sized project (175h)
This is a continuation of efforts developed during GSoC 2019. The code needs updates, some bug fixing, and improve over existing algorithms.
The objective by the end of the summer is to provide a working implementation of a GNSS receiver working with Beidou B2a signals, delivering RINEX files (the standard input of geodesic software libraries for high—accuracy positioning) and an on-the-fly navigation solution (that is, computation of position, velocity and time of the user’s receiver).
Implementation of acquisition and tracking algorithms for Beidou B2a signals, following the examples already implemented for other GNSS signals. This would facilitate research on multi-constellation, multi-frequency receivers (e.g., GPS + Galileo + Beidou) working with real signals.
Demodulation of the navigation message, opening the door to open innovation in multi-constellation receivers and addressing topics such as integrity, reliability, robustness, enhanced coverage, and high-accuracy positioning.
Integration of Beidou observables into the PVT position.
Basic knowledge of digital signal processing and C++ programming (familiarity with the GNU Radio framework or GNSS-SDR is a plus).
Damian Miralles, Luis Esteve.
Medium-sized project (175h)
This is a continuation of efforts developed during GSoC 2019. The code needs updates, some bug fixing, and improve over existing algorithms.
The objective by the end of the summer is to provide a working implementation of a GNSS receiver working with Beidou B1C signals, delivering RINEX files (the standard input of geodesic software libraries for high—accuracy positioning) and an on-the-fly navigation solution (that is, computation of position, velocity and time of the user’s receiver).
Implementation of acquisition and tracking algorithms for Beidou B1C signals, following the examples already implemented for other GNSS signals. This would facilitate research on multi-constellation, multi-frequency receivers (e.g., GPS + Galileo + Beidou) working with real signals.
Demodulation of the navigation message, opening the door to open innovation in multi-constellation receivers and addressing topics such as integrity, reliability, robustness, enhanced coverage, and high-accuracy positioning.
Integration of Beidou observables into the PVT position.
Basic knowledge of digital signal processing and C++ programming (familiarity with the GNU Radio framework or GNSS-SDR is a plus).
Damian Miralles, Luis Esteve.
Please provide in your proposal the information listed down below. Text formatting is up to you, but be sure to include those sections. Other additions are welcome if relevant.
flag_geohash_log_out
) that
enables or disables the Position Geohash tag output in INFO log files. Set to
false
by default.monitor_pvt.proto
:
utc_time
(a RFC 3339 datetime
string),vel_e
, vel_n
, and vel_u
), in m/s,cog
, in degrees,galhas_status
:
geohash
, an
encoded geographic location.cpu_features
library to v0.9.0.volk_gnsssdr
: fix syntax for Python 3.12 without breaking backward
compatibility with Python 2.7.volk_gnsssdr
arising from incompatibility
between complex numbers in C and C++.arm64
processor architecture.PVT.enable_pvt_kf=true
in the configuration
file. The user can set values for the measurement and process noise
covariances with the following optional parameters (here with their default
values): PVT.kf_measures_ecef_pos_sd_m=1.0
, in [m];
PVT.kf_measures_ecef_vel_sd_ms=0.1
, in [m/s];
PVT.kf_system_ecef_pos_sd_m=2.0
, in [m]; and
PVT.kf_system_ecef_vel_sd_ms=0.5
, in [m/s].false
by
default. You can activate its usage with Galileo_E1B_Telemetry_Decoder=true
in your configuration file.PVT.use_e6_for_pvt=false
, fixing the PVT computation in some multi-band
configurations.PVT.enable_monitor=true
) output rate.
Before this fix, it was outputting data every 20 ms, instead of observing the
PVT.output_rate_ms
setting.PVT.output_rate_ms
(500
ms by default), and can be
particularized by PVT.kml_rate_ms
, PVT.gpx_rate_ms
, PVT.geojson_rate_ms
,
and PVT.nmea_rate_ms
. Those values should be multiples of
PVT.output_rate_ms
, or the least common multiple will be taken.As usual, compressed tarballs are available from GitHub and Sourceforge.
]]>We are thrilled to announce that our FPGA IP cores for GNSS-SDR are now commercially available, unlocking unprecedented possibilities for high-performance, flexible, and efficient GNSS signal processing.
Visit our commercial website at https://navposproducts.cttc.es
]]>Geniux (GNSS-SDR for Embedded GNU/Linux) is a customized GNU/Linux distribution for developing and running GNSS-SDR on embedded devices, based on the Yocto Project. This Operating System includes a specific set of popular tools, libraries, and device drivers tailored for supporting an extended range of Software Defined Radio applications, helping to bring them to production-ready deployments with an approach widely adopted throughout the embedded/IoT industry.
The Geniux distribution comes in different version names, following those of the Yocto Project, being Rocko the oldest supported version. Each version name is tagged with a timestamp, so Geniux versions can evolve in time, but tagged versions can be reproduced at any time in the future. In addition, each version and each time tag can be built for a particular board or machine. This is expressed in the figure below:
Geniux keeps the pace of the software ecosystem evolution, but older versions are still reproducible. Virtualization technology allows reproducing images regardless of the software stack running at the host system building it.
Those names (Rocko, Sumo, Thud, Warrior, Zeus, etc.) represent major Geniux
versions. Then, each named version can have time tags (in the figure above,
20.09
and 20.10
). All versions have a latest
tag pointing to the latest
commit. Each named version with a time tag can be built for different
boards or machines (in the figure above, zedboard-zynq7
and rasperrypi3
).
The Geniux distribution follows the versioning format
VERSION_NAME-MANIFEST_DATE.CONF_NUMBER
, where:
rocko
, sumo
, thud
, warrior
, zeus
, dunfell
, gatesgarth
,
hardknott
, honister
, kirkstone
, langdale
.latest
always exists for each version name, and points to the
latest release.
20.09
, 21.02
, …, 21.08
, 22.02
, 22.06
, 23.04
, latest
.0
, 1
, …Example of version name: rocko-23.04.0
.
The generation of images and SDKs for a given Geniux version, time tag, and machine in a virtualized environment is automated by the yocto-geniux repository. With Docker already installed and running on your system, clone the Git repository and go to its base path:
$ git clone https://github.com/carlesfernandez/yocto-geniux
$ cd yocto-geniux
Now you are ready to build Geniux images for the release you want with a single
command, by using the geniux-builder.sh
script. Taking a look at its help
message:
$ ./geniux-builder.sh --help
You should get:
This script builds and stores Geniux images.
Usage:
./geniux-builder.sh [version] [manifest] [machine] (--image-only / -i)
Options:
version Geniux version (from oldest to most recent):
rocko, sumo, thud, warrior, zeus, dunfell,
gatesgarth, hardknott, honister, kirkstone, langdale. Default: dunfell
Check available branches at https://github.com/carlesfernandez/meta-gnss-sdr
manifest Geniux version manifest: 21.02, 21.08, 22.02, 22.06, 23.04, latest. Default: latest
Dated manifests available at https://github.com/carlesfernandez/oe-gnss-sdr-manifest/tags
machine Specify your (list of) MACHINE here. By default, zedboard-zynq7 and raspberrypi3 are built.
If more than one, surround it with quotes, e.g.: "raspberrypi4-64 intel-corei7-64"
--image-only / -i (optional) Build the image but do not execute the container.
Environment variables that affect behavior:
GENIUX_MIRROR_PATH Base path to local mirror. Only used if set.
e.g.: 'export GENIUX_MIRROR_PATH=/home/carlesfernandez/mirror'
The mirror is expected to be at '$GENIUX_MIRROR_PATH/sources/$version'
GENIUX_STORE_PATH Path in which products will be stored. Only used if set.
e.g.: 'export GENIUX_STORE_PATH=/home/carlesfernandez/geniux-releases'
GENIUX_STORE_REQUIRES_SUDO If set, the script will ask for super-user privileges to write in the store.
You will be asked only once at the beginning. The password will not be revealed.
e.g.: 'export GENIUX_STORE_REQUIRES_SUDO=1'
You can find specific examples of how to use this script below. For more advanced usage modes (e.g., an interactive mode that allows you to make changes and experiment), check the instructions here.
The building process takes several hours and requires a powerful host system
with at least 120 GB of free space in the hard disk and 32 GB of RAM. When
finished, you will get your products in the output/
folder (or wherever the
GENIUX_STORE_PATH
environment variable points to). Among others:
wic.xz
and wic.bmap
image files ready to de
deployed on an SD card.Please note that if the automated building process fails for some reason
(failing network connection, misconfiguration, disappeared source repositories,
shortage of free hard disk space, RAM memory or CPU resources, etc.) before it
finishes, the running container will be deleted and you will lose everything, so
you will need to start over again. For a safer procedure, you can use the
interactive
mode
of the Docker image, which allows you to make changes, retry after a failure,
build other images, and save your products to /home/geniux/yocto/output/
when
done, so outside the Docker container. The container itself will be deleted at
exit.
pip3
.meta-xilinx-bsp
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.meta-gnss-sdr
layer is compatible with Xilinx PetaLinux Tools v2018.3.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh rocko 23.04 zedboard-zynq7
$ ./geniux-builder.sh rocko 23.04 zcu102-zynqmp
$ ./geniux-builder.sh rocko 23.04 raspberrypi3
$ ./geniux-builder.sh rocko 23.04 intel-corei7-64
$ ./geniux-builder.sh rocko 23.04 qemuarm
You can replace 23.04
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh sumo 23.04 zedboard-zynq7
$ ./geniux-builder.sh sumo 23.04 raspberrypi3
$ ./geniux-builder.sh sumo 23.04 intel-corei7-64
$ ./geniux-builder.sh sumo 23.04 qemuarm64
You can replace 23.04
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.
meta-xilinx
layer points to the rel-v2019.2
branch.meta-gnss-sdr
layer is compatible with Xilinx PetaLinux Tools v2019.2.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh thud 23.04 zedboard-zynq7
$ ./geniux-builder.sh thud 23.04 zcu102-zynqmp
$ ./geniux-builder.sh thud 23.04 raspberrypi3
$ ./geniux-builder.sh thud 23.04 intel-corei7-64
$ ./geniux-builder.sh thud 23.04 qemuarm64
You can replace 23.04
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh warrior 23.04 zedboard-zynq7
$ ./geniux-builder.sh warrior 23.04 raspberrypi4-64
$ ./geniux-builder.sh warrior 23.04 intel-corei7-64
$ ./geniux-builder.sh warrior 23.04 qemuarm64
You can replace 23.04
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.
meta-xilinx
layer points to rel-v2020.3
branch.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh zeus 23.04 zedboard-zynq7
$ ./geniux-builder.sh zeus 23.04 raspberrypi4-64
$ ./geniux-builder.sh zeus 23.04 intel-skylake-64
$ ./geniux-builder.sh zeus 23.04 qemuarm64
You can replace 23.04
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh dunfell 23.04 zedboard-zynq7
$ ./geniux-builder.sh dunfell 23.04 raspberrypi4-64
$ ./geniux-builder.sh dunfell 23.04 intel-corei7-64
$ ./geniux-builder.sh dunfell 23.04 qemuarm64
You can replace 23.04
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.
meta-xilinx
layer points to the rel-v2021.2
branch.linux-xlnx
kernel for zedboard-zynq7
machine, based on Linux kernel
5.10.meta-gnss-sdr
layer is compatible with Xilinx PetaLinux Tools v2021.2.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh gatesgarth 23.04 zedboard-zynq7
$ ./geniux-builder.sh gatesgarth 23.04 zc706-zynq7
$ ./geniux-builder.sh gatesgarth 23.04 raspberrypi4-64
$ ./geniux-builder.sh gatesgarth 23.04 intel-skylake-64
$ ./geniux-builder.sh gatesgarth 23.04 qemuarm64
You can replace 23.04
by latest
in order to get the latest developments.
pip3
.meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh hardknott 23.04 intel-corei7-64
$ ./geniux-builder.sh hardknott 23.04 raspberrypi4-64
$ ./geniux-builder.sh hardknott 23.04 qemuarm64
You can replace 23.04
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-xilinx-vendor
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.
meta-xilinx
layer points to the rel-v2022.2
branch.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh honister 23.04 intel-corei7-64
$ ./geniux-builder.sh honister 23.04 raspberrypi4-64
$ ./geniux-builder.sh honister 23.04 zedboard-zynq7
$ ./geniux-builder.sh honister 23.04 zc706-zynq7
$ ./geniux-builder.sh honister 23.04 zcu102-zynqmp
$ ./geniux-builder.sh honister 23.04 zcu208-zynqmp
You can replace 23.04
by latest
in order to get the latest developments.
pip3
.meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh kirkstone 23.04 intel-corei7-64
$ ./geniux-builder.sh kirkstone 23.04 raspberrypi4-64
You can replace 23.04
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-xilinx-vendor
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh langdale 23.04 intel-corei7-64
$ ./geniux-builder.sh langdale 23.04 raspberrypi4-64
$ ./geniux-builder.sh langdale 23.04 zedboard-zynq7
$ ./geniux-builder.sh langdale 23.04 zcu208-zynqmp
You can replace 23.04
by latest
in order to get the latest developments.
Starting from Geniux Zeus 21.08, the geniux-builder.sh
script produces .wic
images that can be flashed on an SD card and your device will be ready to go.
For image flashing, we recommend using a software tool such as Balena
Etcher. Just pick up the
gnss-sdr-demo-image-$MACHINE-yyyymmddHHMMSS.rootfs.wic.xz
file, flash your SD
card, insert it in your device, and it will be ready to boot and run gnss-sdr
.
Other flashing options here.
All the required information for building a Geniux release is contained in three public repositories:
rocko
, sumo
,
thud
, warrior
, zeus
, dunfell
, gatesgarth
, hardknott
, honister
,
kirkstone
, langdale
. Those branches are updated as we learn more about the Yocto
Project usage, so they evolve in time.rocko
, sumo
,
thud
, warrior
, zeus
, dunfell
, gatesgarth
, hardknott
, honister
,
kirkstone
, langdale
.meta-gnss-sdr
has been pinned to a specific commit. This allows
fully-reproducible buildings in the future since it defines a
fully-specified software system set. Examples: rocko-20.09
, sumo-20.09
,
thud-20.09
, etc.MANIFEST_DATE
is set to latest
, all the
layers are pinned to a specific commit but except the meta-gnss-sdr
layer,
which points to whatever it is in the corresponding branch of that layer at
that point of time.If you miss any feature on Geniux, or have an idea on how to make it better, pull requests and issues are welcome on those repositories. Their contents are released under the MIT License.
Yocto Project and all related marks and logos are trademarks of The Linux Foundation. This website is not, in any way, endorsed by the Yocto Project or The Linux Foundation.
Enjoy Geniux!
]]>PVT.use_has_corrections
, set to true
by default, can be used to deactivate
the application of HAS corrections but still retrieve the HAS data if set to
false
.Acquisition_XX.blocking=false
.PVT.bancroft_init=false
in
your configuration file.ZMQ_Signal_Source
for working with streams of samples published via
ZeroMQ.Labsat_Signal_Source
. This
fix is only available if gnss-sdr is linked against Boost >= 1.58.0.lapack
port dependency installed with the +openblas
variant does not install blas
but openblas
, which is used as a replacement if blas
is not found).-DENABLE_FPGA=ON
building option).gnss-sdr
binary and/or the GNU Radio
libraries were built with the -D_GLIBCXX_ASSERTIONS
compiler option. This is
added by default in some GNU/Linux distributions (e.g., ArchLinux and Fedora).-DENABLE_OWN_GLOG
,
-DENABLE_OWN_ARMADILLO
, and -DENABLE_OWN_GNSSTK
can now be switched ON
and OFF
without the need to start from an empty buiding folder.volk_gnsssdr
if the corresponding
environment variables are defined. This fixes warnings in some packaging
systems.very-long-line-length-in-source-file
warnings since those files were not
recognized as binaries. The configuration flag -DENABLE_PACKAGING=ON
passed
to CMake deactivates file downloading.ENABLE_GENERIC_ARCH
building option was removed, simplifying the process
of buiding the software in non-x86 processor architectures.GLONASS_L1_CA_DLL_PLL_C_Aid_Tracking
and
GLONASS_L2_CA_DLL_PLL_C_Aid_Tracking
implementations.UHD_Signal_Source
learned a new parameter otw_format
for setting the
over-the-wire data format
(that is, the format used between the device and the UHD) in some devices,
thus allowing to select the sc8
format instead of the default sc16
. This
would reduce the dynamic range and increase quantization noise, but also
reduce the load on the data link and thus allow more bandwidth.UHD_Signal_Source
learned another two optional parameters:
device_recv_frame_size
and device_num_recv_frames
for overriding
transport layer defaults.Osmosdr_Signal_Source
implementation of a SignalSource
.Osmosdr_Signal_Source
implementation learned a new parameter if_bw
to
manually set the bandwidth of the bandpass filter on the radio frontend.Channels_XX.RF_channel_ID
allows to specify
the signal source per channel group.PVT.use_unhealthy_sats
, set by default to
false
, allows processing observables of satellites that report an unhealthy
status in the navigation message if set to true
.As usual, compressed tarballs are available from GitHub and Sourceforge.
In order to make GNSS-SDR more easily referenced, and to promote reproducible research, each software release gets a Digital Object Identifier provided by Zenodo. The DOI for GNSS-SDR v0.0.18 is 10.5281/zenodo.7805514.
]]>Geniux (GNSS-SDR for Embedded GNU/Linux) is a customized GNU/Linux distribution for developing and running GNSS-SDR on embedded devices, based on the Yocto Project. This Operating System includes a specific set of popular tools, libraries, and device drivers tailored for supporting an extended range of Software Defined Radio applications, helping to bring them to production-ready deployments with an approach widely adopted throughout the embedded/IoT industry.
The Geniux distribution comes in different version names, following those of the Yocto Project, being Rocko the oldest supported version. Each version name is tagged with a timestamp, so Geniux versions can evolve in time, but tagged versions can be reproduced at any time in the future. In addition, each version and each time tag can be built for a particular board or machine. This is expressed in the figure below:
Geniux keeps the pace of the software ecosystem evolution, but older versions are still reproducible. Virtualization technology allows reproducing images regardless of the software stack running at the host system building it.
Those names (Rocko, Sumo, Thud, Warrior, Zeus, etc.) represent major Geniux
versions. Then, each named version can have time tags (in the figure above,
20.09
and 20.10
). All versions have a latest
tag pointing to the latest
commit. Each named version with a time tag can be built for different
boards or machines (in the figure above, zedboard-zynq7
and rasperrypi3
).
The Geniux distribution follows the versioning format
VERSION_NAME-MANIFEST_DATE.CONF_NUMBER
, where:
rocko
, sumo
, thud
, warrior
, zeus
, dunfell
, gatesgarth
,
hardknott
, honister
, kirkstone
.latest
always exists for each version name, and points to the
latest release.
20.09
, 21.02
, …, 21.08
, 22.02
, 22.06
, latest
.0
, 1
, …Example of version name: rocko-22.06.0
.
The generation of images and SDKs for a given Geniux version, time tag, and machine in a virtualized environment is automated by the yocto-geniux repository. With Docker already installed and running on your system, clone the Git repository and go to its base path:
$ git clone https://github.com/carlesfernandez/yocto-geniux
$ cd yocto-geniux
Now you are ready to build Geniux images for the release you want with a single
command, by using the geniux-builder.sh
script. Taking a look at its help
message:
$ ./geniux-builder.sh --help
You should get:
This script builds and stores Geniux images.
Usage:
./geniux-builder.sh [version] [manifest] [machine] (--image-only / -i)
Options:
version Geniux version: rocko, sumo, thud, warrior, zeus,
dunfell, gatesgarth, hardknott, honister, kirkstone. Default: dunfell
Check available branches at https://github.com/carlesfernandez/meta-gnss-sdr
manifest Geniux version manifest: 21.02, 21.08, 22.02, 22.06, latest. Default: latest
Dated manifests available at https://github.com/carlesfernandez/oe-gnss-sdr-manifest/tags
machine Specify your (list of) MACHINE here. By default, zedboard-zynq7 and raspberrypi3 are built.
If more than one, surround it with quotes, e.g.: "raspberrypi4-64 intel-corei7-64"
--image-only / -i (optional) Build the image but do not execute the container.
Environment variables that affect behavior:
GENIUX_MIRROR_PATH Base path to local mirror. Only used if set.
e.g.: 'export GENIUX_MIRROR_PATH=/home/carlesfernandez/mirror'
The mirror is expected to be at '$GENIUX_MIRROR_PATH/sources/$version'
GENIUX_STORE_PATH Path in which products will be stored. Only used if set.
e.g.: 'export GENIUX_STORE_PATH=/home/carlesfernandez/geniux-releases'
GENIUX_STORE_REQUIRES_SUDO If set, the script will ask for super-user privileges to write in the store.
You will be asked only once at the beginning. The password will not be revealed.
e.g.: 'export GENIUX_STORE_REQUIRES_SUDO=1'
You can find specific examples of how to use this script below. For more advanced usage modes (e.g., an interactive mode that allows you to make changes and experiment), check the instructions here.
The building process takes several hours and requires a powerful host system
with at least 120 GB of free space in the hard disk and 32 GB of RAM. When
finished, you will get your products in the output/
folder (or wherever the
GENIUX_STORE_PATH
environment variable points to). Among others:
wic.xz
and wic.bmap
image files ready to de
deployed on an SD card.Please note that if the automated building process fails for some reason
(failing network connection, misconfiguration, disappeared source repositories,
shortage of free hard disk space, RAM memory or CPU resources, etc.) before it
finishes, the running container will be deleted and you will lose everything, so
you will need to start over again. For a safer procedure, you can use the
interactive
mode
of the Docker image, which allows you to make changes, retry after a failure,
build other images, and save your products to /home/geniux/yocto/output/
when
done, so outside the Docker container. The container itself will be deleted at
exit.
pip3
.meta-xilinx-bsp
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.meta-gnss-sdr
layer is compatible with Xilinx PetaLinux Tools v2018.3.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh rocko 22.06 zedboard-zynq7
$ ./geniux-builder.sh rocko 22.06 zcu102-zynqmp
$ ./geniux-builder.sh rocko 22.06 raspberrypi3
$ ./geniux-builder.sh rocko 22.06 intel-corei7-64
$ ./geniux-builder.sh rocko 22.06 qemuarm
You can replace 22.06
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh sumo 22.06 zedboard-zynq7
$ ./geniux-builder.sh sumo 22.06 raspberrypi3
$ ./geniux-builder.sh sumo 22.06 intel-corei7-64
$ ./geniux-builder.sh sumo 22.06 qemuarm64
You can replace 22.06
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.
meta-xilinx
layer points to the rel-v2019.2
branch.meta-gnss-sdr
layer is compatible with Xilinx PetaLinux Tools v2019.2.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh thud 22.06 zedboard-zynq7
$ ./geniux-builder.sh thud 22.06 zcu102-zynqmp
$ ./geniux-builder.sh thud 22.06 raspberrypi3
$ ./geniux-builder.sh thud 22.06 intel-corei7-64
$ ./geniux-builder.sh thud 22.06 qemuarm64
You can replace 22.06
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh warrior 22.06 zedboard-zynq7
$ ./geniux-builder.sh warrior 22.06 raspberrypi4-64
$ ./geniux-builder.sh warrior 22.06 intel-corei7-64
$ ./geniux-builder.sh warrior 22.06 qemuarm64
You can replace 22.06
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.
meta-xilinx
layer points to rel-v2020.3
branch.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh zeus 22.06 zedboard-zynq7
$ ./geniux-builder.sh zeus 22.06 raspberrypi4-64
$ ./geniux-builder.sh zeus 22.06 intel-skylake-64
$ ./geniux-builder.sh zeus 22.06 qemuarm64
You can replace 22.06
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh dunfell 22.06 zedboard-zynq7
$ ./geniux-builder.sh dunfell 22.06 raspberrypi4-64
$ ./geniux-builder.sh dunfell 22.06 intel-corei7-64
$ ./geniux-builder.sh dunfell 22.06 qemuarm64
You can replace 22.06
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.
meta-xilinx
layer points to the rel-v2021.2
branch.linux-xlnx
kernel for zedboard-zynq7
machine, based on Linux kernel
5.10.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh gatesgarth 22.06 zedboard-zynq7
$ ./geniux-builder.sh gatesgarth 22.06 raspberrypi4-64
$ ./geniux-builder.sh gatesgarth 22.06 intel-skylake-64
$ ./geniux-builder.sh gatesgarth 22.06 qemuarm64
You can replace 22.06
by latest
in order to get the latest developments.
pip3
.meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh hardknott 22.06 intel-corei7-64
$ ./geniux-builder.sh hardknott 22.06 raspberrypi4-64
$ ./geniux-builder.sh hardknott 22.06 qemuarm64
You can replace 22.06
by latest
in order to get the latest developments.
pip3
.meta-xilinx-bsp
,
meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.
meta-xilinx
layer points to the rel-v2022.1
branch.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh honister 22.06 intel-corei7-64
$ ./geniux-builder.sh honister 22.06 raspberrypi4-64
$ ./geniux-builder.sh honister 22.06 zedboard-zynq7
$ ./geniux-builder.sh honister 22.06 zcu102-zynqmp
$ ./geniux-builder.sh honister 22.06 zcu208-zynqmp
You can replace 22.06
by latest
in order to get the latest developments.
pip3
.meta-raspberrypi
,
meta-intel
,
and
openembedded-core/meta
layers.Examples on how to generate images and the SDK using the yocto-geniux repo:
$ ./geniux-builder.sh kirkstone 22.06 intel-corei7-64
$ ./geniux-builder.sh kirkstone 22.06 raspberrypi4-64
You can replace 22.06
by latest
in order to get the latest developments.
Starting from Geniux Zeus 21.08, the geniux-builder.sh
script produces .wic
images that can be flashed on an SD card and your device will be ready to go.
For image flashing, we recommend using a software tool such as Balena
Etcher. Just pick up the
gnss-sdr-demo-image-$MACHINE-yyyymmddHHMMSS.rootfs.wic.xz
file, flash your SD
card, insert it in your device, and it will be ready to boot and run gnss-sdr
.
Other flashing options here.
All the required information for building a Geniux release is contained in three public repositories:
rocko
, sumo
,
thud
, warrior
, zeus
, dunfell
, gatesgarth
, hardknott
, honister
,
kirkstone
. Those branches are updated as we learn more about the Yocto
Project usage, so they evolve in time.rocko
, sumo
,
thud
, warrior
, zeus
, dunfell
, gatesgarth
, hardknott
, honister
,
kirkstone
.meta-gnss-sdr
has been pinned to a specific commit. This allows
fully-reproducible buildings in the future since it defines a
fully-specified software system set. Examples: rocko-20.09
, sumo-20.09
,
thud-20.09
, etc.MANIFEST_DATE
is set to latest
, all the
layers are pinned to a specific commit but except the meta-gnss-sdr
layer,
which points to whatever it is in the corresponding branch of that layer at
that point of time.If you miss any feature on Geniux, or have an idea on how to make it better, pull requests and issues are welcome on those repositories. Their contents are released under the MIT License.
Yocto Project and all related marks and logos are trademarks of The Linux Foundation. This website is not, in any way, endorsed by the Yocto Project or The Linux Foundation.
Enjoy Geniux!
]]>cpu_features
library to v0.7.0. The building option
ENABLE_OWN_CPUFEATURES
has been replaced by ENABLE_CPUFEATURES
, defaulting
to ON
.src/utils/scripts/download-galileo-almanac.sh
that
downloads an XML file with the latest Galileo almanac published by the
European GNSS Service Centre at https://www.gsc-europa.eu/gsc-products/almanacAs usual, compressed tarballs are available from GitHub and Sourceforge.
In order to make GNSS-SDR more easily referenced, and to promote reproducible research, each software release gets a Digital Object Identifier provided by Zenodo. The DOI for GNSS-SDR v0.0.17 is 10.5281/zenodo.6473244.
]]>If you are an eligible and interested student, read through the list and note the projects you are interested in. You, as the student programmer, then submit a proposal to Google, using the GSoC 2022 website. The application form for students will be open from April 4, until April 19 at 18:00 UTC. We recommend you to submit your application early. By doing so, it will be given a greater share of attention than is possible for applications submitted at the last minute.
You might submit a proposal following the guidelines below, or you might want to adapt them to your needs. Changes to the proposal could include:
You think the project as suggested is too large and you can only feasibly complete part of it; if so, make sure your proposal covers a reasonable subset of the functionality (that is, something which is useful without the rest of the project being implemented).
You think the project as suggested is too small; in this case, you might want to extend the idea, combine projects, etc.
You like the basic idea of the project but it is not such a good fit for the skills that you have; in this case please feel free to suggest an alternative, but try to remember that the idea is for the software to be useful for its existing and potential users.
Your proposal should include the following: your project proposal, why you would like to execute on this particular project, and the reason you are the best individual to do so. Your proposal should also include details of your academic, industry, and/or open-source development experience, and other details as you see fit. An explanation of your development methodology and schedule is a good idea, as well. It is always helpful to include your contact information, as it will not be automatically shared with your would-be mentors as part of the proposal process.
Hereafter we list, in no particular order, some proposals for projects to be carried out by the students participating in GSoC 2022. This is by no means a closed list, so the students can feel free to propose alternative activities related to GNSS-SDR. Original topics for proposals are especially welcome and use to be highly ranked.
This is a continuation of the work developed during GSoC 2021.
GNSS technology is vulnerable to spoofing attacks, in which a malicious agent imitates genuine GNSS signals in order to feed a false location to a target user. Spoofing detection and mitigation has been a topic of significant interest in the GNSS community for decades. Recent developments have resulted in GPS receiver architectures which are capable of identifying and rejecting spoofed signals, allowing the receiver to obtain estimates of the true receiver location even during a spoofing attack.
Good understanding of spoofing detection and mitigation methods, GNSS signal processing and C++ programming (familiarity with the GNU Radio framework is a plus).
Mr. Luis Esteve, Dr. Carles Fernández-Prades.
This is a continuation of the work developed during previous GSoC editions, and some additional voluntary efforts by the mentor. The code is almost complete, but some additional bug fixing and refinements are needed.
The objective by the end of the summer is to provide a working implementation of a GNSS receiver working with Beidou B2a signals, delivering RINEX files (the standard input of geodesic software libraries for high—accuracy positioning) and an on-the-fly navigation solution (that is, computation of position, velocity and time of the user’s receiver).
next
.Basic knowledge of digital signal processing and C++ programming (familiarity with the GNU Radio framework or GNSS-SDR is a plus).
Dr. Damian Miralles, Mr. Luis Esteve.
This is a continuation of efforts developed during GSoC 2019. The code needs updates, some bug fixing, and improvements over existing algorithms.
The objective by the end of the summer is to provide a working implementation of a GNSS receiver working with Beidou B1C signals, delivering RINEX files (the standard input of geodesic software libraries for high—accuracy positioning) and an on-the-fly navigation solution (that is, computation of position, velocity and time of the user’s receiver). Implementation of acquisition and tracking algorithms for Beidou B1C signals, following the examples already implemented for other GNSS signals. This would facilitate research on multi-constellation, multi-frequency receivers (e.g., GPS + Galileo + Beidou) working with real signals. Demodulation of the navigation message, opening the door to open innovation in multi-constellation receivers and addressing topics such as integrity, reliability, robustness, enhanced coverage, and high-accuracy positioning. Integration of Beidou observables into the PVT position.
Basic knowledge of digital signal processing and C++ programming (familiarity with the GNU Radio framework or GNSS-SDR is a plus).
Dr. Damian Miralles, Mr. Luis Esteve.
Please provide in your proposal the information listed down below. Text formatting is up to you, but be sure to include those sections. Other additions are welcome if relevant.
Limesdr_Signal_Source
for interoperability with LimeSDR (requires gr-limesdr and the -DENABLE_LIMESDR=ON
building flag).cppcoreguidelines-prefer-member-initializer
clang-tidy check to enforce this policy.cpplint
job on GitHub: Added the build/include_what_you_use
filter for early detection of missing includes.clang-tidy
job on GitHub: More robust detection of LLVM paths installed by homebrew.cpu_features
library for improved processor detection.NavDataMonitor.enable_monitor=true
, NavDataMonitor.client_addresses=127.0.0.1
and NavDataMonitor.port=1237
in the configuration file. Format described in the nav_message.proto
file. A simple listener application written in C++ is included in src/utils/nav-listener
as an example.TelemetryDecoder_XX.dump_crc_stats=true
and, optionally, TelemetryDecoder_XX.dump_crc_stats_filename=./crc_stats
in the configuration file. At the end of the processing (or exiting with q
+ [Enter]
), the CRC check success rate will be reported in a file.UHD_Signal_Source
learned to dump data in folders that do not exist, e.g., if SignalSource.dump=true
, SignalSource.dump_filename=./non-existing/data.dat
, and the non-existing
folder does not exist, it will be created if the running user has writing permissions. This also works for absolute paths.PVT.rtk_trace_level
that sets the logging verbosity level of the RTKLIB library.Flag_PLL_180_deg_phase_locked
in the monitor output that indicates if the PLL got locked at 180 degrees, so the symbol sign is reversed.Channels.in_acquisition
, cannot be larger than the total number of channels. The program will stop if those requirements are not met in the configuration file.File_Signal_Source
and extended integration times.Fifo_Signal_Source
Signal Source implementation learned to handle the ibyte
type.CITATION.cff
file.As usual, compressed tarballs are available from GitHub and Sourceforge.
In order to make GNSS-SDR more easily referenced, and to promote reproducible research, each software release gets a Digital Object Identifier provided by Zenodo. The DOI for GNSS-SDR v0.0.16 is 10.5281/zenodo.6090349.
]]>