2
\$\begingroup\$

While using a logic analyzer with analog voltage to test Digital Output Pin voltages on an Arduino UNO, I am seeing the expected digital output and analog output (HIGHs and LOWs for digital and 5V to approx. 0V for Analog).

I'm using a Saleae logic 4 to test the digital output of an Arduino and an Arduino-compatible (Ruggeduino) for simple digital output. The Arduino seems to run my sketch just fine and the Saleae can read my output pin as both digital and analog. The moment, however, I drop the "Ruggeduino" in with the same sketch, my digital output seems to fail to work, and when I take another sample with the Saleae, my "Analog" voltage shows the highs and low voltages I'm expecting, but the "Digital" output is suspiciously blank.

Why would my logic analyzer show the expected digital and analog output when testing the Arduino Uno, but show a consistent "High" for digital output but both high and low voltages on the Analog output when testing the Ruggeduino?

Additional Information: Devices used:

Edit: Not satisfied to just sit and wait for someone to answer, I did some more digging. Here's what I found out:

  • The logic appears "High" despite the change in voltage, looking as if it's stuck High
  • The Analog voltage of "Low" for the output pins appears to be 1.586V, which falls outside the range of TTL "LOW" (and most likely the cause of the "stuck" logic level)
  • This only happens when the pins are connected to the downstream input pins that should only be listening for digital output. Once you remove the downstream pins from the equation, the "LOW" voltage drops back down to just above 0V.

I don't currently have a screenshot handy to upload, but I can upload my sketch to show what I'm attempting to do:

void writeWiegand(String);
int outZeroPin = 6;
int outOnePin = 7;
int led = 13;


void setup() {
  pinMode(outZeroPin, OUTPUT);
  digitalWrite(outZeroPin, HIGH);
  pinMode(outOnePin, OUTPUT);
  digitalWrite(outOnePin, HIGH);
  Serial.begin(9600);
  delay(1000);

}


void loop() {
  String code = "0001001001100101100000001011010010";
  writeWiegand(code);
  delay(500);


}

void writeWiegand(String code) {
  for (int i = 0; i <= (code.length() - 1); i++) {

    if (code.charAt(i) == '0') {
      digitalWrite(outZeroPin, LOW);
      //delayMicroseconds(100);
      delay(100);
      digitalWrite(outZeroPin, HIGH);
      Serial.print(code.charAt(i));
    } else {
      digitalWrite(outOnePin, LOW);
      //delayMicroseconds(100);
      delay(100);
      digitalWrite(outOnePin, HIGH);
      Serial.print(code.charAt(i));
    }
    //delayMicroseconds(100);
    delay(100);
  }
  digitalWrite(led, LOW);
  Serial.println(" Output to Wiegand");
}

Edit 2: The downstream device is a proprietary Access Control Panel, and the input pins are pins are for Wiegand communication with a card reader. Since it is proprietary, I'm not sure what I'm legally allowed to share. According to the manufacturer, the two input pins output 5V which the reader is supposed to Pull to ground to send information on either the "Zero" or "One" wire. The UNO R3 works fine for this task with the same code above. When pulling low with the Ruggeduino, there is still 1.586V left over, which I find confusing.

\$\endgroup\$
  • \$\begingroup\$ Interesting puzzle... (a) Adding links to the devices would help readers, otherwise you are forcing all readers to search for the same things :-) (b) Adding screen captures from the Salae software showing "good" (Arduino) and "bad" (Ruggeduino) digital and analog readings would also help. (c) You said: " "Digital" output is suspiciously blank " - do you really mean blank, or do you mean that the displayed logic level doesn't change e.g. stays "stuck" at logic 0 or 1? (d) Have you measured the actual Ruggeduino logic 0 and 1 voltage levels with something else e.g. multimeter or 'scope? \$\endgroup\$ – SamGibson Aug 8 '16 at 19:40
  • \$\begingroup\$ Thanks, Sam. i added more information above. I can see now why it's not being read as a LOW ( for some reason the board is outputting 1.568V as it's "LOW" signal), just not sure why the board might be doing that. \$\endgroup\$ – TheEmpireNeverEnded Aug 8 '16 at 21:21
  • \$\begingroup\$ Hard to say exactly. The downstream device isn't configurable, the pin is input by default, however, there is 5V voltage on this input pin, which the manufacturer states is entirely normal. The devices that are normally connected to those input pins ignore the 5V and pull the voltages low when required. \$\endgroup\$ – TheEmpireNeverEnded Aug 8 '16 at 21:27
  • \$\begingroup\$ Thanks for the answers to some of my questions. "for some reason the board is outputting 1.568V as it's "LOW" signal" - No, that voltage isn't being output, because as you explained: "This only happens when the pins are connected to the downstream input pins that should only be listening for digital output." Therefore those "downstream input pins" are where you need to focus your investigation. Please explain (and link to details about) that "downstream" device. \$\endgroup\$ – SamGibson Aug 8 '16 at 21:29
  • \$\begingroup\$ @SamGibson, Updated above in "Edit 2" \$\endgroup\$ – TheEmpireNeverEnded Aug 8 '16 at 21:40
4
\$\begingroup\$

Since it is proprietary, I'm not sure what I'm legally allowed to share. According to the manufacturer, the two input pins output 5V which the reader is supposed to Pull to ground to send information on either the "Zero" or "One" wire.

I suspect that they have a strong (i.e. low-value) pull-up resistor to +5 V on these "input" pins, and that is enough cause a significant voltage drop across the 220 Ω input protection PTC resistor on the Ruggeduino-SE, when the MCU attempts to pull that I/O pin low.

Ruggeduino I/O pin protection components:

Ruggeduino I/O pin protection

Source:http://www.rugged-circuits.com/ruggeduino-1

A quick calculation is that a 470 Ω pull-up to +5 V in the device, in conjunction with the 220 Ω input protection PTC resistor on the Ruggeduino-SE, would result in approx. 1.5 V at the actual Ruggeduino-SE "connector terminal" in the above diagram, when the MCU (i.e. "Microcontroller Pin" in the above diagram) tries to pull that pin down to 0 V.


To test this hypothesis, temporarily short (i.e. bridge across) the 220 Ω resistor for one of the output pins you are using on the Ruggeduino. That will directly connect the MCU pin, to the output connection terminal. See if the measured voltage at the output connection then drops to approx. 0 V for logic 0 output, when connected to this proprietary Access Control Panel input.

According to this Ruggeduino-SE page:

"If you do have an application where this built-in 220 ohm resistance is not wanted, you can easily change it. Every I/O pin has through-hole pins surrounding its PTC fuse that can be jumpered with either a wire for 0 resistance or with a standard resistor. Here is a picture showing how to bypass the 220 ohm PTC for pin D7."

Ruggeduino bypass 220R PTC

[Updated to refer to the 220 Ω resistor as a 220 Ω PTC resistor, as described on the Ruggeduino-SE according to the page linked in the original question.]


After a quick bit of research, it seems that devices using the Wiegand interface usually have open-collector outputs; have a pull-up resistor to some voltage, typically at the input device (that fits with the earlier hypothesis); the voltage for the pull-up resistors is sometimes +5 V, but sometimes higher.

Potential solution

More research would be needed (although out-of-scope for this specific answer), but based on what I have read, I would simply add open-collector drivers (either BJT NPN or MOSFET N-channel) to the two Ruggeduino outputs (i.e. the "Connector Terminal" pins) used for the Wiegand interface outputs.

In that way, the 220 Ω PTC resistors on the Ruggeduino are not in the external current path, and therefore they would no longer form a potential divider with the pull-up resistor in the external device. Using open-collector drivers in this way would allow the outputs to reach (close to) 0 V, and so would resolve the originally stated problem.

Note: Adding open-collector drivers would have the side-effect of inverting the polarity of the MCU output, i.e.:

  • MCU pin high = open-collector driver "on" = open-collector output low
    (the open-collector output is actively pulled toward 0 V)
  • MCU pin low = open-collector driver "off" = open-collector output effectively high
    (the output is not actively driven and is pulled-up by the external resistor)

This behaviour would need to be considered in the MCU firmware.

\$\endgroup\$
  • \$\begingroup\$ Nice call. Interested drawback of the ruggeduino \$\endgroup\$ – Scott Seidman Aug 8 '16 at 22:10
  • \$\begingroup\$ @Scott - Thanks, I'm not sure of this hypothesis, but it fits the currently available facts, and with a proprietary device, we're limited for more info. As you say, it's an interesting drawback of that input protection, when the pin is used as an output :-( \$\endgroup\$ – SamGibson Aug 8 '16 at 22:17
  • \$\begingroup\$ @SamGibson Thank you immensely! I have not yet been back to the office to test the theory via shorting the 220 Ohm PTC. Question: With the device I'm building, I'm trying to make it as plug-and-play as possible, so adding shorts or even Open Collector Drivers may not be the ideal solution for what I'm trying to do. Admitting that I'd be losing some of the benefits of the Ruggeduino, do you see a potential issue reverting to the standard UNO R3 for this purpose, assuming that the proprietary device is pulling up to 5V via a 470 Ohm Resistor? \$\endgroup\$ – TheEmpireNeverEnded Aug 9 '16 at 12:23
  • \$\begingroup\$ Shorting the 220 PTC brings the voltage down near 0V as hypothesized. \$\endgroup\$ – TheEmpireNeverEnded Aug 9 '16 at 17:18
  • \$\begingroup\$ @TheEmpireNeverEnded - You're welcome, glad you've confirmed the cause :-) Re: "do you see a potential issue reverting to the standard UNO R3" - personally I wouldn't do that, due to the lack of resilience for external electrical issues. I understand that it may work, but are long-term reliability and lack of field failures important? What if the pull-up voltage increases, as this page implies is possible? As a minimum, I would use open-collector drivers (and, if not using a Ruggeduino, add input power overvoltage mitigation). \$\endgroup\$ – SamGibson Aug 9 '16 at 18:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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