Raspberry Pi Guiding Newbie

[pete_81]

Hi @SiD the Turtle, thanks for your input. I'd rather have lots of comments to view through and try to figure out which setup is likely to be best for me...
Had thought about using PHD2 just from the amount of readily available help it seems to offer, and I've looked at PHD GUI compared to the internal kstars guiding one, just to get focus and connections tested, but once focused, star select, then press 'go' just sounds nice! (as appears to be case with PHD, not that I've got into the internal one yet...)
Not looked at plate solving, need to get the above setup completed and at least try to capture some images with camera control from RPi (tested it today for basic functionality on the MBP but I've not actually ever ran guiding, camera and mount control from the same computer up to now), hence want to get this solved, then plate solving after, but yes, agreed that it's something to do once basics are addressed.
I'm sold to the ethernet connection from the RPi, with wifi again being frowned upon so heavily!
For the RPi4, what classes as an 'appropriate case'? Is the little red & white one suitable or stay clear?
Also, for the RPi4, now that I have all working, what size (RAM) is 'minimum'? Obviously the 400 has 4GB which seems to be plenty, but is there any gain going to 8GB? Obviously it's not going to be used to do the image manipulation, just guiding & controlling mount + cameras (and vnc for image transfers as they'll be saved local (perhaps backed up on the Nikon SD, but accessing from RPi to transfer seems the easiest way to go at this point)

[teoria_del_big_bang]

Regarding cases I don't think the standard red and white case has any form of cooling and if the RPi gets hot then it automatically slows it down.
So would stay clear of the standard case for £5 or whatever it is and get a metal one with passive cooling like this FLIRC case

Now a metal case does well for cooling but does reduce the effectiveness of the WiFi but if you are using Ethernet then that is not an issue.

Regarding memory I have been told that 4 Gb is fine and that you will see no significant improvement with 8Gb.
I have both the 4Gb and 8Gb RPi 4 and although not tested both thoroughly certainly nothing is standing out to say the 8Gb is a vast improvement.

Steve

 

[SiD the Turtle]

• Connection- are you thinking of running ethernet outside then? I would have thought that'd be a pain/another cable coming out of the house.
• Case- yep I'm using the FLIRC case that's been mentioned previously. It does get pretty warm in the standard case: https://thepihut.com/products/flirc-raspberry-pi-4-case. I've not worried about water ingress or anything like that as I'd like to think I'd run everything inside if the heavens started to open, but you can get rubber caps if you are worried.
• When I bought the Pi 4 the choice was between 2GB and 4GB, there was no 8GB model. I opted for the 4GB model and to be honest I don't see that the CPU or RAM has been maxed in its lifetime. Even plate-solving, would you believe it. In hindsight I would probably have been okay with the 2GB, though the 4GB does give you a bit of future proofing if you ever decide to re-purpose it for something else in future.
• You are right about plate solving- focus on getting an image out of the setup first. But once you have the image if you set up plate solving if you want to hit that target again, you feed it a pre-existing image and it'll solve then auto rotate the whole setup to exactly the same place. I'm targeting Andromeda at the moment and it makes it super easy to frame, seeing as it fills my FoV.

[gilesco]

18 minutes ago, SiD the Turtle said:

When I bought the Pi 4 the choice was between 2GB and 4GB, there was no 8GB model. I opted for the 4GB model and to be honest I don't see that the CPU or RAM has been maxed in its lifetime. Even plate-solving, would you believe it. In hindsight I would probably have been okay with the 2GB, though the 4GB does give you a bit of future proofing if you ever decide to re-purpose it for something else in future.

I can only see the 8GB version being an advantage in the future, perhaps when people move to a 64-bit version of Raspbian, and then perhaps if live stacking is added to the platform.

However, the Linux kernel always benefits from extra memory, it serves as a buffer and cache for disk reads and writes. Not just in userspace but system space too. 

[fozzybear]

Iv'e got all my rpi4's in Flirc cases they do keep the cpu cool

[fozzybear]

must get a dymo machine to label them up

[SiD the Turtle]

15 hours ago, gilesco said:

I can only see the 8GB version being an advantage in the future, perhaps when people move to a 64-bit version of Raspbian, and then perhaps if live stacking is added to the platform.

However, the Linux kernel always benefits from extra memory, it serves as a buffer and cache for disk reads and writes. Not just in userspace but system space too. 

Completely agree, it'll come down to your requirements and available cash at the end of the day.

For me personally I find the semi-regular release of new RPIs and my love of tinkering means buying the top end model might not make sense as the next new model might have something I want that would replace it- for example USB 3, faster processor etc. So the most demanding requirement gets the new RPI, then the others get downgraded to less taxing duties. For example the RPI2 I started experimenting on with Astroberry is now a PiHole.

[gilesco]

1 hour ago, SiD the Turtle said:

I find the semi-regular release of new RPIs and my love of tinkering means buying the top end model

I have about 6 or 7 prior releases of Raspberry Pis just lying around, but they are sufficiently cheap enough for me to just buy the high-end ones that get released, I think I'd only change that if the highest spec one suddenly cost more than £100 / unit and actually, I probably end up buying more than one, as the first batch tend to have some bugs, which get ironed out with minor board revisions and tweaks without changing the part / model number.

I will probably end up donating the old ones to the under-privileged / schools etc... but I find it especially useful to sometimes just have access to a number of basic Linux boxes for other areas (I work in IT and Networking).

[pete_81]

So final update to this I think (at least for now).
In effort to get better guiding and understand better setup technique, I'd read about Drift-Alignment (remember I've only done visual up to now, and with (AZEQ6Pro setup in) Alt-Az) and found Bill Gwynne's YouTube Video outstanding. I've had a blocked view of Polaris due to large tree (more on that later...) so copied Bill's drift-alignment when it was clear (for a period!) on Friday night. I was delighted to see the drift-plots came almost horizontal during my setup, indicating the mount was getting closer to correct polar alignment. Cloud then appeared so I packed up after a successful night where I became armed with a good understanding on how to align decently enough for next clear night...

I've also taken the plunge and bought a stand-alone RPi4 4GB rather than the Pi-400 as advised throughout this topic. The plan here is to have shorter USB cables connecting mount and cameras (guide + DSLR) to the RPi with everything attached to the dovetail so only 2 cables (12V mount power & RPi power) will travel up from the ground and no other cables (USB) to get in the road! So this + Astroberry + VNC + Anydesk is my present setup. Images coming later in the post...

So, last night was clear again and I decided to top the Polaris blocking tree. It missed the house and I was given first time views of Polaris standing on our patio. Then imaging setup began. Wow, being able to see Polaris in the finderscope makes setup so quick, doesn't it?! Ignoring drift alignment and fine tuning, I just wanted to get onto guiding as I've not done it to date. I've been seeing errors in the internal EKOS guider "GUIDE_RA: Scope cannot reach the start point after 21 iterations. Possible mount or backlash problems", so wanted to persist with PHD2 for the time being, as there's a wealth of tutorials and tools (drift alignment etc) documented readily on the web.
I struggled somewhat to get things to connect between the various softwares in EKOS/Indi/PHD2 and eventually worked out that rather than setting PHD2 up independently using the ZWO camera and EQMod mount that I had to start KStars, enable EKOS and let INDI from here talk to all the equipment (mount + guidecam + DSLR), THEN start PHD2 and select connections to come from INDI, and I now have a profile for this:

I ignored darks (stay with me!) and let the calibration run. The issue with EKOS internal guider may have been due to the balancing of the setup (I'd left things perfectly balanced initially rather than going East-heavy) or having the guide camera turned 90º. The latter I conclude as during PHD2 calibration, N moves push the guidestar E.

Anyway, between gaps in the cloud, lighter cloud cover and selecting stars that were likely too bright based on Bill's video, I managed at long last see PHD2's status change from the calibration to read "Guiding"! YAY! I didn't align (2-star alignment) the mount, plate solve or anything, just wanted again to get the mount guiding, but getting to this point was again another success as I've not seen this point before.

I'm sure everyone here will frown at the screenshot I took of my triumph but remember I'd not spend hours on Polar Aligning or optimising by Drift Alignment, I just wanted the mount to guide and not drift excessively. Plus the state of the clouds was NOT going to help my cause - the screenshot was taken AFTER I'd shot a couple of long (1, 2 & 5 min images with DSLR) showing the cloud-cover and throughout the guiding, the cover came and went also.

Next time, I'd aim to setup better and drift-align as Bill's video, hoping to get better again.

Setup wise, here's an image of how I've done things with description of why.
AZEQ6Pro, with power cable and Wifi dongle (only purpose of this was to turn change brightness of polar finder illumination). 330mm dovetail with 3D printed holder for RPi and 2x Manfrotto type RC2 Quick Release Plates, one for DSLR and other for GuideScope. The cables then come from camera, guidecam and Mount head to the RPi, using 3 of the 4 available USBs, and all connected wirelessly to the router inside house. No issues with connection last night, although I do have additional wireless USB dongle if required later.

My camera lens is the Tamron 500 f/8 mirror lens, which yes, isn't the flashiest camera kit, but certainly works. The plan later is to use the 1200 f/4.8 but remember the purpose of this topic - learn guiding and the main issues before getting into better imaging.

As an indication, here's a 5min exposure at ISO 100 f/8, pointing somewhere in Orion (remembering I didn't do alignment, just used KStars to GOTO M42 before starting guiding calibration (and leaving it guiding once it started), hence saying somewhere in Orion!)

I think my stars are quite good (spots, rather than trails!) so I'm prepared to call my first guiding experience a success. Next stages obviously are to do more with regards to aligning mount (actually doing the 1/2/3 star alignment + plate-solving), but clearoutside (coords changed slightly so nobody stalks me!) is suggesting I've a week of cloud cover before I get out again! 🙄

Thanks to all for suggestions on gear and I hope this lets folks know their help to beginners like myself is appreciated!

Edited January 26, 2021 by pete_81

[pete_81]

On 09/01/2021 at 22:59, fozzybear said:

I have my Rpi4 in a Flirc case and via wifi to my router albeit as the crow flies about 10 metres away outdoors

Hi FozzyBear,
Can you send the .conkyrc file you are using to monitor things. Yours is one of the cleanest I've seen and just looks like it works!

[fozzybear]

1 hour ago, pete_81 said:

Hi FozzyBear,
Can you send the .conkyrc file you are using to monitor things. Yours is one of the cleanest I've seen and just looks like it works!

here you go

.conkyrc

[fozzybear]

3 hours ago, fozzybear said:

here you go

.conkyrc 2.2 kB · 3 downloads

let me know if ok

[pete_81]

12 hours ago, fozzybear said:

let me know if ok

Yep Worked lovely, thank you

[rickwayne]

Tammie represent! I've used the Tamron 500 mirror for a fair old lot of stuff. Actually acceptably sharp -- IF you can get  the ruddy thing focused. (Non-astro example; considerably  less-compelling astro example) Topaz Sharpen AI does miracles with it, too.

If you're going to use plate solving, eh, don't bother star-aligning  your mount. Just get the polar alignment dialed in good and proper, Ekos will sync the mount to the plate-solved solution to higher accuracy than you  can achieve anyway. If you do a Capture and solve / Slew to target, it syncs  the mount along the way, no need to do a separate go with the  "sync" radio button checked.

Edited June 5, 2021 by rickwayne

[pete_81]

EKOS Guiding...

Going to continue this thread rather than start new one for the sake
I've got the setup as shown above...
RPi, running Astroberry and KStars. This is connected to...

• AZ-EQ6 (USB direct to the newer mount)
• Nikon DSLR (main imaging camera, which will either use standard photo lenses, or get positioned on the 10"f/4.8 once everything else really mastered!)
• T7C Guide camera, not using ST4 for guiding, connected to 240 f/4 guidescope
• Wifi dongle, just for better wifi signal - in my pic of setup, one can see the wall of the house so not far from router. That's not the topic here though!

So, I've successfully used PHD2 for guiding, and did a 10min exposure of M101 the other night which guided well with no star trails etc. So all is connected correctly to guide and so on.

But I'm interested in changing over to EKOS for guiding, using the internal guider. Each time I do this, I get an error up about issue clearing backlash or something along those lines. Yes, I know detailing the actual issue is better for debugging, but I was more interested in getting images than taking note of issues so switched back to PHD2 via EKOS.

Does the internal guiding calibration take account of direction of guidecam (figure it all out itself as PHD2 appears to) or do I need to setup with UP on camera to +RA (for example) then calibrate?
What about balancing the scope - East Heavy is the norm here, but to engage the dec drive better, should one offset the balance of the N/S too? I don't think that's a good idea as the dec shouldn't really be correcting if polar align is good enough, but just throwing ideas out to see if anyone does this.

TLDR: Issue with EKOS guider - unable to guide due to error 'unable to clear backlash' or similar. PHD2 works for guiding so what's going wrong with my use of EKOS?

[wimvb]

Guiding wise, I haven’t notice much difference between ekos and phd. Some nights one may show slightly better results than the other for some reason. I’ve never figured out why.

calibration always seems easier in ekos. If you have backlash issues, set backlash to zero in the ekos mount module, then mechanically minimize backlash. Because the mount has belt drive, loading east heavy shouldn’t be needed. If you have minimal backlash, that is.

[alacant]

4 hours ago, pete_81 said:

Does the internal guiding calibration take account of direction of guidecam

Hi

Yes. Just as PHD2, EKOS' internal guider needs the guide camera to be the same if you choose to re-use the guide calibration (recommended) between sessions. 

In the guider options, there is a check box to clear backlash before calibration in DEC, IMO, better than in PHD2 where you have to nudge the mount manually north in DEC before the west calibration begins. 

With a t7c and a 240mm guide telescope, try a guide pulse of 900 and 6 iterations. Of course, use SEP Multistar and the PPEC GPG for RA.

Here are our settings for an old eq6:

HTH

 

 

[pete_81]

Me again. Oh nuts says everyone!
Changed to altair guide-cam (GP-Cam, IMX224) as T7C noted to be very noisy. This camera isn't supported by (at least I can't it connect to) PHD2, so forced to use new profile with guiding camera as 'ALTAIR' and internal guiding which kept reporting the backlash issues as above.
Not so last night M51, here we go

Guidecam connected, focused easily, and completed calibration, but during this and after a while guiding, frames dropped/frozen and "Exposure timeout. Restarting exposure..." messages throughout. Grrr. Eventually, "Exposure timeout. Aborting Autoguide." If I selected the Subframe, it appeared to run in streaming better, or if exposure was very short (0.5s), but I know these are not the typical settings. I don't really want to go down the route of cropping the camera image via the indi controls either!
I am running the guidecam directly from the RPi (RPi4 4GB, astroberry), and think I've read somewhere about it not being powerful enough to run guiding - is this the case here (thinking if this is the issue, then a powered USB hub is the likely solution)

Other than that, I was enjoying M51 last night, and getting much faster with the setup from scratch! Just have to remember camera cable and batteries charged!

TLDR: RPi4 + Altair guidecam => is the RPi powerful enough on it's own to run USB power (via USB3 port) to run USB2 Altair guide-cam, or should I run powered USB3 hub?

[pete_81]

Edited June 16, 2021 by pete_81

[wimvb]

The issues with the guidecam can also be driver related. The first generation asi120mm had similar problems. I got it to work by setting bit depth to 8 bits, avoiding 16 bits. No hub needed. Otoh, with my main imaging camera, the ASI174MM, I needed a powered usb3 hub. Even with 12v connector plugged in for cooling. I use a Rock64, and not a Raspberry Pi.

[pete_81]

https://indilib.org/ccds/altair-cameras.html
About 2/3 down page

Dang

Cropping in 100px on each side still yields the timeouts, T7C running now as test and not one timeout. Might be going back to that.

Edited June 16, 2021 by pete_81

[wimvb]

That actually looks very much like the asi120 problem, where usb packet size didn’t comply with usb standards. zwo solved it by releasing the ASI120MM-S. You can try with the camera in 8 bit mode. It’s under the control tab in the indi configuration panel.

8 bit mode halves the data traffic while keeping full field of view.

[pete_81]

Thanks for those posts Wim. Don't think this will work - here's a screenshot of the T7C (called via ZWO 120 from EKOS/Indi), which contains the 8-bit option. The Altair has no such control, although it does have a 'levels' tab which isn't available with the ZWO equivalent. The issue I suppose here is the levels are capped to 8-bit (0-255) as seen.

 

 

Reducing the range (0-127) did make it become more stable, so playing around with the 'dynamic range' in this way might make it OK, but not really too keen on this idea. Running streaming in Indi panel ('Streaming' tab) without any visible frame drops over > 10sec, but when running the same streaming settings from EKOS, the video keeps freezing and the error "Exposure timeout. Restarting exposure..." reappears. Not ideal for any guiding!
Any last tips before I pack this one in?

Edited June 17, 2021 by pete_81

[pete_81]

On 05/06/2021 at 20:33, rickwayne said:

Tammie represent! I've used the Tamron 500 mirror for a fair old lot of stuff. Actually acceptably sharp -- IF you can get  the ruddy thing focused. (Non-astro example; considerably  less-compelling astro example) Topaz Sharpen AI does miracles with it, too.

If you're going to use plate solving, eh, don't bother star-aligning  your mount. Just get the polar alignment dialed in good and proper, Ekos will sync the mount to the plate-solved solution to higher accuracy than you  can achieve anyway. If you do a Capture and solve / Slew to target, it syncs  the mount along the way, no need to do a separate go with the  "sync" radio button checked.

Sorry Rick,
Only seeing this as I browse through the topic again to see how far I've come! Yes, quite pleased with the 500f/8, debated getting a smaller scope to learn guiding and imaging with then thought why not just use this one! It's longer than the likes of the WO ZS73APO, allbeit a stop and a bit slower, but posts from a few years ago (Site1 Site2 Site3) suggest that yes, it's dang sharp for the price and other than the bokeh being 'interesting', it's as sharp as one will get without spending 4 figures. Downsides are generally all terrestrial related and the MF, but I've 3D printed a frame that straps onto the camera:

One ring locks to the fixed base of the lens, and the other on the rubber focus grip - do rough focus, then tighten up the rings, add a 3D printed Bahtinov to the front of the 3D printed extended hood (the original hood is in a 'safe place' and if I remember correctly wouldn't fit on with the UV filter) and fine-tune focus with the large knurled screws which slowly turn the focus ring. Works nicely, other than the dust spots (possibly in lens) being visible as the doughnuts (see my post above from 26th Jan!)
But yes, not a bad lens, and certainly cheaper than telescope or the Nikon 200-500! Still would be cheaper to use it with dedicated astro cam with help of an adapter (ASI or Altair).

Roll on clouds, although not much dark time at night!

[pete_81]

As a last effort, I've just attached the Altair to the MBP and thought things were going well. Did live streaming in EKOS as opposed to INDI.
However, after a minute or so of stability, the frame froze and first 'timeout' warning. Granted it did recover faster than the RPi, but that's to be expected due to the sheer processing power differences. Then it's in the loop of <10sec of stable footage, then timeouts. Any final thoughts on this one?