I have set up my AVX mout indoors and done a quick align.
Ekos is running and connected, I've set the Celestron GPS scope and the CCD Simulator.
Slew to an object that's about cross the meridian - Procyon as it happens.
The mount display in Ekos shows the Ra, Dec, Ha and LST as expected. The meridian flip is expected, the Ha limit is set to 0.1 hrs and when the mount data indicted an Ha of -20 minutes the time to flip was 26 minutes. All exactly as expected.
Looking on the HC display the Ra and Dec are the same, the LST is slightly different, by 2 mins 40 secs but that may be accounted for by slight differences in time or location in the mount or KStars The 6 minute delay before the flip is attempted should account for it.
I've set up an acquisition using the simulated CCD, 5 minute exposures.
And now I'm waiting...
The HC and EKos times are different by a couple of minutes or so, this probably accounts for the difference in LST.
These minor differences would be compensated for by doing a real alignment but the HC may have a slightly different position where a slew will change from one pointing state to the other.
Things I've not done:
I've not changed my location.
I've not set the meridian mode, it remains disabled.
I've not done a factory reset. That would set the mount location to Torrance.
The mount thinks it's past the meridian, ha axis shows 190 and increasing, Kstar doesn't think so.
Now Kstars thinks the mount is past the meridian, flip in 5 mins or so.
The image acquistion may cause it to hold off for a bit longer, up to the exposure time.
BTW I have set the mount time without DST enabled because Indi doesn't seem to handle it in it's local time structure.
Meridian time finished - Meridian flip running mount slewing
And it's a long slew, to the other side of the meridian.
I'm a little surprised there wasn't a delay but perhaps the CCD waits if there isn't time to complete the exposure before the slew is required.
Anyway the meridian flip was done as expected.
Hope this helps with working out what is happening
There's nothing in that log fragment that relates to the mount.
I would expect there to be problems with that setup. The attempt to move by the scope seems to indicate that the mount has recieved a slew command and the meridian mode, which is diferent to what I suggested, caused the mount not to do a flip.
- Hand control / Meridian : Favor East
- Ekos : Flip if HA > 0.00 h
When the object crossed the meridian, the scope started a flip without completing it (it had some sort of a hiccup !) and Ekos said :
"Meridian flip running ..." and then "Meridian flip completed" and then "Status : inactive"
As I said in my previous message:
Set the meridian mode to None.
Set the Flip Ha position to 0.2h
I would certainly wonder if any command was actually sent to the mount. A full debug log from the mount driver will show the commands to the mount. It should also show the pier side response from the mount.
When the Ra limits are disabled there are still limits of 20 degrees before and 20 degrees after the meridian.
The meridian mode controls how the mount responds to slew commands when it is close to the meridian.
Favour West will cause a slew to use the West pointing state if the object is less than 20 degrees east of the meridian, so it will slew using the West pointing state if the object is within 1 hour 20 mins of the meridian. it will slew early.
Favour East will use the East state until the object is 20 degrees after the meridian, it will flip late.
For the range from 20 degrees before to 20 degrees after the meridian you can use either pointing state, using favour east or favour west to choose which side.
If you set favour current it will do what you ask and not do a flip.
To get a flip at the meridian you need to turn the meridian mode off. AND you also need to set the flip position in Ekos to a little after the meridian so there is no debate about if the mount thinks it has crossed the meridian.
I use the meridian mode to handle the ASCOM set SideOfPier behaviour.
Won't the drivers provided by QHY before they withdrew support continue to work?
I wonder what the oldest standard is that's in current use on the internet. TCP/IP must be pretty old, so are the email protocols. Then there's ASCII... As for the QUERTY keyboard...
As a retired developer I'd agree with much of this, what I'd add is:
When you find good developers, keep them. Pay them the staying rate, not the going rate.
Be generous with development tools and equipment. It costs a fraction of the cost of a good developer.
IMO people have a limited amount of change they can manage. Your developers are generating change so minimise other changes by keeping the environment around them stable. Don't even rearrange the desks.
Encourage them to interact with others, particularly sales and support, and even users. It's important that your developers understand what users really want.
I'd be uneasy about just having a script for each state change because that's abdicating the development to the user. Most use cases can be met with a few options such as specifying the priority for scope park and Roof/shutter close.
But having a script option for complex systems is a good idea.
One thing to bear in mind is that in the warning state, where imaging is suspended but the mount continues tracking, it may not be possible to close the shutter if this is the roof of a roll off roof observatory. The roof would only be closed after the mount has been parked and that would be done when the system enters the ALERT state.
This would probably need to be configured by the user on a case by case basis.
Similarly for going from ALERT --> WARNING, some observatories will need to open the roof before unparking the telescope and slewing to the object.
Just a thought, the way I've thought about the observtory status is with two states, safe to Observe and safe to Open.
Safe to Observe controls the imaging and this is designed to pause imaging if something happens to make imaging impractical, such as a patch of cloud. The observatory would stay open, the camera cool, the scope tracking etc., while it waited. when this becomes true the system can quickly resume the observing process.
Safe to Open controls the observatory safety, the observatory could stay open through thin cloud but close for heavy cloud. This could warm the camera, park the scope and close/park the observatory.
sterne-jaeger wrote: Hi Chris,
I experience the same problem form time to time, but not too often. Please be so kind and post the entire log file. Maybe I can drill the problem down.
Thanks, Logs attached.
Log_19-18-42 is the one which contains the log fragment that I posted earlier, there are several bad image collections starting at 22:44:04 with a good one at 22:43:30. This has Ekos running on my Windows 10 laptop and indiserver remotely on my rasPi.
Log_21-26-35 has errors at about 23:35, 23:36:57 and 23:37. That's the times I noticed bad images. This is running Ekos on the RasPi. This log seems remarkably uninformative, apart from a vast number of phonon reports, no idea why.
The windows log gives chapter and verse about versions, the RasPi log doesn't, I'm running 3.2.2 at present but not sure if that was the case when the log was collected.
Hope this helps, Chris
File Attachment:File Name: log_19-18-42.txt
File Size: 307 KB
File Attachment:File Name: log_21-26-35.txt
File Size: 1,280 KB
Sorry for the delay in replying.
I've ended up doing a lot of examining the code and from what I can see the concept of Dome Park making the observatory safe is embedded in the INDI system so closely that the work of untangling it and making it more like what is specified is prohibitive.
For example indiTelescope.cpp snoops on the dome park state and uses this to inhibit scope movement when the dome is parked. Godness knows how many other places this is the case.
The fact that so much of this functionality is embedded into the INDI core components removes my primary problem with the documented specification being misleading - that a developer could produce a driver or client using the specification and get the wrong functionality. It's not practical to do this because any driver has to be built on the core indi libraries and these will deliver the core functionality.
As for improving the documented specification I think this needs to done by someone who is intimately aware of the whole INDI functionality, and that's not me. It was only by examining the code in what seemed like an unrelated module that showed that my suggestion was impractical. If I hadn't seen this I could have rewriten the specification incorrectly.
Developer speak. inditelescope.cpp and inditelescope.h are the source code files that provides much of the basic functionality of the telescope driver. Ekos will use these to control the telescope.
I've done some more digging and I don't see a way that this can be happening in the driver, at least not in the device specific part and I don't see anything obvious in the base inditelescope part either.
The slew and tracking state change in the driver uses an enumeration - TrackState - that is defined in inditelescope.h. Goto() sets this to SCOPE_SLEWING, then ReadScopeStatus uses this to poll the mount to see if the slew has finished and if it has sets TrackState to SCOPE_TRACKING. That's it and the log messages show that this is working. There are no transient changes.
inditelescope has a switch property CoordS(P) which seems to be analogous to TrackState and I guess is what is used for communicating the state between the client and indi. However I can't see anywhere where changes in TrackState get passed into CoordS(P). The only mention is in inditelescope ISNewSwitch where IUUpdateSwitch and IDSetSwitch are called.
I may have found the problem; in inditelescope in ISNewNumber the number called "EQUATORIAL_EOD_COORD" is found, this is EqNP. The Ra and Dec are extracted and CoordSP is checked, if it is "SYNC" then the driver Sync function is called, otherwise the driver Goto function is called.
No change is made to the CoordSP state in inditelescope but somehow after each of these CoordNP is set to the default "TRACKING" state, this seems to be done after a short delay for sync and after the slew has completed for slew. I guess that CoordNP is used by ekos to determine if a slew has completed.
When things are working well ekos sets CoordSP to "SYNC" then sets the coordinates in EqNP . This causes the sync to be done and CoordSP is set back to "TRACKING". Then ekos sets CoordSP to "SLEW" then the slew destination in EqNP. This cause the slew to be done and CoordSP is set to "TRACKING" when it completes.
When it goes wrong ekos sends the sync command but before the response to the sync command has been returned it sends the slew command. When the sync response is received it sets CoordSP to "TRACKING". ekos sees this and thinks it means that the slew has finished but what it means is that the sync has finished. The slew is still in progress. This accounts for seeing the state in the telescope tab change momentarily.
It looks as if ekos should wait until it gets the signal that the sync has completed before sending the slew command.
Hope this helps.