kens

If you use ST4 you need to set the mount to On Camera. The further away the easier it will be to focus. To test during the day aim at anything you can get into focus on the camera. Turn on the cross hairs or grid (View > Bullseye or View > Fine Grid). Set the manual guiding Guide Pulse Duration to its maximum (5000). Tools > Manual Guide to get the popup dialogue. Click the various buttons and you should see the image move a small amount. The grid/bullseye makes it easier to detect the movement.

I'm running it as an Indi server and PHD2 server. For me the purpose of using these SBC's is as a form of embedded computer. So its not a Linux versus Windows question. I treat the Linux device as just a part of my telescope. I switch it on and connect to it via KStars/Ekos running on Windows like I would the camera or mount. If anythings acts up I switch it off and switch it on again like any other device. Linux is ideal for this use and dominates embedded systems due its reliability and small footprint. So far the Aaeon works well and boots up quickly and reliably even when shut down very ungracefully. The RPi is a bit flakey when it is not shut down gracefully. BTW moving the RPi to boot from USB is not one way. Just a small change in one file on the SD card. You still need the SD card but the Boot sector is on the USB stick.

Some valid criticisms. On point (2) - I just downloaded Ubuntu on another machine and burnt the ISO onto a USB stick. No problems installing like that. I then used a Netgear USB stick to do the rest. I did try a RTL USB as well but it wasn't recognised - probably too old. I also have a spare Broadcom USB that would probably work. Worst case I would have plugged in an ethernet usb dongle and connect directly to the router or connect via another computer.. On the cost side I got the 4/64Gb version for around the equivalent price to your 2/16Gb version in AUD (<$250). Is the difference due to VAT vs our GST (10%)? Certainly GBP 140 for the 2/16 sounds steep. On point (6) it is a bit annoying. But I found it boots and connects reliably with the external antenna so it only takes a Ping to see if it is running. If not I just cycle the power to reboot it (unplug and plug in again or switch off/on at the wall). Unlike the Pi it doesn't kill the boot sector on the SD Card when you do this. To resolve this on the Pi I boot from a USB stick. What I really want is a LED that shows whether it is running or not. But the LED on on the Pi is still lit when it is shutdown but power is connected. I'm also using Ubuntu 16.04 just like on The Pi with Ubuntu Mate. I'm a little more hopeful of 18.04 being made available on the Aaeon than on the Pi where Ubuntu Mate has gone very quiet. I do prefer the straight Ubuntu over the Mate version.

I think there is small bug in the indiwebserver. I recall patching it locally some time ago but never submitted it for inclusion in the official version. The issue is that it uses just one fifo so I patched it so there was a different fifo for each port. Starting indiwebmanager on another port doesn't help either as it too uses the same fifo. If I can find a spare moment I'll find the fix and submit it for inclusion.

If you are using Indiwebmanager you can set the port that Indiserver runs on. By default its 7624. Pretty sure that is saved in the indiwebmanager profile. So you could start one server on port 7624 and another on 7625. In Ekos you can nominate which server port you connect to. Worst case you could start each server manually with the -p <port> parameter

I got mine from Mouser. Delivery was fast. I just did a normal Ubuntu install (16.04 - kernel for 18.04 is due out September) then followed the instructions to enable the Wifi and bluetooth. The only difficulty came because I did not have the external antenna so I had to sit it right next to the router to get online. So far I've had no need to use support although I tend to be self-sufficient as I know how to switch things on and off I've only checked the forum to see when 18.04 will be supported - that's the community forum at https://forum.up-community.org/ 5v at 4A is only 20W so it runs warm rather than hot and I power it though a UBEC 12V to 5V reducer. My only gripe there is that the only power connection is the barrel socket - on the Pi I can use the GPIO pins which is easier to rig up in a case. Speed wise I tested it with the ASI1600 saving the files only on the server. The time to save a 32Mb file was a blink of the eye. Downloading over the network was very slow but I haven't yet tried it with compression since that would only be to preview and focus.

I'm using the AAEON-UP CORE which is based on the Atom x5-Z8350 with 64Gb eMMC and installed Ubuntu 16.04 on it. I chose this one to take over from my RPi3 as it has a USB3 port and the x86 architecture supports one of my cameras that has no ARM driver. Given that the price includes the eMMC it is quite reasonable. Plus it can take (indeed requires) an external Wifi antenna so no need to hack the board like with the RPi3. If you get one I recommend also ordering the Wifi antenna and if you also want a couple of USB2 ports order the adapter cable.

AFAIK Kstars/Ekos on Windows needs to talk with an INDI server for full functionality. The ASCOM interface uses an INDI wrapper around ASCOM which provides only basic functionality.

It wouldn't be easy to fit around the rectangular hole where the sled focuser fits. I've decided to try to keep ithe whole rig in original condition as much as possible. I was able to fit a helical focuser that scews into the sled focuser. So I can lock the sled and fine focus with the helical

The scope has good optics but the focuser was always a bit sloppy. Ok for visual but hard to focus well for imaging.

Here's my Vixen R150S on its SP mount which I've had since about 1983. Piggybacking is a Vixen 60mm guide scope. The only mod I've made since is to add a helical focuser to the sled focuser and build a controller for autoguiding.

Heres the drawin for the ultra slim: http://www.qhyccd.com/files/QHYCFW2-M-US drawings.PDF Looks much the same but slimmer A T-thread (or T2 thread) is M42/0.75 - be careful with the term M42 as it is also used to refer to the Pentax M42/1.0 thread which has a different thread pitch. In fact, be careful with M54 as well as I just saw one adapter for M54/1.0 so it might be best if you measure the pitch to be sure. By the way, a very useful tool to have is vernier calipers to mesaure threads, spacings etc...

I'm assuming you have the Standard filter wheel in which case here are the mechanical drawings: http://www.qhyccd.com/files/QHYCFW2-M-SR drawings.PDF The drawings show that the threads on both sides are M54 /0.75 (54mm diameter with 0.75mm thread pitch) Which flattener do you have? Is it a 2 inch/ M48 type? If so you'll need a M54 to M48 adapter and maybe some M48 spacers.

Guiding lets you take longer images without star trails caused by Periodic Error (PE) or Polar Alignment (PA) error. Periodic error causes an oscillating movement in RA whilst Polar Alignment error causes a drift in Dec. Guiding uses a second camera to monitor the position of a guide star and sends small corrections to the mount to adjust for any movement caused by PE or PA. You need a second camera because the guide camera checks the guide star position every few seconds whereas your imaging camera might only take one expsoure every few minutes. The guide camera and scope can be relatively inexpensive. Guiding is pretty much essential for DSO imaging. For lunar and planet the exposures are so short it isn't really needed.

Some cameras are equipped with a ST-4 port that can be connected to the mount. You connect the camera to your computer with a USB cable as usual and connect the camera to the mount with a ST4 cable. In PHD2 you select a mount type of On Camera. PHD2 sends guiding commands to the camera via the USB cable and the camera in turn sends them to the mount via the ST4 cable. The advantage of this is that you don't need a driver for your maount. With ASCOM guiding you install the driver for the mount on your computer and connect the mount to your computer with a suitable USB cable. You connect the camera to your computer with a separate USB cable but you cdon't connect the camera to your mount. In PHD2 you select a mount type that corresponds to your mount e.g. HEQ5/6. PHD2 sends guiding commands directly to the mount. The main advantage of this approach is that PHD2 can communicate with the mount so it knows where it is pointing. This lets you reuse your calibration in different parts of the sky. For guiding you need a separate camera from your imaging camera.

You need to be able to find a decent guide star near the object you ar eimaging. If you are imaging small galaxies, a bright star can be hard to find and more aperture can help. Typical aperatures for a guidescope range from 50 to 80mm. You can also use an off axis guider (OAG) which is an attachment on the focuser that lets you attach both your imaging camera and guide camera so you don't need a guide scope. The OAG uses a small prism to pick off some of the light coming through the focuser and send it to the the guide camera.

That depends on your imaging scope. Autoguiding software like PHD2 http://openphdguiding.org/ can resolve down to around 0.1 pixels. As a simpe rule of thumb, a guidescope should have a focal length in the order of 1/4 the focal length of your imaging scope. Many people adapt a finderscope for the purpose.

I have some code that enabled auto-guiding on my Super Polaris mount but that was using unipolar steppers. I'm happy to share that FWIW. Auto-guiding will help to overcome periodic error in the RA drive train. Periodic error exists to some degree in every mount due to slight imperfections. It causes tracking to speed up and slow down slightly - enough to cause problems with astrophotography. Autoguiding uses a second scope and camera to track a guide tar and send corrections to the RA motor that keep the star stationary. When you get your camera, aim at a star and take a long exposure (5 minutes or more). That will show you graphically the effects of periodic error and polar alignment.

Now that you have an Arduino controller it would not be hard to code it to do guiding pulses so you can autoguide.

Displaying in arc-sec is good practice, but providing the pixel scale shown is correct, the guiding looks good. That suggests differential flexure is the problem. However, the RMS values don't correlate with what is showing on the screen shot. Please attach the guide log as it is hard to analyse screen shots in any depth.

It is unrelated to the drift problem. Assuming what we can see of your guide log is representative, PHD2 is keeping the guide star centred so there is no major problem there. So if the stars in the image are moving the most likely reason is differential flexure. If you could attach your PHD2 guide log it would really help the analysis of your problem by removing a lot of guessing and assumptions.

I've also been chasing down a differential flexure problem with similar symptoms. The guide graph shows that for half the time at least the guide star was centred, yet the stars in the image are moving. By the way, screen shots are pretty useless for analysis - you need to attach the guide log itself. Attached file shows the images from the session stacked without alignment so the movement is clearly shown. I think one of those hockey sticks is the guide star but can't be sure. The guide star was kept centred in the guide scope the whole time. To home in on the problem I pointed at the pole and took a series of images from both guide camera and imaging camera as I rotated the mount 90 degrees in RA East and West. I did this by running two PHD2 sessions as I described earlier and File | Save As at each point. The combined traces are attached. For a bit of fun I edited in lines showing the movement of BQOct. The plots clearly showed a problem with the imaging scope as the trace should have been circular in both cases. So at least I could eliminate at least half the possibilities. Two possibe causes came to mind: the dovetail mount and the camera attachment. Some preliminary adjustments to the dovetail have been promising - an after shot had a circular trace but I'm not sure it will stay that way. In short - there is no easy solution without gathering diagnostic data. Hope this technique may help you. Its work in the southern hemisphere as there are some nice bright stars near the pole TEST-all-30s.tif

Try this: Open two PHD2 sessions. You open the second one with "-i 2" on the command line Set up the first session as usual with your guide cam Set up the second session with your imaging cam and disable guide pulses Start the two sessions guiding simultaneously Session 1 will guide the scope whilst session 2 will just record the movement of the guide star in the imaging scope Any deviation in session 2 is due to differential flexure. Working out the cause is still a challenge but the shape of the graph can help

Indeed but that can be hard on a headless setup when you lose network connectivity

I found setting up a headless Pi very frustrating as the SD card kept getting trashed when I had to power down/up to reboot. I switched to a bootable USB and haven't had a problem since. If you're interested I can dig up the instructions. In a nutshell you still need a SD card but it doesn't need a boot sector. You edit config.txt to point to the USB drive and write your image with boot sector there. USB drives seem to be more robust to powering down without dismounting.