Altus Metrum GPS output to antenna tracker

The Rocketry Forum

Help Support The Rocketry Forum:

This site may earn a commission from merchant affiliate links, including eBay, Amazon, and others.

ckamila

Well-Known Member
Joined
Jan 16, 2011
Messages
63
Reaction score
0
Looking to create automated antenna tracker similar to what RC community uses for FPV (first person view). This is rather ambitious as i lack programming skills but have a Arduino and Raspberry Pi kicking around to learn from and hopefully involve my son. Not sure how viable this sort of tracker would be given the speed of rocket takeoff vs a slow moving airplane, helicopter or UAV. I know how to sniff wi-fi and ethernet data but Bluetooth or USB sniffing/parsing is new to me.

Anyone else out there ever attempted something similar or can point me in the right direction towards converting data? I have both the USB TeleDongle and TeleBT allowing data input via TeleDongle during testing tracker while still manually tracking with TeleBT.


DSCF8041-624x1024.jpg

Thanks,

Chris
 
The rocket will lose GPS lock during boost and if you are using a narrow-beam antenna you may not reacquire the rocket even when it comes back into GPS lock, so that's a potential problem.
I'm also not sure if the slew rates of typical antenna trackers are fast enough even if lock was kept.
 
Mike - yes, those are some of my thoughts too. Maybe incorporate dual antenna's but then how do you switch from primary antenna providing wide angle coverage at launch to yagi during near apogee for descent. Starting yagi in a vertical position my solve the loss of GPS on assent problem (loss is dependent on speed of assent to some degree) but off angle flights might be outside antenna reception cone in a single antenna solution? Fallback position would have antenna preforming high angle 360 degree sweep for GPS signal.
 
Of course, the easiest solution is to use enough transmitter power and receiver sensitivity that you can just use omni antennas. You have to go pretty high with the Altus Metrum before you need a directional antenna, and even then you could probably get by with a wide-beam 3 or 5 element Yagi pointed straight up.
 
A panel antenna is a better choice, good gain and much wider beamwidth than a Yagi.
Maybe (depends on the patch and the Yagi) but it's hard to find a 70cm patch antenna commercially, so you may have to make your own.
 
Of course, the easiest solution is to use enough transmitter power and receiver sensitivity that you can just use omni antennas. You have to go pretty high with the Altus Metrum before you need a directional antenna, and even then you could probably get by with a wide-beam 3 or 5 element Yagi pointed straight up.

Last year at NXRS I was over 21k on a min dia 54mm and plan a min dia 75mm this year. Not sure what altitude i should expect yet but hoping for 30K+. Last year i used a 3 element yagi (arrow antenna) with good reception until i went behind hill to the East but reacquired signal shortly thereafter long enough to get a good fix before signal was lost. Some sort of tracking antenna would be helpful.
 
Last edited:
Look at this thread if you want to roll your own patch antenna. Could conceiveably do it for 70cm.

https://www.rocketryforum.com/showthread.php?123183-DIY-Patch-Antenna&p=1425707#post1425707

Kurt

Looks like more research is needed. I also found a link to patch panel arrays that might prove interesting. https://vk6ysf.com/Patch_Antenna_Pt1.htm

While i need to pick or test antenna(s), being able to process the GPS data and programming the servos to track is more important at this point.
 
Last edited:
Keep in mind that the new Teledongle has better sensitivity and should increase range. Also, what data rate were you using before? Lower data rates should improve range.
Getting data out of the system shouldn't be hard. You'll have to know the position and orientation of your ground station, of course, though there are probably off-the-shelf solutions from the FPV community to do that.
https://plane.ardupilot.com/wiki/automatic-ground-antenna-tracking/
 
While i need to pick or test antenna(s), being able to process the GPS data and programming the servos to track is more important at this point.

Try looking for information on tracking ham satellites. There is a wealth on info out there.

At UHF and low power to boot you are not going to get data from the rocket once it goes behind a hill! A beam isn't going help that, bulldozer maybe. The last data before the rocket descends below the hilltop should get you close anyway.

I use absolute encoders for my large 432 MHz MoonBounce array. I like them because they give good accuracy and once calibrated stay calibrated. They can be purchased, .1 degree accuracy (https://www.usdigital.com/) or homebrewed, .5 degree accuracy (https://www.qsl.net/oe5jfl/encoder.htm) which can be time consuming, your choice.

Stepping motors might be a better choice for turning the antennas.
 
Last edited:
You can reduce the speed that the antenna tracking system has to move the antennas by starting with the antennas pointing straight up. They will have a fairly wide beam
width so the the rocket should stay in the pattern most of the way up to apogee. You could have the tracking system start tracking when the rocket was more than 1000 feet above the launch pad.

If you want to build a small yagi, these designs work well and are easy to build. https://www.wa5vjb.com/yagi-pdf/cheapyagi.pdf.
 
Let me know if I can help in any way. Note that we report the GPS lat/lon, but the UI use baro for altitude as that works even when GPS loses lock on ascent, and presumably the rocket isn't going sideways (at least we hope not!). The telemetry packet parsing code is all in twisty java code for the UI, but there's also C code that might be easier to deal with on the pi.
 
Let me know if I can help in any way. Note that we report the GPS lat/lon, but the UI use baro for altitude as that works even when GPS loses lock on ascent, and presumably the rocket isn't going sideways (at least we hope not!). The telemetry packet parsing code is all in twisty java code for the UI, but there's also C code that might be easier to deal with on the pi.

Keith - If you can push me in the "best" direction for parsing the C GPS data that would be great! I know very little code but thought enough examples are floating around for me to "shake and bake" an antenna tracker. First question is why Pi over Arduino? Not that it matters as i am new to both.

Chris
 
Last edited:
Blurker - Thanks for the link. I do have Arrow 3 element yagi and a home brew 6 element yagi from link on BRB's page. Home brew needs work as i mounted the BNC connector at the butt end. Bad location as it created too much stress and snapped off. Need to move it further forward on the handle and zip-tie both sides.
 
Last edited:
What might make the most sense is to design your antenna tracking system onto the existing Altos UI. Maybe add a antenna tab? All the parsing and math for the tracking is already done for you. You would only need to figure out the interface from the antennas to the computer and do some simple code to steer the antenna to the azimuth and elevation that have already been calculated. The code is open source I believe. It would run on a PC instead of a micro which might be an issue for you. You could use a micro to interface the antennas to the PC via a USB port? It could be an interesting addition to an already cool product.
 
Keith - Looking at your AltOS Telemetry document https://altusmetrum.org/AltOS/doc/telemetry.pdf, is this the correct way to begin deconstructing the example TeleDongle packet at the bottom of page 7?

Note: extra space within packet is unintentional.

TELEM 224f01080b05765e00701f1a1bbeb8d7b60b070605140c000600000000000000003fa988

Length = 22
Data = 4f01080b05765e00701f1a1bbeb8d7b60b070605140c000600000000000000
rssi = 003f
lqi = a9
checksum = 88

or should data begin after 4f0108
Data = 0b05765e00701f1a1bbeb8d7b60b070605140c000600000000000000

thanks,
chris
 
What about,, instead of using the data to make adjustments to the antenna use a diversity setup that uses several antennas pointing at say 40 degrees from each other and the strongest signal gets an adjustment of the motor. I saw this done with an RC FPV setup and it worked quite fast and smooth.

73

Chris
 
Keith - Looking at your AltOS Telemetry document https://altusmetrum.org/AltOS/doc/telemetry.pdf, is this the correct way to begin deconstructing the example TeleDongle packet at the bottom of page 7?

Note: extra space within packet is unintentional.

TELEM 224f01080b05765e00701f1a1bbeb8d7b60b070605140c000600000000000000003fa988

Length = 22
Data = 4f01080b05765e00701f1a1bbeb8d7b60b070605140c000600000000000000
rssi = 003f
lqi = a9
checksum = 88

or should data begin after 4f0108
Data = 0b05765e00701f1a1bbeb8d7b60b070605140c000600000000000000

thanks,
chris

The first byte is the length (34), then the packet data starts right after that with the serial number (two bytes, 0x014f) and the timestamp (two bytes, 0x0b08). This is a GPS position packet, type 5.
 
What about,, instead of using the data to make adjustments to the antenna use a diversity setup that uses several antennas pointing at say 40 degrees from each other and the strongest signal gets an adjustment of the motor. I saw this done with an RC FPV setup and it worked quite fast and smooth.

73

Chris

That sounds like a great idea. First though, i need to be able to parse the packets.
 
Here is the concept I was talking about.

[video=youtube_share;tLCiwqwpvqI]https://youtu.be/tLCiwqwpvqI[/video]

This is using 5.8ghz video but there is no reason it would not work on 70cm.


73

Chris
 
I know you are on a track of using data to get the direction but time-doppler techniques like the hams use for fox hunting may work also. In this system you would not need the data but just the RF carrier will do.

Here is a example,

https://www.byonics.com/dsp-rdf/
 

Latest posts

Back
Top