×

INDI Library v1.9.7 Released (29 Jul 2022)

Bi-monthly INDI Library released with new drivers and bug fixes.

Driver OnStep (LX200 like) for INDI

  • Posts: 320
  • Thank you received: 41
Keine Ursache :-)
Oups was typing by error in the wrong window ...
By the way, the new version is now in the PPA's repository.
Last edit: 3 years 7 months ago by Alain Zwingelstein.
3 years 8 months ago #34092

Please Log in or Create an account to join the conversation.

  • Posts: 107
  • Thank you received: 4
Alain / All
I installed the Nightly version on my Rasb Umbuntu Mated, but i discovered the updates where not visible in the Mac version ( i didn't found the add functions in the motion Tab)
While it say remote driver, in the wizard (profile editor)
Logon on my Rasp Unbuntu Mate an started there the Kstars it show also version 1.4 interface 5 any clue?
So it looks like its not yet available in the Nightly version?

Nightly build versions
kstars-bleeding is already the newest version (6:3.1.0+201901252021~ubuntu16.04.1).
indi-full is already the newest version (1.7.6~201901270856~ubuntu16.04.1).



Chris
Last edit: 3 years 7 months ago by Chris Alberts. Reason: Updating it version numbers
3 years 7 months ago #34159

Please Log in or Create an account to join the conversation.

  • Posts: 320
  • Thank you received: 41
Chris,
I have exactly the same version installed and evreything is fine
dpkg -l | grep indi-full
ii indi-full 1.7.6~201901270856~ubuntu16.04.1 armhf Instrument-Neutral Device Interface library - Full INDI
dpkg -l | grep kstars
ii kstars-bleeding 6:3.1.0+201901252021~ubuntu16.04.1 armhf desktop planetarium for KDE
ii kstars-bleeding-data 6:3.1.0+201901252021~ubuntu16.04.1 all data files for KStars desktop planetarium
ii kstars-bleeding-dbg 6:3.1.0+201901252021~ubuntu16.04.1 armhf debug information for the desktop planetarium for KDE
__________________________________________
Do you run the server and driver on the raspberry before connecting from you Mac?
alain@ObservatoirePI2:~$ indiserver -vvv indi_lx200_OnStep
2019-01-28T05:13:30: startup: indiserver -vvv indi_lx200_OnStep
2019-01-28T05:13:30: Driver indi_lx200_OnStep: pid=12434 rfd=3 wfd=6 efd=7
2019-01-28T05:13:30: listening to port 7624 on fd 4

Here my connection via device manager,
It should show this in the connection tab,

I don't have a Mac, or at least only an old I-book G4, so I can't test , but anyhow one thing is sure, only the Ubuntu packages are bleeding edge, other packages base on indi Version 1.7.4. except I am wrong.
If your version is not updated most probably something went wrong with your upgrade.
It may happen that a package installation conflicts with locally built versions. Did you install indi via local compilation some time before upgrade?
If yes it is better to uninstall completely indi from within your build directory before installing via apt.
CD to your build directory and execute following :
alain@asus:~/Development/azwing/build/libindi$ sudo xargs rm < install_manifest.txt
this should remove all the files installed locally

another way to check if your files have been installed is to list the indi_lx200_OnStep driver and check the date, which should be the date of your upgrade
ls -l /usr/bin/indi_lx200_O*
lrwxrwxrwx 1 root root 17 janv. 27 19:28 /usr/bin/indi_lx200_OnStep -> indi_lx200generic

Hope this helps
3 years 7 months ago #34193
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 107
  • Thank you received: 4
Alian/James_Lan

I fixed it, what i did was that there were still packages which must be upgrade. i only did a update :-( Sorry

Now i played a little with the medrian, but i have not yet a good feeling if its working wel
I used the following configuration
Onstep both site are defined 1 degree to flip this means 4 minutes after medium the flip wil start
in the OnStep indi driver it show 4 minutes (iNDI Control Pannel) this is 0,0667h. I use 0.08 for HA In Ekos (4.8 minutes when the flip must kick in)
HA describes (command a medrian flip if the hour angel exceeds the specified value. Capture and guiding will suspend)

What happend is that my capture is still running but the medrian flip kicks in on the OnStep 4 minutes. but it should wait until the capture is stopped.


after the capture is finished the medrian flip start but will never end, see screen shot? So what setting is wrong or....?
I had also situation that flip was in progress, then the capture was finished. medrian flip started after HA and told it was finished which caused that the slew to where the flip started was aborted.

Chris
The following user(s) said Thank You: Ray Wells
Last edit: 3 years 7 months ago by Chris Alberts.
3 years 7 months ago #34227
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 320
  • Thank you received: 41
@Chris,
There is no synchronization between Eko and the driver (all the drivers not only OnStep)
The principle it to set HA so that Ekos sends a slew command resulting in an meridian flip in OnStep.
If OnStep does the meridian Flip before then Ekos gets lost.

So HA setpoint must be lower than OnStep setpoint for meridian flip trigger
Last edit: 3 years 7 months ago by Alain Zwingelstein. Reason: some typos, my English get worse and worse
3 years 7 months ago #34230

Please Log in or Create an account to join the conversation.

  • Posts: 107
  • Thank you received: 4
Mmm, i understand i will do some more tests this evening.

Chris
3 years 7 months ago #34243

Please Log in or Create an account to join the conversation.

  • Posts: 107
  • Thank you received: 4
Alain, James, Jasem

I did the test with the indi OnStep default settings

Minutes Passed meridian 5m both site (#Set)
Autoflip = On
HomePause:Off #No idea what this is doing
Preferred Pier Side = East. (#set)
HA in ekos on 0.00, direct after passing the Meridiaan, the Flip is initiate but waits until exposure is finished than flip started. It does for the OnStep Mount

The Log of the Capture Module
2019-01-29T22:11:51 Capturing 300,000-second image...
2019-01-29T22:11:51 Telescope completed the meridian flip. #Stops the meridian flip but not on position yet
2019-01-29T22:11:49 Retrying meridian flip again... #Meridian flip Is still running
2019-01-29T22:11:49 Telescope meridian flip timed out. Please make sure your mount supports meridian flip. #Meridian flip Is still running
2019-01-29T22:10:19 Current hour angle 0,07 hours exceeds meridian flip limit of 0,00 hours. Auto meridian flip is initiated.
2019-01-29T22:10:19 Received image 2 out of 10.

on the moment the Telescope completed the meridian flip and the start new capture. The flips is not finished but stops slewing on the moment it tels in the log that it is finished which is not the case.

it looks like my mount in this case is to slow to finish the flip in the Ekos defined Time Out. To fix this I must be able to define the flip time out in ekos, I think this is something we need to request jasem to add this as variable. When I look to his Video his scope is much faster than my scope.
Hoop this setting can be added some where. It would be handy also to have HA also visible in the mount / alignment tab (first tab of ekos) how much time to to the meridian flip will be initiated but this is nice to have. I think we are there almost when we can define the time a meridian flips take, this value differents depending on the mount speed.

For Astrophotographer this must be working and is essential ;-)


Chris

PS the image show where it stops OnStep, Aurigae was the star where the flip start and and point
Last edit: 3 years 7 months ago by Chris Alberts.
3 years 7 months ago #34273
Attachments:

Please Log in or Create an account to join the conversation.

  • Posts: 257
  • Thank you received: 22
@Calberts: Thanks for helping with testing! :)
3 years 7 months ago #34278

Please Log in or Create an account to join the conversation.

  • Posts: 320
  • Thank you received: 41
@Chris,

II experiences this timeout too as well as Ekos believing flip is foinished right before slewing ended.
This is the consequence of unsynchronized process running in Ekos on one side and OnStep on the other side.

Since there is no command to initiate a flip and not command to check is if is in progress Ekos relies on coordinates, which is the reason of Ekos thinking it is done and OnStep still slewing.
I have to check how Ekos really does the thing and if the timeout could solve this synchonization issue.

This means diving into Ekos code, a new challenge :-)

here the code where Ekos checks if flipping, now I understand why we are still sleawing when Ekos consideres flip is done
====================================
case MF_FLIPPING:
{
double ra, dec;
currentTelescope->getEqCoords(&ra, &dec);
double diffRA = getInitialMountCoords().ra().Hours() - ra;
// If the mount is actually flipping then we should see a difference in RA
// which if it exceeded MF_RA_DIFF_LIMIT (4 hours) then we consider it to be
// undertaking the flip. Otherwise, it's not flipping and let timeout takes care of
// of that
// Are there any mounts that do NOT change RA while flipping? i.e. do it silently?
// Need to investigate that bit
if (fabs(diffRA) > MF_RA_DIFF_LIMIT /* || nvp->s == IPS_OK*/)
meridianFlipStage = MF_SLEWING;
}
========================================

and here where timeout is defined (unfortunately #DEFINED, no way to set it currently
========================================
#define MF_TIMER_TIMEOUT 90000
#define GD_TIMER_TIMEOUT 60000
#define MF_RA_DIFF_LIMIT 4
========================================
and the code to check timeout, at least there are three retries at 90s before giving-up, leaves 270 seconds to do the flip
========================================
void Capture::checkMeridianFlipTimeout()
{
if (meridianFlipStage == MF_NONE)
return;

if (meridianFlipStage < MF_ALIGNING)
{
appendLogText(i18n("Telescope meridian flip timed out. Please make sure your mount supports meridian flip."));

if (++retries == 3)
{
//KNotification::event(QLatin1String("MeridianFlipFailed"), i18n("Meridian flip failed"));
KSNotification::event(QLatin1String("MeridianFlipFailed"), i18n("Meridian flip failed"), KSNotification::EVENT_ALERT);
abort();
}
else
{
if (executeMeridianFlip())
appendLogText(i18n("Retrying meridian flip again..."));
}
}
}
=================================
Last edit: 3 years 7 months ago by Alain Zwingelstein.
3 years 7 months ago #34297

Please Log in or Create an account to join the conversation.

  • Posts: 107
  • Thank you received: 4
Alain

I think here we need definitely the help of guys like Jasem, I dont know who this is working in the forum should we ask hem to add the Flip duration which will be result in timout settings in above code?

How can we ping him in to this discusion to understand his view?


Chris
3 years 7 months ago #34304

Please Log in or Create an account to join the conversation.

  • Posts: 300
  • Thank you received: 24
I am not sure if this would work, but worth a try ...

Once Ekos initiates the meridian flip, it should wait for a timeout period (configurable), and for two conditions to be true before it considers the flip complete.

The two conditions are:
- is the OTA east of pier (pointing west)? and
- is the mount tracking?

The timeout period will be something by trial and error depending on the slew rates for the mount. It should be measured and then configured in Ekos.
3 years 7 months ago #34321

Please Log in or Create an account to join the conversation.

  • Posts: 320
  • Thank you received: 41
Chris,
The right way to have this changed is to change the code, test it and then pull request to Jasem.

I believe the subject is already covered here: indilib.org/forum/ekos/1170-auto-meridia...ure-module.html#7917
Considering the code as it is today and that it suppports not only Onstep, if we change something we must ne sure it does not break functionality for other mounts.

For the moment I see only the way of having MF_TIMER_TIMEOUT beeing a default value, and introduce a new variable that could be set-up in Ekos UI.
Changing only the default value may break functionality for other mounts.

regards
3 years 7 months ago #34322

Please Log in or Create an account to join the conversation.

Time to create page: 1.747 seconds