When testing the Shoestring Astronomy FCUSB with an Orion Accufocuser motor (using an Odroid XU4, Ubuntu, nightly builds), it initially worked great. But when testing with my Celestron CGEM DX (indi_celestron_gps driver), I've had very few instances where it's worked. Normally, when indiserver starts, the red light on the FCUSB goes out... and the focus controls fail to function. If I start indiserver on the Odroid without the Celestron GPS driver, no problems (even without unplugging the mount). Any pointers on configuration settings, etc that may help these two drivers co-exist? Thanks!
FWIW, I have had good luck with a Hardkernel Odroid XU4 running Ubuntu.
I have put it in an enclosure suitable for outdoors that has sufficient space for cable management. I use E-MMC for root (fast) and capture frames onto an SD card (64GB). Works fine off battery power (hours and hours...all night). With the XU4, I have experienced some issues using Zwo ASI120MC-S (which appears to reset the USB3 bus constantly...), but resolved by re-arranging the other usb devices (some are more tolerant of this behavior than others, it would appear). I'm currently using an external (usb powered) WIFI adapter (IOGear GWU627) that plugs into ethernet on the XU3 (I suspect this has better throughput than using USB).
I just completed a set of planetary imaging sessions (Mars, Neptune, Uranus) with KStars / Indi, but I used
to control an SVBony SV305. To be honest, I really liked AstroDMx Capture because I found many tools helpful with the (somewhat specialized) needs of very high magnification planetary imaging (lucky imaging) -- for both super bright targets (Mars) and relatively dim targets (Neptune). It would not be a bad tool to study in this regard.
Using a combination of KStars / Indi (with a carefully aligned guide camera) along with AstroDMx was helpful... because I could quickly slew (and plate solve) with the guide camera... and then launch AstroDMx Capture ... and (critically) use the mount controls in Indi to make fine adjustments to center the planet.
1) The ability to define a region of interest and then slide the ROI around across the full frame (at high magnification, planet can drift)
2) The ability to easily adjust exposure time / frame rate -- and move easily between a few categories (tens of seconds, seconds and ms). I found myself at times using very long exposures (tens of seconds) to get the "glow" of the planet... which helped me find the planet when off by just a bit at very high magnification. Once the planet is in view, I'd quickly move to a typical video frame rate.
3) Ability to adjust gain quickly / easily.
4) The ability to easily import resulting SER files into the usual cast of post-processing software (pipp, autostakkert, registax). Please test this. The files from the current video recording capability in Indi today (I found) were a bit hit or miss (some worked, some had issues... no clear reason why).
5) The ability to put a reticle on the field of view (centered)
6) The ability to configure viewing (brightness / contrast) separate from capture (because viewing the planet for capture may need different settings than desirable for capture...depends on screen brightness, etc.).
7) Information display wrt current frame rate (frames per second)
Maybe a button to launch the Xplanet solar system viewer with the current field of view? I'm weird, but I discovered this tool _after_ my planetary imaging session... and it is really very cool in aiding with understanding where the moons are at the moment... how the planet should appear at that moment, etc.
By the way... getting my guide camera lined up just so with the main planetary camera (with a 3X Barlow on an LX200 ... effectively 6000mm focal length at F30) is a pain. Life might be easier if Kstars / Indi could develop a mount model that could take into account the relative differences in pointing between a guide camera (guide telescope) and the main camera / telescope (assuming it were possible to do plate solving with both... would likely do an initial plate solve with the main camera at prime focus 'cause that's not happening at 6000mm at F30 w/ the Barlow installed). In that scenario... when plate solving with the guide telescope, Indi would know the difference in pointing between it and the main telescope and correct for that when slewing the mount into position. How cool would that be?!??
My alternative hardware solution that I'm considering is simply a flip mirror... with the guide camera at prime (for plate solving, slewing) and the main camera behind the Barlow after the mirror).
To start to autoguide (internal or phd2, etc) the iOptron CubePro w/ the venerable 8401 hand controller (with latest V090701 firmware), it appears that one must go outside (brrr) to the mount and use the hand controller put it into auto guide mode. Once through with picture taking and ready to slew somewhere else, in this mode, one must go outside (brr) to get out of auto guide mode. Painful. If the INDI control panel included a button (autoguide on / off) and sent :RG# (to start guiding) or :RC# (to stop guiding) [based on the appendix G, page 40 in the
iOptron 8401 manual
] then I could do this switch back and forth in software.
Even better would be the ability to send these codes automatically when guiding is set to start / end when this hand controller / indi driver is in use.
Is this already implemented and I missed the feature? Did I misinterpret the iOptron manual and these codes are not really doing what I think they're doing (the description is terse).
Thanks for any pointers!
At high magnification (and with DSLR's with many pixels), plate solving with the primary scope can be slow and painful at times. My guide camera is far faster and more reliable at plate solving. Maybe this is already implemented, and I missed it... but sometimes it's a pain to get the guide scope perfectly aligned with the primary scope...and I'd like to know if Indi/Ekos could help me be just a bit lazier than I already am! :> If Indi / Ekos has done plate solving and understands the relative position of each scope (guide and primary), would it be possible to use the guide scope to do plate solving and positioning of the mount... while correcting for the relative difference in pointing between it and the primary scope? In other words, could the mount model take into account the difference in the pointing of the guide scope vs the primary scope? Maybe some basic calibration step would be needed so that each scope had done a couple plate solves in order to build this model...
Dumb idea? Already there and I didn't catch it in the manual? Thanks!
Just purchased a USB dongle from Etsy with the Navisys GR-701W that includes a ppi signal. It works well w/ my odroid on ubuntu and my laptop w/ fedora 28. GPSD and NTP set up...working well. Creates a usb-serial (ttyUSB*) device.
HOWEVER -- I noted that cgps utility looks good (valid output...takes 5-10 seconds for a fix)... but within kstars / ekos / indi... I do not get the right longitude. I get 360- <my longitude...of -77 degrees). Instead of -77, I get 283. Any ideas how to fix this?