subscribe to our Youtube


14455 questions

17168 answers


0 members

We are migrating to our new platform at Moving forward, you can continue discussions on this new platform. This current platform will be temporarily maintained for reference purposes.
0 votes
249 views 7 comments
by anonymous

what is the minimum signal time when using trigger (e.g. high level) on digital IO (DIN2) to be sure the trigger is raised?

Currently it seems to be a (very) slow trigger - let's say input must be high for nearly a second to be sure for signal trigger.

The hardware could be do much faster.

I wrote a small script that will check the value of gpio19 (DIN2) every millisecond and that works but the trigger is not raised then.

Thanks for some timing information - would be great to see that in wiki, too.

1 Answer

0 votes
by anonymous

The DI frequency for the device to log the signal as low or high (change state) is about 1seconds yes.

It's not meant for short pulses
by anonymous
Thanks for the feedback, that's what I thought.

Is there any option to speedup the trigger frequence for 100ms or 50ms?

It is so boring to rewrite an existing software doing all we need just for this speedness.

Thanks for any hint to come on this.
by anonymous
Sadly, this is the nature of the DI that we use for that pin and it cannot be any faster. The only fast DI device we have is TRB2 series, there, I think the time is around 50ms for the input to trigger with a 50% duty cycle
by anonymous

How can I understand your answer?

The issue is not hardware related:

#!/usr/bin/env ash

# example trigger reader for input signals on DIN2 with 50ms frequency
while true
  # read gpio DIN2
  V=`cat /sys/class/gpio/gpio19/value`;
  # high signal is represented by 0
  if [[ "$V" == 0 ]]
    # message about active
    echo "on";
    # wait for releasing the signal
    while [[ "$V" == 0 ]]
      # micro sleep 10ms to lower the CPU usage
      usleep 10000
      # re-read the gpio
      V=`cat /sys/class/gpio/gpio19/value`
  # micro sleep for 25ms to lower CPU usage
  usleep 25000

by anonymous
The thing is that if the pulse is quite short, you run the risk of the input not being detected, the shorter the pulse the lower the probability of it being detected.

For a 100% detection, around 1 seconds of hold is required. If it so happens, that on a short pulse it was detected, great.

The low detection rate for slow pulses is related to the device hardware, in very regular pulses, you could detect maybe 4 pulses a seconds, with 50% duty cycle, meaning the pulse is on 125ms and pulse is of for 125ms.

Maybe RUT956 RUT951 be better at this because of the new chipset, I am not sure, we have not tested that
by anonymous

I put a pulse generator at the DIN2 and get pulses with duty 50% for 25ms with no leak currently.

Constantly reading 12 pulses per second
by anonymous
Okay, that's nice to hear, did you test on RUT9M or RUT9 firmwares?

Also, so what exactly is the issue right now that you're facing, that the I/O juggler is slow to reach to changes?
by anonymous
Currently were are on RUT 955 with latest Legacy 6.x firmware.

We are monitoring industrial machines (IIOT) and adding now counting of a process.

Depending on the machine speed, there are 1 to 12 counts per second signaled.

I have written my own service by now in GO which count the signals from gpio and forward to RUT MQTT broker.