Jasem's video on the Android/OS app called StellarMate was shown to be a one stop shop for managing StellarMate. I kicked the tires and found it lacking in setting up StellarMate. Yes, KSTAR Wizards, Site Configuration, and ECHOS setting GPS to set location all work at the OS. None of these options exist in the StellarMate app. In fact, no option exists yet to determine if location is correct. Being off 50 miles is pretty significant. Ok, maybe I was just dreaming an SmartPhone app could set the bar. On my Android KSTARS works well as is. I have access to all of these functions in Android.
I did set StellarMate up like I did AstroBerry. Then, the app StellarMate is a good app for a pre-configured StellarMate system. I like the search for a StellarMate function. I am looking forward to a clear night.
I finally got around to installing StellarMate. The supplied video on the App shows its use like AstroBerry Web.
Within the App, PA is not explicitly stated. Plate solving is. But, one feature I see missing is location. PA and plate solving require explicit location, longitude and latitude. The next big item is the mount. The motors and gears must be synced with RA and DEC circles.
I keep looking for the SYNC button. My home network’s ISP messes up location because it’s Location is 50 miles north. A picture of the sky should be all that is needed.
I am waiting for a clear night free to test this out. Maybe my AstroBerry experience is clouding my StellarMate experience.
Thank you for the tutorial. This encouraged me to consider the app. I do have a question. I saw the tool said correctly the my mount was east point west. I wanted to see if my location was close. Where is the Location for the app kept? I am looking for if I am located at my ISP and not where I am. The ISP is 50 miles north away. I do have my coordinates. Where do I put them in manually?
Ihoujin wrote: I'm configuring a setup from a clean install of Raspberry OS (64bit) and found KStars Master will not compile unless I built and installed stellarsolver first. Therefore this step should be added to the script.
Also, if you have a chance, Please add Firecapture and OaCapture to setup. I have had difficulty installing them myself.
Thank you kindly.
The AstroBerry site has a written tutorial. Http://www.astroberry.io AstroBerry, EKOS, and INDI must know where it is first for a session to be fruitful. If establishing AstroBerry where it is, the next step is to tell AstroBerry and EKOS what equipment you are using for your session.
If you live where the developer lives, Warsaw, PL, then you don’t have to do anything location steps. Every where else in the world must tell AstroBerry, EKOS, and KSTARS the session’s location.
stevenball wrote: Hi, before I realised you could transfer the GPS location from your Ipad to SM, I bought a GPS receiver. I have not managed to get this work, Not sure if its the device or SM, followed instructions, but no joy. Now I want to go back to using the SM app to sync the GPS data for SM. I'm not sure what the settings should be in Ekos and Kstars to do that, as there doesn't seem to be an option for that. its only Kstars, mount or GPS device.
Yes, I did have to configure a /dev/PPS device. The RPI OS setups what is provided by the vendor.
Yes, I did consult this PDF before purchasing and using. I read this statement.
Future u-blox receivers are likely to employ multiple GNSS system times and/or receiver local times (in order to support multiple GNSS systems in parallel), so users should not rely on UBX messages
that report GNSS system time or receiver local time being supported in future. It is therefore recommended to give preference to those messages that report UTC time.
Also, USB dongle and GPIO dongles are two different things. Sufficient to say, the USB version is not producing this error. And given the GPIO pin out identified, this is still a local configuration issue and not a universal alert. As this statement attests, I can confidently use UTC time. Wow! KSTARS uses UTC also. That makes it a win for me.
Here is another.
6.6 Real Time Clock
u-blox receivers contain circuitry to support a real time clock, which (if correctly fitted and powered) keeps time while the receiver is otherwise powered off. When the receiver powers up, it attempts to use the real time clock to initialise receiver local time and in most cases this leads to appreciably faster first fixes.
I added an RTC to assist with faster locks. Also, a state of Static is when the movement Delta is near 0. Then drift is less likely when Static. With limited GPIO pins, USB is the better option. Two options exist for 3V RTC devices. Most exhaust fans block pin 1. I used the second 3V pin group. This allowed use of the RTC.
Under KSTARS and INDI, GPSD is PPS based under Ubuntu. With Raspbian, CHRONY provides time. I would suggest using GPSD and properly configure it. I never thought to use GPS for time. PPS was it.
If a fixed pier is an astronomer’s site, yes, a GPS dongle is wasted money. My site is variable. A GPS dongle solved one problem, taming KSTARS. Stellarium can use INDI to talk with an astronomer’s equipment. Stellarium can use all equipment in INDI. Best $7 I spent to fix my position during my variable session.
U-Blox 7 device provides PPS. PPS is part of their setup requirements. Besides, my KSTARS GPS sampling rate is 15 minutes. Within KSTARS, I can update as needed manually. As long as I know where I am, a GPS dongle, (properly configured), is a welcomed addition.
A more stable site is required for a non GPS use. Preconfigured can be setup. Besides, this is my first thread I have read which said strange things about GPS dongles. I configured mine to meet recommended settings. It worked fine. When I looked CGPS output, I saw 9 or more satellites it was polling from. If a clear line of site, time is pretty stable under PPS.
Not everyone needs a GPS dongle. Setting up a fixed position is one step. Resetting the RPI4B clock requires logging in and setting it manually within a terminal window. All of these steps work great for a remote and fixed site with internet. Internet NTP is pretty stable. GPS dongle is not needed.
No power, no internet, and a variable location is the realm of GPS dongles. Proper setup of GPS dongle use is required. Follow the manufacturer’s recommendations.
I bought StellarMate in 2018. This week I downloaded the image. Using my trusted method of building an image, I created the image on a 400G drive. My first try failed. I viewed the image and only AstroBerry folder was present. My second try produced the obligatory “this drive is no longer formatted” in Windows 10 version 2004. Maybe I zigged when I should have zagged. The AstroBerry empty folder was it.
The third try I did not format the drive. I placed the image over the previous session. This went much faster. I then used my RPI3B+ with Ubuntu to fsck the volume. Sure enough, the volume had a dirty bit. Hmm... I ejected the Volume from Windows. I umounted the volume under Ubuntu. Why the dirty bit? Looks like either the image tool or the image has a dirty bit.
Once the dirty bit was repaired, the volume booted fine. I am now running on StellarMate.
I have a U-BLOX 7 USB GPS. When I was having rule problems, I also had rights problems. I could not save my position. Come to find out, VNC was not showing the child authentication wind to authenticate as Root. While this was going on, I added an RTC to my RPI4B. Did it resolve everything? No. Once I got the rules straightened out, the U-BLOX sets the time, time zone, elevation, and location. I am on Astroberry 2.03.
The FOV of the camera is not aligning with the FITS catalog of objects. The FITS catalog is limited. Download the libraries which match the FOV calcuated by KSTARS. Space on a suggested 32G SSD is limited. I am a 64G and space is still limited.
Why you should use a GPS dongle: GPS is a wonderful addition to mounts which do not have an integrated GPS solution. What does a GPS provide?
2. Time zone
4. Relative Time.
KSTARS has EKOS. Wiithin EKOS, INDI can be configured to be dependent on GPSD. I used the GPS to set the postion and time zone of the session. KSTARS needs both to setup the star catalogs and the position of Polaris and other important celestial objects. Having the location allows KSTARS to point to objects relative to the location. When GPSD is not working, Warsaw Poland is its default location.
So, Yes. A GPSD is necessary when not connected to NTP over the internet. GPSD is better when a RTC device is not installed. Even with an RTC, location is important.