Nice work!

I take it that you are running with two instances of the dsi_ccd driver then? That sounds like a pretty good solution to me, though it seems that some other CCD drivers support multiple devices per driver. I don't know if there's something to be gained by that approach, though? Jasem?

I suspect that you could get a non-zero serial number reported by the devices by uncommenting DsiDevice.cpp:298. The comments regarding the actual serial numbers are not encouraging, but you might have a reasonable chance at getting something unique.

I'm glad to hear that your DSI III is working with the INDI driver...I think you're the first one to confirm this.

I'll work on improving the driver to include the DSI model name and serial number properties in the INDI control panel.

Thanks,
Ben

Read More...

Are you sure you're using the right serial port? You can use gnu screen or even cat to send simple commands and see onstep respond to them since it's all just ascii.
-Ben

Read More...

I am able to reproduce the high memory usage of indi_dsi_ccd using the script that was provided. Interestingly, I don't see anything obviously wrong using valgrind. I think I was able to reproduce the same high memory usage when I was using ekos, but the memory usage was attributed to kstars rather than indi_dsi_ccd. I'm going to look at other driver code to see if they do something the indi_dsi_ccd driver does not.

I still haven't been able to reproduce the failed exposure.

Read More...

I'm unable to reproduce either of these problems on my raspberry pi. Could you share your script?
-Ben

Read More...

I was actually seeing kstarts ballooning up, not indi_dsi_ccd. The memory leak bug that I thought was there is actually in the code, but it seems g++ handles it just fine. So, I'm unable to reproduce the high memory usage of indi_dsi_ccd on my intel machine. I've also been unable to reproduce the problem of not being able to download an image.

I'll fire up my raspberry pi and see if i can reproduce it there.

It might be helpful if you could share the logs from the shell running indi_dsi_ccd (indiserver).

Thanks,
Ben

Read More...

I think I see the memory leak in the code (and I definitely see it when running). I'm going to try and get valgrind running to make sure I get them all.

I'm attempting to reproduce the main issue that you posted about. I'll let it run overnight and see what happens.

Thanks,
Ben

Read More...

Hi Soren,
I'm assuming this is repeatable, is that right? If so, could you provide instructions to reproduce it?

Thanks,
Ben

Read More...

Hi,
Were you able to test the DSI III? I see an issue with the reporting (you would probably see a message saying "Found a DSI with an unknown CCD: 285AQ") but that shouldn't affect the functionality. Hopefully it's working for you!

Thanks,
Ben

Read More...

The changes have been merged into the indilib:master. Do you use Jasem's PPA? If so, the initial support for DSI III color should be there tomorrow. Please let me know if you try it (whether it works or not).

Thanks,
Ben

Read More...

Hi guys,
I think I have found and fixed the "Telescope did not respond to ACK" problem. The root cause is a copy/paste error in the firmware. All responses to the ACK command were being sent to serial port 0. This explains why I was able to connect using serial port 0, but not serial port 1. I have fixed the code and submitted a pull request to Howard. Here are my changes in case anyone is interested:
[ben@zen OnStep]$ git diff --staged
diff --git a/Command.ino b/Command.ino
index 415f7dd..4554ff2 100644
--- a/Command.ino
+++ b/Command.ino
@@ -1262,9 +1262,9 @@ boolean buildCommand_serial_one(char c) {
// (chr)6 is a special status command for the LX200 protocol
if ((c==(char)6) && (bufferPtr_serial_one==0)) {
#ifdef MOUNT_TYPE_ALTAZM
- Serial_print("A");
+ Serial1_print("A");
#else
- Serial_print("P");
+ Serial1_print("P");
#endif
}

Thanks,
Ben

Read More...

Are you able to build INDI from source? What OS are you using and on what platform? What is the version of INDI that you are currently running?

Thanks,
Ben

Read More...

Well I'm not quite sure what I did to make it work, but it seems to be functional now. Now I just need to figure out how the heck to use it...

Thanks!
-Ben

Read More...

Hi azwing,
Thanks for this driver! I'm attempting to test with my OnStep (Teensy, if that matters) setup and am not getting very far...

I'm using OnStep-alpha so I have the changes you submitted to the controller for :Gc#. I'm also built the latest version of indi directly for Jasem's github repo. Here is the error that I see:

DEBUG 632.829915 sec : Toggle Debug Level -- Scope Verbose
DEBUG 633.449983 sec : Toggle Logging Level -- Scope Verbose
DEBUG 635.944619 sec : Testing telescope connection using ACK...
DEBUG 646.055417 sec : Failure. Telescope is not responding to ACK!
ERROR 646.055583 sec : Error connecting to Telescope. Telescope is offline.

I have tried connecting both via bluetooth (rfcomm) and the virtual serial port from the USB connection. The OnStep controller works just fine when I use the Android application. I don't see that the OnStep controller code supports the <ACK> LX200 command, but I didn't look very hard and suspect that I'm wrong about this. Any ideas?

Thanks,
Ben

Read More...

I am attaching some patches that you could try. Alternatively, you could clone my indi tree from github.com/bgilsrud/indi/ and build the indi-dsi 3rdparty driver. Please let me know if you have any questions.

Thanks,
Ben

Read More...