Julien date

[Ishakengineer]

Libpredict use Julien date as a reference, and when I google it I find out that the value of (JULIAN_TIME_DIFF =2444238.5) is incorrect because between January 1st in 4713 before Jesus (-4712) and 1979-12-31 00:00:00 UTC the difference has to be JULIAN_TIME_DIFF =(4712+1979)*365.25=2443887.75 I tested with your value and I compared the slant range with Gpredict and I didn't find the same result. Please Help me I stuck

[bjorgan]

I've looked this up, and it turns out to be a bit more fiddly.

• Day 0 is at January 1, 4713 BC (at noon), but in the Julian calendar. We are using the Gregorian calendar, where this would be November 24, 4714 BC (https://en.wikipedia.org/wiki/Julian_day).
• The period of Earth's revolution is not exactly 365.25 days, but slightly less. Leap days are added or removed every century to rectify for this, which makes the day count calculation complicated.

There exists formulas for calculating the julian day count that takes this into account, e.g. https://en.wikipedia.org/wiki/Julian_day#Converting_Gregorian_calendar_date_to_Julian_Day_Number or https://quasar.as.utexas.edu/BillInfo/JulianDatesG.html. I get 2444238.5 for December 31, 1979, 00:00 (Y = 1979, M = 12, D = 30, and +0.5 due to the time difference between midnight and noon).

As for the slant range, I am not able to reproduce the problem. I get the same slant range values using gpredict and libpredict when tracking the same TLE from the same ground station. Could you provide the TLE and code used to call the libpredict functions, and your gpredict ground station settings? Is it just the slant range that differs, or also the other properties?

[Ishakengineer]

Thanks for the time u gave to my question, I really appreciate it.

first I didn't get the meaning of using the date December 31, 1979, 00:00, why this date exactly?, because I know that Unix time starts on January 1st, 1970. In the function get_julian_start_day in the field of the year, you subtract 1900 from 1979, do I have to subtract 1900 from 2020 for example when I enter actual time and date?

On the other hand, I filled the "struct tm timeval" with date and time from (RTC in stm32) field by field I used the same TLE from the same ground station as Gpredict

[bjorgan]

The date is probably rather arbitrary. We inherited it from Predict when we forked the core code, but didn't see much reason to change it.

To obtain a predict_julian_date_t, you should convert it from a time_t using predict_to_julian() (https://github.com/la1k/libpredict/blob/master/include/predict/predict.h.in#L63). The safest bet is to use time(NULL) to obtain a time_t value for the current time.

If you need a fixed date/time, you can use mktime() and create it from a struct tm (the time supplied here should be in your current timezone, and not in UTC). To answer your specific question: Yes, the year put into the struct tm needs to be year-1900.

[Ishakengineer]

Thank you, I tested today and I noticed that when I track from the center of the earth (latitude =0, longitude =0 and alti=0) it works properly, but when I track form another place I have a problem, so I tried to find out the problem I notice that in (https://github.com/la1k/libpredict/blob/master/src/observer.c#L86) you put (geodetic.theta = 0.0) which is the geodetic effect (https://en.wikipedia.org/wiki/Geodetic_effect). I didn't understand, is it a constant? I've seen this (https://github.com/la1k/libpredict/blob/master/src/unsorted.c#L88) it calculates geodetic theta in given time and pos, I tried to calculate it but in vain

[bjorgan]

If it works at lat,lon,alt=0,0,0, it might be that you have some errors when you set your observer coordinates. The coordinates should be with the positive direction along the N/E direction, and are currently required to be in radians rather than degrees (https://github.com/la1k/libpredict/blob/master/include/predict/predict.h.in#L281). If you are doing this, and you still get different values, could you please paste your code?

geodetic.theta is here the Greenwich sidereal time. It is initialized to zero, and then modified by Calculate_User_PosVel. These functions seem to be translated from similar functions in Orbital Coordinate Systems, Part II if you want to read more about it.

[Ishakengineer]

Thank you, finally it works properly, So I will mention that the time must be in UTC ( Greenwich) even if we track from Oslo, Tunis or Moscow because the TLE epoch is in UTC, second as you said the observer parameter must be in radian. So thank you again and Happy tracking!