Issues with I/O Flickering in noisy environments

Hello Particle Community,

I made a prototype device, using the B404X SoM dev kit, for a customer that simply turns on/off a SSR relay to larger load, and it works perfectly for me, but it stutters on first boot up and on first toggle command for my customer.

My customers device was placed in a much noisier environment than mine, and has lower cellular service than i do, so I was wondering if anyone had similar issues regarding this?

Below is the code that works perfectly for me, but creates a stuttering phenomenon for my customer:

int relay = D4;
int relayState;

unsigned long lastTime = 0;

void setup()
{

   pinMode(relay, OUTPUT);

   Particle.variable("relay_state", &relayState, INT);
   Particle.function("contactor_relay_new", relayToggle);

   digitalWrite(relay, LOW);
   relayState = 0;

}


void loop()
{
}

int relayToggle(String command) {

    // get the current time
  unsigned long currentTime = millis();
  // check if the function was called less than 5 seconds ago
  // if we called this function less than 5 seconds ago, we will ignore this request
  if (currentTime - lastTime < 5000)
  {
    // if it was, return 0 without doing anything
    return 0;
  }
  else
  {
    // if it was not, update the last time and toggle pin accordingly
    lastTime = currentTime;

    if (command == "on")
    {
      digitalWrite(relay, HIGH);
      relayState = 1;
      return 1;
    }
    else if (command == "off")
    {
      digitalWrite(relay, LOW);
      relayState = 0;
      return 1;
    }
    else
    {
      return -1;
    }
  }
}


You can notice in my code, that I won't even toggle the relay pin if it received the same command less than 5 seconds ago, so it's not an issue of a bunch of toggle commands being stored in a cloud buffer and then being sent to the device in a rapid fashion; this must be something hardware wise, but not sure what exactly could be causing this.

This is what my crude prototype looks like:

The I/O wire (orange) and Relay GND wire (blue) is rather long, so I can see it capturing noise to changing the logic level, but do you think this would enough length to cause such an issue?

This is the problem my customer was having:VID_20230529_190402.mp4 - Google Drive

The video was shot before I implemented the 5 second max frequency toggle, but the same stuttering experienced in the beginning of the video still happened, so that didn't fix it.

Any assistance on this would be greatly appreciated!

Thank you,

Nicolas

Seems like some value is floating until stabilization is reached.

What mA does the SSR need? You can try raising the current of the D4 from 2 mA to 9 mA with this command:

// PROTOTYPE
int pinSetDriveStrength(pin_t pin, DriveStrength drive);

https://docs.particle.io/reference/device-os/api/input-output/pinsetdrivestrength/

void setup()
{
   Particle.variable("relay_state", &relayState, INT); // moved these two lines up in setup()
   Particle.function("contactor_relay_new", relayToggle);

   pinMode(relay, OUTPUT);
   int errorCode_relay = pinSetDriveStrength(relay, DriveStrength::HIGH); // added this line

   digitalWrite(relay, LOW);
   relayState = 0;

}

@nicolasmontoya:

  1. If possible, bring the transistor closer to the dev board
  2. Do you have a current limiting resistor on the base of the transistor?
  3. What transistor are your using?
  4. What SSR are you using?
  5. If you ground the SSR input wire (disconnected from the transistor), does it latch and not stutter?
1 Like

Hi Rob,

The SSR requires around 10 to 20 mA, since it's effectively a photodiode with TRIAC, so i am using a NPN BJT to amplify the current, but i can also try increasing the base current to the BJT via this command. It may not make a difference for me but maybe for my customer?

I find it annoying that the pins source a pathetic amount of current, like 9mA for "High" drive strength? Why is it so low? Arduino's can source up to 40 mA... I guess I should have use NMOS to begin with...

Hi peekay,

I can bring it closer, that could help, and yes I have a 1k resistor limiting current to the base, so I shouldn't be trying to source too much current.

I am using a 2N2222

The SSR is from OMRON, this is the link to it: https://www.amazon.com/gp/product/B07L6CFZLL/ref=ppx_yo_dt_b_search_asin_title?ie=UTF8&psc=1

Yes when I directly ground the SSR without going through the transistor, it latches fine. It also latches fine for me going through the transistor, just stutters when i send it to my customer.

So it must be something in the environment that's causing it to teeter on the edge of working / not working?

Hey @nicolasmontoya , I think the stutter at boot up might be the IO toggling. I read about this for other Particle devices when they boot up. Cab you put a scope on the IO?

Is your setup identical to the customer's, with the looong wires?
Is it possible to use your setup at the customer's?

Similar to what @peekay123 said, put the BJT and base resistor at the SSR and run a coax wire from the Boron to the BJT.
Make sure there is a good ground connection between the power supply for the SSR and the Boron board.

1 Like

The device that your customer has: did you wire it or did someone else wire it? Perhaps it would be a good idea to double check all connections on that (remote) setup?

Make sure that Ethernet detection is not enabled on the devices. If enabled, D5 gets toggled at boot. Normally D4 would be an input, but if you are using the Particle M.2 SoM eval board and the jumpers are installed the W5500 will toggle the D4 pin. The setting is stored on the B Series SoM, and the initial state may depend on how the device was initially set up. It's probably a good idea to disable the feature flag in your firmware to make sure it's off. The symptoms don't completely fit your scenario but it's worth looking into just in case.

4 Likes

That's a good point... Can you point me to the documentation that shows how to disable this feature? Are there any other features I should disable on the B SoM when i make my own PCB for it? The product will always be connected to mains power, and I won't need ethernet or BLE, just cellular.

Thank you

My customer wired it up, I did suggest that the wiring could have been loose because when the contactor switches, it does vibrate a good amount, so it could have joggled the wires loose, but he insisted he tightened them down properly

That's a good idea, i will scope it out when I have time and see what's going on.

Yes, this was sent to my customer and used in similar fashion, so it is the same wire length.

Perhaps an NMOS would be more suitable for this than a BJT? Especially with the low current capabilities of the B SoM?

Hi @nicolasmontoya

I think you need to figure out if the problem is coming from the Particle board, or from the transistor and wiring directly. A scope would tell you quickly.

Shorter wiring and shielding, as has been mentioned, is a good idea--just don't block the antenna on the Particle SoM.

I would also recommend a snubber of some kind on the output of the SoM before the base of the NPN transistor. Maybe a 1kohm series resistor that I think you have plus a capacitor to ground at the base of the transistor. The value here is hard to choose without knowing more about the noise but certainly try values from 0.1 to 5uF. Watch the polarity if you use an electrolytic--the transistor base is positive. You could also try a series choke but I would start with the RC network as a snubber.

2 Likes

I had something similar happen in a very noisy environment and the first step was exactly what @bko mentioned. For me, the culprit was noise from the control wiring. Shielded cable (grounded at only 1 end) fixed the issues for me. But we'd expect the problem to occur even after the BSOM startup if it's purely environmental noise (unless the control wire is picking up BSOM modem noise, etc, related to Startup).

It seems reasonable that Scoping the Pin with and without the control wiring would point you in the right direction/suggestion to know if the issue is "on-board" or external.

2 Likes

This is good advice from @Rftop. As is the grounding the cable shields at one end only.

Another thing people forget to check is conducted noise on the power supply. If this is in a location where there is a lot of high power switching going on, spikes and noise on the incoming power line can be a big problem. You can scope the power supply outputs and even try using an isolated battery to supply SoM to check.

I would also normally recommend looking for ground loops but I don't think the opto-isolated relay should care about that. In general you want to think hard about the points that join the low-voltage, low-current parts of the system and the high-voltage, high-current parts. Those points include both the control signals and their respective grounds.

5 Likes

This topic was automatically closed 182 days after the last reply. New replies are no longer allowed.