Marci

APT and BYE are just different flavours of imaging control software with pretty much similar feature-set. Both link to PHD2 for guiding.

Can’t help with BYE and PHD2 - I use APT, which just sees it and connects to it and dithers. Presume BYE will do the same if PHD2 is running before BYE is launched. If you’re using ST4 from camera to mount, just select "On Camera" as the mount. Ignore aux mount. ST4 is a standardised protocol that isn’t dependant on mount-specific drivers. Disabling Dec: https://openphdguiding.org/man-dev/Advanced_settings.htm#Algorithms_Tab and set Declination dropdown to 'none'.

A typical night in the back garden... Shed's set up as a warm room. Those are 40' conifers (dark ones) completely obscuring north, and more obscuring NW (the lighter ones to the right) - I learnt to drift align early on in my Astro adventures...

And that’s why I use Jessie LITE, not Jessie. With Jessie LITE, everything works as per above (still). And I never got the encoders hooked up - blew them all up... not had chance to get back to it since.

Just looks like a Celestron Nexstar+ LCM on steroids...!

I had similar issues - had to introduce a 4.5 multiplier into the code, so when driver sends 10000, the stepper moves 45000, which is required for full range of travel in my case.

To enable ssh on clean install of Raspbian lite, see https://dirtyastro.com/2016/12/10/project-retrofitted-goto-dob-pt3/

To create a file... pico [nameoffile] Type or paste in content, ctrl+o to save, ctrl+x to exit

Hmmm - using the new Directshow pipeline in 2.10, I’ve lost 520fps from my camera... if I switch to original DirectShow pipeline and restart, I’m back up to 500-600fps. Switch to new SharpCap pipeline (no other settings changed) and I’m immediately dropped down to 30fps or less. (Opticstar PL131M)

wget https://sourceforge.net/projects/astroberry/files/Astroberry/Astroberry 1.0.4/indi-astroberry_1.0.4-1_armhf.deb/download?use_mirror=heanet and then, because I suspect it will store the file as 'download?use_mirror=heanet', you'll need to move it to the correct name... mv ~/download?use_mirror=heanet ~/indi-astroberry_1.0.4-1_armhf.deb && sudo dpkg -i ~/indi-astroberry_1.0.4-1_armhf.deb Your update not working looks to be because that Pi cannot access the internet... what happens when you attempt to ping www.google.co.uk or ping www.bbc.co.uk ? http://archive.raspberrypi.org is working fine for me, so I'd say it's an issue local to that particular Pi and it's network settings. Re: Libindi needing upgrading on it... just download the latest libindi by hand and reinstall by hand as you did the other day. I don't think apt-get would actually pick it up to update it as it wasn't installed with apt-get to begin with. Astroberry PiFace is an updated Astroberry release specifically for the PiFace HAT (altho if memory serves, the docs don't say which specific PiFace HAT, and it'll only work with the right one). If you don't have this, I'm not sure it would work anyways. Better to stick to the original Astroberry release.

What make & model EFW? Is it listed when you run lsusb from commandline?

(Apols if teaching to suck eggs!)

No probs...! Your next mission tho will be to read into creating udev rules so that your devices always appear at consistent place, otherwise port numbers (e.g.: /dev/ttyUSB0, /dev/ttyUSB1 etc) change on order of connection. Ideally do this for all your devices BEFORE configuring the libindi drivers for those devices... and then you can name the new STATIC ports whatever you want (/dev/atikcam, /dev/focuser, /dev/eq8mount etc) - they'll always use those names regardless of physical port / connection order.

You could also install FileZilla or similar on your main system and connect to the Pi via sftp using port 22, then you can just drag n' drop from your main system to the /home/pi folder on the Pi

Ssh on as Pi, should put you in Pi home folder. in web browser right-click copy shortcut for the file you want to download. in your ssh window: wget [ctrl-v to paste] {enter} (wget downloads files via http from commandline.)

Just move the extracted folder to your home directory... sudo cp -R /boot/libindi_1.3.1_rpi /home/pi/ sudo rm -rf /boot/libindi_1.3.1_rpi cd /home/pi/libindi_1.3.1_rpi sudo dpkg -i *.deb Once it's done installing you can delete the extracted installer... rm -rf ~/libindi_1.3.1_rpi Always safest to do everything in the Pi user's home folder at /home/pi ( ~/ = shortcut to current user's home)

On a Skywatcher 200p, a T-thread for DSLRs is built in to the focus tube adapter. Just screws straight on once you've gotten a T-ring adapter for your DSLR. For your typical 8" / 1200mm Dob, you'd need an NEQ6 Pro mount, Fast 400mm FL guidescope & guide camera rigidly mounted, PHD2 running on a laptop to handle guiding. And ideally your own thread as this is way offtopic.

The Skywatcher Dob 8" & 10" Synscan Upgrade kits still seems to be kicking about in Canada for 1200CanDollars + shipping, but these are basically an entire replacement base if I recall correctly, and may not suit the Orion OTA.

Yes, but as per @Astrobits' post, you'd still need a field de-rotator as you're not tracking equatorially (DSLR vs CCD vs webcam is irrelevant - that's down to exposure time which is determined by tracking precision). Or you'd need to put the whole lot on a DIY wedge. BUT I doubt any of the domestic GoTo Dobs would handle being on a wedge and dealing with the offset lateral loads for long without adding tapered bearings everywhere. EQPs are a null-start with GoTo. Too complex as you'd have to disable tracking on the GoTo once target located, hand over to the EQP til it reaches end of travel, break for a rewind, reinitialise and re-align the GoTo (unless the EQP is _precision_ made), repeat. An EQP on it's own has no GoTo ability, but will track a located object [if precisely aligned], but generally not precisely enough for long exposure AP unless guided, and for an EQP that can be guided - dig deep or built it yourself. Only choices. EQPs are inherently a DIY endeavour anyway, best suited to visual or very casual one-shot AP.

Any push to system is going to cost you around £300 (minimum) once you factor in both encoders and controller. Any similar aftermarket motorised GoTo setup will cost the same if not more. If a proper manufacturer provisioned kit can't be sourced you're looking at DIY from modular parts (source steppers, source gears/belts, source controller, work out how to fit to your base) Essentially it ain't cheap to buy. It IS cheap to make... IF you're a programmer with some mechanical engineering know how & all the kit. If that were the case you wouldn't be raising this thread. So... Ultimately... as above really - sell it. Buy a GoTo Dob. S'the only simple and economically viable option given the price of current GoTo Dobs.

Brand: Sakura Model: Sakura 30-260x160 Material: Metal body covered with rubber, which anti-slip and durable Color: Black Lens Coating: Fully coated Magnification: 30-260X Field of View: 180FT/1000YDS at 30X, 60M/1000M at 30X Length: 370mm Eye Lens Diameter: 17mm Objective Lens Diameter: 80mm Weight: 2123g (For reference) searching SGL for Sakura shows they have a reputation for "misprints" on their equipment... TL:DR - Avoid like the plague...!

Still working on this in the background whilst awaiting the encoders... it’s now had the following added: 1-Wire sensor network implemented, with a single Dallas 18B20 temp probe hooked up at the moment Focuser from my Pi-Focus has been added, so it now drives 2x DC Motors & 1x stepper. Parsers have been put in place to allow the focuser to be controlled via ASCOM and INDI, where it masquerades as a Moonlight Focuser. The DC Motors are still parsed as Celestron Nexstar and just use the regular Celestron driver libraries builtin to apps or via ASCOM/INDI. MatrixOrbital MX202-24 USB LCD Display (found in a drawer from escapades years ago!) added and screens configured to show Motor Speeds etc. At somepoint this will want moving from the USB bus over to the I2C bus on the Pi’s GPIO pins. It’s keypad will provide the necessary onboard user input to replicate that of the original Nexstar hand control - allow selecting of targets from catalogs, initialise alignment process etc. As per usual, all being handled by Node-Red. These parts will be documented later down the line. In the meantime here are some pix of the LCD screen as it currently stands... some of these are just the defaults as supplied with LCDd / lcdproc On bootup, once Node-Red and any other modules are initialised, the screen turns on and displays the hostname by default, then rotates around the remaining screens, 20 secs per screen. If any of the motors are moving, their screens get priority and are forced to display. Screens can be cycled through by hand using the left and right buttons, and the rotation paused / locked to any screen via the Enter button. F2 opens the builtin menu to set screen background & contrast, and allows access to custom menus. These will be where I add the star catalogues etc at a later date. Next up we cycle to the ambient temperature sensor... System memory & swap file stats - figures are available size... Historical system load (ie: cpu, mem, io - system as a whole) CPU Load, Overall, User Space, System Space etc... Network loads... Historical CPU Usage chart... Free Disk Space... Date & Time (& eventually GPS) System Uptime... DC Motor directions & Speeds... Stepper position (Focuser motor) - 0 thru 45000 steps by default, user definable via the Web UI... And, just in case we don’t have Bonjour running on the network, IP addresses...

Yup - figured that one out in the wee hours... was testing with POTH at the time. Ta! Explanation: Have implemented the AAF2 drivers serial protocol in a node-red sketch to drive 28BYJ on UL2003 connected to RaspPi GPIO... no arduino. Currently takes commands via ASCOM (VCP to TCP), MQTT, OSC, websockets, http & HomeKit/Siri (although I had to convince Siri the focuser is a set of window blinds) & USB-HID. It's own 'native' interface is via node-red-dashboard / socket.io Ultimately node-red's just translating between AAF2 serial commands / other protocols and my own Python CLI executable which does the local grunt work. No-one else's drivers (moonlite, robofocus et alle) obeyed their own protocol docs (or docs not updated), so ended up going with yours!