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.

Hellracer666

RCLine User

Wohnort: Hannover

Beruf: EAT

  • Nachricht senden

121

Donnerstag, 13. Dezember 2007, 18:26

Gibt es denn bald eine erste Aufbauanleitung, mit Stückliste etc.?
Ist ein echt :ok: :ok: :ok: Projekt!
Sebart Su S29 e30 AXI 2826/14, Jeti Adv 40+, HS65hb, 4S SLS :nuts: :nuts:
QQ Yak54 AXI 5320/18, D-Smart100+ HV, SLS 8) 8(
TT-CopterC. V2, SLS :O :ok:
T-rex 500 DFBL, BeastX, 6S SLS :nuts: :evil:

122

Donnerstag, 13. Dezember 2007, 22:00

Hallo Dominik,

sauge dir bei www.cadsoft.de EAGLE. Damit kannst du die Schaltungs- und Leiterplattendatein .sch und .brd anzeigen und bearbeiten.
Duch Auswahl der angezeigten Ebenen bekommst du z.B einen Bestückungsplan. Mit Export kannst du eine Bauteileliste erstellen.

Gruß Sven

Bruchflieger

RCLine User

Wohnort: 18km südl. der Lutherstadt Wittenberg

Beruf: Energieelektroniker / HWK-Meister E-technik

  • Nachricht senden

123

Sonntag, 16. Dezember 2007, 11:23

Sorry für etwas offtopic.

Ich hab zwar letztens relativ gute Ergebnisse bei der Direkttoner-Methode mit ganz normalem Kopierpapier gemacht, aber da hatte ich auch Leiterbahnen mit min. 0,4mm Breite im Layout.
Ich muß jetzt aber mal 2 Platinen ätzen, wo unter anderem Leiterbahnen nur noch 0,2mm dick sind, und die Abstände zw. den Leiterbahnen teilweise nur 0,1mm betragen. - Da ist extrem sauberes arbeiten Pflicht, und ich brauche da ein Transfermedium, was doch etwas besser geeignet ist, denn beim normalen Papier bleiben doch etliche Papierfasern am Toner kleben, die den Ätzvorgang arg abbremsen - gerade in engen Leiterbahnzwischenräumen.
Reichelt-Kataloge hab ich leider nur einen, da ich bei der letzten Bestellung keinen neuen bekommen hatte, und daher möchte ich ihn nicht schlachten. Ich hab auch schon Versuche mit dem Blatt gemacht, was bei der FMT auf der Rückseite den Adressaufkleber trägt, mit transparenter Laserfolie und einigen anderen Medien - aber jedes mal hat es nicht so richtig geklappt.

Gibt es eventuell Tonertransferpapier irgendwo günstig zu kaufen?
Grüße Dani.

Dante

RCLine User

Wohnort: Rheinknie

  • Nachricht senden

124

Montag, 17. Dezember 2007, 22:05

Ich nutze meistens "Ofenpapier".
Das ist Hitzebeständig und "fettig" genug, um die Leiterbahnen wieder abzulösen.

Leo
Trollfilter: Ein

berndhac

RCLine User

Wohnort: Trier / Aurich

  • Nachricht senden

125

Montag, 31. Dezember 2007, 12:09

Hallo,

finde dieses Selbstbauprojekt sehr interessant. Respekt den Umsetzern!!

Mich würde mal interessieren, wie die Übertragungssicherheit im Vergleich zu den Kommerziellen Anlagen einzustufen ist - insbesondere im Vergleich zum Futaba FASST?? Der eigentliche Funkweg ist ja der selbe, bleiben also eigentlich nur Unterschiede in Punkto software Signalauswertung und Failsafegeschichten??

Gruß
Bernd

126

Montag, 31. Dezember 2007, 19:07

Hallo Bernd,

die Antwort läßt sich recht einfach geben..
Die Funkstrecke entspricht Graupners IFS / XPS (da gleiche Hardware)
Was Failsafe und Kanalwechsel angeht, können wir vielleicht durch gute Programmierung besser sein als das genannte System, da sind meiner Meinung nach einige "Bugs" drin... (gibts auch einige interessante Threads zu..)

Allgemein würde ich sagen, dass das System natürlich am Anfang vor Programmierfehlern nicht sicher ist. ein paar Leute können wohl nicht so viel testen wie große Firmen...

Das ganze richtet sich momentan ja auch vor allem an Leute, die Spaß am basteln haben, und das Risiko einschätzen können..(und neue Zusatzfunktionen testen wollen). Wenn es um teure, große Flieger geht, würde ich mir auch ein FASST System kaufen.

Also dann

feiert schön und ein frohes neues (Bastel)Jahr

Marc

127

Mittwoch, 2. Januar 2008, 13:55

Hallo,
ist euch schon aufgefallen wie lange ein Kanalwechsel benötigt?
Ich habe etwas mehr als 15mS gemessen!!!!
Wenn ich innerhalb eines Ppm Frames (ca. 20mS) den Kanal wechseln möchte wird das knapp.
Der Scann aller Kanäle (Energy Scann) dauert 374mS, somit gibt es absolut keine Möglichkeit zwischendurch mal einen Kanal zu suchen welcher einen niedrigeren Störpegel hat.
Der Scann nur eines Kanals benötigt ca. 32mS somit kann man auch nicht nach jeder Sendung einen anderen Kanal Scannen!
Habt ihr da Ideen oder Lösungen?

Grüße
Wolfgang

Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

128

Mittwoch, 2. Januar 2008, 17:14

Zitat

Original von wgottlieb
Habt ihr da Ideen oder Lösungen?

Hallo Wolfgang,

die 15ms decken sich mit meinen Erkenntnissen, auch wenn ich die 15ms mangels Messtechnik/Messidee selber nicht messen konnte. Aber mir ist es gelungen zwischen 2 PPM Frames den Kanal zu wechseln, ohne das ein Frame verloren ging (ich verwende UI Sequenznummern pro ausgesendeten Frame).

Ich habe in meinem Sendermodul habe ich 2 XBee vorgesehen. Je nach Betriebsmöglichkeit des Empfängers, hier sind entweder 1 oder auch 2 XBee vorgesehen, bieten die 2 XBee im Sender sicherlich genügend Zeit den ED durchzuführen.
Das zweite XBee im Sender ist eine einmalige Investition für alle Modelle und vereinfacht aber auch den Kanalwechsel ungemein.
Einer der XBee kann schon vor dem Hoppen auf den neuen Kanal betrieben werden und dort warten das der Empfänger sich dort meldet.

Als "Abfallprodukt" hat man durch die 2 XBee im Sender ein Raum Antennen Diversety, welches 2 Polarisations Ebenen bedienen kann.
Die endgültige Antennen Strategie wir das Diversety mit dem Hopping in den Einklang zu bekommen ist (wechsel ich genberell den Kanal wenn ich die Antenne wechseln möchte?) ist mir aber selber noch nicht ganz klar.

Thomas

[IMG]http://www.rclineforum.de/forum/attachment.php?attachmentid=74860&sid=[/IMG]
Gruß

Thomas

129

Mittwoch, 2. Januar 2008, 17:34

Hi Space,

Coole Sache. :)

Wie wäre es wenn du ein Paket aussendest, die Frequenz wechselst, ein Paket sendest... bis du die Frequenzen durchrotiert hast. Am Abstand der empfangenen Pakete müsste doch die Kanalwechselzeit plus Zeit für ein Paket ablesbar sein.
Hab ich aber ehrlich gesagt noch nicht probiert. :(

Ansonsten hast du coole Ideen. Auch wenn das den Anhängern der reinen Diversitylehre nicht gefallen wird. :D

Grüße,

Jog Hurt
"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

130

Mittwoch, 2. Januar 2008, 18:05

Hallo Thomas,
Diversity ist sicher super doch wirkt sich das leider negativ auf Kosten - Aufwand und die Größe des Empfängers aus!
Da ich schon ein 433Mhz Fernsteuersystem entwickelt habe (Chipcon CC1020) weiß ich wie schell moderne Pll’s locken, und 15mS sind eine Ewigkeit!
Ich habe schon Überlegungen angestellt (mir graut davor) eine eigene Firmware für den eingesetzten Freescale Controller zu erstellen.
Source Codes und eine Entwicklungsumgebung sind Downloadbar ‚Xbeecodedevelopment’.

Hier die Messung:

Kanal 1 Gelb, vom Controller zum Xbee Modul
Kanal 2 Blau, Antwort vom Modul

Langes Paket Kanal 1 Gelb TX 30 Byte Nutzdaten
Danach Antwort vom Modul
Jetzt Kanal umschalten
Danach Antwort vom Modul
Alles Api Mode 1

Grüße
Wolfgang
»wgottlieb« hat folgendes Bild angehängt:
  • TX 16 Bit Kanalwechselklein.jpg

Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

131

Mittwoch, 2. Januar 2008, 19:27

Super Messung Wolfgang endlich mal handfeste Fakten zum Thema Kanalwechsel. :ok: :ok: :ok:

Wenn ich das richtig interpretiere wartest du das OK vom XBee ab, nachdem du den Kanalwechselframe gesendet hast (?)

Ich vermute das hier noch Zeitpotential vorhanden ist, wenn man den API Frame ohne OK Push ( Frame ID=0) sendet.
Überspitzt, alle 3 Frames direkt hintereinander dem XBee übergibt.

Wird wohl so nichts, weil die ja auch die Gegenseite den Kanalwechsel als Slave vollziehen und hierfür seine Zeit bekommen muss.
Interessant währe aber wie lange man die Aussendung den 2 Nutzdatenframe verzögern müsste damit auch dieser nicht auf taube Ohren trifft. Den Wert müsste man wohl experimentell ermitteln...

Zitat

Alles Api Mode 1
Meinst du den MAC Mode (MM=1) oder den API Frame Mode (AP=1)

Zitat

Diversity ist sicher super doch wirkt sich das leider negativ auf Kosten - Aufwand und die Größe des Empfängers aus!
Das hast du natürlich recht.
Auf der Senderseite habe ich mit den (Einmal-)Kosten und Baugröße aber kein Thema.
Auf der Empfängerseite ist bei den preiswerten Modellen sicherlich kein Diversity notwendig. Bei den (wenigen) teuren passt es schon mit den zusätzlichen 40€ für ein XBee.
Ein 2'es XBee lässt den Empfänger bei meinem jetzigen RX-Layout etwa 6mm dicker werden.

Thomas :w
Gruß

Thomas

132

Mittwoch, 2. Januar 2008, 22:22

Hallo Thomas,
so ganz ohne Antwort ist das schon riskant und nur bedingt realisierbar.
Wenn schon ein Kanalwechsel durchzuführen ist, will ich auch wissen ob das Ok ging und gegebenenfalls den Befehl wiederholen (nach Timeout).
Z.B. der Empfänger wartet sonst vergeblich auf Daten oder umgekehrt.
Zeitlich überlappend sende ich eh schon, wenn das 1. Byte der Antwort vom Kanalwechsel empfangen wurde starte ich den TX.
Inwieweit man das noch ausbauen kann weiß ich noch nicht.
Diesbezüglich fehlen jegliche Angaben im Datenblatt (wie so manches andere).
Wenn man das Modul wie du schreibst mit Daten ‚überfütterst’ verliert es den einen oder andern Befehl, das habe ich schon probiert!

Ja MM=1 u. AP1

Grüße
Wolfgang

Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

133

Donnerstag, 3. Januar 2008, 11:37

Hallo Wilhelm,

das OK des XBee als Antwort auf einen Befehl ist meiner Meinung nach nur das OK auf "Befehl richtig empfangen", aber nicht das OK für "Wechsel real durchgeführt"
Wenn das OK erst nach der Durchführung des Befehl kommen würde, dann währen die Kanalwechselzeiten ja nicht wirklich langsam zu nennen.

In meinen Augen hat es keinen großen Wert diese OK abzuwarten, da in der Kommunikation zwischen XBee und µC mit einer sehr geringen Fehlerrate rechnen kann, wenn man die realen Baudraten des XBee beachtet. Um eine Ende-Ende Auswertung (Timeout) des Erfolges der Kanalwechselaktion kommt man ja sowieso nicht vorbei.

Die 100Byte Buffer im XBee sind bei einer Fersteueranwendung in meinen Augen schon recht schwer zum Überlauf zu bringen. Zur Not kann man hier die Schnittstellensignale (DTR) des XBee auswerten.

Du hast recht, in vielen Punkten muss man über das Verhalten der XBee spekulieren oder diese experimentell herausfinden, anstatt dies in der Doku nachlesen zu können.

Gruß
Thomas
Gruß

Thomas

134

Donnerstag, 3. Januar 2008, 13:39

Hallo Leute,

klasse, dass sich was in die Richtung tut, danke für die Messungen Wolfgang!

Bei den Überlegungen sollte vielleicht erst mal gekärt werden, was das Ziel mit dem Springen ist. Entweder ein regelmäßiges, vorher synchronisiertes Springen nach jedem x-ten Frame oder eine Methode a la XPS, d.h. nur im Notfall ausweichen.

Bei beiden Verfahren ist es meiner Meinung nach nicht zielführend, jedes mal eine Bestätigung des eigentlichen Kanalwechsels zu machen. Dies sollte durch die normale Rückmeldung erfolgen. Sonst kommt man in die gleiche Zwickmühle wie XPS, dass man bei einem plötzlich verstopften Kanal ohne Strategie dasteht, weil man sich ja nicht mehr "einigen" kann.

Wie Thomas schon sagte: Ein wichtiger Wert wäre jetzt die Zeit, die es kostet, wenn man den Kanalwechsel ohne Bestätigung macht.

Gruß

Marc

135

Donnerstag, 3. Januar 2008, 13:48

blinder Kanalwechsel

Hallo,

ein Kanalwechsle ohne Ruckmeldung wird fällig wenn dieKomunikation sowieso unterbrochen ist. Also sollte im Vorfeld zwischen Sender und Empfänger Wechselkanäle vereinbart und notfalls nach festen Timing "blind" angesprungen werden.

Ich mich aber noch nicht weiter praktisch mit dem X-Bees beschäftigt seit dem die Simpelsoftware läuft. Einfach zu viel andere Sachen:-)
z.B war mein kleiner Indoor-Funk war erstmal viel wichtiger.

Gruß Sven

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »sven.stoecker« (3. Januar 2008, 13:49)


Hellmut1956

RCLine User

Wohnort: FFB

Beruf: Dolmetscher und Übersetzer für Technik

  • Nachricht senden

136

Montag, 14. Januar 2008, 23:35

Hat jemand Erfahrung mit den XBEE´s/XBee Pro´s und der Reichweite beim Betrieb in Booten? Wasser mit seinen Reflexionseigenschaften ist ja recht kritisch. Schon Mal dankeschön.
MfG
Hellmut

Dante

RCLine User

Wohnort: Rheinknie

  • Nachricht senden

137

Dienstag, 15. Januar 2008, 09:52

Das ist mit den XBees, wie mit den anderen 2.4GHz Systemen. Es funzt am See.

Leo
Trollfilter: Ein

138

Dienstag, 15. Januar 2008, 13:26

Hallo Hellmut,

kann bestätigen, dass es mit XBeePro auf dem Wasser klapp (meine ersten Tests hab ich nicht fliegend, sondern mit Schiffchen gemacht :D

Unter Wasser siehts allerdings trübe aus...
Mich wundern die Berichte von Leuten, die ihre UBoote mit den Anlagen fahren..
Mein Test mit Xbee auf 10mW ist bei knapp 10cm Wasser über Boot abgebrochen...

Grüße

Marc

139

Samstag, 19. Januar 2008, 13:41

Hallo,
wer von euch hat eigentlich ein fertiges flugtaugliches System damit schon Testflüge absolviert?

Wolfgang

140

Samstag, 19. Januar 2008, 20:40

Hallo Wolfgang,

bin mit meinem System schon vor einiger Zeit geflogen (steht auch weiter oben oder in einem anderen Thread...). Klappt problemlos.
Fertig ist das System aber nicht... Wird ein "Bastel-System" wohl auch nie sein :tongue:
Der Spaß daran ist es ja, Funktionen zu realisieren, die es bei käuflichen Systemen nicht gibt.
Sparen kann man nicht, wenn man die Arbeitszeit anschaut 8(

Wie siehts bei den anderen hier aus?
Auch so wenig Zeit gerade?

Nicht, dass das ganze hier einschläft... Die "Problemchen" der käuflichen Systeme spornen da doch auch an, oder??

Grüße

Marc