INDI Astroberry provides:
* Astroberry Focuser - stepper motor driver with absolute and relative position capabilities and autofocus with INDI client such as KStars and Ekos
* Astroberry GPS - GPS driver for easy scope location and UTC time setting
* Astroberry AltIMU - accelerometer, magnetometer, gyro, atmospheric pressure sensor driver
* Astroberry Board - power switch board allowing for remote powering on/off up to 4 devices.

The latest changes (version 1.0.3) include:
indi_rpigps - Sync to latest INDI::GPS changes
indi_rpibrd - Added 1) system shutdown and restart buttons, 2) System info (board, uptime, load, ip) 3) System time info
indi_rpifocus - Code improvements

You can download source and binary package from here

Great work Radek! One small note regarding indi_rpigs, you have auto refresh enabled by default. While this is OK, it will keep asking the client (e,g, KStars) and drivers to update their time & location data every second. In fact, I had something similar to your implementation in my first draft of the INDI::GPS class. I had "Update Period" property which would send an update every X seconds out to the clients & drivers, but I dropped it because in reality you'd probably want to do this operation only once on startup. That is unless you expect the client and driver clocks to drift in a very short time which isn't usually the case.

Also drivers like LX200 would send the time and location info to the hand controller, and you'd probably don't want to do that every second!

Jasem you are absolutely right. However after lots of thinking I decided to leave it this way and add Autorefresh button to the driver, so users can switch it off after gps fix is obtained. Because time and location values are snooped to telescope you cannot just disconnect gps driver after fix is obtained because you loose the values of these parameters. Therefore the workflow should be:
1. Connect telescope and configure snooping device to Astroberry GPS
2. Connect Astroberry GPS driver and wait for 3D FIX
3. Disable Autorefresh
4. Enjoy
Such an approach is actually required to trigger gps data stream from gpsd. Otherwise users will see no gps data at connection. Calling updateGPS() onec at connection is not enought (as you do in INDI::GPS) because gps data stream is does not contain all necessary packets before a fix is obtained.
Let us try this one and maybe in the meantime we will figure out how to procede from here.

BTW. For all of you willing to use gps as a location and time source - indi_rpigps is not raspberry pi specific and can be used on any linux based system, providing you have gpsd service installed, configured and running.

Radek

PS. I gave it a second thought and I believe that we have another option i.e. remove Autorefresh button and stick to the standard INDI::GPS Update button BUT use a while loop in the updateGPS() function to read gps data and autorefresh until 3D FIX is obtained. As soon as there is a gps fix stop autorefresh. Update button would trigger the update procedure from scratch. What do you think? If you're OK with this I will do necessary changes to the code and compile the binaries for testing.

One thing to note is that updateGPS() is _not_ supposed to send data to the client. It says this specifically in the documentation (no IDSetXXX within updateGPS()). In updateGPS() only the values and states of TIME_UTC and GEOGRAPHIC_COORD are changed.I think a better solution is as following:

1. Upon connection, updateGPS() is called. If GPS stuff are ready (unlikely), simply return true, otherwise false. It would still proceed to define TIME_UTC and GEOGRAPHIC_COORD but the state is ALERT so anything they have is discarded.
2. in INDI::GPS I will SetTimer(1000) and in TimerHit() I will check if updateGPS() is true or false. If false, I will SetTimer(1000) again and again, until updateGPS() is true. If it is true, I call IDSetXXX and TimerHit is never called again.
3. If user wants refresh, they use the refresh button.

Is this solution acceptable to you?

Let's go for it. I will do necessary changes in indi_rpigps as soon as you release new version of indi libs.

Ok done. I made another change so now updateGPS() will return a state (Ok, Busy, Alert) with Busy being waiting for GPS fix so that the client at least knows it is in progress visually as well. In updateGPS() if GPS fix is in progress, TIME and LOCATION properties are set to IPS_BUSY and you return IPS_BUSY as well. Same goes for IPS_OK and IPS_ALERT.

Dear all.

That great as a short proposal (even with a lot of information provided by me when I openned the EQMod snoop and GPS topic) gives interresting remarks and a nice result.
From another topics related to chain Indiservers, I just saw that snoop messages are not forward to the next indiserver If I attach my GPS to another indiserver than the mount one, it wouldn't be work (or I do a mistake?). In fact this is not an issue for me, but maybe for somebody else, as Radek wrote the GPS driver could be build for any other linux PC, not only for RPI.

Very best regards.
Philippe.

This is very interesting topic. It does apply also for rpi/arduino based weather stations, which could run bunch of useful sensors and forward their status to master indi server. This might be a good point for a change request in Wish List section.

I never checked snooped properties over chained servers, will do and check the results.

Hi Jasem.
I'm not sure what you have done, but now I've snooped issues. WIth my "develop" config on Unbuntu 14.04 and on the EKOS VM too since I've apt-get upgraded it to day. The simulator instance of the telescpope is not updated with GPS simulator value....
I saw you check the "name" value against "IPS_OK", but it shoudn't be against "Ok" instead? as the XML message contain this value, not the IPPState.
Regards

Yes good catch! Sorry for that stupid mistake!

Jasem, one more thing related to INDI::GPS and INDI::GPS::ISNewSwitch function specifically.
I believe we need to change the way the refresh button works. It calls updateGPS() function directly whereas it should actually call SetTimer(POLLMS). Otherwise after loosing gps fix the only option would be to disconnect and reconnect to get a fix. This would be also consistent with the way we handle the first gps update and IPS_* flags in driver's updateGPS() function.

BTW. I noted that the timer is not removed when gps is disconnected. This results it calling updateGPS() function even though the device is not present anymore. We can either set a new timer conditionally if gps is connected or remove a timer when gps device is disconnected.

Best regards

Radek