search

rkaczorek / astroberry-diy

Astroberry-DIY provides INDI drivers for Raspberry Pi devices such us Astroberry Focuser - stepper motor driver, Astroberry Board - power switch board for up to 4 devices, Astroberry System - operating system status.
GNU General Public License v3.0
31 stars 16 forks source link

In function 'AstroberryFocuser::Connect()', gpiochip number is incorrect when Raspberry Pi model number is 5. #34

Closed jctk closed 4 months ago

jctk commented 5 months ago

Current Astroberry focuser cannot work on Raspberry PI 5. To use the same GIPO numbers as before, gpiochip4 should be used.

I have created code to get the model name from /sys/firmware/devicetree/base/model and use the appropriate gpiochip number. Could you merge the attached patch?

diff.patch

Or should I submit a Pull Request?

mimosa4 commented 4 months ago

even when applying the patch the focuser does not work

jctk commented 4 months ago

Hi @mimosa4

Please let me know a few things to help me isolate the issue.

Q1. Was Focuser working on Raspberry PI 4 before you applied this patch?

Q2. Did you install the HAT and Stepper Motor that worked on Raspberry PI 4 on Raspberry PI 5?

Q3. Have you confirmed that the Stepper Motor installed on Raspberry PI 5 in Q2 works with any test program other than Astroberry Focuser?

Q4. Is the INDI control panel for Astroberry Focuser on Raspberry PI 5 the same as that on Raspberry PI 4?

Q5. What message is displayed when the following command is executed on Raspberry PI 5? cat /sys/firmware/devicetree/base/model

For my Raspberry PI 5, the following string is displayed. Raspberry Pi 5 Model B Rev 1.0

mimosa4 commented 4 months ago

Hi jctk and thank for your answer

Q1 - I have never tested with an RPI4 but I tested directly with RPI5.

Q2 - See Q1.

Q3 - I tested Stepper motor and driver with another program and everything is OK.

Q4 - I don't know ; see Q1.

Q5 - The same as you : " Raspberry Pi 5 Model B Rev 1.0 "

I can do a test with a RPI 4 I have. I'll come back to post after the test.

jctk commented 4 months ago

When you test with RPi4, could you check with the original code without the patch and with the patched code?

mimosa4 commented 4 months ago

OK, I will

mimosa4 commented 4 months ago

Hi jctk Finally I managed to install astroberry focuser on RPI4 but only with bullseye 64 bits ; compilation errors with bullseye 32 bits. I tested with and without patch and both work.

jctk commented 4 months ago

I am using INDI with bookworm 64bit for both RPi4 and RPi5.

Now, if I set the INDI Control Panel settings on the Astroberry Focuser on the RPi5 to the same as on the RPi4, did it work?

The only difference in behavior between RPi5 and RPi4 is whether gpiochip4 or gpiochip0 device is used. The logs of the patched Astroberry Focuser show the model name of the Raspberry PI and the name of the target device.

For example, for the RPi5, the following is shown.

2024-04-25T13:58:46: [INFO] model:Raspberry Pi 5 Model B Rev 1.0, device:/dev/gpiochip4

Does this show up in the INDI Cotrole Panel logs like this?

If it doesn't work, could you please set its log level to Verbose and share the detailed log?

mimosa4 commented 4 months ago

Sorry but I don’t know where to find the indi logs; I’m mostly a fedora user and the logs are in/var/logs. I looked for them but I did not find them. If you say that on your setup it works on RPI4 and RPI5 there is no reason for it to be otherwise with my hardware. As I did a lot of manipulations with this RPI5 there may be a library problem. I will redo a fresh installation. I will come back to this post later. Thanks for your help.

mimosa4 commented 4 months ago

Hi jctk I reinstalled raspiOS Bookworm 64-bit, used the patch and used the same settings as for RPI4. It still doesn’t work. When I start a movement, the engine brake comes into action and the axis does not rotate.

jctk commented 4 months ago

When I start a movement, the engine brake comes into action and the axis does not rotate.

If the motor is rattling but not moving in a certain direction, the wiring between the stepper motor and the handler is not correct. Or maybe there is not enough voltage, current, or torque in the motor.

mimosa4 commented 4 months ago

The engine doesn't rattling it is simply maintained . I did not change the wiring between the engine and the driver. I use 2 separate 5V/5A power supplies for the RPI5 and 12V/3A for the motor. The wiring is exactly the same as when testing with the RPI4. The only difference is that on the RPI4 I use an SSD on USB3 and on the RPI5 an NVMe SSD on a HAT. I don’t think it matters. I use a A4988 driver and a 17HS08-1004S stepper motor. I don’t understand what’s going on.

jctk commented 4 months ago

I am concerned that the voltage and current of the A4988 motor is too high relative to 17HS08-1004S, but I don't think that is the cause.

I think logs are needed to analyze the cause. You can find the log output settings and storage location at https://www.indilib.org/.

mimosa4 commented 4 months ago

The current on the A4988 can be adjusted but this is not the problem since the exact same configuration works with the RPI4. Attached is the log file: indi + focuser (verbose). For information eqmod, gps and zwo are not connected. log_16-47-37.txt

I will finish this discussion because I will be leaving and I will not be back until Thursday. Thanks for everything

jctk commented 4 months ago

I looked at the log. The function AstroberryFocuser::Connect() determines the model as Raspberry Pi 5, the correct device "/dev/gpiochip4" is opened, and the function outputs a log indicating that it has completed successfully.

My patch is only the part that determines the device name. The device is successfully opened as determined by the code in the patch.

I suggest you check with the author of the original source or do your own investigation on the behavior of the other parts.

The original source has no error handling for GPIO operations. Therefore, even if the GPIO operation fails, it cannot be determined in the log. You may need to investigate with the debugger or add logs.

Finally, here are a few things you might want to check. After connecting to Profile with KStars, open a terminal and run the "gpioinfo" command. You can see which GPIOs the Astroberry Focuser is using in the "gpiochip4" block. You can check if the correct GPIOs are assigned.

Here is part of the output of the "gpioinfo" command for my Astroberry DIY Driver HAT

   line  17:     "GPIO17" "m1@astroberry_focuser" output active-high [used]
   line  18:     "GPIO18" "m2@astroberry_focuser" output active-high [used]
   line  19:     "GPIO19"       unused   input  active-high 
   line  20:     "GPIO20"       unused   input  active-high 
   line  21:     "GPIO21"       unused   input  active-high 
   line  22:     "GPIO22" "sleep@astroberry_focuser" output active-high [used]
   line  23:     "GPIO23" "dir@astroberry_focuser" output active-high [used]
   line  24:     "GPIO24" "step@astroberry_focuser" output active-high [used]
   line  25:     "GPIO25"       unused   input  active-high 
   line  26:     "GPIO26"       unused   input  active-high 
   line  27:     "GPIO27" "m3@astroberry_focuser" output active-high [used]

Supplementary information. Your version of KStars is very old. The latest KStars is 3.7.0. I recommend using the same time release of KStars and INDI.

healeysa commented 4 months ago

Current Astroberry focuser cannot work on Raspberry PI 5. To use the same GIPO numbers as before, gpiochip4 should be used.

I have created code to get the model name from /sys/firmware/devicetree/base/model and use the appropriate gpiochip number. Could you merge the attached patch?

diff.patch

Or should I submit a Pull Request?

This Patch worked great for me on a Raspberry Pi 5. Thanks for sharing!!

rkaczorek commented 4 months ago

Thanks for great work! Pushed to master

jctk commented 4 months ago

Thanks for merging this patch. It is only a workaround because there is no guarantee that this logic will work in the future since it depends on the RPi model name.

The best way is to use libgpiod's API to get the appropriate GPIO Chip name.

Well, this workaround should be sufficient for a few years.