EQMod Telescope "jumping" from NCP to eastern horizon with GoTo command on Raspberry Pi #209
Comments
|
@geehalel I tried to figure this out but can't understand why this happens on the Pi only? |
|
Hi,
I just tried to control the mount with a Hand Controller running SynScan V
04.37.03 and serial/USB connection to the RPi4. Kstars/Ekos connected
through indi_synscan_telescope and the GoTos worked fine with Stellarmate
OS on RPi4_4Gb.
So either it is the Ubuntu drivers for my AstroLynx/Shoestring FTDI cables
or the indi_eqmod_telescope driver I am guessing. The FTDI drivers are
built into the OS correct? Or can I update the cable drivers somehow?
Hope that info helps.
…-Giac
On Sun, Aug 30, 2020 at 2:17 PM Jasem Mutlaq ***@***.***> wrote:
@geehalel <https://github.com/geehalel> I tried to figure this out but
can't understand why this happens on the Pi only?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#209 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADGYSOHYYOTC3MLPCWEZYRDSDKQUJANCNFSM4QPUGUGA>
.
|
|
Yes, they're built into it. Try running this command:
then restart, and test. Does it help? |
|
Jasem,
Ok. I don't quite believe this, but everything seems to work now even
without using the remove rpi.gpio-common command.
I just powered off the mount after using the hand controller and
reconnected everything with my EQDirect cable instead. Then I powered it
back on and tested everything again and all the GoTo issues seemed to have
resolved without doing anything else.
I tested this on the RPi4_4GB, RPi4_8Gb, and even the RPi2_1Gb without
doing anything to my original setup other than having used the HC once (and
only connected to the RPi4_4GB). I did check the RPi Configuration screens
on all the RPIs and they all had Remote GPIO already disabled.
Any explanation why this happened? What hand controller sorcery was going
on? ;-)
I'm very happy it's all working now, but want to avoid or at least quickly
diagnose this issue if it arises again.
Hope this helps any others that may have the same issue.
…-Giac
On Sun, Aug 30, 2020 at 3:37 PM Jasem Mutlaq ***@***.***> wrote:
Yes, they're built into it. Try running this command:
sudo apt-get -y remove rpi.gpio-common
then restart, and test. Does it help?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#209 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADGYSODQZY2KOILGH5R7NSTSDK2ALANCNFSM4QPUGUGA>
.
|
|
I do want to note that after I saw that the GoTos were working after
reconnecting with an EQDirect cable , I disconnected the EKOS and powered
off the mount.
Then when I powered it back on, it showed it was pointing at the Eastern
Horizon! Then I sent it to park at the NCP, powered it off and then
powered it back on and tested it again on the RPi_4GB before moving on to
the other RPis. When testing with the other RPis, the starting position
was always at the NCP. It was just that one time after powering off after
GoTos started to work that it initialized at the Eastern Horizon.
Maybe the HC had to release the parking state of the mount? Just a wild
guess and just glad it's working now!
…-Giac
On Sun, Aug 30, 2020 at 4:37 PM Giac Vu ***@***.***> wrote:
Jasem,
Ok. I don't quite believe this, but everything seems to work now even
without using the remove rpi.gpio-common command.
I just powered off the mount after using the hand controller and
reconnected everything with my EQDirect cable instead. Then I powered it
back on and tested everything again and all the GoTo issues seemed to have
resolved without doing anything else.
I tested this on the RPi4_4GB, RPi4_8Gb, and even the RPi2_1Gb without
doing anything to my original setup other than having used the HC once (and
only connected to the RPi4_4GB). I did check the RPi Configuration screens
on all the RPIs and they all had Remote GPIO already disabled.
Any explanation why this happened? What hand controller sorcery was going
on? ;-)
I'm very happy it's all working now, but want to avoid or at least quickly
diagnose this issue if it arises again.
Hope this helps any others that may have the same issue.
-Giac
On Sun, Aug 30, 2020 at 3:37 PM Jasem Mutlaq ***@***.***>
wrote:
> Yes, they're built into it. Try running this command:
>
> sudo apt-get -y remove rpi.gpio-common
>
> then restart, and test. Does it help?
>
> —
> You are receiving this because you authored the thread.
> Reply to this email directly, view it on GitHub
> <#209 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ADGYSODQZY2KOILGH5R7NSTSDK2ALANCNFSM4QPUGUGA>
> .
>
|
|
Thanks for your very detailed report and for testing in various other situations. |
|
Thank you @geehalel for the insight. I'll close this for now since the user reported it is working. Please re-open if the problem arise again. |
|
Thank you for your explanation of what may be going on with HC vs
indi_eqmod. I will definitely keep GoTo speeds and current draws in mind
as a possibility.
Clear skies!
…On Sun, Aug 30, 2020 at 5:08 PM geehalel ***@***.***> wrote:
Thanks for your very detailed report and for testing in various other
situations.
You pointed out the problem in the log, the DEC axis motor controller is
reset just after the goto command is started.
It is then marked uninitialized in the driver. The only way to reset a
motor controller is a hard reset (or going write into some registers which
indi-eqmod does not do directly). Thus the only explanation I can see is an
electrical issue. And the reason why only indi-eqmod is causing a reset may
be that it is using a higher goto speed than the HC or synscan, and drains
more current from the power. Another possibility is a short in the TX line
of the controllers which would reset the controller. Both controllers share
the same RX and TX serial lines. For RX there is no problem. For TX they
are not supposed to send messages at the same time. The controllers set
this line high when they don't use it, and there is a diode per controller
to avoid shorts when the other controller sends data (and may set the line
to 0). Maybe one diode is deficient.
Just seen your last comment, glad to see it has gone.
And your last last one. The HC and the indi-eqmod parking state are not
related (I don't know if the HC may park the mount anyway).
Maybe we could add a property to adjust the goto speed in a future release
(one another button...)
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#209 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/ADGYSOCLNKBQYS3U2ND6NOLSDLEVZANCNFSM4QPUGUGA>
.
|
log_19-00-12.txt
I have attached link to a screen recording of the issue I have encountered.
https://drive.google.com/file/d/1YzCEazlgXND_vE45QbBLmTHBSOVHK2e0/view?usp=sharing
Descprition: I seem to be having an issue with indi_eqmod_telescope on Raspberry Pi. I have been able to successfully use indi/kstars/ekos on Ubuntu Mate 20.04 with my Intel Nuc10 and Azulle Byte 3 minicomputers and was trying get an install working on a more portable Raspberry Pi. I got the RPi installation working with the Telescope Simulator and CCD SImulator including control over an iPad with Skysafari, but when I actually connected to my Orion Atlas mount, I started having issues when attempting a GoTo command. (Manual on screen controls and joystick control were ok). When I initiate a GoTo command upon startup of Kstars/Ekos, the telescope "jumps" from start position at NCP to eastern horizon and then the Indi Control Panel shows that the DE_Motor Initializaiton status button goes from green to red. From then on the mount no longer responds to commands for DE axis movement.
To Reproduce
I have tried multiple installs of indi/kstars/ekos on Rasbian 32, Ubuntu Mate 20.04 for RPi4 as well as pre-packaged installs of Astroberry and Stellarmate. I am using a CanaKit 3.5A power supply with the RPi4 as well as other 3A power supplies just in case it was a power issue. I have tried this on 2 RPi4s (8Gb version and 4Gb version). I even tried both Stellarmate and manual install on Raspian 32 on an older 1GB Rpi2 that I had. I have tried purging the parking data and writing the default home position under Site Management, GPS sync vs manual location setting, apt update/upgrade, etc. I have tried both the LynxAstro and Shoestring Astro cables to connect my mount to the RPi (they both work on my Nuc10 and Azulle Byte 3 installs).
Exact steps to reproduce the behavior.
In the log files I noticed that the [COMM] read_eqmod" "=xxxxxx" starts at the same "=000080" right before the [SCOPE] GetDEEncoder() = xxxxxxx goes from 10642945 to 8388608 and stays there. Does that point to the culprit?
2020-08-28T19:03:21.382 CDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: "=0166A2", 8 bytes read "
[2020-08-28T19:03:21.383 CDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] GetDEEncoder() = 10642945 "
[2020-08-28T19:03:21.383 CDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] Current encoders RA=8391755 DE=10642945 "
[2020-08-28T19:03:21.390 CDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: ":f1", 4 bytes written "
[2020-08-28T19:03:21.413 CDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: "=011", 5 bytes read "
[2020-08-28T19:03:21.414 CDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: ":f2", 4 bytes written "
[2020-08-28T19:03:21.416 CDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: "=211", 5 bytes read "
[2020-08-28T19:03:21.420 CDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] GetRAPeriod() = 6 "
[2020-08-28T19:03:21.420 CDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] GetDEPeriod() = 6 "
[2020-08-28T19:03:21.420 CDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] CheckMotorStatus() : Axis = 1 "
[2020-08-28T19:03:21.421 CDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[DEBUG] IsRARunning() = true "
[2020-08-28T19:03:22.416 CDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] Compute local time: lst=16.07754419 (16:04:39.16) - julian date=2459090.50230981 "
[2020-08-28T19:03:22.417 CDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: ":j1", 4 bytes written "
[2020-08-28T19:03:22.438 CDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: "=338980", 8 bytes read "
[2020-08-28T19:03:22.438 CDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] GetRAEncoder() = 8423731 "
[2020-08-28T19:03:22.439 CDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] dispatch_command: ":j2", 4 bytes written "
[2020-08-28T19:03:22.457 CDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[COMM] read_eqmod: "=000080", 8 bytes read "
[2020-08-28T19:03:22.458 CDT DEBG ][ org.kde.kstars.indi] - EQMod Mount : "[SCOPE] GetDEEncoder() = 8388608 "
Expected behavior - I expected the GoTos to perform just as they did on my Ubuntu Mate 20.04 installs of indi/kstars/ekos with my Intel Nuc10 and Azulle Byte 3. As an aside, I was able to test the same hardware with an ASIAir Pro (another Raspberry Pi!) and was able to get the expected GoTo behavior.
Screenshots
Please see attached files and link to screen recording at beginning of this post.
Below is screen shot from my RPi2 with Rasbian 32 bit (2020-08-20 release)
Desktop (please complete the following information):
Log Files
I hope that I included the correct log files. Please let me know if I need to create it differently.
The text was updated successfully, but these errors were encountered: