30 replies to this topic

[ButterFly]

Introducing CodeTalker - a star chart generator that talks to an ephemeris service, like JPL Horizons, and star catalogs, like GAIA DR3.

 

I created this software so I can get data right from JPL Horizons and plot it against GAIA DR3 stars.  Faint moons are hard to get right with software alone, and fasteroids (an asteroid that moves more than a few arcseconds per minute) move very fast against the sky.  I wanted something that could do both, creating a star chart that goes as deep as I need it to, with the position of the target based on my Latitude, Longitude, and Elevation.  For fasteroids in particular, I also really needed an "Update" button, so I can follow the thing between the time I get oriented in the field, and when I spot it, and every so often thereafter.

 

I can also export plots for later use, but I much prefer to use it at the scope.  Here is an example for 2005 EK70, moving at about 11"/min at present:

 

 

This object will get below 13th magnitude in a few days, so it will be fun to follow over the next few days.

 

For my particular telescope, eyepiece, and mount type (a dob), I have the program generate the proper field of view, and set the proper flips and rotation angle to match my eyepiece view.  It has helped a lot at the scope, and I offer for your use and modification, subject to GNU GPL v3.0.

 

There is a manual along with it, with an initial walk through to help get your bearings.

 

Here is a link to the installer and the manual for the latest version: https://drive.google...x1UJFBsITQFFXFE

 

As the program updates, so will the installer, and if necessary, so will the manual.

[ButterFly]

Latest Source: https://drive.google...GeorLoGsc6gSDvi

 

The Source will be updated to the link above as it changes.

[ButterFly]

Should any errors occur, please send me the text of the error messages via PM so I can fix any bugs.  Let me know what you were doing when it happened, and whether you can recreate the error.  That will help out a lot!

 

I'll post an update if one is available, to the link in the first post.  Digging down several posts for the latest version is not fun.  Adding that a new version is available should bump the thread upward, while leaving the latest version in the first post.

[CHnuschti]

Great contribution for "end-users", thank you for your efforts. The manual is very detailed.

 

regards

[ButterFly]

Bug fix:  Latitude, Longitude, Elevation change not registered

 

Version 24.2.19 available at link in first post.

[ButterFly]

Bug Fix: Fixed exception after error message when trying to get asteroid orbital elements from IMCCE

 

Version 24.2.25 available at link in first post.

 

Thanks for the reports.

[jrkorman]

Looks quite interesting! May I suggest posting this to the "Software and Computers" forum!

[ButterFly]

Looks quite interesting! May I suggest posting this to the "Software and Computers" forum!

It's a better fit in solar system.  It has SIMBAD and DSS support, but that's really tangential to the Ephemeris service support.  I did find the GAIA depth very helpful for M31's globs closer to the core.  SkySafari just wasn't cutting it.

[ButterFly]

Bug Fix: Fixed Simbad plus signs in identifier not working, ie SBSG 1116+518

 

Version 24.3.12 available at link in first post.

 

Thanks for the reports.

[ButterFly]

v24.4.20
Added Repeating SIMBAD ID when it fails to retrieve single object
Added 15 days default paths for SkyCharts
Added Site Selection
Added Range to ephemeris
Fixed Exception handling for failed Syncs
Fixed blank DSS Label while Fetching Image
Fixed ESA server error message
Fixed Longitude error message
Fixed ephemeris intervals

 

Version 24.4.20 available at link in first post.

[ButterFly]

v24.5.4
Added Presets of one day, week, and month to ephemeris generator
Fixed cryptic exception message when ephemeris end time earlier than start time

 

Version 24.5.4 available at link in first post.

[CHnuschti]

Made use of your software finally. A great tool, thank you again.

 

I do express the wish if it would be possible to label the stars? E.g. the 3 brightest in the view. This would be a big help, as then there is not much to sort out "who is who".

 

2024 MK is coming soon, an event ALSO suited for smaller gear.
Below my comparison between Codetalker and Skysafari, when it passes HR 8149. Skysafari (MESZ=UTC+2) is some 15mins too early. Location is Zurich 47.3N 8.5E.

Maybe you deign to give some insights from your perspective for 2024 MK? Thanks.

 

http://astro.vanbuit....nl/neo/2024 MK

 

regards

 

 

Edited by CHnuschti, 27 June 2024 - 03:58 PM.

[ButterFly]

 

I do express the wish if it would be possible to label the stars? E.g. the 3 brightest in the view. This would be a big help, as then there is not much to sort out "who is who".

 

I am seriously trying to avoid that generically!

 

The reason is that I designed this to work on my phone's data plan out in the wild.  If I get ID's for each star, that could be three thousand strings for each time I call it for a particular field for my dob, and GAIA ID strings to boot!

 

The next big issue is that GAIA strings are just a long string of non-sense.  Cross-referencing them to other useful catalogs like Bayer, may not be possible in most fields, but tycho should be possible in most real fields.

 

Would a right click context menu item such as "Get ID and cross references" be something useful for you?  Then, if I happen to have one already for some star, I could display it along with the magnitude information when one clicks on a star.  That seems like a server friendly, data plan friendly, and usefulness friendly compromise.  Would you need to be able to copy the ID text after that?

 

Displaying a long GAIA string (let alone three) on the chart is just going to get in the way, and it's not really useful unless you can copy it to do something with it.  Getting the rotation to match my field of view has really been all I have needed, but I have goto scopes.  It's working out surprisingly well in all my scopes with just geometric relationships, matching the rotation of the eyepiece view.

[ButterFly]

 

2024 MK is coming soon, an event ALSO suited for smaller gear.
Below my comparison between Codetalker and Skysafari, when it passes HR 8149. Skysafari (MESZ=UTC+2) is some 15mins too early. Location is Zurich 47.3N 8.5E.

Maybe you deign to give some insights from your perspective for 2024 MK? Thanks.

 

SkySafari should match what CodeTalker return when using MPC, assuming SkySafari's elements are fresh.  MPC is NOT GOOD for things this close, ironically enough.  MPC's ephemeris service does NOT return positions based on MPC's own NEO list, for some strange, regrettable, and entirely unknown reason.

 

MPC's ephemeris service always returns the following warning:

 

 

The current system is not completely reliable in the case of objects with very-close approaches with the Earth.

 

For very close approach objects, use either JPL or IMCCE as the ephemeris service in CodeTalker, because those two calculate based on MPC's NEO list elements.

 

MPC has been promising to update its ephemeris service, for quite a while now.  If and when it does, I will make any necessary adjustments to CodeTalker to avail whatever it spits out.

 

Lowell's ephemeris service is another option for those who have a nearby observatory code, or an observatory code of their own.  Lowell's API does not permit one to use an observer's latitude and longitude, so I excluded it from CodeTalker.  Should Lowell add the ability to use a latitude and longitude, rather than just an observatory code, I will without a doubt include it as an option in CodeTalker.  Lowell would allow comparison with astorb as well, which would be fun to see.

[CHnuschti]

Hi Butterfly.

 

Thank you for re-iterating the main aspects of those near objects, and the "issues" with the ephemerids, depending from where they come.

 

As for the labeling in the Codetalker charts. I do agree the credit-card-like numbers of GAIA probably are not that helpful, rather add efforts to identify the long numbers. Tycho sounds much better, my thought was a selection of the labels bond to a magnitude threshold, analog like the selection of the magnitude limit displayed. In order to not plaster the display full with labels, would be counterproductive.

 

E.g. take symbols and labels up to the selected "label magnitude", and add symbols alone for the stars above that "label magnitude".

A right click context "get ID" would be even better. If meant to be applicable to ONE selected star?

 

But I'm no coder.

 

The need for a copyable label I personally do not see at present. For me it's more a question of comparability with another chart like Skysafari, in order to "assign" the Codetalker chart mentally to the other. Like in this case, where the timings in Skysafari might notably differ from those given with Codetalker, in order to easily locate the position to get the general overview.

 

Would surely be helpful, thank you.

 

No cougars here to ruin this MK 2024 pass, but clouds announced, rain & lightning included!

 

regards

Edited by CHnuschti, 28 June 2024 - 06:27 PM.

[ButterFly]

As for the labeling in the Codetalker charts. I do agree the credit-card-like numbers of GAIA probably are not that helpful, rather add efforts to identify the long numbers. Tycho sounds much better, my thought was a selection of the labels bond to a magnitude threshold, analog like the selection of the magnitude limit displayed. In order to not plaster the display full with labels, would be counterproductive.

 

E.g. take symbols and labels up to the selected "label magnitude", and add symbols alone for the stars above that "label magnitude".

A right click context "get ID" would be even better. If meant to be applicable to ONE selected star?

 

But I'm no coder.

 

The need for a copyable label I personally do not see at present. For me it's more a question of comparability with another chart like Skysafari, in order to "assign" the Codetalker chart mentally to the other. Like in this case, where the timings in Skysafari might notably differ from those given with Codetalker, in order to easily locate the position to get the general overview.

 

 

Going the "Get ID" route is probably what I'll do first.  GAIA has cross references to Tycho stars: 1) if Tycho goes down that far; and, 2) if they're sure it's the same star.  If it has a Tycho id, I'll present that first, and then the credit card number(s)!  I'll just have to make sure that each TAP server has the tycho cross reference available in their data tables.  Of course, if one is getting the stars from Tycho or Hipparcos, rather than GAIA, the top level ID and cross references change accordingly.

 

If I add a slider, that means I have to either get all the IDs and cross references already, or get them on the fly.  Each is awful.  Getting them all at once is a lot of data that I won't be using, most of the time.  Getting them on the fly, as needed, adds a delay.  Plus, a slider takes up a lot of room.  I'll see how an "Add three labels" button does, as well as a remove all labels button.  That way, the control isn't taking up much room, and I don't need to send a whole bunch of queries to get IDs and cross references at once.  If the delay of on the fly isn't too awful (it really depends on the TAP server one chooses, and the present load on that server), I can put all of those settings in a "Labels" button.
 

[ButterFly]

For ArgoNavis users, I did notice a bug when uploading comet elements from MPC.  Avoid sending ArgoNavis comet elements from MPC until I get to fixing that in the next release.  JPL comet elements still upload fine to ArgoNavis.

[CHnuschti]

If I add a slider, that means I have to either get all the IDs and cross references already, or get them on the fly.  Each is awful.  Getting them all at once is a lot of data that I won't be using, most of the time.  Getting them on the fly, as needed, adds a delay.  Plus, a slider takes up a lot of room.  I'll see how an "Add three labels" button does, as well as a remove all labels button.  That way, the control isn't taking up much room, and I don't need to send a whole bunch of queries to get IDs and cross references at once.  If the delay of on the fly isn't too awful (it really depends on the TAP server one chooses, and the present load on that server), I can put all of those settings in a "Labels" button.
 

I see the point, that is, there is no much point to retrieve lot of ("delaying") data that isn't used at all in the end. With 3 labeled stars, among the brightest hopefully, everything would be defined, orientation included. Helping straight away to identify the sector in another chart with ease. Minimalistic and effective.

 

regards

 

[Fabricius]

Just a quick dumb noob question here.

I could not find system requirements.

Is it possible to run Codetalker on a Windows computer? If yes, then how?

[ButterFly]

Just a quick dumb noob question here.

I could not find system requirements.

Is it possible to run Codetalker on a Windows computer? If yes, then how?

Yes; the release is only windows for now.  Android is on its way eventually, but hopefully soon.

[ButterFly]

I see the point, that is, there is no much point to retrieve lot of ("delaying") data that isn't used at all in the end. With 3 labeled stars, among the brightest hopefully, everything would be defined, orientation included. Helping straight away to identify the sector in another chart with ease. Minimalistic and effective.

 

regards

 

There are coordinates to go by as well.  Just use the coordinates of the target, paying attention to the displayed epoch.  It shows selected objects' (including stars') coordinates as well.

 

SkySafari lets one center by simply typing in the coordinates.  Before I wrote CodeTalker, I would just center to the actual coordinates the fast things would be near, then pick stars near the center, then add them to an observing list.  I would at least get the correct path that way, by displaying the objects in the observing list.  The path can be very wrong in SS at times when the elements change quickly.

[ButterFly]

v24.8.18
Added button to overlay Star Charts for blinking
Added local storage for passes
Added UCAC5, GSC 2.4.2, GSC 2.3.2, USNOB1
Added DMS site entry
Added GetID to stars in chart
Added North/East indicator on chart
Added Press Enter to Retrieve RADec
Added Position Calculator
Added once per day default path steps for SkyCharts
Fixed can't select stars very near target or close to poles
Fixed distance label for sub-arcsecond separations
Fixed retrieving other moons
Fixed JPL Asteroid Element Magnitude retrieval
Fixed Write Comet to ArgoNavis from MPC when there is no fractional day part to epoch
Fixed display RA to one more decimal place of seconds of time than Dec in seconds of arc
Fixed Naming star chart window for Simbad
Restructured Server Classes and Constructors
Made 64-bit only

[CHnuschti]

Great work, thank you for the update and the efforts.

 

(The new) Retrieving the star ID (=Tycho) works well here. Also explored the "moons" feature, pretty cool with its markers and also the labeling/identification when clicking on it. E.g. for Himalia? notorious for way off positions in several programs Skysafari included?

 

The minor issues report:
Switching from UTC to local time or viceversa, then "get time now" triggers an "exception".
The view of the plot is set to azimutal per default. Sometimes however it does not get into that orientation for unknown reasons, when plotting a new chart. Maybe a kind of "reset" is missing. Noticed this in the "moons" subsection.

 

regards

Edited by CHnuschti, 18 August 2024 - 09:32 PM.

[ButterFly]

Also explored the "moons" feature, pretty cool with its markers and also the labeling/identification when clicking on it. E.g. for Himalia? notorious for way off positions in several programs Skysafari included?

 

Moons were there since the beginning.  The big moons generally do fine with other software, but tiny moons, far away moons, and very close in moons need a good ephemeris from JPL.  Unfortunately, MPC doesn't allow inputting latitude and longitude for moons, but only accepts observatory codes (for whatever stupid reason), so I don't bother to ask it.  Not everyone lives near an observatory code.

 

 

 

The view of the plot is set to azimutal per default. Sometimes however it does not get into that orientation for unknown reasons, when plotting a new chart. Maybe a kind of "reset" is missing. Noticed this in the "moons" subsection.

Nothing new here at all - I just moved the logic from a one-off at plot startup to inside the charting logic so it can adjust rotation with updates.  Check your settings for your scope to make sure they match up to the view you get through the eyepiece or on the sensor.  Remember that the parallactic angle is always either zero or 180 at meridian, to help you sort out the other constant rotations you setup provides.

 

Set the AZ to 0 or 180 on the new positions tab, and adjust the rotation settings, to see how they work.  In real life, set your AZ to 0 of 180 by pointing along the meridian.  There will always be three segments: North or South horizon to North or South pole; pole to zenith; and, zenith to South or North pole.

 

 

Switching from UTC to local time or viceversa, then "get time now" triggers an "exception".

I can't recreate that.  Send me the details (including a screenshot of the exception message, and the copied text) in a PM.

[ButterFly]

v24.8.19
Fixed keeping RA in range of 0-24 hours after interpolation