Hi. glad to see SC4 is now available including an ASCOM driver! . questions - max bin mode? Does the ASCOM driver support the SC3? Can you specify the distance between the 4 mounting holes on the SC4 and what screw thread and length is required as I will need to attach this to a custom adapter between the FW side of the SC4 and the FW. Why still USB 2.0 and not 3.0? I am sure you told me that you were going to feature a new sensor but this has the same sensor as the SC3? Regards Martin
Martin, StarChaser supports up to 4x4 binning, though anything above 2x2 is done in software. The ASCOM driver supports all DL Imaging models. It's designed for our standard large format mounting plate https://cdn.diffractionlimited.com/downloads/STX_Mounting_Plate.pdf, which has four 6-32 screws on a 2" radius from center. USB 2.0 is plenty fast enough for this small array, but also please see next answer. We have been working on a new version of the circuit boards, which will support a new sensor. We switched it over to USB 3.0 simply because that's what we're using on all new USB-based designs. Unfortunately we had to put that project on hold for now, as our engineering resources are tied up on another project. In the meantime we are using an IR-enhanced version of the original sensor. Nevertheless, the SC-4 features an all-new mechanical and optical design: It incorporates a 0.7X focal reducer, to provide a larger field of view and greater sensitivity The focus mechanism is greatly improved. In the original version we were limited by using some off-the-shelf hardware, so the focus knob was tiny, the motion was overly fine, and the focus moved out when you turned the knob clockwise, which is confusing. In the new design we've designed a fully custom mechanism that resolves these issues. The mirror position can now be adjusted using an external knob, which means you can easily make adjustments without dismounting the camera. Doug
2x2 for sure; we were planning to do 3x3 and 4x4 - I just need to wait until the guys are in the office to find out if that made it into the drivers. Yes, it has been out for quite a while. We have 32-bit and 64-bit ASCOM drivers that support all the DL Imaging based cameras: SBIG StarChaser SC-2/3/4 off-axis guiding cameras SBIG STC-7 / STC-428 CMOS cameras SBIG Aluma CCD47-10, 77-00, 694, 814, 8300, 3200 CCDs SBIG Aluma AC2020BSI, AC4040, AC4040BSI sCMOS cameras It's the same 4-inch bolt circle pattern used on all the 3-inch hardware, like the STX-, AC-4040, FW5/7, AFW-series filter wheels. The unit is 0.875 inch thick. Hole size for 6-32 machine screws / socket head cap screws. Longer cable lengths are possible with USB 2.0. 480Mb/s is plenty fast for the data and size of sensor. There's no advantage. This has the enhanced version of the sensor used in the SC-3. It is slightly more sensitive and picks up more of the deep red/near IR.
Doug/Colin SC4 received and tested oK. In this very short test, the ASCOM driver worked perfectly with SkyX. Great to see the 1/1000th of a second exposure capability back. But wow it gets really hot…one needs to be careful about putting a finger on that little heatsink you put on there….very hot indeed. I will send you an operational report in due course. Martin
Doug...so I still cant use the SC4/AOX combination with the SkyX or any other program for that matter e.g NINA - why is that? If I choose DL Imaging as the native driver outside TSX I can tell it that I have an AO attached. If I select the ASCOM driver with TSX and then bring up the DLImaging Camera 1 Setup dialogue, there is no option there for me to tell it that an AO is attached. By doing this you are tying users to Maxim DL to take advantage of what is supposed to be an independent guiding unit to include an AOX. On top of that, you cant use any 64bit driver with Maxim. So I am in exactly the same position as before with the SC3/STX16803/AOX i.e extremely limited in how I can use it. Surely this is an oversight? Can it be remedied? thanks martin
That is outside our control. ASCOM doesn't have an AO interface standard. TheSkyX would have to support it through our native API.
That is really quite disappointing. I have always thought that an ASCOM driver would deliver the same functionality as a native driver, much like the ASCOM driver for a Paramount which allows the use of Direct Guide. Any reports on how v6.4 is now handling AO operations because that was another failure with the SC3 i.e getting it to calibrate the AO/drive. Separate question: I need to make a custom power cable for the SC4. There are 2 wires in the cable, one is sheathed in white the other is loose....from the manual it would suggest that the loose cable is negative - is that correct?
Remember you are working with someone else's software here. We have absolutely no control over it whatsoever. You should bring this up with them. As for ASCOM, remember that AO is a separate device, so it would need a separate interface. As an example, ASCOM has separate Camera and FilterWheel interface standards. If you talk to one of our filter wheels, it just happens to send the commands through one of our cameras. But that's completely under the hood from the ASCOM perspective - the application software doesn't even know it works like that. The same thing would apply to AO. It's a device that wiggles the optical path to stabilize the image. It's not part of the camera. In our case we communicate with it through the camera, but that's an implementation detail. Unfortunately there is no ASCOM AO standard, and there has been very little impetus in the community to develop one. It comes up maybe once a year, there's a couple of messages, and then it goes dormant again. I'm guessing that's because there are very few programs available that support AO, and not very many products on the market. It is also surprisingly complex to implement a program to operate an AO. Aside - ASCOM is NOT the same as a native driver. Here's why: ASCOM is a fantastic innovation, which provides a standardized way to talk to astronomy equipment. In order to do that well, it doesn't try to implement every single little feature that every piece of equipment provides, because it's pretty much impossible to do that. ASCOM implements all the functions that are needed for normal observing operations - for a telescope mount that would be things like slewing, guiding, adjusting tracking rates, resyncing etc. It includes all the stuff that your planetarium or imaging program wants to use. The Telescope standard is pretty mature and does a lot, but by intentional design it does not include "engineering" functions. You can't set the PEC curve of a mount through the ASCOM interface. That's by design because every manufacturer implements PEC very differently, often radically so, and it's pretty much impossible to come up with a standard for that stuff that makes any sense. The ASCOM driver may have the capability to program PEC for that specific mount, but that will be in the driver's Setup dialog. That's where you're supposed to put all the equipment-specific stuff that is rarely used. Putting on my application developer hat, I don't even want to know about that manufacturer- and/or product- specific stuff. I wouldn't know what to do with it.
There has been some progress on the AO driver in MaxIm DL, but to be completely honest I'm not certain we have it absolutely perfected yet. We're close. A couple of users say that there might still be a nit with the calibration function, while others haven't had any problems. One customer has suggested that calibration doesn't work properly with binning... might be true, might be a total red herring... we need to test it. As I mentioned above, it's tricky software and very hard to test properly on a bench. I've been wanting to do some more field testing in my observatory, but we usually get crap weather here from November 1 to about mid-January... and yeah, it's been like that. Cloud city. (Relatively warm and no snow... but as cloudy as usual.) As for the power cable... the center terminal of the jack is positive. I have no idea what the color convention is on the wire, because we don't make the power supplies. They're built to order for us with our specified connector already installed. I'd literally have to cut the wire on a power supply to find out. Also over the years we've used a few different suppliers, and they do things differently. It's safest to get a voltmeter and check! IMPORTANT TIP: If you make a custom cable, test it with the USB disconnected and the StarChaser not touching the telescope or camera. Otherwise if you wire it backwards, you can short the power supply directly to another ground (especially USB), and that will make smoke. We protect ourselves against reversed power, but having the +12 connected directly to the USB ground isn't going to end well if there's a shared ground anywhere in the system. Usually there is substantial damage to the camera and the computer. As you can imagine, setting the camera on fire is not covered by the warranty. Isolate the StarChaser from everything else, plug in the power, and listen for the power-up sequence (shutter clicking). If that doesn't happen, you probably have it wired backwards!!! Unplug immediately and double-check. If the StarChaser shutter clicks and the little red light turns on, you're good to go.
Ok, all noted thanks regarding the power cable, it is not centre positive....the power socket on there has 6 pins...3 on the right are +12v and the 3 on the left are GND. So given the uncertainty that v6.4 has not fixed all the problems its probably not worth me spending $190 to upgrade. All this just makes my planned trip to Chile on 16 Jan a total waste of money.
What Doug was talking about is the power cable wire itself. The wire is a coaxial cable - it has a centre conductor that is +12V and the outer shield braid is Ground (0V). Then you have the 6-pin Kycon connector - wiring in the manual.
Sorry yeah there's been several versions of the cables over the years. Confused wording there. When wiring up the Kycon connector it's very easy to get it backwards. Pay close attention to the orientation of the diagram. It's looking into the camera. If you wire it up thinking the diagram is looking into the connector, you'll reverse it. This has been done before, with catastrophic results! That's why my warning about isolating the StarChaser when testing the power supply.
News is that we're going to make a change to the way binning operates for the SC-2, SC-3, SC-4 guiders which we think will help with star detection; this change is part of DLImaging drivers, and will be made available to you as soon as we finish some related development. I'm also looking at the AO code in depth to see if we can modify it to give better diagnostics to determine what the actual cause of the problem is at your end. We've also determined that there is a lack of consistency of the problem from customer to customer. Some have had their hardware repaired - and are no longer having issues since they have repaired their mounts, cabling, computers, operating systems, binning, optics, power, grounding. Others are still experiencing issues and there is little consistency between them making it very hard to figure out what the cause is. When I get back from AAVSO meetings, am going to do a new system build in the observatory to see if I can figure out what makes the problem occur.
