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.
KSTAR 3.5.0 has been in the wild for a while. When is KSTAR 3.5.0 going to be ready for Astroberry? Can this be updated manually?
I use the 4G model with Buster. For a time, a rash of updates would cause the device not to boot. I used my RPI3B+ with UBUNTU to fix file system privileges. I reviewed boot logs to find the ailing load process.
Yes, I do understand. However, the way Astroberry works and the way the NexStar works are completely divergent paths. Here is why.
The Hand Controller is another Astroberry. What I am reading is Astroberry plugging into Astroberry. This is why it isn't working.
The RPI4B must be plugged into the Mount and not the Hand Controller. The Astroberry must use the ST4 port and talk with the mount. Astroberry talks with Mounts. Selecting a Mount is the critical path requirement. Every Profile must contain a Telescope Emulator to save.
The referenced USB cable plugs into the input port of the controller. The referenced cable plugs into the PC. This is a closed loop. The “and” is missing. That “and” is the mount. The PC must see the mount. The controller sees the mount. The PC sees the controller only. The mount contains the RA and DEC motors. Motors are controlled by the hand controller in this NexStar model.
Something must happen for INDI to see the mount. One method is to use the ST4 port. The PC would see the mount through the ST4 port.
The Adafruit HAT can control RA and DEC motors which are accessible through a port or wiring. I use an AstroEQ to manage my external RA and DEC. To me, the Adafruit must have a custom cable to manage the mount through the ST4. The Adafruit and RPI4B replace the controller.
I am suggesting a picture of the assembly be taken to see how these three devices are being implemented. Add the picture here.