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).
Last edit: 3 years 7 months ago by Chris Alberts. Reason: Updating it version numbers
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
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.
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
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
PS the image show where it stops OnStep, Aurigae was the star where the flip start and and point
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
double 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
if (meridianFlipStage == MF_NONE)
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);
appendLogText(i18n("Retrying meridian flip again..."));
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?
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.