Widgetlords Pi-SPi-8DI returns occassional bad result

[douglm]

Really just started on the raspberry pi (5) with a project to monitor my central heating system. Using pi4j 3.x snapshot

Asking this question in case I'm missing something obvious...

So far I've only got as far as monitoring temperatures and some of the zone valves and circulators.

My code (https://github.com/orgs/douglm-raspberry-pi/repositories) is just printing out the values every second adn i see the digital inputs occasionally change from true to false - never from false to true.

The board (https://widgetlords.com/collections/pi-spi-series-1/products/pi-spi-8di-raspberry-pi-digital-input-interface) takes 24v ac inputs - I wired one of them up to the 24v supply so it should be permanently true.

It's based on a MCP23S08 with TLP292-4 on each input.

Currently I have 2 boards on the same CS wit different hardware addresses - though I see the issue with only 1 board.
I initialize the chip with hardware addressing enabled, all ports input and uninverted.
Reading with the data transfer: 43 09 00
I get back as expected: "ff ff fe"
i.e. my 24v power is present.
Every so often - 14-30 seconds it returns "ff ff ff"
This appears to be a per-port issue - the next bit represents one of the zones and when that turns on I will see
"ff ff fc" with the occasional "ff ff fe" or "ff ff fd", i.e. one of the ports returns a 0 instead of a 1.

Checked my power appears ok with the advice here - https://gist.github.com/Paraphraser/17fb6320d0e896c6446fb886e1207c7e

The inputs are either 0v ac or very close to 24v ac. The board terminals are connected to the heating system via some cat5-e cable with sockets - so I can disconnect the whole thing. I couldn't determine what the minimum voltage is to be seen as a 0 but I'd be surprised if the voltage is dropping enough and apparently randomly.

[eitch]

Two questions:

• Can you pinpoint me to the relevant code?
• How long is the cable to the SPI device? Maybe it's just a random signal error on your cable. Maybe your cable is squeezed somewhere? Maybe you've got a grounding error? Those are all issues i've had in the past, albeit on an I2C bus, so not sure if it is relevant here.

[douglm]

I did wonder about noise but I've just had another thought:
The image below is a section of the schematic for the board. It's slightly incorrect in that the TLP292-4 actually has 2 back to back ir diodes.

From my unskilled reading of this it seems to me that the reading I get from the MCP23S08 depends on which part of the input AC cycle I'm on.

[eitch]

This schema is over my head =))

[douglm]

So - if my reading of the above I correct then either I need to make hardware changes (rectify + smooth the inputs or add something to the board) or address it with software.

Out of interest I wrote a small method read the chip every millisecond and write out when the input went low and how long since the last transition. With 60Hz input we get a zero transition every 8.333 millis. Running my code I get a transition on approximately 8 millisecond intervals. Here's a small segment of the output...

22:10:42,869 INFO  [Monitor] ---------- 25
22:10:42,877 INFO  [Monitor] ---------- 8
22:10:42,894 INFO  [Monitor] ---------- 17
22:10:42,902 INFO  [Monitor] ---------- 8
22:10:42,911 INFO  [Monitor] ---------- 9
22:10:42,927 INFO  [Monitor] ---------- 16
22:10:42,944 INFO  [Monitor] ---------- 17
22:10:42,952 INFO  [Monitor] ---------- 8
22:10:42,969 INFO  [Monitor] ---------- 17
22:10:43,002 INFO  [Monitor] ---------- 33
22:10:43,011 INFO  [Monitor] ---------- 9
22:10:43,027 INFO  [Monitor] ---------- 16

Turns out it doesn't see every zero transition but that might be timing. Most of the time it only returns one low result though I have seen up to 3.

My solution - not sure I like it much but it's cheap and easy - is to read the chip 5 times, 1 millisecond apart and OR the results - sort of digital smoothing. I ran that for a day or more and never saw a transient low (or at least my code never recorded any).

[eitch]

So I also use the Raspberry Pi to monitor I/Os, for movement of containers on conveyors, where i need to handle over 40 inputs and over 20 outputs. For this case i use these:

https://www.horter-shop.de/en/i2c-din-rail-modules/105-433-kit-i2c-digital-input-module-4260404260714.html#/26-terminals-plug_in_terminals/28-pcf_type-pcf_8574_a_adress_112_128

and there i can use interrupts to then read the input's state using I2C. This has always worked really well. In some cases if the interrupt is triggered really quickly, then sometimes the pi4j code misses it and for this case i have a watch dog, which actively reads the interrupt pin every few seconds to check if it was missed. This way i haven't had any issues with the conveyors for years.

One caveat: This is all still running on pi4j 1.4, i haven't upgraded to version 2 or 3 yet, this is still on my todo list.

So what i want to say, perhaps the SPI has some issues with the timings or something, i don't really know. I always prefer i2c i possible as i have never had issues there, unless the cable was really long and i had grounding issues. From students i've helped in the past, i have had quite a number of issues with SPI, so not really a fan. It seems to be a bit more finicky for those not very knowledgeable. And sadly my knowledge is not great when it comes to electronics.