Posts Tagged ‘tracking’
As I mentioned in passing yesterday I have a number of Arduino based projects buzzing around in my head. One of them is to produce a satellite antenna pointer/indicator.
I have used an Android AR tracking solution before (flaky at best) and can see the relevant information in Orbitron or SatPC32 to know where to point the antenna but it is difficult to see a PC screen when stuck out in the middle of the lawn!
My idea is this, I will make a large tripod to which I can attach appropriate antenna as I need, then during the satellite pass it has indicators to show where to point the antenna manually.
I envisage the azimuth indicator to be a large horizontal circle with 36 LEDs positioned at 10 degree intervals, the elevation will be a quarter circle with 20 LEDs positioned at 5 degree intervals. Then during the pass the appropriate LEDs will light and assuming I keep the antenna aligned to these I should in theory get the best signal... Crazy??
Yes I know I could make or buy an azimuth/elevation rotator, eBay is full of low speed high torque geared DC motors with auto-stop/hold and numerous software solutions exist to drive them but this would require a bit more engineering and isn't something I can easily fabricate at the moment. My contraption would be much more rustic being made of rough cut timber!
Bright LEDs are ridiculously cheap and controlling this number from the Arduino will require the use of multiplexer drivers. The popular ones are the MAX 7219/7221
I won't go into the details of exactly what multiplexing is, other than to say that each display element (LED) is driven one at a time but by switching the electronics at high speed combined with the persistence of vision make the viewer believe the entire display is continuously active.
This technique can be used for individual LEDs, an LED grid matrix, or for 7 segment displays. Last night I successfully got a MAX7219 based 8-Digit 7-Segment LED module working.
The next stage was to investigate how an Arduino could calculate the appropriate azimuth and elevation data. Thankfully a library already exists qrpTracker (code is here), within this library is a port of the Plan-13 algorithm first written in Basic by James Miller G3RUH in 1990, subsequently ported to C by Edson Pereira, N1VTN and further updated by Howard Long, G6LVB.
Plan-13 processes keplerian elements, time and (optionally) observer location, and uplink downlink frequencies; it outputs satellite latitude and longitude, azimuth and elevation, and Doppler shifted frequencies. At the standard 16 MHz Arduino clock speed, this code can complete these calculations in approximately 30 ms. This code is reported to be highly accurate, if provided with proper data.
The important data are the observer location (longitude/latitude) and the current time. Step forward my well used GPS module which once lock is achieved can supply that data.
The next is get the appropriate up to date Keplerian twin element sets (TLE) and extract the appropriate information from it and pass that data to the Plan-13 functions.
The standard TLE follows the following format
You need to extract the Epoch Year/Day (including partial data), Inclination, Right Ascension, Eccentricity, Perigee, Mean anomaly and Mean Motion for a calculation (drag/orientation aren't critical) For the moment I have just extracted this manually from the latest TLE and entered it directly into the program.
After just an hour or so of research and programming I have the LED displaying the current azimuth and elevation of the FUNCube-1 satellite (AO73) based on the current position and time derived from the GPS!
The first four digits is the azimuth, the second four the elevation.