Come and join our community. Expand your network and get to know new people!
This is an interesting discussion and gives some insights into the coding of KStars and INDI.
BUT: I still don't understand, why the device manager keeps listing a wrong version number! (KStars and INDIlib on localhost!)
I tried to debug KStars and could trace down the calls in "drivermanager.cpp".
Surprisingly the following code snippet returns the wrong version (0. even if in the corresponding XML-File the version is "0.9":
name = valuXMLAtt(ap);
el = findXMLEle(root, "version");
... snip ...
Unfortunately I was not able to trace down the function "findXMLEle" in "lilxml.c+. QT Creator doesn't let me in!
Another suggestion I've seen is a infrared transmitter and receiver or reflector, where the receiver is effective when the scope is in the parked position.
I wonder also about using an accelerometer something like learn.adafruit.com/adafruit-lis3dh-tripl...ter-breakout/arduino
Wim, which system do you use?
If Ubuntu, this package is available only since 18.04, see:
Pick one of those for the usb c cable
What about extending the INDI webmanager? It already has a web interface and the python infrastructure for starting/stopping an INDI server.
My scheduler shutdown script also powers off everything (except weather station). It also starts a data-reduction-pipeline and when all done powers off the main PC.
A separate process may be the way to go alright. I've bee playing with a python script that uses dbus to start/stop the scheduler but haven't made much progress lately. I have a raspberry pi in the observatory which is switched on all the time and was hoping to run it there. It would do a wakeonlan to the main pc and then use dbus to load the schedule file and start the scheduler.
Thank you for the reply. I substituted wlan0 for vap0. I also installed RealVNC. Everything is 90% working. I have to hardwire the AstroBerry network into my iPad network connection, e.g. manual. Everything VPN works on AB 1.1 with RealVNC.
I have toyed with AB 2.01. I kicked the tires so to say. If I see the need for an RPI 4, I will use AB 2.01.
At the present, AB 1.1 has the Debug tools necessary to validate and explicitly defined a problem. Under AB 2.01, INDI devices have DEBUG disabled.
Sometimes, updates break things. Finding root cause is better than be frustrated and denigrating the team and package. Nothing gets better being frustrated and angry.
I tried to install the deb package, but got a dependency error. I don't have astroberry installed so I downloaded the deb from the link provided. Upon installation I got the following dependency that was not met:
python3-paho-mqtt , which isn't available (tried sudo apt install python3-paho-mqtt)
How can I resolve this error?
I'm very happy with the functionallity of astroberry in my RPI4, congratulations for the developers. All my equipment works well with this versión, but I have a problem with the Indi driver for my Pegasus PPB, astroberry detect the device but with warning messages and dont shows the sensor data.
It seems that with New indi drivers works well, but I don't how to update the indi drivers safetely....
A y Help for this? Thanks in advance,
Enviado desde mi SM-T813 mediante Tapatalk
Ok I've been thinking that the additional INDI server only runs the weather driver (and perhaps any power controlling drivers), but not dome/mount..etc.
Now, it could be Ekos Scheduler module itself or a separate process that monitors weather and commands the scheduler to shutdown or startup. The current "Park Wait" implementation is fine for short periods, but inefficient for long periods of inactivity, and therefore a complete power-off shutdown would be the way to go (given you don't cut off power from weather station!). The dedicated process or Ekos can then start the scheduler when the weather improves. The scheduler has no idea and would start as it would have been started by a human operator. That intelligence just acts as the decision maker. It's not just weather, for could be used perhaps for the holy grail we've been seeking for a long time: multi-night scheduling.
As I already explained to Jasem, unfortunately I don't have time anymore to look into this and the little amount of time I was able to spend on this wasn't enough to solve this properly. Sorry!
Yes, I think a completely separated process is best. What about building a separate web application on top of an INDI server that controls the observatory and communicates with the scheduler? INDI is already perfectly prepared with its distributed architecture. I would build two INDI servers, one for the observatory devices (dome, weather, maybe energy control for the mount) and one separate INDI server for mount, CCDs, focuser etc.
Ekos could use both INDI servers so that everything is at hand from one UI. And a separate web application sitting on top of the observatory server would control the observatory devices only and in addition communicate with the scheduler via DBUS for starting, stopping etc.
maxthebuilder wrote: For me it also felt laggy compared to 1.4.3 (this version I used for a while) but faster than 1.4.4/5 (those I used only briefly).
All runs on RPI4 with wired VNC to a desktop at 1920x1080 resolution
Yes, mine runs in 2560 x 1600, so was wondering if that was the issue with being really laggy, but if you are running on just full HD then maybe it’s not my res....but it is really laggy, it seems fine for a couple of mins after booting, then slows right down, thought it may be rpi temp, but hat does not go above 55 degrees..so not that either...
But other version such as the new Astroberry 2.0 runs super fast and really well indeed... over VNC at 2560 x 1600
Would it be possible to have a microswitch that will be operated by the OTA as it reaches the park position? You can get microswitches with long arms that are designed for this sort of thing, you may already have some on your roof.
The switch is connected to an input of your observatory safety system, the rest is just software.
Yes I agree. We need to consider all the various scenarios as well to accommodate different requirements for each. So this would be a completely separate external process?