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.

Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

1

Freitag, 19. Oktober 2007, 00:01

2,4 GHZ RC-Line Eigenentwicklung

Die Diskussion und die Initiative zum genormten Datenprotokoll ist sinnvoll und richtig. Leider ist sie aber zu sehr in die Richtung „Was könnte man alles machen“ abgedriftet. Damit sind 95% aller Anwender, welche einfach nur eine sichere Fernsteuerung ihrer Modelle erwarten, abgehangen worden weil der Bedarf für Hochtechnisierte Fernsteuerungen wohl in der Masse nicht gegeben ist.

Ich persönlich scheue ich mich derzeit aufgrund der rechtlichen Unsicherheit derzeit in 2,4GHz Technik von Robbe oder Graupner zu investieren. Eine sichere Ersatzteilversorgung über Jahre nach dem Inkrafttreten der neuen Verordnung in 07/2008, ist derzeit zweifelhaft. Welches Interesse sollte z.B. Graupner haben, 2012 noch Empfänger für eine Technik zu verkaufen, für die das Sendermodule in 2007/08 nur 1 Jahr auf dem Markt war?


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.
Bei dem Vorhaben gesetzt, ist das XBEE pro Modul für die Funkstrecke. Das wohl technisch bessere FASST Verfahren kann wohl nicht zur Anwendung kommen, da die speziellen Futaba IC’s wohl nicht beschaffbar sein werden. Es fehlt also nur noch Layer 3-7 in der Übertragungstrecke und ein abgestimtes Gesamtkonzept.

Konkret in Software zu schaffen ist ….

…. die Adaptierung mittels µProzessor der vorhandenen Sendertechnik an die neue 2,4GHz Funkstrecke -> PPM (PCM) Rahmenauswertung im Sender (Sendermodul)

…..Definition und Programmierung eines sicheren Übertragungsprotokolls. Prämissen hierbei Datensicherheit (-> niedrige Datenrate ergo hohe Wiederholrate, Sicherungsmechanismen) , Universalität (spätere Nutzung des Rückkanals, sichere und ungesicherte Datenübertragung)

…..Adaptierung der bisherigen Servotechnologie an die Funkstrecke (Entwicklung eines Empfängers)


Die notwendige Hardware ist überschaubar. Jeweils zum XBEE pro Modul im Sender/Empfänger ein Atmega XX Prozessor und ein wenig Krusch drumrum. Die Hauptarbeit ist die Software.


In dem RCN Thread zum standartisierten Protokoll, sind bereits viele Ideen gekommen, wie so ein Übertragungsprotokoll aussehen könnte. Ich habe einige der Ideen aufgegriffen und eigene Gedanken hinzugefügt. Angelehnt ist das ganze an das UDP/TCP IP Protokoll, allerdings auf Grund der anzustrebenden niedrigen Datenrate und niedrigen Latenz stark abgespeckt.

Die Merkmale des Protokollentwurfs (Details im nächsten Beitrag):

• Gesicherte (TCP für Servodaten) oder ungesicherte (UDP für z.B. Loggerdaten) Datenübertragung je nach Dateninhalt möglich
• Der Dateninhalt und deren Größe sind nicht fest definiert im Protokoll. Es können reine Verwaltungsframes (z.B. einfache ACK), Servoframes oder Datenframes (Logger, Vario) übertragen werden.
• Nur die Servodaten werden übertragen, welche sich seit dem letzten versendeten Frame, deren Empfang bestätigt wurde, verändert wurden.
• Bei fehlerhaft empfangenen Daten, kann der Empfänger ein erneutes Versenden der Daten anfordern (RESEND). Bleibt das ACK oder das RESEND des Empfängers für eine Weile (z.B. 2ms) aus, beginnt der Sender automatisch permanent die neusten Inkrementells seit dem letzten bestätigten Frame zu versenden.
• Um die Qualität der Übertragungsstrecke permanent zu monitoren, sollten auch bei nicht veränderter Knüppelposition am Sender, alle 10ms ein Frame mit PSHACK gesendet werden. Ab einer kritischen Fehlerrate, also einer hohen Anzahl von nicht bestätigten oder mit RESEND bestätigten Frames, sollte ein Beepton am Sender den Piloten warnen.
• Um die Sicherheit zu erhöhen kann ein zweites XBEE Modul in Diversitykonfiguration zur Anwendung kommen (Sender/Empfänger).


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.


Thomas
Gruß

Thomas

Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

2

Freitag, 19. Oktober 2007, 00:10

Protokoll Rahmenaufbau

<SYNCWORD L1><UNIQUEADRESS L3> <SEQUENCENO L4><FLAGS L4> <CRC L4> <SERVONO/WERT L6/7><SERVONO/WERT L6/7><SERVONO/WERT L6/7> <FRAME END>

Ein Frame ohne Dateninhalt besteht aus 10Byte.


<SYNCWORD> (2Byte) Framebeginn z.B. 1010 1010 1010 1010 (xAAAA)

<UNIQUEADRESS> (3Byte, L3 Addresse, erstes Bit immer 0) Eindeutige Adresse des Senders, welche beim Pairing dem Empfänger eingelernt wird. Die L3 Adresse des Empfängers ist = Senderadresse+1

<SEQUENCENO> (1 Byte , L4 Datenfluss/Datensicherung)
• Bei gesetztem DATA -Flag, ist dies die Sequenznumer des Senders.
• Bei gesetztem ACK -Flag, ist dies die Sequenznumer des Frames von dem der einwandfrei Empfang bestätigt wird

<FLAGS> -> [0 |Verwalt.={ACK|PSHACK|RST|RESEND}|Datenbeschreibung(Port)={SERVODATA|OTHERDATA|LEARN }]> (L4 , 1 Byte)


ACK Es wird der einwandfreie Empfang des Frames <SEQUENZNO> bestätigt

PSHACK Es wird erwartet das der Empfang des Frames mit einem ACK bestätigt wir

RST Sequenzcounter auf 0 zurücksetzen

RESEND Frame mit <SEQUENZNO> nicht fehlerfrei empfangen

SERVODATA Servodaten werden in dem Frame mitgesendet, 0 wenn keine Daten im Frame (z.B. ein reiner ACK Frame)

OTHERDATA Andere Daten (keien Servodaten) werden in dem Frame mitgesendet (Vario, Logger)

LEARN Bindingmode. Die L3 Adresse des Senders wird vom Empfänger übernommen



<CRC> (1 Byte) Prüfsumme über L3-L7


<DATA> (2Byte pro Wert) z.B. Ein Servowert <SERVONO/WERT>
Detail: 0 Anfangsbit immer „0“ | 1/0 | Sollwert/Failsavewert | 1111 Servonummer max. 16 | 11 1111 1111 Servowert (10Bit)

< FRAME END > (2Byte) 1101 0101 1101 0101
Gruß

Thomas

3

Freitag, 19. Oktober 2007, 13:30

Hallo,

finde ich sehr interessant!!!
Was schätzt du wie groß der finanzielle Aufwand wird?
Leider kenne ich mich bei diesen Sachen noch nicht so gut aus, hoffe aber irgendwie mitzumachen, wenn es geht.
Benni

4

Freitag, 19. Oktober 2007, 13:45

Hoert sich gut an. Bin dabei soweit es meine Zeit zulaesst.
Das meiste Zeugs liegt eh derzeit ungenutzt bei mir rum.
Gruss
Thomas

🖖
So long, and thanks for all the fish.


5

Freitag, 19. Oktober 2007, 15:24

Finde ich gut!

2 Anmerkungen von mir auch wenn ich nicht ins Detail gehen soll.

Löse dich von TCP und RESEND.

Resend kann dir nur alte Daten liefern deren Ereignishorizont bereits überschritten ist. TCP bedeutet das du auf fixe Timeframes festgelegt bist. UDP ist ein verbindungsloses Protokoll bei dem keine Antwort erwartet wird und kann sowohl vom Sender zum Empfänger als auch umgekehrt benutzt werden. Unabhängig davon ob die Gegenstelle antwortet kann die Sendestelle auf das Ausbleiben von Antworten innerhalb eines lockeren Zeitrahmens reagieren ohne in ein festes Korsett gezwängt zu werden.
Ist eben die Frage ob es wichtiger ist das aktuelle Pakete mit Steuerungsinformationen beim Empfänger ankommen oder ob sich beide damit beschäftigen sollen wer gerade welches Paket nicht verstanden hat welches eigentlich schon zeitlich verfallen ist.
"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

6

Freitag, 19. Oktober 2007, 18:01

Hallo Thomas,

Zitat

Ich möchte mit diesem Thread einen anderen Ansatz anstossen, eine gemeinschaftliche Eigenentwicklung.


Das ist zwar ganz im Sinn den ich meine. Genau dies ist aber z. B. bei ACT in ähnlicher Art wohl vorgesehen.

Vergiss das aber mit TCP und XBEE, das wird Nichts.

Wenn schon, dann warte bitte ab bis die Norm steht und dann sollte es damit kompatibel sein. Bald wird man mehr wissen. Eine weitere parallel geführte Linie ist nur kontraproduktiv.
Nur so mach das für nicht so versierte Selbsbauer Sinn.

Unterschreibt bitte die Initiative.

Gruss Bruno

7

Freitag, 19. Oktober 2007, 20:00

Bruno,
XBEE sehe ich hier nur als Basis um einfach mal was zu machen. XBEE sehe ich nur als Transport Layer. Bin nicht mal sicher ob die beiden Module die ich hier rumliegen habe XBEE sind. Liegen schon eine Weile und sind inzw. wieder gut verpackt. Also: Ueber die Uebertragung sollten wir hier wirjlich nicht diskutieren.

Ein spaeteres genormtes Protokoll? Meinst du das mit Norm?
Menschenskinder, ich hab nur noch 15 Jahre bis ich plane in Rente zu gehen. ;)

Lass uns doch hier einfach mal forstsetzen was du und Wurpfel mit euren Vorstoessen angefangen haben. Aus der Praxis fuer die Praxis.

Wer ist ACT? Muss ich die hier im Forum kennen? :D ;)

Du verstehst wohl was ich meine. Warum auf einen Hersteller warten. Parallel dazu koennen wir alle lernen. Spaeter kann man ein Protokoll immer noch anpassen.
Gruss
Thomas

🖖
So long, and thanks for all the fish.


^____

RCLine User

  • »^____« wurde gesperrt

Wohnort: anonymisiert

Beruf: anonymisiert

  • Nachricht senden

8

Freitag, 19. Oktober 2007, 21:08

Hallo Thomas,

Zitat

Ein spaeteres genormtes Protokoll? Meinst du das mit Norm?


Ja, an sich schon. So gesehen hast Du mit Deinem Beitrag schon Recht, ich sehe das ähnlich. Ich dachte bloss, dass diese XBEE's ja nicht unbedingt dafür gemacht wurden was wir wollen. Zum Experimentieren ist es aber sicher eine gute Basis.

Leider ist die Initiative bisher nicht sehr erfolgreich verlaufen. Wenn man bedenkt, das weit über 5000 Mal auf die entsprechende Seite zugegriffen wurde, ist die Ausbeute an Unterschriften schon etwas mager.

ACT = Anti Crash Technology

Sag bloss, Du wusstest das nicht! :D ;)

Gruss Bruno

Ps:

Zitat

Menschenskinder, ich hab nur noch 15 Jahre bis ich plane in Rente zu gehen.


So Jung könnt Ihr schon in Rente gehen? ich hab auch noch 15 Jahre. ;(

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »^____« (19. Oktober 2007, 21:10)


Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

9

Freitag, 19. Oktober 2007, 22:00

Hallo,

klingt doch gut, schon 2-3 Interessenten welche aktiv mitmachen möchten. Mal sehen ob es noch mehr werden und wie man das Projekt am besten praktisch ans laufen bekommt.

Zitat

Original von sidigonzales
Löse dich von TCP und RESEND.
Resend kann dir nur alte Daten liefern deren Ereignishorizont bereits überschritten ist.

Da hast du vollkommen recht, es macht keinen Sinn die alten Daten nochmal über die Funkstrecke zu senden. Ich habe mich hier leider nicht genau ausgedrückt: "... beginnt der Sender automatisch permanent die neusten Inkrementells seit dem letzten bestätigten Frame zu versenden... " bezieht sich nicht nur auf nicht bestätigte Frames, sondern auch auf RESEND Frames. Sinn des ganzen ist es im Normalfall nur alle 10ms ein Frame zu senden, wenn keine Änderungen eingetreten sind. Nur bei gestörter Übertragung soll geburstet werden und dann auch nur die Inkrementells seit dem letzte ACK um durch die kleine Datenmenge die Warscheinlichkeit der fehlerfreien Übertragung zu erhöhen.

Zitat

Original von B. Eberle
Vergiss das aber mit TCP und XBEE, das wird Nichts.
Bitte nicht auf die genauen Funktionen TCP und UDP aus dem IP Protokoll mit dem TCP/UDP light vergleichen. Das TCP light soll stark abgespeckt und vom Funktionsumfang angepasst verwendet werden.
Begreife die TCP light Funktion eher als Qualitätsmonitoring, um aufgrund schlechter Q Parameter andere Massnahmen ( schnelle/schlanke RESENDS, Pilotenwarnung, Frequenzhopping und/oder Diversityschwenk) anzuwenden.

XBEE
Ich pflichte da Thomas Radetzki bei. Fokus des Projektes ist nicht die verwendete Funkhardware, sonder die Adaption der vorhandenen Sender/Servo Technik und der Entwicklung einer sicheren Datenübertragung über die Funkmodule XXX.
Aber was spricht in deinen Augene eigentlich gegen die XBEE Module?

Zitat

Original von B. Eberle
Wenn schon, dann warte bitte ab bis die Norm steht und dann sollte es damit kompatibel sein. Bald wird man mehr wissen. Eine weitere parallel geführte Linie ist nur kontraproduktiv.
Nur so mach das für nicht so versierte Selbsbauer Sinn.

Ich denke nicht das aufgrund der Initiative eine Vorgabe entsteht, welche von einem Hersteller angenommen wird. Sowohl die Firmenpolitik der Modellbaufirmen als auch der in meinen Augen zu "technisierte" Standart, welcher nicht den wahren Bedarf der großen Masse der Modellbauer wiederspiegelt, wird wohl eine Durchdringung verhindern.
Das ist meine Meinung warum es wohl so nichts wird, was aber nicht heisst daß das erarbeitetet schlecht ist.
Der Fokus der Initiative sollte darauf liegen, den Modellbaufirmen den Wunsch der Kunden nach einer Herstellerübergreifenden Kompatiblität näher zu bringen.

Opensourceprojekte haben den Vorteil das eine Anpassung der Software an neue Standarts möglich ist.

Zitat

Original von B. Eberle
Unterschreibt bitte die Initiative.
..mach ich :ok:

@Benni
Der finanzielle Aufwand wird hauptsächlich duch die Funkmodule bestimmt. Ein XBEE pro liegt bei ~30-35€. Das Sendermodul brauch ein XBEE und pro Empfänger braucht man auch eins. In Diversitykonfiguration das ganze mal 2. Atmel Prozessororen je nach Typ 2-4€, Krusch drumrum ~5€, Antene Stecker 10€. Die Kosten für die Platinen hängen stark von der Auflage ab 5 ->20 .
Macht etwa 100€ ohne Spesen für das erste RX/TX Paar (ohne Diversity).

Freu mich schon, bald wieder den Lötkolben zu schwingen und den Kompiler zu quälen.

@Mitmacher
Welche Entwicklungsstandarts für die Hardwareentwicklung (Eagle, Target) und Software (Bascom, AVR, ...) schlagt ihr vor?


Gruß
Thomas [SIZE=1](derzeit noch im Urlaub auf Griechenland)[/SIZE]

[SIZE=1]EDIT: Kostenauflistung[/SIZE]
Gruß

Thomas

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Space« (20. Oktober 2007, 12:20)


10

Freitag, 19. Oktober 2007, 22:07

Enzwicklungsumgebung: GNU C und Eagle waere mein Vorschlag.
Mit Bascom kann ich mich nicht anfreunden.
Gruss
Thomas

🖖
So long, and thanks for all the fish.


11

Freitag, 19. Oktober 2007, 22:45

genau mein Geschack

Hi,

genau sowas hab ich auch vor. Nur das ich in allen notwendigen Fachbereichen nur die Hobbyebene erreicht habe. Als Nachbauer und Tester bin ich aber geeigent.

X-Bee pro ist vorhanden und sendet (z.Z auf dem Schreibtisch) GPS-Daten zur "Bodenstation" die auch schon PPM-Daten der FS einlesen kann. Als nächtes soll ein "Empfängerbaustein zur Servosignalerzeugung und Stromversorgung des GPS entstehen.

Ich nutze Winavr, AVR-Studio und Eagle 4.13

Ich denke einfach loszulegen ist die beste Lösung. Sie Software kann sicherlich einfach auf verschiedene Hardware angepasst werden. Bei entsprechend modularem Aufbau ist nachher der Einsatz aller möglichen Funk-Module denkbar. Z.B Pollins RFM12 oder Infrarot.

Normen werden nicht per Petition festgelegt sondern oft aus praxiserprobten Lösungen entwickelt.

Also lasst uns erstmal eine Hardware definieren die dann für erste Tests herhalten kann.

Gruß Sven

Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

12

Samstag, 20. Oktober 2007, 12:21

RE: genau mein Geschack

Zitat

Original von sven.stoecker
X-Bee pro ist vorhanden und sendet (z.Z auf dem Schreibtisch) GPS-Daten zur "Bodenstation" die auch schon PPM-Daten der FS einlesen kann. Als nächtes soll ein "Empfängerbaustein zur Servosignalerzeugung und Stromversorgung des GPS entstehen.

Hallo Sven, scheint ja so, als bist du bereits fertig mit dem Open2.4 Projekt ;)

LAYOUT SOFTWARE
Eagle ist also gesetzt für das Projekt. Ich verwende die V4.16. Sven verwendet V4.13. Gibt es da Probleme beim Austausch von Dateien mit unterschiedlichen Versionsständen?

PROGSPRACHE/COMPILER
Die Progsprache ist praktisch auch klar, WIN AVR/GNU C :
Meine Favoriten 1) Bascom -> 2) WIN AVR -> 3) AVR-Studio
Sven 1) WINAVR 1) AVR-Studio
Thomas R. 1) GNU C (->WINAVR)

Meine C Kenntnisse sind nicht doll. Ich habe aber kein Thema damit, mich von Bascom zu lösen und mich in einen der anderen Vorschläge einzuarbeiten. Da geht anfangs sicher auf die Produktivität ;) aber ist auch die Gelegenheit dazu.

HARDWARE
Als Hardwarevorschlag für den Empfänger würde ich den Atmega168 (MLF32) vorschlagen. Die interne Betriebsspannung in dem RX, das XBEE arbeitet ja auch damit, sollte 3,3V sein. Vergleichbar von der Pinanzahl ist der Proz mit dem Mega 8, allerdings handelt es sich um die modernere Variante welche weniger Strom als der M8 verbraucht. An 3,3Volt, sollte er mit 12MHz sicher betrieben werden können und somit eine sauber Auflösung der Servoimpulse ermöglichen.
Die Pinanzahl reicht für 12 Servos + 3 freie Pins und ein frei nutzbarer SPI/I2C Bus. (Anbindung Sensoren oder GPS)
Mit 16K Flash bleiben genügend Reserven für alle möglichen Spielereien.
Bei einem Diversitysystem sind 2 Hardware UART von Vorteil (2xXBEE). Hier würde ich den Atmega164 (MLF44) vorschlagen.

Der Proz im Sender benötigt gegenüber dem RX Proz weniger Pins und kann wegen der sicheren 5V auch mit 20MHz betrieben werden. Trotzdem den M164 oder 168 verwenden oder den M8 ?


Wie schaut es mit der Hardware generell aus? Ich möchte vorschlagen aufgrund der manchmal recht hohen Versandspesen die Bestellungen zu bündeln. Ich bin auch gerne bereit dazu dieses zu übernehmen.
Ihr habt ja aller bereits die XBEE im Regal oder bereits vor euch liegen. Ich aber noch nicht. Wer noch nicht?

Falls es die M164 oder M168 werden, so hat die wohl auch kaum einer so rumliegen….wer auch nicht?

Zur Datei/Sourcen Verwaltung schlage ich vor im Opencharge WIKI , in der Downloadsektion einen extra Abschnitt einzureichten.
@Sven, kannst du dort eventuell schon deinen aktuellen Entwicklungsstand dort ablegen?


Thomas
Gruß

Thomas

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Space« (20. Oktober 2007, 14:14)


13

Samstag, 20. Oktober 2007, 17:08

Im Sender wuerde ich vorschlagen auch eine 3,3V Variante des Mega zu nehmen. Vereinfacht die Spannungsversorgung da das XBEE auch 3,3V braucht.

Hatte mal nachgeschaut. Die Funkmodule die ich hier habe sind keine XBEE. Habe mir daher vorhin was bestellt. Wuerde aber bei einer Sammelbestellung noch zwei weitere Module nehmen.
Auf jeden Fall bitte das XBEE-PRO. Und dieses mit whip Antenne. Ich trau irgendwie diesen Chip Antennen nicht so richtig.

4.13 und 4.16 sind beim Eagle meines Wissens kompatibel. Muesste man mal ausprobieren.

Ja, Prozessoren braeuchte ich auch. Ein M168 liegt gerade noch rum.

Eine Frage noch zur Hardware: Komplett SMD ist doch wohl angesagt. Oder zweigleisig?
Gruss
Thomas

🖖
So long, and thanks for all the fish.


14

Samstag, 20. Oktober 2007, 18:24

Hallo,

ich möchte jetzt nicht irgendwie eine Diskussion anfackeln oder so...
Aber stimmt es das wenn zwischen FLieger und Sender eine MAterie (z.B. ein Baum) ist, das man dann keinen Empfang mehr hat?
Benni

15

Samstag, 20. Oktober 2007, 18:47

Hi,

ich versuche meine Projekte immer "reichelttauglich" auszulegen. Drum würde bei mir nur Mega8L verwendet und dann der Einfachkeit halber mit interner 8MHz (natürlich kallibriert)
Ich denke mit 8MHz-Mega8 sind sowohl Sender und Empfänger zu realisieren.
Wobei auch beim Mega8 mehrere UART per Software machbar sind.
Meine Versuche mit einer Turbinen-ECU und meinem GPS-Anzeiger haben gezeigt, dass die Pinbelegung bei vielen Spezialfunktionen oft mal getauscht werden muss:-).
Also muß die Pinbelegung genau durchdacht sein.

Die endgültige Leiterplatte dann in SMD ich habe keine Lust auf massenhaft Löcher bohren.

Mein derzeitiger "Empfänger" hat Mega8, 8Servoanschlüsse, GPS, I2C und 8pin Telemetrie(2xInterupt füer Drehzahlmessung und Telemeti-UART) und 6 ADC.
Das Ganze (sind eigenlich fast nur Stiftleisten) passt warscheinlich locker auf eine 42x28mm Leiterplatte. Bin noch drüber her und das dauert immer paar Abende.
Die Progpins liegen bis auf Reset auf den Servopins. die 8 "Telemetieleitungen sind auch für Servos zu nutzen, liegen aber derzeit auf einer 5x2 stiftleiste.

M8, M168 und M164 sind doch Pinkompatibel!? Dann ist es egal welcher Prozessor zum Einsatz kommt. Die Software sollte weitestgehend prozessorunabhängig sein. Dann könnte im Sendemodul auch Mega256 sein, der gleich eine Display steuert und paar Podis abfragt:-)
Ihr werdet stauen wieviel Software in den M8 passt wenn man nicht Bascom verwendet:-)

Gruß Sven

^____

RCLine User

  • »^____« wurde gesperrt

Wohnort: anonymisiert

Beruf: anonymisiert

  • Nachricht senden

16

Samstag, 20. Oktober 2007, 18:51

Hallo Benni,

Zitat

Aber stimmt es das wenn zwischen FLieger und Sender eine MAterie (z.B. ein Baum) ist, das man dann keinen Empfang mehr hat?


Keinen nicht, aber die HF wird mehr oder weniger stark gedämpft was die Reichweite je nach Fall deutlich einschränken kann. Je höher die Frequenz, desto problematischer wird dieser Effekt.

Gruss Bruno

17

Samstag, 20. Oktober 2007, 19:31

Und wenn wir es schaffen die SW sauber zu modularisieren koennen solche "Feinheiten" auch gleich mit geplant werden.
Denn z.B. auf ein Display moechte ich am Sender nicht verzichten.
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

18

Sonntag, 21. Oktober 2007, 22:10

Hallo,

ich bin gestern Nacht zurück aus dem Kurzurlaub, war nett nochmal Sonne zu tanken.

Zitat

ich versuche meine Projekte immer "reichelttauglich" auszulegen. Drum würde bei mir nur Mega8L verwendet und dann der Einfachkeit halber mit interner 8MHz (natürlich kallibriert)
"Reichelttauglich" macht natürlich Sinn, darum mein Vorschlag den Atmega 88 bei Neubauten zu verwenden. Der M88 ist in allen Varianten bei Reichelt (2.05€) zu bekommen und ist Pinkompatibel zum Atmeag8 so dass du (Sven) auch mit dem M8 weitermachen kann.

Den internen Takt würde ich aber sehr ungern verwenden, aus 2 Gründen:
  • Der interne Takt ist nicht Spannungskompensiert. Ich habe es auf die Schnelle nicht gefunden, für welche Betriebsspannung laut Atmel die Kalibrierung gültig ist. Aus eigener praktischer Erfahrung weiss ich, das der RC-Takt bei veränderter Betriebsspannung schwankt. Bei meinem Beispiel funktionierte die Serielle Kommunikation bei 5V nicht sauber, bei 4V war alles gut. Da wir die Proz bei 3,3V betreiben möchten, werden die 8MHz sicherlich nicht 8MHz sein, es sei denn Atmel hat sie für 3,3V kalibriert.
  • Der interne Takt ist nicht so temperaturstabil, wie ein Quarz. Das könnte zu Folge haben das die Servos im Winter eine anderer Mittelstellung als im Sommer haben. Im Worstcase funktioniert die PPM Auswertung nicht mehr oder die asynchrone UART Kommunikation bricht zusammen.

Ein SMD Quarz kostet bei Reichelt 24Cent, ich denke das ist nicht das Problem.

Zitat

Wobei auch beim Mega8 mehrere UART per Software machbar sind.
Stimmt natürlich, geht auch per Software. Der Empfang per Software UART ist normalerweise immer abzupollen, da sie normalerweise keinen Interrupt auslösen können.
mhhhhh. grübel.. wobei ein PIN-LOW Interrupt an einem INT Eingang des Atmel müsste wohl doch gehen. Alternativ könnte man die RTS/CTS Schnittstellenleitungen zum XBEee verwenden.
Muss man sehen ob das klappen könnte ich denke aufgrund der vielen zeitkritischen Punkte wird es schwierig auf den Hardwareempfangspuffer zu verzichten.

Zitat


Ihr werdet stauen wieviel Software in den M8 passt wenn man nicht Bascom verwendet:-)
Ich werde es sehen 8( , Thomas Radetzki weiss es glaube ich schon und ich werde es bald erfahren.
Ich habe Gestern einige Zeit mit warten auf Transportmittel verbracht. Dabei habe ich den C Kraschkurs durchgearbeitet. Bin noch nicht wirklich warm mit C. Mir fehlt da die Übersichtlichkeit des Codes. Die vielen Befehle mit Klammern unterschiedlichster Ausprägung, * und & machen das nicht sehr leserlich. Wird schon...

Zitat

Und wenn wir es schaffen die SW sauber zu modularisieren koennen solche "Feinheiten" auch gleich mit geplant werden.
Denn z.B. auf ein Display moechte ich am Sender nicht verzichten.
Geht mir auch so, mir schwebt da auch sowas vor, wie eine Variofunktion später zu integrieren und andere Loggerdaten runter zu senden.
Aber erst sollte die Pflichtfunktion stehen wobei man hierbei auch schon an die Kühr denken kann :)

Zitat

Und dieses mit whip Antenne. Ich trau irgendwie diesen Chip Antennen nicht so richtig

Beginnt der aktive Teil der Whip Antenne eigentlich direkt an der Platine oder ist das erste Stück noch Coax so das man die Whip aus dem (CFK) Rumpf führen kann? Kann man an dem XBEee ggf. ein Stück Koax anlöten oder sollte man dann lieber das RF Connector Modul verwenden?

Knnt jemand eine Bezugsquelle für 90° gewinkelte, 3polige Stecker, wie man sie an dem Empfänger benötigen wird?

Zitat

Eine Frage noch zur Hardware: Komplett SMD ist doch wohl angesagt. Oder zweigleisig?
Meiner Meinung nach nativ SMD.

@Sven
Kannst du deine bisherigen Entwicklungsstand schon mal zur Verfügung stellen ?
(ggf. per Mail)

Thomas
Gruß

Thomas

19

Sonntag, 21. Oktober 2007, 22:22

Da ich tatsaechlich andere Module da habe und auf die XBee erstmal warte geh ich von der Spec aus. Und da habe ich verstanden Coax + Whip.

Interner Takt: Das lass uns rausschieben. Ist erstmal egal. Ob Intern oder Reso oder Quarz kann leicht im Layout geaendert werden.

Platz im M8 ist viel. Wahrscheinlich genug fuer die Aufgaben die der Sender/Empfaenger braucht. Warten wir mal ab und bleiben Pinkompatibel. M8 waere eine Basis.
Bzw. M8L wg. den 3,3V sonst wird es auf der HW nicht so locker weil wir zwei Spannungen brauchen.
Gruss
Thomas

🖖
So long, and thanks for all the fish.


20

Montag, 22. Oktober 2007, 14:10

Hallo zusammen,

da ist man mal ein paar Tage nicht im Forum und schon gibts hier eine interessante Aktion... :ok:

Da es im alten Thread über das "französische Projekt" wohl untergegangen ist und hier auch gut reinpasst, schreib ich mal was über mein Projekt. Meine Erfahrungen bringe ich hier auch gerne ein!

Habe auf Basis von 2 XBee-Pro mit Whip-Antenne und Atmega88 ein Fernsteuerungssystem gebaut.


Wie man sehen kann, alles noch sehr provisorisch auf Lochraster und mit LM317 aufgebaut, aber es funktioniert... Wie schon erwähnt, ist der meiste Aufwand die Software.
Hier mal ein kleines Demo-Video: http://www.youtube.com/watch?v=jdrqIjb6Io4

Tests sind bisher erfolgt in einem Boot (man weiß ja nie...), und dann im Easystar.


Steuerung nicht anders als normal, die Reichweite allerdings nicht überragend (bekomme die Empfangsstärke zurückgemeldet...). Gab auch einige kurze Failsafe-Einschaltungen, die gut die Grenze zeigen. Macht sich bei meinem System durch ein kurzes Aussetzen des Motors bemerkbar.

Werde das ganze demnächst mit einer besseren Antenne am Sender aufwerten, hoffe, dass sich damit die Reichweite erhöht.

Habe meine Software nicht hier, deshalb nur eine kurze Beschreibung:
PPM-Sampling vom L/S-Port
Übertragung eines "Fernsteuer-Frames" alle 20ms
Spezielles Frame zur Failsafe-Einstellung
Einstellung und Anzeige über Display (parallel arbeitet die Steuerung natürlich weiter, sieht man im Viedeo)

Rückmeldung der Feldstärke und der verlorenen Pakete alle 10 eingegangenen Pakete (sparen von Bandbreite)
Spezielles Rückmeldepaket, wenn kein Empfang.
Failsafe, wenn 3 Pakete nicht empfangen wurden (ist ziemlich scharf, aber zum testen gut).

Was noch nicht realisiert ist, ist das Binden von verschiedenen Empfängern an den Sender und das Freuquenzwechseln bei belegtem Kanal.

Angesteuert werden die XBee´s im API-Mode.

So, dann weiter...

Grüße

Marc