OK, thanks and will do
, there seems to be a non-stop set of hurdles.
So I have the control of my mount working through CdC, and my Phillips SPC900NC Long Exposure B/W Modded camera is recognised by PHD2 as the tracking camera, but PHD2 now doesn't seem to have a way to connect to my mount.
How does CdC and PHD2 work together to control the mount or is CDC just used to get you to a new location then PHD2 is activated to keep you accurately there? Is there an instance when to two clash or is their isolation a user control thing?
If that is correct that CdC and PHD2 are individual things, does that mean I can look for any other software that is compatible with my camera and my mount?
In regards to my big dream future plan of a fully automated astro photography setup. From my limited experience, I assume there would be a need to set all the viewing limits of your scope/mount, to take into account mount stop points and viewing limitations due to interference like buidings, etc. Does CdC allow you to program in all those limitations so it automatically stops heading to unviewable stars/ etc?
Is there a software that allows you to set up a photography plan, where it goes to a point, starts capturing, then goes to another point, etc? But it can also tell you, based on your set limitations, if they are possible to do? One issue may be automating the auto tracking star. Conceptually it would be possible, but not sure if it's currently done. I gather auto focusing the photography camera may be another issue depending on what in the viewer where your photographing, or is thee software smart enough to go to the nearest know star, focus, then go back to where you want to photograph?
Did you ever get your MCU to connect to PHD or PHD2? I've loaded up PHD2, but when I'm required to choose a mount, there is nothing in the small list of options even close. All I can choose from are:-
I've seen example that show many other types, but can't find how to get them.
That was a well (or unlucky) timed post I did in updating my previous post, I even checked to ensure you hadn't posted before I did.
Thanks for explaining the MCU details and the associated speeds.
From my small play with CdC it looked like I could Goto any of the locations on the sky map, which it did, then it would just keep tracking once it got there? A quick read about PHD2 seems to imply if can connect to CdC and provide auto guiding even with the web cam I have. (I'll remember to use Pulse Guide if the option is available).
I did come across CCDCiel, it looks like a pretty good capture software, it does mention working with INDI and ASCOM, but I'll do some deeper investigation to see if it can work with CdC, otherwise I may be back here workign with you again to get the INDI driver sorted
Ok, so I've installed CdC and it connected to my mount, that seemed easy enough. And it seems to be slewing from point to point.
I was wondering why the MCU upgrade used a 15 pin connector instead of a standard 9 pin. Though I'm not familiar with ST-4, is that a way of controlling the mount externally from a tracking camera? I do have an old modified Phillips web camera I used to use, though I can't remember if it was for manual tracking or automatic.
Can CdC do auto tracking using ST-4?
Is there a way to control the speed of the tracking and slewing in CdC so I can utilise the Conrad gears I changed in my mount or is that just automatic after I set the speeds through v4 Control?
Sorry for the questions, I'm basically wondering if CdC will allow me to use most if not all of the functionality the MCU Update provides such as:-
Good PEC, and
Ok. Thanks for explaining that, better to find out now then keep banging my head for the next 6 months.
You mentioned earlier you had it working fine with CdC (is it the same as Sky Chart?), did you have to do anything different to get it to work or did it just work fine straight away?
I thought EQMODs ability to interface with ASCOM meant it would work fine as long as the correct driver was used in ASCOM?
Shouldn't the ASCOM drivers convert the mount protocol to work with any ASCOM compatible interface?
If that's not the case, I'm certainly confused and my attempts to use EQMOD are pointless .
EQMOD aside, I'm still stuck on the issue of not being able to get the ASCOM Littlefoot driver to correctly communicate with my MCU Upgraded mount, with what appears to be because of a random value in the Declination.
Do you have one of the MCU Upgrade firmware v3 versions? I could try that and see if pre v4 works?
If you have any ideas or suggestions of how to fix that one, that'd be great .
I originally used MCU Control and V4 Control which were made specifically for the MCU Update. They still connect and I gather work fine.
I am trying to get EQMOD to work through ASCOM, but I believe I need to get ASCOM to connect successfully with a driver (I assume the Lightfoot driver) before I can start controlling with the EQMOD software.
I'm not familiar with CDC and I don't know where or which LX200 is Direct LX200 to use?
I assume CDC is an acronym for something so I'll look into it, if it's as capable as EQMOD appears to be (with good PEC, CCD tracking, etc) I'll certainly give it a go.
Thanks for the quick replies and continual chat this time, it's been great and helpful. I unfortunately need to get to bed now. I will be back, but not for about another 18 hours or so after work tomorrow .
Thanks again, chat soon.
"df" is the HEX for "ß"
Looks like you are getting the same.
I believe this is why it's failing in windows, because the ASCOM Driver then produces and unrealistic value for the longitude and latitude, then failing to proceed.
Ummm, that's a worry then. It's the ASCOM LittleFoot driver that is giving me the issue with not handling the "ß".
Any thoughts as to why it's giving me that issue and worked fine for yourself or how to got around the issue?
I'm using the MCU upgrade, were you using the same or the Lightfoot (I assume they are different?)?
Thanks for the thoughts Markku.
By hacking the firmware, I'd decompile it completely down to the C it was written in and change it there, then recompile it, so that would avoid the addressing issue. Though the checksum check could be an issue, or maybe not as the installer uses the version number in the filename to check against, but I don't think I'd risk it, too much of a pain to remove the MPU to reprogram it .
I'm thinking of setting up a serial man-in-the-middle Arduino to pass all the serial comms with the exception of the problem causing characters? Never done it or sure if it's possible, but it would probably be the easiest option as I've never written a driver before and reverse engineering a MPU's code is no easy task.
Ummm, that doesn't sound promising. Did you ever try the ASCOM LittleFoot Driver, it seem specifically for our MCU's (based on the name anyway)?
Do you know if the v6.18 is a compatible upgrade for the v4.17D MCU? Mind you I'd still need to find a version of it if it was
That's awesome NMAC, thanks for that.
I did some rs232 port sniffing and compared the values between using V4Control and ASCOM with the ASCOM LittleFoot Driver and I think I may have found an (hopefully the) issue.
As part of the ASCOM connection test, it passes a request to the mount for a few things, which are: #0:VX#, #:GR# and #:GD#. The mount replies to all of the requests, but it sends an extra character with the #:GD# which I believe kills the ability for ACSOM and EQMOD to correctly connect to the mount.
When the mount receives #:GD# it returns - "+00ß00".
It's very strange that the "ß" is in there, but V4Control still works fine with that, but ASCOM doesn't like it.
The Latitude and Longitude ASCOM shows after the connection (in Device Connection Tested) is 1612345:00:00.000 4898765:00:00.000, with the first numbers in each being clearly wrong.
When trying to connect in the LittleFootClassic Setup it errors saying 1612345 is out of range.
I am using MCU Firmware 4.17D and I did reflash my MCU Firmware to 4.10D, but is still had the same issue.
My next thought is to try and get the MCU firmware and modify it to remove the "ß", or try and get the ASCOM LittleFoot driver source code and modify it to correctly read values with "ß" in it.
Do you know if there is a later version firmware that 4.17D? I did see messages from Rajiva (from many years ago) talking of a version 6 Firmware, but can't find anything close and it seems there are no longer any traces of Rajiva on the Internet (maybe he was NEO )?
Any thoughts on the "ß" in the value returned by the mount?
Hi NMAC (or anyone who has it),
Could you please send me the document containing the command set. I am also trying to get my MCU modded HEQ5 working with EQMOD?