| |
CX2SA > SATDIG 26.03.13 20:02l 844 Lines 33310 Bytes #999 (0) @ WW
BID : AMSATBB894
Read: GUEST
Subj: AMSAT-BB-digest V8 94
Path: IZ3LSV<IK2XDE<ON4HU<CX2SA
Sent: 130326/1802Z @:CX2SA.SAL.URY.SA #:4667 [Salto] FBB7.00e $:AMSATBB894
From: CX2SA@CX2SA.SAL.URY.SA
To : SATDIG@WW
Today's Topics:
1. Re: satellite los footprints (Paul Williamson)
2. Re: satellite los footprints (Ken Ernandes)
3. Re: Hawaii-FO-29 (Dave W?DHB)
4. FT-857D Satellite File Request (Les Rayburn)
5. Re: satellite los footprints (Brenton Salmi)
6. gpredict and ft-817 cat control (Richard Ferryman)
7. Re: satellite los footprints (Greg D)
8. predict client example in python (Phil)
9. Re: gpredict and ft-817 cat control (Erich Eichmann)
10. Re: satellite los footprints (Joe Fitzgerald)
11. Re: gpredict and ft-817 cat control (Greg Dolkas)
12. Dragon Returns (B J)
13. Re: satellite los footprints (Joseph Armbruster)
14. Re: satellite los footprints (Joseph Armbruster)
----------------------------------------------------------------------
Message: 1
Date: Mon, 25 Mar 2013 14:23:30 -0700
From: Paul Williamson <kb5mu@xxxxx.xxx>
To: Joseph Armbruster <josepharmbruster@xxxxx.xxx>
Cc: "amsat-bb@xxxxx.xxx BB" <amsat-bb@xxxxx.xxx>
Subject: [amsat-bb] Re: satellite los footprints
Message-ID: <B4FC40BD-73B9-42D2-B8BA-D1F9C9FDAED6@xxxxx.xxx>
Content-Type: text/plain; charset=us-ascii
On Mar 25, 2013, at 8:15 AM, Joseph Armbruster <josepharmbruster@xxxxx.xxx>
wrote:
> I can not decide how to implement ground footprints with my google earth
satellite tracker.
InstantTrack uses a spherical Earth model for ground footprints.
> option 3 : use a digital elevation model and an ellipsoidal model to
cull-out regions that are not visible due to geographic features and project
an irregularly shaped polygon downwards towards the footprint
>
I believe that local terrain is dominant over any large-scale terrain effect
you'd be able to see on a footprint map. It would be worth modeling for
AOS/LOS or mutual visibility purposes.
73 -Paul
kb5mu@xxxxx.xxx
------------------------------
Message: 2
Date: Mon, 25 Mar 2013 18:42:44 -0400
From: Ken Ernandes <n2wwd@xxxxxxxxxx.xxx>
To: Joseph Armbruster <josepharmbruster@xxxxx.xxx>
Cc: "amsat-bb@xxxxx.xxx BB" <amsat-bb@xxxxx.xxx>
Subject: [amsat-bb] Re: satellite los footprints
Message-ID: <243E7CA6-DE8E-4594-8BE4-4FFC2FC171E8@xxxxxxxxxx.xxx>
Content-Type: text/plain; charset=us-ascii
My humble suggestion:
1. Implement option 1 for the satellite footprint.
2. If you decide to give the users the ability to input their location,
them the option to provide either a single minimum elevation angle or a
local map -- i.e., 360 individual minimum elevations as a function of
Azimuth. It's much easier to project this and the user is generally
interested in an unobstructed LOS with respect to his/her location.
73, Ken N2WWD
Sent from my iPad
On Mar 25, 2013, at 11:15 AM, Joseph Armbruster <josepharmbruster@xxxxx.xxx>
wrote:
>
> I can not decide how to implement ground footprints with my google earth
satellite tracker. I figured, since I can't make up my mind, I should get a
second (and third, and fourth) opinion. For this thread, I would like to
discuss how satellite ground-footprints should be implemented. A quick
brainstorm led me to three possible implementations (I am leaning towards
3). For each of these, I assume that a geographic line-of-sight footprint
is desired with no RF characteristics taken into consideration:
>
> option 1 : assume a spherical earth model and project a polygon downwards
towards the footprint
>
> - note: this is obviously the easiest approach but will result in the most
error
>
> option 2 : assume an ellipsoidal earth model and project an irregularly
shaped polygon downwards towards the footprint
>
> - note: this is arguably more difficult than option 1 and would result in
less error
>
> option 3 : use a digital elevation model and an ellipsoidal model to
cull-out regions that are not visible due to geographic features and project
an irregularly shaped polygon downwards towards the footprint
>
> - note: In this case, our footprint polygon would have holes cut out for
the regions that are culled out by mountain ranges, canyons / etc...
Obviously, this would be the most difficult to implement but would likely be
the best visual representation. The problem is, I would never dream of
distributing DEMs for the entire Earth with my tool, even DTED0 would be
absurd in my opinion. I could make the elevation queries accessible using a
web-service, but then the user would be tied to the internet. The other
option would be to allow the users to download their elevation data into a
cache, then the tool would just load / use it. This way the user would only
have to obtain the elevation data for their region of interest. Maybe that
would be the best approach? I am open to suggestions!
>
> If you have any experience visualizing footprints, please let me know. I
would be interested in hearing your lessons-learned. These are what the
line-of-sight indicators look like right now: Google Earth Satellite
Tracker - Line of Sight Update
>
> I am open to comments and suggestions,
> Joseph Armbruster
> _______________________________________________
> Sent via AMSAT-BB@xxxxx.xxx. Opinions expressed are those of the author.
> Not an AMSAT-NA member? Join now to support the amateur satellite program!
> Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
------------------------------
Message: 3
Date: Mon, 25 Mar 2013 17:45:07 -0600
From: Dave W?DHB <dave@xxxxx.xxx>
To: "'John Fickes'" <kc0bmf@xxxxx.xxx>, <amsat-bb@xxxxx.xxx>
Subject: [amsat-bb] Re: Hawaii-FO-29
Message-ID: <001f01ce29b2$c7fb5d60$57f21820$@xxx>
Content-Type: text/plain; charset="iso-8859-1"
John
Don't think you can get Robert NH7WN he needs 13 deg. Elevation to get this
way.
You could email Tom K4XV on Kauai, he is getting is station together and
also has access to the Kauai College Station.
His email is good on qrz.com.
Dave W0DHB
-----Original Message-----
From: amsat-bb-bounces@xxxxx.xxx [mailto:amsat-bb-bounces@xxxxx.xxxx On
Behalf Of John Fickes
Sent: Monday, March 25, 2013 11:42 AM
To: amsat-bb@xxxxx.xxx
Subject: [amsat-bb] Hawaii-FO-29
Any Hawaii hams around for FO-29 pass today (3-25) 19:30utc to Iowa EN31
Thanks John KC0BMF
_______________________________________________
Sent via AMSAT-BB@xxxxx.xxx. Opinions expressed are those of the author.
Not an AMSAT-NA member? Join now to support the amateur satellite program!
Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
------------------------------
Message: 4
Date: Mon, 25 Mar 2013 10:55:35 -0500
From: Les Rayburn <les@xxxxxxxxxxxx.xxx>
To: FT-857@xxxxxxxxxxx.xxx
Subject: [amsat-bb] FT-857D Satellite File Request
Message-ID: <51507377.7000601@xxxxxxxxxxxx.xxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I'd like to try some very limited satellite operation from my mobile,
using an FT-857D. I know this rig is not ideal for satellite ops,
because it lacks full duplex
capability. But it is all mode, and should allow me to operate several
different satellites using portable antennas from the truck.
I use RT Systems software to manage the memories on my rig, and wondered
if anyone might have already done the programming for satellite operation
for this rig--including most of the major birds for CW/SSB and FM. If
so, could you possibly e-mail your file to me off-list? It would save me
a ton of time
figuring it all out, and get me started much faster. I'll be forever in
your debt.
--
73,
Les Rayburn, N1LF
121 Mayfair Park
Maylene, AL 35114
EM63nf
6M VUCC #1712
Grid Bandits #222
Central States VHF Society Life Member
Active on 6 Meters thru 1296, 10GHz & Light
------------------------------
Message: 5
Date: Mon, 25 Mar 2013 13:58:10 -0400
From: Brenton Salmi <kb1lqd@xxxxx.xxx>
To: Joseph Armbruster <josepharmbruster@xxxxx.xxx>
Cc: "amsat-bb@xxxxx.xxx BB" <amsat-bb@xxxxx.xxx>
Subject: [amsat-bb] Re: satellite los footprints
Message-ID:
<CA+7Uq1hEXNvPOwkmUZ+i697rBsSjEo0SFwr8Q6inQpoifzyKaQ@xxxx.xxxxx.xxx>
Content-Type: text/plain; charset=ISO-8859-1
There is so much variability in the footprint that #1 or #2 would probably
suffice. Working satellites on the fringes of AOS and LOS wheigh heavily on
your location, surroundings, and equipments that it's impractical, it's
just a visual "references" that shows relative satellite reception.
Hope this helps.
- Brent, KB1QD
On Mon, Mar 25, 2013 at 11:15 AM, Joseph Armbruster <
josepharmbruster@xxxxx.xxx> wrote:
>
> I can not decide how to implement ground footprints with my google earth
> satellite tracker. I figured, since I can't make up my mind, I should get
> a second (and third, and fourth) opinion. For this thread, I would like to
> discuss how satellite ground-footprints should be implemented. A quick
> brainstorm led me to three possible implementations (I am leaning towards
> 3). For each of these, I assume that a geographic line-of-sight footprint
> is desired with no RF characteristics taken into consideration:
>
> option 1 : assume a spherical earth model and project a polygon downwards
> towards the footprint
>
> - note: this is obviously the easiest approach but will result in the most
> error
>
> option 2 : assume an ellipsoidal earth model and project an irregularly
> shaped polygon downwards towards the footprint
>
> - note: this is arguably more difficult than option 1 and would result in
> less error
>
> option 3 : use a digital elevation model and an ellipsoidal model to
> cull-out regions that are not visible due to geographic features and
> project an irregularly shaped polygon downwards towards the footprint
>
> - note: In this case, our footprint polygon would have holes cut out for
> the regions that are culled out by mountain ranges, canyons / etc...
> Obviously, this would be the most difficult to implement but would likely
> be the best visual representation. The problem is, I would never dream of
> distributing DEMs for the entire Earth with my tool, even DTED0 would be
> absurd in my opinion. I could make the elevation queries accessible using
> a web-service, but then the user would be tied to the internet. The other
> option would be to allow the users to download their elevation data into a
> cache, then the tool would just load / use it. This way the user would
> only have to obtain the elevation data for their region of interest. Maybe
> that would be the best approach? I am open to suggestions!
>
> If you have any experience visualizing footprints, please let me know. I
> would be interested in hearing your lessons-learned. These are what the
> line-of-sight indicators look like right now: Google Earth Satellite
> Tracker - Line of Sight Update
>
> I am open to comments and suggestions,
> Joseph Armbruster
> _______________________________________________
> Sent via AMSAT-BB@xxxxx.xxx. Opinions expressed are those of the author.
> Not an AMSAT-NA member? Join now to support the amateur satellite program!
> Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
>
------------------------------
Message: 6
Date: Tue, 26 Mar 2013 01:00:37 -0000
From: "Richard Ferryman" <g4bbh@xxxxxxxxxx.xxx>
To: <amsat-bb@xxxxx.xxx>
Subject: [amsat-bb] gpredict and ft-817 cat control
Message-ID: <924B2A3BE36F474B92A2DD450CD33AFF@xxxxxxxxxxxxx>
Content-Type: text/plain; charset="iso-8859-1"
Does anyone know a way around the problem that gpredict can only control the
FT-817 downlink frequency. I suspect there is a limitation in the hamlib
control for this rig. The gpredict manual says 'the TX frequency can not be
adjusted via the CAT interface (e.g. Yaesu FT-817)' but SatPC32 on windows
manages to handle TX and RX so it must be possible.
Dick G4BBH
------------------------------
Message: 7
Date: Mon, 25 Mar 2013 21:49:26 -0700
From: Greg D <ko6th.greg@xxxxx.xxx>
To: Gus <8p6sm@xxxx.xxx>
Cc: amsat-bb@xxxxx.xxx
Subject: [amsat-bb] Re: satellite los footprints
Message-ID: <515128D6.8010907@xxxxx.xxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Further to what Gus writes, I think Method #3 will suffer from two
assumptions, giving an impression of precision when less should be
expected. First, you are highlighting the shadows that mountains and
other terrain should give, but which are only applicable to visible
light. Radio waves bend and knife-edge diffract over and around these
things, so you're eliminating areas from being in serviceable view when
they could be interesting to try, if not perfectly useful.
Second, local obstructions such as buildings, trees, and other stuff
that aren't represented on Google Earth can be a big factor in the
success of any satellite pass, especially if / when we ever get back
some microwave capability in orbit. I have a small video camera mounted
on my Az/El rotor boom because I have this huge oak tree immediately
behind my house, and it was critical to know where it was - one large
limb in particular - compared to AO-40, in order to make a contact in
that direction. That tree is big, but I suspect not sufficient to show
up on Google Earth.
My recommendation is that you go with simple and easy now, and update it
later when you need something with more precision, for example, if /
when we get a high orbit target to aim precisely at. Maybe we'll have a
Google Backyard View by then.
Greg KO6TH
Gus wrote:
> I would suggest you go with #1 or #2. The added complexity of method
> #3 probably won't pay any significant dividends in practical terms.
> You could always implement #3 for version II. :-)
>
> Will you be considering squint? Frankly, I'm not sure any current
> satellites are using antennas where squint would play a part.
>
> Regards...
>
> On 03/25/2013 11:15 AM, Joseph Armbruster wrote:
>> I can not decide how to implement ground footprints with my google
>> earth satellite tracker. I figured, since I can't make up my mind, I
>> should get a second (and third, and fourth) opinion. For this thread,
>> I would like to discuss how satellite ground-footprints should be
>> implemented. A quick brainstorm led me to three possible
>> implementations (I am leaning towards 3). For each of these, I assume
>> that a geographic line-of-sight footprint is desired with no RF
>> characteristics taken into consideration:
>>
>> option 1 : assume a spherical earth model and project a polygon
>> downwards towards the footprint
>>
>> - note: this is obviously the easiest approach but will result in the
>> most error
>>
>> option 2 : assume an ellipsoidal earth model and project an
>> irregularly shaped polygon downwards towards the footprint
>>
>> - note: this is arguably more difficult than option 1 and would
>> result in less error
>>
>> option 3 : use a digital elevation model and an ellipsoidal model to
>> cull-out regions that are not visible due to geographic features and
>> project an irregularly shaped polygon downwards towards the footprint
>>
>> - note: In this case, our footprint polygon would have holes cut out
>> for the regions that are culled out by mountain ranges, canyons /
>> etc... Obviously, this would be the most difficult to implement but
>> would likely be the best visual representation. The problem is, I
>> would never dream of distributing DEMs for the entire Earth with my
>> tool, even DTED0 would be absurd in my opinion. I could make the
>> elevation queries accessible using a web-service, but then the user
>> would be tied to the internet. The other option would be to allow the
>> users to download their elevation data into a cache, then the tool
>> would just load / use it. This way the user would only have to obtain
>> the elevation data for their region of interest. Maybe that would be
>> the best approach? I am open to suggestions!
>>
>> If you have any experience visualizing footprints, please let me
>> know. I would be interested in hearing your lessons-learned. These
>> are what the line-of-sight indicators look like right now: Google
>> Earth Satellite Tracker - Line of Sight Update
>>
>> I am open to comments and suggestions,
>> Joseph Armbruster
>> _______________________________________________
>> Sent via AMSAT-BB@xxxxx.xxx. Opinions expressed are those of the author.
>> Not an AMSAT-NA member? Join now to support the amateur satellite
>> program!
>> Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
>>
>>
>
>
------------------------------
Message: 8
Date: Tue, 26 Mar 2013 15:27:12 +1000
From: Phil <phil_lor@xxxxxxx.xxx>
To: amsat-bb@xxxxx.xxx
Subject: [amsat-bb] predict client example in python
Message-ID: <515131B0.2090102@xxxxxxx.xxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
I've recently become interested in python and, as an exercise, I thought
I might attempt to port my C++ predict client to python. The problem is
that I haven't advanced far enough yet to know how to use python sockets.
I'd like to know how to connect to the predict server. Can anyone point
me towards any predict client code written in python? Surprisingly, a
Google search hasn't discovered much at all.
--
Regards,
Phil
------------------------------
Message: 9
Date: Tue, 26 Mar 2013 09:16:07 +0100
From: "Erich Eichmann" <erich.eichmann@xxxxxxxx.xx>
To: "Richard Ferryman" <g4bbh@xxxxxxxxxx.xxx>
Cc: amsat-bb@xxxxx.xxx
Subject: [amsat-bb] Re: gpredict and ft-817 cat control
Message-ID: <89E433DC05C044199B22AA238D3DAAF3@xxxxx>
Content-Type: text/plain; format=flowed; charset="iso-8859-1";
reply-type=original
Hello,
To adjust the TX frequency via CATcontrol a program first has to toggle the
VFOs (command hex. 81) to get access to the TX VFO. After adjusting the TX
frequency it has to toggle the VFOs back, of course.
Also, it is necessary to check the TX status (command hex. F7) before
sending frequency commands. The frequencies must not be changed during TX.
The adjusment has to be suspended until the radio is in RX again.
73s, Erich, DK1TB
----- Original Message -----
From: "Richard Ferryman" <g4bbh@xxxxxxxxxx.xxx>
To: <amsat-bb@xxxxx.xxx>
Sent: Tuesday, March 26, 2013 2:00 AM
Subject: [amsat-bb] gpredict and ft-817 cat control
> Does anyone know a way around the problem that gpredict can only control
> the FT-817 downlink frequency. I suspect there is a limitation in the
> hamlib control for this rig. The gpredict manual says 'the TX frequency
> can not be adjusted via the CAT interface (e.g. Yaesu FT-817)' but SatPC32
> on windows manages to handle TX and RX so it must be possible.
> Dick G4BBH
> _______________________________________________
> Sent via AMSAT-BB@xxxxx.xxx. Opinions expressed are those of the author.
> Not an AMSAT-NA member? Join now to support the amateur satellite program!
> Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
>
------------------------------
Message: 10
Date: Tue, 26 Mar 2013 07:58:07 -0400
From: Joe Fitzgerald <jfitzgerald@xxxx.xxx.xxx>
Cc: "amsat-bb@xxxxx.xxx BB" <amsat-bb@xxxxx.xxx>
Subject: [amsat-bb] Re: satellite los footprints
Message-ID: <51518D4F.70909@xxxx.xxx.xxx>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
On 3/25/2013 6:42 PM, Ken Ernandes wrote:
> 2. If you decide to give the users the ability to input their location,
them the option to provide either a single minimum elevation angle or a
local map -- i.e., 360 individual minimum elevations as a function of
Azimuth. It's much easier to project this and the user is generally
interested in an unobstructed LOS with respect to his/her location.
>
>
It's not the best resolution but in the image below, you can see how
there are "cut outs" in the circles surrounding NASA's ground stations -
the software has clearly implemented the idea Ken outlined above. For
example, there is apparently some obstruction to the south east of the
Hawaiian tracking station. If the sub-satelite point is inside the
white line it's AOS. The surface of the earth visible to the shuttle,
on the other hand, is simply a red circle, just faintly visible in this
image.
http://vault.newsfromspace.com/missions/sts114/STS114_land-5.jpg
-Joe KM1P
------------------------------
Message: 11
Date: Tue, 26 Mar 2013 07:25:30 -0700
From: Greg Dolkas <ko6th.greg@xxxxx.xxx>
To: Erich Eichmann <erich.eichmann@xxxxxxxx.xx>, Richard Ferryman
<g4bbh@xxxxxxxxxx.xxx>
Cc: amsat-bb@xxxxx.xxx
Subject: [amsat-bb] Re: gpredict and ft-817 cat control
Message-ID: <63be22f0-42a0-4c97-b8a9-d36d49c57666@xxxxx.xxxxxxx.xxx>
Content-Type: text/plain; charset=UTF-8
What happens if you do try to change frequencies during transmit? There is
a race condition between the status check and frequency programming where
the mike PTT button could be pressed.
Greg. KO6TH
--
Sent from my new toy... Please ignore tupos.
Erich Eichmann <erich.eichmann@xxxxxxxx.xx> wrote:
>Hello,
>To adjust the TX frequency via CATcontrol a program first has to toggle
>the
>VFOs (command hex. 81) to get access to the TX VFO. After adjusting
>the TX
>frequency it has to toggle the VFOs back, of course.
>
>Also, it is necessary to check the TX status (command hex. F7) before
>sending frequency commands. The frequencies must not be changed during
>TX.
>The adjusment has to be suspended until the radio is in RX again.
>
>73s, Erich, DK1TB
>
>----- Original Message -----
>From: "Richard Ferryman" <g4bbh@xxxxxxxxxx.xxx>
>To: <amsat-bb@xxxxx.xxx>
>Sent: Tuesday, March 26, 2013 2:00 AM
>Subject: [amsat-bb] gpredict and ft-817 cat control
>
>
>> Does anyone know a way around the problem that gpredict can only
>control
>> the FT-817 downlink frequency. I suspect there is a limitation in
>the
>> hamlib control for this rig. The gpredict manual says 'the TX
>frequency
>> can not be adjusted via the CAT interface (e.g. Yaesu FT-817)' but
>SatPC32
>> on windows manages to handle TX and RX so it must be possible.
>> Dick G4BBH
>> _______________________________________________
>> Sent via AMSAT-BB@xxxxx.xxx. Opinions expressed are those of the
>author.
>> Not an AMSAT-NA member? Join now to support the amateur satellite
>program!
>> Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
>>
>
>
>_______________________________________________
>Sent via AMSAT-BB@xxxxx.xxx. Opinions expressed are those of the
>author.
>Not an AMSAT-NA member? Join now to support the amateur satellite
>program!
>Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
------------------------------
Message: 12
Date: Tue, 26 Mar 2013 17:06:36 +0000
From: B J <va6bmj@xxxxx.xxx>
To: amsat-bb <amsat-bb@xxxxx.xxx>
Subject: [amsat-bb] Dragon Returns
Message-ID:
<CAP7QzkPc6Lz3zB4tAdtT=yV_GYnwrsu7YT3M4WCH7MGPth6G+w@xxxx.xxxxx.xxx>
Content-Type: text/plain; charset=ISO-8859-1
http://www.parabolicarc.com/2013/03/26/dragon-re-entry-updates/
http://www.nasaspaceflight.com/2013/03/spacexs-crs-2-dragon-iss-departure-spla
shdown/
73s
Bernhard VA6BMJ @ DO33FL
------------------------------
Message: 13
Date: Tue, 26 Mar 2013 13:47:15 -0400
From: Joseph Armbruster <josepharmbruster@xxxxx.xxx>
To: Ken Ernandes <n2wwd@xxxxxxxxxx.xxx>
Cc: "amsat-bb@xxxxx.xxx BB" <amsat-bb@xxxxx.xxx>
Subject: [amsat-bb] Re: satellite los footprints
Message-ID: <3E44F5BC-6805-4320-BE42-132904119D08@xxxxx.xxx>
Content-Type: text/plain; charset=us-ascii
Ken,
I have already implemented the concept of ground station, albeit, i'm not
sure I like the way I have the configuration file set up, see:
ground station implementation: Google Earth Satellite Tracker - Ground
Stations U...
los implementation: Google Earth Satellite Tracker - Line of Sight Upd...
I'm likely going to implement 1 and move on for now. With respects to the
ground station, I like the idea of having a minimum elevation angle, that
would be insanely easy to implement. Expect these two to be implemented
later tonight :-)
Joseph Armbruster
On Mar 25, 2013, at 6:42 PM, Ken Ernandes wrote:
> My humble suggestion:
>
> 1. Implement option 1 for the satellite footprint.
> 2. If you decide to give the users the ability to input their location,
them the option to provide either a single minimum elevation angle or a
local map -- i.e., 360 individual minimum elevations as a function of
Azimuth. It's much easier to project this and the user is generally
interested in an unobstructed LOS with respect to his/her location.
>
> 73, Ken N2WWD
>
> Sent from my iPad
>
>
>
> On Mar 25, 2013, at 11:15 AM, Joseph Armbruster
<josepharmbruster@xxxxx.xxx> wrote:
>
>>
>> I can not decide how to implement ground footprints with my google earth
satellite tracker. I figured, since I can't make up my mind, I should get a
second (and third, and fourth) opinion. For this thread, I would like to
discuss how satellite ground-footprints should be implemented. A quick
brainstorm led me to three possible implementations (I am leaning towards
3). For each of these, I assume that a geographic line-of-sight footprint
is desired with no RF characteristics taken into consideration:
>>
>> option 1 : assume a spherical earth model and project a polygon downwards
towards the footprint
>>
>> - note: this is obviously the easiest approach but will result in the
most error
>>
>> option 2 : assume an ellipsoidal earth model and project an irregularly
shaped polygon downwards towards the footprint
>>
>> - note: this is arguably more difficult than option 1 and would result in
less error
>>
>> option 3 : use a digital elevation model and an ellipsoidal model to
cull-out regions that are not visible due to geographic features and project
an irregularly shaped polygon downwards towards the footprint
>>
>> - note: In this case, our footprint polygon would have holes cut out for
the regions that are culled out by mountain ranges, canyons / etc...
Obviously, this would be the most difficult to implement but would likely be
the best visual representation. The problem is, I would never dream of
distributing DEMs for the entire Earth with my tool, even DTED0 would be
absurd in my opinion. I could make the elevation queries accessible using a
web-service, but then the user would be tied to the internet. The other
option would be to allow the users to download their elevation data into a
cache, then the tool would just load / use it. This way the user would only
have to obtain the elevation data for their region of interest. Maybe that
would be the best approach? I am open to suggestions!
>>
>> If you have any experience visualizing footprints, please let me know. I
would be interested in hearing your lessons-learned. These are what the
line-of-sight indicators look like right now: Google Earth Satellite
Tracker - Line of Sight Update
>>
>> I am open to comments and suggestions,
>> Joseph Armbruster
>> _______________________________________________
>> Sent via AMSAT-BB@xxxxx.xxx. Opinions expressed are those of the author.
>> Not an AMSAT-NA member? Join now to support the amateur satellite program!
>> Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
------------------------------
Message: 14
Date: Tue, 26 Mar 2013 13:59:42 -0400
From: Joseph Armbruster <josepharmbruster@xxxxx.xxx>
To: Greg D <ko6th.greg@xxxxx.xxx>
Cc: amsat-bb@xxxxx.xxx
Subject: [amsat-bb] Re: satellite los footprints
Message-ID: <22D6F4F2-5E21-46EF-A9E5-995204852BCF@xxxxx.xxx>
Content-Type: text/plain; charset=us-ascii
Greg,
You bring up good points across-the-board. Note: I made it a point to
explicitly mention the lack-of-rf-considerations in my original email.
You mentioned Google Backyard View.... what's interesting about my
implementation is that if you zoom-in to the ground in Google Earth, you
enter "Ground Level View". If you look up into the sky, you can actually
see the paths that i'm rendering. I could potentially style the orbits
based on the different views. From the ground-view perspective, I could
display the AZ / EL. So if someone new to the hobby wanted to make sure
they were pointing the right way, all they would have to do is look.
There are all sorts of possibilities when it comes to having a Google-Earth
like interface. It is extremely trivial to generate description bubbles and
style them cleanly. For our next satellite, we could auto-generate
placemarks of the telemetry on the orbit in near-real-time, so when people
fly Google Earth, they could see the spots immediately. I think the whole
thing is just fun :-)
Joseph Armbruster
On Mar 26, 2013, at 12:49 AM, Greg D wrote:
> Further to what Gus writes, I think Method #3 will suffer from two
assumptions, giving an impression of precision when less should be expected.
First, you are highlighting the shadows that mountains and other terrain
should give, but which are only applicable to visible light. Radio waves
bend and knife-edge diffract over and around these things, so you're
eliminating areas from being in serviceable view when they could be
interesting to try, if not perfectly useful.
>
> Second, local obstructions such as buildings, trees, and other stuff that
aren't represented on Google Earth can be a big factor in the success of any
satellite pass, especially if / when we ever get back some microwave
capability in orbit. I have a small video camera mounted on my Az/El rotor
boom because I have this huge oak tree immediately behind my house, and it
was critical to know where it was - one large limb in particular - compared
to AO-40, in order to make a contact in that direction. That tree is big,
but I suspect not sufficient to show up on Google Earth.
>
> My recommendation is that you go with simple and easy now, and update it
later when you need something with more precision, for example, if / when we
get a high orbit target to aim precisely at. Maybe we'll have a Google
Backyard View by then.
>
> Greg KO6TH
>
>
> Gus wrote:
>> I would suggest you go with #1 or #2. The added complexity of method #3
probably won't pay any significant dividends in practical terms. You could
always implement #3 for version II. :-)
>>
>> Will you be considering squint? Frankly, I'm not sure any current
satellites are using antennas where squint would play a part.
>>
>> Regards...
>>
>> On 03/25/2013 11:15 AM, Joseph Armbruster wrote:
>>> I can not decide how to implement ground footprints with my google earth
satellite tracker. I figured, since I can't make up my mind, I should get a
second (and third, and fourth) opinion. For this thread, I would like to
discuss how satellite ground-footprints should be implemented. A quick
brainstorm led me to three possible implementations (I am leaning towards
3). For each of these, I assume that a geographic line-of-sight footprint is
desired with no RF characteristics taken into consideration:
>>>
>>> option 1 : assume a spherical earth model and project a polygon
downwards towards the footprint
>>>
>>> - note: this is obviously the easiest approach but will result in the
most error
>>>
>>> option 2 : assume an ellipsoidal earth model and project an irregularly
shaped polygon downwards towards the footprint
>>>
>>> - note: this is arguably more difficult than option 1 and would result
in less error
>>>
>>> option 3 : use a digital elevation model and an ellipsoidal model to
cull-out regions that are not visible due to geographic features and project
an irregularly shaped polygon downwards towards the footprint
>>>
>>> - note: In this case, our footprint polygon would have holes cut out for
the regions that are culled out by mountain ranges, canyons / etc...
Obviously, this would be the most difficult to implement but would likely be
the best visual representation. The problem is, I would never dream of
distributing DEMs for the entire Earth with my tool, even DTED0 would be
absurd in my opinion. I could make the elevation queries accessible using a
web-service, but then the user would be tied to the internet. The other
option would be to allow the users to download their elevation data into a
cache, then the tool would just load / use it. This way the user would only
have to obtain the elevation data for their region of interest. Maybe that
would be the best approach? I am open to suggestions!
>>>
>>> If you have any experience visualizing footprints, please let me know. I
would be interested in hearing your lessons-learned. These are what the
line-of-sight indicators look like right now: Google Earth Satellite Tracker
- Line of Sight Update
>>>
>>> I am open to comments and suggestions,
>>> Joseph Armbruster
>>> _______________________________________________
>>> Sent via AMSAT-BB@xxxxx.xxx. Opinions expressed are those of the author.
>>> Not an AMSAT-NA member? Join now to support the amateur satellite program!
>>> Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
>>>
>>>
>>
>>
> _______________________________________________
> Sent via AMSAT-BB@xxxxx.xxx. Opinions expressed are those of the author.
> Not an AMSAT-NA member? Join now to support the amateur satellite program!
> Subscription settings: http://amsat.org/mailman/listinfo/amsat-bb
------------------------------
_______________________________________________
Sent via amsat-bb@xxxxx.xxx. Opinions expressed are those of the author.
Not an AMSAT member? Join now to support the amateur satellite program!
http://amsat.org/mailman/listinfo/amsat-bb
End of AMSAT-BB Digest, Vol 8, Issue 94
***************************************
Read previous mail | Read next mail
| |
