Gene and Fabrizio's responses came while I was writing mine. Thanks guys. I did increase the timeout, by the way, to no avail. I like Gene's option. If this were my main mount (or if someone had already written up an easy recipe for doing this directly from a Raspberry Pi), I'd probably go for it. Seems like using the HC port is the better fit for me, assuming I can find the right adapter and get it to work.

Read More...

My naïve reading of the Connectivity section of the driver docs was that the "proper level converter" that was needed was simply something to bring 12v down to 5v, and that this was inherent to any standard USB/Serial adapter. But there's something else needed?

Perhaps the driver documentation needs some clarification and cleanup? The document I'm talking about is here: indilib.org/telescopes/celestron/celestron-aux-driver.html. One of the options it describes is "serial cable connected to Celestron AUX port." The warning about needing a "proper level converter" seems to only be with respect to the "old standard RS-232 [with] symmetric +/-12V signalling." On the other hand, the document indicates that since the "cheapest USB/serial converters . . . have serial lines with TTL levels (+5V,0V) . . . they [actually] work with AUX port."

As for the HC port, any suggestions on the best place to get a USB/Serial cable that will actually work with it?

Read More...

My other mount is in the shop, so I thought I'd play around with this driver and my old Nexstar SLT to put together a first smart-scope for my kids.  But it's not quite working out.  Has anyone tried this driver with an older (circa 2008) Nexstar SLT?  

It appears to be working directly through the handset, but the whole point of this driver to me at least is to connect directly to either the HS or AUX port.  For the HS port, I'm wondering if my USB-Serial (FTDI) adapter lacks symmetric voltage.  I'm trying to find a compatible adapter, but the ones on Amazon tend not to specify whether they support symmetric voltage.

For the AUX port, I've successfully used the SkyPortal WiFi module (which I lost) with this mount in the past, so my understanding is that I should be able to use the AUX port.  I've made my own cable, so maybe I did something wrong there.  Here's what I did:

RJ12 pin 1 <-> DB9 pin 8 (CTS)
RJ12 pin 2 <-> DB9 pin 2 (RX)
RJ12 pin 3 (not connected)
RJ12 pin 4 <-> DB9 pin 3 (TX)
RJ12 pin 5 <-> DB9 pin 5 (GND)
RJ12 pin 6 <-> DB9 pin 7 (RTS)

The driver thinks it is connected, but the mount does not respond to commands.  Looking at the logs, the driver does not appear to actually be receiving anything from the mount,  Rather it's just getting back an echo of what it sent, which it then ignores.

Looking deeper into the logs and the code, it appears to not be receiving a CTS signal.  detectRTSCTS() returns false.  There are no handshake errors, which I interpret to mean that waitCTS() is never seeing the TIOCM_CTS flag.  I'll spit out an excerpt from the log below just in case I'm misinterpreting.

DEBUG    6.428512 sec    : Connecting to /dev/serial/by-id/usb-FTDI_FT232R_USB_UART_A16IRNH1-if00-port0 @ 19200
DEBUG    6.436192 sec    : Port FD 3
DEBUG    6.436338 sec    : Connection successful, attempting handshake...
DEBUG    6.436417 sec    : CAUX: connect 3 (serial)
DEBUG    6.792473 sec    : detectRTSCTS = false.
INFO    7.349836 sec    : Setting serial speed to 9600 baud.
CSER    7.400070 sec    : CMD <56>
CSER    7.400170 sec    : aux_tty_read: 3
ERROR    8.401306 sec    : Timeout error
INFO    8.401479 sec    : Detected Mount USB serial connection.
DEBUG    8.401557 sec    : Communicating with mount motor controllers...
CAUX    8.401638 sec    : CMD <     GET_VER>  APP ->  AZM
CSER    8.451916 sec    : CMD <3B 03 20 10 FE CF>
CSER    8.452100 sec    : aux_tty_read: 3
CSER    8.452221 sec    : aux_tty_read: 3
CSER    8.452312 sec    : aux_tty_read: 3
CSER    8.452436 sec    : RES <3B 03 20 10 FE CF>
CSER    8.452583 sec    : Got 4 bytes:  ; payload length field: 3 ; MSG:
CSER    8.452688 sec    : [3B 03 20 10 FE CF]
CAUX    8.452758 sec    : RES <     GET_VER>  APP ->  AZM
CAUX    8.452825 sec    : Got msg not for me (AZM). Ignoring.
CAUX    8.452903 sec    : CMD <     GET_VER>  APP ->  ALT
CSER    8.503168 sec    : CMD <3B 03 20 11 FE CE>
CSER    8.503328 sec    : aux_tty_read: 3
CSER    8.503422 sec    : aux_tty_read: 3
CSER    8.503501 sec    : aux_tty_read: 3
CSER    8.503595 sec    : RES <3B 03 20 11 FE CE>
CSER    8.503673 sec    : Got 4 bytes:  ; payload length field: 3 ; MSG:
CSER    8.503737 sec    : [3B 03 20 11 FE CE]
CAUX    8.503795 sec    : RES <     GET_VER>  APP ->  ALT
CAUX    8.503852 sec    : Got msg not for me (ALT). Ignoring.
INFO    8.503909 sec    : Got response from target ALT or AZM.
DEBUG    8.503965 sec    : Connection ready. Starting Processing.
INFO    8.504064 sec    : Celestron AUX is online.

Marco,

This thread just saved me a lot of time and frustration. I was literally hunting down the KStars Lite source code so I could see what I could do to make it useable, when I stumbled upon your new app, which I'm sure is way better than I would have come up with. Question, though. You guys mention plate solving, and I can't find anywhere in the app to do that. Am I just blind and missing it, or is it not supported yet?

Thanks,
Karl

Read More...

I don't have a K3-II for testing. I wouldn't object to having one, of course, but my wife thinks the money would be better spent elsewhere

I think someone else was having some issues with the K3-II as well. I can't recall where that conversation ended up, but I think the issue was related to this thread: github.com/asalamon74/pktriggercord/issues/25 . So perhaps try astrotracer mode instead of bulb, and make sure that bulb mode is in press-hold mode? Oh, and just in case, make sure you're in MSC/MFT, because I suspect PTP does not support bulb on any camera.

Read More...

Just FYI, it is also possible to connect over wifi *if* you get the INDI server on the same network as the PMC8. There's several different ways of doing this, though it's probably not any easier than connecting over serial.

Read More...

No. There are not enough hours in the day, unfortunately. I did respond to the pixel size issue on GitHub. I think it's technically a KStars/Ekos issue, not a driver issue, but the driver could probably be enhanced to supply the values for the K70 so as to avoid the issue in the future.

I had done some initial profiling a while back to see how much time FITs conversion was taking on the Pi4. I was surprised to find it taking less than a second, which is a big improvement over the Pi3 and probably attributable to having more memory available. Unfortunately, this means that clipping and/or downsampling before FITs conversion is unlikely to help much--the bottleneck right now appears to be the transfer from the camera to the Pi4. I'm going to look into it one more time just to double check, though.

Were there any other loose ends?

Read More...

Were you using a lens, or doing prime focus? For the K-70 at least, the SDK provided by Ricoh does not expose certain settings unless it detects a lens on the camera that supports those settings. I'm sure whoever decided on this limitation thought they were doing the user a favor by only exposing settings supported by the lens, but obviously they were not thinking about prime focus. Anyway, this means that PTP mode is severely handicapped if you're doing prime focus. Much to my frustration, I did not discover this until after I had already developed the PTP driver, as I probably would have started with MSC mode only had I been aware of the limitation.

The Ricoh SDK does not support bulb mode for PTP with the K-70 (or any camera, I suspect).

Read More...

Last I remember, StellarMate was using Ubuntu Mate. Is that still the case? Also, did you install from the package, or compile it yourself? This may be the issue where the toolchain on Ubuntu Mate doesn't compile libricohcamerasdk correctly. (One of the many frustrations that could be solved if Ricoh would just open up the SDK, or even just recompile it).

Read More...

@Noideaforanae - As far as the 64 bit question, is StellarMate actually running on a 64 bit OS? I'm using a 32 bit OS (Raspberry Pi OS / Raspbian) since I didn't see an improvement when I tried 64 bit Ubuntu Mate. Long story short, PTP mode should work on the Rpi4, if you're using a 32 bit OS.

However, if you are in fact using a 64bit OS, that would rule out PTP mode removal as being a possible solution to your car charger problem, since the 64bit version of the driver already builds without it.

(I have debated removing PTP mode support to make things less confusing. I decided against that path originally because I wanted to provide the maximum possible support. But as more people provide feedback, if the possible scenarios in which PTP mode could be useful keeps dwindling, perhaps that is a decision to revisit. I could, after all, make a separate driver that supported PTP mode available to those who wanted to compile it themselves).

Read More...

I hadn't thought of sum stacking the live view video for planets--just assumed it wouldn't work because it was too bright. That'd be an interesting use case.

I am surprised ISO is working in MSC mode for you guys. For me, it says it changes, but when I go to the images, they're reporting the original ISO. The camera will change to the ISO if I unplug it and plug it back in, but that's kind of pointless. There's an old ISO issue in pktriggercord that they could never resolve, and I just assumed it was manifesting itself here.

The Ekos autofocuser routine relies on getting FITs images from the driver. Because the driver takes a long time to convert the image to FITs, the autofocuser routine is unbearably slow on anything less than a RPi4 (which makes it annoying slow instead of unbearably slow). So live view is nice for at least getting close. As is the ability to take a lower resolution picture in PTP mode, since that speeds up the FITs conversion.

(Hmmm, I did just have an idea though--I wonder if I can could add an option for the driver to downsample or clip the original image before FITs conversion, to speed things up. I'll add that to my list of things to look into).

Read More...

Awesome. How long were your exposures? It makes me want to get out there and see what I can get. I've never had the patience to stack more than about fifteen minutes of light frames. Between coma and focus problems, it was just too frustrating. But I recently acquired a coma corrector and just bought a more powerful stepper motor yesterday, so hopefully I'll be up to the task soon (if I can figure out how to get the motor attached to the focuser).

Live view should be available for the K70 in PTP mode, but there's not much control over exposure/framerate, and I'm not sure whether Polaris would even be visible.

Aside from Bias frames, I'm not sure the updated driver would give you any different results--the main fixes were with the short exposure settings, so really only for planetary imaging.

Read More...