RadarSimPy, a radar simulator that produces baseband data you can process

A simulator that also ships the receiver

RadarSimPy is described as a Python-based radar simulator that models radar transceivers and simulates baseband data from point targets and 3D models, and the feature list is organised in four groups that are worth reading in order.

The first group is radar modelling: transceiver modelling, arbitrary waveforms including CW, FMCW, PMCW and Pulse, phase noise, and phase and amplitude modulation schemes including CDM, FDM, DDM and TDM, plus fast-time and slow-time modulation.

The second is simulation: baseband data from point targets and 3D models, interference simulation, target RCS simulation, and LiDAR point cloud simulation.

The third is signal processing, and this is the part that distinguishes the package from a bare scene generator. Range and Doppler processing, direction of arrival estimation with MUSIC, Root-MUSIC, ESPRIT and IAA, beamforming with Capon and Bartlett, and CFAR detection with CA-CFAR and OS-CFAR.

The fourth group is characterization: radar detection characteristics using Swerling's models. Swerling's models are the classical set of target fluctuation models, and having them in the same package means the detection performance you measure is against a defined target statistics rather than against a fixed reflector.

The audience is a student or engineer in radar signal processing who needs data to develop against. The phrase in the description that it is the perfect tool for anyone looking to develop new radar technologies or expand their knowledge of radar systems is the marketing voice, but the substance is real: the package pairs a scene generator with the receiver-side processing, so you can close the loop without leaving Python.

The licence is GPL-3.0, the last push to the repository was on 2026-10-16, and there are no GitHub releases recorded.

A Python package over C++ and CUDA binaries

The installation is unusual, and understanding why tells you how the project is put together.

The documented path is to download the pre-built module and place the `radarsimpy` folder in your project directory.

your_project.py
your_project.ipynb
radarsimpy/
  ├── __init__.py
  ├── [platform-specific binaries]
  ├── radar.py
  ├── processing.py
  └── ...

The folder is not a normal Python package directory with pure Python inside. It contains platform-specific binaries alongside the Python modules, and the README names them: on Windows `radarsimcpp.dll` and `simulator.xxx.pyd`, on Linux `libradarsimcpp.so` and `simulator.xxx.so`, and on macOS `libradarsimcpp.dylib` and `simulator.xxx.so`.

So the architecture is a Python layer over a C++ core, with a compiled simulator module per platform, and the .pyd extension on Windows is the giveaway that the simulator is an extension module rather than a subprocess.

The source tree confirms the structure. There is a `src/` directory for the C++ and Python sources, a `build.sh` and a `build.bat` alongside `build_config.py` and `build_instructions.md` for building from source, `package_source.py` with its own shell and batch variants for producing a source distribution, `benchmarks/`, `tests/`, `models/` for bundled assets, `references/` for papers, and `gen_docs/` for the documentation generation.

The Python build script confirms the toolchain. It imports Cython and builds extension modules, and its docstring says it builds the radarsimpy package with C++ extensions and CUDA support, supporting both CPU and GPU architectures. The constants at the top of the file are `VALID_ARCHS` set to cpu and gpu, with `DEFAULT_ARCH` set to cpu, which is a good summary of the project's default posture: the CPU path is the baseline and the GPU path is a variant.

The requirements file is small, with numpy at 2.0.0 or later and scipy at 1.9.0 or later as the core dependencies, and a set of optional mesh libraries where only one is needed: trimesh, pymeshlab, pyvista or meshio, with trimesh installed by default, and pygltflib for keyframed glTF and GLB targets through the animation kit.

Which platforms actually get a GPU build

The support matrix is the most useful thing in the README for anyone planning around this package, and it has a hole in it that is easy to miss.

| | CPU (x86-64) | CPU (ARM64) | GPU (CUDA) | | --------------- | ------------ | ----------- | ---------- | | Windows | yes | no | yes | | Linux | yes | yes | yes | | MacOS | yes | yes | no |

MacOS has no CUDA, which is obvious once stated, and Windows has no ARM64 CPU build. On Linux the GPU module is available for both x86-64 and ARM64.

The GPU build has a hardware floor that is stated repeatedly: it requires a GPU with Compute Capability 7.5, Turing or higher, with a link to the minimum required driver versions for CUDA 13.

The platform requirements below the matrix are specific enough to be useful. Windows needs the Visual C++ Runtime. Ubuntu 22.04 needs GCC 11 by default, Ubuntu 24.04 needs GCC 13, and Ubuntu 26.04 needs GCC 15, and all three are supported on x86-64 and ARM64. For generic Linux the documentation suggests trying the Ubuntu 22.04 or 24.04 module for your architecture, or requesting a custom build. On macOS, both Intel and Apple Silicon use the default Clang with no extra dependency.

The device selection is done at call time rather than at build time, which is the good design decision here. The simulator entry points `sim_radar`, `sim_rcs` and `sim_lidar` take a `device` argument.

from radarsimpy.simulator import sim_radar, gpu_available

print(gpu_available())  # True only on a GPU build with a usable CUDA device

data = sim_radar(radar, targets, device="auto")  # "auto" (default), "gpu" or "cpu"

The three modes have a subtlety that matters for anyone timing runs. `"auto"` uses the GPU when one is usable and the CPU otherwise, without a warning. `"gpu"` falls back to the CPU with a `RuntimeWarning` when no GPU is usable, so a timing taken from that run is a CPU timing. And `CUDA_VISIBLE_DEVICES=-1` hides the GPU, which makes `"auto"` run on the CPU. That last one is a useful trick, because it lets you benchmark the CPU path on a machine that has a GPU without reinstalling anything.

What the performance table actually shows

The README publishes execution times for the example notebooks in a separate radarsimnb repository, across three releases, and the numbers are worth reading carefully rather than as a benchmark claim.

The FMCW imaging radar example is the headline. On the CPU it takes more than 7200 seconds in the first two releases, and then 854.76 seconds in v15.4.0, which is a large improvement but still measured in minutes. The GPU column tells a different story: 2259.91 seconds on v12.5.0, 445.48 on v12.6.1 and 63.59 on v15.4.0.

So across those three releases the GPU path for that example improved by roughly a factor of thirty-five, and the CPU path by at least a factor of eight over the same span, though the CPU number is a floor rather than a measurement because the earlier runs were cut off at 7200 seconds.

Two things follow. First, the numbers show a project where the accelerator path is where the engineering effort is going, and the CPU path remains slow enough that a full imaging scene is impractical without one. Second, a CPU figure of more than 7200 seconds is a censored measurement, not a value, and treating it as a number would overstate the improvement.

The examples come from the radarsimnb notebooks repository, which is the right place to look for a complete scene, since the repository itself carries a `benchmarks/` directory and a `references/` directory of papers.

The fair reading is that RadarSimPy is fast enough for interactive work on smaller scenes and for the processing-chain development it is aimed at, and that the very largest imaging scenes remain a batch job on a GPU machine.

Where the model stops being physics

It is worth being blunt about what a simulator like this does and does not give you, because the package is used in research contexts where that distinction matters.

The modelling is a geometric and statistical model, not an electromagnetic solver. A point target returns a signal determined by a radar cross section and a position, a 3D model returns returns computed from its geometry, and interference is added as configured. None of that is the full multipath solution of Maxwell's equations over a real scene, and the LiDAR point cloud simulation is a geometric model as well. If your question is what a real radar sees in a cluttered urban canyon, including the clutter, the multipath and the material effects, this is not that tool.

The detection characterization is explicitly model-based too. Swerling's models give you target fluctuation statistics, and CFAR gives you a detection rule with a false alarm rate you set. That is exactly right for comparing algorithms and for a textbook or a course, and it is a deliberate abstraction rather than a measurement.

The other constraint is the pre-built binary distribution. The documented installation is a download of a pre-built module for your platform, which means the numerical core is a compiled artifact you did not build, from a vendor who also sells a commercial product at radarsimx.com. The GPL-3.0 licence covers the source, and the build scripts are in the repository, so building from source is possible. But the default experience is a binary download, and that is a meaningful difference from a pure-Python package for a team with supply chain requirements.

The practical fit is therefore: use it to develop and test signal processing chains, to generate scenarios you cannot easily measure, and to teach. Do not use it to certify that a radar will detect a target in a specific real environment.

The alternative is writing the simulator yourself, or using recorded data

The realistic alternatives are three, and they differ in what they cost.

The first is to write the signal path yourself in NumPy. For a single point target with a simple waveform, that is not much code, and it gives you full control and no binary dependency. The cost is that you are then maintaining the physics and the signal processing separately, which is exactly the duplication RadarSimPy exists to remove.

The second is to work from recorded or measured data instead of simulated data. Real recordings contain the imperfections that no simulator reproduces, and they are free. The cost is that you cannot change the scenario, so you cannot test your processing against a case you have not already been lucky enough to capture, and you have to find data with the right waveform, the right geometry and the right target dynamics.

The third is a different simulator with a different emphasis. There are electromagnetic solvers that solve Maxwell's equations over a mesh, which give you far more physical fidelity and cost orders of magnitude more to run, and there are statistical radar simulators that model detection and detection performance without a waveform-level baseband at all, which are the right tool if you only need detection statistics.

RadarSimPy's position between those is coherent. It is waveform-level, so you get real baseband data, and it is fast enough to iterate on a signal processing chain, which is the use the package is designed around. The processing library being in the same package is what closes the loop, since you can generate a scene, process it with the reference implementations, and know that a result you get matches what the package's own processing produces.

That last point is the underrated feature. When you are developing a DoA estimator or a CFAR variant, having the reference implementation next to your test is worth more than the fidelity of the scene.

Editorial conclusion

RadarSimPy suits a student or engineer who needs realistic radar returns to develop and test a signal processing chain against, and who wants the processing library in the same package so the reference chain is comparable. It does not suit a team that needs a validated, high-fidelity electromagnetic model, since the point target and geometric approaches are approximations, and it does not suit a macOS user who needs the GPU path, which the support matrix excludes. Verify first that the platform and CPU architecture you need has a build, that the waveform and processing features you require are in the version you take, and that the detection characteristics you plan to rely on match the Swerling model assumptions you are working under.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. Project website
4. radarsimx/radarsimpy on GitHub
5. README