Gauge Magic – Fuel, Temperature & Pressure Gauge Matching / Calibration / Linearisation

[Jonathan Kay]

Thanks.

Caerbont FCT1 temperature.

I'll have a search.

Jonathan

[revilla]

Could they be JST EL connectors?

https://www.automotiveconnectors.com/6-way-jst-el-connector-female-black.html

[revilla]

@Mike-360R - Did you have your posted to a different name then? I don't seem to have an eBay order for a Mike at all.

[revilla]

@mph: It occurred to me last night after watching your video that those gauges have a full 270° sweep, which would be unusual for regular passive moving coil gauges. I'm a little bit concerned that they might be some sort of active gauge with internal electronics, in which case they may not work properly with Gauge Magic. I've emailed Caerbont Automotive Instruments this morning on your behalf to enquire about the mode of operation of those gauges and the connector type. I'll let you know if and when I get a reply. In the meantime, don't cut anything!

Text of email sent below:

Hello,

I'm wanting to install an electronic module in a Caterham which has your gauges FFC1 and FCT1. The module allows calibration of the gauge and sender, but drives the gauges with a pulse width modulated signal.

This works fine for regular passive moving coil gauges but may not work for gauges containing active electronics. I notice that these gauges have a 270° sweep and that led me to wonder whether they are just passive moving coil meters or whether they are something more sophisticated.

Before I start cutting wires, could you please confirm what sort of mechanism these gauges use please?

I would also be grateful if you could confirm the connector type used on these gauges. I believe they may be JST EL?

Thanks,

Andrew Revill

[Mike-360R]

#28 Hi Andrew. Yes, I elected to have the unit posted to my father (Derek) in Hereford. I've received an email last night from eBay confirming the item had been posted. Many thanks. The recent posts about the gauge connectors got me thinking about mine which also have the 270 deg sweep.

[revilla]

@mph, @Mike-360R:

I just had this response from Caerbont:

FFC & FCT gauges are microprocessor electronic and will not work on PWM, depending on model they are either CAN driven or resistance driven, I would need the exact model number on the labels on the back of the gauges to tell you whether they are CAN or resistive.

Just to be clear my current Gauge Magic device is only designed for regular, mechanical, moving-coil gauges. These usually have more like a 90° sweep than a 270° sweep. Gauges which have internal microprocessor electronics are unlikely to respond properly.

I can have a think about a different output stage that might be able drive these gauges. In the meantime, if anyone has ordered this in error and has 270° electronic gauges, I'll be happy to process a refund.

[mph]

Andrew, you are a star! Thank you for checking into them. 
Looks like I'll have to live with their randomness and admire your work from afar

[Benton]

Ordered Module and LED this morning, just read incompatibility problem, great shame. BM'd and EBay messaged (user:- blackwelot) to cancel, sorry.

Hope you find a solution going forwards.

[Mike-360R]

Hi Andrew,

Many thanks for your prompt investigation into the compatibility with the (newer?) gauges. I echo #32 response.

I can ask my father to return the unit to you or alternatively I will be at the Club's 40th Anniversary event at Brooklands in a couple of weeks and can hand it over then (if you are attending) or I can sell it on to another interested member at the event.

 

[revilla]

Right, I'm trying to do a rapid turnaround here ...

It seems there's a lot of demand for this with more modern gauges, which I hadn't really anticipated. These gauges will be sensing the instantaneous current flow in the sender and won't have the equivalent mechanical damping which smooths the on-off PWM signal into an average.

I think I've come up with something that would work with the newer gauges. Subject to some testing and refinement, it may well work with ALL analog gauges (none of this will work with digital gauges controlled over CAN by the ECU instead of being connected directly to a sender), including the newer microprocessor-controlled gauges and 270° sweep gauges without any changes, which means it could just replace the existing design.

If it works it:

• Will fit on the same size circuit board.
• Will re-use 90%+ of the existing design.
• Will work exactly the same from a user perspective. Other than the actual circuit diagrams and board layouts, everything I've written about the original device and how to use it will still be correct and relevant.
• Will work with the same device firmware and Windows tool (the only change being that you would probably only want to use the higher drive frequencies - if I do decide to use the new design exclusively I could probably simplify the configuration tool by taking out the frequency selection altogether).
• Will sell for the same price.

This is a first cut at the change. As you can see it's just a change to the output circuit that connects to the gauge:

The microcontroller will still generate a PWM output on pin D9 as before, at a high frequency of say 15.625kHz. This is then smoothed to a DC voltage by a  filter consisting of a 1kR resistor and 4.7uF capacitor (instead of relying on the damping of the gauge to provide the smoothing and averaging). This then directly feeds a 2kR resistor (component values still to be finalised during testing) to generate a steady current into a current mirror made of two matched transistors, in place of the previous single output transistor. This will then sink a steady DC current from the gauge.

This will act much more like a resistive sender as far as the gauge is concerned. The gauge won't see any of the PWM signal and won;t be aware of the drive frequency etc. It will just see a steady current sink controlled by the microcontroller.

Higher PWM duty cycles, which would have resulted in a higher average current in the original design, will now result in a higher steady currents.

And this is how the new circuit could be fitted into the original circuit board plan:

I'm 90% confident this will work. But it needs some testing and probably a bit of tweaking to get everything right.

And that's where I need to ask for a favour ...

Would any of you who have the newer gauge design be prepared to lend me a gauge for a few days for testing, please? I wouldn't need it for long. Ideally I would like to borrow both a fuel gauge and a temperature gauge to check that they are both driveable using the same setup. I would aim to build one and test it with gauges I have here first, then would just need to confirm correct operation on the newer gauges.

If this works out I should be able to get replacement exhange units out to anyone who bought the original unit in error quite quickly. Of course I'll still accept a return for a refund if that's what you would prefer, but I'd really appreciate the chance to get this working properly with all of the analog gauges out there.

If someone could volunteer that would be great.

And if people who have bought the original unit and would need a replacement could confirm what they would like to do given the above then I'll action any refunds still required.

Cheers,

Andrew

[mph]

How quickly could you test Andrew? I need my car this weekend, and would need them back by Aug 1st at the absolute latest (track day the next day  ) but if you were able to make use of them next week I could probably pull them out on Sunday and ship to you on Monday for next day delivery? Unless you're in Yorkshire somewhere, then I could probably drop them in 

If you find somebody nearer able to help, that'd be great. But if you're really stuck, I'll see what I can do.

Many thanks!

--Mark

[Mike-360R]

Wow Andrew - great response and swift analysis for a potential solution to the more modern gauges.

Unfortunately I won't be with my car for a couple of weeks - just before the Brooklands event. If you're struggling for test gauges at that time I will be able to take mine out and drop it over to you on Monday 7th Aug - I think you may be East Mids based.

I'm happy to keep the order you have already sent and will swap it over once your tested new solution is ready.

 

[revilla]

I'll order any parts I need today. With a following wind I'll get them by Saturday and I can build and test using my own gauges over the weekend. If that goes to plan, yes I could test on yours next week. I'd only need them for a day or two, I would just need to check whether the new device worked and take some measurements for future reference. I only have next week until I go away for two weeks and I'd like to get this resolved before I leave, so I need to move quickly.

Assuming everything goes to plan and works as expected I should be able to get some replacements sent out before I go. If things don't go smoothly I may run out of time in which case I'm afraid there'll be a two week delay.

[revilla]

In the meantime, a couple of support questions I've had so far ...

• When I plug the device into my laptop, it beeps 9 times. This is correct. If the device is not connected to a sender, it will read as though it was seeing a completely empty fuel tank. The default configuration I'm supplying them with gives 9 beeps and a solid red LED for very low fuel levels, so the 9 beeps are just the low fuel warning being triggered.

• Windows is not recognising the device when I plug it in, I'm not seeing a new COM port. Windows usually downloads the drivers automatically, but sometimes it doesn't. If you have this problem, you need to install the CH340 chip drivers manually. I've just uploaded a new ZIP file to my website at https://andrewrevill.co.uk/Downloads/GaugeMagic.zip . In this file there is now a folder CH340 Driver containing a file CH341SER.EXE. This is the very latest driver installer package downloaded directly from the manufacturer's website today, and supports Windows XP through to 11. Run this executable file and follow the prompts to install the driver. You may need to unplug the device and plug it back in again once the driver is installed for it to be recognised.

[revilla]

Well I've spent two very late nights doing some work an an upgraded version of Gauge Magic that will work with the microprocessor-controlled gauges.

It was nowhere near as easy as I thought! There are a few subtle issues involved in creating one device that will work with anything. The main problems I found were:

True moving-coil meters are ratiometric. They respond largely to the ratio of the resistance of the sender to that of the coil. If you drive them with a fixed current, you can easily set the gauge to an arbitrary position, but they then move a bit as the supply voltage changes. With a real directly-connected sender, an increase in battery voltage would drive an increase in current through the sender as well as the reference coil, leading to a steady reading. So a fixed current doesn't emulate a fixed resistance very well. The old Pulse Width Modulation method was correctly ratiometric. When driving the gauge at 50% duty cycle, it was driving it with an average of half of the supply voltage, whatever the voltage was. So it read correctly.

So I went back to first principles...

Nearly every gauge input circuit I can think of effectively consists of supplying the sender with a known voltage through a known resistance. This either leads to a measured voltage at the sender due to the potential divider formed by the known resistance and the sender, or a measured current flowing (through the moving coil in a traditional gauge). In fact these two are exactly equivalent due to Ohm's law. The current through the sender will always be the voltage across the sender divided by the resistance of the sender. Equally the current flowing in the fixed resistance in the gauge input circuit will always be the voltage across it divided by it's fixed resistance.

What this means is that instead of driving a gauge with a resistance, we can equally well drive it by drawing a particular current from it (as in my current mirror idea) or by droving the input to the voltage that would result from a particular resistance. The guage won't know the difference between any of these scenarios as they are actually equivalent; a resistive sender can be thought of as driving the input to the voltage where the currents through the sender and fixed resistance would be equal, and driving the input to a particular voltage will always involve sinking exactly the same current from it a resistive sender that produced the same voltage would.

So I had a think about a completely different approach, driving the gauge by driving the voltage at the input terminal directly. This has a few complexities:

In the case of a simple moving-coil gauge, the voltage that needs to be driven in will be a fixed fraction of the battery voltage for any given reading and will need to vary with the battery voltage to maintain a steady reading. This is the ratiometric principle described above.

For a microprocessor-controlled gauge, we don't even know what voltage is being fed to the internal fixed resistor. It could be the battery voltage again, but it's equally likely to be a regulated 5V source from a regulator inside the gauge itself. A true resistive sender wouldn't need to know, but we do. In this case the voltage driven in would need to be a given fraction of the reference voltage and would not vary with battery voltage.

If the gauge was expecting a 0-5V input signal and we accidentally fed it a 12V gauge signal, the chances are we would fry it.

I've come up with a circuit which I think addresses ALL of the above. If this works as well as I hope, it will be capable of driving ANY kind of gauge, whether it's a bimetallic strip, moving coil gauge, microprocessor-controlled gauge or full electronic dash. So far I've made a first prototype and although there were a few teething trouble type issues (all of which I think I have now resolved in the design) the basic idea seemed to work well. It's a bit more complex in concept that the first version, but an awful lot more capable.

I've used two additional analog to digital converter channels in the Arduino to read two voltages, each one of which is read by reading a precise fraction of 1/3 of the voltage derived by a resistive potential divider to bring the voltage in the range of up to 15V down to the 5V range of the Arduino's analog channels. The first is the battery supply voltage. The second is the voltage at the gauge input terminal.

The PWM output from the Arduino is heavily smoothed to a steady voltage. An operational amplifier is used to buffer this to drive the gauge. It drives the gauge terminal to match the target voltage through a PNP transistor emitter follower. This serves two purposes. Firstly it boosts the current drive capability of the operational amplifier to ensure it can provide the 100mA+ needed to drive a gauge. Secondly, it ensures that the amplifier can only ever pull the gauge input terminal downwards towards ground in the way that a resistive sender would, and can never drive it upwards. This protects against the scenario of driving a 12V signal into a 5V gauge input, the circuit just isn't capable of doing it so is safe. Note that the operational amplifier is powered off the full battery supply voltage and has a gain which exactly the reciprocal of the 1/3 sampling fraction, amplifying the 5V signal up to 15V for the output, and the feedback resistor chain that sets the gain doubles as the sampling resistive divider for the Arduino analog channel which monitors the gauge input voltage.

When the device boots up, the firmware briefly attempts to drive the output to 15V. As it can only pull downwards, the voltage it will then measure back will be the reference voltage fed to the internal fixed resistor built into the gauge. This allows it to work out whether it should be driving out a fixed fraction of a variable battery voltage, or a fixed voltage in the case of an internally regulated supply voltage. If the voltage is greater than 10V it is assumed to be variable battery voltage, below 10V it is assumed to be a regulated fixed voltage. It performs this check once, decides what mode it needs to run in, then switches to normal operation. When driving a fixed fraction of the battery voltage, the Arduino reads the current battery voltage and corrects the PWM drive duty cycle for the difference between this and the voltage at which it was calibrated, emulating a true resistive sender accurately. When driving a gauge that uses an internal voltage regulator, the battery voltage is ignored and a fixed voltage is supplied.

There's obviously quite  a bit more electronics in this design, bet after some head-scratching it all fit on a board which is only 0.1" wider and the same length as the original design.

The device firmware will obviously now be different in places but in terms of the PC application and the way you use it there will be very little change at all. The only noticeable difference is that there will be no gauge drive frequency to choose as it is now driving the gauge with a smooth, steady signal rather than a high-frequency pulse train. This should satisfy the input requirements for the later Caterham electronic gauges as well as the earlier moving-coil gauges, and the device should be able to detect what it is driving and configure itself appropriately without any need for the the user to know what is required.

I still need to get some more parts in to build some final prototypes and test. I'm going flat out to resolve the issues as quickly as I can.

Note that there was nothing actually wrong with the original design, it was just designed for the case of mechanical moving coil gauges only. It is still a perfectly good solution for those gauges. This new version will just be more widely applicable.

If you compare the original and latest circuit diagrams, you will see that it can be thought of the same device but with a smoothed, buffered, voltage-output, pull-down output stage instead of the direct PWM output and the ability to monitor the supply voltage and correct for it.

I'll update as soon as I've got it all tested and working. I'm going to need a bit of time to build, test, update the firmware and update the Windows configuration application and I'm away for a couple of weeks from the end of this week.

I'm also fairly sure I've pinned down exactly what the connectors on the later gauges are. They're not JST EL but Molex, Micro-Fit 3.0 Receptacle Connector Housing, 3mm Pitch, 6 Way, 2 Row. These have all the correct polarisation and keying. I should therefore be able to produce Gauge Magic units for the newer gauges with the correct plug-and-play connectors as I did for the earlier gauges, with no need to cut any wiring etc.

[Jonathan Kay]

Two days? Were you very busy on other projects?

; -)

Jonathan

[revilla]

More like two nights! Feel bad that people have bought it and it's not doing what they hoped. Already cracking on with the software and firmware changes needed. Will be a couple of days until some more appropriate op-amp chips arrive, then I can test properly.

[ECR]

I don't think you need to feel bad Andrew. You've acknowledged a problem and are working fast to correct it. If only vehicle manufacturers reacted like this!

[Mike-360R]

#43 - I totally agree. No need to feel bad at all Andrew. I'm really impressed how quick you've designed and progressed V2 of your product. Good luck with the testing.

[John Vine]

#43 #44

Oh, yes indeed.

JV

[Rich Goddard]

I'm looking to drain my tank and calibrate the sender/gauge this weekend. 
On a Duratec set-up (with plenum) can someone please help pin-point the best joint on the fuel line to split, to pump the tank out?

Cheers, Rich

(SuperSport R, 2015)

[John Vine]

#46

If you want to drain the tank completely, you'll need to syphon the fuel out  This is because there will be at least six litres of inaccessible fuel (yellow outline) below the pump (red outline):

 

 

To use the pump to lower the fuel level to your new calibrated "empty" point, detach the fuel connector at the fuel rail by pressing the quick-release tab:

The fuel line is stiff and doesn't twist easily, so you'll probably need an extension hose to your container.

Even with the connector detached, turning on the ignition will run the pump for only a short while (producing around 100ml of fuel).  This equates to the normal priming action.  To run the pump continuously, you'll need to lay a separate 12v feed to the pump. 

JV

 

[Rich Goddard]

#47

Thanks John.

Yes, looking to pump-out just to the top of your yellow outlined 'unusable' fuel.

Thanks for the pointers on disconnection point, and 12v feed  

[revilla]

Just in case anyone was thinking I'd forgotten about this ...

I've been going round and round the houses trying to design a driver circuit that could be constructed in approximately the same size circuit board but which would drive both passive moving coil and active electronic gauges. I've bough myself a cheap electronic gauge, not a Caterham one but one with a similar calibration that will work that same way and which did demonstrate very poor behaviour on the PWM output as expected.

I've ended up building 10 different prototypes along the way. Pretty much everything I tried was defeated by one or more of the following issues:

• Especially on 5V electronic gauges, the sender needs to be able to pull very close to ground. So buffering the output with a transistor follower was out.
• I could drive it with an open collector transistor output, but the linearise it sensibly needed an operational amplifier stage to drive that and negative feedback.
• Driving capacitive loads with operational amplifiers can be challenging in terms of stability and oscillation. It turns out that the standard gauge, which is basically an inductive coil with quite a bit of parasitic capacitance (a resonant tuned circuit) is a very nasty load to stably at low gain (the negative feedback become positive feedback at high frequencies because of the phase shift introduced by the load). It was very hard to drive the basic gauge without wild radio frequency oscillations at around 800kHz and 2V amplitude.
• The gauge I have here obviously uses a fairly basic switching regulator internally to generate the 5V reference to feed the gauge. Because an open collector transistor output is effectively a current sink, the output voltage is high impedance (as in the current drawn doesn't change much with changes in voltage). The result of this is that ALL of the switching regulator ripple from the gauge is driven across the sender input terminal, unlike in the case when it is being fed by a resistive sender which has a very low impedance. It was very noisy.
• Driving the standard basic gauge with either a fixed voltage or a fixed current didn't replicate the immunity that it would normally have to changes in supply voltage. With a resistive sender, increases in supply voltage cause a corresponding increase in the sender voltage and the gauge is constructed to respond to the ratio of these, so reads consistently with the engine on/off etc. The original PWM design effectively replicated this as it was driving out a fraction of the supply voltage. In my later designs I was having the measure the supply voltage on the device and compensate the drive level.
• Trying to squeeze anything that worked around the above onto a small board was very difficult.

In the end I did come up with a design that worked:

But:

• It was a lot more complicated. More expensive in terms of parts and took a lot longer to build, and needed quite a few compromises (chip pins removed, multiple wires sharing a single hole, bridge wires over the chip) that actually made it quite difficult to assemble. It wasn't a beginner's project any more.
• It needed a rework of the device firmware and and the calibration utility. The calibration process was further complicated by the need to record the battery voltage at which the calibration was done, so that it could actively compensate for changes.
• Even with everything I'd tried, it was still prone to oscillation being triggered by the gauge switching noise. The gauge seemed to react to OK still. But I wasn't happy with it.

But then last night I has a Eureka moment!

The existing output circuit consisted of a transistor switch to ground (fed with the PWM signal) and a flyback protection diode (as the gauge itself is an inductor). Add to that one inductor and one capacitor and you've got the configuration of a buck converter, used in power supplies to generate a voltage from a PWM-controlled regulator. It would be a "a bit backwards" in that I would be configuring at as a power-consumer rather than power-supply (the gauge itself would be feeding at the output through its internal resistance, I'd be switching on the input side). But it was simple enough to test just by including the two components as a filter in the wires between the device and the gauge:

And the result ... it works a treat! Putting an oscilloscope on the gauge shows a steady drive voltage with only a few millivolts of ripple as expected rather than a wildly on-off PWM signal. The advantages if this configuration are:

• It's cheap and simple and with a bit of tuning I should be able to build it right into the board.
• It's inherently supply-voltage compensated. The output voltage is the supply voltage multiplied by the PWM duty.
• It works with both kinds of gauge equally well.
• There are NO changes required to the device firmware and NO changes required to the Windows configuration application (other than the fact that the drive frequency becomes a bit redundant as you would always want to use the highest frequency for best performance and the gauge itself never sees it, so I will probably strip that out to simplify it).

All of the gauges I have here respond nicely to it.

Unfortunately I've run out of time to get this all productionised before I go away for two weeks. I was really hoping to get replacement units out to people before I went, but with all of the different iterations an investigations I've run out of time. Please bear with me and give me a bit of time to sort this out. The problem is solved, I'm sure. I'll crack on with making it all ready to send out as soon as I get back.

[Mike-360R]

Hi Andrew. Excellent post on your ongoing investigations, issues encountered and your 'Eureka' resolution. Sounds like you've had a busy and 'testing' week. Don't worry about the timelines for bringing your solution to production - really great to hear you've found a solution that works for all. I hope you enjoy your well-earned two week break.