If we look at the data that Gonzo has provided it shows that the system has connected to the camera and is downloading all the information correctly. It is also able to read images from the camera and display them. That is the sort of thing that involves the USB cable and it all seems OK.
What we see is that the image data that is read from the CCD is incorrect. Sometimes it is blank and sometimes there is partial data - but there is always data. This looks as if the problem is inside the camera, getting data from the CCD. How a USB cable can be involved in this escapes me.
Gonzo, when you get the blank images exactly what does the data look like? Is is always a single value? Or does the histogram show that there is noise in the data? If the data is always one value that may indicate a problem with the ADC but if there's noise then it may be more likely to be between the ADC and the CCD. It's important to know because replacing a circuit board won't help if the problem is actually with the CCD.
I'm very happy with the Moonlite focuser hardware and software. I've made sure that the INDI software works, it needed a minor tweak a few weeks ago but that was it. The hardware is a work of art and runs really nicely.
At least some Altair Astro GP-CAM MT9M034M Mono cameras also do not work with INDI. It is fine in Windows.
From what I've heard the problem is the SDK and low level driver and AFAIK what happens is that there are two versions of this camera which are apparently identical except that they have different USB IDs. If people say their camera works this is no guarantee that yours will.
The symptom is that INDI does not recognise that there is a camera there.
Altiar are really just a box shifter, prettily badged boxes with their own logos and camera with their own ID, but they have no control over what they supply.
I've decided not to get anything from them that uses electricity. If you do then make sure you have tested it and demonstrated it works on the system you plan to use it on while you can still return it if it doesn't work. And please do so.
Possibly more a historic artefact
I'm not sue what we can do to help.
The middle image, with the vertical stripes and stars in the brighter ones, seems to indicate that the problem is the connection between the controller and the CCD, IMO probably the reading of the data from the CCD rather than the control signals used to clock the data out. That could be the white ribbon cable, the preamplifier or the ADC chip on the board.
The Lesve dome uses a Velleman K8055 USB controller board to manage the dome using a selection of relays for outputs and digital inputs to monitor the dome rotation using a gray code encoder. It polls the encoder inputs so needs to do so fast enough that transitions are not missed. There's quite a lot on the web about how the hardware needs to be set up.
The dome controller software is shareware and AFAIK is not published. There appears to be a Linux driver for the K8055 board that is open.
I don't think this is the sort of thing that can be coded without physical access to the hardware. It might be easier to start again using an arduino. Perhaps a solution already exists going that way.
All I do with my Celestron is a quick align. This gets the mount going then solve and sync to get positioned.
Vinito wrote: Regarding "park" I guess the negative I can think of is what I've experienced with mine, that being:
since "Park" is a prominent option, i.e. a button for it exists in more than one location... if you can't set up some mounts to park, then the existence of the button is worse than useless because accidentally pressing it sends the mount moving to some position (which seems random on my mount).
In my case, that "random" position has, 50% of the time, been such that it will crash the mount unless I intervene to stop it. Obviously, if a guy wanted to set up his rig to remotely control it, then an accidental sending of a "park" command is a significant problem.
If some mounts <em>can't</em> "park", then maybe having an option to select whether or not you want the buttons to be present at all on the controller screens or not would be a good thing? In the case of these types of mounts, at best it's a dead button, at worst accidental pressing of a button<em> you can never use but is always present</em> can possibly damage a mount.
In other words, in my case (and others), since my mount apparently can't park at all, if I could make the button disappear altogether on the control screens (or be grayed out and non-functional or whatever), then that could very well protect a guy's equipment from being damaged. Seems like a pretty good idea.
Looking at the iOptronv3 sources the mount does park. It gets the park altitude and azimuth, converts them to a Ra and Dec, slews to that position, then stops tracking. That should be pretty reproducible in terms of the direction the mount is looking but the side of the pier the mount ends up on may vary if it's close to the meridian.
I suggest moving the mount to the position you want it to park and setting the park position to the current position. Then save the settings. That shoud make parking more predictable.
The limits being talked about here are altitude limits. I've no idea how well they work but the thing to do is try them with your mount. If you only want a low limit then set the upper limit to 90. Set them up and try various ways to move the mount past the limit.
The other limits which would be useful are limits to the movement of a GEM which stop it moving too far past the meridian and running into the mount. These are not implemented but there's been talk that they will. I don't need to worry about these because I have a Celestron GEM and they have software limits where they should be - in the motor controller.
That's two minutes - 0.5 degree past the meridian? Had you just done a slew to this position? It could be in the zone where the mount may think it hasn't passed the meridian.
If you can't track two minutes past the meridian then you will have problems with long exposure imaging. Imagine if you are taking 5 minute images. An image starts one minute before you reach the meridian but it won't finish until 4 minutes past and that's the first time that a check can be done to see if a flip is needed.
What i think is needed are hour angle limits. They are:
A tracking hour ange limit. This is the hour angle beyond which the mount must not track. When it reaches this limit tracking is stopped and the acquisition process is paused. Normally this would be well past the meridian, 30 minutes or so, but it could be less, even in some cases before the meridian is reached.
A flip hour angle limit. This is the hour angle which is the earliest that a slew command will do a flip. Normally this is a few minutes after the meridian but some mounts - the Celestron ones for example - can be set to do the flip up to 20 degrees before the meridian.
The flip process should also be managed using the Pier Side property when this is available. At present this isn't used, it uses hour angle. As a result there's a lot of scope for confusion where a mount does a flip earlier than expected and the flip process does another one or, worse, the flip process does one too early. The system now thinks that a flip has happened but it hasn't and it tracks into a hard stop.
Given these things the acquisition process could be made more flexible and reliable. With reliable pier side (NOT simulated, that just moves the problem into the driver) the flip process can be managed correctly and witth hour angle limits things such as mounts with restricted movement can be handled.
I'd have liked to have sorted this out but the complexities and lack of documentation in the Ekos sources make it impractical for a newcomer. I've tried and the majority of my time is spent fighting my way through multiple layers of undocumented code trying to deduce what it's doing. That's not my idea of fun.
hy wrote: The easiest, but of course least elegant answer, though is that you can set the time manually (each time you boot).
I have no RTC nor GPS, but rarely use it in the field. When I do, I look at my phone, and then type something like the following
sudo date -s "10 feb 2012 8:57pm"
I believe that's right, but unfortunately I can't test right now.
Google search seems to confirm, e.g.
Could this be scripted with the time obtained from the INDI device?
I've done something like that in the ASCOM/Windows world.
Or, if your mobile phone has a data connection, use it as a hotspot. That way the internet time would be available through the phone.
The Celestron mount time uses local time, the time zone and a DST offset of one hour. The INDI mount base uses an offset only which means that the DST setting needs to be handled separately.
On reading the time I read the DST setting from the mount and use it to update the offset appropriately but when writing the time to the mount I apply the offset and force the DST to 0. This will change the time shown on the mount.
I'd like to regularise this and I'm wondering what other drivers do to handle this, options I can see are:
- Ignore it. Always set DST to 0.
- Add a DST setting to the Mount Info tab. Ideally a check box which is checked when DST is used.
- Read the current DST setting from the mount and use that.
Would reducing the ISO help for collecting flats? It's important to use the same settings for darks and bias but flats are used as a ratio so the absolute values don't matter.
This may be common knowledge but what I've found with Arduinos is that they do a reset when the serial connects and it takes a couple of seconds to get started.
A two seconds delay after the connect can help a lot.