Jump to content

Stargazers Lounge Uses Cookies

Like most websites, SGL uses cookies in order to deliver a secure, personalised service, to provide social media functions and to analyse our traffic. Continued use of SGL indicates your acceptance of our cookie policy.


  • Content Count

  • Joined

  • Last visited

Community Reputation

13 Good

1 Follower

About Mart

  • Rank

Profile Information

  • Location
  1. I have three OTAs in my Obsy each with a motorised focuser but only one focuser control unit. I just swap the cable from the controller to the focuser motor on whichever OTA I'm using for imaging. I'm now "upgrading" to run two cameras to double my image capturing whenever there's a gap in the clouds. So I need two focuser control units. I've started a build of Robert Brown's DIY controller - just waiting for the bare PCB to be delivered from China. I have a Lakeside focuser motor connected to one of the OTAs which has the standard Robofocus motor wiring on pins 1-5 of the DSub - but it also has a temperature sensor which looks to be connected to the pins 6-8. Does anyone know what type of sensor is on the Lakeside units and what the pinout connections are across the pins 6-8? If possible I thought I'd use this temperature sensor to do the focus compensation.
  2. Thanks Chris. Still puzzled. I've found set park commands in TheSkyX and POTH but neither seem to be permanent. When I disconnect and power down the scope and PC and power it all up again the client software is still sending the mount to somewhere other than my Home position. I wrote a VBscript to perform an explicit setpark and have put that at the beginning of my CCDC script - so long as the mount is in the Home position I can then run the CCDC script and the Park commands work. I just didn't need to do all this "last week"?
  3. I have an EQ8 worked through EQMOD connecting with a number of clients - TheSkyX, MaximDL, CCD Commander etc. I ran a CCDC script last night and was puzzled as to why when it did a "Park" command the mount put the scope on its side. A Park from any client has always (in the past) put the scope upright with weights down (my Home position). However, EQMOD still Parks to the Home position. I've been trying lots of things this morning, turning off - moving scope - turning on; resyncing encoders; autohoming using SynScan handset and rehoming .... but not fixed the problem. The EQMOD message centre shows when I use EQMOD to Park the scope: Slewing mount to home position I've now tried the Park command from three different clients and they all do the same sort of thing: CoordSlew: RA[ 01:55:00 ] DEC[ +87:48:44 ] Goto: 01:55:00 +87:48:44 Goto: 01:55:00 +87:48:44 Goto: 01:55:00 +87:48:44 Goto: 01:55:00 +87:48:44 RA Motor set at Sidereal rate Goto Slew Complete. 01:55:00 +87:48:44 Goto: SlewItereations=4 Goto: RaDiff=000.03 DecDiff=000.02 CoordSlew: RA[ 01:55:33 ] DEC[ +87:48:44 ] Goto: 01:55:33 +87:48:44 Current location set as new park position. Goto: 01:55:33 +87:48:44 Scope parked. You may turn it off after slewing When I do a Park, EQMOD is doing a slew to a specific coordinate ? I've done a lot of fiddling with the software to get it working after a Windows 10 Anniversary upgrade (lots of discussion elsewhere) so am guessing I've changed something somewhere along the way that has change what the ASCOM Park command now does. EQMOD is configured with "Park Mode" as "PARK at Home Position" - but this only seems to apply when I Park from EQMOD, if I park from ASCOM clients it does this CoordSlew. Any ideas ?
  4. Well, I suppose it was bound to happen as we approach Halloween fright season ... My observatory PC decided to do the Win 10 Anniversary upgrade ... my observatory is now broken. I can no longer connect to my mount and my dome controller has stopped working. Many thanks for all the suggestions above - I went for the fix Billy pointed to at http://www.totalcardiagnostics.com/support/Knowledgebase/Article/View/92/20/prolific-usb-to-serial-fix-official-solution-to-code-10-error and it worked a treat, I can connect to my mount, lovely. .... but now I can't connect to my Robofocuser. It seems the RS232 to USB adapter I use with my Robofocuser wants to use the same Prolific driver that the Hitech adapter uses ... I've tried lots of different versions of the driver but I haven't found one that both my mount and my focuser like ! The Robofocuser RS232 to USB adapter is quite happy with the new windows drivers - presumably it uses legitimate chips rather than the counterfeit chips in the Hitech adapter? As for the dome controller - I think it's just come out in sympathy with the others, the driver looks to be working - it looks like it's the electronics inside the dome controller itself that's failed. Can I blame Win 10 Anniversary upgrade for this too ? Mart NB - I have a workaround for the Robofocuser - there's still an RS232 D-sub on the back of my obsy PC so I've plugged the Robofocuser in there for the moment.
  5. Hi Hugh, happy for you to play with the app - but the code is not a pretty sight. Come to that the app might not be that pretty - e.g. if you haven't got ASCOM installed you may get an "unhandled exception" rather than a friendly user error. I've zipped up and attached the programme. As mentioned above, I'm running it on Windows 10. I know it doesn't run on Windows XP so can't vouch for any other operating system. Happy to share my "experience" from putting it together if there's a problem you've had doing similar things. Cheers, Mart DPoint.zip
  6. Last October I started a topic (here) seeking help for a "challenge" I had with pointing side-by-side telescopes through the narrow opening in my motorised dome. After a lot of research, going back to first principles on spherical geometry and teaching myself how to do Visual Basic programming - I've come up with a software solution I've called DPoint. It's running on my Windows 10 Observatory PC and acts as a "pointing controller" for the dome. I set up the dome and telescope geometry measurements in DPoint and tell DPoint how to connect to the dome and telescope. The software then gets the Alt-Az data from the scope, performs some maths using my scope configuration and hey presto, DPoint works out where the dome needs to point and tells the dome to go there. DPoint polls the scope every few seconds and tells the dome where to go - this lets the dome follow the scope when the scope is slewing. I've been really pleased with how well this has worked - I can select the scope I want to use and DPoint positions the dome opening so the scope is right in the middle of the opening. Here's some screen shots of what DPoint looks like. First is the configuration tab where you set up the dome and scope geometry, for some reason I built it to support five scopes (I only have two but clearly had aspirations for more?): Next is what I called the Setup tab. This is where you connect to the scope and dome and select which scope you want DPoint to slave the dome to. DPoint remembers everything you configure but I also added some Import/Export buttons to make it easy to backup or moving the configuration data around: DPoint is the "operational" tab. In the top half I show where the scope is pointing, where DPoint thinks the dome should be pointing (Target) and where the dome is actually pointing (Current). To slave the dome to the scope you just tick the "Slave Dome to Scope" checkbox. I added the bottom half of this tab to give me full manual control of the dome - I can nudge it left or right, slew the dome to a specific azimuth, Park the dome, Sync the dome to the Target azimuth, and as always, have a big Stop button: The two controls on this tab I haven't mentioned ("Use DPoints" and "Add") are for another pointing mechanism I built into DPoint but haven't fully tested - because I found I didn't need it. If you find that DPoint has quite centred the scope in the middle of the dome opening you can manually move the dome and when it's in the right position press the "Add" button. This adds a "DPoint" coordinate to a database DPoint builds up. If you have enough DPoints in the database, you can tick the "Use DPoints" checkbox and DPoint calculates the Dome Target as normal but then looks at the nearest DPoints in the database and works out a new Dome Target by blending the DPoints data with the original calculation. This seemed like a neat idea at the time to compensate for any non-linearity in the dome geometry or dome pointing (e.g. my dome is not actually level !). However, the maths works fine without having to get the DPoints stuff working. So I can now happily leave the observatory to run my photographic command scripts overnight with the dome following the scope around - I even (eventually) got the setup to handle meridian flips in the middle of the night. All I need is a dark sky and no clouds ....
  7. Ahah, there was something obvious I was missing. Always upgrade to the latest version of your software. ASCOM-talk forum advised that there was a problem with side-of-pier flagging in earlier versions of EQMOD which probably account for the wrong geometry I was seeing. I've upgraded to the latest version of EQMOD ASCOM and the Dome Target Azimuth looks much more sensible. Now I'm just back to my original problem - how can I adjust the Dome pointing to centre either of my side-by-side scopes to the Dome opening. (Note to self, always check software versions ...)
  8. Even more puzzling. I've just connected to the "Telescope Simulator for .NET" and slewed to "Kappa-1 Cet/96 Cet/HIP15457 (Star)". The scope and dome data look similar to yours: I then connected to the "EQMOD ASCOM Simulator" and again slewed to "Kappa-1 Cet/96 Cet/HIP15457 (Star)". The scope data looks the same but the dome data is completely different ???? I changed nothing else - so it looks like the EQMOD driver is confusing the calculation of the Dome pointing somehow ?
  9. Back to the start of this discussion and my problem of pointing the dome with side-by-side scopes on a GEM. I've reworked the measurements in my dome and used Steve's spreadsheet (thanks Steve) to get the signs the right way up ... and my dome still doesn't line up with the scopes. I tried MaximDL and POTH. I prefer MaximDL as it tells me the "target" azimuth it's trying to get to for the given scope azimuth. With POTH I can only see the dome's current azimuth - so I don't know where it's actually trying to get to but it's not in line with the scopes. I've just connected the ASCOM telescope simulator to MaximDL and slewed the scope to 90 deg Azimuth, here's the EQMOD telescope data, the Dome view from MaximDL and the Slaving Parameters in MaximDL: What puzzles me is that I've pointed the telescope to 90deg Azimuth, the GEM is leaning back so the scopes are "south" of the mount pivot point so I would expect the Dome Target to be greater than 90deg Azimuth - but the Dome Target is 74deg, i.e. north of the mount pivot point. I'm wondering whether there's something really obvious I'm missing ? NB my location is 52 deg N (51.965183, -2.691222)
  10. Hi Hugh, I think you said you had a number of Arduino modules doing different things. You connect the one you use as the controller to your PC with a USB cable - as you do to download the code and run the window to read values during debugging. That window terminal on your PC is connected to the USB port that's connected to the Arduino board - so what you type into the terminal is sent down the USB cable to the Arduino and the messages from the Arduino come back up and are displayed in the window. When you connect the ASCOM driver to the Arduino, you open the setup dialogue and select the USB port that's connected to the Arduino - so now the ASCOM driver is talking to the Arduino. Here's a code snippet from my driver: Public Sub Park() Implements IDomeV2.Park Dim s As String = "GOPARK#" objSerial.Transmit(s) objSerial.ReceiveTerminated("#") TL.LogMessage("Park", "Completed") End SubMy protocol uses a "#" character to delimit my commands, so this command sends a text string "GOPARK#" to the Arduino. At the Arduino, I'm listening for serial data to be received: if (Serial.available() >0) { cmd = Serial.readStringUntil('#');this puts into my string variable cmd the text "GOPARK". I then have some conditional logic looking to see which command it is:else if (cmd=="GOPARK") { bCmdMatched = true; if (eDomeState == stationary) { goPark(); // Dome in Tracking mode so command is to Go Park Serial.print("0#"); Serial.println(); // Command complete response to ASCOM Driver }so if it is "GOPARK" I call a subroutine "goPark" which does the actual parking of the Dome. When that routines finished I then send the text string "0#" back from the Arduino to the driver to tell the driver the command has completed - if you look at the driver there's a line waiting for "#" character to be sent by the Arduino objSerial.ReceiveTerminated("#") The driver then carries on with whatever it needs to do next. Hope that gives you an idea. Regards, Martin
  11. Hi Hugh, as Andrew describes, the ASCOM site has developer downloads and a couple of very good tutorial videos that are worth stepping through if you want to go down the DIY path - http://ascom-standards.org/Developer/DriverImpl.htm I developed my own simple protocol to talk between the ASCOM Driver and my Arduino - from the Arduino end it's "just" a matter of doing serial reads and writes. You parse what you receive from the ASCOM driver to work out what command it sent and then send back an appropriate response. The great thing about using Arduino is that you can just use a dumb terminal on your PC to talk to the Arduino - so I would write some dome code and then test it out by sending and receiving commands using the terminal. Only when I was totally confident that the Arduino was doing what I intended did I then start to develop the ASCOM driver. The downside of this approach is that I found the ASCOM commands weren't quite what I was expecting and I had to rework some of my simple protocol and Arduino code. But you live and learn. Regards, Martin
  12. Steve, that's great, I'll have another go at measuring up my observatory and trying out POTH. The measurement I have least confidence in is the U/-D offset from the notional "equator" of the dome - the dome is distinctly not hemispherical. Any feeling for the sensitivity of the maths to this dimension ? Hi Hugh, not wanting to discourage you but this project is hard ! Happy to help where I can. I can't quite picture your system model but here's an outline of the bits in my systems that control the dome if it helps (I ought to draw a picture - maybe later, I'm meant to be fixing a plumbing problem on our central heating at the moment): CCD Commander - a script runs my photography session and talks to lots of other software, tells MaximDL what to point the scope at | v MaximDL - controls the scope, camera, guide camera and dome, the dome is set to "slave" to the scope. MaximDL works out where the dome needs to be to line up with the scope. MaximDL sends an ASCOM "SlewToAzimuth" command to the dome every second | v ASCOM Dome Driver - converts the "SlewToAzimuth" command from MaximDL into the specific command strings that my dome understands | v Arduino Dome Rotator - receives the command string to rotate the dome to a specific azimuth, works out how many motor steps that will take and starts stepping | v L297 Stepper Motor Controller - takes a step pulse from the Arduino and turns it into the appropriate motor phase waveforms | v L298 dual bridge driver - takes the motor phase waveforms and drives constant current to the stepper motor windings | v 4Nm Stepper Motor - steps | v 100:1 gear box - drives a pulley | v pulley drives the belt to turn the domeFor me to use POTH I'll use MaximDL to control the scope, POTH will "listen" to where the scope is pointing and I'll have POTH talk to the ASCOM Dome Driver. From your description, if you want to connect the POTH directly to your dome controller you would have to write an ASCOM Dome Driver to join the two up. I guess the Lesvedome systems has its own ASCOM driver and your controller is talking to the Lesvedome systems. In which case, to use POTH you just select the Lesvedome driver to talk to the dome ? Good luck, Martin
  13. Hi Mike, my challenge is that I have an old dome with a much narrower slot opening - just a fraction over 20". When the GEM is slewed over on its side my 10" has to be aimed exactly mid-centre of the opening to see through it and the side-by-side 4" scope is looking at the inside of the dome. For photographic sessions I have to choose which scope to use and align it to mid-centre of the opening and that's fine with the dome slaved to the scope so long as I keep away for the zenith - but after a meridian flip the geometry is completely wrong and the scope is looking at the inside of the dome again. I've tried using POTH, MaximDL and CCD Commander to do the maths to control the dome and using the same mount measurements they behave very differently. I've found MaximDL to work best for me so far. I gave up on POTH as I couldn't get it anywhere near right - it seemed to think the mount was reversed ? Is there a dummy's guide to how to enter the mount dimensions into POTH and when a dimension is +ve or -ve value. Many Thanks, Martin
  14. Summer last year I started a little project to motorise the dome on my observatory. Little did I know that it would get so involved and take so long. The need to motorise the dome arose when my old LX200 mount finally gave notice and I decided to invest in a new mount - I opted for an EQ8 GEM. I have two scopes which I wanted to mount side-by-side - a 10" Meade SCT and a 4" refractor. I was agog to watch the GEM leaning over as it contorted to slew to a target. By the time I moved the dome to line the slot up with one of the scopes, the scope is leant over and looking through the dome slot at such an angle that I found myself continuously having to nudge the dome round in order to take long exposure photographs. Thus started the project to motorise the dome. After much mechanical, electrical, electronic and software engineering I now have a motorised dome that my various astronomy software can connect to and command to slew to an azimuth or slave to my scope. Now for my (current) problem. In my various software I can configure the dimensions of the GEM within the dome such that the software can calculate the azimuth for the dome slot in order for it to line up with the scope. However, this only applies for a single OTA neatly arranged symmetrically on top of a GEM - I can find nothing that will handle a lopsided side-by-side scope arrangement on a GEM. Has anyone had and solved this problem ? Does anyone have (and is willing to use) the mathematical skills to work out an algorithm to calculate the dome azimuth for this arrangement ? Thank you for listening - a problem shared is ... still a problem unless there's an answer. Martin
  15. Mart


    Herefordshire skies
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.