Ken Self replied to the topic 'Plate solving giving wrong results' in the forum. 5 days ago

SOLVED!! (excuse the pun)
Altering the ANSVR config to return J2000 coordinates fixed the issue. I must have set it to JNOW once when messing around with SGP on Windows.

Read More...

Ken Self replied to the topic 'Plate solving giving wrong results' in the forum. 5 days ago

Looks like JNOW is an ANSVR config option which is why I couldn't find it in the astrometry.net API documentation. I'll see how to switch it off an hopefully then the solves will work.

Read More...

Ken Self replied to the topic 'Plate solving giving wrong results' in the forum. 5 days ago

TallFurryMan wrote: Looking at the log, it seems to me we're dealing with an API change here:

[2018-09-12T21:59:09...][     org.kde.kstars.ekos.align] - "{\"jobs\":[62],\"processing_finished\":\"1\",\"processing_started\":\"1\",\"user\":\"0\",\"user_images\":[]}"
[2018-09-12T21:59:09...][     org.kde.kstars.ekos.align] - "{\"status\":\"success\"}"
[2018-09-12T21:59:09...][     org.kde.kstars.ekos.align] - "{\"dec\":\"-14.816192073\",\"epoch\":\"JNow\",\"orientation\":97.5146272814133,\"parity\":1,\"pixscale\":1.96562592485983,\"ra\":\"296.199887826\",\"radius\":0}"

RA/DEC seem to be returned in JNow here.
-Eric

As far as I understand it, astrometry.net returns only J2000 coordinates. I've not found any option to return JNOW coordinates.
I tested again today on another target and Ekos consistently puts the target some 15' off centre in RA. I then switched to Astrotortilla using the same engine and it correctly centred the object.

What I suspect now is that the J2000 to JNOW conversion is being applied twice. Astrometry.net returns RA of 19h43m44s as J2000 which converts to JNOW of 19h44m48s which is the value in the log (296.199887826 degrees). A further J2000 to JNOW conversion is then applied to 19h44m48s which results in 19h45m50s as shown in the next part of the log. 1m of RA corresponds to 15 arcminutes which is the error I am seeing.

Read More...

Ken Self replied to the topic 'Re:Plate solving giving wrong results' in the forum. 5 days ago

TallFurryMan wrote: That may sound stupid and I do not suggest it could be the case in your test, but I need to mention that I had very weird results when I forgot to suspend guiding while plate-solving. Guiding corrections actually offset the mount model. PHD2 has an option to disable guiding while the mount slews, the internal guider does not.

-Eric

I was using PHD2 but guiding was off. I re-ran the platesolve under controlled conditions.

Read More...

Ken Self replied to the topic 'Plate solving giving wrong results' in the forum. 6 days ago

astrometry.net is doing the right thing. It returns coordinates in J2000 which Ekos converts to JNOW. Its the conversion to JNOW that appears to be wrong so the corrective slew to target is taking the target further away from the centre of the field instead of closer to it.

Read More...

Ken Self created a new topic ' Plate solving giving wrong results' in the forum. 6 days ago

I'm running Kstars 2.9.8 on Window 10 64 bit. Platesolving through Ansvr.
My target was NGC6822 (Barnards Galaxy) at (from KStars):
JNow: 19h 45m 58s -14° 45' 45"
J2000: 19h 44m 56s -14° 48' 23"
I get a successful solve and the mount slews. The next solve says it is within acceptable range.
But if I then take an image and solve at nova.astrometry.net it is around 15 arc-minutes off in RA.
Results from nova.astrometry.net (J2000) are:
Center (RA, Dec): (295.932, -14.862)
Center (RA, hms): 19h 43m 43.610s
Center (Dec, dms): -14° 51' 44.593"
Size: 38.1 x 28.8 arcmin
Radius: 0.398 deg
Pixel scale: 1.96 arcsec/pixel
Orientation: Up is 262 degrees E of N
I suspect the conversion of J2000 returned by nova.astrometry.net to JNOW is in the wrong direction. Perhaps as I'm in the southern hemisphere?
Had the same issue with 2.9.6 the other day which is why I upgraded.

Attaching Kstars log and image solved on nova.astrometry.net

Read More...

Jasem Mutlaq thanked Ken Self in topic Post your INDI Setup! 7 days ago
Eric thanked Ken Self in topic Post your INDI Setup! 7 days ago
Ken Self replied to the topic 'Post your INDI Setup!' in the forum. 1 week ago

Finally an INDI setup I'm happy with. This is the RC8 on the Avalon M-Uno mount with ASI1600MM-C imaging camera, ZWO 8-pos EFW, Optec TCFSi focuser and ASI120MM-S guide camera through TS-Optics OAG.
The main computer is the Aaeon-Up Core running Ubuntu 16.04 and can be seen on the second picture with its external Wifi antenna. Its USB3 port has a 10 port powered USB3 hub which everything connects to except the mount. In addition I can plug into the hub an Ethernet adapter and Displaylink adapter for troubleshooting if the Wifi has problems. Otherwise it runs wirelessly. I run PHD2 on this one using the native ZWO driver and a remote INDI Avalon driver.
The mount is driven from a Raspberry Pi3. The INDI server on the Aaeon connects wirelessly to the Pi3. It was initially located physically under the OTA but it has issues with Wifi there - possibly due to an earth loop. Located on the side of the mount it has no problems. It can also be connected to ethernet for troubleshooting but I cant get Displaylink to work on it. And in case of real problems I can always connect the mount to the Aaeon Up via the hub. But that adds one extra cable crossing from RA to Dec axis. I could have connected wirelessly to the Avalon but so far I've found excessive latency going that route. If I had my time over I would have ordered the Avalon with the Bluetooth option rather than Wifi.
In my preferred setup the only cable is one 12V cable coming through the polarscope hole to the RA axis where it powers the mount and the Pi3. It then continues onto the dec axis to power the Aaeon-Up, USB hub, ASI1600 and Optec. The Aaeon-Up and Pi3 have UBEC voltage down converters to supply their 5V. As you can see it is still a work in progress with some tape holding the cable in place and a few unsecured cables
My next plan is to fit a slip ring into the polarscope hole so the power cable can rotate without twisting.
I also have a desktop computer in the observatory running Windows 10, Kstars and Ekos. All images are save locally to the Aaeon and I download them either through ethernet or with a USB stick. I'm currently experimenting with registering and stacking on the Aaeon-Up with Siril but its not working out just yet. So for now I'm sticking with DeepSkyStacker.




Read More...

Ken Self replied to the topic 'Ascom Focuser with Ekos' in the forum. 2 weeks ago

ASCOM only works on Windows as it uses the Registry. Maybe the driver would work under Windi www.cloudmakers.eu/windi/

Read More...

Ken Self replied to the topic 'Taking time off' in the forum. 2 weeks ago

So sorry to hear about your loss Jasem. They really are part of the family.

Read More...

Ken Self replied to the topic 'ToupTek GCMOS Driver' in the forum. 2 weeks ago

With guidance I could give you remote access to mine - just not sure how to do that. Alternatively I could build the driver and try it out. I've got my camera running on Ubuntu with the native driver so I know it works on that platform.

Read More...

Ken Self replied to the topic 'libindidriver.so issue on RPi3' in the forum. 1 month ago

I removed indi-full and reinstalled.
When I do a locate I get:

ken@ken-pi3:~/indi/build/indi-avalon$ locate libindidriver.so
/usr/lib/arm-linux-gnueabihf/libindidriver.so
/usr/lib/arm-linux-gnueabihf/libindidriver.so.1
/usr/lib/arm-linux-gnueabihf/libindidriver.so.1.7.4
I assume those are part of the install?
Then I deleted the buil/indi-avalon folder and reran cmake
The when I run sudo make install I get
ken@ken-pi3:~/indi/build/indi-avalon$ sudo make install
[sudo] password for ken: 
Scanning dependencies of target indi_lx200stargo
[ 20%] Building CXX object CMakeFiles/indi_lx200stargo.dir/home/ken/indi/libindi/drivers/telescope/lx200telescope.cpp.o
[ 40%] Building CXX object CMakeFiles/indi_lx200stargo.dir/home/ken/indi/libindi/drivers/telescope/lx200driver.cpp.o
[ 60%] Building CXX object CMakeFiles/indi_lx200stargo.dir/lx200stargofocuser.cpp.o
[ 80%] Building CXX object CMakeFiles/indi_lx200stargo.dir/lx200stargo.cpp.o
[100%] Linking CXX executable indi_lx200stargo
CMakeFiles/indi_lx200stargo.dir/home/ken/indi/libindi/drivers/telescope/lx200telescope.cpp.o:(.data.rel.ro+0x3c): undefined reference to `INDI::Telescope::ISSnoopDevice(_xml_ele*)'
CMakeFiles/indi_lx200stargo.dir/lx200stargo.cpp.o:(.data.rel.ro+0x3c): undefined reference to `INDI::Telescope::ISSnoopDevice(_xml_ele*)'
collect2: error: ld returned 1 exit status
CMakeFiles/indi_lx200stargo.dir/build.make:175: recipe for target 'indi_lx200stargo' failed
make[2]: *** [indi_lx200stargo] Error 1
CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/indi_lx200stargo.dir/all' failed
make[1]: *** [CMakeFiles/indi_lx200stargo.dir/all] Error 2
Makefile:127: recipe for target 'all' failed
make: *** [all] Error 2
ken@ken-pi3:~/indi/build/indi-avalon$
I'm pretty sure I've got a version class with the libraries but I con't work out where. Whats the best way to go back to a clean sheet?

Read More...

Ken Self created a new topic ' libnova issue on RPi3' in the forum. 1 month ago

I'm working on the Avalon driver and it works fine on x64 and x86 but I'm having a problem on ARM. The driver fails in a call to get_local_sidereal_time which is defined in indicom.c. It is in library libindidriver.so and I can see it there with nm -D (assuming I'm looking in the right place)
libnova 0.14.0-2.1 is installed andif I call the libnova procedures directly from the driver everything works.
I figured I must have run cmake before I installed libnova so I deleted build/libindi and reran cmake. In the output it says it found libnova. Then I rebuilt libindi
But when I rebuild the driver it still fails in the call to get_local_sidereal_time.
Any ideas what I'm doing wrong?

Read More...

Ken Self replied to the topic 'Avalon mzero Stargo with lx200 protocol' in the forum. 1 month ago

Pull request sent. Its now very stable although it still has a couple of small things to fix around that timing problem. I thought I read in the code that the ttyread timeout was in seconds but I'm not seeing that. Elsewhere I've seen the timeout for ttyread being in tenths of a second which corresponds to what I'm observing. Currently the StarGo driver is using a timeout of 5 - if that's 0.5s then I might need to up it to 10 (1s) as I'm seeing the occasional read timeout which sometimes triggers the same issue I've been sorting out.

Read More...

Ken Self replied to the topic 'Avalon mzero Stargo with lx200 protocol' in the forum. 1 month ago

Made a great deal of progress but it took quite a bit of refactoring. As far as I could tell the issues were related to the commands/responses that went through the LX200driver code. Each time I migrated a function from there to the Stargo driver that command stopped being a problem. Its possibly a problem n the object code and maybe resolvable by rebuilding everything together but the code needed a bit of a cleanup anyway.
Attached are a before and after log. Due to some other problem the lat/lon coords fortuitously do not point to my home.
I haven't yet tested all the functions.

Read More...

Ken Self replied to the topic 'Avalon mzero Stargo with lx200 protocol' in the forum. 1 month ago

I had to enable logging from LX200driver as well so now I'm seeing what is happening. All is going ok until :X362# command which receives an additional :Z1nnn response (unless there is an unlogged command sent) and that throws out the rest of the stream. When I was snooping on the USB stream a while back I did see that some of the X36n commands get two responses. I'll see if I can flush the second response

Read More...

Login



3rd Party

Choose from the numerous 3rd party INDI drivers to suit your needs!

Got Problem?

Check out the FAQ, the forum, and the bug tracking system to resolve any issues you might have!
You can also subscribe to INDI newsletter and development mailing lists to get the latest updates on INDI!