Examples of analysis that can be done with SatelliteToolbox.jl

Specific Domains Astro/Space
21

Yeap, so it seems thanks. Now up to find how to TEME 2 ECEF, but only later tonigh.

22

I guess I still need help on this. From my understanding of reading the docs one must compute a rotation matrix between the two reference frames and apply it. That’s what I try to do by adding these three steps

eop_IAU1980 = SatelliteToolbox.get_iers_eop()
rot = SatelliteToolbox.r_eci_to_ecef(SatelliteToolbox.TEME(), SatelliteToolbox.ITRF(), t[n], eop_IAU1980)
tt = reshape(r[n], 1,3) * rot

Now, what I see is that even at intervals of 60 seconds the rotation matrix changes a lot and the result or rotating the TEME vectors result in garbage. If I apply the same rotation to all points along the track, the result looks reasonable but still wrong.

23

Hi @joa-quim !

The rotation between TEME and ITRF changes mainly with Earth’s rotation. That’s why you are seeing the difference in 60s. Hence, you need to compute the rotation matrix using r_eci_to_ecef at every step updating the Julian day.

What I do not understand in you example is why you are reshaping the vector. The result of r_eci_to_ecef is a DCM. Thus, you only need:

tt = rot * r
24

@Ronis_BR, I realized that I had an error in calculating the t[n]s (they were not julian days) but I still do not get the correct result.

The reshaping is because Static arrays my be convenient for speed but they are a PITA when we need to send the data to C libs. GMT.jl doesn’t know what they are.

25

But it seems you are computing t’ * rot, which does not provide the same result. Why not Vector(rot * t)?

26

Yes, you are right, though I had to do tt = rot * r[n] because tt = rot * r errored with (I’m computing a single position)

ERROR: DimensionMismatch("Tried to multiply arrays of size (3, 3) and (1,)")

Now I get the same result as with the Matlab program. To help with the confusion, I cannot find the same locations as are being displayed in this site (even used theirs TLE) but that’s not what I care. I’ll check again with OceanColor’s data but that takes longer to find the precise instant.

1 Like
27

A bit better now :smile:

track
track1824×1633 170 KB

vs

image
image758×791 135 KB

1 Like
28

Out of curiosity: What is the issue here? I remember that we had a problem with StaticArrays in ERFA.jl when I turned all Ptr{Cdouble} parameters to Ref{Cdouble}. But with the former StaticArrays work without problems, see here: https://github.com/JuliaAstro/ERFA.jl/blob/main/test/runtests.jl#L38

1 Like
29

Well, probably the transmission StaticArrays to the GMT dll could be solve but before that the data often has to be stored in a GMTdataset and the functions that create and use instances of it know nothing about StaticArrays. So having to deal with a

typeof(r) = Vector{StaticArrays.SVector{3, Float64}}

in the middle of trying out to figure out how to make the main task work was something I really didn’t to worry about. Fighting with types is tiring and often frustrating.

2 Likes