Hi Christian
Have you tried updating the system with standard sudo apt update && sudo apt upgrade?
These software packages depend on linux-firmware package, which provides support to various cameras. I cannot help with QHY because I don't have one. Anybody else using astroberry and QHY?

Read More...

Normally you configure these in the telescope driver (options tab). Profile refers to Ekos profile. If you don't use a typical driver for your telescope you can always use Telescope Simulator and configure the parameters there. Don't worry about warning related to config file not found - as soon as you click Save on Options tab it will be found the next time.

Read More...

BrianH wrote: When i restart it still defaults back to Fri Feb 12, 02:28!!!!!

This is really strange. I use RTC and do not do anything more than already said. My RPi gets the time from RTC every time it reboots.
I have just checked and found out that in case of your module you should have dtoverlay=i2c-rtc,ds1307 in /boot/config.txt (NOT what I use: dtoverlay=i2c-rtc,ds3231 because I have different RTC chip connected). Can you double check this?
Also please check if the time is OK after reboot WITHOUT disconnecting power from RPi. If it OK without diconnecting the power but it is not if you disconnect the power, your RTC battery is dead.

Read More...

Instead messing with the daemon configuration I would suggest stopping the service and running gpsd in a foreground (-N) in a terminal window.

Read More...

stash wrote: So my question is in this case,a UBLOX7, will the hard coded serial not cause a problem ?

I don't know how gpsd prioritizes hardcoded serial device vs USBAUTO. If the former has precedence, it might cause a problem.

stash wrote: 3. I do not have any of the PPS/GPSD lines reported into my logs (even if the UBlox7 is not plugged in) but except your reasoning for the difference.

It might be. By just setting GPSD_OPTIONS="" you don't make gpsd daemon to try polling data in the background. These log entries might appear if you try to reach gpsd daemon with a client while GPS device is not connected.

I do appreciate your input. It is of the highest value for users that encounter issues while configuring their system to their needs. I wouldn't be able to handle all possible requests myself.

Happy New Year and clear skies !

Read More...

stash wrote: Astroberry image set up does cause problems even when you don't have a GPSD installed .

What kind of problem does it cause? I can't see any in the attached logs. These are absolutely normal log entries if you don't have GPS connected to /dev/ttyS0 or PPS signal is not available to kernel (separate connection required, not available for USB dongles AFAIK).

Let me explain it.
GPSD service gets GPS data from a device over a serial port. If you don't get valid NMEA data over your serial you cannot expect GPS working.
Default configuration in Astroberry Server assumes you connect your device to hardware serial port available on RPi on GPIO (pins 8 and 10) hence serial device in /etc/default/gpsd is set to DEVICES="/dev/ttyS0". If you connect your device over USB there's nothing on /dev/ttyS0 (gps is not connected to hardware serial on RPi!) and you need to change the configuration to (presumably) DEVICES="/dev/ttyUSB0" (or anything else, depending on how the system recognizes your device). After changing configuration restart GPSD service (sudo service gpsd restart) and you should be fine. If you're not, you need to check your serial. Stop GPSD service (sudo service gpsd stop) and connect any serial terminal (minicom or miniterm or screen or whatever you like) to GPS serial port e.g. miniterm /dev/ttyUSB0. You should see NMEA data flowing from your GPS device. If you don't it is either wrong serial port or wrong serial speed.

And last but not least - please review carefully gps drivers description. There are two of them, namely GPS and GPS NMEA .

Read More...

Hi Clive
The "-n" option is configured intentionally so gpsd daemon gets the fix as soon as possible and GPS data is available to a client right after connection. See gpsd manual:

-n Don't wait for a client to connect before polling whatever GPS is associated with it. Some RS232 GPSes wait in a standby mode (drawing less power) when the host machine is not asserting DTR, and some cellphone and handheld embedded GPSes have similar behaviors. Accordingly, waiting for a watch request to open the device may save battery power. (This capability is rare in consumer-grade devices).

It is configured in /etc/default/gpsd (see GPSD_OPTIONS="-n"). Users are free to change it setting GPSD_OPTIONS="" - AFAIK the only impact would be longer fix time, since gpsd will poll data from GPS device only if a client is connected (so no ready to use gps data at connection time).
I have no idea where the "-N" option comes from. It is not explicitly configured anywhere in the Astroberry Server.
I think none of the above would influence the results, but feedback is much appreciated.

Read More...

Yes, it is. The hardware clock is connected properly (a device with address 0x68 is connected over I2C, and it's being used by a system module - UU). Just play with hwclock command now and you will be fine.

Read More...

Bisque Paramount , QSI CCD and FocusLynx are supported by INDI drivers. All you need to do is to connect the focuser and CCD to RPi with USB cable, add devices to your Ekos profile, start and connect. If there's any problem with it please provide some more details i.e. logs, screenshots.

Read More...