CrazyDiversity - Ein Projekt im Entstehen

[fofi1]

Hallo ihr da draussen,

nun fange ich mal an ein bisschen was zu dokumentieren.

>Was ist das?
Das wird ein Diversity mit einer Master-Slave Architektur. Das soll heissen, es gibt einen zentralen Master der alles steuert und die Slaves reden nur wenn sie gefragt werden. Durch ein offenes Protokoll soll das Projekt andere Bastler dazu anregen neue Bausteine zu entwickeln, wie Tracker, Analyser usw.

2 Kanal Diversity(Software Master)--------------LCD mit Drehencoder (Software Slave)------------optional zweites Diversity oder Tracker (Software Slave)------------usw.


>Heisst das ich kann unendlich viele Diversity Kanäle haben
Nein, irgendwann ist der Master oder der Bus zu langsam. Aber es lassen sich damit locker bis zu 10 Kanälen realisieren.



>Wirst du den Code für den Master und den Slave veröffentlichen?
Nein, erstmal nicht. Der Code ist in bascom geschrieben und wird den meisten Usern hier nichts sagen, da sie nur Arduino beherrschen. Das Protokoll wird aber dokumentiert, damit Erweiterungen entwickelt werden können.

>Wie teuer wird das ganze?
Wunder punkt...ganz wunder Punkt...
Ich habe das ganze für mich entwickelt, daher hab ich jedliche Preisoptimierung umgangen. Die Die Grundkonfiguration (Slave und 2er Diversity) liegt so im 150er Bereich mit allen Bauteilen und Gehäuse. Sollte aber Hobbybastler nicht abschrecken und da ich die Schaltpläne veröffentliche kann jeder gerne neue Platinen mit günstigeren Teilen Layouten.

 

[fofi1]

So, dann fange ich mal mit dem Slave an.
Der Slave hat ein DOG-M LCD drauf. Dieses wird via SPI befeuert. Dann hat er noch viele Optionale Sachen drauf, das ist für spätere Erweiterungen gedacht und wird erstmal nicht bestückt.

Hier der Schaltplan:

http://files.brauchmer.net/imghost/up/5068cb7215e35953474c2b610d560c62.png



Soooo und nun gehts Tagebuchmässig weiter:

4.05.2013 EA DOG-M Routinen geschriebn
Nach Knapp 20 Stunden hab ichs nun fertig. Das DOG-M LCD hat seine eigenen befehle bekommen. Warum so lange? Das scheiß Ding ist sowas von schlecht dokumentiert! Das Original Datenblatt kann man vergessen. Wenn man den LCD-Controller googelt findet man dann das passende: ST7036. Naja, die Wartezeiten beim Init sind mehr als falsch im Datenblatt. Das Ding braucht oftmals doppelt so lange wie beschrieben. Wenn dann ein Befehl zu schnell kommt läuft das ganze LCD logischerweise Amok. Gut also erstmal Logicanalyser ausgepackt und angeschaut ob der uC alle Zeiten einhält. Ja das tut er! Soweit so gut, dann habe ich die Wartezeiten etwas erhöht und siehe da es geht! Ob ihrs glaubt oder nicht, das hat mich die gestrige Nacht und den ganzen Tag heute gekostet.

 

[Nabazul]

coole sache! Hab aber noch nicht so ganz verstanden wie du dein Diveristy realisiert hast. Auswertung über RSSI oder Videoqualität? Oder beides ?

Beim Open Diversity Receiver hab ich auch ein DOG-M Lcd verwendet für Arduino gibts da schon ne fertige Lib hätte dir vlt einiges an Arbeit erspart :-/

 

[Kayle]

Hallo,

sehr sauber aufgebaut. Gut gemacht. Ich als BASCOM Jünger kann verstehen warum Du Bascom und nicht Arduino einsetzt. Ich kann mich mit Arduino auch nicht 100% anfreunden ( auch wenn es dort für jeden sch... eine Library gibt )

Gruß Kayle

 

[jreise]

Na, dann bin ich mal gespannt. Bitte weiter berichten .

Geh ich recht in der Annahme, dass das Ding, wenn's mal fertig ist (wer definiert "fertig" ?), zur Nutzung auf dem Flugfeld eigentlich viel zu schade und vorrangig zur Befriedigung der niederen Bastlertriebe entstanden ist?

 

[fofi1]

@ Nabazul: Ja, die Auswertung erfolgt über RSSI und Videoqualität. Arduino ist für mich zu "closed" , das heisst ich weiss nicht was die library im Hintergrund für Sachen treibt. Wenn die in Register schreibt, die ich auch benutze dann darf ich lange rätseln warum mein programm spinnt. Wenn sie einen Interrupt auslöst und mir so mein Hauptprogramm in einem kritischen Moment stoppt geht die Sucherei auch los usw. Da hab ichs lieber etwas transparenter. Ich nutze auch daher sehr ungern die Bascom Routinen und Code alles per Fuss.

@Kayle: Ja genau. Ich hab mit Bascom angefangen damals. GCC ist nun auch dabei und ein kleines bisschen Assembler auch. Im Gegensatz zur weitläufigen Meinung finde ich Bascom sehr gut, wenn man nicht unbedingt die internen Routinen benutzt.

@ Jreise: Fertig ists dank offener Schnittstelle hoffentlich nie . Es ist auf jeden Fall zu 20% eine Spielerei, also es sind Sachen drauf die man nicht unbedingt braucht, aber das betrifft eigentlich nur die optionalen Sachen die für später geplant waren oder für eine spätere Problemlösung . Der Bus dagegen ist zu 100% sinnvoll bis jetzt.
Also ich werde es auf jeden Fall aufm Flugfeld verwenden, da es dafür konstruiert wurde . Da ich redundant arbeiten könnte (und evtl werde) ist es mir lieber als eine "ein Chip Lösung". Aber es ist und bleibt eine Edel-Lösung

 

[fofi1]

So, das Menü ist fertig...hat aber auch lange gedauert. Menüstruktur geht jetzt TOP, braucht auch nicht allzu viel durchlaufzeit, aber immer noch viel zu viel. Da werd ich nochmal optimieren. Der Drehencoder ist etwas hakelig, dem muss ich nochmal ne Entprellungs-Routine aufs Auge drücken. Hier im Video sieht man das Menü:

http://www.youtube.com/watch?v=qox9TP_6KNw&feature=youtube_gdata

 

[sausarus]

is nur bei mir das video kurz nach anfang tonlos und schwarz?

 

[fofi1]

Zehn Zeichen

 

[fofi1]

Geht wieder. Rendereinstellung war bei Vegas falsch.

 

[fofi1]

So Leute,

ich hab fleissig am Code für das LCD gearbeitet und nun ist die V1 stabil und fertig. Das protokoll muss ich nochmal dokumentieren, aber es ist recht einfach aufgebaut:
<Adressbyte><Flagbyte><Datenbyte*10><CRC8>
Wenn länger als 10ms keine daten kommen und der Eingangs-zähler schon aus dem Nullzustand raus ist wird resettet. So werden Störungen abgefangen. Stimmen Adresse und CRC dann gelten die Daten als ok. Die Datenkommunikation ist scheißlahm und wurde eigentlich nur auf Erweiterungsfreundlichkeit ausgelegt, da werde ich vllt nochmal ran müssen.

Das LCD hat eine "begrenzte" Intelligenz. Soll heissen: Es zeigt auch ohne Master die Menüs an und man kann auch Eingaben machen, nur die variablen werden nicht aktualisiert. Erst wenn der Master sich meldet und als erstes die Daten aus seinem EEPROM (wie Akkuwarnschwelle usw.) schickt, dann lässt das LCD sich normal bedienen.

So...nun werde ich noch den Master programmieren und dann erhoffe ich mir mal einen schönen Praxistest. Bin vor allem auf die Mischung aus RSSI und Vsync gespannt.

 

[fofi1]

Sodala...kleines Update: Projekt komplett umgekrempelt. Wie es halt so ist merkt man nach dem ersten prototypen dass es anders besser geht. Das ganze Ding hat schon erste Testflüge gemacht, aber das bussystem war mir in der Softwarepflege zu anstrengen.
ALSO: Alles kommt auf eine Platte und bekommt einen einzigen prozessor. Basta! KISS-Prinzip hat gesiegt


Die Boardfiles gebe ich hier frei (Wie immer, nicht zur kommerziellen Verwendung) Falls jemand von den AVR-Bastlern ne Platine braucht (Das ist nämlich ein nettes Universalboard), dann soll er mir einfach ne Pn schreiben. Ich hab noch ein paar hier rumliegen. Die Platine wurde zum Glück nicht nur für das Diversity-projekt entwickelt.

 

[fofi1]

Hi Leute,

es ging noch laaaaaaaange mit dem Projekt weiter. Ich bin unterdessen bei der V4 und hab jetzt keine Lust mehr. Bis auf ein paar mechanikprobleme ist jetzt alles pefekt.

Wen es interessiert, für den hab ich hier nen Bericht verfasst : http://fpv-team.de/blog-aktuelles-news/entry/bauberichte/crazydiversity-v4

Sry dass ich das "auslagern" musste, aber ich kann nicht immer alles doppelt schreiben

 

[fofi1]

Was kann die V4 alles?
- 2 videoausgänge
- Videoverstärker
- Individuelle Empfängerplatinen, die über I2C adressiert werden
- bis zu 6 Kanal Diversity
- RSSI und V_SYNC auswertung
- DOGM-LCD mit Scrollrad zur intuitiven Bedienung
- Integrierter lüfter zur kühlung der Baugruppen
- lipo-Lade-IC zum direkten Laden des Lipos (zurzeit noch Probleme)
- 2200mAh 2S Akku für Brille und Diversity
- Alles in einem stabilen POM Gehäuse verbaut

 

[fofi1]

Servus,

ich hab derzeit noch mit folgendem zu kämpfen, deswegen steht auch das Projekt grade ein bisschen:

- die "neuen" RX5808 sind VIEL unempfindlicher als die alte Generation. Die Reichweite ist besch*ssen.
- das Lipolade-IC will den akku nicht über 80% laden. Da bin ich derzeit noch auf Fehlersuche. Da hab ich was falsch berechnet.
- der ADC hat gesponnen, weil ich die interne referenzspannung getötet habe, aber das habe ich nun endlich behoben.

Mfg,
Flo

 

[Kholdstare]

Hallo Flo

Sehr schönes Projekt! Eine Frage: was erhoffst Du Dir von R12?

edit: Zweite Frage: Hast Du eine CNC Fräse zuhause? Das Gehäuse hast aber sehr schön hinbekommen.

Gruss, Philipp

 

[fofi1]

Die Platine wurde universell gehalten. R12 wäre für die lawmate Empfänger. Bei denen muss man oft den Videopegel an die 50Ohm anpassen. Daher ist hier ein (unbestückter) R12 drinnen .

Ich habe leider nur eine normale Fräse daheim (die nun auch weichen muss, siehe biete thread), aber ich habe zum Glück in der Arbeit Zugriff auf eine CNC.

 

[Kholdstare]

Dann reden wir nicht vom selben R12, auf P1 im Diagramm steuerst Du damit den Summer über einen Transistor an, R11 ist 10K gleich vor der Basis.

 

[fofi1]

Achso, der alte Plan ! .

Also das war als (ewig großer) Pulldown für den Transistor vorgesehen, der aber nie bestückt wurde. Die Atmega Pins haben ja feste Pegel und daher kann den Transistor nichts stören. Die kurze Phase im init (wo er theoretisch über berührung oder umliegende teile durchschalten könnte, weil der der Pin auf Tristate ist) würde nichtmal reichen dass der Pieper richtig anschwingt.

War also unnötig...

 

[cnwund]

sehr interessantes Thema, das ganze. Wahnsinn was sich Leute selbst ausdenken! Super!