Question

Hi,

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.

Answer 1

Hi,

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

Comments

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.

---

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

---

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 do   # read gpio DIN2   V=`cat /sys/class/gpio/gpio19/value`;   # high signal is represented by 0   if [[ "$V" == 0 ]]   then     # message about active     echo "on";     # wait for releasing the signal     while [[ "$V" == 0 ]]     do       # micro sleep 10ms to lower the CPU usage       usleep 10000       # re-read the gpio       V=`cat /sys/class/gpio/gpio19/value`    done   fi   # micro sleep for 25ms to lower CPU usage   usleep 25000 done

---

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

---

Curios

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

---

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?

---

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.