Technical Questions

3 views
Skip to first unread message

Theo Brundin

unread,
Jul 31, 2026, 3:39:42 PM (3 days ago) Jul 31
to doubango-ai
Hi all,

We hold the ANPR license (eLinux / AArch64) and are evaluating ultimateALPR v3.13.2 for a Raspberry Pi 5 deployment. Here are our questions

1) LICENSE SCOPE vs BINARY FAMILY
Our master is scoped ANPR / eLinux / AArch64. Our target is a Raspberry Pi 5 on 64-bit Raspberry Pi OS (Debian aarch64), and we intend to ship binaries/linux/aarch64 — not binaries/raspbian/, which is armv7l-only (32-bit, wrong for Pi 5).

Will a runtime key generated from binaries/linux/aarch64 on Debian aarch64 activate against an eLinux/AArch64 master? Since activation is irreversible and machine-bound, we'd like to confirm this before generating a key on the production device.

2) MULTI-LINE / STACKED-CHARACTER PLATES
For US plates with stacked characters or multiple lines, what character order does the SDK emit in the `text` field, and is any separator inserted? We hash the normalized plate text to identify returning vehicles, so read-order stability matters more to us than raw accuracy.

3) VERSION NUMBERING
c++/ultimateALPR-SDK-API-PUBLIC.h declares VERSION_MAJOR 3 / MINOR 10 / MICRO 5 (3.10.5), but our binary reports 3.13.2 at init. Which is authoritative? Trying to gate CI on the correct value.

4) MACOS BUILD
binaries/osx/ contains only a .gitkeep. Is a macOS/Apple Silicon build planned? Our dev machines are Apple Silicon; we're currently running the aarch64 Linux binaries inside a linux/arm64 container as a workaround, which works but adds friction to the dev loop.

Any pointers appreciated, thanks.

Theo

MAMADOU DIOP

unread,
Jul 31, 2026, 3:49:04 PM (3 days ago) Jul 31
to Theo Brundin, doubango-ai

Hi,

On 7/31/2026 9:35 PM, 'Theo Brundin' via doubango-ai wrote:
Hi all,

We hold the ANPR license (eLinux / AArch64) and are evaluating ultimateALPR v3.13.2 for a Raspberry Pi 5 deployment. Here are our questions

1) LICENSE SCOPE vs BINARY FAMILY
Our master is scoped ANPR / eLinux / AArch64. Our target is a Raspberry Pi 5 on 64-bit Raspberry Pi OS (Debian aarch64), and we intend to ship binaries/linux/aarch64 — not binaries/raspbian/, which is armv7l-only (32-bit, wrong for Pi 5).

Will a runtime key generated from binaries/linux/aarch64 on Debian aarch64 activate against an eLinux/AArch64 master? Since activation is irreversible and machine-bound, we'd like to confirm this before generating a key on the production device.

You have to use https://github.com/DoubangoTelecom/ultimateALPR-SDK/tree/master/binaries/linux/aarch64

"binaries/raspbian/" is for 32-bit RaspBianOS

"binaries/aarch64" is for 64-bit Vanilla Linux (Ubuntu, Debian, CentOS...)


2) MULTI-LINE / STACKED-CHARACTER PLATES
For US plates with stacked characters or multiple lines, what character order does the SDK emit in the `text` field, and is any separator inserted? We hash the normalized plate text to identify returning vehicles, so read-order stability matters more to us than raw accuracy.
No sep, left -> right, top -> bottom

3) VERSION NUMBERING
c++/ultimateALPR-SDK-API-PUBLIC.h declares VERSION_MAJOR 3 / MINOR 10 / MICRO 5 (3.10.5), but our binary reports 3.13.2 at init. Which is authoritative? Trying to gate CI on the correct value.
Binaries

4) MACOS BUILD
binaries/osx/ contains only a .gitkeep. Is a macOS/Apple Silicon build planned? Our dev machines are Apple Silicon; we're currently running the aarch64 Linux binaries inside a linux/arm64 container as a workaround, which works but adds friction to the dev loop.
Unfortunately no plan for macOS

Any pointers appreciated, thanks.

Theo  --
You received this message because you are subscribed to the Google Groups "doubango-ai" group.
To unsubscribe from this group and stop receiving emails from it, send an email to doubango-ai...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/doubango-ai/016bd418-207f-40a1-9782-79a601822fd0n%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages