DIY GPS Antenna Tracker

Met het oog op komende zomer ook FPV te gaan vliegen en het knutselen met (micro)elektronica, wil ik mij gaan storten op het maken van een eenvoudige antenne tracker.

Een microcontroller die GPS-gegevens van de GPS-module toegediend krijgt en vervolgens de relevante informatie filtert (positie/hoogte). Die informatie wordt dan omgezet in audiosignaal (codering nader te bepalen) en kan via de videozender, mits deze is voorzien van een audiokanaal, naar het grondstation worden gestuurd.

Op de grond kan een microcontroller het audiosignaal van de ontvanger weer decoderen, wat rekenen met de gegevens en vervolgens de patch antenne besturen.

Ja, zulke systemen bestaan al natuurlijk maar het gaat meer om de kick van het zelf maken. In een ver verleden heb ik NMEA-converters gemaakt voor de scheepvaart (heel ver verleden om info van NMEA0180/0181/0182/Loran-C en gebrekkig NMEA0183 op diverse snelheden van diverse ontvangers te converteren naar standaard $GPGLL voor navigatie op een PC, u weet wel met een EGA scherm 8O).


Vraag is welke baudrates gangbaar zijn voor de diverse GPS-modules in verband met auto-detectie van de bitrates en de manier van audio moduleren en data coderen/comprimeren.

 

De chip die mijn setje gebruikt staat standaard op 9600bd maar kan er meerdere aan.

http://www.geosat.com.tw/meat/doc/ST06-datasheet.pdf

 

Yep, 1200 (heel ouderwets), 2400 (zeldzaam), 4800 (standaard NMEA ooit), 9600 (huidige standaard) worden de waarden waarop sowieso gecontroleerd wordt. Maar 19200, 38400 en hoger lijken mij zeldzamer. Maar ik wil die niet uitsluiten als die gebruikt worden. Ik wil het wat universeel houden, misschien wel op basis van een Arduino.

 

Dan kun je gemakkelijk wat in elkaar fietsen.
Heb je al een idee over een modem dan ?

 

Ik hoef die data niet met 9600 baud uit de lucht weg te sturen in hetzelfde formaat. Leesbare tekst maak je gewoon binaire data van. Als je elke seconde een volledige positie doorgeeft is dat genoeg. Met een beetje FM in het audiogehoorgebied (1000-3000Hz) kun je het dus af. Die beperking heb je omdat de geluidskwaliteit niet best is van die videozendertjes.

Ook weer makkelijk te decoderen: De "draaggolf" is je referentiefrequentie als "0", een flinke afwijking in PWM dus een "1". Met circa 10 bytes kun je heeeeel veel versturen. Da's 80 bits data. Lat/Long past ruimschoots in 6 bytes (kan in 5 bytes zonder NSEW bits), Alti in 1 byte (2 als je op de meter nauwkeuriger dan stappen van ca. 10 meter wilt). Extra 3 (of 2) bytes om een checksum te maken en indicatie voor een geldige fix. Elke bit 10 msec. modulatie, dus binnen elke seconde alle data verstuurd. Genoeg om op de grond de GPS in de lucht te blijven volgen. Geen hoge eisen aan rekenkracht etc.

De nodige hoeken voor de servo's zijn eenvoudig uit te rekenen op basis van de drie gegevens. De antennepositie bepaal je bij de start door bijv. even op de knop te drukken. De actuele GPS positie van je vliegtuig is dan ruwweg de positie van je antenne.


Oh ja, de baudrate wordt natuurlijk bepaald door je FPV-set. De RxD vanaf de GPS (eigen dus TxD ) wordt afgetakt zodat deze naar zowel je OSD als de modulator gaan.

 

Als ik al die kennis zou hebben dan zou ik mij storten op een all in one systeem.
Een telemetrie systeem die de besturing en beeld mogelijk maakt.
Zeg maar aan beide kanten een zender ontvanger.

 

Daar heb ik wel over nagedacht. Maar dat is enerzijds het wiel opnieuw uitvinden en anderzijds gaat dat ten koste van het lowbudget karakter. Er zijn heel veel betaalbare OSD setjes en heel veel FPV'ers hebben al een OSD. Doel is om een systeempje te maken van hooguit 60 euro exclusief servo's en andere radiobenodigdheden. Geen hightech maar lekker simpel.

 

Ik ben benieuwd

 

Met alleen baud rates ben je er niet. Bij moderne GPS ontvangers kan je de NMEA data string aanpassen. Zodoende kan je hogere refresh rates halen door gewoon de data waar je geen interesse in hebt niet mee te sturen en dus een hogere datarate kunt halen in de data waar je wel interesse in hebt. Ga je alle NMEA data doorsturen dan zul je inderdaad je baudrate op moeten schroeven, maar dan stuur je ook allerhande data mee waar je niks mee doet/kunt.

Met vriendelijke groet,

Sander Sassen
ImmersionRC - Real Virtuality

 

Da's waar maar die instellingen ga ik niet beïnvloeden. Ik hoef alleen maar een tap van de seriële uitgang van de GPS naar de OSD. De software zal moeten controleren of er gefragmenteerd $GPGLL (lat/long), $GPGSA (fix, afwijking) en $GPVTG (snelheid) is als informatie. Sommige GPS-en sturen $GPRMC (fix, lat/long, heading, snelheid). Mooiste is als $GPGGA (lat/long, fix, hoogte) aanwezig is waarmee je eigenlijk alle noodzakelijke informatie hebt.

Gezien de informatie die de gemiddelde OSD heeft, zal daar alles in zitten wat ik nodig heb. Als ik uit ga van 115.200bps en dan steeds lager ga controleren, zit ik helemaal goed. Ik controleer gewoon op alle gangbare snelheden tot er "leesbare" data voorbij komt. GPS-commando's zijn altijd herkenbaar aan $GP aan het begin ($ voor startsignaal GP om aan te geven dat het om een GPS apparaat gaat). Auto-sensing zal dus een paar seconden in beslag nemen maar de gemiddelde piloot is toch 2 minuten aan het knoeien voordat-ie vliegt.

De module die ik destijds geprogrammeerd heb, ging er al vanuit dat niet alle data aanwezig was. Die haalde eruit wat voorbij kwam en bruikbaar was, koos bij meerdere inputs de meest nauwkeurige informatie van de desbetreffende aangesloten apparaten (toen keek men ook niet op een cijfertje meer of minder achter de komma), verwerkte die als het nodig was naar het juiste formaat en stuurde het vervolgens als één "apparaat" naar buiten.

De seriële buffer leest alles braaf in, die is groot genoeg voor vele seconden bulk data. Verwerken van de buffer is in een paar milliseconden gebeurd. Filteren en herberekenen eveneens. Het naar buiten sturen via audio zal ook minimale rekenkracht vergen. Het enige waar alles op hangt en staat zijn timers en interrupts maar die zijn er voldoende. Datacodering naar buiten zal iets van Manchester codering worden, modulatie gewoon key on/off. Elke packet een eigen sync zodat er geen afhankelijkheid is bij verstoringen. Gewoon voor het ouderwetse analoge modemgevoel.

 

Zo, alle benodigdheden aan microcontrollers en randverschijnselen zijn onderweg. 8)

Auto-sense voor baudrates wordt: 4800, 9600, 19200, 38400, 57600 en 115200.

Belangrijkste data wordt $GPGGA, die bevat alle nodige informatie en is de enige data met hoogteinformatie dus zit in alle OSD GPS-modules.

Code:

 $GPGGA,123519,4807.038,N,01131.000,E,1,08,0.9,545.4,M,46.9,M,,*47

Where:
     GGA          Global Positioning System Fix Data
     123519       Fix taken at 12:35:19 UTC
     4807.038,N   Latitude 48 deg 07.038' N
     01131.000,E  Longitude 11 deg 31.000' E
     1            Fix quality: 0 = invalid
                               1 = GPS fix (SPS)
                               2 = DGPS fix
                               3 = PPS fix
			       4 = Real Time Kinematic
			       5 = Float RTK
                               6 = estimated (dead reckoning) (2.3 feature)
			       7 = Manual input mode
			       8 = Simulation mode
     08           Number of satellites being tracked
     0.9          Horizontal dilution of position
     545.4,M      Altitude, Meters, above mean sea level
     46.9,M       Height of geoid (mean sea level) above WGS84
                      ellipsoid
     (empty field) time in seconds since last DGPS update
     (empty field) DGPS station ID number
     *47          the checksum data, always begins with *

 

Knap hoor... Bijzonder als je zo'n controllertje zelf weet te maken. Ik denk dat er zat mensen zijn die ook wel zo'n controllertje willen hebben.

Word er ook een Tiny telemetrie voor een paar tienen gebouwd? Ik kan er namelijk wel een stuk of wat gebruiken

 

Ik wil het simpel houden. En ook niet commercieel gaan uitbuiten. Als het werkt dan maak ik er wel wat open source-achtigs van. Met zijn alleen beter maken kan geen kwaad. Arduino's in hun standaard configuratie zijn betaalbaar (€17,50 voor de Mini Lite, optioneel USB-serieel adaptertje is €13,50, software en tools zijn gratis), aantal randcomponenten zal marginaal zijn voor de eenvoudigste vorm (geen schakelaars, lampjes, displays etc.). Ik mik op zo'n 50 à 60 euro kostprijs.

Als alles werkbaar is, zou meer telemetrie mogelijk zijn. Alleen zal dat ook veel meer rand-elektronica opleveren en komen de kosten als snel in de buurt van standaard oplossingen (bijv. EzOSD/EzTracker).


Huidige doel: Antenne volgen in een zichthoek van ca. 135° tot 180° horizontaal en 0° tot 90° vertikaal en hoorbaar signaal bij dreigende overschreiding van deze posities.

Toekomstige doelstellingen: Logging (extern of op SD), hoorbaar signaal RSSI waarschuwing, overige telemetrie mogelijkheden.

Fun doelstellingen: Random waypoint(s) en hoorbaar signaal bij nadering van het punt (ouderwets vossen maar dan met FPV 8)).



*wachten duurt lang*

 

Ik denk dat het hier nog interessant gaat worden, en dit niet alleen voor de geroutineerde modelbouwers onder ons. Er is blijkbaar hier iets moois aan het bloeien.

Er zijn meerdere modelbouwers hier op het forum met een elektrotechnische achtergrond die via het FPV-gebeuren zich goed kunnen uitleven.
Zekerst met ideeën zoals dat van Sleurhutje en met het delen van informatie met iedereen.
Er is de laatste tijd een evolutie of revolutie aan het gebeuren op elektrotechnisch vlak voor mensen die geïnteresseerd zijn in elektronica en programmeren, en hier verwijs ik naar bijvoorbeeld de arduinoprojecten en dergelijke die te vinden zijn op het net. Niet iedereen is elektrotechnisch-ingenieur, maar tegenwoordig hoeft dit ook niet echt meer en zijn er gelukkig mensen die meer en meer hun kennis willen delen.:teacher:
Momenteel ben ik het draadje van “ Het grote FPV (First person view) draadje.”
aan het doornemen, ik zit momenteel nu aan pagina 115, maar het is de moeite om dit als beginner eens te doen.

 

DragonOSD heeft nu die opties.
RTH en waypoints.

 

Joepie, de Arduino's zijn binnen. Zo ook een USB-serieel interface (een tweede heb ik nog van mijn Atmel Tiny programmer). Alles even in een testopstelling zetten zodat het mee kan in de notebooktas en in wat verloren uurtjes (onderweg) verder geknutseld kan worden. 8)



Oh ja, verwacht niet dat het volgende week klaar is. Ik maak minstens 60 uur in een week (een ict-clubje draaiend houden heeft zo zijn nadelen), bouw ook nog aan 5 verschillende andere projecten en moet af en toe vrouw en kinderen ook wat aandacht geven.

 

Sleur, goed werk.
Je blijft me verbazen !

Kan niet wachten....maar dat weet je

 

Zoals ik al eerder heb aangegeven ga ik dit zekerst met alle aandacht volgen.
Hou ons op de hoogte zou ik zeggen, we kunnen altijd nog wat bijleren.

 

Hehehe, leerzaam is het zeker. 20 Jaar geleden heb ik mijn studentenleven achter me gelaten en ben begonnen in de lichtreclame. Voor een hobbyist met micro-elektronica is er niets mooier dan pielen met controllers, programmeren en vooral veel LEDjes. 8) Ik heb buitenborden gemaakt van vele meters bij vele meters waar dik 200.000 LEDjes in zaten. 8O Ondertussen compleet achterhaalde techniek, met uitzondering van de controllers (destijds een Intel i960 en Philips 80C552 gebruikt). Voor mij is dit dus zeker een stukje "jeugdsentiment".

Hoe dan ook, kriebels, kriebels, kriebels... Arduino Mini Lite voorzien van de standaard LED op pin 13, een luidsprekertje want we moeten wel horen wat we doen en tijdelijk een Arduino USB serieel interface. En ja hoor, het knippert, toetert en stuurt tekst terug. :bday:



Volgende stap wordt dus het maken van een stroomdiagram als ontwerpfase voor de software.


-edit-
En ook dit soort displays voor binnen. LED-blokken en schuifregisters, veel schuifregisters. Borden waren onderling (horizontaal en vertikaal) door te lussen om een groter display te maken. De kleine links zijn ontworpen als tekstdisplay onder de monitoren in televisiestudio's. 8) De rechter kennen de meeste wel als presentatiedisplay bij entree's van kantoren en lobby's. Kon het niet laten ze even op te vissen uit het stof. :?




-edit 2-
Zo, de encoder (vliegtuigkant) codeert/moduleert de data naar 1500Hz audio met een bitrate van 120bps. Lijkt op zich niet veel maar voor elk stukje data van vliegtuig naar grondstation is 6 tot 8 bytes nodig (nog nader te bepalen op basis van tests). Per seconde dus ongeveer twee posities door te geven. De gecodeerde data is inclusief een synchronisatie (preamble) waarmee het grondstation de snelheid bepaald. Sneller versturen is dus alleen op de encoder aanpassen, de decoder bepaald zelf de snelheid van de datastroom. 8)

Ondertussen dus in Huize Sleur het fijne geluid van elektronische krekeltjes... :? :lol:

 

Update!!!

Middagje vrij en e.e.a. op papier uitgewerkt. Automagische detectie van de baudrate werkt. Principe is vrij simpel: Open de seriële poort op een specifieke snelheid, luister een aantal gekonden en kijk of in de buffer iets met $GP staat (begin van elk stukje data van de GPS module). De kans dat deze data leesbaar is op een verkeerde snelheid is theoretisch niet mogelijk (iets met bitsnelheden en combinaties die niet te vormen zijn). Als de tekst niet in de buffer staat, seriële poort sluiten, andere snelheid kiezen en hetzelfde herhalen. Gekeken wordt op 2400, 4800, 9600, 19200, 38400, 57600 en 115200 baud (8,N,1). Als alles een keer getest is maar geen bruikbare snelheid is gevonden, begint de procedure gewoon weer bij 2400 baud etc. Net zo lang tot de snelheid gedetecteerd is.

Meeste werk zat nog in de routine om een mooie bufferinput te maken en regels te kunnen lezen (mits die bestaan). Die routine heb ik straks toch weer nodig dus geen weggegooide tijd.



Na de krekels en de snelheidsmeting dus tijd om GPS-data te voeren. Helaas bleek mijn antieke 0,5Hz module er totaal geen zin meer in te hebben. Ik moet het dit weekend even doen met een simulatie van de log van mijn Garmin Oregon. Even wat rondjes rondom een locatie rijden met de auto zodat we een "heen-en-weer" log hebben.

Keep you posted.