Feature request: Choose Meridian when satellite tracking

[Ruediger3]

Hi Michel, I would kindly ask for the feature to chose the Meridian when tracking satellites analog the handpad. The reason is, that very often only one hemisphere of the transit is visible for me and it makes only sense to track after Flip. If I start from West, I only lose time for flipping. please see example attached (red transit, actual Horizon of my home in the image). As you can see it makes no sense to track on the red curve the west part of the transit.

Thanks for evaluating! Rüdiger

[Ruediger3]

The next test will be: PC and Mount using both GPS time. The very next test will be both using PC time. But now clouds are rolling in :(

[Ruediger3]

Hi Michel, Just tested with FPS both. failed again on both meridian sides. Mount was behind the ISS approx 1,5s. Rüdiger

[Ruediger3]

Hi Michel, just tried with PC time and the ISS was in FOV (but very close to the edge).

Cheers Rüdiger

[proceau]

I'm problem too

[mworion]

Hi Rüdiger, many thanks for the intensive testing. To sum up in my words (to be clear where to move on), please confirm:

• There is no big difference in tracking and getting Sat in FOV between mount calculation and MW4 calculation (if you could describe the difference better, please try it.
• The deviation of spotting a sat in FOV is related to the used time base. GPS is off, PC time is in.

Just as remark: the model corrects also for time deviations. If the mount model is done with PC time and there was a GAP between PC and GPS time, Sat tracking with GPS time will not get the sat in FOV.

If all above is true and correct, the question is, why there is a difference between GPS and PC time. My thoughts: PC time system via NTP is UTC based. Mount time system is also UTC based. Actually GPS - UTC difference is 18seconds (which is correct configured)

Strange... Michel

[Ruediger3]

Hi Michel,

thanks for your patience. It is very hard to say something is like, since the transits and weather only allows to repeat one or two tests for each setup combination. So I hesitate to say "it is". Simply there are too little count of tests. I will try to repeat the identical test multiple times to be sure it is like this. Unfortunately that is in the nature of tracking ISS.

1. Yes. I had issues with both
2. Yes. The offset with PC time was less. But this could be by chance.

I have created a new 90 point model last night. I will retest with new model.

Yes, there is a difference between PC time and high precision mode of Windows. Now it is the question which one is the less wrong. Actually, GPS should be correct, since it is a stratum one layer time reference. May there is a delay in processing the updates timely from MGPBox to mount or something other wired. But it looks like that both times run slow.

The GPS offset cannot be changed anyway. I think it is not editable. I remember there was an issue with the10; Mount configurator which showed 19s offset. Maybe there is also a bug.

That said, I am not sure where the root cause lies. I will do following:

1. Setup everything to work with internal tracking
2. When 1 successful repeat the tests systematically.

I have to ask for some patience since I can only test max. once a day due to the obstruction of my FOV.

Thank you! Rüdiger

[proceau]

I'm test, the standard NTP of windows have 500ms of error, i'm change to other NTP stratum 2 and it's more correct.

[Ruediger3]

Yea thats true and thats why I do not use them. I use the NTPPool.org

[mworion]

Rüdiger, question: if the offset stays constant is it worth to try to adjust the time offset for tracking to catch the satellite?. Is this possible? Interesting question would be if that offset stays constant between different satellites and observing nights as I could persist this value then. Michel

[Ruediger3]

Well, using a offset means to know it in advance. If this would be possible, I could adjust the clock too and have the same result. The problem is, an offset needs an reference point and here I am not sure. This definitely needs more and systematic testing, since the results are not consistent.

[mworion]

Rüdiger, I updated the GUI behavior to make it more clear what happens (changing text and color) in v2.0.0b28 Michel

[Ruediger3]

Hi Michel,

I was testing yesterday and I missed ISS again. It was not in FOV. I will test again as soon as possible.

Cheers Rüdiger

[mworion]

I anyway working on some features for finding near satellites which are visible and sun lit. If that's running we should be able to find more and easier opportunities to select satellites for testing. I currently not know, why and for what reason I miss the FOV in MW4 math, when the satellite is in the FOV for 10micron calcs.

[squark-envoyer]

18s it's not second correction of GPS ? because some time 1s it's add or remove per year on UTC, the GPS have not correct ?

https://fr.wikipedia.org/wiki/Seconde_intercalaire

[mworion]

Actually (since 01-01-2017) the difference GPS - UTC is 18s. And as the gap is more closing, there might be for some years more no need increasing it further. But in result 18s delta is correct.

[squark-envoyer]

the TLE parameter it's on GPS time ou UTC time ? the 10micro correct internal time with 18s or not ? because the pointing error it's coherent with that, and explain problem pointing ?

[mworion]

TLE should be as spec in UTC and the mount internally does all things in UTC. This fits nicely. If you are using a GPS for time sync you have to take care about the 18s. It would be great to know if the deviation is only about time and nothing more and if so how much in each case.

Maybe we have some other topics when using GPS as time source (and Rüdiger, this might also explain your observation that GPS time and NNTP time was different):

Many general purpose GPS devices utilise NMEA protocol, which is a standard protocol for GPS devices. However, the problem with using these devices for as a GPS Clock for computer timing is that the NMEA sentances are often not synchronised to be generated at specific intervals.

Many GPS devices therefore can only provide an accuracy of plus or minus 1 second, which is generally just not accurate enough for network timing purposes.

I will ask Martin, how his MGBox receiver is designed for that.

[squark-envoyer]

Would anyone have any idea how to simulate and time the simulation to get a feel for the fault? When the mount is in simulation mode we know the chosen start time, it would be possible in simulation mode to set the starting time of the latter? My idea is to simulate the same TLE with a laser on the mount, started at a given time and see when the laser passes a reference point of the trajectory and see if in PC UTS, the 18s offset is applied or not in addition.

[Ruediger3]

It looked like that MW was slow for a second but track ok. I followed life in Stellarium and the mount was "behind" ISS. I guess around 1 second. What I also had noticed was a time difference of approx. 600ms between mount and PC.

[mworion]

Rüdiger, if you say 1s behind, you reference a time system which you did from NTP service correct? So would the gap 600ms to mount add another 600ms, so in total 1.6s behind "Mount" or would this reduce the difference to 400ms ?

[mworion]

@squark-envoyer, Starting the simulation in that precision is hard to do as execution times might differ. I made the calculation comparison between mount and MW4 if you use the same time base that you run inside a 10 arcsec window for Alt and AZ as the normal satellites have a "speed" of about 0.03 deg / s which is about 100 arc sec per second. So the sat should be in the FOV just by calculation.

[Ruediger3]

The 1s was a guess from watching screen. The 584ms were displayed by the 10M clock sync tool, which was set not to sync. I also noticed, MW says time not GPS synced to mount, but the hand pad does. So there are many potential root causes, which makes it really tricky to tackle the root cause.

[mworion]

Rüdiger Good point about handpad and MW4. I asked already 10micron because I see with :gtg# command that I loose sync sometimes. I have to check Handpad as well. Could you tell where to see if the time is synced on the handpad?

[Ruediger3]

Based on the symbol shown.

[Ruediger3]

Here a screenshot from life system:

[mworion]

Rüdiger, many thanks. I think there is a different between "usage" and synced (at least the is some room for interpretation).

[Ruediger3]

Welcome. You are right. This is ambiguous. Rüdiger

[mworion]

I close this point as there is no chance to sync mount time with high precision to GPS time. I publish a 2.1.0 beta this evening with another extended Satellite feature set (search and tracking correction). You should be able to adjust track as a matter of time, ra or dec directly. So the time delta +- 1s along the track is now available in MW4. Michel