Math nerd question

[intuitionsys]

I should prefix this question by mentioning I work with alot of the underlying orbital mechanics mathematics, mainly for LEO satellites, where I work, usually referred to as orbital propagation or orbital determination. I actually used my own software when I was sighting the clearance I'd need for my dish before purchase which is kind of cool in a geeky sort of way

That said (ugg ) I was just curious if USALS uses the SDP4 algorithm for azimuth calculation or is it much simpler than that? I'm guessing the latter but was just curious.

 

[Hermitman]

I think it's trig. Have you seen the program code here?

http://cvs.tuxbox.org/cgi-bin/viewc...nigma/lib/dvb/frontend.cpp?rev=1.91&view=auto

 

[intuitionsys]

It won't load but if it's fairly simple geocentric trigonometry that makes sense since no gravitational terms need to be used on a body assumed to be kept in a given orbital position (or more accurately speed) and the satellite doesn't have an equator epoch since it's not moving with respect to the earth's surface.

I just found it interesting since they obviously aren't using updated ephemeris.

 

[mastermesh]

2+2=4, but only in certain conditions.

You are way above my head on this one. I'd assume that yes, gravity pull north and south wouldn't matter in figuring out location of some satellite above the equator since the equator ain't gonna move north or south any time soon.

However, if you are looking for birds that don't stay on the equator (i.e. geostationary or geosynchronous orbit), then the more complex math will come in to play... but all dvb satellites are geostationary... non-geostationary birds are mainly weather satellites and stuff like that...

NOAA would need something like what you seem to be talking about...

it's geosyncrhonous but does move north and south, so it's not totally on the equator as close as other birds.

http://science.nasa.gov/Realtime/jtrack/noaa.html

 

[intuitionsys]

However, if you are looking for birds that don't stay on the equator (i.e. geostationary or geosynchronous orbit), then the more complex math will come in to play... but all dvb satellites are geostationary... non-geostationary birds are mainly weather satellites and stuff like that...

I wasn't interested in non-geosynchronous DVB satellites since that would require elevation and azimuth motors and a much more complicated tracking system. My work involves non-geosynchronous satellites for remote sensing using very large X-Band antennas (10m) with az/el motors for tracking the satellites from horizon to horizon as it passes over our window of visibility.

The algorithms for calculating geosynchronous and low earth orbiting satellites are very similar which is why I was wondering. Just mathematical curiosity.

NOAA would need something like what you seem to be talking about...

it's geosyncrhonous but does move north and south, so it's not totally on the equator as close as other birds.

Not all the NOAA birds are geosynchronous; e.g. the NOAA-xx fleet are sun-synchronous LEO satellites in high orbits. I developed a ground imaging and framing system for them several years ago (not for NOAA but a subcontract for a company working with NOAA data).

 

[Eastcoast]

Can't offer any comments about the math but have received APT images from those LEO/Polar orbiters like NOAA 15,16 etc.Lots of fun but havn't done that in a while.

Dave

 

[intuitionsys]

I haven't worked with NOAA for several years either. Right now we're working with data mainly from ERS-2, Envisat-1 (ESA), Radarsat-1 (CSA) and Landsat-5/7 (NASA). Our sister station out west receives NOAA data though. Data rates run from 85 Mbit/s to 150 Mbit/s depending on the satellite and we may be supporting one soon that downlinks at 300 Mbit/s. Now that's hi-def

Since I'm new to FTA but familiar with all the hardware and some of the underlying software, my USALS question was part of some musing about designing a receiver from the ground up using OTS hardware and open sourcing the software. I already have a project I'm knee deep in right now but maybe in 6 months to a year's time it would be something fun to work on.

 

[LordAlex]

Do a search on the Dreambox. An open source linux based dvb receiver. I suppose you could upload a different algorithm for locating the satellites or create a module to do so but...... not real sure it would be worth the effort since usals works quite well for most people.

:

 

[intuitionsys]

I could use whatever math I wanted to in the receiver since it's just using DISEqC 1.2 commands offsetting from a known reference.

I'm aware of the DreamBox and it appears to be a class act I just thought it would be interesting to do it myself someday.

 

[GrumpyGuy]

This might interest you.

http://www.freepatentsonline.com/4888592.html

 

[intuitionsys]

This might interest you.

http://www.freepatentsonline.com/4888592.html

Yeah I thought of that too Doing some surfing last night it looks like alot (all?) of the OTS cards like the ones from Twinhan support USALS anyway so it's a moot point. The only sticky point is where that code actually lies; in firmware, the driver or the supplied software. The first two you're free and clear but of course if it's in their software then you're looking at infringement unless of course you just keep the code to yourself then nobody cares.

It's just musing right now anyway so it's not a big deal one way or the other. I know Twinhan provides drivers for the Linux 2.6 kernel but I haven't even looked at the driver code or any APIs. Building something like that would be a fairly big undertaking, mainly the control frontend to the DVB card, and my wife would kill me if I got any busier than I already am