inputs of DIO, DI modules: limitations and noise

[mezz]

Hi,

I was thinking of using the digital inputs of the DIO module (14 inputs) or the DI module (16 inputs) to monitor in a house whether a window/door is open/closed with standard alarm contacts.
For these digital signals the hardware configuration requires:

- long cables (say 30 meters at maximum)
- all the inputs are usually short-circuited since the windows/doors are normally closed

I have run some preliminary tests with a cat5 network cable 40m long and the signals seem stable.
In a house though with standard cables some inputs every 2-3 hours are kind of reset, they go to 0 for 1 second / 500ms and then come up again.

The questions are then:

- could this the effect be electromagnetic noise due to a 50Hz nearby network for instance? Is this 0 temporary signal a reset of the DI/DIO module or interference? could an ethernet cat5 cable be used as an input cable?
- what are the limitations with long cables? -if so long cables are not recommended is there a way around this? would a 24V pull-up used to invert the logic be of any help? As far as I know a 2,4 mA signal is expected on a digital input.

Thank you, regards

Enrico

[dirk]

Hi, please excuse my late reply. Could you measure the voltage levels on the DIO? Are you sure that they are sufficient as you use that long cables?
The zeroes on the inputs may be causes by PiBridge communication errors. Please check the "/var/log/kern.log" or provide it here.

[mezz]

Hi Dirk,

thank you for your reply, I have been struggling with this issue for a couple of weeks now and made some troubleshooting progress today. I would like to carry out one more test at this stage before saying something but maybe you can help me with the troubleshooting, I suspect the problem is related to the power supply, below is my configuration, perhaps you can confirm my suspicion.

Attached is the kern.log from today.

I have two issues actually:
1- the input pins of the DIO flicker from a high state 1 to 0 and back to 1 within milliseconds, this affects all the input pins of the DIO module in high state at the same time
2- upon restart the modbus master is not always refreshing the registers of 2 Arduinos connected via a USB hub, this happens say every third reboot of the RevPi Core 3. The serial devices are correctly mapped and I can look up the USB device details correctly, so it seems a missing connection between the Modbus Master of the piControl and the system devices.

But the nagging problem is 1 at present, 2 could be a subject for a different topic unless you would like to reply here as well.

Problem 1 is somehow related to this post: viewtopic.php?f=3&t=909&p=3825&hilit=di ... e%2A#p3825

My system uses:
- RevPi Core 3, the operating system is Stretch
- 2 DIO modules
- USB hub: https://revolution.kunbus.de/shop/de/in ... hub-4-port
- 60W power supply: https://revolution.kunbus.de/shop/de/ne ... -mdr-60-24
- the whole system power is supported by a UPS: https://www.apc.com/shop/bg/en/products ... BX1400U-GR

problem 1: the input pins of the DIO modules when they are in a high state (1) for days (short circuited) every 3-4 hours suddenly go to 0 and then back to 1 within milliseconds. This is detected via a software loop checking the input variables every 50ms. The same software system has been running with a RevPi Core 1 and 5 DIO modules for months in another place with no issues.

The DIO modules had firmware version 1.3 initially and the errors I was seeing in the kernel logs were:

Code: Select all

........
Sep 27 14:07:07 RevPi6733 kernel: [   14.856405] smsc95xx 1-1.1:1.0 eth0: hardware isn't capable of remote wakeup
Sep 27 14:07:09 RevPi6733 kernel: [   16.475928] smsc95xx 1-1.1:1.0 eth0: link up, 100Mbps, full-duplex, lpa 0xC5E1
Sep 28 23:40:11 RevPi6733 kernel: [26944.648122] NOHZ: local_softirq_pending 80
Sep 28 23:40:11 RevPi6733 kernel: [29059.219880] NOHZ: local_softirq_pending 80
Sep 28 23:40:11 RevPi6733 kernel: [34798.775392] NOHZ: local_softirq_pending 80
Sep 28 23:40:11 RevPi6733 kernel: [39330.000907] NOHZ: local_softirq_pending 80
Sep 28 23:40:11 RevPi6733 kernel: [45371.633423] NOHZ: local_softirq_pending 80
Sep 28 23:40:11 RevPi6733 kernel: [63798.620850] NOHZ: local_softirq_pending 80
Sep 28 23:40:11 RevPi6733 kernel: [74975.638637] NOHZ: local_softirq_pending 80
Sep 28 23:40:11 RevPi6733 kernel: [78902.707030] NOHZ: local_softirq_pending 80
Sep 28 23:40:11 RevPi6733 kernel: [90381.806193] NOHZ: local_softirq_pending 80
Sep 28 23:40:11 RevPi6733 kernel: [93704.707449] NOHZ: local_softirq_pending 80
Sep 28 23:40:11 RevPi6733 kernel: [120799.562166] piControl: too many communication errors -> set inputs to default 0 0 11 0   0 0 0 0
Sep 28 23:40:11 RevPi6733 kernel: [120799.582178] piControl: too many communication errors -> set inputs to default 0 0 12 0   0 0 0 0
Sep 28 23:40:11 RevPi6733 kernel: [120799.602220] piControl: too many communication errors -> set inputs to default 0 0 13 0   0 0 0 0
............

After an upgrade to firmware version 1.4 the logs have disappeared but I have started seeing this random signal flickering reading the DIO input variables.
Now I am tracking the changes via logs and this is an example, the "v:1" actually means that the DIO input pin is not short circuited, the logic is inverted because it is a door alarm signal.
The first lines are wrong readings of 1-wire sensors connected to the Arduinos (2 Modbus Masters in piControl).
This shows that within a second there is a signal degrade, probably voltage, and this affects both the Arduino readings and the DIO input pins.

Code: Select all

ERROR: 2018/10/24 21:37:52.386519 switchedmapper.go:79: error reading pin temp_3, continue to next, error: invalid temperature read 508.453125, temperature above DS18B20 maximum 125.000000, check the wiring
ERROR: 2018/10/24 21:37:52.386695 switchedmapper.go:79: error reading pin temp_4, continue to next, error: invalid temperature read 414.992188, temperature above DS18B20 maximum 125.000000, check the wiring
ERROR: 2018/10/24 21:37:52.386934 switchedmapper.go:79: error reading pin temp_4_split, continue to next, error: invalid temperature read 414.992188, temperature above DS18B20 maximum 125.000000, check the wiring
INFO: 2018/10/24 21:38:04.335064 trigger.go:79: IO activity, pin={props},...:
I_1_i05={"v":1},I_2_i05={"v":1},I_4_i05={"v":1},I_5_i05={"v":1},I_6_i05={"v":1},I_7_i05={"v":1},I_8_i05={"v":1},I_9_i05={"v":1},I_10_i05={"v":1},I_11_i05={"v":1},I_12_i05={"v":1},I_13_i05={"v":1},I_14_i05={"v":1}
INFO: 2018/10/24 21:38:04.534765 trigger.go:79: IO activity, pin={props},...:
I_1_i05={"v":0},I_2_i05={"v":0},I_4_i05={"v":0},I_5_i05={"v":0},I_6_i05={"v":0},I_7_i05={"v":0},I_8_i05={"v":0},I_9_i05={"v":0},I_10_i05={"v":0},I_11_i05={"v":0},I_12_i05={"v":0},I_13_i05={"v":0},I_14_i05={"v":0}

My suspicion is that there is a faulty power supply but correct me if I am wrong, I have tried replacing different parts of the system so far with no luck:
- 24V power supply
- cables, which have been tested separately on another RevPi with 40m of Cat5 ethernet cable and displayed no corrupt behaviour
- removed all door sensors and short circuited the cables
- replaced the DIO modules
- checked all the wirings
- measured the voltage input at the DIO input pin, it was 24,2 V with the long cable connected. The current was about 2,46 mA

The only two tests I am left with:
- replace the UPS
- replace stretch with Jessie

My questions to get some troubleshooting help please:


- if it lies on the UPS why is the RevPi Core 3 up an running all the time and there are no kernel errors? Just the DIO inputs seem to fail
- could it be that the voltage of the main input power of the DIO drops at so low a value that the input chip of the DIO undergoes a fault state? I think this is the chip you are using: https://datasheets.maximintegrated.com/ ... X31913.pdf
So this could be the reason why all the input pins in a high state go to 0 altogether at the same time.
- if I downgraded the system to Jessie would firmware 1.4 be supported at all on Jessie, which according to my investigation supports 1.3 at maximum?

As for problem 2, the missing modbus master resync on reboot is less troublesome but still nagging because I need to tell the customer to try to shut down and switch on the system with "brute force" being not physically there.

I suspect both issues are my bad be the way but I am making little progress and debugging takes up plenty of time.

Thank you indeed

Enrico

[mezz]

Hi Dirk,

I replaced the UPS as well this morning and the problem still occurs.
The only candidate I am left with is the RevPi Core 3 Stretch version, I am going to replace it with a working Jessie version I have been testing separately and which is known to have no such issues.
Let's see how it goes, another user fixed this kind of problem by downgrading to Jessie, probably with a different version of the piControl driver.

Unless you have other suggestions I am going to do this, the question is though:
can I use version 1.4 of the DIO modules with Jessie or do I need to flash the old firmware 1.3? If required how would I do that please?
Jessie won't probably allow me to update the 1.4 DIO firmware with a piTest -f I guess.

Problem 2 with the modbus master RTU with a USB hub remains on reboot.

Thanks

Enrico

[Mathias]

Hi Enrico,
DIO V1.4 should also be working with Jessie.
I am setting up a test rack to reproduce your problems with the inputs going to 0. Please give some time to investigate that.

Modbus: Maybe your USB-Serial-Adpaters are initialized after the modbus master is started. Could you send me the kern.log and daemon.log files after a boot where it did not start?
It should be working after a call of 'piTest -x'. This also restarts the modbus master.

Mathias

[mezz]

Hi Mathias,

thanks I'll try a downgrade to Jessie in the meantime since I need to rely on the system stability as soon as possible.

The attached logs in the previous reply contains both reboots:

The failing one is from line:

Code: Select all

Oct 24 19:44:16 RevPi6733 kernel: [    0.000000] Booting Linux on physical CPU 0x0

The working one is the second reboot from line:

Code: Select all

Oct 24 20:10:36 RevPi6733 kernel: [    0.000000] Booting Linux on physical CPU 0x0

I tried several times to reset the driver with a "piTest -x" with no success, only a reboot seems to have effect.

The daemon log for the same time span is attached.

Thank you

Enrico

[mezz]

Hi Mathias, Dirk,

I replaced the RevPi Core 3 with Stretch with one running Jessie and both issues have not shown up in the last four days, previously on Stretch I could spot 0 inputs every couple of hours.

I have been running the Stretch RevPi separately and I could reproduce problem 2 at least: the modbus communication loss on reboot, this is definitely related to Stretch or the piControl version coming with it.

As for the most troublesome issue problem 1, Jessie runs perfectly up till now on the live environment, but it is hard to replicate the same hardware separately and I have not seen it appearing on the Stretch RevPi in stand-alone mode, I am not using the same DIO modules and virtual modbus RTU masters though. I double checked all the wiring on the live hardware as well.

Since other users fixed the issue by downgrading to Jessie I am not the only one experiencing this, it would be good to understand why: if it depends on the number of modules installed, if the system is less resilient to noise, if it is related to piControl etc. because when this problem happens it wreaks havoc.

I downloaded Stretch from the official online repository.

Please let me know when you have any news, until then I will stick with Jessie.

Thanks

Enrico

[mezz]

Hi Mathias,

is there any news regarding the 0 reads of DIO modules and the modbus master connection loss upon reboot on Stretch?

Cheers

Enrico