A General-purpose USB controller for the Obs

[bmitchell82 (Brendan)]

Nice work steve,

what was being measured/read in the program gui?

[DavidU (Dave)]

I think this project is going to come up well.

[kinetic (Steve)]

Originally Posted by bmitchell82

Nice work steve,

what was being measured/read in the program gui?

The potentiometers on the board Brendan (pic4)

Steve

[mldee (Mike)]

Originally Posted by bmitchell82

Nice work steve,

what was being measured/read in the program gui?

Thanks, Brendan, appreciate your comments and offer.

Since tonight is really the first night for throwing the whole concept on the table, I'll sit back and lurk a bit and respond later in the evening, but yes, it's looking good and I'm sure your skills will come into it some where.

Cheers

[mldee (Mike)]

Steve,

You beat me to it, I keep promising to drive down to Jaycar and get one, but now I don't have to

Actually, I've been picking up a few prototype bits and pieces off Ebay HKG, such as 12V motor/gearboxes, motor PWM controllers, TEC coolers, etc, so as the discussion moves on, we can start to look at what we want to initially focus on. Pun intended

I also got my Ebay HKG Pentax to EOS adaptor today, so am going out to do some widefield trials with my old Takumar 50 and 135mm lenses in a minute.

Cheers.

[mldee (Mike)]

Originally Posted by DavidU

I think this project is going to come up well.

I Hope so David, thanks for your comment.

Please feel free to contribute further as you see fit. Do you foresee any possible uses you may have?

I would love to see this forum have a multitude of inputs from prospective users, not just posts from a clique of techno-geeks

Cheers

[DavidU (Dave)]

Originally Posted by mldee

I Hope so David, thanks for your comment.

Please feel free to contribute further as you see fit. Do you foresee any possible uses you may have?

I would love to see this forum have a multitude of inputs from prospective users, not just posts from a clique of techno-geeks

Cheers

I may have some uses for it in the future, I just want to see a great bit of kit develope here. And sadly I'm a techno geek my self (but valve equipment)

[mldee (Mike)]

Originally Posted by DavidU

I may have some uses for it in the future, I just want to see a great bit of kit develope here. And sadly I'm a techno geek my self (but valve equipment)

David, don't let that stop you, it's ideas and creative, constructive suggestions that make things happen, not whether they have indirectly heated cathodes or not

[mldee (Mike)]

OK, looks like things are quieting down for the night. Thanks to everyone for their inputs.

What I would like to propose now is that we identify the functions in remote observatories that are felt to be frustrating yet difficult to correct.

I suspect that for most people it would be three things:

1 - Remote focusing, especially multiple scopes
2 - Dew elimination and all the factors controlling it
3 - Observatory 12V power status

There are a bunch of others as well, but since these are basically the most important to a pleasant nights photography, and easy to address, I propose we initially put our efforts into a solution for them, then we move onto the more diverse and perhaps more difficult functions.

If people wish to contribute their views and suggestions on functions they feel are either important or desirable, please post your ideas here.

I suggest we now spend a couple of days collecting suggestions and ideas, then move forward into allocating tasks so that we get beyond the talk stage into actually doing something productive

One area that hasn't yet been addressed is what people would like to see in the PC user interface. That's easy to say, but difficult to express, so probably we need to come up with some examples and screen grabs for folks to comment on.

I'm a mouse man, others prefer keyboards, so there are many inputs needed to come up with a good GUI. I would like to see a high priority on the design after some samples are posted.

Anyway, enough for tonight, and will be back in touch tomorrow.

Took a couple of nice widefields of Antares region tonight with the 1000d and Takumar 135mm on the EQ6. Then the clouds came in....

Cheers,

[kinetic (Steve)]

Originally Posted by mldee

I suspect that for most people it would be three things:

1 - Remote focusing, especially multiple scopes
2 - Dew elimination and all the factors controlling it
3 - Observatory 12V power status

There are a bunch of others as well, but since these are basically the most important to a pleasant nights photography, and easy to address, I propose we initially put our efforts into a solution for them, then we move onto the more diverse and perhaps more difficult functions.

If people wish to contribute their views and suggestions on functions they feel are either important or desirable, please post your ideas here.

It's going to be different for each person.

Here's a wish list for me as an example:

Turn on/off Dome red lights (output)
(So I can visually check a webcam/CCTV image of the dome.
Cables not fouling etc)

Turn on/off Dome interior white lights (output) (reason as above)

Focus Camera (output)
Focus position feedback (input)

Rotate dome CW/ Anti CW (output)
Position feedback for Dome (input)

Rain detector (input)
CCD temperature (input)
Dome ambient temp (input)

Turn on Dome wideview CCTV camera or webcam (output)

My GUI would need to only address my list.
Someone else would want a different list. Or a bigger list etc.
If someone designed a GUI front end that had everything functional
then maybe just a script file (a la Mel B's Scope) could be used to
toggle on or off only the functions you wanted visible and activated.

Steve

[rally]

Possible suggestion ?

You probably already know that there are existing standard protocols for many of the functions that you are proposing within ASCOM.

It could make good sense that your system attempt to use these because that makes your box compliant with a large amount of existing Astronomy software out there.
It also means that you are not reinventing the wheel entirely and can make use of existing programs by writing an appropriate driver and can then mix and match amateur and commercial products as the need arises and people progress from one level to another or want the functionality that an existing commercial product offers because they dont have the skills to precision machine their own device for example.

I am sure I have read about existing Observatory controllers that make use of the Velleman board that are ASCOM compliant

Once you go down the automation path you might want to make use of the existing scheduling and planning software - "Glue", that holds all the different telescope/obs sub systems together.

So you may as well make use of them and just write the stuff to control the devices that are not already covered by them.

Just a thought ?

Cheers

Rally

[mldee (Mike)]

Originally Posted by kinetic

It's going to be different for each person.

Here's a wish list for me as an example:

Turn on/off Dome red lights (output)
(So I can visually check a webcam/CCTV image of the dome.
Cables not fouling etc)

Turn on/off Dome interior white lights (output) (reason as above)

Focus Camera (output)
Focus position feedback (input)

Rotate dome CW/ Anti CW (output)
Position feedback for Dome (input)

Rain detector (input)
CCD temperature (input)
Dome ambient temp (input)

Turn on Dome wideview CCTV camera or webcam (output)

My GUI would need to only address my list.
Someone else would want a different list. Or a bigger list etc.
If someone designed a GUI front end that had everything functional
then maybe just a script file (a la Mel B's Scope) could be used to
toggle on or off only the functions you wanted visible and activated.

Steve

Point made, hope we can see some more comments from others on their preferences, it gives us all a better feel for what level of complexity we need.

I've spent sometime this morning googling around the various electronic kit sellers, there are plenty of multi-channel relay and temp sensor kits out there, together with stepper and servo controllers. You've obviously done this as well, so I just put the comments in for the casual observers.

On the GUI, I'm not au fait on MEL Bartel's approach, I'll take a look, but the basic script concept sounds sensible. I don't like complex GUI's (Hate the EQMOD one), but it does get the job done.

I was thinking along the lines of a simple GUI that had BIG Buttons that were easy to click with a mouse, and some simple graphical readouts for temp, focuser, etc. Uncluttered, perhaps with one or two screen pages and suitable for use with an older surplus 486 style PC using XP, although I guess Vista should eventually also be looked at for new PC owners.

A question that's gonna come up soon from the onlookers is "Emmachizzit?". My initial response would be that since all design and programming labour is free and voluntary, it's just material costs plus the option of any paid assembly the purchaser wishes. You want it cheap, then build it yourself, if not, then pay someone to do it for you, and they can quote the cost themselves.

You can also buy all the kit components yourself if you wish, they will be listed in the documentation that eventually accompanies the project.

As a guesstimate based on that approach, the basic controller plus some I/O hardware (Relays, temp sensors, motor controller board) should be around $200 plus shipping. YMMV!

Then comes the costs of any external bits and pieces such as focus motors (12VDC, stepper or servo?) all of which are pretty cheap, say $25 each? Then comes mounting brackets to fit them to your specific focusers, Dew straps, temp and voltage sensor cables, LAN switch, old PC for the obs, pretty boxes to put everything in, etc.

BTW, speaking of PC's, one of the items I just bought to try was a small 12VDC designed-for-cars power source for PC motherboard, AUD67. Ebay here: http://cgi.ebay.com.au/120W-Auto-Car-DC-DC-PC-micro-ATX-Mini-ITX-Power-Supply_W0QQitemZ200375362086QQcmdZV iewItemQQptZAU_Components?hash=item 2ea74d6226&_trksid=p4634.c0.m14.l12 62. This is an Ebay link and don't know if it'll work for you. The Ebay shop is called Virtual Village and sells lots of Chinese-made electronic boards for cars and computer overclockers, etc......Good source of bits and pieces.

I have tried it with an Asus P4 MB including HDD and CDROM, it works just fine, powered from my 7.7Ah Gel cel. I'll measure the current later , but it didn't seem very much. I'll also take some pics. I'm just thinking of the obs PC, which could be made totally solid state with an SD card for the OS, I also have an IDE to SD card adaptor, so I'll be happy to tinker with that.

A little old PC dedicated to the Obs housekeeping and LAN accessible by Remote Desktop seems a simple approach. I have a program that formats an SD card as a boot disk, used it on my Eee PC 701 to install XP. I feel keeping the small dedicated housekeeping 486 PC seperate to your main imaging PC is probably advisable.

BTW, I use Remote Desktop here to access my Obs Dell Inspiron 1505 lappie from inside the house and it works just fine, runs CdC, EQMOD, EOS, the lot with no hiccups. My inside computer is just an old P4/3GHz + 1GB. Still have to walk outside to focus though .......

Time to go out for a tinker and some PC happy snaps.

I think I'll also break down and buy one of those Jaycar kits so I can play with controlling my 12VDC focus motor and also generate some more in-depth comments on a GUI approach.

Cheers,

[mldee (Mike)]

Originally Posted by rally

Possible suggestion ?

You probably already know that there are existing standard protocols for many of the functions that you are proposing within ASCOM.

It could make good sense that your system attempt to use these because that makes your box compliant with a large amount of existing Astronomy software out there.
It also means that you are not reinventing the wheel entirely and can make use of existing programs by writing an appropriate driver and can then mix and match amateur and commercial products as the need arises and people progress from one level to another or want the functionality that an existing commercial product offers because they dont have the skills to precision machine their own device for example.

I am sure I have read about existing Observatory controllers that make use of the Velleman board that are ASCOM compliant

Once you go down the automation path you might want to make use of the existing scheduling and planning software - "Glue", that holds all the different telescope/obs sub systems together.

So you may as well make use of them and just write the stuff to control the devices that are not already covered by them.

Just a thought ?

Cheers

Rally

Good comments, Rally, this is where the asset of having IIS reaps the benefits, so many people can make constructive inputs to the design.

I confess I'm unfamiliar with the scope of ASCOM, I just like to use it

If the wheel has been invented, that would seem to be a very sensible approach. I'll do some more research on it.

If you have access to any additional information on ASCOM-related Obs functions, links would be most appreciated.

If we can keep this as far as possible as a "glue" approach, so much the better. I'm still a little bemused that no one in the home Astro community seems to have done this. It's all been about telescopes

Cheers,

[mldee (Mike)]

Steve,

Some inputs:

The Arduino boards, http://www.arduino.cc/, which hikerbob discusses in the IIS dew controller thread, seem quite promising too. Perhaps a better choice than the Velleman?

I stumbled across an astronomy forum discussing them:http://stargazerslounge.com/diy-astr...rsion-2-a.html. The Arduino they discuss http://arduino.cc/en/Main/ArduinoBoardDiecimila seems about the right size, and removes the need for a dedicated obs PC as it can talk to your lappie or such via USB, then functions stand alone and has good wireless comms hardware available.

I also joined the Velleman Yahoo group, but it's pretty empty.

Perhaps hikerbob can give us some insight into the ardiuno stuff?

It has lots of adherents and probably some ASCOM ties as well.

BTW, for camera cooling systems hardware, googling 'overclockers' produces some interesting sites.

Cheers,

[kinetic (Steve)]

Originally Posted by mldee

I'm still a little bemused that no one in the home Astro community seems to have done this. It's all been about telescopes

Cheers,

That's just Rally's and my point (made much earlier)...

ASCOM does all this...works with loads of Astro software already and
most OS as well. And it is easy to add more functions to it.

Without first having a good look at how and what ASCOM does Mike
I think you might waste a lot of unnecessary energy.
FWIW.

Steve

[mldee (Mike)]

Originally Posted by kinetic

That's just Rally's and my point (made much earlier)...

ASCOM does all this...works with loads of Astro software already and
most OS as well. And it is easy to add more functions to it.

Without first having a good look at how and what ASCOM does Mike
I think you might waste a lot of unnecessary energy.
FWIW.

Steve

I was being a little facetious in my comment.......I'd taken a read of the ASCOM site info. The point that I was trying to make was that despite all the drivers and such written for ASCOM, I haven't yet seen an ASCOM-derived integrated obs controller unit for sale, at least at a price most of us can afford

If there are interested members who would like to advise the group into how to better use ASCOM, their inputs would be most appreciated, just don't expect too many suggestions from me, as I don't have the knowledge

I would love to see someone offer to do the ASCOM 'glueing', but it's beyond my capabilities. That's the reason for this thread.

[kinetic (Steve)]

Originally Posted by rally

I am sure I have read about existing Observatory controllers that make use of the Velleman board that are ASCOM compliant

Here is the site you may have seen Rally:
http://www.dppobservatory.net/DomeAu...DomeDriver.htm
This is where I found out about the Velleman kit in the first place
He has written an ASCOM driver for it.
When I get time I will test the driver.

Steve

[rally]

Steve,

Thanks.
I recall reading that one and there is another one with full DIY details somewhere out there too !
Probably based on the same system, just another implementation

In addition to those, there is also a Polish made USB Dome Controller that is relatively cheap - $270EU = AUD$460 (it was $350EU last year)
http://www.scopedome.com/en/scopedomeusbcard.aspx

It appears to be a very well made unit and seems to support an encoder for dome positional feedback - they supply their ASCOM compliant software free of charge.
Just add motors and gears !

I think the project is a good idea, but I am not sure if recreating all the functions that are already available is necessarily a good one.
Use ASCOM for all of its existing functions and seek to add further functionality to ASCOM by catering for those things that arent already handled. That way it can work with any custom designed software and it can work with existing software that seeks to control common devices.

This then dictates how the controller hardware should be designed and the nature of the software driver/interface to the controller and any applications that will use it.

Cheers

Rally

[mldee (Mike)]

Originally Posted by rally

Steve,

Thanks.
I recall reading that one and there is another one with full DIY details somewhere out there too !
Probably based on the same system, just another implementation

In addition to those, there is also a Polish made USB Dome Controller that is relatively cheap - $270EU = AUD$460 (it was $350EU last year)
http://www.scopedome.com/en/scopedomeusbcard.aspx

It appears to be a very well made unit and seems to support an encoder for dome positional feedback - they supply their ASCOM compliant software free of charge.
Just add motors and gears !

I think the project is a good idea, but I am not sure if recreating all the functions that are already available is necessarily a good one.
Use ASCOM for all of its existing functions and seek to add further functionality to ASCOM by catering for those things that arent already handled. That way it can work with any custom designed software and it can work with existing software that seeks to control common devices.

This then dictates how the controller hardware should be designed and the nature of the software driver/interface to the controller and any applications that will use it.

Cheers

Rally

Rally, there seems to be some misconception that the intent is to reinvent the wheel.

Actually it's more to find out what has already been made for the wheel and then build the wheel using those materials!

If ASCOM compatability is the way to go, and of course it is, then advice to us mere mortals living in suburbia is what is needed, not just asides that that's the way we should do it.

Now, can someone actually give us some concrete advice on how and what we should be looking at to implement an ASCOM-compatible project?

Cheers

[rally]

Here is the link to the ASCOM site's info regarding the 7 (6?) current device standard interfaces.
Telescope Driver
Camera Driver
Dome Control driver
Filter Wheel driver
Rotator Driver
Focusser Driver

Somewhere I think there is also a Weatherbased one - I think the Boltwood is ASCOM compliant ?
Not sure about the Flip-Flat ?

http://ascom-standards.org/Standards/Index.htm

Browsing though those and the "General requirements" should yield some idea of what its all about
http://ascom-standards.org/Standards/Requirements.htm

I am guessing that if you had a range of Hardware that was considered generically useful they might consider adding it.

In Steves case he mentioned a need to control his lighting - so maybe Astronomy related lighting and therefore a Lighting Controller in all of its variances could become a new standard and a new hardware device created ?

This would then make it modular, ASCOM compliant (assuming they can agree to it)

Most of the rest of Steve's list of requirements are already covered by ASCOM I think.
Someone just needs to make the hardware controllers, write an ASCOM driver and a Windows interface !!!

Then hopefully the rest of the world (if they think its useful) can integrate
its functionality into their software too.

Food for thought.

Rally