Personally, I cannot wait until I can get into my car and tell it where to drive me, without having to do the driving myself. Now that doesn't mean I don’t enjoy driving - because I do - but it’s not something I feel I have to do. And I also honestly believe that autonomous cars will result in a lot less congestion and road accidents.

A fairly busy road runs right past the front of my house. I don’t have a driveway, so I have to park my car on the road. It is a main road, used a lot by commuters and hauliers, which makes getting in and out of the car quite challenging at times. Despite it being a main road, it is speed restricted to 30 mph, as there are two schools situated on it. You might think that parked cars and school children would be enough to stop people speeding, but it really isn’t. In fact, there are accidents on a fairly regular basis; the last one was a motorcyclist right outside our front door. The road was closed for several hours and the motorcyclist had to be air-lifted to the hospital.

There are no safety cameras on that stretch of the road, which is probably why drivers regularly speed along it. While I can’t be sure that all of the accidents that happen are the result of people speeding, I’m fairly certain that it is a contributing factor.

As a resident, I want the council to put up a safety camera, or at least one of those signs that tells you how fast you’re going. As an engineer, I want to devise a way of measuring the speed and level of congestion, in a way that I can perhaps present to the council to support the investment needed to install a safety camera. So, let’s grab an old envelope and start designing.

At a top level, I think it should be a cloud-based service that could support an undefined number of standalone detectors. The basic premise is that by capturing the presence of a vehicle in several places along a stretch of road, I could determine the average speed of a particular vehicle without capturing any other data about it (and therefore avoid any potential GDPR issues). Each detector would be triggered by a vehicle, and tag that event with an exact time and its own position. This data can then be sent to the cloud, where an app can work out the time between two events on a stretch of road; the distance between the two detectors and the time of the events will give the average speed of the vehicle. As well as the speed, it can also count the number of vehicles using the road in each direction.

OK, so it has some flaws; if a vehicle stops between two devices it wouldn’t be picked up leaving the zone, but the app can compensate for that. If one vehicle stops and another parked car drives off it could cause anomalies to arise, but on the whole I think the idea of simply detecting vehicles as they pass known locations will provide enough data to give some meaningful insights.

Although the main part of the design should be fairly straightforward, there are two areas that need a bit of contemplation; the type of wireless connectivity to use, and how to detect the vehicles. A LPWAN would be ideal, but I’m not sure if I have Sigfox or LoRa coverage in my area, besides the amount of data the detectors generate may be too high for a LPWAN to cope with. Given that the area to be covered could be many kilometres, Wi-Fi is out, so right now that only really leaves cellular. There are plenty of low-cost, pre-certified cellular modules available now, some of which have GPS built-in, so I think that part of the design is basically covered.

The sensor is a different matter; it is not obvious what kind of solution to use in this cFppase, as the basic requirements are to detect fast lateral movement from a range of around 10 meters. Individually these requirements aren’t that difficult. With a suitable lens, a PIR sensor (like the ones technology used in low-cost security lights) can detect movement at that range. The problem is the speeds are involved. A PIR sensor can react relatively quickly to a single event, but cannot subsequently recover fast enough to detect multiple events in quick succession with adequate accuracy for this application. An optical solution will work fast enough, but range could be a problem.

I remember reading about Time-of-Flight (ToF) sensors, which use emitters and detectors to measure the time it takes for photons to reach an object and get reflected back. A quick search has turned up the VL53L1X from STMicroelectronics. This might do the trick; it’s a really cool device that is small, low power and highly integrated. It would be very well suited to any number of applications where distance measurement is required, but not this one sadly - as its range is limited to 4 metres, which, while impressive for such as small device (it measures less then 5 mm by 2.5 mm and is only 1.56 mm high), isn’t going to be enough in this application context. I think it needs to cover at least double that distance, because the detectors would be mounted on one side of the road to cover both lanes. Something that can cover up to 12 metres will be spot on, which probably rules out any kind of optical device that relies on an emitter and receiver.

Taking out the emitter leaves an optical detector that works on visible light, also known as a camera. Now, while cost isn’t necessarily a major concern when you’re making one or two devices, there is an outside chance that this could turn into a viable product, something that the local council might be interested in, for example, so I don’t want to rule that out by basing it on an expensive camera-based arrangement. This needs to be power efficient and low cost, as well as relatively simple. While CMOS sensors can be both inexpensive and low power, the processing effort that would be required just to detect movement seems like an unnecessary overhead. One way around that is to use a sensor that just detects light levels, like the BH1749NUC ambient light sensor from Rohm. This is a nice little device (with just eight pins) that integrates four photodiodes and detects Red, Green, Blue and NIR levels, converts them to a digital format and outputs them over an I²C bus. Simple, yet effective! This is the kind of device that is used in modern TVs so they can adjust their output based on surrounding light conditions, for example. While, conceivably, I can use one of these to detect motion, it would require some (probably not that cheap) optics to get the performance needed. There has to be a better way.

It just occurred to me that microwave is the way to go. The technology most speed detectors employ - including police scanners - is microwave. As this isn’t your everyday technology, I’m guessing that integrated solutions will be difficult to find and expensive to buy, which suggests a discrete solution is necessary, but I’ve just discovered that both Infineon Technologies and Texas Instruments have millimetre wave (mmW) devices that are aimed at just this kind of application.

The least integrated (and least expensive) is the BGT24Mxx silicon germanium (SiGe) MMICs from Infineon. It comes in a 32-pin VQFN package, which claims to save around 30 percent of the board space required for a discrete solution. That’s nice, but really the benefit here is the pre-integration of the transmitter and receiver. It operates at 24GHz, so it is in the ISM band and therefore does not require a licence to operate - another bonus. However, while this is a very competent and cost-competitive transceiver, it would still require a separate processor to handle the data. Could there be something even better? (and when I say better, I mean more convenient.) The answer, it appears, is yes.

I think the IWR1642 single-chip mmW sensor from Texas Instruments is just what I’m looking for. Let’s go to the application listings: industrial sensor for measuring range, velocity and angle - check; tank level probing radar - urm, check?; displacement sensing - probably not, but check; field transmitters - no idea; traffic monitoring - ah, double-check!

As well as the RF part (implemented in CMOS on this device), it comprises a DSP and an ARM Cortex-R4F processor sub-system, which takes care of the signal processing and control elements. It even incorporates a ROM with the firmware, as well as 1.5Mbyte of on-chip memory for application code.

Right, that’s the basic design covered, time to start getting down to details. But first, a nice cup of tea is in order.