Last night I tried my first session with my RP4 2gb running KStars on Raspbian.
Polar alignment ran perfectly and smooth (also in full screen).
Guiding ran so I started a small imaging session of 1x60s, 1x120, 1x180, 1x240 and 1x300s subs. During the 180 sub, I wanted to check the Stars on the 120 s and my messing about with the fits viewer, while guiding and taking a 180s sub, caused KStars to crash.
After restarting and reconnecting etc I tried the same imaging session again, this time leasing the poor fits viewer alone. This time no crash.
I then slewed to a New target, solved and synced and started a one hour session of 30s subs - no problems. Darks, Bias and flats afterwards without problems.
So I’ll just try not to push my 2GB RP4 too hard I did notice that my cooler fan was running pretty much all the way through my session.
Just tried again last night, this time with my Raspberry Pi 4 instead of my Mac. Did a rough polar alignment, forgot to level my tripod etc and then ran the Ekos Polar alignment tool. This time no problems, the crosshair was very close to my selected star and only very small adjustments needed to center the star. I haven’t changed anything in my setup besides changing from Mac to RP4. I’m happy.
I've been looking at the Stellarmate App as a way to check and control my setup during the night instead of VNC on my phone. But I'm not really sure how this works.
Do you need the Stellarmate OS or just KStars/Ekos (eg. from rlancaste's AstroPi3 script)?
Do you need an Ekos Live (free or paid) account?
The free version includes 500 MB/month - how is this calculated? 500 MB will run out very fast if just checking some images during the night, focusing and guide calibration. Or am I missing something?
Sorry for the really stupid questions
I can't wait to give this a try again in the (hopefully) near future.
Vox45 wrote: That is interesting. Would that mean when I was only clicking once it was showing the crosshair on the other end of the purple line but I could not see it as it was off screen ? If so, what is the purpose of bringing the crosshair to the other side of the purple line when clicking twice ? As you can see in the screen shot I was centered in that crosshair but the alignment is out by 1° ... This is odd
All the times I've tried to PA I could only see the Purple line across the entire FOV. When moving as far as possible along the line and then redoing the PA to get even closer, I was told be Ekos that the NCP was outside my FOV, eventhough I should've been closer than my initial PA. When the weather clears (should be within the next decade or so ) I'll give it a try again and double clicking this time (I've moved from running KStars/Ekos on my Mac to running it on a Raspberry Pi 4, but haven't had a chance to test it yet).
I think we need some of the developers to look at the thread. Maybe they can tells us about the double click etc.
Ok, I just tried the PA tool in the simulator. That shows the crosshairs right away. Clicking a star moves the purple line and crosshairs to the new location. When double clicking a star, the crosshairs moves to the star in the other end of the purple line. So I don't think you are supposed to double click a star?!
Vox45 wrote: -> when I get to the final screen, I double click on a star in the field to get the correction vector's crosshair
(It took me a while to understand what was happening as I was only "clicking" on a star as it is instructed but only clicking once only moves the purple line to the star but does not show the crosshair...)
Wow! It's also news to me that you need to double click a star. I always just end up with a purple line, but no crosshairs (except the first time I tried - maybe I double clicked by accident then?) so I haven't been able to PA correctly yet. I'll give the double click a try next time.
If your PA error is too large afterwards, then just try and redo the process. This should help improve the PA - I guess.
I just tried inserting a USB stick into one of the USB ports on my RP4 (installed Tuesday this week). It worked without problems. Tested in both the USB2 and the USB3 ports. All worked.
rlancaste wrote: One thing I should clarify for #2. If your laptop has an IP address on wifi, it might get a 192 address. That will make it less likely for it to connect to the Pi if it is not on a network and has a 169 address. Turning off your wifi on your laptop will force it to get a 169 address allowing them to start talking. Once you are connected, you can tell the pi to connect to a network, enter passwords, etc. And then disconnect your laptop form the Pi and turn back on your wifi. Then you can connect wirelessly.
When i tried the direct link my laptop’s WiFi was disabled, so only the direct link Ethernet connection was present. It was first after a while that I opened the WiFi connection again and logged on to the Pi to check IP etc.
One thing though, is that my MacBook Pro is without native Ethernet port. I use a Thunderbolt to Ethernet adapter from Apple. It works perfectly when connected to normal LAN and it gets an IP from the Raspberry Pi, so it should work - but it doesn’t.
1) KStars didn’t save my location, Windows size etc. Ekos did. Turned out that the users .config folder was set to root user and group. Running “chown pi.pi -R .config” did the trick. Maybe this should be included in the script?
2) I’ve set up static ip in the script to 169.254.0.1 (my laptop was 169.254.x.y). But it doesn’t work when connecting my laptop to the Pi with an Ethernet cable. I get an IP adress, but I can’t make any connections to the Pi (VNC, SSH or even Ping). WiFi works perfectly, normal LAN works perfectly and I guess that Hotspot works too (haven’t tried it). Using WiFi I can see the Pi gets the correct IP on the direct link etc, but it doesn’t work.
3) (not really script related I guess) But when the Pi is connected to my local LAN using Ethernet it also connects via WiFi. Priority for WiFi set to 0, Ethernet to 1, HotSpot -1 (I think) and Direct link to 5. Why is WiFi also enabled?
rlancaste wrote: You can just re - run the script later to set up the static ip. You should really know what IP your computer self assigns to itself before doing this. It *should* be in the 169 range, but it is not guaranteed. That's easy to test, just:
1. disconnect your laptop from any network by going far away
2. (maybe) connect the ethernet cable between the pi and your laptop (This may or may not be needed to make it give itself an IP)
3. Take a look at what IP address your computer self assigns.
Do you mean that it wanted to update the software before or after you ran the script? One of the steps in the script is to update everything. So I would be surprised if it had another update after that. But yes, you can let it update things if you like.
Be sure to test everything inside thoroughly before going out under the sky. Do it with the simulators, and then later do it with real equipment. Then try doing a real observing session.
Ok, I’ll run the astropi3 script again then for the IP setup. Or can I do it a quicker way?
But it’s just a normal Ethernet cable, right?
It was first time I booted after your script KDE told me that it would Update the software. I’ll let it do it next time then.
AstroNerd wrote: You sure do need a fan on the rpi4, don’t try and run without one as you will throttle the CPU...it’s a must in these little things..
Yeah, I was a bit surprised about that, cause I’ve had multiple RP3’s with only passive cooling that never got hot. The RP4 was hot right after first boot of Rasbian. So I ordered a fan right away, should come today or tomorrow latest.