LODESTONETechnical report TR-2026-01 · revision 3Հայերեն
Contents
  1. Cover and contents
  2. 1Introduction
  3. 2State of the art
  4. 3Physics of detection and identification
  5. 4System architecture
  6. 5Induction subsystem
  7. 6Radar subsystem
  8. 7Positioning and timing
  9. 8Signal processing and machine learning
  10. 9Work plan
  11. 10Team and responsibilities
  12. 11Budget and funding
  13. 12Risks, safety and quality
  14. AAppendices
Chapter 4

System architecture

The three sensing subsystems, their interfaces and the common time base.

This chapter gives an overview of the platform before the subsystems are described in detail in Chapters 5 to 7.

4.1Overview

Induction head 3 TX coils (x, y, z), 3 RX coils class-D drivers, current sense ×33 low-noise preamplifiers Radar ADALM-Pluto (AD9363) PA, LNA, coupler 2 Vivaldi antennas, 0.5–3 GHz Positioning RTK GNSS base and rover IMU, magnetometer camera, time-of-flight ranger CS42448 codec 6 in, 8 out, 48 kHz, one clock DAC ADC Host Teensy 4.1 or Raspberry Pi TDM Processing computer 1 demodulation of 12 tones 2 SFCW sweep to range profile 3 pose estimation (EKF) 4 time alignment by PPS 5 dipole inversion, β(ω) 6 classification and fusion 7 map, dataset, reports Python; data stored with metadata and checksums on the team server USB USB, IQ samples UART / USB, 10 Hz fixes, 200 Hz IMU, 60 fps PPS Common time base: GNSS PPS is recorded on codec input 5 and blinks an LED in the camera view
Figure 4.1.System overview. Three sensing subsystems feed one processing computer. The GNSS pulse-per-second signal is recorded on a codec input and shown to the camera, which places induction samples, video frames and position fixes on one time line.

4.2Design principles

  1. One clock per subsystem, one time base overall. All induction channels are sampled by one codec with one master clock, so their relative phases are exact. The radar derives its time from the host computer, and the GNSS pulse ties both to GPS time.
  2. Calculate before building. Every component value is derived from a model, and each work package starts by checking one prediction against a measurement (Chapter 9).
  3. Physics before learning. Known relations such as the \(1/r^6\) distance law and tensor rotation are handled by an explicit model. Machine learning is applied only to the orientation-independent quantities that remain (Chapter 8).
  4. Open and reproducible. Designs, code, data and this report are published under open licences at the end of the project.

4.3Subsystems

Table 4.1.Subsystems, main hardware and procurement status.

SubsystemFunctionMain hardwareStatus
InductionMulti-frequency, full-tensor measurement of the target responseCS42448 codec board, 3 TX and 3 RX coils, class-D drivers, ×33 preamplifiersCodec owned; rest to build
RadarDepth and shape by stepped-frequency GPR, 0.5 to 3 GHzADALM-Pluto (AD9363), RF amplifiers, two Vivaldi antennasPluto and amplifiers owned; antennas to build
PositioningSensor pose at every sample, centimetre level2 × RTK GNSS receivers, IMU, magnetometer, global-shutter camera, time-of-flight rangerTo buy
HostStreams codec data to the PCTeensy 4.1 (baseline) or Raspberry PiTo decide in T1.2
ProcessingDemodulation, pose estimation, inversion, classification, fusionLaptop PC, PythonAvailable

4.4Interfaces and data rates

Table 4.2.Data interfaces.

LinkInterfaceRateNotes
Codec to hostTDM serial audio48 kHz × 6 chMaster clock shared by all channels
Host to PCUSB9.2 Mbit/s6 channels × 32 bit × 48 kHz
Radar to PCUSB 2.0 (IIO)up to about 4 MS/s IQOne capture per frequency step
GNSS to PCUART / USB (UBX)10 Hz fixesPPS wired to codec input 5
IMU to PCI²C or SPI through host200 HzAccelerometer, gyroscope, magnetometer
Camera to PCUSB60 frames/sPPS-driven LED in field of view

4.5Host decision

Two hosts are possible for the codec board. A Teensy 4.1 drives the CS42448 over TDM with existing library support; because its standard USB audio class is limited to two channels, the six input channels are streamed as a raw serial stream at 9.2 Mbit/s, which is well within its USB 2.0 High Speed port. A Raspberry Pi supports the CS42448 in its mainline audio drivers and presents it as an ordinary multichannel sound card, which simplifies the software. The choice will be made in task T1.2, after both have been tested with the actual board. The rest of the design does not depend on it.