Cubino + Eu152: building a complete, low-cost Gamma spectroscopy ecosystem

There are many ways to build a radiation detector. There are far fewer ways to build a useful spectroscopy system that is affordable, understandable, reproducible, and pleasant to use in the real world. That is the space where the Cubino project and the Eu152 software were born.

At first glance, Cubino may look like a hardware story: scintillation crystals, SiPMs, analog front ends, compact enclosures, USB interfaces, and detector geometry. And yes, all of that matters. But if I had to describe the real center of gravity of this project, I would put it elsewhere: in software.

Cubino only becomes fully meaningful when paired with Eu152. The detector is the physical front end, but Eu152 is what turns raw pulses into a complete operating environment: spectrum acquisition, pulse processing, calibration workflows, identification support, Geiger-style counting, telemetry, visualization, and mapping. In other words, Cubino is the instrument, but Eu152 is the software layer that makes the instrument usable, teachable, and extensible.

From a system-design perspective, this division is intentional. Cubino keeps the analog electronics relatively simple and stable, while Eu152 carries a large part of the signal-processing and workflow logic in software.

Why this project exists

A recurring problem in gamma spectroscopy is that many systems fall into one of two extremes. On one side, there are professional instruments with excellent performance, but with costs, complexity, and form factors that are hard to justify in educational or experimental contexts. On the other side, there are consumer-friendly devices that are easy to approach but often too constrained, too closed, or too optimized for passive dose-rate style use rather than real spectroscopy.

The Cubino + Eu152 project emerged from a different ambition: to create a platform that remains technically serious while still being accessible. Not a toy, not a locked appliance, and not a laboratory-only object. Instead, the goal has been to build a modular platform for real gamma spectroscopy that students, hobbyists, educators, and technically curious users can actually understand and use.

That goal influenced every layer of the system. Hardware had to be manufacturable in small series, reproducible, and realistic in cost. Mechanical design had to be practical. The signal chain had to be good enough for spectroscopy, not just counting. And the software had to do much more than display a chart: it had to become the bridge between detector physics and a real user workflow.

What makes this possible is not the absence of complexity, but its redistribution. Instead of relying entirely on specialized analog electronics, part of the intelligence is moved into software. This is one of the fundamental ideas behind the project.

From detector to platform

The Cubino family did not appear fully formed. It is the result of iteration. Earlier prototypes explored different crystal sizes, enclosure strategies, SiPM coupling approaches, and signal chain ideas. One of the important lessons of that phase was that hardware alone does not determine whether a detector is successful. You can have a promising sensor head and still end up with a frustrating instrument if the acquisition chain is opaque, calibration is awkward, or the software experience is weak.

That realization gradually pushed the project toward a more integrated view. Instead of seeing hardware and software as separate pieces, I started treating them as co-designed layers of the same instrument. The detector, the analog front end, the digital acquisition path, and the user interface all had to support each other.

This is one reason why Eu152 eventually became so central. Rather than treating software as a minimal companion application, the project evolved toward a system in which the software is responsible for a large part of the detector’s practical value.

At a high level, the architecture can be summarized as follows:

• Detector and analog front end: scintillator, SiPM, bias generator, pulse shaping
• Digitization: USB audio codec used as a general-purpose ADC
• Software processing: pulse detection, measurement, histogram, calibration, and analysis

The analog chain is intentionally minimal and designed to produce shaped pulses compatible with audio-rate sampling. All higher-level processing is then performed in software.

 

Cubino Lite and the hardware philosophy

One of the most important branches of the project is Cubino Lite: a compact spectroscopy device based on a 10×10×30 mm CsI(Tl) scintillator coupled to a single 6×6 mm SiPM. It was conceived as a serious attempt to reduce cost and complexity while preserving the features that make a detector genuinely useful for spectroscopy.

This point is important. Reducing cost is easy if one is willing to reduce the instrument to a novelty. The harder challenge is reducing cost while still preserving enough crystal volume, enough optical efficiency, enough stability, and enough signal quality to make the result educationally and experimentally meaningful.

Cubino Lite sits precisely in that compromise space. It is not trying to mimic high-end laboratory electronics in every respect, nor is it trying to win a specification contest on paper. Instead, it aims to provide a balanced instrument: compact, practical, reproducible, and capable of producing spectra that matter.

From an electronic perspective, the design remains intentionally simple. The SiPM is biased using a compact high-voltage generator followed by passive filtering in order to keep the supply noise low. The detector signal is then shaped using a basic RC network and directly digitized by a USB audio codec.

That last choice is one of the defining aspects of the project. Instead of using a dedicated MCA board or a fast ADC under microcontroller control, the detector presents itself to the host system as a standard USB audio device. This drastically simplifies compatibility and cost, but it also means that the quality of the final instrument depends strongly on the software side.

The software is not an accessory

In many detector projects, software arrives late and remains secondary. It serves mainly to prove that the hardware works. Eu152 was developed in the opposite direction. It grew into a substantial part of the instrument itself.

The central idea is simple: a detector that appears to the host as a generic audio device can benefit from a surprising amount of digital signal processing. Once the analog pulse stream is captured with sufficient fidelity, software can take over a large part of the filtering, thresholding, pulse detection, integration, smoothing, and display logic. This is not merely convenient. It changes the economics and flexibility of the entire system.

Using software in this way makes it possible to iterate quickly, compare algorithms, expose controls to the user, and adapt the same hardware platform to different workflows. A compact USB detector then becomes something much more capable than a simple pulse source. It becomes a reconfigurable measurement instrument.

That is the real role of Eu152. It is not “the app for Cubino.” It is the operational layer that transforms Cubino from hardware into a complete, evolving spectroscopy platform.

There is also a deeper technical reason behind this approach. A modern smartphone or tablet can provide more than enough processing power for baseline estimation, filtering, pulse detection, pulse-area or pulse-height extraction, histogram accumulation, and user interaction. In other words, the host device is not only a display, but also a signal-processing engine.

Why Android

A key design decision was to take Android seriously as a spectroscopy environment. That may sound unusual at first. But modern Android devices provide high-quality processing power, good displays, touch interfaces, storage, portability, and in many cases the ability to interact with USB audio devices in a robust way.

This makes Android a very attractive target for field instruments and educational devices. Instead of requiring a full desktop setup, the detector can be paired with something the user already owns. A phone or tablet becomes not just a display but a DSP engine, a visualization platform, a data logger, and a portable operating console.

This choice shaped Eu152 from the start. The application is not only about “showing the spectrum.” It is responsible for acquisition, signal conditioning, user interaction, calibration, analysis support, and data persistence inside a constrained and highly portable environment.

Another practical advantage is that Android makes it easy to merge multiple operating modes into a single handheld workflow: spectrum acquisition, count-rate monitoring, mapping, telemetry display, and data export can all coexist within one device.

Inside Eu152

From the outside, Eu152 may look like a standard spectroscopy interface similar to many others. In reality, much of its value lies in the details of the acquisition and processing pipeline.

The app has been developed around a practical pulse-processing architecture for audio-based acquisition. It deals with sample capture, device selection, sample-rate choices, polarity handling, software gain, threshold logic, smoothing, and filtering. The signal path has gone through repeated refactoring to eliminate duplicated logic and keep behavior consistent across preview, acquisition, and analysis paths.

This matters more than it may seem. In spectroscopy software, inconsistency is corrosive. If the preview path uses one filter configuration, the acquisition path uses another, and the analysis tools assume a third interpretation of the pulses, the user is left with a system that cannot be trusted. A lot of Eu152’s development work has therefore focused on making the signal chain coherent and reusable.

Over time shared DSP components were consolidated into reusable filter structures. The same conceptual pipeline could then be used in multiple parts of the application. This is a software engineering choice, but it is also an instrumentation choice: it reduces hidden divergences and makes the instrument more reliable.

The acquisition model itself has also been treated as a real design problem rather than a quick coding exercise. There has been work on baseline estimation, pre-roll buffering, hysteresis, pulse termination logic, dead time behavior, peak versus area-based extraction, and other small but essential details that ultimately determine whether the software behaves like a measurement tool or just a waveform viewer.

From a signal-processing point of view, the system operates on discrete-time samples acquired typically at 44.1 kHz or higher. That has direct implications: the analog shaping time must be matched to the sampling rate so that each pulse is represented by a sufficient number of samples. With 44.1 kHz sampling, one sample is acquired every 22.7 µs. With 96 kHz or 192 kHz, this spacing becomes much smaller, allowing shorter shaping times or more accurate reconstruction of the same pulse.

This relationship between pulse shaping and sampling rate is one of the key practical constraints of audio-based spectroscopy. It is also one of the reasons why software flexibility matters so much: it allows the measurement strategy to evolve with the signal conditions.

It is also worth noting that successful operation with USB audio hardware requires bypassing as much “consumer audio intelligence” as possible. Features such as automatic gain control, noise suppression, and echo cancellation are useful for voice signals, but destructive for pulse measurements. A usable spectroscopy pipeline must therefore operate on raw or minimally processed audio data.

More than a spectrum viewer

If Eu152 only plotted counts versus channel, it would still be useful. But that would not justify the effort behind it. The application has gradually developed into a multi-view environment in which different operational modes support different ways of interacting with radiation data.

There is the spectrum itself, of course: the core representation for spectroscopy work. But there is also a Geiger-oriented layer, useful when the user wants immediate count-rate feedback rather than spectral interpretation. There are mapping capabilities, allowing measurements to be associated with GPS position and visualized geographically. There are telemetry paths, making it possible to integrate external runtime data sources. There are calibration and ROI tools that move the workflow from mere display toward actual interpretation.

This is precisely why I think of Eu152 as an ecosystem. It does not force the user into a single style of interaction. The same detector can be used in a bench setup, in a classroom, in exploratory field use, or in a quick “is something here?” mode. The software layers make those transitions possible.

 

ROI, calibration, and the move toward real interpretation

One of the most meaningful software directions in Eu152 has been the shift from simple observation toward structured interpretation. That is where ROI handling and calibration become crucial.

A spectroscopy system becomes much more valuable when the user can define regions of interest, attach energy references, perform calibration, and then use that calibration as the basis for further identification work. These steps are mundane in professional systems, but in small, low-cost platforms they are often poorly handled or skipped entirely.

In Eu152, calibration has increasingly been treated as an explicit workflow rather than a hidden assumption. The user can define ROIs, associate known energies, compute a linear energy calibration, store that result, and then use it as the basis for subsequent operations such as isotope identification support. That design choice is important because it makes the relationship between the spectrum and the calibration visible and editable.

This is also philosophically consistent with the project. A user should not be asked to trust invisible magic. Calibration should be something they can understand, reproduce, correct, save, and reload.

Once again, this is where the software carries much of the instrument’s educational value. Good software does not only automate. It also teaches the user what the instrument is doing.

Geiger mode, telemetry, and operational flexibility

Another important aspect of Eu152 is that it does not treat spectroscopy and counting as unrelated worlds. The software supports a Geiger-style mode with count-rate presentation and audio feedback, but it also allows this part of the system to evolve beyond purely local audio pulse detection.

Bluetooth telemetry support has been one of the extensions that pushed the architecture further. Instead of assuming that all count information originates locally from the audio acquisition path, the software can also ingest structured external telemetry and feed that into the same high-level application model. This opens the door to hybrid instruments, remote sensor heads, or alternative acquisition architectures that still benefit from the Eu152 interface layer.

From a software engineering perspective, this is significant. It means the app has been evolving from a single-input application toward a source-aware instrument shell. The same views can operate with different count sources, and the user experience remains coherent. This is exactly the kind of capability that makes a platform long-lived.

It also reflects a wider principle in the project: flexibility should be designed into the software architecture, not added later as a patch.

Mapping and the idea of context-rich measurement

Radiation measurements become more informative when they are connected to place. For that reason, Eu152 also developed mapping capabilities based on GPS logging and visual overlays. A count rate is useful; a count rate attached to a location history is more useful. Once measurements can be seen as a trail or as points on a map, the instrument begins to support exploratory workflows that are very different from bench spectroscopy.

This part of the software is especially interesting because it shows how the project has moved beyond the traditional “MCA on a screen” model. A modern device can log, geo-reference, annotate, and later reload a dataset as part of a broader observation process. That does not replace classic spectroscopy tasks, but it broadens the scope of what a compact detector platform can do.

In practical terms, it also makes the project more engaging. Students and users can see that radiation data is not only a static histogram. It can also be part of a time-and-space record of exploration.

Software architecture as a scientific instrument problem

One thing I have learned repeatedly during this project is that writing software for a detector is not the same as writing generic application code. Many software design decisions are, in practice, instrument design decisions.

A filter bug is not just a bug. It may change pulse shape interpretation. A duplicated code path is not just technical debt. It may create inconsistent measurement behavior across views. A weak state model is not just inelegant. It may make start/stop logic unreliable in the field. An unclear calibration workflow is not just a UX problem. It may teach the user the wrong mental model of spectroscopy.

Because of that, Eu152 has gone through a substantial amount of refactoring aimed at separating responsibilities, reusing DSP components, clarifying data flow, and reducing hidden coupling between user interface and measurement logic. These changes are not glamorous, but they are what allow the application to grow without becoming self-contradictory.

This is one reason I want to place strong emphasis on the software when describing the Cubino ecosystem. The hardware may be the visible object, but the software is where much of the scientific discipline of the project actually lives.

Educational value through transparency

Another core motivation behind the project is educational value. I am deeply interested in instruments that do not merely provide a result, but help users understand why that result exists.

Cubino + Eu152 is therefore not designed around opacity. On the contrary, the more the project evolved, the more important it became to make the workflow legible. Signal enters the system. Pulses are processed. Spectra are accumulated. Regions are selected. Calibration is built. Identification becomes possible. Data can be saved, exported, reloaded, and compared. This chain should not be hidden behind a single button labeled “analyze.”

For students, that transparency matters enormously. It makes the instrument a teaching device in the best sense: not because it is simplified, but because it reveals the structure of the measurement process. For hobbyists and technically curious users, it means the system remains open to experimentation. For the project itself, it means that software improvements can continue to add value without requiring a total redesign of the hardware.

Why low cost does not mean low ambition

Low-cost scientific instrumentation is often misunderstood. People hear “low cost” and assume “simplified,” “disposable,” or “inferior.” But low cost can also mean something much more interesting: careful allocation of complexity.

In the Cubino ecosystem, complexity is not eliminated. It is redistributed. Instead of pushing everything into expensive dedicated electronics, part of the intelligence is moved into software. Instead of relying on proprietary acquisition environments, general-purpose computing platforms are used intelligently. Instead of sealing the instrument into a fixed appliance, the system is allowed to evolve through software architecture and iterative development.

This is not a compromise in the weak sense. It is a design stance. The project tries to ask: where does complexity create the most value? Which parts must be analog, which parts can be digital, which parts should be visible to the user, and which parts should remain internal but robust?

When those questions are taken seriously, low cost becomes less about cheapness and more about efficiency of design.

Open-ended development, not a frozen product

Another feature of this ecosystem is that it remains in motion. Eu152 is not a static companion app completed once and then forgotten. It has evolved through repeated technical changes: DSP cleanup, filter refactoring, acquisition logic improvements, ROI workflow revisions, telemetry integration, mapping behavior, calibration persistence, and user-interface restructuring.

This ongoing development is not a sign that the system is unfinished in a negative sense. Rather, it reflects the fact that the project is alive. Real instruments improve when they are used, questioned, stressed, and redesigned in response to actual experience. That is especially true when the same person is simultaneously thinking about detector behavior, user workflow, educational clarity, and software maintainability.

In that sense, Cubino + Eu152 is less like a sealed product and more like a coherent research-and-development platform that is already useful while continuing to improve.

The bigger idea behind Cubino + Eu152

If I had to summarize the deeper ambition of the project, I would say this: to prove that serious gamma spectroscopy tools do not have to be inaccessible, and that compact instrumentation can still be architecturally honest.

Cubino provides the physical basis: scintillator, photosensor, analog chain, enclosure, portability, practicality. Eu152 provides the operational intelligence: acquisition, processing, visualization, calibration, interpretation support, telemetry, mapping, and workflow cohesion. Neither side is complete without the other.

That is why I prefer to speak of an ecosystem rather than a device. A detector alone is an object. A detector plus a disciplined software environment becomes an instrument. And an instrument plus a transparent, extensible workflow becomes a platform.

This is the stage where the project now stands. Not as a single gadget with one headline specification, but as a growing platform for spectroscopy that tries to remain technically serious, educationally useful, and practically accessible.