Problem with PR16-10-5A

Hardware
1

I have a “1-Channel General Purpose SPDT Relay Shield + 7 GPIO with IoT Interface” that has been in production with an embedded Particle Photon 2 without issue for a few years. The assembly is used to control a water pump as a function of a float switch in a storage tank. The application uses only a single GPIO terminal to monitor the float switch (the relay is not used).

Last year I bought a second unit to use as a test bed. Like the production unit, the new one also has an embedded Photon 2. Today I flashed that Photon with the exact same firnware that is running without issue on the production system in order to test some enhancements to the application before formal deployment.

In the process and before any changes to the firmware and with nothing connected to any GPIO terminal, I discovered that GPIO #3 always shows a closed circuit, i.e. the command “controller.readInputStatus(3)” always returns a “1”. All the other GPIO’s return “0” as expected. But the mystery continued when I could not get any of the other terminals to return a “1” when I connected each of them to either of the two ground terminals. In other words, none of the GPIO terminals is working as designed. One always returns "1’ and the other 6 always return a “0” regardless of any wiring connections or a complete absence thereof.

So the question: should I conclude that the relay shield is defective or is there something obvious to others - not to me - that would explain this behavior? I thought that it might have something to do with the Photon so I swapped it with another, brand new one and the issue persists.

Any fix short of replacement that anyone can suggest?

2

Hey Brian,

I hope you are well.

The only reasonable explanation to what you are describing would be that the IO lines on the MCP23008 are damaged in some way. However this is very untypical. I have not seen this in the past. Typically the MCP23008 is either functional or not. If you are able to communicate with it then it should work.

There really is no circuitry between the Screw terminals connected to the 7 IO lines on the MCP23008. The inputs are internally pulled high or low. If you pull them up via the I2C register that controls the input direction then connecting the terminals to Ground would set the input to 0 or 1 when not connected to Ground.

This really feels like a firmware issue in some way to me. I just can’t see the hardware failing in the specific way required to result in what you are describing.

Thanks Brian,
Travis

3

All well here Travis (for a guy now officially older than dirt).

I doubt it is firmware since, as mentioned, the firmware is the exact same file that runs fine on an identical relay shield & Photon setup.

As also mentioned, I’ve tried two Photon 2s. One has device OS 6.3.4 and the other Device OS 6.3.3.

When you say “If you are able to communicate with it …”. I can communicate with the Photon(s) of course, but I don’t know how to communicate with the MCP 23008. Can you clarify? BTW, my code includes this snippet:

if ( millis() > lastReset + 3600000 ){ // Reinitialize the MCP23008 chip on the NCD relay board every hour
controller.setAddress(0,0,0); // Reinitialize the MCP23008 chip on the NCD relay board
lastReset = millis(); // Reset last initialization time to current program time
}

Screenshot 2025-12-03 at 10.35.42
Screenshot 2025-12-03 at 10.35.42582×998 62.3 KB

4

Hi Brian,

You have a working setup at the well currently. Would it be possible to take this new board to that setup, swap the photon from the working setup into the new board and see if everything works? This would definitively tell us if there’s an issue with the hardware or not.

Thank you,
Travis Elliott

5

I sure wish I could Travis but it is 300 miles away!

One addiitonal note: although I know very ittle about how to use a multimeter, I have one and I measured the resistance/ohms between each of the two ground terminals and each of the GPIOs. GPIOs 2, 3, 5, 6 and 7 show open. GPIOs 1 and 4 return a value but I don’t know how to interpret them.

One more BTW: I think I have mentioned this before, but the GPIO labeled 4 is addressed in firmware as GPIO 3. Here’s a photo of the production system. You will note that the white wire is connected to #4 but my firmware “knows” it as #3. That therefore seems to explain why my meter shows #4 not open on y test system and my firmware returns a “1” from #3.

if (millis() >= lastPublish + publishInterval){ // If it’s been 15 minutes since last publish
int status3 = controller.readInputStatus(3); // Read input terminal 3; this is the production input
Particle.publish(“Tank”, String(status3));
}

IMG_4010
IMG_40101920×2551 532 KB

6

The confusion with the GPIO lines is because GPIO 0 is driving the relay while GPIOs 1-7 are exposed on the screw terminals.

Without putting my hands on the board and testing it’s hard to say what could be going on.

Are you able to turn the relay on and off?

What library are you using? Our old NCD1Relay library on Particle or something else?

7

NCD2Relay.h
I’ll try the relay; stay tuned.
If push comes to shove, I can send the board to you for testing. since my developent efforts aren’t time critical.

Oops; if you saw my previous post that said the relay didnt work, ignore. I had copied to the Photon the code that I have running on a Boron. The Boron is on an NCD relay shield that has two relays. I am using relay #2 for that application, so my code referenced relay 2. When I copied it to the Photon I neglected to change the reference to relay #1. Once I corrected that error, I am easily able to operate the relay on the suspect board.

IMG_0057
IMG_00571920×2560 467 KB

8

Great. So everything is well then? Inputs are working as expected as well?

Thank you,
Travis

9

No. Inputs still not working.

10

Interesting. It sounds like the direction is not being set correctly or the inputs are not being pulled high. If you are able to toggle the relay on and off though I would say the board is perfectly fine.

Set your volt meter to measure DC voltage. Put the black Lead on one of the GND terminals. Then connect the Red lead to GPIO 1. You should read 5VDC, possibly 3.3VDC. Let me know what you see.

If you see no voltage then switch your meter to continuity. Let me know if it beeps.

If you do not see continuity and the voltage reads 0VDC try loading in the 2 channel relay firmware and turn relay 2 on and off. This should set GPIO1 as an output and it should go to 0VDC when off and 5VDC when on or vice versa.

Let me know what you find.

Thank you,
Travis Elliott

11

Interesting!

Voltage wanders around 5.

If it would be of any value Travis, I can give you my login credentials to my Particle account and you can play around with the thing to the extent that you can learn anything about the shield indirectly via the Photon and the firmware running thereon.

12

Update @ 21:00 EDT:

I strapped ground to the terminal labeled “GP2” which is addressed in firmware as GPIO 1 and to the terminal labeled GP7 which is addressed in firmware as GPIO 6. GPIO 1 and 6 both show high as I would expect but GPIO 3 still shows high as it has - erroneously - all along.

Screenshot 2025-12-04 at 21.32.29
Screenshot 2025-12-04 at 21.32.29596×834 52.3 KB

FWIW, here’s the code that has been running without error on the production Photon for a couple of years at least:

// This #include statement was automatically added by the Particle IDE.
#include <NCD2Relay.h>

NCD2Relay controller;

SYSTEM_THREAD(ENABLED);

String data = String(10);

int status1;
int status2;
int status3;
int status4;
int status5;
int status6;

int publishInterval = 900000; // 15 minutes
int lastPublish = millis();
float lastReset = millis();
bool Restart = true;

void setup(){

waitUntil(Particle.connected);
controller.setAddress(0,0,0);
int status = controller.readInputStatus(3); // Read input terminal 3
lastReset = System.millis();

Particle.variable(“GPIO1”, status1);
Particle.variable(“GPIO2”, status2);
Particle.variable(“GPIO3”, status3); // This is the production input
Particle.variable(“GPIO4”, status4);
Particle.variable(“GPIO5”, status5);
Particle.variable(“GPIO6”, status6);

}

void loop(){

if ( millis() > lastReset + 3600000 ){ // Reinitialize the MCP23008 chip on the NCD relay board every hour
controller.setAddress(0,0,0); // Reinitialize the MCP23008 chip on the NCD relay board
lastReset = millis(); // Reset last initialization time to current program time
}

if ( Particle.connected() ){
if ( Restart == true){
Particle.publish(“Restart”, “Photon restarted”); // Send status to log
Restart = false;
}
}

status1 = controller.readInputStatus(1); // Read input terminal 1
status2 = controller.readInputStatus(2); // Read input terminal 2
status3 = controller.readInputStatus(3); // Read input terminal 3;this is the production input
status4 = controller.readInputStatus(4); // Read input terminal 4
status5 = controller.readInputStatus(5); // Read input terminal 4
status6 = controller.readInputStatus(6); // Read input terminal 6

if (millis() >= lastPublish + publishInterval){ // If it’s been 15 minutes since last publish
Particle.publish(“Tank”, String(status3));
}

lastPublish = millis();

}

13

OK Travis, at this point I think I have incontravertible proof that this relay board is defective relative to GPIO 3. However, the other GPIOs seem to be behaving. Since my application only needs one I/O port, I am willing to cease any further efforts to fix the unfixable and move my application to a different port.

14

Good to know Brian. That is a pretty rare thing(for one GPIO to be non functional with all others working as expected) But in the world of electronics almost anything is possible.

Keep me updated and let me know if you need anything.

Thank you,
Travis Elliott

15

As always, I appreciate your assistance. Since yesterday evening I have been running all kinds of experiments and testing using the other GPIO ports and so far no issues of any kind. I’ll just have to be careful to never address GPIO 3 again.