Gilles Gagnon created a new topic ' Persistent serial port mapping and /dev/bus/usb/00x/00y' in the forum. 7 days ago

I use persistent serial port mapping for my all my serial devices with virtually no problem (e.g. /dev/mount, /dev/filterwheel, /dev/focuser,...), except that once in a while a device connects as /dev/bus/usb/00x/00y instead of /dev/ttyUSBz and the port mapping doesn't work. This seem to happen when I disconnect/reconnect the device or if I connect it after the system as booted. As I ideally do not want to reboot to correct the problem, I wonder if there is a reason/solution/work-around to this issue.

Thanks.

Read More...

Gilles Gagnon replied to the topic 'More RTC madness!!!!' in the forum. 1 week ago

Thanks for reviving this thread. You made me realize that my suggestion (in #34237) of putting "hwclock -s" in rc.local was not quite correct; sorry for that.

In my case, what worked was to put "/sbin/hwclock --hctosys" in rc.local (before the "exit 0"), not "hwclock -s" as mentionned in my previous post. "--hctosys" will set the system time and date with the time/date from the hardware clock.

Sorry for the confusion, must have been my winter cold :-/ !

Read More...

Gilles Gagnon replied to the topic 'More RTC madness!!!!' in the forum. 3 weeks ago

Hello Brian,

When I issue "date; sudo hwclock -r" I get an output similar to yours. I don't have any Internationalisation Options in raspi-config either.

Have you tried adding "hwclock -s" in /etc/rc.local, before the "exit 0" line? It solved the problem for me.

Good luck.

Gilles

Read More...

Gilles Gagnon replied to the topic 'More RTC madness!!!!' in the forum. 3 weeks ago

Just as a follow-up, adding hwclock -s to /etc/rc.local worked! The system clock is now set correctly when the system boots.

Thanks again.

Gilles

Read More...

Gilles Gagnon replied to the topic 'More RTC madness!!!!' in the forum. 3 weeks ago

Thanks for the info Radek.

I'll add "hwclock -s" to rc.local and see if it fixes it when I get back home. Hope its "as simple as that", and that the solution can work for Brian and others.

Gilles

Read More...

Gilles Gagnon replied to the topic 'More RTC madness!!!!' in the forum. 3 weeks ago

I could also make use of the information on making the RTC set the system clock as I am in a similar situation. Stellarmate raspi with a DS1307 RTC which, from what I understand is a "less precise" DS3231.

I have the same dtoverlay line in my /boot/config file; the RTC driver is loaded, from the i2cdetect command; haven't checked the output of lsmod | grep rtc. I know the RTC is accessible and works as I can issue hwclock -w and hwclock -r command to set and read the RTC but the RTC date and time won't be used at boot time to set system date and time. I can always set the system clock manually after boot but I would prefer the system to set it up automatically, especially in a headless configuration.

Any help will be appreciated. Thanks in advance.

Read More...

Gilles Gagnon replied to the topic 'Script to set system date from GPS' in the forum. 2 months ago

Thanks for this info. This GPS NMEA solution is simpler than the GPSD one, plus it frees a port on my USB hub and there's one less cable in the way. Great!

Read More...

Gilles Gagnon replied to the topic 'Script to set system date from GPS' in the forum. 2 months ago

I think you are correct in your assumption. If KStars is running on a machine connected to the Internet, that machine will have correct time and position, and will likely pass the information to the rpi but I haven't tested this configuration and as such can't be certain.

My solution is meant for people who observe/image on the go without access to the Internet for current time and position information. If your position is fixed, there is not much use for the script.

Read More...

Gilles Gagnon replied to the topic 'Script to set system date from GPS' in the forum. 2 months ago

GPS may not be as relevant for fixed installation, as you set your location once and you're done, but it may come handy for those who observe/image on-the-go, at different locations and without internet access.

As far as using the script to set the system time; as per the INDI configuration panel, KStars can get the date/time and position info from gpsd but from what I found out, only the position is passed correctly. The time is taken from the system time which is not correct if it's not set via a real time clock and don't have access to the Internet for ntpd.

BTW, I found the series of posts about your remote pico observatory. Great work and it gives me ideas on how to build one for my installation.

Read More...

Gilles Gagnon created a new topic ' Script to set system date from GPS' in the forum. 2 months ago

For those who may find this useful, I have adapted/written a short script that reads from 'gpsd' and sets the computer system date. If you don't have an RTC on your computer (Rasp Pi, Odroid, etc...) or access to a network and/or 'ntpd' (remote nomad operation), the script is useful to set the correct date and time for kstars. Normally the script should be started at boot time, after 'gpsd' is started but I am not sure where to put it (rc.local or other startup scripts).

It can be run manually using 'sudo' ( sudo /file/path/gps_set_date ) but making it automatic would be the best. Furthermore, as I haven't been writting scripts in a long long time, so improvements are welcome, and consideration for the timezone may be needed. See below for the script which works on my Odroid XU4Q running Ubuntu Mate 18.04 LTS, KStars 2.9.8, Ekos and INDI.

gps_set_date:

<strong>#!/bin/bash

if [ ! -e "/dev/gps0" ]
then
exit
else
GPSDATE=""

until [ "$GPSDATE" != "" ]; do
GPSDATE=`gpspipe -n 10 -w | grep TPV | grep -e '"mode":[23]' | grep '"time":' | sed -r 's/.*"time":"([^"]*)".*/\1/' | tail -1`
done

date --utc -s "$GPSDATE"
fi
</strong>

Read More...

Gilles Gagnon replied to the topic 'indi_lx200_OnStep driver or OnStep firmware ACK problem' in the forum. 3 months ago

As a followup, I was told that this is a Teensy issue that can be circumvented by running a Python script prior to connecting the OnStep controller to indi. So, case closed but I can provide those interested with the information.

Read More...

Gilles Gagnon created a new topic ' indi_lx200_OnStep driver or OnStep firmware ACK problem' in the forum. 3 months ago

It seems there is a ACK handshake problem between the indi_lx200_OnStep driver version 1.3 and the OnStep firmware 1.8s under Ubuntu 18.04 LTS. Things work OK under Ubuntu 16.04 LTS.

My configuration: ODROID XU4Q, Ubuntu Mate 18.04 LTS, MiniPCB OnStep with 1.8s firmware.

OnStep won't ACK (special command 0x06) with indi unless I send a command to the controller (e.g. ":GVN#") from a serial communications app such as 'cutecom'. Once I do that, the ACK between OnStep and indi will happen and things will work. I looked at the code from both lx200_driver.cpp (indi) and command.ino (OnStep) but could not see anything obvious.

I am attaching the indi log file below for info. I will also submit to the indilib group.

Any help will be appreciated. Thanks.

Log file:

INFO 24.572425 sec : Session log file /home/gilles/.indi/logs/2018-11-10/indi_lx200_OnStep/indi_lx200_OnStep_17:29:03.log

DEBUG 30.811541 sec : Connecting to /dev/OnStep

DEBUG 30.812563 sec : Port FD 8

DEBUG 30.812632 sec : Connection successful, attempting handshake...

DEBUG 30.812684 sec : Testing telescope connection using ACK...

DEBUG 40.917488 sec : Failure. Telescope is not responding to ACK!

DEBUG 40.917599 sec : Handshake failed.


********* This is when I sent a command to the OnStep controller with 'cutecom'


DEBUG 130.431524 sec : Connecting to /dev/OnStep

DEBUG 130.431833 sec : Port FD 9

DEBUG 130.431900 sec : Connection successful, attempting handshake...

DEBUG 130.431964 sec : Testing telescope connection using ACK...

DEBUG 130.436976 sec : Testing successful!

INFO 130.437053 sec : LX200 OnStep is online.

DEBUG 130.439580 sec : Configuration successfully saved for DEVICE_PORT.

DEBUG 130.442179 sec : Configuration successfully saved for DEVICE_BAUD_RATE.

DEBUG 130.445073 sec : Configuration successfully saved for CONNECTION_MODE.

DEBUG 130.467094 sec : Site Name <Test>

DEBUG 130.482126 sec : Mount Controller Latitude: 0 Longitude: -0

DEBUG 130.497170 sec : Mount controller UTC Time: 2018-11-09T22:15:29

DEBUG 130.497281 sec : Mount controller UTC Offset: -5.00

INFO 130.517644 sec : Mount is unparked.

DEBUG 130.518061 sec : InitPark Axis1 0 Axis2 0

INFO 130.518150 sec : =============== Parkdata loaded

INFO 130.528279 sec : Mount is unparked.

DEBUG 130.528585 sec : InitPark Axis1 0 Axis2 0

INFO 130.540937 sec : Site location updated to Lat 0:00:00 - Long 0:00:00

INFO 130.541724 sec : Debug is disabled.

DEBUG 130.545900 sec : Active Snoop, driver: Dome Simulator, property: DOME_PARK

INFO 130.556936 sec : Site location updated to Lat 0:00:00 - Long 0:00:00

DEBUG 130.558274 sec : Configuration successfully saved for GEOGRAPHIC_COORD.

INFO 130.559079 sec : Pulse guiding is enabled.

DEBUG 130.559420 sec : Configuration successfully loaded.

DEBUG 130.805379 sec : Configuration successfully saved.

INFO 131.461171 sec : Mount is unparked.

INFO 134.147493 sec : LX200 OnStep is offline.

Read More...