Re: GRS longitude syst.II
The jupiter.1020 bdl file is now out of date so the values are being computed using Meeus copyright 1982. The GRS has migrated several degrees away from the model built at that time.
|
Greetings,
Using the "official" JUPOS value I was unable to get accurate transit times (compared with S&T predictions, etc.).
There seems to be an "offset", since using ~29¡ã (instead of the current ~16¡ã) everything seems right. Am I missing something obvious?
Thanks in advance!!
Rui Teixeira
version 4.1.0? - 2012, September 13
-----
Linux Mint 20.3 / Release: 20.3? (una)
|
Re: Some confusion concerning INDI device names
? Thanks for the information. The key turned out to be installation of the base INDI package so that I could run indi_getprop to see the names of the relevant configuration parameters. I need to do a bit of follow-up work on actual sky objects, but with the mount running in my office I can see that movements are reasonable and both the sky marker and "Telescope GoTo" functions are now working.
|
Re: Some confusion concerning INDI device names
Hello,
Please see section ?I will paraphrase here.
The INDI Control Panel doesn't "know" what it's doing. Since INDI is a self-describing protocol, XEphem?can show all properties and allow you to interact with them in a generic fashion. You as the user know what a "Set" button does, but XEphem just dutifully sends the property as strings without knowing what is happening.
But the Sky marker and GoTo control needs to be told exactly what properties to use for sending and receiving this information. This is done in the INDI Configuration panel. Here you enter the complete device.property.element tuple for each of the different situations, and enable the ones desired. In addition, you must enter scaling and offset values to convert to/from XEphem's internal coordinates (always radians) and the coordinates?expected by the telescope property (perhaps degrees, hours etc). You can determine the proper tuples by examining?the communications logged in the top section of the Control Panel but you must determine the scaling by knowing how your particular INDI telescope driver works.
Hope this helps. Thanks for using XEphem and INDI.
Elwood
? I have an Ubuntu-20 system running INDIGO server connected to a Losmandy GM8/Gemini mount. INDIGO provides legacy support for INDI devices, and XEphem connects to the emulated server at localhost:7624 without any issues. I've found that I can run both the INDIGO and XEphem control panels simultaneously, and any actions initiated in one place are reported correctly in the other. In the XEphem panel, if I enter celestial coordinates then click SET, the mount will slew to that region of the sky as intended. It's clear that data are moving correctly in both directions between the emulated server and XEphem.
? What I haven't determined are the proper configuration settings needed for the sky point and Telscope GoTo functions in XEphem Sky View. I've tried a few different device names in the XEphem INDI configuration dialog beyond the default Telescope and Mount choices, but the result is either a device not found error or nothing happens at all.
? Screen captures showing the information provided to XEphem from the server through the driver are provided below. From that, can the correct device name be determined? It appears that it may be "Mount LX200", so I'm wondering if the space in the device name may be confusing things.
? A question: Since the mount can be moved and the coordinates reported by the mount through the driver are reported correctly in the XEphem INDI panel, why do configuration parameters need to be set in the Sky View config dialog? Seems everything needed is already available.
? I can live with entering coordinates to point the telescope as needed -- I frequently need to do that presently when working with our PlaneWave mounts -- however it would be very convenient if it were possible to work through the Sky View window. Any suggestions or guidance would be most appreciated.
? The XEphem binary is revision 4.1.0, compiled from sources retrieved from the GitHub repository on 2021-12-29.
|
Some confusion concerning INDI device names
? I have an Ubuntu-20 system running INDIGO server connected to a Losmandy GM8/Gemini mount. INDIGO provides legacy support for INDI devices, and XEphem connects to the emulated server at localhost:7624 without any issues. I've found that I can run both the INDIGO and XEphem control panels simultaneously, and any actions initiated in one place are reported correctly in the other. In the XEphem panel, if I enter celestial coordinates then click SET, the mount will slew to that region of the sky as intended. It's clear that data are moving correctly in both directions between the emulated server and XEphem. ? What I haven't determined are the proper configuration settings needed for the sky point and Telscope GoTo functions in XEphem Sky View. I've tried a few different device names in the XEphem INDI configuration dialog beyond the default Telescope and Mount choices, but the result is either a device not found error or nothing happens at all. ? Screen captures showing the information provided to XEphem from the server through the driver are provided below. From that, can the correct device name be determined? It appears that it may be "Mount LX200", so I'm wondering if the space in the device name may be confusing things. ? A question: Since the mount can be moved and the coordinates reported by the mount through the driver are reported correctly in the XEphem INDI panel, why do configuration parameters need to be set in the Sky View config dialog? Seems everything needed is already available. ? I can live with entering coordinates to point the telescope as needed -- I frequently need to do that presently when working with our PlaneWave mounts -- however it would be very convenient if it were possible to work through the Sky View window. Any suggestions or guidance would be most appreciated. ? The XEphem binary is revision 4.1.0, compiled from sources retrieved from the GitHub repository on 2021-12-29.  
|
Re: Strange jumps of Pluto between 2246 and 2247B (fwd)
Hi,
Attached are 2 plots of the same trail, one with the old elements,
one with the new fixed ones (ie perihelion epoch, and n)
diff --git a/libastro/plans.c b/libastro/plans.c
index 9680c2a..805d88f 100644
--- a/libastro/plans.c
+++ b/libastro/plans.c
@@ -53,9 +53,10 @@ double *ret) /* ecliptic coordinates {l,b,r} at equinox of date */
inc0 = 17.097, /* inclination, deg */
Om0 = 110.297, /* long asc node, deg */
omeg0 = 115.058, /* arg of perihel, deg */
- mjp = 2459000.5 - MJD0, /* epoch of perihel */
+ mjp = 2447654.5 - MJD0, /* epoch of perihel */
mjeq = J2000, /* equinox of elements */
- n = 0.0039; /* daily motion, deg */
+ n = 0.003959; /* daily motion, deg */
double inc, Om, omeg; /* orbital elements at epoch of date */
double ma, ea, nu; /* mean, excentric and true anomaly */
[
The new ones give better continuity with Chapront's solution, which does not mean accuracy. If anyone needs better accuracy over centuries, a simple ellipse will probably not make it. So as continuity with Chapront is ensured, I think we can easily fix and keep the new elements.
--
fm
toggle quoted message
Show quoted text
On Thu, 27 Jan 2022, Brandon Rhodes wrote: On Tue, Jan 25, 2022 at 1:01 PM Serge Montagnac <obs.psr@...> wrote:
All the format aspect (columns, width, precision, spaces, NO tabs ...) must be
identical !
... or you'll get problems.
Happily, these elements sit in the raw C code, which is impervious to any whitespace
sensitivity. So they should not be haunted by any format problems.
I am reverting the recent?commit and restoring Pluto to its previous long-term orbit! I'll
see about a new release in the next few days to make it official.
--
Dr Fran?ois Meyer Tel : (+33) 3 81 66 69 27 Mob : (+33) 6 27 28 56 83
Dir. ex¨¦cutif plateforme OscIMP
Dir. LNE-LTFB, laboratoire temps-fr¨¦quence associ¨¦ au LNE
Institut UTINAM / OSU Theta
41b avenue de l'Observatoire, BP1615
25010 Besancon cedex - FRANCE
** Universite de Franche-Comte ** CNRS UMR 6213 ** URA 3245
|
Re: Strange jumps of Pluto between 2246 and 2247B (fwd)
On Tue, Jan 25, 2022 at 1:01 PM Serge Montagnac < obs.psr@...> wrote:
All the format aspect (columns, width, precision, spaces, NO tabs
...) must be identical !
... or you'll get problems.
Happily, these elements sit in the raw C code, which is impervious to any whitespace sensitivity. So they should not be haunted by any format problems.
I am reverting the recent?commit and restoring Pluto to its previous long-term orbit! I'll see about a new release in the next few days to make it official.
|
Re: Strange jumps of Pluto between 2246 and 2247B (fwd)
Ouuups ... I think you are on the good way !
Reference done from my early troubles of Chebichev coeff of planets
2020-2040 :
All the format aspect (columns, width, precision, spaces, NO tabs
...) must be identical !
... or you'll get problems.
Best regards,
Serge
On 25/01/2022 12:35, dulle wrote:
Hi,
If i am not mistaken there is a confusion in the new code between
elements reference epoch and perihelion epoch. Plus, daily motion
truncated to 2 significant digits is probably too
harsh.
2447654.529 for the perihelion brings it back in the ballpark,
and n=0.00395 seems to be closing quite well. Is n available
with more accuracy in the Almanach ?
--
Serge Montagnac + GPG Key 0xDF083D7B +
Nature, Not Human Activity, Rules the Climate.
|
Easy compile of XEphem on Mac using "brew"?
Good morning, XEphem folks!
It came to my attention that the free ¡°GitHub Actions¡± build service, which can be configured to run each time there¡¯s a new commit, now supports macOS. I¡¯ve just done a long series of experiments to see if it could compile XEphem.
The result: I was able to get it compiled!
But I don¡¯t know if the resulting binary would really run, because I¡¯ve not worked out whether GitHub Actions can somehow be induced to run a ¡°headless¡± X server.
First I edited the Makefile so that the Linux/Mac section looks like:
UNAME_S = $(shell uname -s)
ifeq ($(UNAME_S),Darwin)
PLATI = -I/usr/local/opt/openssl@3/include
PLATL = -L/usr/local/opt/openssl@3/lib
endif
CC = gcc
CLDFLAGS = -g
CFLAGS = $(LIBINC) $(CLDFLAGS) -O2 -Wall -I$(MOTIFI) $(PLATI)
LDFLAGS = $(LIBLNK) $(CLDFLAGS) -L$(MOTIFL) $(PLATL)
XLIBS = -lXm -lXt -lXext -lXmu -lX11
LIBS = $(XLIBS) $(LIBLIB) -lm -lssl
It then compiles with:
brew install openmotif
brew install openssl
brew install xquartz --cask
make -C GUI/xephem
(Note that make is NOT provided with a MOTIF= argument in this case.)
Some questions for the folks on this email thread:
Is anyone interested in trying this locally? I wonder if the resulting binary would run. If we discover this does produce a working executable, are these realistic instructions for the INSTALL file? Can we just show users the three brew install ... commands and have them happily compile? Or is brew not an option for most macOS users, and they will continue to be stuck with MOTIF=../../libXm/osx and the Xprint extension errors that it gives on modern macOS? (I tried installing brew on my old MacBook here at home but it said my MacBook is too old, so I have no way to verify locally what kind of binary the above instructions might produce on a real laptop.) It¡¯s just occurred to me that maybe I could ask GitHub Actions to give me back the compiled binary when it¡¯s finished? If we built one that¡¯s statically linked, maybe this could produce a binary for macOS folks with each XEphem release that they could use without having to compile it themselves. Do any of you know how to produce binaries that work across different macOS versions?
In any case, I¡¯m happy at least that these build steps seem to provide a way to automatically verify, on each commit, that XEphem still at least successfully compiles under macOS, without users having to find out for themselves later that something broke.
What I don¡¯t know, since I¡¯m not a macOS user, is whether these successful compile steps might be the basis for real users getting it compiled themselves.
Let me know! I'm open to ideas.
|
Re: Strange jumps of Pluto between 2246 and 2247B (fwd)
Hi,
If i am not mistaken there is a confusion in the new code between elements reference epoch and perihelion epoch. Plus, daily motion truncated to 2 significant digits is probably too
harsh.
2447654.529 for the perihelion brings it back in the ballpark,
and n=0.00395 seems to be closing quite well. Is n available
with more accuracy in the Almanach ?
--
fm
toggle quoted message
Show quoted text
On Mon, 24 Jan 2022, Brandon Rhodes wrote: On Mon, Jan 24, 2022 at 2:27 PM Brandon Rhodes via groups.io
<brandon@...> wrote:
On Mon, Jan 24, 2022 at 2:06 PM Elwood Downey <elwood.downey@...> wrote:
1. I confirm your report using XEphem 4.0.1 but I can also report
the?jumping does NOT happen with my legacy 3.7.6 so?SOMEBODY BROKE
SOMETHING.
Back in July, someone offered to update the Pluto orbital elements ¡ Here's the code
update they suggested:
I have just tested and can confirm that the above-linked commit is the one that introduced
the discontinuity. Apparently this new elliptical orbit for Pluto does not provide a smooth
join with the ¡°chap95_pluto¡± Pluto positions that "planpos()" uses over the time period
from?CHAP_BEGIN to?CHAP_END which, it appears, are the dates?1689/3/19 through?2247/10/1.
I'm open to ideas about the best way to resolve this. Should we revert the improvement and go
back to our old Pluto ellipse?
_._,_._,_
|
Re: Strange jumps of Pluto between 2246 and 2247
Dear friends,
Indeed, 2247/10/1 is the date the jump occurs for me. I am impressed that you found out so quickly!
Another basic question: is there an easy way to activate the Inertial frame by default in Earth view (so that it's selected even at the very first use of XEphem on a specific student's own session)? I find this much more pedagogical...
Yours,
Maxime
toggle quoted message
Show quoted text
Le 24/01/2022 ¨¤ 21:37, Elwood Downey a ¨¦crit?: Many thanks for your research, Brandon.
Since 2248 uses the new elements and this date produces wildly incorrect
positions, I would suggest reverting back to the older elements.
For reference, I ran a quick check on Horizons and for 9/27/2248 it reports
16:55 -11:55 so the old elements are still within a few degrees.
--
Maxime GOMMEAUX, ma?tre de conf¨¦rences
- Affiliation:
Universit¨¦ de Reims Champagne-Ardenne, UFR Sciences,
D¨¦partement des sciences de la Terre
Laboratoire GEGENAA, EA 3795
- Adresse de visite ou postale:
CREA, 2 esplanade Roland Garros, Bureau NE-401
F-51100 Reims (GPS: 49.2385¡ãN; 4.0628¡ãE)
R¨¦ception: 08:30-12:15 et 13:30-17:30 (sauf Ve: 13:30-17:00)
- T¨¦l: +33 3 26 77 36 83
-
|
Re: Strange jumps of Pluto between 2246 and 2247
Many thanks for your research, Brandon.
Since 2248 uses the new elements and this date produces wildly incorrect positions, I would suggest reverting back to the older elements.
For reference, I ran a quick check on Horizons and for?9/27/2248 it reports 16:55 -11:55 so the old elements are still within a few degrees.
On Mon, Jan 24, 2022 at 12:48 PM Brandon Rhodes < brandon@...> wrote: On Mon, Jan 24, 2022 at 2:27 PM Brandon Rhodes via <brandon= [email protected]> wrote: 1. I confirm your report using XEphem 4.0.1 but I can also report the?jumping does NOT happen with my legacy 3.7.6 so?SOMEBODY BROKE SOMETHING.
Back in July, someone offered to update the Pluto orbital elements ¡ Here's the code update they suggested:
I have just tested and can confirm that the above-linked commit is the one that introduced the discontinuity. Apparently this new elliptical orbit for Pluto does not provide a smooth join with the ¡°chap95_pluto¡± Pluto positions that "planpos()" uses over the time period from?CHAP_BEGIN to?CHAP_END which, it appears, are the dates?1689/3/19 through?2247/10/1.
I'm open to ideas about the best way to resolve this. Should we revert the improvement and go back to our old Pluto ellipse?
|
Re: Strange jumps of Pluto between 2246 and 2247
On Mon, Jan 24, 2022 at 2:27 PM Brandon Rhodes via <brandon= [email protected]> wrote: 1. I confirm your report using XEphem 4.0.1 but I can also report the?jumping does NOT happen with my legacy 3.7.6 so?SOMEBODY BROKE SOMETHING.
Back in July, someone offered to update the Pluto orbital elements ¡ Here's the code update they suggested:
I have just tested and can confirm that the above-linked commit is the one that introduced the discontinuity. Apparently this new elliptical orbit for Pluto does not provide a smooth join with the ¡°chap95_pluto¡± Pluto positions that "planpos()" uses over the time period from?CHAP_BEGIN to?CHAP_END which, it appears, are the dates?1689/3/19 through?2247/10/1.
I'm open to ideas about the best way to resolve this. Should we revert the improvement and go back to our old Pluto ellipse?
|
Re: Strange jumps of Pluto between 2246 and 2247
1. I confirm your report using XEphem 4.0.1 but I can also report the?jumping does NOT happen with my legacy 3.7.6 so?SOMEBODY BROKE SOMETHING.
Back in July, someone offered to update the Pluto orbital elements:
Here's the code update they suggested:
Could those parameters be at fault? They looked like fairly innocent adjustments when I read over the change. But maybe the real problem is elsewhere in the code, in a change I'm not even thinking of; I'll go do a quick search.?
|
Re: Strange jumps of Pluto between 2246 and 2247
Hello Maxime,
?
Two comments:
?
1. I confirm your report using XEphem 4.0.1 but I can also report the?jumping does NOT happen with my legacy 3.7.6 so?SOMEBODY BROKE SOMETHING.
?
5/16/2247 00:00 UTC? ? 4.1.0 RA 16:52:53.90? Dec -10:36:26.5
? ? ? ? ? ? ? ? ? ? ? ?3.6.7 RA 16:52:53.90? Dec -10:36:26.5
9/27/2248 00:00 UTC? ? 4.1.0 RA 11:52:36.30? Dec 16:13:59.6
? ? ? ? ? ? ? ? ? ? ? ?3.6.7 RA 16:46:16.01? Dec -11:05:43.7
?
2. Remember that Pluto's orbit?is only modeled as a simple ellipse, so its accuracy will degrade more quickly (albeit still smoothly) than the other planets.
?
|
Strange jumps of Pluto between 2246 and 2247
Dear friends of XEphem,
I am very happy that the improving pandemic situation has enabled me to resume my practical courses with XEphem in a real room with real Bachelor students...
I haven however, experienced an anomalous behavior of Pluto in the Solar system view. I simulate a revolution with a 500d step, starting today. The motion seems to be OK until the year 2246 but over the next time-step Pluto jumps backwards by approximately 1/4 of an orbit.
If I continue further, it seems to be OK between the years 2247 and 2498 (period ~251yrs) and again between 2498 and 2748 (period ~250yrs).
I enclose two consecutive screenshots (in 2246 and 2247). This is XEphem 4.1.0 on Ubuntu 20.04 (x64).
Do you have an idea of what could cause these jumps?
Yours,
Maxime
--
Maxime GOMMEAUX, ma?tre de conf¨¦rences
- Affiliation:
??Universit¨¦ de Reims Champagne-Ardenne, UFR Sciences,
??D¨¦partement des sciences de la Terre
??Laboratoire GEGENAA, EA 3795
- Adresse de visite ou postale:
??CREA, 2 esplanade Roland Garros
??F-51100 Reims (GPS: N 49.2385; E 4.0628)
- T¨¦l: +33 3 26 77 36 83
-
??
??
|
Re: Difficulty with OSX builds post Xephem-3.7.7
that worked for 10.5.8 and xephem 4.1.0 thanks elwood
|
Re: Difficulty with OSX builds post Xephem-3.7.7
You need -lXp, just as in my post:
> XLIBS = -lXm -lXt -lXext -lXmu -lX11 -lXp
Now I will say no more.
On Fri, Jan 7, 2022 at 4:40 PM Karl Oestreich < oestrek@...> wrote: CFLAGS = $(LIBINC) $(CLDFLAGS) -O2 -Wall -I$(MOTIFI) -I/opt/X11/include
< LDFLAGS = $(LIBLNK) $(CLDFLAGS) -L$(MOTIFL) -L/opt/X11/lib
< XLIBS = -lXm -lXt -lXext -lXmu -lX11
the above part has no value for my situation since nothing lives in /opt/X11 on my system
earlier OSes put it in /usr/X11
I put the EXACT stuff otherwise in the makefile and the EXACT same compile error is kicked as I posted a little earlier.
This problem seems to lie with the XM files in ../../libXm/osx? though they did work on the same system at least with xephem-4.0.1
The xephem-4.0.0 fails to compile by the way because of an error in versionmenu.c a missing { or } near an instance of the word Software
The normal way I fixed it was to blow a versionmenu.c from 4.0.1 over the 4.0.0 version of versionmenu.c? under OSX LION it will then compile under 10.5.8 it kicks the same error as does the compile from 4.1.0
-Karl
|
Re: Difficulty with OSX builds post Xephem-3.7.7
CFLAGS = $(LIBINC) $(CLDFLAGS) -O2 -Wall -I$(MOTIFI) -I/opt/X11/include
< LDFLAGS = $(LIBLNK) $(CLDFLAGS) -L$(MOTIFL) -L/opt/X11/lib
< XLIBS = -lXm -lXt -lXext -lXmu -lX11
the above part has no value for my situation since nothing lives in /opt/X11 on my system
earlier OSes put it in /usr/X11
I put the EXACT stuff otherwise in the makefile and the EXACT same compile error is kicked as I posted a little earlier.
This problem seems to lie with the XM files in ../../libXm/osx? though they did work on the same system at least with xephem-4.0.1
The xephem-4.0.0 fails to compile by the way because of an error in versionmenu.c a missing { or } near an instance of the word Software
The normal way I fixed it was to blow a versionmenu.c from 4.0.1 over the 4.0.0 version of versionmenu.c? under OSX LION it will then compile under 10.5.8 it kicks the same error as does the compile from 4.1.0
-Karl
|
Re: Difficulty with OSX builds post Xephem-3.7.7
Try using the changes I showed in my diff, you're still not doing it the way I did.
On Fri, Jan 7, 2022 at 2:50 PM Karl Oestreich < oestrek@...> wrote: compiles on xephem-4.1.0 have issues with XM when done with OSX 10.5.8
The compiler kicks the following errors
with a make MOTIFI = ../../libXm/osx
gcc -L../../libastro -L../../libip -L../../liblilxml -L../../libjpegd
-L../../libpng -L../../libz -g -L../../libXm/osx -L/usr/X11/lib -o
xephem aavso.o annotmenu.o broadcast.o calmenu.o closemenu.o compiler.o
coordsmenu.o datamenu.o db.o dbmenu.o earthmap.o earthmenu.o fallbacks.o
favmenu.o formats.o fsmenu.o gallerymenu.o glance.o gsc.o gscnet.o
helpmenu.o homeio.o hznmenu.o indimenu.o imregmenu.o jpeg2pm.o jupmenu.o
listmenu.o mainmenu.o marsmenu.o marsmmenu.o moonmenu.o moviemenu.o
msgmenu.o netmenu.o objmenu.o obslog.o patchlevel.o plot_aux.o
plotmenu.o preferences.o progress.o ps.o query.o rotated.o satmenu.o
saveres.o scope.o sites.o skybinary.o skyeyep.o skyfifos.o skyfiltmenu.o
skyfits.o skyhist.o skyip.o skylist.o skytoolbar.o skyviewmenu.o
solsysmenu.o splash.o srchmenu.o sunmenu.o time.o tips.o trailmenu.o
uranusmenu.o ucac.o usno.o versionmenu.o webdbmenu.o xe2.o xe3.o
xephem.o xmisc.o -lXm -lXt -lXext -lXmu -lX11 -lastro -lip -llilxml
-ljpegd -lpng -lz -lm -lssl
Undefined symbols: "_XpSetImageResolution",
referenced from: __XmPutScaledImage in libXm.a(ImageCache.o)
__XmPutScaledImage in libXm.a(ImageCache.o) "_XpGetPdmStartParams",
referenced from: _XmPrintPopupPDM in libXm.a(PrintS.o) "_XpEndPage",
referenced from: _PrintNotifyHandler in libXm.a(PrintS.o)
"_XpGetPageDimensions", referenced from: _ResourcesUpdate in
libXm.a(PrintS.o) "_XpSelectInput", referenced from: _SelectXpEvents in
libXm.a(PrintS.o) "_XpGetOneAttribute", referenced from:
__XmPutScaledImage in libXm.a(ImageCache.o) _ResourcesUpdate in
libXm.a(PrintS.o) "_XpQueryExtension", referenced from:
__XmPutScaledImage in libXm.a(ImageCache.o) _Initialize in
libXm.a(PrintS.o) "_XpGetDocumentData", referenced from: _XmPrintToFile
in libXm.a(PrintS.o) "_XpGetContext", referenced from:
__XmPutScaledImage in libXm.a(ImageCache.o) _SelectXpEvents in
libXm.a(PrintS.o) _Initialize in libXm.a(PrintS.o) _Destroy in
libXm.a(PrintS.o) _FilePipeCB in libXm.a(PrintS.o) _XmPrintToFile in
libXm.a(PrintS.o) _XmPrintPopupPDM in libXm.a(PrintS.o)
"_XpGetScreenOfContext", referenced from: _Initialize in
libXm.a(PrintS.o) "_XpEndJob", referenced from: _PrintNotifyHandler in
libXm.a(PrintS.o) "_XpStartPage", referenced from: _PrintNotifyHandler
in libXm.a(PrintS.o) ld: symbol(s) not found collect2: ld returned 1
exit status make: *** [xephem] Error 1
|
