Thread: iGO Speedcam (DISCUSSION)

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.

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.

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. ]

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.

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,

One important thing to keep in mind regarding your test where the 50 km/h point seemingly "closed" the section: this might actually be a false positive caused by a standard iGO engine timeout rather than the speedcam data itself.

In legacy WinCE Primo, if you slow down significantly or come to a complete stop (e.g., at a traffic light or intersection upon entering the town area), the engine's internal smart timeout triggers. When the vehicle remains stationary or drops below a certain speed threshold for too long, iGO assumes you have left the monitored highway or parked, and it automatically drops/kills the active average speed session.

It is highly likely that your section closed simply because of this speed drop or a brief stop, creating a coincidence that made it look like the 50 km/h point worked as a closer. True system closing should only be handled via proper technical scripting (like SPEED=0), as relying on accidental speed-drop timeouts will eventually lead to unexpected speeding tickets on a real road.


Since you have already removed the "use_road_speedlimit=1" parameter, here is a practical configuration to test for your unskinned WinCE Primo device.

The standard engine requires paired points (Start and Finish) for Type 4 and cannot dynamically update the target speed within a single zone. The only option to track these segments is to physically split the route into sequential sections in your speedcam.txt using the following layout:

X,Y,TYPE,SPEED,DIRTYPE,DIRECTION
; --- SECTION 1 (100 km/h) ---
X1,Y1, 4, 100, 1, Angle // Entry camera: Starts Section 1
X2,Y2, 4, 0, 1, Angle // Virtual point: Closes Section 1

; --- 30-METER GAP (Crucial 2-3 seconds delay for WinCE hardware to process commands) ---

; --- SECTION 2 (50 km/h) ---
X3,Y3, 4, 50, 1, Angle // Virtual point: Starts Section 2
X4,Y4, 4, 0, 1, Angle // Virtual point: Closes Section 2

; --- 30-METER GAP ---

; --- SECTION 3 (100 km/h) ---
X5,Y5, 4, 100, 1, Angle // Virtual point: Starts Section 3
X6,Y6, 4, 0, 1, Angle // Exit camera: Closes Section 3

Two critical adjustments for this test:
1. SPEED=0 is used as the zone closer instead of SPEED=5. Since you disabled map speed limits, "0" acts as a system marker to clear the active section without triggering low-speed visual or audio warnings.
2. A physical gap of at least 30 meters between sections is mandatory. WinCE processors need this distance (approx. 2–3 seconds of driving) to finish parsing the close command before they can initialize the next start point.

Test this specific structure on your route to see if your unskinned build handles the transitions.

Additionally, look at this from a pure mathematical and traffic enforcement perspective: it is highly probable that a unified "100 -> 50 -> 100" average speed section does not even exist on that road, or it is purely formal.

If you slow down to 50 km/h or stop at traffic lights inside the town, your total travel time (T) increases drastically. This massive time buffer drops your actual calculated average speed for the entire route way below any violation threshold. If the police monitored this as one single continuous zone, any driver could legally blast through the 100 km/h zones at 150 km/h, because the time wasted at city intersections would completely dilute the violation.

Real-world traffic authorities know this math. That is why they never set up a single point-to-point zone across mixed urban/rural environments with рваный (disrupted) speed limits. In reality, the police either run two completely independent sectional radars (one ending before the town, and a separate one starting inside/after it), or they only monitor one stable segment and ignore the rest.

By expecting iGO to calculate a shifting target speed across a town setup where you naturally slow down, you are trying to benchmark a code behavior against a scenario that makes no sense on a real road. Try the SPEED=0 layout on a proper, uninterrupted highway segment to see how the engine actually behaves when it isn't being tripped up by speed-drop timeouts and stoplights.