Activity for mars
-
mars posted a comment on ticket #99
Please run the following commands and take a screenshot: cd ~/Projects/indi git log indiserver cd ~/Projects/indi-3rdparty git log From the error message, it seems that indilib is not 2.0.9 (but it is unclear whether the file version is wrong or the installation is wrong).
-
I believe there are a few points that need to be clarified.: This is the complete set of steps and scripts, just like the pictures provided before, starting from the burning of the SD card, and you should also start from this step (this is to completely eliminate old environmental factors). There are two ways to install indi-3rdparty, full installation and partial installation. To debug this issue, only one driver is installed in the script, so you should follow the content in the script. (You will...
-
The issue you encountered should be due to the master version being too active in development. I have selected a specific version in the script (both INDI and 3rd party need to use the same version). I have documented the scripts used You can skip the part about modifying the /etc/apt/sources.list file; I had to change the mirror myself because the network was too slow.
-
This issue appears to be related to a commit from this month; I need to set up a new system to verify it.
-
I understand that from the phenomena you've observed, it does seem like an SDK error, but I'm looking at the logs from execution. The logs show that the incorrect API was called, and it was called in a very strange way (half right, half wrong). This kind of issue typically occurs in some temporary versions during the development phase, and previous logs also indicate that the SDK at that time was a temporary version, not a released version. So it's clear that the error occurred before the SDK. Moreover,...
-
-
I understand that from the phenomena you've observed, it does seem like an SDK error, but I'm looking at the logs from execution. The logs show that the incorrect API was called, and it was called in a very strange way (half right, half wrong). This kind of issue typically occurs in some temporary versions during the development phase, and previous logs also indicate that the SDK at that time was a temporary version, not a released version. So it's clear that the error occurred before the SDK. Moreover,...
-
I understand that from the phenomena you've observed, it does seem like an SDK error, but I'm looking at the logs from execution. The logs show that the incorrect API was called, and it was called in a very strange way (half right, half wrong). This kind of issue typically occurs in some temporary versions during the development phase, and previous logs also indicate that the SDK at that time was a temporary version, not a released version. So it's clear that the error occurred before the SDK. Moreover,...
-
yes, indi-3rdParty is missing maybe follow this steps https://indilib.org/download/raspberry-pi/category/6-raspberry-pi.html I use these steps allow me chose the version I want https://github.com/indilib/indi https://github.com/indilib/indi-3rdparty If you can use remote assistance software, such as TeamViewer anyDesk, we can arrange a time to check the issue together. (The email address has already been posted in the previous post)
-
I understand that having more systems that can "very well" support various devices and software is definitely a good thing for amateur astronomer. I myself also use different versions of customized astronomy systems. I like them. However, every system with good support goes through a painful process (I actually saw a small part of AstroArch's scripts, which is why I find it quite challenging; the scripts also make special handling of some driver files, so I guess it might be to avoid some undesirable...
-
I understand that having more systems that can "very well" support various devices and software is definitely a good thing for amateur astronomer. I myself also use different versions of customized astronomy systems. I like them. However, every system with good support goes through a painful process (I actually saw a small part of AstroArch's scripts, which is why I find it quite challenging; the scripts also make special handling of some driver files, so I guess it might be to avoid some undesirable...
-
I have some questions: Why use https://gitea.nouspiro.space/nou/astro-soft-build instead of https://github.com/indilib/indi for verification? I have re-downloaded and installed the official version of the OS, both 32-bit and 64-bit, installed KStars with system libraries, recompiled INDI and INDI 3rdparty, and installed the SDK as prompted (https://www.qhyccd.cn/html/prepub/log.html#!log.md). I think now I can be sure that both methods can be used normally with cooling. Additionally, regarding that...
-
I have set up a test environment under astroarch and found that directly controlling the temperature is ok. However, the power (PWM) obtained from kstars is incorrect, and I am investigating the cause. I will return to the Raspberry Pi OS system, but I need to wait a bit (more SD cards are needed).
-
-
I saw that response, but I didn't think that is the direction I want to go I believe astroarch didn't fully understand this issue. I might have to use the astroarch system to debug this problem and see where the issue lies. From the logs, it seems that for some reason the wrong API was called. This might be the easiest way to handle it. Another question: Besides using indiserver and md5sum, are there any other ways to confirm the version of indi_qhy_ccd?
-
I saw that response, but I didn't think that is the direction I want to go I believe astroarch didn't fully understand this issue. I might have to use the astroarch system to debug this problem and see where the issue lies. From the logs, it seems that for some reason the wrong API was called. This might be the easiest way to handle it. Another question: Besides using indiserver and md5sum, are there any other ways to confirm the version of indi_qhy_ccd?
-
I saw that response, but I didn't think that is the direction I want to go I believe astroarch didn't fully understand this issue. Below, I might have to use the astroarch system to debug this problem and see where the issue lies. From the logs, it seems that for some reason the wrong API was called. This might be the easiest way to handle it. Another question: Besides using indiserver and md5sum, are there any other ways to confirm the version of indi_qhy_ccd?
-
64bit OS image
-
Raspberry Pi OS KStars 3.7.2 INDI 2.0.8 this problem not occur
-
I am working on verifying this, but the permission issue has not been resolved yet. I will continue to update if there is any new progress. What bothers me more than verifying this is figuring out where the strange version number of the SDK comes from.
-
We tested the directly downloaded indi2.0.8 and 2.0.9, but neither could reproduce the issue, so we plan to shift our focus to the system environment. However, we encountered a new problem: I am unable to obtain system permissions locally, which may take some time to check. I am still concerned about the unusual SDK version mentioned in the logs; this usually indicates a non-released version, and it also implies that this image might be using some unconventional environments, making it difficult...
-
It seems a bit strange: when connecting to 174GPS, the log shows that the wrong API was used, but when connecting to 600M, it is correct. Therefore, it might be happening at the upper layer (driver). I will continue to investigate this issue, please wait patiently.
-
No problem, I will set up an AstroArch environment to confirm this issue. If AstroArch uses the same SDK as you, I should be able to resolve it. Additionally, since the National Day holiday has just begun, all testing will be slower, please be patient (about 8 days).
-
The SDK version looks like not a publish version, can you tell me where you get that SDK? Please send to (my◎qhyccd.com)
1
