I'm writing a library that will interface with a control unit on a refrigerator compressor pump (QDZH35G). One of the features of the control unit is that it can detect what problems it's encountering and report them via a flashing LED. Operational errors will cause the LED to flash a number of times. The number of flashes depends on what kind of operational error was recorded. Each flash will last 1/4 of a second. After the actual number of flashes, there will be a delay with no flashes, so that the sequence for each error recording is repeated every 4 seconds.

My goal (as it relates to this post) is to monitor the signal from the diagnostic lead and report what error the control unit has detected. I used my oscilloscope to monitor the diagnostic port, here are some pictures of that (fault codes 1 and 4):

Fault code #1 Fault code #4

(more photos here)

So the signal looked simple and clean enough. But just to be sure, I wanted to make sure Arduino was seeing it as my Oscilloscope was. I hooked the diagnostic port up to my Arduino digital port 8 and analog pin A0 (I wanted to monitor both to decide what would be the best to use for this) and uploaded the following sketch:


void setup() {        


void loop() {
  int currentAnalogValue = analogRead(ANALOG_DIAGNOSTIC_PIN);
  int currentDigitalValue = digitalRead(DIGITAL_DIAGNOSTIC_PIN);

  // Bump binary 1 to int 1023, to make it easier to see in the logs
  Serial.print(currentDigitalValue == 0 ? 0 : 1023); 


And oddly enough, the signal Arduino was giving back seemed to be all over the place for both the digital and analog pins. While there was some pattern visible it's a pretty big mess.

Then I used CoolTerm to monitor and export the serial data into a CSV file which I then imported into a Google Docs spreadsheet (here) to create some graphs. I captured 10+ seconds in each of the following scenarios:

  1. No fault/control (zero blinks)
  2. Fault #1 (1 blink then 4-second pause)
  3. Fault #3 (3x 0.25 second blinks separated by 0.25 seconds, then 4-second pause)

Here are the screenshots of the graphs (also in the Google spreadsheet doc and imgur gallery):

Graph of control scenario - no fault (zero blinks) Graph of fault code 1 enter image description here

Finally - The question.. Why is the data seen by Arduino seem considerably less stable than that seen by my oscilloscope? I know that when reading a signal from some sensors (pressure transducer, thermocouple, etc) you get much more accurate and consistent results by averaging the last n readings, but the diagnostic voltage port isn't really a "sensor", it's just a voltage reading.

Additionally, it's reading from a pump powered by a DC desktop power unit, which has very stable voltages (I only say this because I know the voltage affects the level of the peaks from the diagnostic port).

  • Comments have been moved to chat; please do not continue the discussion here. Before posting a comment below this one, please review the purposes of comments. Comments that do not request clarification or suggest improvements usually belong as an answer, on Arduino Meta, or in Arduino Chat. Comments continuing discussion may be removed.
    – Nick Gammon
    Jul 11, 2023 at 5:06
  • A lot of comments, but no answers posted. If the situation is resolved please post an answer. @Justin - you can answer your own question if you think you have the solution. Thanks!
    – Nick Gammon
    Jul 11, 2023 at 5:07

1 Answer 1


Where to start? Your O'scope photo shows about 3 vertical divisions when the fault line is 'high'. The labelling at the bottom shows '5.00V', which I'm going to assume means '5V per vertical division'. This would mean your 'high' voltage is about 15V, much too high for the 5V max input either analog or digital input on the Mega.

So, you need something like a 3:1 voltage divider just to start with. The 'bottom' resistor on the divider will set the output impedance driving your analog (and digital) inputs, so this needs to be reasonably low (10K or so).

Before connecting the voltage divider to the Mega, look at the voltage divider output with your O'scope to verify the 'high' voltages are <= 5V. Then, and only then, connect the voltage divider output to the Mega with the O'scope still connected. If you see a big drop in the 'high' voltage, it means the Mega input impedance is loading down the voltage divider output, which means the voltage divider resistor values are too high - choose lower values (same ratio of course).

The specs for the Arduino Mega show a top speed of about 10,000 readings per sec, so your loop speed should be OK as long as adjacent millisec printouts are different.

I suspect you will find that the Mega analog input is loading down the signal.

  • The analog input of the Mega is basically a 14 pF capacitor. Not really a high load. Jul 11, 2023 at 20:55
  • Yeah, that sounds right, but even 14pf can form a low-pass filter if the output impedance of the 'diagnostic lead' is high enough. For sure something is causing a >5V signal to read like 2V. That's why I wanted to make sure the OP kept the O'scope connected when they connected the diagnostic lead to the Arduino analog input.
    – starship15
    Jul 12, 2023 at 1:40
  • 1
    The OP's data does not look like a low-pass filtered version of the expected signal. Besides, for an RC filter to have a large effect at this time scale you would need R ≥ 200 ms / 14 pF = 14 GΩ. Jul 12, 2023 at 18:54
  • I think you mean 14MegOhms? 200x10-3/14x10-9 = 14x10+6. I don't know about you, but 14MegOhm output impedance wouldn't be out of the question for a 'diagnostic lead'. I'm not sure how you came to the conclusion that the reported values "don't look like a low-pass output" - maybe you could elaborate on that?
    – starship15
    Jul 12, 2023 at 22:57
  • I mean 14 GΩ: a picofarad is 1e-12 F. Even 14 MΩ would be unusually high for a diagnostic port. Keep in mind that a typical scope has an input impedance of 1 MΩ. Re “don't look like a low-pass output“: here is what a square wave through an RC filter looks like. Nothing like the collection of spikes in the OP's data. Jul 13, 2023 at 7:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.