Mutual Contact Window AOS/LOS
Real time satellite tracking and orbit prediction
Status: Beta
Brought to you by:
csete
Menu
▾
▴
#10 Mutual Contact Window AOS/LOS
Hello, on this feature request, I am used to a DOS based program called Quik Trak 4, from many years ago, on a Tandy 1000SL. One function that it had, that I haven't seen anywhere else, and I would like to see the option inserted into Gpredict.
It is a Mutual Contact Window AOS/LOS calculation, for when the satellite's footprint is within footprints of two ground stations and then can be used as a relay station, for when the two ground station footprints are not within range of each other. Similar to my case, Wichita, KS to Chicago, IL and, of course, the second station location must be user entered or selected and a single satellite had to be selected also.
Basically, when the satellite is "seeable" by both ground stations, simultaneously, then that "Mutual AOS" is calculated and when the satellite drops from view of both ground stations, then that "Mutual LOS", is calculated, as it can no longer serve as a relay station, along with each minute in between, for that event. A tabular output was the result, with antenna Az/El position and Doppler tuning shift, on a minute by minute basis. I am used to a tabular output, but if a plottable map output can be done, I'd welcome that, also.
This was a huge benefit when planning contacts, as much as, a week in advance, back in the early 90's and bouncing a packet signal over the MIR or DO-17. This would greatly set Gpredict out from other programs available to me. I currently run it on Ubuntu Linux 8.04 (Hardy Heron), on an IBM R31 Thinkpad.
Hi,
I have indeed been thinking about adding this functionality. The current design supports adding this functionality very well. It may not be ready for the next beta release (due in a few weeks) by I'll try to include it in the final 1.0 release.
As a starter, could gpredict display on the world map the other ground stations declared in the preferences? Maybe this could be optional, a check box for each ground station would tell whether to display these non default ground stations. With the satellite footprint drawn, one could see how it goes.
White_Knight_32_KS:-) I have also noticed another small thing. The text field for retrieving sat track data for for updates is not long enough to get everything I was after, at celestrak.com. Could we have another line or two, to expand this? Thank you much for considering the mutual contact window function! Sincerely, KA0YCU.
KA0YCU:
Are you sure it's not long enough? The text field can contain much longer strings than what it can display. The rest will just be hidden on the display but it will still be there. Nonetheless, I'll take a look to check it.
White_Knight_32_KS/KA0YCU, I'm currently able to only retrieve about half of the sat track data that I was originally after. I'm only aware of celestrak.com, for that info. In my older day, I was used to stripping out the text of the 2 line format, at the start, so the other DOS based programs would accept it. Not having to fuss with that is very nice! If you know of another web site where more sat's are found, please advise me, as I'm currently unaware. I used to get some of it at the old NOAA BBS dial up, many years ago and sometimes off the packet BBS's, when I could link up to them. KA0YCU
There is another service called Space Track http://www.space-track.org but as far as I know Celestrak has all the satellites in orbit.
I plan to do some changes to the wat satellite data is managed in the next version of Gpredict. When done, Gpredict will include all the satellites available via Celestrak.
White_Knight_32_KS/KA0YCU- Thank you much and that does sound sweet! And thanks much for putting up with me! Gpredict has been the nicest program that I've seen since the DOS days, that runs on ubuntu well. Initially I ran it on 6.06 LTS, on 600 series IBM Thinkpad (P2-300 MHz) and now currently on R-31 Thinkpad (P3-1.13 GHz), under 8.04 LTS, both on Gnome interface. I'm still hunting for rotor hardware that has linux support, for an Az/El antenna array set up, to use in conjunction with it.
For rotor support you can check out Hamlib support:
https://sourceforge.net/apps/mediawiki/hamlib/index.php?title=Supported_Rotators
As of version 1.0 beta, Gpredict can control rotors via hamlib's network interface.
White_Knight_32_KS/KA0YCU- Thanks for the link on supported rotor hardware! I was already up on hamlib, pulled up Synaptic to double check, but I already put that package in. Thanks again, for the tip!
Is there anyone who still cares about this out there?
As of svn checkin 808, there is now a svn branch for mutual contact called mlos (mutual line of sight). It is very rough at this point but it is submitted for comment. If one hacks a module appropriately and creates corresponding qth files, useful information appears in the MLOS at a glance window and other ground stations show up on the map. The paradigm is that one has a qth as before and is interested in working "groundstations" in different parts of the world.
Of particular interest here is the paradigm for grounds stations correct with the two level heirarchy?
If someone wants a sample mod and qth's, I can supply them privately. I do not want to be supporting them.
Added to the gtk-sat-module was a way to read in new ground stations.
How is the software structured, there are two new calls in predict-tools.c. get_mlos and get_mloses. These are similar to their get_pass equivalents except that they take another qth argument. They make successive calls to get_pass until they find overlapping passes within the time window.
The mapview then plots these other stations as unlabeled colored points the same color as the qth.
The MLOS at a glance window then resembles sky at a glance, except that passes should be shorter and the tooltip identifies the other groundstation as well as the satellite. (if you click an mlos, then good luck. Not tested yet.)
There are several things that need to be done. This list is incomplete.
Validate that this does not crash (too easily?)
Understand how this fits in with the events we already have.
Do we do something spiffy on the polar plots to show we have contact with a desired station? a different color trace perhaps.
Same with ground tracks.
gui issues (color on map, selecting the multiple qth's.)
other dynamic qth's and updating. (the other qth could be gpsd enabled.)
There is some language I would like to change in the code. mlos (which was the first stab) should probably be renamed something along the lines of mutual contact. Also groundstations should probably be replaced with other qth's or other language that reflects the heirarchy of stations.
Feedback appreciated.
Mutual Contact Screenshot SVN v813
Sbumitted for consideration a screenshot of the mutual contact window for the Amateur module using my QTH near Lowell, MA and attempting mutual contact with New York, NY and Frenchville, ME.
All political subdivision are in the USA.
Hi Charles,
Is it really necessary with new functions in predict-tools? Can't we use get_passes() for qtha and qthb, then find the intersection between them?
Also, I'm not sure that the sky-at-glance is a proper template for this, since it may require looking ahead much farther than 12-24 hours.
Alex,
It looks as though 1.4 will be a significant set of updates.
There are arguments for and against the new functions based on simplicity, computational efficiency and paralellism between mutual events and single event. We can create them in your proposed fashion provided the code is not using maxdt=0, then get_passes cannot run forever to get_passes for qtha before running for qthb. If we never expect maxdt=0 then get_passes can be run as you described. When implemented as you propose, there is still the question of whether there should be a short hand to facilitate computing them. Personally, I like the idea of having a shorthand. With that position, the conversation simplifies to whether we should write the wrapper around get_pass or get_passes. If that is the conversation, then for getting only a single mutual event, writing it around get_pass should be faster in that fewer passes are computed. Some of this interpretation is reading between the lines because get_passes has a num argument that limits the number of passes to generate. Wrapping around get_pass would mean that all the work is done to get all the passes and all that num would do is limit the memory foot print. The existing get_mlos and get_mloses code is a wrapper around get_pass. From a parallelism point of view, we have a get_pass and get_passes with certain arguements. Having a function for getting mutual passes seems reasonable. If we mimic arguments then having maxdt=0 minimizes later confusion.
I envision find_maos and find_mlos functions for adding such events to the event viewer.
Do you want to put them inside a mutual-tools.c instead?
There is value in the sky at a glance view. However it does not address all of the original feature request. The sky at a glance template was selected as the first implementation as it was the easiest place to visualize for debugging. It allowed head to head comparision. No mutual aos should not occur unless there was a corresponding pass in sky at a glance. Looking out weeks ahead, then yes, sky at a glance is probably not the correct tool. (The future pass window is probably more appropriate.) However even short term there is useful information. There are passes where NY is unavailable and Frenchville is through SO-50 and AO-51. I also know that NYC will not be competing with me if I try that pass. (If they were NYC would show up as a mutual opportunity.) The future pass window from the map view popup is probably something closer to what we would want weeks out. For the short term opportunistic operator, the sky-at-a-glance interface is useful. For the long term op who is trying to fill out some grid square or chase a distance record, sky-at-a-glance is the wrong tool.
As you raise, the gui is far from complete. There is a need for a long term look ahead. There is need for a mutual contact details dialog.
Part of the point of the original post was that with this "mutual" information there are now many other places in the gui where it can be used beyond the scope of the original request.
73
Charles
Alex,
There is a cleaner reason for a new function.
Computational, passes can leapfrog each other saving computing the details of intermediate passes.
Now for how this works. If passA is behind passB, then unless the sat is up at A at the start of B, then we do not need to look between because there cannot be mutual communication in between. When they flip play the same game again. This reduces fast forwarding through time twice and keeps us from computing the details of some passes.
If only I had recognized this sooner, it would be checked in.
Thanks for making me think about this.
Charles
I think whenever a user will want to use this MLOS feature, he/she will also be interested in knowing when the sat has AOS/LOS in general (not just for MLOS). Therefore, I think that having the full pass info instead of just MLOS info might be useful. I can even think of ways to extend the sky-at-glance to show not only the MLOS but also the full passes for both ground stations, without causing any pain for the eyes.
Having said that, please just go ahead and do whatever you planned to do and we'll see how it works.
Sorry it took me so long to get back to you folks! Now running Ubuntu 10.04 on Mac G4 PPC CPU!
It's been ages since I've run that DOS program, but if I remember right there was a listing of formulas in the text manual that came with it. If I dig around here hard enough, I might find the hard copy that I had bound up, back then for reference. I just moved also, so it might take me a few weeks, but it it saves you folks some headaches, I'd be glad to hunt for it. It's been well over 25years since I've taken calculus, so I'd rather have the formulas in front of me than re-derive them! :))
Reason I say this, I thought I saw it while I was unpacking my old packet radio gear that I used back then. KA0YCU
Just to update you, I've been running gpredict on two old PPC based Mac G4 Powerbooks, one on Ubuntu 10.04 and the other on Ubuntu 12.04, bot
Both of the older IBM units, the 600 series, on Ubuntu 6.06 and the R31, on Ubuntu 8.04, have since been unuseable due to bad screen hinges and only useful with external monitors. This is why I changed hardware, they held up to the beating, for a service unit to repair pc's in the field. Please advise if gpredict can be ported out to arm based CPU's running linux, so far finding a continually updated linux os for this architecture has been a challenge, for my oddball tablet. My newst hardware is cortex A8 based Android 4.0, until I get off my butt and root it!
Sincerely,
Bob Nelson, KA0YCU
white_knight_32_ks@yahoo.com
On Mon, Feb 4, 2013 2:52 PM CST Alexandru Csete wrote:
Related
Feature Requests: #10