RadekK

Yes, as @stash_old said KStars uses positive numbers for longitude i.e. 0-359 instead -180 - 0 - 180 (don't ask me why). However it does not influence anything except introduces some confusion. Regarding the time - GPS provides UTC time with no time zone info.

You guys are faster than light! I have announced new site just today afternoon and you discuss it since Wednesday 😉 There were many request on system documentation in one place so I decided to refresh a website and add own wiki so community can share guides, how-tos etc. I hope it will be filled up with instructions very quickly. I have a long list of guides to publish myself but feel free to share your experiences as well at https://www.astroberry.io/docs/

PARK is mount's "position at rest", which by default is scope looking to north pole, counter-weight down. A system must know that your scope/mount is in this position to park back to this position. How it can be achieved depends mainly on a mount because not all of them support HOME... I would suggest the following steps to set things up: 1. Make your mount find HOME with a hand controller and shut things down. The scope should be pointing to north pole, counter-weight down. If it is not, release clutches and set it to this physical position. If your mount has encoders and it's not pointing right, there is some other problem and you should stop here, read and play until mount is pointing as described, before moving to step 2. 1. Connect everything (INDI with drivers, Ekos started) 2. UnPARK your mount 3. Go to INDI control panel / Site Management tab and click Current, then Write Data - this will set your current position as PARK position and save it to a file 4. Click PARK - at this point only mount status should change to PARKed, but your mount should not move at all (see point 3). 5. Click unPARK - no move expected, mount ready to slew 6. Slew your mount to any direction 7. PARK - your mount should come back to position set in point 3 8. From now on use PARK/UNPARK only. In case there is some major failure e.g. you loose power the middle of a session, you would have to find HOME again. YOur PARK position should not change though. If it does you need to recalibrate PARK position again.

Not really the case for Raspberry Pi. microSD card cannot be just formatted to exFAT as it must contain at least two partitions i.e. vFAT and root EXT4. The former is a boot partition required by Raspberry Pi, the latter contains whole operating system.

I promise that I will add nice looking GUI to edit location in the next release! In the meantime run sudo nano /etc/location.conf When asked enter astroberry password. When finished editing your location use Ctrl+o to save and Ctrl+x to exit. Reboot and you will be at home 😉

As far as it can be controlled by video4linux2 (V4L2) as a regular webcam, it can be handled by INDI with indi_v4l2_ccd driver. AFAIK the latest raspbian provides support for V4L2 for these cameras so it shouldn't be a problem. I have not tested it though, so it's just a guess

New version of Astroberry-DIY driver has been just released. v2.6 * Major changes and new functionalities added - added: Support for DS18B20 temperature sensor - added: Temperature compensation - added: Resolution unlocked from 1/1 to 1/32 microsteps - added: Changing to lower resolution fine tuned - update: system info driver separated from board/relay driver - update: default BCM pins changed (!!!) Sources: https://github.com/rkaczorek/astroberry-diy Binary for Raspian Buster: https://www.astroberry.io/

BTW. I took my time and added GPIO pins configuration to Options Tab. No more recompiling if custom pins are used!

@Gina et all, I have just released astroberry-diy drivers (including focuser, relays and system info). This version is independent of WiringPi and BCM2835 low level control libraries. Instead I decided to use the latest libgpiod, which uses mainland kernel character device. This makes the driver totally independent from any external library. As for now the driver need some testing so it is kept in separate branch. As soon as you test it and confirm it works ok I will move it to master branch and release debian packages. You can grab the source code by running: git clone https://github.com/rkaczorek/astroberry-diy.git cd astroberry-diy git checkout libgpiod Make sure that you have libgpiod-dev package installed before compiling this version. The compilation should go smoothly by running: mkdir build && cd build cmake -DCMAKE_INSTALL_PREFIX=/usr .. make make install Please let me know if it works as designed

Well, it should not cause any problem whatsoever. Except python 2.x is obsolete now 😉 However if it works it works.

Add bs=8M when using dd 😉 bs it stands for block size - it will significantly shorten the time

Add status=progress when using dd 😉

Run the following to grab the version with BCM support: git clone https://github.com/rkaczorek/astroberry-diy.git git checkout 3283e99

At first I have been surprised by what @JamesF said but I have just read this http://wiringpi.com/wiringpi-deprecated/ So it looks like wiringPi will not be maintained anymore 😞 It's really bad news. However I fully understand Gordon. Maintaining a software is a nightmare nowadays. Few understand how much work it takes and how many nights one has to invest to keep things running for others for free. Having said that I will have to move astroberry-diy back to BCM2835 library. It will take a while though so stay tuned.

Are you sure that the site is not available? I have just opened it and downloaded latest wiringpi from https://project-downloads.drogon.net/wiringpi-latest.deb

Hi @Gina Remove wiringpi installed with apt and use the latest version from the author's site http://wiringpi.com/wiringpi-updated-to-2-52-for-the-raspberry-pi-4b/ The driver used to support low level library designed for raspberry pi only (bcm2835) and wiringpi. The latest version uses wiringpi only as it makes it more generic - now it can be used on other devices than raspberry pi and is not limited to a specific version of raspberry pi.

Thanks for sharing. Default gateway set to 0.0.0.0 is strange indeed. This must be an isolated case. I have reviewed and retested configuration on fresh system and I always get proper gateway from local dhcp servers. I will keep the configuration in the image as it is now unless this issue is reported by other users. Clear skies!

Can you share the solution providing specific details here? https://github.com/rkaczorek/astroberry-server/issues

Astroberry 2.0.0 is built on top of official "Raspbian Buster with desktop" (Release date: 2019-09-26). You can install it on "Raspbian Buster with desktop and recommended software" following commands on https://www.astroberry.io/

Hot Spot uses standard functionality of Network Manager and the only thing that Astroberry does is... adding predefined hot spot connection. If it does not work it must be Network Manager issue or (as stash suggests) local issue.

I second BME280. Very reliable. I'm using it outside for last 2 yrs. No problem whatsoever The easiest way to build descent weather station enclosure is to use... flowerpots, or actually their parts. See the image blow.

At least your mount is in predictable and controllable position, so as soon as you reconnect INDI client (=KStars/Ekos) you can park safely instead of manual intervention. Same for focuser position. The rest does not matter.

You made my day with this comment If I sound like Arnold I will make more videos then There is one, but very important benefit - if you start indiserver and drivers from within ekos (locally) they will crash along kstars/ekos (if it happens, and it sometimes does), if you start them independently from ekos, they keep running whatever happens to kstars/ekos

Don't worry. Let's leave it to other people for testing