Thread: iGO Speedcam (DISCUSSION)

When I edit the OSC database, it happens on the OSM map, for example. I try not to remove the azimuth of the radar from the road by more than 17 degrees. The analysis that I did for BBS is based on the work of spudigo.

'Lufop' - Review.

Errors have been fixed for France, 4 errors out of 4796, a very good indicator.
4 Azimuth errors:

6.384894,47.536585,1,0,1,186
3.13245,49.87916,1,0,1,60
2.837172,49.0094721,1,0,1,0
-0.380144,49.264178,1,110,1,201

Problems with exporting speedcam.txt for iGO, (DIRTYPE = 1, DIRECTION = 0) this combination cannot be applied to all lines., if a circular notification is needed, it is applied (DIRTYPE = 0, DIRECTION = 0)

X,Y,TYPE,SPEED,DIRTYPE,DIRECTION
-2.12949,57.06996,1,70,1,0
-4.06547,53.21998,1,70,1,0
-2.48195,56.82178,1,70,1,0
-2.23322,53.83041,1,70,1,0

On the map, it looks like a suspended fish, there will be no alerts for iGO.

Spoiler: +++++

«Lufop»
Corrected, this will work in the iGO program,
by country and number of radars. As well as a comparison of the number of radars with the SCDB database and POIbase.

Code:

Please Login or Register to see the links

I sincerely apologize for the inconvenience regarding yesterday’s data update. Please note that the UK file (in kilometers) was not correctly updated, as it contained an export from March 10th. We kindly ask you to re-download this specific file.
This issue only affected the UK file from the OSC database; all other countries were successfully converted and updated from the April 11th OSC database. Thank you for your patience and understanding.
To ensure there is no further confusion, please note that all files have now been updated as of April 12th, 2026.

And of course, you should not apologize for yesterday's Great Britain in kilometers, in case the file (speedcam.txt ) was posted on another forum. Without specifying the source. The obvious fact is that the file was taken yesterday from the gpspower forum, and not downloaded from the OSC database, since the UK cannot be exported on April 12, 2026 with data from March 10, 2026.

The Speedcam Encoding Debate
European iGO users are accustomed to using codes 1–31 and 69 (197) in speedcam.txt, while Russian users typically use 192–223, 68 (196), and 227 (195). Both communities consider their respective versions to be the most "correct." However, from a technical standpoint, iGO Primo is indifferent to which of these codes are used in the source file.

AI-Assisted Analysis:

How the iGO engine processes camera types from the speedcam.txt file when converting to the binary speedcam.spdb format.
Here is a brief breakdown of which codes are easier to understand and why:
1. Codes 1–31 (Traditional / "Legacy")
Core Idea: These are the standard values that have been established historically.
Complexity: The system uses a "warped" mapping. As noted in the text, a TXT value of 1 becomes binary 0, 5 becomes 1, 2 becomes 2, 4 becomes 3, and so on.
Verdict: These are closer to the community's traditions and habits. They are used to avoid confusing other users, even though the internal conversion logic is unintuitive.
2. Codes 32–63 (Technical / "System")
Core Idea: These are values that iGO interprets using the remainder of division by 32 (Modulo 32 operation).
Advantage: This method uses direct correspondence. If you write 32, the system sees 0. If you write 33, it sees 1. You don't need to memorize a complex remapping table (where 5 is 1 and 4 is 3).
Verdict: These are closest to the architectural understanding of the system. This is a "clean" way to set the binary type index directly, bypassing the old mapping.
Summary: Which one to choose?
If your goal is compatibility and avoiding questions from other community members, use 1–31. This is the generally accepted standard, despite its convoluted internal logic.
If your goal is simplicity of development and direct bit management without "shuffling" types, the 32–63 range is more logical, as it eliminates confusion with number remapping (1 to 0, 5 to 1, etc.).

How it works in iGO:
1. The Mapping Layer (for numbers 1–31)
For "classic" values, the program code uses a hardcoded Look-up Table (LUT). The software detects the number and replaces it:
Input 1 → writes ID 0 to binary
Input 5 → writes ID 1 to binary
Input 2 → writes ID 2 to binary
Input 4 → writes ID 3 to binary
Input 3 → writes ID 4 to binary
This was implemented historically so that camera types in the TXT (where 1 is a fixed camera) would match the internal indices for voice alerts and icons.
2. The Binary Logic Layer (for numbers 32 and above)
When iGO encounters a number greater than 31, it switches to pure mathematics. The engine allocates only 5 bits of memory for the camera type (providing 32 combinations: from 0 to 31).
If you enter a number like 32 or 192, bitwise truncation occurs (which is mathematically identical to a Modulo 32 operation):
32 in binary is 00100000. The last 5 bits are 00000 (ID 0).
33 in binary is 00100001. The last 5 bits are 00001 (ID 1).
64 or 192 divided by 32 leaves a remainder of 0 (ID 0).
What’s the "trick"?
Numbers in the 32–63 range bypass the mapping table. The system simply takes them "as is" (minus 32) and writes them to the ID.
If you write 1, the mapping kicks in → you get ID 0.
If you write 32, the math kicks in (32-32) → you get the same ID 0.
Summary:
1–31: The mapping method (a hardcoded, non-linear table).
32 and above: The remainder method (pure bitwise math).

iGO speedcam.txt Reading Speed:
The difference in processing speed between code 1 and 32 is negligible for the CPU—we are talking about nanoseconds. You will never notice this visually or in terms of UI smoothness.

Applying the 32–63 Range in Legacy iGO Versions:
The issue with older versions (iGO 2006, iGO 8.0, early Amigo), which supported only 5 camera types, is much more critical:
1. Backward Compatibility
Legacy iGO versions (especially from the WinCE era) were unaware of the "Modulo 32" method for extending types.
Code 1: An old program will understand this because it is hardcoded in its mapping table.
Code 32: Most likely, an old version will either ignore this line or trigger an error while parsing the TXT file because its valid range is strictly limited (e.g., from 1 to 5 or 15). The software simply doesn't "expect" such a high value.
2. Mapping (Transposition)
In modern iGO versions: TXT 1 → ID 0 (Fixed Camera) and TXT 32 → ID 0 (Fixed Camera).
In legacy versions: TXT 1 → understood as ID 0, while TXT 32 → might be treated as an "unknown type," causing the camera not to appear on the map at all.
3. Performance (Legacy Devices)
For old navigators (with 300–400 MHz CPUs), the crucial factor is the file size, not the math (1 vs 32).
The conversion from TXT to the binary speedcam.spdb format happens only once at startup (if the file has been updated). After that, iGO reads the pre-compiled binary where both 1 and 32 have already been converted into the same ID 0.
Conclusion: During actual navigation, there is absolutely no difference in speed.
Summary for Legacy Systems:
Using codes 32–63 is a risk.
The Safe Route: Use 1–5, as these are understood by every version of iGO released in the last 15 years.
The Risky Route: Codes 32+ may render the file unreadable for legacy software.
The author of the text you cited is right about one thing: using "inflated numbers" (32+) is a hack that is convenient for modern skin developers but can "break" compatibility with old or stock software.