I pulled over to take a closer look, and found a car belong to SGS S.A. – a Swiss multinational company which provides inspection, verification, testing and certification services.

There was a piece of tripod mounted equipment labelled TIRTL on one side of the intersection.

And a second unit on the other side.

Also connected to an equipment box.

So what was it all for? The green thing labelled ‘TIRTL’ is actually a ‘The Infra-Red Traffic Logger‘ unit:

The transmitter sends two cones of infrared light across the roadway, and the receiver records vehicles as they break and remake these cones. TIRTL transmitter’s infrared cones cross each other and form two straight and two diagonal beam pathways.

When a vehicle crosses the beam pathways, TIRTL records two beam events; it records one from the vehicle breaking and one leaving the beam pathway. These two beams events are recorded for all four beam pathways. Thus, eight timestamped events are generated per axle. The velocity is derived from the timestamps of these beam events.

This velocity data is then compared with the velocity data calculated by the speed camera system itself, as part of the testing and maintenance procedures required under the Road Safety (General) Regulations 2019.

Quarterly:

– Speed accuracy and speed reliability testing
– Camera system asset inventory
– Camera system sensor evaluation

Which leads to the issuing of an annual test certificate for each camera.

Footnote: and another one

I’ve also found the speed and red light camera at the corner of Flinders Street and William Street undergoing testing.

Back in 20114 it was the speed camera which issued the most fines in Victoria, with 20,774 in one quarter. While in 2017 it claimed the dubious honour of Victoria worse location for motorists running red lights, with almost 2000 fines issued in one quarter.

Post retrieved by 35.215.163.46 using

The post How to calibrate a speed and red light camera appeared first on Waking up in Geelong.

The easiest way to backup a self-hosted WordPress blog is by using the “WP-DBManager” plugin – install it via the control panel, tick a few boxes, and a backup of your entire database gets sent to you via email every night, giving you a way to get your website content back if something goes wrong.

For me WP-DBManager did everything it promised, at least until my hosting provider changed their security settings and disabled a number of functions that the backup plugin needed to work, leaving me with a failing backup job and this error message:

Checking PHP Functions (passthru(), system() and exec()) …
passthru() disabled.
system() disabled.
exec() disabled.

I’m sorry, your server administrator has disabled passthru(), system() and exec(), thus you cannot use this backup script. You may consider using the default WordPress database backup script instead.

Unfortunately for me, I didn’t realise my backups weren’t working until a few weeks after the server config change was made, when I discovered that my nightly emails only contained an empty backup file!

With the easy to use WP-DBManager option ruled out, I turned to a cron job – a small program that runs on your server, based on a regular schedule you define. Thankfully someone had already come up with a script to do just what I wanted to do – you can find his instructions at http://www.tamba2.org.uk/wordpress/cron/.

Once I added the above cron job to my server I ran into a major issue – the ‘mutt’ command for sending email was not available to me, so I needed to jump into the world of shell scripting to find another way to do the same thing. This is the replacement script I came up with:

#Set the 4 variables
#Replace what is AFTER the = with the information from your wp-config.php file
#That's your information on the right okay ?

DBNAME=DB_NAME
DBPASS=DB_PASSWORD
DBUSER=DB_USER

#Keep the " around your address
EMAIL="you@email.com"

DATE=`date +%Y%m%d-%H%M%S`
PARTDATE=`date +%Y-%m-%d`

mysqldump -u $DBUSER -p$DBPASS $DBNAME > $DBNAME-$DATE.sql
gzip $DBNAME-$DATE.sql
uuencode $DBNAME-$DATE.sql.gz $DBNAME-backup-$DATE.sql.gz | mail -s "MySQL backup for $PARTDATE" $EMAIL
rm $DBNAME-$DATE.sql.gz

My shell script does much the same thing as the original script I based it upon, except that the email you get isn’t anywhere as nice looking – just a subject line and an attached backup file.

Fill in your own values for the first four variables, save the script as a file, and then follow the instructions back at http://www.tamba2.org.uk/wordpress/cron/ to get it running as a Cron job on your own server.

I setup my backups to run once daily, and since I’ve set it up the emails have been successfully arriving in my inbox, with a gzipped SQL script as the attachment. Let’s hope I never have a need to restore them!

And a sidenote…

The derailed V/Line train picture above was the aftermath of a tree falling over the tracks at Stonyford, Victoria back in 2009. No-one was killed or seriously injured when the leading locomotive ended up sideways, with the second locomotive and a few of the carriages coming off the rails – more details in the accident investigation report.

Post retrieved by 35.215.163.46 using

The post Backup your WordPress database with a cron job appeared first on Waking up in Geelong.