An Enginerds life with a 2003 Aprilia Caponord Rally-Raid ETV1000 (2008 – 2024)
Saturdays lovely sunny weather gave way to thick fog and a definite chill in the air – time then to hunker down on the PC and finish the CGI dashboard and add a couple of extra bits to make it a touch more interesting on the eye.
An old (ironic) joke in England states that you will stand around for an eternity waiting for a bus – only for three to come along at the same time! In the same way, dashboard faults sometimes do a similar thing. Recently I had three boards arrive; all had defective speedo/tacho motors. All six motors were physically broken and two electrically dead.
The motors mount to the circuit board by four soldered pins and two push-fit pegs. The arms on the motor case that grip the pegs break off and that leaves the motor pivoting 
on the four soldered pins. With time and vibration, the armature wires that are soldered to the pins flex and break – one dead motor.
Replacements are available from flea-bay for between £30 and £45 –not exactly a cheap part, especially when the old one may still be working fine. Now it seems a cheaper solution is available in the form of a replacement front cover (part with arms) for a fraction of the price of the full motor. On close inspection it doesn’t look like a 1-for-1 copy of the original (the arms are slightly different) but it’s well worth a punt at that price to see if it works.
So why are they failing? Well my guess is, it’s a combination of age, vibration and heat/cold cycling that causes the arms to fracture. Once that support has gone, the motor is left suspended on the four soldered arms – and they in turn are press-fitted into flimsy 
plastic spacers. The armature wire (very thin!) is soldered onto these pins, with very little slack ……. So any flex between motor and pins will inevitably stress the wires and cause them to break. They can be repaired of course, you just need good equipment, a magnifier and VERY steady hands!
Unfortunately, spotting a broken motor is difficult without striping the dashboard, but here’s a little something to look out for …… have a good close look at the needle, where it passes through the inlay. If the speedo needle looks like it’s drooping downwards or the tacho needle looks like it’s leaning to the left – suspect a broken motor. Remove the dashboard and give it a gentle shake – hear something rattling inside? That’ll be the broken arms floating around – tick-tock, tick-tock – it’s only a matter of time now before the armature wires give way!
I’m not really enthusiastic about the constant onslaught of technology on motorcycles …. the cynic in me sees mostly a revenue-earning exercise whereby the benefits to you and me are far outweighed by the locked-out, take-it-to-the-dealer and be fleeced mentality of the manufacturers.
But occasionally I do spot something that tweaks the nose of my flagging interest …. this time it’s been the BMW Dynamic Brake Light system. Trying to get the myopic, half-asleep nit-wit to notice the difference between my normal braking and HARD BRAKING is sometimes a real issue. There’s nothing worse than gliding to a halt only to hear some plank with full ABS active about to kiss my back wheel! Hmmm so how hard can it be to make a box of tricks to do the same as the BMW system and fit it on the Capo …..
Well a tad more difficult than I first thought that’s for sure! The BMW system seems to work as follows:
*EU rules quote a rate of 4Hz (±1Hz) for LED’s and 4Hz (-1Hz) for incandescent bulbs.
So how to replicate this on the Capo? Enter one test-box to get things started …… a microcontroller that measures acceleration in three axis and has inputs/outputs to the brake light, hazard lights and speedometer. The box of tricks is designed to allow normal brake/hazard light function in case of power or hardware failure … all in the name of safety don’t ya know.
Getting usable data from the accelerometer was harder than I thought ….. the thing is VERY sensitive and has needed a lot of filtering and data-smoothing to get usable info from it. But after a couple of days and quit a few emergency stops (all good practice!) the data is starting to look good.
Next up, I need to input the Capo’s speed to the microcontroller. For this I’ll use the speed output pin directly from the dashboard – I knew it would come in handy one day! All the inputs are buffered with opto-isolators to make sure the system is as well protected from the noisy fluctuating voltage in the Capo’s loom as is possible. Now with the prototype well under way, it just remains to find answers to some other questions ….. such as what about braking on wet, loose, icy surfaces where deceleration will be significantly less, but the dynamic brake light might still be useful. My guess is the BMW system has some integration with the ABS system to shift the triggering point, but I don’t have ABS! This one I’ll have to ponder on a while longer.
One things for sure …. you learn a lot about braking forces, motorcycle dynamics and breaking code doing this malarkey! Oh and I’ve found out that a warm front tyre breaks grip at about 1.1g …… 😳
Sometimes a particular feature of a piece of technology can drive you nuts – that itch you can’t scratch! Here’s my particular niggle with the Capo dashboard ……
Just imagine, it’s a nice day and you’re all suited-and-booted, ready to tear up the countryside on the Capo. You’ve pushed the ‘Set’ button on the dashboard to display the trip meter and all is fine and dandy in the world, later you pull over for a break and when you restart the bike – the dashboard has switched back to odometer! I know it’s not exactly the end of the world, but it is annoying. Why couldn’t Aprilia just code the damn thing to display on start-up what it showed at shut-down, many other bikes seem to do it.
So as part of the long running Mk2 dashboard project, the feature has now been incorporated!
With a little bit more code and a couple of extra wires, the dashboard now knows what was displayed (odometer or trip) at key-off. Then it simply electronically replaces a winter-gloved podgy finger and prods the ‘Set’ line to the old microcontroller a second after the board finishes its POST (power-on-self-test) routine. It also now reads the voltage from the fuel level sensor in the fuel tank, so that if the trip meter is displayed at key-off AND the fuel level changes from less than 15% to greater than 90% (approx. <5l to >20l refuel) at the next key-on, the trip meter will be reset automatically. If you don’t want the reset to go ahead, you simply make sure the dashboard is displaying the odometer before switching the bike off, now the reset is ignored.
Of course all this is well and good on the workbench, but in real day-to-day use – will it scratch that itch? Hmm, time and a few miles under the Capo’s belt will determine that answer……. maybe I’ll just end up with a nasty little rash! 😕
Way back when I started playing with the idea of using the dashboard tachometer as a voltmeter, I was aware I had one stumbling block …. I didn’t have a decent workbench power supply to calibrate the software/voltmeter against. In the end just using a battery and resistors the ball-park calibration wasn’t too bad, reading within a needles width of the correct voltage from 13 – 14v but it drifted terribly above and below this range.
Then in summer along came a gift from ABSL via Andy (Beasthonda) …. A very nice Thurlby 30V-2A dual power supply, which unfortunately had to languish in Oxford as it was too heavy to transport back by Capo! But patience is rewarded and it finally sits on the workbench, performing brilliantly and its first job has just been to calibrate the dashboard voltmeter once and for all. In the end it required a little code revision to get it just so, but it was worth it – now the voltmeter is accurate to a needles width over the full range of 9 – 16V. Happy Days! One more job to tick off the must-finish list. 😀
I really can’t say how much I appreciate Andy for thinking of me and ABSL for letting this power supply go to a complete stranger, I look forward to putting it to good use and hope that some of the tinkering on the workbench can make its way into other Caponords.
On the Mark 1 Capo there’s a screw-on cover, on the Mark 2 a panel held on by 4 screws but on the Raid it’s just waving in the wind …. staring at you with those half-inch high letters screaming “FUSE”. Quite why Aprilia felt the Raid needed an uncovered fuse box below the dashboard is anyones guess …….. it’s not like I need millisecond fuse changes!
Besides it’s always niggled me that one sunny 
day some light-fingered arse would think it a jolly wheeze to pull all the fuses out when it’s parked up. To remove the temptation I’d been keeping an eye open for a replacement panel for a while. Recently when a panel from an 05 came up on Ebay I was in-like-Flynn and the Capo got a nice little upgrade. I think it looks much better now. 😀
With just over 82,000 miles on the Caponord, the dashboard died. Yes, while about to set off from a rather innocuous little shop car park on a hot and humid afternoon, the dashboard shuffled off its mortal coil … Curled up its toes, bought the farm – as dead as the proverbial Dodo.
On the way home I mulled over the possible cause, was it the additional microcontroller/hardware I added in 2013 or simply a failure of some part of the original Magneti Marelli circuit board? By the time I got home, I had a few possibilities rolling around my head, but nothing concrete. 15 minutes after cutting the ignition, the dashboard was on the test-bench.
Ultimately the fault was traced to a ‘Via’, a hole where a signal/power track passes from one side of the board to the other. In this case, where there should have been 12 Volts, there was 2 Volts! A simple wire link bypassed the problem and the dashboard popped back into life.
So is it a design flaw or manufacturing defect? I’d say probably a bit of both! Below is a photograph of the faulty area on a Mk1 and Mk2 board. Notice the Mk2 (right hand) has a much larger track area AND has 4 Via’s instead of the Mk1’s single Via bringing power from the top of the board to the underside. All well and good BUT both boards still only have a single Via (red dot) to pass power to the regulator on the front ……….. And it’s this Via that failed!
It seems that this was known to be a troubled area and was re-designed …. sort of. But the fact that the last Via was never upgraded, simply left this as the weak link – unfortunately, one of many on these boards!
Anyway, this one’s a runner for now ……. and that’s a jolly good excuse for a run around for an hour or two to thoroughly test it out! 😀
A few days ago while doing a bit of investigating for an AF1 forum member regarding the tachometer signal from the ECU, more specifically what would he observe on a multimeter instead of an oscilloscope, I momentarily shorted the tacho line against the chassis with the bike running. The tacho shut down and the bike just kept chugging along quite happily – no EFI light, no tacho. Recycling the ignition bought the tacho back to life and it’s been fine ever since ……… but two points came out of this that may be of use to other owners.
Anyway, just a quick observation, a new (to me) fault code …. one to file away in the compendium of Capo facts. It certainly proves that the tacho signal isn’t just a ‘dumb’ signal, it’s one the ECU monitors and protects as neccessary by shutting it down.
While the wrist is healing nicely on light-duties and (thankfully) out of the heavy and restrictive cast, I’ve had a chance to play with the idea of an active cruise control for the Capo. An active system will adjust the throttle automatically to maintain a given speed even as the road rises and falls unlike a passive system which is nothing more than some form of throttle locking mechanism.
The system I’m thinking about will, when all parameters are met (speed, revs etc) lock onto the chosen speed when the ‘Set’ button is pressed. The microcontroller will then look at the error between the chosen speed and actual speed and adjust the throttle as neccessary to try and maintain the error at zero – this is done using PID (proportional-integral-derivative) in the controller. If cruise is stopped (operation of brake or clutch) or the PID error goes beyond a pre-determined maximum (high gear on a steep hill for example) the requested speed is stored and can be re-activated by pressing the ‘Res’ume button. And while in cruise, the speed can be adjusted in 1Kmh increments by using the same two buttons, now working as ‘Acc’elerate and ‘Dec’elerate. That’s the theory anyway!
Inputs
Outputs
To date the inputs and safety stuff has been written and from the tacho/speedo signals it’s calculating what gear the bike is in pretty quickly, but I’m sure it can be speeded up …… I just need to learn more programming! The operating parameters I’ve decided on are:
At the end of the day, I just want a system that will give my old worn out wrist a rest at motorway speeds on the run between Italy and the UK, taking into account the (very!) variable speed limits and ascents/decents especially through Switzerland. If it can do that I’ll be a very happy bunny indeed.
Of course this is all well and good, but I’ve got to get all the bits talking to each other first and make it robust enough for long-term and safe use on a motorbike ….. the problem is that in amongst all this enthusiasm my wrist still has a way of letting me know who’s really in control while swanning around on light duties!
I switched on the fog-lights to better illuminate the mud and stone strewn road ahead; when it dawned on me that I hadn’t taken the Capo out in the dark for ages, months probably. And here I was winding a path along our troubled road and hopefully onward for a nice little night-time ride all in the name of testing the auto-dimming backlighting!
After getting the set-up working nicely with the old thumb-over-the-sensor routine, it was time to take the old girl out for a spin and see what the illumination was like both in unlit rural and street-lit urban riding. I took the netbook and cable along so that changes to the code could hopefully be done at the roadside.
In the end I was really pleased with how the lighting worked anyway, the only change I made was to the minimum brightness – dropping it slightly – so that it’s totally readable without putting stress on my tender night-time vision. Daytime backlighting is, as you would expect fully-on at 100% while the night-time drops to 30%, which with the higher output LED’s (blue & green) is just about spot on.
But ……
And there’s always a ‘but’ …… the two LED’s in the binnacle (Autoswitch & Battery monitor) now stand out as being overly bright compared to the dashboard at night, so, time to work out how to take these signals and pass them through the Arduino and subject them to the auto-dimming code as well, then the whole cockpit area will be sorted at last! 😉