Raspberry Pi Zero W -- bookworm -- Node-Red 4.0 -- GPIO problem

[GeorgeX]

Hi, i am running following system:

Raspberry Pi Zero W, Rev 1.1, 1GHz, RAM 512MB
ARMv6-compatible processor rev 7 (v6l) 32Bit

Connected to the raspberry is a mix of wired and wireless sensors. The system is running fine since some years. So no bad wiring, no loose connections...

I upgraded now form Bullseye to Bookworm, from Node-Red v2.1.4 to v4.0.5, from Node.js v14.18.1 to v20.18.0. .....one flow with approximately 690 nodes.....mosquitto, grafana, influxdb...

The new system works fine with latest Node-Red....BUT there is a BIG problem with the GPIO pins!

One symptom, one of the three Ds18B20 sensors (the one on the longest wire connection) loses connection after some hours. Node-red-contrib-sensor-ds18b20. Complete reboot it's there again...

The other problem is with the node-red-node-pisrf. The values it delivers are way off. On the old system I get accuracy within 10mm. On the new system the values are way off in the range up to 80cm!! On top of that I recognized, if I change settings of the node and use deploy, it loses the connection as well. Connection comes back only after complete raspberry reboot.

I can repeat that behavior by swapping just SD-cards old to new system. So no touching or tinkering with the wiring.....

So, that's obviously a software problem....RPi.GPIO package bookworm...node-red-node-pisrf....and node-red-contrib-sensor-ds18b20......Any ideas ?

[dceejay]

Make sure you backup the old card !
Personally unless I had good reason to I would stick with the old one. If it ain’t broke don’t fix it !
Official builds for v6 32 bit nodejs stopped a while back so there may have been compromises made to make it work. Also latest piOS changed the way IO was handled, so those two combined along with the low power processor may mean things start to go astray.
Net is that some hardware and software are just better matched - I’d stick with the old unless you really need to upgrade.

[Colin]

Do you mean nodejs and the OS? The node red upgrade should ok should it not?

[dceejay]

It should all be OK - by some definition of OK.
It does run - but there may well be compromises having to be made to keep things basically running. Eg like running latest desktop on a Pi 1. At some point it will struggle. Or a bit like running OpenCore Legacy Patcher on an old Mac... it works... but... it lags... and timing will be the first thing to go...

[iiot2k]

Maybe that has nothing to do with the topic. Today I worked with a RPi Zero W 32bit OS and tested my nodes. You really need a lot of patience to work with it. Some nodes also worked incorrectly on 32bit. You have to change the nodes for 32bit. Therefore, as I mentioned in my previous post, I decided to only make my nodes available for 64bit OS. This may annoy some users, but for me the effort of testing the nodes for 32bit and 64bit on different Raspi models is simply too much.

[GeorgeX]

Dceejay thank you for your swift response ! It's exactly like you said. Maybe it starts with a timing issue somewhere...

Node-Red v4.0.5 / Node.js v20.18.0 "works to an extent" on a Rpi Zero W, Rev 1.1, ARMv6 32Bit SoC BCM2835 with Debian v12 bookworm.

I would add = “works” as long as you OLNY use simple I/O on pins. In this case it's fine.

But to me it looks like there is a PROBLEM with older SoC BCM2835 when you need more sophisticated hardware peripherals as serial ports, I2C, SPI, DPI, PWM. As Dceejay mentioned, Raspberry changed the kernel to drive GPIO pins, when they moved from bullseye to bookworm. The kernel interface for gpio access changed from library gpio to lgpio….and so on….. For me node-red-contrib-sensor-ds18b20 "works to an extent" (problems with sensors on wire >12m) and node-red-node-pisrf (serial connection) delivers complete OFF values. By “off values” I mean, values are returned but with so many outliers that filtering becomes impossible.

Example for node-pisrf and measuring distance of exact 50 cm:

Bullseye & Node-Red v2.1.4 / value stream = -50.0 / -49.4 / -51 / -49.7 / -49.2 / -50.0… Mean value -49.88 cm
Bookworm & Node-Red v4.0.5 4 / value stream = -50 / -82.4 / -73.2 / -68.2 / -22.3 / -49.8... Mean value -57.65 cm

I use node-red and my system since 2019 (24/7/365 in very stable condition) dedicated to building engineering physics. Serial, 1-Wire bus, mqtt, grafana, influxdb, pilight.... For now, I will not upgrade Rpi SoC BCM2835 from Bullseye & Node-Red v2.1.4 to newer versions because that works just almost for me I have tested this extensively…with and without the whole kit and caboodle of other nodes … If I find a solution, I will post it.

KEEP UP THE GOOD WORK ON NODE-RED. IT’s AWSOME !!!

[iiot2k]

I have also noticed that the time functions sometimes do not work properly with 32bit.
I wanted to know why and found out the following:
In Linux there is a function (C/C++) called clock_nanosleep and it is used as follows:

timespec ts;
ts.tv_sec = sec;
ts.tv_nsec = nsec;
clock_nanosleep(CLOCK_REALTIME, 0, &ts, NULL);

The function works perfectly with 64bit, sometimes with 32bit.
The pitfall with 32bit is that the data type of ts.tv_nsec is 32bit (signed).
There is an overflow with large numbers and the function does not work as expected.
32bit has other pitfalls too.

[Colin]

@iiot2k

time functions sometimes do not work properly

What issues does that give in node red?

[iiot2k]

I can of course only speak for my nodes. Parts of the nodes are written in C++ and these errors occur there. The core of node.js is also written in C/C++, such as lib_uv. I think this problem exists there too. It is very time-consuming to test everything for 32-bit and 64-bit OS. Node.js has also ended support for Windows 32bit Node.js — Node v23.0.0 (Current) . It is also possible that support for Linux 32-bit will be ended.

[GeorgeX]

Thank you very much for your contributions!

I read your comments, thought about it and spend a lot more time more testing this.

Rpi Zero W 32Bit is on the very very low end of computing power. But if you get everything right, you can run surprisingly big systems on it, with very very low energy consumption. My Rpi setup is headless SSH (no Wayland), turned off Bluetooth radio, hdmi socket off, gpu_men=16….with now 700 nodes.

When I tried to update to Rpi Bookworm, Node-Red v4.0.5, Node.js v20.18.0…I had problems with node-red-contrib-sensor-ds18b20 and node-red-node-pisrf.

I want to be fair to Raspberry - Node-Red - Node.js unofficial-builds project (officially Node.js stopped to support ARMv6 as of Node.js 12).

I can finally confirm: YEAH IT WORKS !!!

For all experts, it's boring and case is closed.
Maybe Santa will drop of Rpi Zero W 2 64Bit

For everyone with similar problems, what did I do and how did I debug this ?

DS18b20 sensor: I exchanged SD cards for and back. New system - old system, checking settings in raspberry bullseye, node-red config…..until I recognized…..I am losing connection to this specific sensor on the old software system now as well. Murphy's law... . I replaced this sensor….problem solved.

Node-red-node-pisrf, that’s a longer story.

On a long wire (>15m) I am running one of these JSN-SR04T v2 ultrasonic sensor modules. This module is known to be “difficult” (physical sensor position, reflections of ultrasonic sound in thigh spaces, wide sensor beam….) From 3 possible modes, I use the standard mode. To trigger a measurement, Pisrf has to send a very short burst of signal on one wire, while it is listening on a second wire for a result. If this interval of triggering a measurement is not happening in a regular interval, it will produce more outliers and a very high number of just faulty measurements, which can’t be filtered out.

So, first I decided to send a longer trigger signal and changed line 32 in nrsrf.py of the PiSrf library. I am not sure if that is beneficial to the communication between Rpi and the module but since it’s mounted on a long wire, I just tried to give it a “better” signal (…wire resistance, signal flanks…)

Then I used command ‘top’ on Rpi, to watch info’s about the running OS system.

First line to the right: “load average”. That's where you should look first.
Three values for average CPU load of 1min/5min/15min. You can find a complex Linux definition… very simple imagine a row of cars, going bumper to bumper over a bridge. No car has to break. Speed of all cars is 1GHz. That’s the speed of the RPi Zero W CPU. The value would be 1.0. A value below 1.0 means light traffic with bigger distances between cars. If you see higher values than 1.0, that’s heavy traffic. A value of 2.0 means, while one car is passing over the bridge, a second car has to wait until the first car has passed the bridge. You are looking at a backlog. Speed is still 1Ghz but cars (processes on your CPU) have to wait until they can “pass the bridge”. No immediate breakdown, because traffic is going up and down. But still, the timing of these processes running on your CPU are influenced by a delay. If you just turn a single gpio pin to high, in most cases, it doesn't matter if this happens 25ms later. If you have connected a device, which expects signals within a specific time frame, this delay will cause problems.

I recognized higher average loads. ( simple: 3.0 is HEAVY traffic…all over 5.0 is critical…7,9,12 you can pull the plug, your Rpi might be frozen and not recover from that...)

How to find the source of high workload?

Disable flows/nodes on your workspace and watch if short time load average is going down. If not even by a tiny bit, disable a different group of nodes. Search your workspace systematically. It’s a time consuming and subjective process. I found a “bad” gpio-out-node, causing higher traffic and I replaced this one. I checked all my JavaScript code in function nodes. Is there something marked red...deprecated or obsolete code language because of updates...

Lower load average = better timing I saw subjective less outliers returned by node-pisrf.

To support this further, I changed node-red-pi --max-old-space-size=256 to 128. Garbage collection kicks in earlier. I set the ‘nice’ value of node-red (Linux process priority) from 0 (all processes are equal…) to -10 then -20 (highest priority)...to get that node-pisrf code with less delay through the process traffic. Python 3 processes went automatically up to -20 as well. I changed swapping from 200 to 280 to allow temporarily a bit more "memory" space.

All these settings have advantages and disadvantages. You have to try a bit and find out, if these changes are a solution to your problem, without causing somewhere new issues.

After working though all my flows and trying better settings of the OS, I see the same accuracy of measurements with node pisrf, like I did with my old software setup. Next system update I will solder a resistor onto the JSN-SR04T v2 module to change to automatic mode (no triggering necessary). Maybe that's easier on timing too.

Hope this helps someone...Thanks!