An experimental optical check counter inspired by the Cremer Tel‑O‑Scan TSV-1560 — built as a diagnostic instrument to capture real scan-line behaviour from tablets and capsules, and to expose the edge cases that normal counters keep hidden.
ASTRA‑1P started as ICC‑01 (Instant Check Counter‑01). The goal wasn’t to build a perfect production counter — it was to build a machine that could tell the truth about what optical sensors really see.
The concept was based on a bulk counter style: products fall through a counting channel while an LED/phototransistor array scans across the opening. But unlike typical systems that reduce everything to “count / no count”, ASTRA‑1P recorded the interesting scan lines so they could be analysed later.
In practice it counted surprisingly well — often close to 1 miscount per 10,000 products (highly dependent on product type, surface finish, and presentation). For check counting, that still wasn’t good enough… and that was the key lesson.
Outcome: never released as a product — but became a long-term diagnostic tool used repeatedly to validate and refine later sensor designs.
Each captured scan line was written to a text file in a human-readable format — fast to log, easy to inspect, and perfect for building intuition.
That “positive” effect sounds odd until you see it: reflections and lensing can make some receivers see more light when a glossy object passes. Capturing those moments made it clear why certain products miscount — and what signal features are safe to trust.
The point wasn’t perfect counting. The point was visibility.
Completed ASTRA-1P. Final desk-top test system with keypad + LCD UI.
Early concept promo. “Instant Check Counter” era branding, later renamed ASTRA‑1P.
Hand-built enclosure. Wood construction, silver spray-painted for a “metal look”.
Frame and channel assembly. Built from reclaimed drawer parts found at the curb site — fast iteration, low cost, high learning.
Array boards. Discrete logic + wiring harnesses feeding the scan-line capture system.
System integration. Array boards connected to the SBC during bench testing.
A custom-made PC‑104 card provided the DAC/ADC functions needed to drive the scanning array and capture analogue levels with enough resolution to preserve greyscale behaviour.
PC‑104 era hardware. The interface card installed in the stack during testing.
Software was written in Free Pascal under GO32 / MS‑DOS — chosen for speed, control, and direct hardware access.
LCD + keypad. Simple interface — the focus was diagnostics, not prettiness.
Bring-up rig. Testing the UI alongside the SBC stack and storage.
Still in active use. By 2011, ASTRA-1P was no longer an experimental prototype, but a trusted diagnostic platform for analysing the optical response of a wide variety of tablets and capsules under real operating conditions.
Its value was never in being a finished production counter. Instead, it remained in service because it exposed behaviours that conventional counters hide: reflections, partial occlusions, lensing effects, and timing ambiguities that only become visible when raw scan-line data is examined.
That continued diagnostic use directly influenced later architectural decisions — including the realisation that throughput and accuracy could not be traded against each other, but had to be achieved simultaneously.
ASTRA‑1P proved a harsh but valuable truth: optical bulk counting can be excellent in the right conditions, but check counting demands a level of certainty that some products simply won’t allow.
More importantly, the work on ASTRA-1P demonstrated a fundamental limitation: once bulk counting introduces uncertainty, that uncertainty cannot be corrected downstream. This made it clear that exact counting would require a different architectural approach rather than further refinement of bulk sensing alone.
And that’s exactly why it belongs in the Museum: it’s a machine built to reduce assumptions — and replace them with data.
ASTRA-1P wasn’t just a one-off diagnostic counter — it directly shaped the thinking that later became XIAC’s hybrid counting protocol. The original plan was a “count anything” machine with a bulk counting section, followed by a count completion section that would top up the last few products from single-file lanes to hit the exact target quantity.
In practice, the bulk section wasn’t accurate enough for tablets/capsules: if the true count might be 95 or 96, you don’t know whether to add 5 or 4 — and you can’t ship that uncertainty. On top of that, the bulk lane required the product feed to pause so the memory flap could close at a known moment, wasting a significant slice of each second. Hybrid counting solved both problems: it keeps products in controlled single-file lanes (but scales the number of lanes with product size), and it creates a deterministic “allowed-to-close” moment without stopping the feed.
This is why the bulk-lane concept would only have made sense for very large counts per bottle, whereas the hybrid protocol remains efficient across all count sizes. Read more on the Hybrid Counting Protocol in the Technology section.
Original sketch of the early “bulk + count completion” concept: a flat bulk feed area in the middle, with V-lanes at the sides for controlled single-file completion lanes.