iGO Speedcam (DISCUSSION)

**Andrey Form** · 19th October 2026, 10:13 AM

Back in 2022, I discovered a critical syntax error in the files published by Cserrobi (aka Sunnyside Navi) that corrupts the original structure of speedcam.txt. In 2023, I was banned from one of the forums simply for asking questions about this error. It wasn't until 2024 that I finally tracked down the root cause and found who was responsible for spreading this technical defect. Now, with BBS Radars / LaradioBBS completely shut down, I can finally reveal the whole story. A story that actually traces all the way back to around 2004.

This semicolon at the end of the DIRECTION; header is a classic example of a "domino effect" in the world of legacy software and amateur coding. It has absolutely nothing to do with the official specifications from NNG (the developer of iGO).
The history of its appearance and spread comes down to technical illiteracy, blind copying of third-party scripts, and long-standing makeshift fixes within the Spanish community.

1. The Root Cause: The Spanish Connection (BBS Radars / LaradioBBS)

The original source of this infection is the Spanish forum La Radio BBS (also known as BBS Radars).
Many years ago, at the dawn of iGO Primo and Amigo, one of the self-taught Spanish moderators wrote a home-brewed script (most likely using PHP or Excel macros) to automatically convert official Spanish DGT road safety databases into the speedcam.txt text format for iGO.
While generating the header row in the script's code, a basic syntax error was made:
• Instead of the correct output: ...DIRTYPE,DIRECTION
• The script outputted a string where the name of the last column was accidentally merged with a statement termination character or a delimiter used inside the code itself: ...DIRTYPE,DIRECTION;
Since the LaradioBBS databases were incredibly popular in Spain, tens of thousands of people downloaded this corrupted file. The engines of older iGO 8 versions and early Primo builds were quite forgiving—they often discarded or ignored trailing garbage at the end of a line, meaning the databases still managed to work on legacy navigation systems. Nobody noticed the mistake, and the script kept generating this broken syntax for years.

2. How Robert (Cserrobi) Inherited the Defect

Robert (Cserrobi / Sunnyside Navi) is a textbook example of a "copy-paste master." He is not a programmer and does not write his own parsers from scratch.
When Robert decided to compile "his own" databases for m/lolo and Facebook groups, he didn't bother diving into NNG syntax rules. He simply took the old, pre-made Spanish script from BBS Radars as a template (or copied their parsing structure).
Furthermore, Robert managed to take this mistake to an absolute extreme. Take a look at the structure of his "masterpiece":
DIRECTION; Készítette: Cserrobi, Vitafórum:...
Instead of removing the Spanish semicolon, he assumed that ; was a perfect delimiter to jam his own advertising text directly into the technical header string!
In the iGO syntax, the ; character does indeed signify the start of a comment, but only if it occupies a separate line or is preceded by a proper separator (a comma). By pasting the text Készítette... directly against DIRECTION;, he turned a system variable name into unreadable gibberish.

3. Why Others Don't Have This, and Why It Blew Up Now

In healthy, technically advanced communities (such as the post-Soviet space, engineers always strictly audited the syntax. There, the header was always pristine: IDX,X,Y,TYPE,SPEED,DIRTYPE,DIRECTION (sometimes with a trailing comma for specific Primo builds).
Why this became a total disaster on modern Android 13/14 and NextGen systems:
1. Strict Parsers: Modern iGO NextGen and iGO Luna engines run on updated, far more rigid software compilers. When a modern navigation app encounters the header DIRECTION; Készítette:..., it chokes right on the word DIRECTION.
2. Broken Azimuths: The application fails to properly initialize the data array required for camera direction angles. For the parser, the DIRECTION column effectively becomes "non-existent" or corrupted.
3. The Result: The navigation app falls back to resetting all direction parameters to 0 (omnidirectional/circular alert). A camera that is supposed to monitor only oncoming traffic starts harassing the driver from all directions, including parallel overpasses and adjacent side streets.

Summary

The semicolon is a "genetic defect" originating from an old LaradioBBS Spanish script, which Robert blindly copied and transformed into a personal advertising banner. What was forgiven by the old iGO 8 WinCE engine 15 years ago acts as a destructive bug on modern NextGen software, turning a speed camera database into broken junk that triggers constant false alerts.
And the fact that you have only ever seen this issue coming from BBS and Robert proves it yet again: Robert simply steals their methods and file structures without having any baseline understanding of how they actually function.

**k1w1_123** · 29th October 2026, 01:47 AM

Hello

the police in my area have installed an average speed camera over a route which passes through a town, so that there are different speed limits in different parts of the route; 50 km/h in the town, and 100 km/hr on the roads either side. I have set this up in my WinCE Primo device as three separate sections, with "imaginary" cameras at each speed limit change, which works but is rather cumbersome.

Is there a better way which will keep track of the speed limiits but only need the actual cameras at each end?

Thanks

**Andrey Form** · 29th October 2026, 05:32 AM

You can map the entire route using exclusively Type 4 (Section Start) points, and use a specific speed value as a script trigger at the very end to close the zone.

The speedcam.txt Layout:

text
X,Y,TYPE,SPEED,DIRTYPE,DIRECTION
X, Y, 4, 100, 1, Angle // Point 1: Actual entrance camera. Starts average speed calc at 100 km/h.
X, Y, 4, 50, 1, Angle // Point 2: Town entry. Updates the current target speed to 50 km/h on the fly.
X, Y, 4, 100, 1, Angle // Point 3: Town exit. Updates the target speed back to 100 km/h on the fly.
X, Y, 4, 5, 1, Angle // Point 4: Actual exit camera. Speed "5" acts as a script marker to CLOSE the entire zone.

How it works:

1. Seamless Transitions: When you pass Points 1-2 and 3, iGO updates its internal mathematical calculator with the new speed limit on the fly, matching how the police point-to-point system computes your total travel window.

2. Manual Override: If the GPS slightly misaligns at the end, having SPEED = 5 mapped allows you to simply tap the speedcam icon on your screen to force-close the section manually.

**lunapark** · 29th October 2026, 10:41 AM

When a section radar torque is installed the distance separating the two control points is D, if the imposed speed is V then the travel time becomes T= D / V

Originally Posted by k1w1_123

Hello
Is there a better way which will keep track of the speed limiits but only need the actual cameras at each end?
Thanks

it is this time T that is important when one controls a section having different speeds and when one knows the distance to be traveled

In your case there are different speeds on this course which is therefore divided into three sections D1(100) + D2(50) + D3(100), all at these speeds will require the time T1 + T2 + T3

what needs to be calculated is the average speed on the integral path Vt=(D1 + D2 + D3) / (T1 + T2 + T3),

- either use a stopwatch and reset the odometer, and then you travel that distance by car at limit speeds which will give you Vt = D / T

- or you measure what distances give for each of the zones using a fictional route on Google Maps, and then know that T1 = D1 / 100 ; T2 = D2 / 50 ; T3 = D3 / 100

Calculate the average speed by the formula Vt = (D1 + D2 + D3) / ( D1/100 + D2/50 + D3/100)

Theoretically if you simulate this route you should have to get both the total distance and the travel time (arrival time - departure time),if necessary, mark the intermediate point path so that it corresponds well to the control area

Round the speed Vt a few km/h below the calculated value and you will be equipped using only 1 radar at each start per direction of traffic, and ending with a end radar set to 5 in accordance with the skin: four in all.

the disadvantage of imposing Vt on the whole course is to have an overspeed alert out of agglomeration, this will depend on whether or not to use the parameter
[speedcam_category:3]
use_road_speedlimit=1

but since the signaled speed will be less than the authorized speed, if you slow down the travel time will lengthen as much as necessary but you will be protected from a ticket, and if the city is punctuated by some red lights you will lose even more time at the disadvantage of speed control

However, please use the overspeed alert for each area otherwise it's over, no more driver's license.

**Andrey Form** · 29th October 2026, 11:38 AM

Originally Posted by lunapark

this will depend on whether or not to use the parameter
[speedcam_category:3]
use_road_speedlimit=1

False theoretical statements!!!
The use_road_speedlimit=1 entry in sys.txt is not an autopilot. You can read about how this entry actually works in the [Only registered and activated users can see links. ]

**k1w1_123** · 31st October 2026, 02:26 AM

Originally Posted by Andrey Form

text
X,Y,TYPE,SPEED,DIRTYPE,DIRECTION
X, Y, 4, 100, 1, Angle // Point 1: Actual entrance camera. Starts average speed calc at 100 km/h.
X, Y, 4, 50, 1, Angle // Point 2: Town entry. Updates the current target speed to 50 km/h on the fly.
X, Y, 4, 100, 1, Angle // Point 3: Town exit. Updates the target speed back to 100 km/h on the fly.
X, Y, 4, 5, 1, Angle // Point 4: Actual exit camera. Speed "5" acts as a script marker to CLOSE the entire zone.

Thank Andrey, sadly this does not work on my device (unskinned, unbranded, Chinese, "waterproof" model running WinCE "Civic Reborn" software). Primo "sees" the two 100km/h sections and tracks average speed in these areas perfectly, but ignores the 50 km/h section. I have tried with different speed limits but still Primo sees only the first and last section
A pity because it is an elegant solution. Perhaps it requires Nextgen or a skin to work?

@lunapark thanks for your idea, I will try it on a the road and see how it goes.

I think I should not use the parameter use_road_speedlimit=1 becaue it is my understanding that this tells Primo to use the speed limits built into the maps, rather than the ones created for my speedcam.txt file.

**Andrey Form** · 31st October 2026, 05:02 AM

It is highly likely that the 50 km/h point is being ignored simply because it falls outside iGO's visibility corridor. Check the point's exact coordinates on the map and try setting its alert direction to omnidirectional (circular).

**k1w1_123** · Today, 01:19 AM

@AndreyForm
It has taken me a few days to test all this out thoroughly over several routes, with multiple combinations of posted speed limit vs speedcam.txt, and using omnidirectional alert points I eventually discovered that my device had the parameter "use_road_speedlimit=1" in the sysyem.ini file which was causing the map speed limit to override my experimental ones. Deleting that parameter fixed the problems with displaying unexpected speed limits but sadly my original problem still exists, which is that Igo sees the second point as a section end rather than a speed limit change.
Do you have any other suggestions?

Thread: iGO Speedcam (DISCUSSION)

Thread Tools

Display

Advertissements

How to make speedcam.txt for average speed camera with different speed zones

Tags for this Thread

Bookmarks

Bookmarks

Posting Permissions