My FJ62 originally came with a 3F petrol tachometer. I swapped in a 2H diesel tachometer gauge (same RPM range, but meant to be driven by the correct diesel signal) for better accuracy. The injection pump is a Denso VE6 (22100-17290) carrying a 1HD-T 2-wire variable reluctance (VR) sensor — not the stock flywheel-mounted sensor a 2H normally uses.
My goal is to drive the OEM 2H gauge from this pump-mounted VR sensor using an Arduino Uno, without spending on an expensive imported tach-converter box. A first attempt using AI-assisted guidance (Gemini) failed because it misdiagnosed the gauge as a simple petrol-style coil-pulse tachometer. This write-up documents the troubleshooting since then, with measurements at every step.
I am by no means an expert or claim any of the below is correct or even accurate, this is my attempt to learn how to DIY. If there are any mistakes, errors or anything please feel free to correct me !
Please note this is a work in progress, the plan is to build a custom ECU where I gather all input signals (EGT, water temp, oil pressure, RPM etc.) and use an ESP32 (or Bluetooth) to output all information on an android device.
The C1006C is a fully self-contained tachometer driver: it takes a signal on the gauge's input terminal and internally handles comparator/conditioning, frequency processing, and driving the needle motor against a return spring. There is no separate divider or driver IC on the board — just the one chip.
Sensor resistance is in the normal healthy range for a VR sensor (typically 500Ω–2kΩ). Frequency scales with RPM as expected for a toothed-wheel VR pickup.
Coil resistance measured directly across the gauge's signal and ground terminals: 27.5 kΩ. Combined with the test results, this told us the C1006C does not respond to held DC voltage — it responds to a changing/pulsing signal. A static voltage gives no edges for the chip to count.
• Stock 2H uses a flywheel-mounted VR sensor reading a 108-tooth ring gear, not a pump sensor
• Stock sensor output is roughly 10V peak-to-peak AC at running speed
• The gauge's internal comparator stage triggers around a 3V threshold
• Internally the signal is divided (documented as ÷32 in that reference) before frequency-to-voltage conversion drives the needle motor
• In the stock harness, the sensor wires run directly to the gauge — no external signal-processing box
This explains why a direct VR-sensor-to-gauge connection (mimicking stock wiring) produced no movement in our case: our pump sensor produces a different frequency profile than the 108-tooth flywheel sensor the gauge's internal scaling was designed around. After accounting for the internal divider, our idle frequency works out far below what the gauge's internal frequency-to-voltage stage appears calibrated for. The practical implication is that the gauge likely needs a higher pulse frequency at the input than our raw pump signal currently provides.
The onboard trimmer pot is adjusted with the engine running until Hz readings are stable. This stage is confirmed working — Arduino-calculated frequency matches a separate multimeter frequency measurement at idle and under load.
Fix: a minimum pulse period check in the interrupt handler discards any pulse arriving faster than a set threshold (effectively a low-pass filter implemented in software, no extra hardware needed).
After this change, Arduino-calculated Hz tracked the multimeter's Hz reading closely across idle and throttle testing.
PPR = (Hz x 60 x 2) / Engine RPM [pump runs at half crank speed] Testing PPR = 24: RPM = Hz x 120 / 24 = Hz x 5 170 Hz -> 850 RPM (idle — plausible) 405 Hz -> 2025 RPM (moderate throttle — plausible)
PPR = 24 produced believable numbers across the whole tested range, while smaller values (6, 12) produced impossible idle RPM and other candidates didn't fit as cleanly. This was adopted as the working calibration: RPM = Hz × 5.
This behavior — RPM rising and falling in step with a known physical event — is good circumstantial confirmation that the frequency-to-RPM scaling is in the right ballpark, even without an absolute reference instrument.
Key fact established along the way: a manual rapid tap of 12V directly onto the signal terminal does move the needle. This confirms the gauge's input stage responds to a 12V-level switching signal — the remaining problem is delivering a clean, correctly-scaled switching signal automatically, and getting the transistor stage wired correctly so it isn't dragging the signal voltage down.
2. Confirm a single, common ground point between Arduino, car battery negative, and the gauge ground terminal — this was found to be missing at one point and caused unstable readings
3. Run a frequency sweep test (Arduino outputs a slowly rising switching frequency to the gauge through the corrected transistor stage) to empirically find the frequency range the C1006C responds to, rather than relying on the ÷32 figure from the stock-system reference, since our sensor source is different from the stock setup
4. Use the result of the sweep to set a multiplier so the pump's natural frequency is scaled into whatever range the gauge actually responds to
5. Cross-check the gauge's reading against the already-working TM1637 digital display once movement is achieved
Posting this for feedback — particularly interested in anyone with direct knowledge of the C1006C's actual input frequency range/threshold, or experience driving a Toyota OEM analog tach gauge from a non-stock sensor source.
Currently I have a digital working RPM gauge, which for me is a great step forward! I am looking for 1HDT gauge to calibrate my RPM to it (as a reference) so I have an accurate reference.
My goal is to drive the OEM 2H gauge from this pump-mounted VR sensor using an Arduino Uno, without spending on an expensive imported tach-converter box. A first attempt using AI-assisted guidance (Gemini) failed because it misdiagnosed the gauge as a simple petrol-style coil-pulse tachometer. This write-up documents the troubleshooting since then, with measurements at every step.
I am by no means an expert or claim any of the below is correct or even accurate, this is my attempt to learn how to DIY. If there are any mistakes, errors or anything please feel free to correct me !
Please note this is a work in progress, the plan is to build a custom ECU where I gather all input signals (EGT, water temp, oil pressure, RPM etc.) and use an ESP32 (or Bluetooth) to output all information on an android device.
Hardware Identification
| Item | Detail |
| Vehicle | Toyota FJ62 Land Cruiser, 2H diesel RPM guage, 1HDT engine |
| Injection pump | Denso VE6, P/N 22100-17290 |
| Sensor | 1HD-T 2-wire VR sensor, fitted to the VE6 pump |
| Gauge | Toyota 83270-90A00, 12V |
| Gauge IC | NEC C1006C (8-pin DIP) — no public datasheet found |
The C1006C is a fully self-contained tachometer driver: it takes a signal on the gauge's input terminal and internally handles comparator/conditioning, frequency processing, and driving the needle motor against a return spring. There is no separate divider or driver IC on the board — just the one chip.
Sensor Measurements
| Measurement | Value | Condition |
| Coil resistance | 1.70 kΩ | Engine off |
| Coil resistance | 2.31 – 2.40 kΩ | Cold start running |
| Coil resistance | 3.00 kΩ | Slight throttle |
| AC output | 0.5 – 2 V AC | At idle, rises with RPM |
| Frequency | 164 – 180 Hz | Cold idle |
| Frequency | ~232 Hz and up | Light throttle |
| Frequency | Up to ~400+ Hz | Moderate throttle |
Sensor resistance is in the normal healthy range for a VR sensor (typically 500Ω–2kΩ). Frequency scales with RPM as expected for a toothed-wheel VR pickup.
Gauge Bench Testing
Before building any circuit, the gauge itself was bench tested off the car to understand what kind of signal it actually wants.| Test | Result |
| 12V DC direct to signal terminal | Needle moved to ~1300 RPM and held |
| 10kΩ or 1kΩ resistor + 12V to signal | Negligible movement — coil is 27.5kΩ, current too low |
| ~22–24V (solar panel) direct to signal | Needle moved only when wire was tapped/scratched, not held |
| Manual rapid 12V tap to signal terminal | Needle responds clearly — mechanism confirmed alive |
| Steady 12V or steady AC, no switching | No sustained movement |
Coil resistance measured directly across the gauge's signal and ground terminals: 27.5 kΩ. Combined with the test results, this told us the C1006C does not respond to held DC voltage — it responds to a changing/pulsing signal. A static voltage gives no edges for the chip to count.
Lessons learned from a Stock 2H Wiring Reference
Reference material on the stock 2H tachometer system (sourced from forum/technical documentation on the factory bellhousing-mounted sensor) gave useful context:• Stock 2H uses a flywheel-mounted VR sensor reading a 108-tooth ring gear, not a pump sensor
• Stock sensor output is roughly 10V peak-to-peak AC at running speed
• The gauge's internal comparator stage triggers around a 3V threshold
• Internally the signal is divided (documented as ÷32 in that reference) before frequency-to-voltage conversion drives the needle motor
• In the stock harness, the sensor wires run directly to the gauge — no external signal-processing box
This explains why a direct VR-sensor-to-gauge connection (mimicking stock wiring) produced no movement in our case: our pump sensor produces a different frequency profile than the 108-tooth flywheel sensor the gauge's internal scaling was designed around. After accounting for the internal divider, our idle frequency works out far below what the gauge's internal frequency-to-voltage stage appears calibrated for. The practical implication is that the gauge likely needs a higher pulse frequency at the input than our raw pump signal currently provides.
Signal Conditioning — LM393 Comparator
To get a clean, Arduino-readable digital signal from the weak VR sine wave, an LM393-based comparator module (HW-103, with onboard sensitivity trimmer) is used ahead of the Arduino input.| LM393 Pin | Connects To |
| VCC | Arduino 5V |
| GND | Arduino GND |
| DO (digital out) | Arduino Pin 2 (interrupt input) |
| AO (analog out) | Not used |
| 2-pin sensor input side | VR sensor leads (polarity does not matter) |
The onboard trimmer pot is adjusted with the engine running until Hz readings are stable. This stage is confirmed working — Arduino-calculated frequency matches a separate multimeter frequency measurement at idle and under load.
Noise Filtering
Initial testing without filtering showed the Arduino occasionally reading spurious spikes (signal jumping to several thousand Hz under throttle, well above what the multimeter showed). This was traced to electrical noise being picked up by the comparator stage at higher signal amplitude, not a real engine signal.Fix: a minimum pulse period check in the interrupt handler discards any pulse arriving faster than a set threshold (effectively a low-pass filter implemented in software, no extra hardware needed).
After this change, Arduino-calculated Hz tracked the multimeter's Hz reading closely across idle and throttle testing.
Working Sub-System: TM1637 Digital RPM Display
Rather than wait on the analog gauge problem to be fully solved, a second, independent readout was built using a TM1637 4-digit display — cheap, simple, 2-wire data interface. This gave an immediate, working numeric RPM reference to validate the Hz-to-RPM math, decoupled from the gauge troubleshooting.Working Out the Scale Factor
With no factory tooth-count spec available for this pump/sensor combination, the pulses-per-revolution value was derived by working backwards from plausible 1HD-T idle RPM (700–800 RPM warm) against the measured idle frequency (~165–170 Hz):PPR = (Hz x 60 x 2) / Engine RPM [pump runs at half crank speed] Testing PPR = 24: RPM = Hz x 120 / 24 = Hz x 5 170 Hz -> 850 RPM (idle — plausible) 405 Hz -> 2025 RPM (moderate throttle — plausible)
PPR = 24 produced believable numbers across the whole tested range, while smaller values (6, 12) produced impossible idle RPM and other candidates didn't fit as cleanly. This was adopted as the working calibration: RPM = Hz × 5.
Display Wiring
| TM1637 Pin | Connects To |
| CLK | Arduino Pin 3 |
| DIO | Arduino Pin 4 |
| VCC | Arduino 5V |
| GND | Arduino GND |
Validation
With no OBD scanner available, the display was cross-checked using the AC compressor: turning the AC on triggers an idle-up actuator that opens the throttle slightly to compensate for compressor load. The display tracked this correctly:| Condition | Displayed RPM |
| Idle, AC off | ~820–850 RPM |
| AC on (idle-up active) | ~920–975 RPM |
| AC off again | Returns to ~920 then settling toward idle |
This behavior — RPM rising and falling in step with a known physical event — is good circumstantial confirmation that the frequency-to-RPM scaling is in the right ballpark, even without an absolute reference instrument.
Open Problem: Driving the Analog Gauge
The digital display works. The original analog gauge does not yet. Attempts so far and what they told us:| Approach | Outcome | Conclusion |
| Arduino 5V pulses direct to signal terminal | No movement | 5V insufficient to trigger C1006C input stage |
| 2N2222 switching 12V pulses (emitter-follower config) | Only ~5–6V reached signal terminal | Wrong transistor topology for this load |
| 2N2222 in pull-up config (collector + pull-up resistor) | Signal stuck low / stuck high depending on wiring | Grounding and biasing issues during trial, not fully resolved |
| Direct VR sensor to gauge (mimicking stock wiring) | No movement | Pump sensor frequency/amplitude profile doesn't match the flywheel-sensor signal the gauge expects |
Key fact established along the way: a manual rapid tap of 12V directly onto the signal terminal does move the needle. This confirms the gauge's input stage responds to a 12V-level switching signal — the remaining problem is delivering a clean, correctly-scaled switching signal automatically, and getting the transistor stage wired correctly so it isn't dragging the signal voltage down.
Current Plan
1. Rebuild the transistor output stage from first principles, using multimeter diode-test mode to positively identify base/collector/emitter on the specific 2N2222 in hand before wiring (datasheet pin order is not always reliable for sourced parts)2. Confirm a single, common ground point between Arduino, car battery negative, and the gauge ground terminal — this was found to be missing at one point and caused unstable readings
3. Run a frequency sweep test (Arduino outputs a slowly rising switching frequency to the gauge through the corrected transistor stage) to empirically find the frequency range the C1006C responds to, rather than relying on the ÷32 figure from the stock-system reference, since our sensor source is different from the stock setup
4. Use the result of the sweep to set a multiplier so the pump's natural frequency is scaled into whatever range the gauge actually responds to
5. Cross-check the gauge's reading against the already-working TM1637 digital display once movement is achieved
Parts Used So Far
| Part | Role |
| Arduino Uno | Reads sensor frequency, drives outputs |
| Arduino Screw Shield | Clean terminal connections |
| LM393 comparator module (HW-103) | Converts VR sine wave to clean digital signal |
| TM1637 4-digit display | Working digital RPM readout |
| 2N2222 NPN transistor | Intended 5V-to-12V signal level conversion for gauge (in progress) |
| 1kΩ / 10kΩ resistors | Transistor biasing |
Posting this for feedback — particularly interested in anyone with direct knowledge of the C1006C's actual input frequency range/threshold, or experience driving a Toyota OEM analog tach gauge from a non-stock sensor source.
Currently I have a digital working RPM gauge, which for me is a great step forward! I am looking for 1HDT gauge to calibrate my RPM to it (as a reference) so I have an accurate reference.
Last edited: