NEQ6 Hardware/Software for Astrophotography

[Photosbykev]

Post #1 updated with a revision to clarify the situation for Synscan handcontoller users.

and the 100th post on thread lol oops 101st post

[chrisshillito]

I think I choose the right way to control my system by using EQMOD lol

I'm sure you did

Kev, If I were you I'd just focus on describing exactly what I'd done myself, explaining the reasoning behind the decisions/choices made. Given the range of equipment and software options available I'm not convinced it is possible to give clear and concise "generic advice" that covers all possible combinations.

Chris.

[MG1]

Great work Kev, I too think this should be a sticky....But maybe consolidate all the comments and options for different levels of set-up?

Just being able to see it as a diagram will help loads of people slip across to the dark side...

Michael

[Photosbykev]

I'm sure you did

Kev, If I were you I'd just focus on describing exactly what I'd done myself, explaining the reasoning behind the decisions/choices made. Given the range of equipment and software options available I'm not convinced it is possible to give clear and concise "generic advice" that covers all possible combinations.

Chris.

I'm sure you are right Chris, when I've read up on your notes about the connection options I will add a link to it from the 1st post.

If nothing else I've learnt one hell of lot about the system and I think a few other people have as well so it was worth starting the thread lol

[astroimpulse]

From everything I've read on here and other forums unpowered hubs are very unreliable so I didn't even consider using one.

I'm not really using one that needs power. I have a few that need powering and they are poor if you use powered devices without it's own supply. Really poor.

But the one I'll be using for just the DSLR (sharing 2 usbs straight into the port) and it's not powering anything or using much bandwidth.

There won't be an issue.

You definately need powered ones for the way you've done in the diagram (and the way I was going to do it).

[astroimpulse]

Personally I think Kev's diagram gives far easier to understand information than most posts with just people's specific set-ups. There's always a million and one ways to do something but even if you do it different...the diagram makes things so much clearer.

For those who want to image...there's always going to have to be further investigation before deciding. But the OP (and diagram) can help those wanting to know 'what the hell do I need' very simply and without the techno babble that can confuse more than help.

[Black Knight]

Personally I think Kev's diagram gives far easier to understand information than most posts with just people's specific set-ups. There's always a million and one ways to do something but even if you do it different...the diagram makes things so much clearer.

^^ This. This diagram made picturing everything in my mind so much easier. And the subsequent posts dealt with some of the questions I felt forming at the back of my mind as well. So a win-win for me at least

Kudos to Kev for taking the time and effort .

[Photosbykev]

I've added a second block diagram for Synscan handcontroller users in post #1 which maybe helpful. Also a note on the Syntrek diagram regarding the use of the ST-4 cable.

[Whippy]

Your diagram gives the impression that you need EQMOD to guide and capture, this isn't that case. It's a nice luxury admittedly, but it's not essential at all on an imaging setup, I think it's worth making that modification on your original post.

Tony..

[Photosbykev]

Your diagram gives the impression that you need EQMOD to guide and capture, this isn't that case. It's a nice luxury admittedly, but it's not essential at all on an imaging setup, I think it's worth making that modification on your original post.

Tony..

post #1 assumes you use a laptop for guiding and image capture and it's how I control my system. Of course there are dozens of alternatives.

[Whippy]

Of course there are dozens of alternatives

Indeed there are, and I too use a laptop (bit tricky using a CCD without one!) for image capture and guiding but EQMOD simply isn't necessary.You can take it out of your setup and just use the synscan handset instead. As I've said, your diagram assumes that it is essential when that isn't the case.

Tony..

[Merlin66]

Tony,

Kev has just added a diagram for the Synscan handcontroller option.

See #1 post (updated)

[Photosbykev]

Indeed there are, and I too use a laptop (bit tricky using a CCD without one!) for image capture and guiding but EQMOD simply isn't necessary.You can take it out of your setup and just use the synscan handset instead. As I've said, your diagram assumes that it is essential when that isn't the case.

Tony..

In the lower diagram i.e for SynScan hand controller users there is no mention of EQMOD ? EQMOD is only detailed in the upper diagram for SynTrek users.

Looking at it again there are two errors in the lower block diagram, I need to remove the Joystick and GPS blocks which wouldn't be used in this configuration.

[themos]

In the Synscan diagram you also need to take out references to unused software.

But I am confused again: in the SynScan case, the ST-4 connection between guide-camera and mount does what? where is the software that's doing the guiding? in the guidecamera? That's a Synguider then, not any old guidecamera.

???

[Whippy]

You could also do away with the USB/serial,temper hum, serial to RJ45 lead for the handset and the powered hub.

At it's simplest its: Laptop to imaging camera, laptop to guidecam and guidecam to mount (assuming the cam has the ST4 mount onboard otherwise something like the GPUSB unit is needed). No need for the powered hub as you're only using 2 USB ports and handset deals with the GOTO.

Tony..

[Photosbykev]

Note 1 covers the use of the ST-4 lead i.e you can either use the GPUSB route to provide guide commands given by PHD if you select the Ascom camera in PHD (in which case the lead isn't required) or you select on-board camera in PHD and the guide commands go back through the guide cam and into the mount via the ST-4 lead. If your guidecam doesn't have a ST-4 port then you would select Ascom camera in PHD and use the GPUSB route.

I could remove the Temperhum which is why it's optional, I use one to give me temperature/humdity/dewpoint information. The USB/Serial is required for most users unless they have serial ports on their laptops. It does assume that users want to navigate and control the mount from the laptop rather than the handset.

[Steve 1962]

Just wanted to say "well done" Kev - great thread that I'm sure will be useful to many others.

Steve

[Photosbykev]

Just wanted to say "well done" Kev - great thread that I'm sure will be useful to many others.

Steve

Cheers Steve, it's been very educational for me as well

[chrisshillito]

In the lower diagram i.e for SynScan hand controller users there is no mention of EQMOD ? EQMOD is only detailed in the upper diagram for SynTrek users.

Looking at it again there are two errors in the lower block diagram, I need to remove the Joystick and GPS blocks which wouldn't be used in this configuration.

Kev,

If the presence of EQMOD is the thing that distinguishes two diagrams then why not label diagram 1 "EQMOD Control" ? After all, whether the actual mount was purchased as a syntrek or a synscan it really doesn't matter as that designation only refers to the handcontroller type fitted - which is irrelevant for EQMOD use.

Also many planetariums (stellarium, &cdc) come with inbuilt nexstar drivers so strictly speaking you can list the ASCOM platform as being optional on diagram 2 (thereby making it suitable for non windows users).

Chris.

[Photosbykev]

Good idea Chris. I'll update the diagrams on Monday when I get back to my desk

[Sp@ce_d]

This is a very helpful thread... it's come at just the right time for me as I'm currently putting a shopping list together for my first "proper" imaging setup..

Thank you

[Photosbykev]

I've added a couple of links for the Temperhum and GPS modules I use. The BlueNEXT usb gps module from CPC works fine with EQCOM under Win 7 64-bit, it arrived this morning and was installed and working in 30 seconds, I can't complain about that lol

[Photosbykev]

I've updated the block diagrams in Post #1 to include a few improvements suggested by forum members.

[NickK]

I've read it and it's top stuff.

But now I'm confused as to which parts of the diagram I can use for a mac if I don't need ASCOM and can't use EQMOD.. Or is that for another thread?

Excellent info Kev, at least I know I can "borrow" swmo's PC when I try this out in the future.

For a mac you will still need something to connect the USB to the serial interface (ie an EQDIR or a USB<->Serial cable for PC-Direct).

The software controlling will then still need to know the EQ-mount specific/proprietary command protocol.

I'm creating AOSX (Astronomy on OSX) which basically is a Mac orientated ASCOM that focuses on making it easy for application developers and equipment vendors - and above all easy for the user.

People can then write apps such as mac native apps (such as EQDIR etc) on top. A common interface is then provided and so the app writer doesn't have to worry about implementing a different protocol etc.

To add support for a device is broken down into a protocol (ie the control of the device) and the transport (ie a serial device/usb/firewire). Then to write a support for a particular device is only a case of implementing a protocol plugin if a transport plugin already exists. They don't have to worry about maintaining preferences or dealing with applications as that's handled by AOSX.

[Digz]

For a mac you will still need something to connect the USB to the serial interface (ie an EQDIR or a USB<->Serial cable for PC-Direct).

The software controlling will then still need to know the EQ-mount specific/proprietary command protocol.

I'm creating AOSX (Astronomy on OSX) which basically is a Mac orientated ASCOM that focuses on making it easy for application developers and equipment vendors - and above all easy for the user.

People can then write apps such as mac native apps (such as EQDIR etc) on top. A common interface is then provided and so the app writer doesn't have to worry about implementing a different protocol etc.

To add support for a device is broken down into a protocol (ie the control of the device) and the transport (ie a serial device/usb/firewire). Then to write a support for a particular device is only a case of implementing a protocol plugin if a transport plugin already exists. They don't have to worry about maintaining preferences or dealing with applications as that's handled by AOSX.

Sounds great, I look forward to seeing what develops.