Saw the 3.5.7b build that was pushed on to gitlab earlier, built it and testing it now; initial tests show that interacting both directly and indirectly over dbus both seem to be functioning and nothing untoward has popped up in use or the logs.

I'll keep throwing some tests at it, just to check and hopefully towards the end of next week get chance to test it on real equipment in a real world situation; if anything pops up I'll keep you informed.

Read More...

Hello again.

I've been doing a bit more testing with the 3.5.7b with the changes to the scheduler.cpp that were pushed to the repo, and found some more problems; I'm not sure if it is a continuation of the same issue or it's another that was hidden by the previous one.

With testing further via the interface, I've found that the scheduler is now causing problems and hanging at the "No Job Running" state when starting the tasks locally via the scheduler interface within Ekos; it's appearing to fall over in exactly the same way as the dbus interface was previous but stopping and force reloading the schedule or toggling pause does not bring the queue to life.  I've been through and checked it with viable targets and with all the overrides turned off (altitude, twilight, etc) a few times just to make sure that it wasn't something I'd overlooked.

I've attached scheduler the log from the last test I ran with it as it's a carbon copy of the others.

Read More...

Thanks Jasem!
I built from git on version 3.5.7b tested with the simulation profiles and the different ways I can think if to arrive to sequence start, and each time it is equal to the behaviour on 3.5.3 and without issue or workflow modification to force anything to happen. I'll throw some more tests at it over the coming days, but I'm not seeing anything different from previous (3.5.3) on it at the moment.
Thanks for the time looking in to this one and thank you for implementing the fix!

Read More...

There has been an on and off issue, for at least 5 years where some Android devices have trouble resolving .local hostnames.

Easiest way around it, if you say it connects using the ip address is to set the Astroberry to a static IP.  It sounds scary but it isn't; when you are on the Astroberry desktop, right click on the network icon on the task bar, and there's an option that says "Edit Connections", click on to that and it'll bring a new window up with the list of connections you've got and which ones have been used. 
Highlight the WiFi connection you want to edit, and then there is a cog wheel at the bottom, click on to that; .
Another window will pop up, with a lot of scary looking configuration tabs; the fifth one being IPv4 Settings, select that, and then from the drop down that says "Method", select "Automatic (DHCP) addresses only". 
The next step is to click on Add, and it'll highlight a row in the table that is visible.  In the first segment add "192.168.1.50" (you can change the 50 for any number you want between 2 and 254, but I'd advise to stick between 50 and 100 there as other fixed devices like printers, WiFi extenders and the like may be sitting on some of the addresses at the extreme ends), the second segment should automatically fill in 24 if it doesn't then do so manually, and the third if it doesn't automatically fill should be set to 192.168.1.1
I'd recommend you set it as well for the Wired Connection.

After that, reboot the Astroberry, and it give it a few minutes to let it connect and the router to register the changes and then you should be able to connect directly via the IP that you assigned above.

Read More...

Right, back from work and here's the rest of it.

The script, ekos_controller.py was put together by another member here, I can't remember who off the top of my head but it was another thread about dbus from quite a while back; I've gone through it, found no noticeable errors in it, rebuilt it a couple of times to make sure and matched it up to the scriptable functions in scheduler.cpp

On the machine, the configuration is a Pi4B 8GB, with the indiserver set to remote though on the same machine to maintain the current settings should kstars go down, the profiles in ekos are set to auto-connect.

The sequence which worked on 3.5.3, was from the terminal (or ssh, or shell script); examples assume relative to desktop.
The CurrentSequence.esl is just a copy of whatever the sequence I am working on at that time.

cd ~/Desktop;
./ekos_controller.py --start_ekos;
./ekos_controller.py --load_schedule ./CurrentSequence.esl;
./ekos_controller.py --start_scheduler;

However on 3.5.5 (and 3.5.7b) using the same python script, the process is :
cd ~/Desktop;
./ekos_controller.py --start_ekos;
./ekos_controller.py --profile 'Default';//Or other server profile name, sometimes fails to connect to the indi control panel
./ekos_controller.py --load_schedule ./CurrentSequence.esl;//Usually will not load correctly, marking as invalid, omitting co-ordinates, job status and .esq sequence count
./ekos_controller.py --stop_scheduler;//To mark the job aborted instead of invalid and allowing to reset
./ekos_controller.py --reset_scheduler;//Here resetting the the schedule sequence to correctly load co-ordinates and .esq file
./ekos_controller.py --start_scheduler;//Restarting the scheduler

This, however, only goes so far to start the scheduler, but when the schedule is started in this manner even with a valid job in the queue, it doesn't select the job and start.

Starting and running a sequence by direct input doesn't cause the same issue to appear. 

File Attachment:

File Name: ekos_controller.py.zip
File Size: 2 KB


Read More...

Hi Jaseem, thanks for the welcome!

It'll be later on today when I get around to it as I'm just on the way to work, and I'll attach the python script that's used for the initiator, command line call, etc.

In the mean time here's the logging output from the scheduler module if it's useful I made yesterday evening from both 3.5.3 and 3.5.5, generated by simulators but it's the same behaviour as the physical hardware attached. The 3.5.3 is up to the point where the simulator is generating the first frame, but 3.5.5. doesn't log any further than where the last line of the log is generated without manual intervention. 

Read More...

A couple of weeks ago, I updated the Astroberry to kstars/ekos 3.5.5 I found a little issue where a schedule won't run if ekos is started and the schedule loaded via a dbus command via python for some automated management I've been working on.

Previously on 3.5.3, the sequence was load ekos, load schedule, run schedule and then it connects devices and off it goes.

However in testing 3.5.5 (not tested on 3.5.4) some issues have crept in where sometimes it will not read the equipment profile from the schedule and won't load the profile unless that is injected over dbus via setProfile(), sometimes it loads the sequence in an inconsistent state which requires triggering of resetAllJobs() to force the scheduler to load the capture sequence and the target co-ordinates. Finally when triggering the start command the schedule is holding at idle with "no job running" until manually pausing/stopping and then restarting the scheduler via the ekos scheduler interface.

On the spare Astroberry, I built 3.5.7b from source to test if it was a one off, but the issues still present, and still end with the same result where it sits spinning the wheel with no job running.

Read More...

This may sound like a little bit of a naive question, as I've only seriously been using Ekos for about six months, and am still getting orientated with the system.
I've thought about this a few times, usually just after crashing the system by forgetting to set the correct solver profile for when I've changed the camera/scope over from guide to imager and then running a solve action, and am wondering if it's possible to create module profiles for specific camera/scope/maybe focuser combinations.  In this, I'm thinking if I've got camera a/scope a (in the align module as an example) then being able to set the solver as astap, and when going to solve then it loads the settings I've already pre-selected or saved from last time and brings them up, but then if selecting camera b/scope b it automatically loads the pre-associated settings like the internal solver and associated profile, gain level, maybe autofilling the checkbox for applying darks, etc.  Also a similar concept in the focus module, with things like tolerance, min/max steps, backlash, etc.
I've had a look around to see if it's possible though not in the scripting engine as I've not looked too deeply in to that yet, I've not found anything but with the amount of configuration and different options within the kStars/Ekos environment, it could be something I've overlooked somewhere; does something like this exist or is it not implemented within the system?
Thanks in advance for any pointers you may be able to give me with this!

Read More...

I tried posting this yesterday, but it didn't seem to process and after waiting a while, it didn't appear in the My Topics section; so if it does appear, apologies for double posting.

This might sound a bit of a naive question but I've only been using Ekos for about six months, and am still getting orientated with the system.  What I've been looking save module settings based on camera/scope selection, so instead of having to go through the module each time and set the correct values for the device in use attempting to find some way to recall the last used settings based on camera or scope selection.
The thing what I'm looking to do, is (as an example, using the align module as reference) when selecting the guide camera for doing alignment with the system up the internal solver with the profile tailored for it, maybe the "use darks" checked as well, but when switching to the imaging camera having it automatically load the configuration for that, so say passing the solving off to astap with settings tailored for that.  That's roughly where the thought came from as there's a couple of times I've crashed the system as the internal solver doesn't really handle my imaging camera that well and I've forgotten to change the profile; though that's a limitation of operating system/Raspberry Pi rather than Ekos itself.
Also similar to this, would be with the focus module, so based on scope/camera being able to save/recall things like min/max step sizes, move speed, backlash and the like.
Is it possible to currently do this in Ekos?  Am I missing something somewhere, or is it something that isn't implemented?
Thanks in advance for any pointers or advice on this.

Read More...