pigpio will not run on a Pi 5 #1658
Comments
|
My first search was unsuccessful, we need some library compatible with RPi5 capable of bitbanging. I'm still investigating... |
|
OK it is done :) We already have a new python script using gpiod library instead of pigpio that works on RPi 4 and 5.
The script detects the GPIO chip and uses the same UI in Signal K server. Only the embedded python code should be replaced in pigpio-seatalk.js and modify the docs. Since pigpio will no longer be used, how should we handle references to pigpio in the file name? |
|
Would it make more sense to create a new connection type rather than change the existing one? With NMEA2000 we have the data type and then source separately. How would / should this affect the current users, with working systems? Do they keep using pigpio or are their systems silently switched over to the new way? As a user I might not want that... |
|
I wrote the Python script that @sailoog tested. It works with gpiod 1.6.3 that comes preinstalled with Raspberry Pi OS Bookworm, and also with gpiod 2.2.1 that is installed when updating it with pip. I tested with Raspberry Pi OS Bookworm on Raspberry Pi 4 and 5 for both versions of gpiod. I haven't tested with older versions of Raspberry Pi OS, or other Pi models. Would it be possible to switch the .js silently when Bookworm and Pi 4 or Pi 5 is detected? |
|
I apologize, I'm not familiar with Signal K Server. Looking at the documentation, I can see how it may be easier to have a separate source for pigpio and gpiod. Otherwise it will be tricky to still cover the pigpio installation steps without confusing the user. |
|
Agree. The change could be made silently to the user, but adding a new source could be more consistent. If I am not wrong we should add a new field "Seatalk Source" to the Data Type "Seatalk (GPIO)" form containing something like "pigpio" and "gpiod" as options but is it possible to make it silent for existing RPi4/pigpio users without any action on their side? For non-OpenPlotter users: As @astuder explained, his script works with both the outdated version of gpiod installed by default on Raspberry OS, and the new active version installed with pip:
Obviously active is the recommended one, but pip will complain that the package is being installed in a non-virtual environment, but you can ignore the warning. I can update the documentation unless @MatsA wants to do it himself. |
|
So I guess a separate .js is the way to go. I will submit a pull-request for st1rx.js later today. For the UI: How about having a new source drop-down defaulting to "gpiod", allowing the user to select "pigpio (legacy)" if they run into problems with gpiod? I do NOT recommend updating gpiod outside of very well controlled environments. It will introduce the unsuspecting user to Python's dependency hell as any other Python application using gpiod will break. Almost all APIs changed between 1.x.x and 2.x.x. I put some effort into supporting both versions, so no need for us to push users to update gpiod. Anyone knows how far back the Python binding of gpiod was available on Raspberry Pi? And what is realistically supported by the current version of Signal K server? Here's the standalone Python script if anyone wants to run some tests. Please report results here. May also be interesting to see how/whether it works on Orange Pi and similar. I plan to test with a legacy Raspian on a Raspberry Pi 3 today. |
|
https://packages.debian.org/search?keywords=gpiod 1.x.x has been there since buster and will still be there in trixie. OK then nothing about 2.x.x version in docs. OpenPlotter has been using 2.x.x since the beginning of version 4 and no problems so far. |
|
Tested on a Pi 3 with a freshly imaged Raspbian GNU/Linux 11 (bullseye): I updated the gist with that change. I also split read() into version specific implementations to improve readability, and minimize overhead. |
Raspbian is not the same as Raspberry OS. Raspberry OS is using the Debian repositories where gpiod was present since Buster, but Raspbian had its own repositories where gpiod was probably not present because it was not a popular library. If I am not wrong Raspbian became Raspberrry OS in bullseye but the 32bit version was still Raspbian. It might be best to advise users to check if gpiod is installed first. If it is installed, do not touch it in case some program is using it. If not installed, install the latest version from pip. |
|
I just ran a test with the script from astuder. I'm not sure if the results are as expected. I get valid Seatalk data using my own script based around pigpiod, and seatalk_read.py (https://github.com/Thomas-GeDaD/Seatalk1-Raspi-reader). I am running it on a Pi 4 and had to install gpiod with pip, which installed without any issues. |
|
@jimseng Thanks for testing, that's the kind of results I was looking for / feared :) Are you able to repeat the test with a fresh Raspberry Pi image? I suspect that the issue is reliability of the solution when the Pi is under load, but it would be a good test to rule out the hardware as a cause. @sailoog Raspian / Raspberry Pi OS: That string is what the OS reports. I don't think there was a 64bit version to choose from in the Imager. |
|
Well for no reason other than to fiddle, I changed ST_BAUD = 4900 and now it works much better. I added a socket and am sending "$STALK" + st_msg via UDP to SignalK on my Pi 5 via ethernet and am getting my instruments displaying correctly in OpenCPN. |
|
Hmm, that's unexpected. Do you have multiple ST devices on the bus? If so, were all instruments not working, or only some? Do you also get occasional invalid messages with pigpio? Like for example the single-byte messages. I may be able to dynamically adjust the bit timing without too much overhead. |
|
Oh, and occasional bit errors can happen with multiple instruments due to bus collisions. I probably should make printing the bit errors a debug option. And add a mechanism to discard partial $STALK messages when bit errors are detected. |
|
The socket could be affecting performance if it is located in the loop. Could you also try the original code without modifications and run it as?:
and
after checking what option works better try to stop all programs or services in your system to unload the CPU and check if the result improves. |
|
I don't think the socket is the problem as I tried it purely with the original script. I didn't get expected results until I changed the baud rate. I am talking purely about looking at the printed datagrams on the screen. When I say my instruments were working in OpenCPN, I first got the datagrams to look as expected by changing the baud rate to 4900. I then moved on to adding a socket to the script to see if I could get the $STALK string over UDP to my Pi 5 (which worked straight away). |
|
The screen grab above is with the baud rate set to 4900 |
|
Oh and with pigpio the attached text file is the output from my own script. I don't think there are many errors, but I haven't looked that hard. |
|
OK thanks. I have also repeated the stress test taking the Raspberry Pi 5 to 100% and I have no data loss. Even the blank space that can be seen in the Signal k log matches the Seatalk log:
|
|
Faster baudrate means that the bit gets sampled earlier, with the last bit having the biggest offset. I wonder if the spacing at the end of a byte is shorter than expected. What happens if you run at 4800 and set ST_STOP=0? @sailoog can you run the same test with st1rx.py? Signal K may suppress non-NMEA output. |
|
Done, same result. I am sure there is no data loss because I can compare at any time what is going out from the Raymarine MFD and what is going in in the SK log or the terminal. Look at my post. I think that could be a hardware issue, remember the problems we had when developing the HAT using slow optocouplers or the wrong resistor. |
|
ST_INVERT = 1 # 0=idle high, 1=idle low $STALK,26,04 |
|
ah well, so much for that theory :) |
|
@jimseng do you have multiple ST devices on the bus? Or just one? |
|
I have the wind, depth, speed plus a couple of St6000+ repeaters, not that I am pushing buttons. |
|
Another idea: what happens if you remove halfbit_ns from this line: |
|
sample_ns = e_ns + halfbit_ns Still no joy. However with the halfbit_ns commented out, 4900 baud rate still gives good results. So far that is the only thing that has made a difference. I'm trying to find an SD card. |
|
So this morning I ran a test with a brand new 64 bit bookworm image. I only installed samba and I get exactly the same issue. (This is with the script unedited, except for the gpio pin number change from 20 to 6): And with 4900: |
|
I did a test with something similar to your circuit. The resistor is 4.7 KΩ:
these are my settings: ST_PIN = 16 It works fine. If I change to a 10KΩ resistor I get similar results to yours and changing the baud rate improves it a bit, but not as much as yours. Can you try with 4.7KΩ? |
|
Ok. So this looks like a hardware issue. Unfortunately I don't have any resistors on board and I am using a custom made PCB so it looks like I need to do a bit of tuning when I can get back with some resistors. Unless there are any more suggestions I will report back when I have had a chance to swap the resistor out, or try with the off the shelf opto module. |
|
If the slow edge is the issue, the width of the positive and negative bits are not of equal size. You probably can fix that issue in software by moving the sample point closer to the start of a bit. Try replacing with I will have to think a bit about whether that's a good permanent fix or not. |
|
Background: Your Seatalk signal looks something like this: The Raspberry Pi recognizes 1 or 0 based on a threshold around 1V. Due to the shape of the transition, this results in shorter 0s than 1s. A smaller resistor will sharpen the transition, reducing the imbalance. st1rx.py determines the state of a bit by sampling at the center of each bit. It is using the first transition to 0 (start bit) as a reference point. If the imbalance is greater than 75/25, the 0 bit gets shorter than the calculated halfbit duration, and the sample point will fall inside the wrong bit. If the 0 period is too short, moving the sampling point to the right will improve the situation. With ST_INVERT=1, the bits are inverted, so the 0 period is too long, and moving the sampling point to the left is needed. (or the other way around, I need more coffee!) On the downside, shifting sampling point will reduce the timing margin. Currently transmission speeds on both ends can mismatch by a bit less than 5% (half-bit shift over 11 bits). Moving the sample point off-center by 1/4 bit, reduces that to less than 2.5%. In short, I may have to come up with a more robust algorithm if we want to avoid issues with non-ideal hardware. |
|
Thanks astuder. That has worked. I have it working reliably at 4800 and I can UDP stream from my pi 4 to my phone and Pi 5. I can't remember what opto I am using, perhaps the opto is slow. Anyway. This is excellent work. I am really grateful for all the help from you all. |
|
I update the pull request and the st1rx.py gist based on the debugging above. The main change is shifting the sample point 1/4 bit earlier/later to accommodate for non-ideal opto-coupler circuits. @jimseng can you test that this still works on your setup? @sailoog can you check with SignalK / OpenPlotter? |
|
Hi. |
|
st1rx.py and SK plugin tested using the MacArthur HAT (transistor) and the external circuit (optocoupler + 4.7KΩ) on Raspberry Pi 5 under stressed and normal operation. No issues. |
|
Everything is ready at OpenPlotter to implement this change when the next version of Signal K server is released. I know you have released one recently, do you have any idea when the next one will be? |
|
Thanks! Closed by #1779 |
|
Great work ! 👍🙏 |
joan2937/pigpio#589
Investigating gpiod and pinctrl as replacement...
The text was updated successfully, but these errors were encountered: