Eigenbau Tracker mit Downlink über den Audiokanal

QuadMax

Erfahrener Benutzer
#1
[size=+1]Neuigkeiten im zweiten Post.[/size]

Ich möchte euch meinen Antennentracker vorstellen.
Hierbei handelt es sich um einen Endlostracker, welcher mit dem Audiokanal der Videoübertragung arbeitet.
Für den ganzen Tracker werden nur 2 Arduinos (pro mini), ein gps, und zwei 180° Servos benötigt.
Optional kann man noch ein Display und ein Megnetfeldsensor anschließen. Mit diesem entfällt das ausrichten nach Norden.
Alles zusammen mit Display und Sensor bekommt man für rund 30 Euro.
Ziel des Projektes war ein Endlostracker, welchen man einschaltet und er funktioniert dann von alleine :).
Das Projekt enstand kurz bevor Rangarid den open360 Tracker ins Leben gerufen hat und da ich meine Teile
schon bestellt hatte, habe ich ich mich an der Umsetzung versucht.

Das ganze ist aber nicht alleine auf meinem Mist gewachsen. Ein besonderes Dankeschön geht an cesco1. Er hat den Code zum einlesen des gps, sowie Sende und Empfang Code geschrieben. Ohne dich wäre das Projekt bestimmt gescheitert!

Zum Funktionsprinzip:
Hierzu werde ich mal in den nächsten Wochen ein Video machen, wie das Teil funktioniert. Hier gibt es schoneinmal ein Link, das Video ist aber nicht von mir:
http://vimeo.com/3991479

Diese Teile hier werden benötigt:
Bild2.jpg
Bild1.jpg

Das Display zeigt das Startbild, das erscheint, wenn man den Tracker einschaltet. In der aktuellen Version gibt es aber keine Uhrzeit mehr, da dies zu kompliziert geworden wäre.
Auf den Bildern fehlt der hmc5883l, der mag Sensor.
Solange der mag Sensor mit dem 1. Servo parallel steht, kann man den Tracker bauen, wie man möchte.
Mein Tracker soll einmal so aussehen:
Bild3.png


Aber man ist nicht an eine Box gebunden, solange man die zwei Servos richtig verbaut hat und der Sensor von den Achsen her richtig steht, kann man das ganze bauen, wie man möchte. Im Video oben sieht man eine noch kompaktere Form.

Im Moment muss ich aber noch das Gelenk zusammenbauen.

Bild4.jpg

Aktueller Status heißt: Testen!

Vielleicht gefällt dem einem oder anderem das Projekt ja und wenn Interesse besteht, erstelle ich eine Bauanleitung.
Da ich nicht so die große Erfahrung mit dem programmieren von Ardus habe, wäre ich dankbar wenn sich jemand meinen Code mal angucken könnte.

Grüße Max
 
Zuletzt bearbeitet:

QuadMax

Erfahrener Benutzer
#2
[size=+3]Anleitung zum Nachbauen auf Github.[/size]

[size=+2]Github[/size][size=+2]--||--[/size][size=+2]Wiki[/size]


[size=-3](anklicken für große Ansicht)[/size]
Anhang anzeigen 131949
Bodenstation
[size=-3](neue Version hat zusätzlich 4fach Stromverteiler)[/size]

Anhang anzeigen 105486
Sendemodem [size=-3](< 10 Gramm ohne GPS)[/size]

[video=youtube;bSRO-cwwE6I]http://www.youtube.com/watch?v=bSRO-cwwE6I[/video]
[size=-3](nicht ganz kalibriert :))[/size]
 
Zuletzt bearbeitet:

DerCamperHB

Erfahrener Benutzer
#4
Ist die Audioübertragung von ProMini zu Promini ohne extra Bauteile stabil, oder eher Störanfällig durch "Rauschen" bei Reichweitengrenzen
 

QuadMax

Erfahrener Benutzer
#6
Die Übertragung selbst habe ich nicht programmiert. Soweit ich es weiß hat es aber einen Rauschfilter.
Hier der Link zum Thread: http://fpv-community.de/showthread....a-Audiokanal-Programmierer-und-Tester-gesucht
Wie gut das bei Reichweitengrenzen funktioniert habe ich aber im Praxistest noch nicht testen können.
Solange aber zuerst das Bild weg ist reicht es mir :).
Vielleicht könnte der Programmierer hierzu mal Stellung beziehen, was das Modem kann.
Hier der Link zu seiner github: https://github.com/Cesco1/ArduModem

Falls jemandem das Projekt gefällt und Lust hat ihm aus den Kinderschuhen zu helfen. Kann ich gerne zwei Ardus und den mag sensor zum testen schicken.
 

Jörn

Erfahrener Benutzer
#7
Ich kann aus Erfahrung sagen, dass sich Audio und Video relativ gleichzeitig verabschieden. Das Gerücht das sich das Video Signal bedeutend länger hält als das Audio Signal, kann ich nicht bestätigen.
Selbst Charles hat ja im Nachhinein zugegeben, dass der Wechsel auf die Daten Übertragung im Video Kanal, wohl eher der schlechten Qualität der erwerbbaren Audio Modem Chips geschuldet war.
 

QuadMax

Erfahrener Benutzer
#8
Hi Jörn, das sind ja gute Neuigkeiten. Bis zur Bildgrenze reicht es ja.
Ich habe noch niemanden gesehen der weiter geflogen ist :D.
 

DerCamperHB

Erfahrener Benutzer
#9
Jörn und genau das meine ich, ein Vernünftiges Audio Modem wird auch länger klare Daten erhalten als ein Software Modem wie es hier verwendet wird, wobei ein Video Modem sicher noch schwieriger zu Programmieren wäre
 

QuadMax

Erfahrener Benutzer
#10
Ob das "Softwaremodem" wirklich schlechter ist als ein "Audiomodem" wissen wir ja noch nicht. Ich werde es mal die nächsten Wochen Testen und dann hier Bericht erstatten was zuerst versagt hat, video oder audio.
 

cesco1

Erfahrener Benutzer
#12
Leider hatte ich schon lange keine zeit mehr mich drum zu kümmern.
Hier einige punkte:

Dem unsignedmark sein modem (und meins ist ne abwandlung davon) sollte weit besser sein als was man bisher an audio firmwaremodems hatte. Die leistung sollte nahe oder gleich einem hardwaremodem sein.

Das modem verträgt KEIN DC BIAS am eingang. Wenn der wandler 2.5V mitte (kein ton) erwartet soll das nicht 2.7V sein. Vielleicht wäre da ein kalibrationsmode gut? Kein ton aber DC bias -> messen/anzeigen -> firmware korrigiert bias?

Normalerweise erwartet das modem eingangsspennungen von 0V bis 5V, wenn da in der firmware vref=vcc gesetzt ist. Das heisst das audio sollte mehr als 1V PP sein und weniger als 5.0V PP. Das ist für audio SEHR VIEL. Man kann in der firmware vref = 1.1V setzen, was eine wesentlich bessere empfindlichkeit ergibt. DC bias muss dann aber Vref / 2 sein, d.h. 0.55V. Damit könnte man (wahrscheinlich) direkt das audio des video receiver nehmen, ohne zusatzverstärker.
(ich hab das nicht getestet, hilfe wilkommen)

Eine andere problematik ist der audiopegel des senders. Wenn man da übersteuert kommt unten nix vernünftiges an. Die audiopegel der mic eingänge sind im mv bereich, d.h. faktor 1000 unter dem was das modem liefert.

... essenszeit ...
 
Zuletzt bearbeitet:

QuadMax

Erfahrener Benutzer
#13
Falls ich es morgen schaffe, klemme ich mal das Oszi dran und poste Bilder. Ist ja nur aus Zeile drei das // zu entfernen?!?
Oder soll ich noch was testen und dokumentieren?
Hobby betreibt man halt nur nebenbei und wenn die Zeit knapp ist, warten wir halt länger auf deine Antworten, mach dir da blos keinen Stress :).
 

cesco1

Erfahrener Benutzer
#14
zeile 3 von was?

Falls du die 1.1V vref meinst, das wäre "#define INTVREF". Dann nachmessen ob am arduino vref ausgang die 1.1V bereitstehen oder nicht .... falls nicht müsste man das extern generieren -> kompliziert.

Den besten audio eingangspegel des video senders muss auch getestet werden. Ich hab einen alten ATV sender mit "line in" verwendet, da geht 0.5 V PP. Aber die typischen FPV videosender haben "mic in" und das ist SEHR empfindlich. Muss man austesten. Unten sollte ein schöner runder sinus ankommen, wenn's ecken hat ist's übersteuert.

Zur datenrate:
Man will anfangs natürlich so schnell wie möglich so viele bytes wie möglich. Das ist problematisch, weil hohe datenrate = hohes SNR, niedrige datenrate = niedriges SNR. SNR = signal noise ratio, oder wie GUT muss mein signals sein um was zu empfangen.
Einfach ausgedrückt, 9600 baud braucht die 8-fache sendeleistung wie 1200 baud.

Deshalb habe ich vor nur gerade 1000 / 1200 baud zu verwenden.
 
Zuletzt bearbeitet:

QuadMax

Erfahrener Benutzer
#15
Der Franzose kommt mit 1200baud auf 2hz updaterate, das wäre ja mehr als genug, korrigiert mich, wenn ich das missverstanden habe.
Ich habe das gerade einmal mit dem Oszi nachgemessen.
Am Arduino stehen die 1.1 Volt bereit.
Am Empfänger messe ich allerdings nur Rauschen.
Dies kann mehrere Gründe haben:
1. Derjenige vor dem Gerät stellt sich zu doof an
2. Die 1.1 Volt waren für den Sender zuviel. ( Hoffentlich nicht ;)) Bild wurde aber weiterhin empfangen

Werde alles morgen wenn ich wach bin nochmal überprüfen.
 

cesco1

Erfahrener Benutzer
#17
Am Arduino stehen die 1.1 Volt bereit.
Gut, allerdings ist AREF bei meinen promini nicht herausgeführt :(

Am Empfänger messe ich allerdings nur Rauschen.
Die 1.1 Volt waren für den Sender zuviel.
Die 1.1V sollen ja nicht zum sender. Das ist beim empfänger die referenzspannung für den ADC.

Bei 1.1V MUSST du beim empfänger "#define INTVREF" drinhaben, bei 5V NICHT, sonst geht da gar nix. Bei 1.1V schaltung muss bei A3 0.55V anstehen, bei 5V schaltung muss A3 auf 2.5V sein.

Ich hab zwei bilder angehängt, eins beschaltung für 5V, eins beschaltung 1.1V interne referenz. Fur die R, besser 10K als die 1K hier.
 

Anhänge

Zuletzt bearbeitet:

cesco1

Erfahrener Benutzer
#18
Hier noch das schaltbild des senders.

Die R und C sind suboptimal, war aber gerade verfügbar. R sollte kleiner sein, C sollte grösser sein. Wichtig ist dass die 32khz unterdeückt werden UND dass kein grosser amplitudenunterschied zwischen 2000hz und 1000hz ton erkennbar ist.

Audio out wird durch den 30k / 1k spannungsteiler reduziert.

Beim sender MUSS "#define TX" drinstehen, beim empfänger NICHT
Auskommentieren mit "//#define TX" oder in "#define RX" abändern
 

Anhänge

Zuletzt bearbeitet:

cesco1

Erfahrener Benutzer
#20
Ich denke zwischen 1nf und 100nf. Ich bin da bei hardware nicht der profi ...

Der sender ist viel kritischer, da vom arduino pin ein starker 32khz träger kommt. Der muss ausgefiltert werden. Dabei sollten die 1000hz / 2000hz kompnenten aber erhalten werden.

Wie das aussieht:
gelb: was der arduino rauslässt.
blau: das durch 30kohm / 1nf gefilterte signal.
 

Anhänge

RCLogger

FPV1

Banggood

Banggood

Oben