Lieber Besucher, herzlich willkommen bei: RCLine Forum. Falls dies Ihr erster Besuch auf dieser Seite ist, lesen Sie sich bitte die Hilfe durch. Dort wird Ihnen die Bedienung dieser Seite näher erläutert. Darüber hinaus sollten Sie sich registrieren, um alle Funktionen dieser Seite nutzen zu können. Benutzen Sie das Registrierungsformular, um sich zu registrieren oder informieren Sie sich ausführlich über den Registrierungsvorgang. Falls Sie sich bereits zu einem früheren Zeitpunkt registriert haben, können Sie sich hier anmelden.

21

Montag, 22. Oktober 2007, 15:48

Ähem, wenn du was verbessern willst, also echt verbessern, dann spendiere deinem Empfänger eine bessere Antenne. :)
Mit dem Sender wirst du auch ohne bessere Antenne die Leistungsreserven voll ausschöpfen können.
Beim Empfänger geht es um jedes µV das man von der Antenne geliefert bekommt und nur was man von der Antenne bekommt kann man auch verstärken. :D
"Die Deutsche Rechtschreibung ist Freeware, du kannst sie kostenlos nutzen. Allerdings ist sie nicht Open Source, d.h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen."
Quelle: GBO

22

Montag, 22. Oktober 2007, 19:42

na, jetzt verstehe ich nurnoch Bahnhof :dumm:
Benni

^____

RCLine User

  • »^____« wurde gesperrt

Wohnort: anonymisiert

Beruf: anonymisiert

  • Nachricht senden

23

Montag, 22. Oktober 2007, 20:32

Hallo Don,

Was Du sagst gilt sowohl für die Empfänger- und Senderantenne gleichermassen.
Es spielt keinerlei Rolle ob Jemand bei einem Schwerhörigen schreit, oder ob man bei einem welcher gut hört nur flüstert. Man muss sich verstehen!

Gruss Bruno

24

Montag, 22. Oktober 2007, 20:45

Bruno,
prinzipiell hast du recht.
Ich sehe da aber hier einen kleinen Unterschied. Insb. im Modellbau hast du immer eine feste und eine bewegliche Komponente. Die bewegliche aendert staendig ihre Lage. Die "feste" auch, aber das ist halbwegs kontrollierbar.
Wie Wurpfel es schon vor Jahren gezeigt hat ist allleine schon durch eine bessere Empfaengerantenne einiges rauszuholen.
Ich sehe hier bei den Antennen noch einiges an Verbesserungspotential.
Ja, auch auf Senderseite. Aber irgendwie doch ein bisschen mehr beim Empfaenger.

Aber das war jetzt alles nicht wirklich Topic dieses Threads. Sollte woanders diskutiert werden.
Gruss
Thomas

🖖
So long, and thanks for all the fish.


Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

25

Montag, 22. Oktober 2007, 21:38

Hallo Marc, das sieht ja auch schon richtig super aus dein Projekt :ok:

Deine Reichweitenerfahrungen decken sich ja mit den Tesflügen der Akamodell.
Mit welcher Sendeleistung betreibst du die XBEE ?

Die wesentlichen Softwarefunktionen hast du ja bereits geproggt.
Würdest du deine bisherigen Projektstand zur Verfügung stellen?


Ich versuche mich gerade an der PPM Auswertung (AVR Studio) und stelle mir gerade die Frage wie ein PPM12 Frame ausschaut?
Ist der gegenüber dem PPM8 einfach nur um 4 Kanalimpulse verlängert, so dass sich der gesamte Frame auf ~30ms (4*2ms) verlängert?

Thomas
Gruß

Thomas

26

Dienstag, 23. Oktober 2007, 08:39

Hallo,

@Space:
Die Testflüge der Akamodell sind von mir gemacht :D (wie auch die anderen elektronischen Spielereien auf der Seite)
Gleiches System, gleiche Sendeleistung, 10mW. Nur unten ein Computer...

Meine Software ist zur Zeit noch ein ziemlich unübersichtlich gecodeter Haufen mit etlichen "entliehenen" Teilen...
Bevor ich die ganz veröffentlichen könnte, muss noch ordentlich geputzt werden.
Kann aber schauen, ob ich vielleicht die wesentlichen Funktionen zur Kommunikation mit dem XBee mal rausnehme. Wenn spezielle Fragen sind, einfach her damit...

Das verwendete Protokoll bring ich mal in lesbare Form und stelle es hier rein. Sollte nicht zu lange dauern.

PPM-Auswertung habe ich hier eine gute Vorlage gefunden: http://ulrichradig.de/ was PPM12 angeht muss ich leider passen.. Messen oder googeln...

zum Thema Antennen:
Wie es Thomas sagt, muss man die Anforderungen an die Antennen bei Sender und Empfänger unterscheiden. Beim Sendet kann ich eine Antenne nehmen, die eine Richtwirkung hat, da ich davon ausgehe, dass ich das Modell in Blickrichtung und den Sender vor dem Bauch habe.
Beim Empfänger möchte ich eine möglichst kugelförmige Empfangscharakteristik, da sich das Modell ja in jeder Lage befinden kann, also kann man hier nicht viel mit Antennengewinn machen. Mein nächster Versuch am Empfänger wird wohl eine am Ende gestrippte Koaxleitung sein (deshalb werde ich demnächst auch Module mit Steckanschluss kaufen.

Grüße

Marc

wurpfel1

RCLine User

Wohnort: CH-rheintal

  • Nachricht senden

27

Dienstag, 23. Oktober 2007, 12:12

Hi Leutz


ihr macht sachen :ok:


ich wette dass ihr genau auf die gleichen probleme stösst die ich bereits gelöst habe :shy:
bin gespannt wie ihr das macht.




viel spass :evil:




PS
ich nutze alle vorteile die ein hierrarchisch struktuiertes protokoll bietet und spare dadurch bandbreite für telemetrie.
besonders das automatische proggen empfinde ich als sehr praktisch. es reicht eine routingtabelle auszutauschen, fertig..
dieser ansatz ist komplett unabhängig von der funkstrecke: sind neue module erhältlich muss nur etwas inizialisierung geändert werden.
ein struktuiertes protokoll ermöglicht auch das modularisieren/aufteilen auf verschiedene mittäter :w

eigentlich reichen ATt15 aus. ich habe im sender wie im modell die gleiche hardware, nur etwas unterschiedlich programmiert :shy:
C wäre natürlich schon professioneller, nur schafft BASCOM die etwa 120zeilen code mit links.
bin schon zu alt zum spielen.. macht aber gleichwohl spass ;-)

28

Dienstag, 23. Oktober 2007, 13:42

Zitat

Original von B. Eberle
Hallo Don,

Was Du sagst gilt sowohl für die Empfänger- und Senderantenne gleichermassen.
Es spielt keinerlei Rolle ob Jemand bei einem Schwerhörigen schreit, oder ob man bei einem welcher gut hört nur flüstert. Man muss sich verstehen!

Gruss Bruno


Nein!

Ich erreiche die 10mW EIRP spielend mit der kurzen Gnubbelantenne am Sender. Klar kann ich eine Antenne mit höherem Gewinn anbauen. Dann muß ich aber die Sendeleistung so weit runterschrauben das ich wieder bei 10mW EIRP ankomme.

Der Empfänger sollte aber so gut wie nur irgend möglich hören können. Wenn möglich so gut das er das Gras wachsen hört.
"Die Deutsche Rechtschreibung ist Freeware, du kannst sie kostenlos nutzen. Allerdings ist sie nicht Open Source, d.h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen."
Quelle: GBO

29

Dienstag, 23. Oktober 2007, 14:56

Protokoll

Hallo,

hier mal kurz der Aufbau des Protokolls. (jede Bezeichnung entspricht einem Byte)

Die erste Ebene ist das, was der Sender als Inhalt erzeugt:

ID; Servo1; Servo2; Servo3; Servo4 (kurz DATA)
ID=1: "normale" Fernsteuerdaten
ID=2: neue Failsafe-Position

Die Subroutine erzeug daraus folgendes Paket:

0x7E; lenghth; lenghtl; 0x01; 0; desth; destl; 0x01; paknum; DATA; CS
^^^ Alles das sind Befehle fürs XBee ^^^^^^^ Paketnummer Checksumme

Der Rückkkanal funktionier genauso, hier ist aber DATA:
ID; RSSI; lostpackets; delaytime

ID=5: Rückmeldung von empfangenen Daten
ID=6: Rückmeldung kein Empfang

So funktioniert das System soweit, wie gesagt fehlen noch die Sachen Binden und Kanalwechsel. Da steckt auch noch einiges an Arbeit drin (Wie sieht es denn damit z.B. bei Kollege Wurpfel aus?)

Nochmal Antenne: Bitte beachten, dass auch der Empfänger sendet und dass die Abstrahlung möglichst Kugel sein soll... Also auch hier nix mit viel Gewinn...

Grüße

Marc

30

Dienstag, 23. Oktober 2007, 15:11

RE: Protokoll

Zitat

Nochmal Antenne: Bitte beachten, dass auch der Empfänger sendet und dass die Abstrahlung möglichst Kugel sein soll... Also auch hier nix mit viel Gewinn...


Hmm, das ist jetzt ein bisschen philosophisch. Die Hauptaufgabe des Empfängers ist empfangen der Fernsteuersignale und selbst wenn der Sender schon lange keine Rückmeldungen mehr entziffern kann sollte der Empfänger dort eine kleine aber möglicherweise wichtige Sicherheitsreserve haben.
Das wir weder mit der kurzen Gnubbeltenne noch mit der Langtenne eine ideal kugelförmige Abstrahlcharakteristik haben dürfte klar sein.
"Die Deutsche Rechtschreibung ist Freeware, du kannst sie kostenlos nutzen. Allerdings ist sie nicht Open Source, d.h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen."
Quelle: GBO

^____

RCLine User

  • »^____« wurde gesperrt

Wohnort: anonymisiert

Beruf: anonymisiert

  • Nachricht senden

31

Dienstag, 23. Oktober 2007, 16:59

Hallo Don,

Klar, sollte der Empfänger eine hohe Empfindlichkeit und eine niedere Rauschzahl haben. Am Verhältnis ändert sich aber trotzdem Nichts.

Gruss Bruno

wurpfel1

RCLine User

Wohnort: CH-rheintal

  • Nachricht senden

32

Dienstag, 23. Oktober 2007, 18:02

Hi Marc


nutzt man zb ein WLAN oder BLUETOOTH können dank fetter bandbreite die servoinfo direkt zu den knoten geroutet werden. verwendet wird dann eine IP-adresse (vier Bytes) die ein modell bis in die hinterste ecke funktionell beschreibt und die sollposition mit 16bit überträgt.


leider bieten datenmodems wie das XBEE oder IR nicht diese bandbreite.
nach etwas rumtesten habe ich mich für eine kompression auf fünf Bytes entschieden.
ich setzte PPM einer analogen anlage (zb. meine MC12) in ein fünf Byte steuerwort um und übergibts dem XBEE im APImode.

das XBEE ergänzt das mit einer präambel, der adresse der gegenstelle, anzahl der übertragenen bytes und einer prüfsumme. es sind immer gleichviele Bytes!


im modell prüfe ich zuerst die anzahl Bytes die empfangen wurden, sonst wird das frame verworfen.
nun legt man die fünf bytes im SRAM ab und ergänzt sie mit einer adresse aus einer routingtabelle. das resultat wird auf dem I2Cbus verbreitet.
busknoten mit der passenden adresse setzen nun die zahl in entsprechende impulse für die servos um.

nun pollt der master die sensorfarm inkl. statusmeldung der busknoten, versieht sie mit einer adresse und übergibt das dem modellXBEE zum runtersenden.

am boden routet der master die telemetrieinfo ans entsprechende modul, das stellt dann diese daten in einem fenster dar oder/und loggt sie im openformat auf die SDcard.





ohne hierrachisches protokoll müsste für jeden sensor, für jeden mischer, für jede netzwerktopologie und für jeden funkmodultyp spezielle SW geschrieben werden: genauso wie in DOSzeiten :D

dazu fehlt mir die zeit, ich nutze darum eine art abstraktionslayer. damit kann die HW immer gleich angesprochen werden, einzig die anbindung an den I2Cbus ist HWspezifisch..
die darstellung der info erfolgt ebenso über "genormte" aufrufe.
man wählt zb höheanzeige mit vier stellen oben links, um den rest kümmert sich im hintergrund die SW.



wenn von PPMsampling ausgegangen wird kommen noch mindestens vier schalter/poties/taster des 2G4interfaces hinzu. es sind vier hauptfunktionen und beliebig viele zusatzfunktionen mit einer garantierten latenz möglich. es können innerhalb einer frame und abhängig der netzwerktopologie beliebig viele servos bedient werden.




das paaren/binden erfolgt simpel durch setzen der ziel-MAC.
ein kleines skript zwingt beim konfigurieren das XBEE in den programmiermode, setzt die ziel-MAC und die leistung auf 10mW,...., zuletzt stellt man den APImode an.
jedes XBEE besitzt eine hardware 64bit-MAC. die liest man zb mit den CTUtool aus oder man lässt ein ZIGBEE-netzwerk aufzubauen und extraiert die MAC der partner...



EDIT
failsafe löst man besser in HW, jeder prozzi besitzt einen "wachhund" der absolut zuverlässig seinen job macht: er läuft zb 300ms, dann startet er den prozzi mit einer definierten einstellung neu: zb der FAILSAFEeinstellung :D

der watchdog wird durch empfang gültiger frames neu gestartet (und so gelöscht), der failsafefall ist simpel das ausbleiben von gültigen frames.
das hauptprogramm versucht unabhängig davon gültige frames zu finden..

die failsafestellung wird beim einstellen des modells ins EEPROM gebrannt.
bin schon zu alt zum spielen.. macht aber gleichwohl spass ;-)

Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von »wurpfel1« (23. Oktober 2007, 18:24)


33

Mittwoch, 24. Oktober 2007, 10:35

Hi Wurpfel,

ich versuche mal zusammenzufassen, was wir gleich und unterschiedlich machen. Erstens um zu sehen ob ichs kapiert habe und dann, um auch mit allen vielleicht weiter zu kommen.

Zitat

ich setzte PPM einer analogen anlage (zb. meine MC12) in ein fünf Byte steuerwort um und übergibts dem XBEE im APImode. das XBEE ergänzt das mit einer präambel, der adresse der gegenstelle, anzahl der übertragenen bytes und einer prüfsumme. es sind immer gleichviele Bytes!


Ok, da entspricht sich das Verfahren ungefähr (und auch die MC12 :tongue: ) , nur, dass ich keine Kompression auf die Kanäle anwende sondern sie einfach als 8bit-Wert hochschicke.
Was mich wundert ist der zweite Satz. Welchen API-Befehl benutzt du zum senden? Ich schreibe in jedem API-Frame die Empfängeradresse und Länge selbst rein (siehe Beispiel oben)

Zitat

im modell prüfe ich zuerst die anzahl Bytes die empfangen wurden, sonst wird das frame verworfen.

Ähnlich, mein Programm wartet bis die im API-Frame stehende Länge erreicht ist und fängt dann mit der Auswertung an, so kann ich auch verschiedene Längen verarbeiten.


Zitat

nun legt man die fünf bytes im SRAM ab und ergänzt sie mit einer adresse aus einer routingtabelle. das resultat wird auf dem I2Cbus verbreitet.

Ablegen ja, dann aber direkte Ausgabe an Servos. Sollte ja erst mal ein simpler Empfänger werden. Ausgabe über Busse natürlich machbar..

Zitat

Telemetrie...

Bis auf das runtersenden der Empfansfeldstärke noch nichts implementiert, wollte als Standardfunktion noch die Empfängerakkuspannung einbauen, dann optional auch einen Bus..
Das mit dem schreiben auf SD ist natürlich nobel... Über Atmega8 und die verfügbaren Codes?

Zitat

...für jeden funkmodultyp spezielle SW geschrieben werden...

Um ein bisschen Coden für ein neues Modul wird man nicht rumkommen... Dass das eigentliche Protokoll davon nichts mitbekommen soll, ist klar.

Zitat

das paaren/binden erfolgt simpel durch setzen der ziel-MAC....die liest man zb mit den CTUtool aus oder man lässt ein ZIGBEE-netzwerk aufzubauen...

An dieser Stelle sollte man vielleicht nochmal rangehen. Zum experimentieren hab ich natürlich auch die Adressen fest einprogrammiert. Meine Idee war, dem Sender einen "Pairing-Mode" zu geben, in dem er dann auf Broadcast-Frames hört und daraus die Ziel-Mac ausliest. Dann Speicherung im EEPROM, fertig.
Programmiermode sollte auch nicht nötig sein (dauert auch immer 1s, oder?), das lässt sich alles über API-Frames machen.

Zitat

Failsafe

Den Watchdog habe ich bewusst noch nicht eingesetzt, da er am Anfang teilweise Programmierfehler kaschiert... Kommt ganz zum Schluss rein. Bei mir läuft aber auch ein Zähler im Hintergrund, der bei Überlauf das Failsafe aktiviert und von den Empfangsroutinen (gültiges Frame) zurückgesetzt wird.

Grüße

Marc

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »FunFlightMarc« (24. Oktober 2007, 10:37)


wurpfel1

RCLine User

Wohnort: CH-rheintal

  • Nachricht senden

34

Mittwoch, 24. Oktober 2007, 17:26

Zitat

Original von FunFlightMarc
Hi Wurpfel,

ich versuche mal zusammenzufassen, was wir gleich und unterschiedlich machen. Erstens um zu sehen ob ichs kapiert habe und dann, um auch mit allen vielleicht weiter zu kommen.

Zitat

ich setzte PPM einer analogen anlage (zb. meine MC12) in ein fünf Byte steuerwort um und übergibts dem XBEE im APImode. das XBEE ergänzt das mit einer präambel, der adresse der gegenstelle, anzahl der übertragenen bytes und einer prüfsumme. es sind immer gleichviele Bytes!


Ok, da entspricht sich das Verfahren ungefähr (und auch die MC12 :tongue: ) , nur, dass ich keine Kompression auf die Kanäle anwende sondern sie einfach als 8bit-Wert hochschicke.
Was mich wundert ist der zweite Satz. Welchen API-Befehl benutzt du zum senden? Ich schreibe in jedem API-Frame die Empfängeradresse und Länge selbst rein (siehe Beispiel oben)

im APImode macht das XBEE sowas automatisch: BYTES anliefern, senden auslösen, rattar-ratter, kommt oben an ;)

Zitat

im modell prüfe ich zuerst die anzahl Bytes die empfangen wurden, sonst wird das frame verworfen.

Ähnlich, mein Programm wartet bis die im API-Frame stehende Länge erreicht ist und fängt dann mit der Auswertung an, so kann ich auch verschiedene Längen verarbeiten.

da ich immer fünf Bytes sende höre ich nach dem prüfen auf wenn da keine fünf steht!


Zitat

nun legt man die fünf bytes im SRAM ab und ergänzt sie mit einer adresse aus einer routingtabelle. das resultat wird auf dem I2Cbus verbreitet.

Ablegen ja, dann aber direkte Ausgabe an Servos. Sollte ja erst mal ein simpler Empfänger werden. Ausgabe über Busse natürlich machbar..


mich nerven meterlange servokabel, WEG damit!
ich verwende auch gerne I2C-servos, dh die analogtechnik fliegt raus und wird durch OPENSERVO-SW ersetzt. so können die servos DIREKT angesprochen werden und liefern zb die servohebelstellung zurück.

das routen ist eine folge der komprimierung, die routingtabelle repräsentiert das modell, bzw sie IST das modell..



Zitat

Telemetrie...

Bis auf das runtersenden der Empfansfeldstärke noch nichts implementiert, wollte als Standardfunktion noch die Empfängerakkuspannung einbauen, dann optional auch einen Bus..
Das mit dem schreiben auf SD ist natürlich nobel... Über Atmega8 und die verfügbaren Codes?

die RSSI wird vom XBEE direkt als PWM ausgegeben. da sie OBEN immer besser ist als unten werte ich die am boden aus.. wozu übertragen?


Zitat

...für jeden funkmodultyp spezielle SW geschrieben werden...

Um ein bisschen Coden für ein neues Modul wird man nicht rumkommen... Dass das eigentliche Protokoll davon nichts mitbekommen soll, ist klar.


es ist ne riesensache für jedes kackservo und für jeden schrumpfsensor eigene auslese-, übertragungs- und darstellungsroutinen zu schreiben.
der output in einem vierbyte-wort darzustellen ist dagegen eine simple fingerübung..


Zitat

das paaren/binden erfolgt simpel durch setzen der ziel-MAC....die liest man zb mit den CTUtool aus oder man lässt ein ZIGBEE-netzwerk aufzubauen...

An dieser Stelle sollte man vielleicht nochmal rangehen. Zum experimentieren hab ich natürlich auch die Adressen fest einprogrammiert. Meine Idee war, dem Sender einen "Pairing-Mode" zu geben, in dem er dann auf Broadcast-Frames hört und daraus die Ziel-Mac ausliest. Dann Speicherung im EEPROM, fertig.
Programmiermode sollte auch nicht nötig sein (dauert auch immer 1s, oder?), das lässt sich alles über API-Frames machen.


willst du wirklich wärend des fluges das modul tauschen???
im APImode geht das setzen sofort..
ich frage mich zudem ob ich bald nur noch im ZIGBEEnetzwerk fliegen möchte: die verbesserte ausleuchtung dunkler funkecken ist recht attraktiv ;)


Zitat

Failsafe

Den Watchdog habe ich bewusst noch nicht eingesetzt, da er am Anfang teilweise Programmierfehler kaschiert... Kommt ganz zum Schluss rein. Bei mir läuft aber auch ein Zähler im Hintergrund, der bei Überlauf das Failsafe aktiviert und von den Empfangsroutinen (gültiges Frame) zurückgesetzt wird.


ich weiss nicht welchen debugger du verwendest.. ich fliege mit getesteten programmen :D
ein watchdogreset ist aber sehr viel einfacher herauszufinden/zu zählen als mit dem spaten nach den auswirkungen eines SWhängers zu graben.




Grüße

Marc



upps, die quoterei sollte ich noch üben :angel:
bin schon zu alt zum spielen.. macht aber gleichwohl spass ;-)

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »wurpfel1« (24. Oktober 2007, 17:27)


35

Mittwoch, 24. Oktober 2007, 22:39

Hallo,

die Postings werden länger, es werden weniger...
An die Runde: Wohin soll es gehen?

Zitat

OBEN immer besser ist als unten

nicht immer: http://www.uni-stuttgart.de/akamodell/pr…agrammflug3.jpg
Ausserdem möchte ich noch die Paketverluste des Uplink wissen, der ist relevant.

Zitat

willst du wirklich wärend des fluges das modul tauschen

Nein, Es geht drum, wie man z.B. einen neuen Empfänger an den Sender anbindet, ohne an den PC zu gehen. Es soll doch um eine einfach zu verwendende Anlage gehen. Spielerein können wir uns immer noch einbauen :D

Zitat

welchen debugger

Im jetzigen Stadium debugge ich in der Hardware, da kein Debugger auf dem Rechner die ganze Hardware simulieren kann (wenn er nicht mehrere 100€ kost...). Wenn du da natürlich eine Alternative hättest: Her damit 8(

Bis dann

Marc

Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

36

Donnerstag, 25. Oktober 2007, 00:13

Zitat

Original von FunFlightMarc
An die Runde: Wohin soll es gehen?

Recht hast du mit dieser Frage.
Das Ziel des Threads ist eigentlich, daß etwas praktisch einsetzbares unten rausfällt.
Leider versumpft der Thread in Detailthemen, ohne das die Basics (z.B. die Schaltung) überhaupt praktisch angegangen werden. Vielleicht sollte man den Thread trenne in eine teoretischen und einen praktischen Thread?

Wenn ich mal zähle, so komme ich auf 3 Personen hier im Thread, welche praktisch bereits Erfolge erziehlt haben.
Leider hat bisher keiner seinen Entwicklungsstatus mal aufgearbeitet und hier seine Ergebnisse dargestellt. ==[] Andersrum hält es mich auch davon ab, Gehirnschmalz in die notwendigen Basissoftwareroutinen hineinzustecken, wenn ich weiss das diese bereits mehrfach auf den Festplatten von andern schlummern.

Es währe toll wenn die wesentlichen Softwaremodule...

-PPM Auswertung
-Servoimpuls Generierung
-Frame Generierung
-XBEE Intialisierung und laufenden Kommunikation

...von einzelnen hier im Thread als "ihr" Detailthema aufgegriffen wird eine Lösung erarbeitet und dargestellt wird. Also, wer macht was....?

Ich werde Morgen mal anfangen mit Eagle zu malen....


Thomas
Gruß

Thomas

37

Donnerstag, 25. Oktober 2007, 00:26

Moin Marc,

womit programmierst du denn? Der Debugger in Atmels AVRStudio ist sehr gut und universell einsetzbar. Man kann damit sogar BASCOM-Progs debuggen. :D

Binding kannst du dir so komplex machen wie du willst.
Legst du im Empfänger die Kennung des Senders ab dann kannst du mehrere Empfänger an einen Sender gleichzeitig binden solltest aber Vorkehrungen treffen um zu verhindern das du mit dem falschen Modellspeicher fliegst. Legst du die Kennung des Empfängers im Sender ab dann kannst du zwar einfach verhindern mit dem falschen Modellspeicher das falsche Modell zu steuern aber du kannst nicht mehr einfach den Empfänger tauschen bzw. mehrere Empfänger für das gleiche Modell an den selben Sender binden.
Möglich ist auch noch eine kombinierte Lösung.
Aber das ist deine Entscheidung.

Grüße,

Stephan
"Die Deutsche Rechtschreibung ist Freeware, du kannst sie kostenlos nutzen. Allerdings ist sie nicht Open Source, d.h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen."
Quelle: GBO

38

Donnerstag, 25. Oktober 2007, 00:42

Lieber Space,

es ist leider so das die wenigsten Menschen völlig genial sind. Dummerweise sind wir anderen nichtgenialen Menschen dazu gezwungen eine von vielen Zielannäherungsstrategien zu wählen. Entweder "bottom up", "top down" oder von beiden Seiten gleichzeitig. Interessanterweise haben ein paar clevere Menschen später herausgefunden das man trotzdem erst mal einen groben Plan haben muß wohin es gehen soll, dann muß man wissen wie man Detaillösungen angeht und dann muß man aus diesem Rahmen und den Füllsteinen ein komplexes stimmiges Gebilde schaffen welches sich so weit wie möglich den selbst gesteckten Zielen annähert. :D

Klar kannst du anfagen zu malen, nur, weißt du denn schon was? Wird das dann deine private Insellösung oder wird das etwas Allgemeines oder löst du jetzt nur ein spezielles Problem?

So wie ich das sehe haben Wurpfel, Marc, möglicherweise du und auch ich sehr unterschiedliche Annschauungen und Lösungsansätze und ich denke erst die Praxis wird zeigen was sich durchsetzen wird.

Grüße,

Stephan
"Die Deutsche Rechtschreibung ist Freeware, du kannst sie kostenlos nutzen. Allerdings ist sie nicht Open Source, d.h. du darfst sie nicht verändern oder in veränderter Form veröffentlichen."
Quelle: GBO

wurpfel1

RCLine User

Wohnort: CH-rheintal

  • Nachricht senden

39

Donnerstag, 25. Oktober 2007, 00:44

Hi Marc

empfängertauschen geht ohne PC und klickmichbunti..

sender in konfig-mode (zwei knöpfe gleichzeitig drücken)
menüpunkt netzwerkaufbauen wählen (scrollen, knopf drücken)
etwa eine sec warten, eine liste wird angezeigt
nun einen neuen partner aussuchen (scrollen, knopf drücken)
bestätigen (nochmels zwei knöpfe gleichzeitig drücken)
fertig :D


alternativen :angel:
man kann auch eine liste mit der MAC der vereins-funkmodule abspeichern, zb im EEPROM des TXbusmaster.. oder in einem I2C-EEPROM zum anstecken!

will man das modell des kumpels steuern steckt man seinen dongle in den sender, schon funzt es.. für LS benötigt man dann zwei stück :w
oder man nimmt einen IRtransceiver und eine ordinäre glotzenfernbedienung bzw ein händy und tippt die MAC ein :evil:



bis jetzt komme ich mit vier knöpfen aus, das butterfly hat fünf..
im flugbetrieb stehen diese knöpfe zb zur flugphasenauswahl zur verfügung.
die kamikazes unter uns können sich zum RXswapen auch HOTKEYs anlegen :shake:
die knopfanzahl des senders ist ja nicht begrenzt..




debuggen tue ich ganz konventionell: nachschauen was in den registern so abgeht. ein buskonzept ist hier recht angenehm, es sind nur drei register :shy:





edit
nachtschwärmerverein ;)

PPM und servoimpulsgeneration ist im RCL-anfängerkurs breit erklärt worden.
TIP: ein timer wird mit einem wert aus einem register per ISR geladen.
jeder AVR mit zwei timer kann benutzt werden.
der I2Cbusmaster kann auch nur einen timer besitzen (zb ATt13), guckt mal die AVR 300

mein hardwaredesign ist eher simpel: ATt15 plus ein kondensator und ne steckerleiste... ein fall fürs heisskleberdesign :nuts:
einige busknoten besitzen optokoppler und ein eigenes BEC. ca 2x1cm lochrasterplatine ist völlig ausreichend falls es nicht zwischen den füsschen platz hat oder optische vorlieben bestehen.
SMD wäre natürlich nett, leider ist eine vierfachsteckerleiste nicht verleinerbar bzw genau so gross wie ein ATt15 :shy:


XBEE-kommunikation kann im manual nachgelesen werden, hier lohnt es sich GENAU an die vorgaben zu halten :) APImode darf man bevorzugen..


was übertragen werden könnte ist hier auch schon öfters breitgeschlagen worden...
bin schon zu alt zum spielen.. macht aber gleichwohl spass ;-)

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »wurpfel1« (25. Oktober 2007, 01:03)


Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

40

Donnerstag, 25. Oktober 2007, 09:33

@Stephan

Zitat

Original von sidigonzales
Interessanterweise haben ein paar clevere Menschen später herausgefunden das man trotzdem erst mal einen groben Plan haben muß wohin es gehen soll, dann muß man wissen wie man Detaillösungen angeht und dann muß man aus diesem Rahmen und den Füllsteinen ein komplexes stimmiges Gebilde schaffen welches sich so weit wie möglich den selbst gesteckten Zielen annähert. :D

Das Vorghehen ist wie von dir angeführt grundsätzlich so richtig.
Jedoch kann man deine Privatdiskusion mit Wurpfel hier in diesem Thread damit vergleichen, das hier die Inneneinrichtung für ein neues Autos geplant wird, jedoch das Auto noch nicht erfunden ist.

Die Prämissen des Threads:

Zitat

Ich möchte mit diesem Thread einen anderen Ansatz anstossen, eine gemeinschaftliche Eigenentwicklung.
Hierbei ist das vorrangige Ziel, die vorhandenen 35MHz Modul in unseren Fernsteuersender gegen ein 2,4GHz Modul auszutauschen und eine sichere Übertragung zu etablieren. Wohl aber sollte hierbei schon ein Augenmerk auf universelle Auslegung des Übertragungprotokolls geachtet werden.
Ist dieses erste Ziel erreicht, kann man über Funktionserweiterungen oder grundsätzliche andere Konzepte nachgedacht werden.


Themen wie Openservo über I2C und über die Abtrahlcharakterisiken von Antennen und der Rauschzahl von Empfängern, haben in diesem Thread nichts verloren und lasen den Thread schnell versanden.
Der Satz von Marc beschreibt dies am besten:
"die Postings werden länger, es werden weniger..."


Gesetzt ist XBEE und und herkömmliche Servotechnik.

Zitat

Aufgrund des Verlaufs des Standartisierungsthreads die Aufforderung:
Bitte lasst uns nun nicht gleich in detailierte technischen Diskussionen verstricken, sondern bitte erstmal nur eine eure Zu- oder Absage an der der aktiven Mitarbeit des Projektes bekunden

Die Zu/Ab-Sage leigt mir von Wurpfel und dir nicht vor. Mitgestalten wollen geht nur, wenn man auch praktische Verantwortung übernimmt. :shake:
Gruß

Thomas