RadekK

@Gina you can run many instances of indiserver using different for port for each instance (see -p switch for indiserver). Each instance can be started with it's own set of drivers. You can even aggregate these instances into one by using remote drivers approach i.e. 'driver name'@ip:port. However... controlling such a setup with a single KStars/Ekos is not possible. Well, you can control a mount and run guiding if all cameras are on the same mount but you need to run separate acquisition thread for each camera, focuser, filter wheel etc. Possibly with CCDciel, but I'm not sure you can run multiple instances. Finally, indi_asi_single_ccd driver works great for multiple ASI cameras so you can use just one, but... it tells a camera from the other ones based on name, not ID. As a result using two ASI 1600 would a be a challenge.

Interesting discussion indeed 😉 Updates to KStars and INDI will be released not ealier than mid October. I'm also planning to release new version of astroberry image (v2.0.4), which should have all the latest software preinstalled. No major changes to the system itself. Let me comment a few points discussed earlier in this thread: client-server architecture is not operating system specific and has nothing to do with linux in particular. While accessing this website you use client-server architecture and it does not matter what operating system you use. In such the case a server component is a web server which serves this website and client component is your preferred web browser. The same way INDI is a server, which serves all devices and possibility of control and KStars/EKOS is a client. BTW KStars/Ekos is not the only client you can use (the same like IE is not the only browser) - you can use many others inluding Cartes du Ciel and Stellarium, see list of supported clients here INDI server has been developed for linux or other unix-like systems and cannot be just rewritten to other systems like some of you would expect. Philosophy of accessing low-level hardware just differs significantly (to be moderate) between unix/linux/macos and windows. I cannot say that it will never happen. I'm not aware of such plans at the moment. ASCOM is not a standard and if some of you believe it is, so is INDI. Applications like Cartes du Ciel, Stellarium and many others support both INDI and ASCOM. KStars supports INDI and does not support ASCOM. Why? The reason is as simple as this - nobody added ASCOM support to KStars. Hey, it's open source software! Anybody can develop and submit any change or add new functionalities to it. Discuss it at your local club, find people interested in it, find programmers willing to accept a challenge and fill the gap if you think there's one. That's how it works in open source world where people create software and share it for free with everyone, including right to modify. Finally, there is not one-fits-all solution. I go with linux and every single photon I capture with my setup comes from "open source astronomy". But this is just me 😉 Clear skies to everyone!

Do your wifi dongle comes with binary drivers? If so, it could be the case that the drivers are compiled for a specific kernel version. That would be dead end if you cannot recompile them for a new kernel. You can try using open source drivers instead and forget vendor provided binaries. You need to identify your hardware (run: lsusb -v). Then try to find your device on a compatibility list like this https://help.ubuntu.com/community/WifiDocs/WirelessCardsSupported or this https://wiki.debian.org/WiFi

@Gina I'm glad it works for you. I guess the problems were related to SD card itself. I have just released an update to INDI 1.9.1 so feel free to update.

Hi Guys, I was PMed by @Martin Meredith so I can take a look at this issue. I do confirm that running the sequence of commands fixes it: sudo systemctl stop gpsd.service sudo systemctl stop gpsd.socket sudo dpkg --configure -a sudo systemctl restart gpsd.service sudo systemctl restart gpsd.socket I guess the issue pops up when upgrading a system installed from a fresh image. It could be the case that it was introduced somewhere in-between image version and the latest version of astroberry-server-sysmod. If one updated the system using former updates the issue does not appear at all. So use this workaround and keep going.

INDI driver is on its way. Stay tuned 😉

Great post! Thanks for sharing

Oh, you meant oaCapture support for Raspberry Pi cam... I thought you meant indi/kstars/ekos support. oaCapture handles devices on its own and does not use indi drivers. I do not know if it supports libcamera - a new API used for HD cam. See this note on introducing new API https://libcamera.org/entries/2020-05-05.html Try using camera with other software eg. INDI/Kstars/Ekos using RPi Camera (indi_rpicam) driver. If it works, you can capture video using Ekos CCD and Live View button located below Sequence List.

What INDI driver did you try?

I wonder how far you land down from my project mentioned earlier in this thread 😉

Actually there were some changes to the gpsd driver recently. I have just pushed them to astroberry repository, so please update (sudo apt update && sudo apt upgrade) and test it. If the issue persists I will take a closer look at the source code.

I have just started a new development project for my weather station, to replace old one which served me for last 4 years or so. The retired version was using: - Arduino Mini Pro (Atmega 328p) + BLE - Weather Meters (wind speed, wind direction, rain fall) - Rain detector (analog humidity sensor) - BME280 (temperature, humidity, pressure) - MLX90614 (cloud detector) - Light detector (optoresistor) Communication based on Bluetooth Low Energy (JSON formatted data sent by weather station every 300s) Data collected by Raspberry Pi inside, running: - Mosquitto server for MQTT publishing environmental data to all other devices at home - InfluxDB (persistent data series) - Grafana (graphs and gauges) I'm gonna keep the sensors and replace the core for the newest Arduino Nano 33 BLE or Arduino Nano 33 IoT. Just waiting for delivery 🙃

BTW. You can use SkySafari to control telescope from your iPad. Just add SkySafari driver to your profile

You must have changed screen resolution. Revert back to something normal

First, download catalogs using KStars menu Data / Download New Data, then take a look at View / HiPS All Sky Overlay / DSS Colored Finally, configure your markers using Settings / FOV Symbols

Wooow! Good to know 😉

One more thing. Have you saved your configuration (Options / Save)? If not, try doing this after setting park position. I'm not sure, but it might help. BTW. if encoders are in use you need to set proper home (=park?) position with your hand controller. Otherwise, whatever you do mount will identify it's physical position based on encoders, ignoring any position saved by software/drivers.

Running KStars/Ekos on PC and connecting via network to INDI server with drivers and devices on Raspberry Pi is not safe in terms of network connection errors. If you lose connection during a session it will be aborted and there is not resume option available. You would have to restart everything from scratch. Likewise everything running on Raspberry Pi is totally network errors proof i.e. losing connection just disconnects you from viewing remote desktop, but everything continues to work on Raspberry Pi. You can safely disconnect and shutdown your PC and reconnect when needed. Including reconnecting from other device to see what's going on with your system running at a scope.

Oh, one more thing - pasting text copied from various guides... When using web interface it is not very convenient, but works very well. When you copy text it goes to a clipboard (as usual), but pasting it requires you to pass copied text to a desktop-in-browser first, for security reasons. So you need to open sliding menu and click clipboard icon on it. Then paste copied text to a text field. After you've done that, the text is ready to paste in the system sitting in the browser. This works the same the other way around i.e. when you want to copy text from desktop in browser, it goes to clipboard in the sliding menu, then you can copy it from your host system and paste it wherever needed. This is a feature not a bug and there is no other way to handle it, keeping remote desktop viewed in browser isolated from host system. Much easier way is to use terminal emulator aka SSH client such as Putty. It lets you connect to this magic black console remotely over the network. Just configure a connection to your Astroberry (default username and password are astroberry) and click connect. What you get is Astroberry console. Copying from it does not require Ctrl+C, just select text and paste it in your host system. If you want to copy any text from host system, copy it as usual and right-click in terminal window to paste it (again no Ctrl+V required). Last but not least... working on console IS much more convenient than you think. You don't need to type every single character. Linux users use so called TAB completion, which auto-complets commands for them after typing a few letters + TAB (once for completion and twice to see available options). Just try it with the most popular command you probably use on Astroberry when updating the system. Type "sudo apt up" and press TAB twice. You will get two options: update and upgrade. Now if you add "d" and press TAB the command will autocomplete to "sudo apt update" but if you add "g" and press TAB you will get "sudo apt upgrade". The same applies to any command you want to use. After you get used to it you realize that it is easier and faster than dozens of clicks. And gives you added value of knowing what's going on in the system. Any error will be visible on the spot. Which is not really the case when you use GUI. Anyway, it's just a point of view of a linux nerd for over 25 years 😉 All the best, clear skies and keep safe. I'm coming back to M57 in Ha. On Astroberry obviously, sitting at my desk while scope is outside 🙃

Hi there! Many questions in one thread but I will try to handle this challenge 😉 First, please take some time and read Astroberry Wiki. It provides answers for some of the questions. For sure it helps to answer "How do I get rid of the Warsaw location in the Astroberry tab?". Don't take it wrong but at least more people know where Warsaw is on the map now 😃 But seriously, Virtual GPS is kind of confusing for many users. To keep it short - disable it if you use real GPS. Weather applet is another story, it does not use GPS and is really buggy. I recommend removing it from taskbar and the problem is gone. I will not add it to taskbar in the next release for sure. Thanks to @TerryMcK for providing answers to some of the questions, before I joined this thread. Calling me by name helps a lot, as I get a notification so I can react. If there is any outstanding issue I will be more than happy to help.

There are some pitfalls too, but keep going 😉

This is fine, no bad feelings whatsoever 🙂

Let's step back. It's all about how GPS works in linux system. Let me explain this To provide system-wide GPS info (location + time) linux system uses GPSD service. It grabs raw data from GPS device and provides it to whole operating system and applications that need this information. KStars is one of such applications, Astroberry panels (GPS and Astro) are the other ones. If you go this way whole system and both applications will get proper GPS data - Astroberry panels directly from GPSD service and KStars using INDI GPSD driver (note the driver's name). What you have done is using your phone as a GPS data source, raw data in NMEA format. You read this data with INDI GPS NMEA driver (note the driver's name) directly to KStars, not using system-wide GPSD service. This means that system or any other application is aware about GPS data. This way you get proper GPS location and time in you KStars but just cannot expect other apps to work this way (namely Astroberry GPS and Astro Panels). See What's difference between INDI GPSD (this driver) and INDI GPS NMEA drivers? section of GPS driver's description. The only way to handle GPS system-wide, including Astroberry panels, KStars or any other application that uses GPS data is using system-wide GPSD service with either (1) GPS device connected to it or (2) virtual GPS simulating GPS device. In the latter case you have to set your location manually as described in Astroberry FAQ: I have not tested it but you can try combining the two approaches i.e. phone as a GPS data source and system-wide GPSD service: 1) Edit gpsd configuration file by running 'sudo nano /etc/default/gpsd' and set DEVICES="" to DEVICES="tcp://phone_ip:port" 2) Replace INDI GPS NMEA driver with INDI GPSD driver in your profile 3) Reboot to activate the changes Note: phone_ip:port should be the same as used in NMEA driver - this is network source for gps data served by your phone.

Yes, you are almost done. Just disable Virtual GPS by running: sudo systemctl stop virtualgps.service && sudo systemctl disable virtualgps.service

😞