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.

Bruchflieger

RCLine User

Wohnort: 18km südl. der Lutherstadt Wittenberg

Beruf: Energieelektroniker / HWK-Meister E-technik

  • Nachricht senden

101

Dienstag, 6. November 2007, 20:42

Zitat

Original von FunFlightMarc
Hallo,

kurze Frage: Warum holt ihr so umständlich das RSSI über ein RC-Glied und ADC in den Atmega? Den Wert in 8 bit bekommt man im Frame doch quasi "gratis" mitgeliefert...
Nur im transparenten Modus nicht, der ist fürs Fernsteuern aber auch nicht so geeignet...


Nun, ich glaube das liegt daran, daß ich doch den Transparenten Modus nutze (so wie die Module aus der Schachtel kommen) und meine Komunikation mit dem Modul wirklich nur das Senden mittels Printbin - Befehl (Bascom) und das Empfangen mittels URXC-Interrupt abläuft.
Ich will allerdings versuchen das Programm so zu erweitern, daß ich auch aus dem Menü heraus per ausgesuchter AT-Befehle konfigurationen am Modul des Senders vornehmen kann - zB das Wechseln der Destination-Adresse...


Zitat

Eure Platinen sehen super aus. Muss unbedingt sehen, dass meine Ätzmachine wieder tut. Frage dazu: Welche Technik verwendet ihr zur Vorlagenerstellung (Laserfolien, Tinte..)?


Also ich hab mir mal einen Laserdrucker gegönnt, und dafür eine Packung mit 100 Folien für 25 Teuros. Der Belichter ist selbstgebaut - hab 3 UV-Röhren 8W bei Reichelt gekauft gehabt und dafür aus 3 Energiesparlampen ebenfalls 8W (oder gar 9W) die Vorschaltgeräte ausgebaut und das dann in ein Scannergehäuse eingebaut...
Grüße Dani.

Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

102

Mittwoch, 7. November 2007, 00:25

Heute war jemand da und hat.....

...einen kleinen gepolsterten Umschlag abgegeben.
Inhalt:
4 x* XBEE mit Koax Kabelpeitschen
und zwei Sätze 2mm Kontaktleisten

DANKE Wurpfel, auch für die gute Verpackung der Bauteil :ok:

Jetzt fehlt mir noch die Reichelt Lieferung und der Laminator (9€) aus der Bucht.

Zitat

Also ich hab mir mal einen Laserdrucker gegönnt, und dafür eine Packung mit 100 Folien für 25 Teuros. Der Belichter ist selbstgebaut - hab 3 UV-Röhren 8W bei Reichelt gekauft gehabt und dafür aus 3 Energiesparlampen ebenfalls 8W (oder gar 9W) die Vorschaltgeräte ausgebaut und das dann in ein Scannergehäuse eingebaut...
Ich werde die Direkt Toner Methode ausprobieren, deshalb der Laminator.
Meine letzte sebstgeätzte Platine vor >10 Jahren hergestellt, habe ich auch fotobelichtet und entwickelt. Ich habe an dieses Verfahren keine gute Erinnerung. Toleranzen durch die Belichtungslampe (Gesichtsbräuner), dem Abstand zur Platine, dem Alter der Fotobschichtung und zuletzt dem Entwickler, haben meist reproduzierbare Ergebnisse verhindert. Wenn man 2-3 Platinen/Monat mit der Methode erstellt, hat man sicher den Bogen im 2.en Monat raus. Aber wenn man nur alle Jubeljahre mal eine Platine macht, finde ich ist das nix.


Was mir an den bisher vorgestellten Lösungen auffällt, das sie von der Hardware teilweise sehr ähnlich sind, aber eben nicht miteinander funktionieren können.
Das ist natürlich jedem sein gutes Recht, seine Lösung zu schaffen. Ich möchte aber das wir in diesem Thread nicht aus den Augen verlieren, daß das Ergebnis einem Standart entsprechen soll. Ziel des Standarts ist es, das ich mit meinem Sender (ich fliege meist Segelflugzeuge) eben auch die den Seenotrettungskreuzer von meinem Nachbarn steuern kann. Steuern muss gehen, aber die speziellen Erweiterungen um das Radar am Mast einzuschalten sind nicht Gegenstand des Vorhabens. Wohl werden die notwendigen offenen Schnittstellen und ein Anwendungstransparentes Protokoll zur Verfügung gestellt. Auch eine Servo NG (z.B. ein I2C Openservo) sollte damit ohne Einschränkung nutzbar sein.
Ich hoffe ich werde es diese Woche noch schaffen, meinen Protokollentwurf mal graphisch aufzuarbeiten um ihn hier dann gemeinsam zu diskutieren und fest(er) zu zurren.
Gruß

Thomas

Dante

RCLine User

Wohnort: Rheinknie

  • Nachricht senden

103

Donnerstag, 15. November 2007, 09:38

Wie sieht's denn so aus?
Ich würde ja gerne mal eine Grossbestellung an Boards aufgeben :shy:

Leo
Trollfilter: Ein

104

Donnerstag, 15. November 2007, 12:04

Vielleicht ist diese Info ja für jemanden der Selberbastler von Nutzen:

http://www.mikrocontroller.net/topic/41341#571326
"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

105

Donnerstag, 15. November 2007, 12:15

Hi leutz


es könnte sein dass ich schon ne ecke weiter bin ;)
https://sourceforge.net/forum/forum.php?forum_id=741603

zz bin ich am datensammeln, dann wird eine routertabelle erstellt damit die knoten gemäss ihrer funktion gebrannt werden können.





meine RC wird so funzen:
funktion/einbauort wählen
AVR brennen oder fertig kaufen
knoten einbauen, servos anstecken
mittelwert/failsafe und endanschläge teatchen
loslegen


wer will kann seinen knoten auch selber proggen, es stehen 65`536 funktionen (servos/LEDs/schalter) mit je 16bit auflösung bereit.
wenn sich leute finden die ihr funktionsmodell veröffentlichen können busknoten dafür geproggt werden.


die übertragung wird für flugmodelle in echtzeit komprimiert, funktionsmodelle nutzen WLAN oder XBEE mit voller bitbreite.


das kompressionsverfahren erlaubt vier hauptfunktionen (gas, SR, HR, QR) plus sieben schalter mit sovielen servos wie benötigt und einer latenz von einer framerate. alle weiteren funktionen werden multiplext und benötigen zwei frames zum übertragen.


es ist egal womit gesendet wird, es würde auch mit xxMHz-funken und achtkanalRX funzen :angel:
das komprimierte protokoll ist mit FEC abgesichert, es können zwei fehler korrigiert oder mist mit 100% sicherheit als solcher erkannt und verworfen werden.


aufgrund der antworten schreibe ich SW für folgende busknoten:
boote.basic: ruder, motor, licht, sound (ATt15)
boote.zweimot_regler: Hbrückenansteuerung für zwei bürsties, temperatur- und stromüberwachung (ATt26 oder ATm48)
boote.zweimot_ruder: 2stk ruder, licht (ATt15)
boote.dreimot: drei ruder, drei motoren, zwei stepper, bugstrahlruder, sechs schalter (ATt26 oder ATm48)
boote.licht: 16schalter mit stromüberwachung
boote.stepper: vier bipolarstepper
boote.stepper_referenz: zwei stepper und endlagentaster

motorflieger.trainer_rumpf: drossel, SR, 2stk HR, SK (ATt15)
motorflieger.trainer_flügel: 2stk QR, 2stk Licht (eingebaut ist hier zb ein ladeklappenmischer inkl. HR und differenzierung)

shocky.basic: SR, MOT, HR, QR (ATt15)

zweiachssegler.basic: SR, HR, SK, licht (EZFW)
zweiachsegler_flügel: 2stk bremsklappen
dreiachssegler_2Kflügel_WK-QRbremse
dreiachssegler_2Kflügel_stoerklappe
dreiachssegler_4Kflügel_links_butterfly
dreiachssegler_4Kflügel_rechts_butterfly


sensor.basic: LED für alarm, TEMP, BAT, TURN (ATt15)
sensor.SCP1000: auslesen der 17bit druckdose mit SPI, mittelwert, steigen, temperatur
sensor.IMU5: 2gyros, 3accelometer auslesen, kalmanfilter applizieren (crumb168)
sensor.GPS: NEMA protokoll wird in richtungsvektor umgerechnet (speed, winkel), position absolut, anzahl sat, fehlermeldungen (ATm48)



ne heidenarbeit :evil:


gerne nehme ich eure funktionsbeschreibungen an, ne PN reicht.
ihr erhält dann ein formular zum ausfüllen und zurückmailen.
ich frage nur nach modelldaten wie name/hersteller, funktionen und mischer :shy:
bin schon zu alt zum spielen.. macht aber gleichwohl spass ;-)

o.dippel

RCLine User

Wohnort: Büdingen / Hessen

Beruf: Software-Developer

  • Nachricht senden

106

Donnerstag, 15. November 2007, 20:45

Hi Sven,

eine etwas verkürzte Version deiner Timer-Funktion:

ISR(TIMER1_COMPA_vect) {
if (PPM < 5) {
PORTB = (1<<PPM + 1);
OCR1A = OCR1A + RX[PPM];
PPM++;
} else {
PORTB = 0;
OCR1A = OCR1Atemp = (OCR1Atemp + 20000);
PPM = 0;
}
}

etwas kleiner unbd schneller :-)

MFG
Olli

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »o.dippel« (15. November 2007, 20:46)


107

Samstag, 17. November 2007, 12:30

Empfänger

Hi,

ich konnte es nicht lassen und habe dem "SLOW"-Empfänger nun noch einen FETten Schaltkanal verpasst. Das wurde notwendig weil meine Indoor-Vampir noch einen Bürstenmotor hat:-)

www.jetcontrol.de/2g4slow.zip

O.K, der ist jetzt nicht mehr richtig Slow und heißt bei mit (intern) ab sofort "6K".
"Slow" ist dann eher die Bauweise von Dani-Bruchflieger die ich dann wohl mal frech kopieren muss:-)
Z.Z entsteht noch eine einfaches Funkmodul für meine Futaba FC18. Die Hallensaison geht los und da will ich 100% 2G4 fliegen.

@olli

Ja, deine Cod sieht besser aus als meiner. Ich hatte aber immer in Hinterkopf,dass nicht alle Servos auf einem Port liegen müssen. Aber auch du verschnekst Rechenzeit:-)

OCR1A = OCR1A + RX[PPM++];

Spart eine Zeil, und Rechenzeit. Habs im Assembler nachgeschaut.
Im meinem code lassen sich noch mehr Stellen zum Optimieren finden odurch der Code kurz und simpel wird. z.B


ISR(USART_RXC_vect)
{
RX[(RX[RXpos]++)&15]=UDR;
}


Also los.

Gruß Sven

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »sven.stoecker« (17. November 2007, 13:00)


Bruchflieger

RCLine User

Wohnort: 18km südl. der Lutherstadt Wittenberg

Beruf: Energieelektroniker / HWK-Meister E-technik

  • Nachricht senden

108

Sonntag, 18. November 2007, 15:04

Hi Sven,

kannst du gern tun, allerdings hab ich seit den Fotos noch ein paar Optimierungsmöglichkeiten gefunden und außerdem noch Lötpads für die Kanäle 7 und 8 hinzugefügt. (das Pad für den optionalen Kanal 6 ist ja das zum ISP Programmieren benötigte SCK und etwas abgesetzt von den ersten 5 bereits vorhanden.)
Auf den Fotos oben geht noch ein weißer Draht gleich durchs Depron weg - der führt direkt zu Platine des Motorreglers an den Akku + Anschluß (hab an der Selle den Schrumpfi etwas gelöst, den Draht von außen durchgefädelt und dann dort angelötet...)

PS: Ich zeichne meine Layouts nur noch mit Sprint Layout die Bedienung ist Kinderleicht - in der V5.0 kann man jetzt auch alle Bauteile frei drehen und auch 2 Seitige Platinen mit je 2 Lagen erstellen (insgesamt also 4 Ebenen).
Außerdem kann man damit auch Platinen bis zu 300mm Kantenmaß erstellen, was bei eagle nur in den extrem teuren Versionen möglich ist...
Grüße Dani.

Bruchflieger

RCLine User

Wohnort: 18km südl. der Lutherstadt Wittenberg

Beruf: Energieelektroniker / HWK-Meister E-technik

  • Nachricht senden

109

Sonntag, 18. November 2007, 20:25

Back to Topic!

Ziel des Threades war es ja nicht, daß hier jeder nur seine Eigenentwicklungen vorstellt, sondern, daß wir uns auf wichtige Grundparameter einigen möchten.
- Das Wichtigste dabei ist mit Sicherheit, daß jeder eine vergleichbare Hardware hat. Daher würde ich gern folgende Parameter für einen Empfängerbaustein vorschlagen, die dann (wenn die Mehrheit zustimmt) als Grundlage für die fortschreitende Projektentwicklung dienen sollen.

Prozessor: Mega8 oder Pinkompatibel.
# Servos am Port B beginnend mit Portb.0
# Komunikation mit Funkmodul per UART an den Ports D.0 und D.1
# I2C Schnittstelle mit je 10kOhm Pullup an den Ports C.4 und C.5 (damit gehen auch 2 ADC-Eingänge Flöten, aber wenn SMD Prozessor genutzt wird, hat dieser 2 ADCs mehr (ADC6 und ADC7))
# restliche ADC Eingänge bleiben für Meßaufgaben die für den Rückkanal benutzt werden können reserviert - Ausnahme die 2 Pins für I2C
ADC-Nutzung Vorschlag:
ADC 0 für RSSI-Signal der Xbee
ADC 1 für Akkuspannung
ADC 2 Motorstrom (z.B. Messung per Shunt und nachfolgende Aufbereitung durch OPV) - nicht am Slowfly-Empfänger

Empfängerbausteine für größere Modelle sollten unbedingt den I2C Bus bereithalten, da dort weitere Sensoren wie z.B. der SCP1000 Luftdrucksensor oder div LM75 Temp.Sensoren angeschlossen werden können, oder wir erwägen dort dann einen größeren µC zu verwenden, der z.B. noch eine 2. UART für GPS-Module bereitstellt und SPI für direktes Loggen auf MMC.

Details, die jeder selbst entscheiden können sollte:
# Welchen Spannungsregler für 3,3V nutze ich? (ich z.B hab den ZLDO 33 T8TA von Reichelt...)
# Prozessor auch auf 3,3V oder doch auf 5V
# wenn Proz. auf 5V wie wird Pegelwandlung realisiert (bei mir funzt R=470 Ohm und Z-Diode 3,3V hervorragend auf der TXD_leitung des µC zum Xbee - der RXD-Eingang des µC braucht dabei keine Pegelwandlung, da 3,3V über der Wahrnehmungsschwelle des µC liegen.)
# Wieviele Servoausgänge will ich vorsehen? (Ich habe im Layout jetzt alle 8 Portpins des Port B als Lötpad herausgeführt, was die Verwendungsvielfalt deutlich erhöhen dürfte.)
# Anschluß der Servos per Lötpad oder Steckanschluß?


Eine Frage, die ich dabei noch hätte:
Wenn der Prozessor auch auf 3,3V arbeitet, muß das PWM-Signal für die Servos auf 5V "Pegelgewandelt" werden?

Der Nächste Schritt ist dann ja wohl auch der Schierigste: Das Übertragungsprotokoll!
Ich persönlich arbeite mit Start- und Stopbytes, mit deren Hilfe ich die Datenpakete kennzeichne als Steuerdaten, Trimmdaten, Failsafedaten, Meßdaten und dann noch div Steuerbytes, die bestimmte Aktionen im Empfängermodul oder auch im Sender auslösen, da ich die Trimmung etc im Empfänger untergebracht habe, und diese vom Sender aus dem Menü heraus programmieren kann und dann per Steuerbyte das Brennen ins Eeprom aktiviere.
Ich weiß auch, daß dies nicht die effektivste Methode ist, aber mir ist nunmal nichts besseres eingefallen... zumal ich ja nicht einfach nur das PPM vom Sender sample und hochschicke, sondern im Sender die gesamte Elektronik ebenfalls ersetzt habe.
Da meine Zielsetzung beinhaltete, die komplette Intelligenz im Modell unterzubringen und diese vom Sender aus editierbar zu gestalten, war es zwingend nötig ein Übertragungsprotokoll vorzusehen, das sich nicht nur auf das Übertragen der Steuerdaten beschränkt, sondern auch das Bearbeiten der Modellspezifischen Einstellungen im Modell ermöglicht - z.B. Trimmung, Servoreverse, Failsafe, Mixer etc.

Daher möchte ich euch ebenfalls bitten, bei der Erarbeitung eines Übertragungsprotokolls eine Erweiterbarkeit um diese Funktionen von vornherein in die Überlegungen mit einzubeziehen!
Grüße Dani.

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »Bruchflieger« (18. November 2007, 20:26)


110

Sonntag, 18. November 2007, 21:57

Hardware

Hi,

>Eine Frage, die ich dabei noch hätte:
>Wenn der Prozessor auch auf 3,3V arbeitet, muß das PWM-Signal für die Servos auf >5V0 "Pegelgewandelt" werden?

nein.

Für alle die neu ins Thema AVR und C einsteigen sollten Deine Vorschläge bindend sein!

Die Hardware würde ICH bis auf den Prozessor (sollte schon eine Mega sein:-) nicht so eng sehen.
Weil I2C nicht auch noch über Interupt laufen sollte und nicht zeitkritisch ist können wir das in der Hauptschleife abarbeiten. Folglich ist jeder Pin geeignet. Einfach 2 #define und gut.

Gleiches gilt für die Belegung der ADC und in Endeffekt auch für die Servopins. Als einziger Interupt darf der zur Erzeugung der Servoimpulse etws länger dauern und damit ist das setzen einzelner Pins kein Problem.

Für viele Modelle ist I2C uninteressant. Ich denke da an Shocky, Hubschrauber, Schaumwaffeln,RC-Cars.... All das Zeug was viele Bastler nutzen.

Wildes Tauschen der Pins am Mega ermöglicht einfachere Leiterplatten mit dem Nachteil der "Hardware.ini"

Es sollt hier ums Protokoll gehen. Dazu müssen die Mitmacher über funktionierend Hardware verfügen. Deshalb auch die leicht nachbaubaren und dokumentierten Bauvorschläge.

>Ich persönlich arbeite mit Start- und Stopbytes,

Ich auch und ich habe sogar mit '0' angefangen:-)
Mach doch bitte mal eine Liste deiner Datenpackete.

Gruß Sven

wurpfel1

RCLine User

Wohnort: CH-rheintal

  • Nachricht senden

111

Montag, 19. November 2007, 12:21

hi leutz


ich arbeite mit immer der gleichen HW, einem ATt15.
der ist für die meisten meiner modelle völlig ausreichend.
mit dem I2C kann im bedarfsfall sehr einfach erweitert werden, einfach anstecken und ne neue routertabelle laden, fertig ;)


ein shocky besitzt vier steckplätze und kein I2C, der funflyer nutzt den gleichen ATt15-busknoten mit einer anderer routertabelle für zwei I2C-OPENSERVOS im flügel plus I2C-BLcontroller..


möchte ich eine schalterbank/stepper wird der ATt15 mit vierfachoptokoppler, darlington-endstufe oder L6205-Hbrücke ge"pimpt" und einfach an den I2Cbus gesteckt.



wenn ich ein altes modell neu ausrüste verbaue ich in jede flügelhälfte einen busknoten, das räumt mit dem kabelkaos radikal auf, es ist nur noch eine MPX-kupplung notwendig.
auch hier reicht ein ATt15-knoten für eine komplexe zweimot mit EZFW, flaps, QR und motor.




das ganze bringt eine erhebliche vereinfachung des ganzen: für 90% der aufgaben reicht ein typ hardware :evil: die zweitletzten 5% sind durch bestücken mit einem leistungsschalter lösbar.

bei funktionsmodellen mit vielen schaltern/steppern/motoren/licht am gleichen einbauort nutze ich einen ATt26/ATm48 um 14-16verbraucher bzw servos zu schalten.



PS
OPENSERVO nutzt den ATm48. die originalservoplatine wird durch ein 15.-€ SMDboard ersetzt, fertig.
I2Cregler gibts im mikrokopterprojekt oder man baut sich einen sensorBLregler nach AVRnote443 :shy:
bin schon zu alt zum spielen.. macht aber gleichwohl spass ;-)

o.dippel

RCLine User

Wohnort: Büdingen / Hessen

Beruf: Software-Developer

  • Nachricht senden

112

Montag, 19. November 2007, 17:01

Hi Leute,
mein vorschlag:

1 Frame:
2bit Startbits

8bit Empfänger-ID
// Echtzeit-Daten (0-16)
4bit Anzahl Realtime-Channels
n * 11bit Realtime-Channel
// Sonstige-Daten
8bit Geräte-Adresse (0 = Empfänger + 255 Devices)
8bit Befehl
8bit Daten

1bit Stopbit


Echtzeit-Daten werden ständig übertragen !
Sonstige Daten (nur 1 Befehl pro Frame) nur bei Änderung oder immer der "älteste" (am längsten nicht übertragener) Befehl.

Vieleicht vor dem 8bit Befehl noch eine Sequenz-Nummer senden, sont muß man (z.B. für ein Nebelhorn) erst den Befehl "Anschalten" senden, und dan den Befehl Ausschalten.


aber...
bei einer Konfiguration im Empfänger, sollte man vieleicht etwas umdenken, und keine "Funktionen" senden, sonder "Schalter-Zustände" ???
Wenn keine Konfiguration im Sender sein sollte, muß man dem Empfänger sagen können,
das er bei betätigung von Schalter x, Funktion y starten soll,
und nicht dem Sender, wenn Schalter x dann Gerät y den Befehl z senden.

Bin aber noch nicht überzeugt von dieser art der Konfiguration (Empfänger-Seitig).
hat aber seine Vorteile (Weniger Echtzeit-Daten, z.B. bei 2 Querruder-Servos)

DBD
Olli :w

Bruchflieger

RCLine User

Wohnort: 18km südl. der Lutherstadt Wittenberg

Beruf: Energieelektroniker / HWK-Meister E-technik

  • Nachricht senden

113

Montag, 19. November 2007, 20:43

Hi Sven,
ich hab mal unten meine ganzen Steuerbytes / Startbytes angehängt.
Steuerbytes werden allein übertragen ohne nachfolgende Daten und werden zB benötigt für einfache Dinge wie den Befehl die Konfigurationsdaten im Modell-EEprom zu brennen. Nach dem Brennen wird je nach dem, ob es erfolgreich war oder nicht ein Steuerbyte zurückgesandt...
Wenn Modelldaten bearbeitet werden, werden die neuen Daten zum Modell gesendet mit einem Startbyte und nachfolgendem Stopbyte. Diese werden im Modell in Variablen zwischengespeichert und nochmal zum Sender zurückgesendet mit neuem Start- / Stopbyte. Im Sender wird das verglichen und wenn korrekt, wird ein entsprechendes Steuerbyte gesendet, daß die empfangenen Daten verwendet werden können...
Ich weiß, das ist recht kompliziert, aber die Datensicherheit ist mir das wert...
Solche Routinen hab ich momentan für Trimmung und Servoreverse sowie für Failsafe. Momentan besteht ein Datenpaket aus 1 Startbyte, 5 Datenbytes und 1 Stopbyte. Ich werde das aber demnächst auf 7 Datenbytes erweitern für 6 Proportionalkanäle und 8 Schaltfunktionen.

Noch eine Besonderheit:
Im Modell wird alle 3 Servoimpulsdurchläufe ein Steuerbyte erzeugt, auf das der Sender dann mit dem Senden der Steuerdaten reagiert. Das heißt, Steuerdaten werden nunr dann gesendet, wenn sie vom Modell angefordert werden. Dadurch kann ich mit einfachen Mitteln im Modell den Failsafe aktivieren und im Sender ebenfalls eine gestörte Verbindung anzeigen.

Nich zu verwechseln Steuerdaten werden auf Befehl des Modells gesendet und dort sofort in Servostellwerte umgerechnet. Die Spezialroutinen mit Zwischenspeichern und Rücksenden sind nur für Daten, die Modelleigenschaften betreffen, und die danach ins EEprom gebrannt werden können/sollten.

Ich hoffe, daß ich die SB's einigermaßen eindeutig beschriftet habe... eine 1 am Ende des Constantennamens kennzeichnet ein Startbyte eine 2 das Stopbyte ohne zahl sind die Steuerbytes...

'** am Modell eingehende SB **
'* Steuerbytes *
Const Sbtrimmsend = &HAB 'Sender fordert Trimmdatensatz zum editieren im Menü an
Const Sbtrimmright = &HBA 'Zurückgesandte trimmdaten sind korrekt
Const Sbfssend = &HAD 'Sender fordert Failsafedaten an zum editieren im Menü
Const Sbfsright = &HDA 'zurückgesandte Failsafedaten sind korrekt
Const Sbresetfstest = &HAE 'Failsafetestmode deaktivieren
Const Sbsetfstest = &HEA 'Failsafetestmode aktivieren zum editieren im Sender - Anforderung neuer Steuerdaten wird unterbunden, wodurch Failsafe ausgelöst wird.
Const Sbbrenn = &HAC 'Trimm und Failsafedaten ins Eeprom brennen
'* Start- /Stopbytes *
Const Sbtrimmdaten1 = &HFA 'Trimmdaten folgen
Const Sbtrimmdaten2 = &HAF 'Trimmdaten ende
Const Sbfsdaten1 = &HFC 'Failsafedaten folgen
Const Sbfsdaten2 = &HCF 'Failsafedaten ende
Const Sbsteuerdaten1 = &HFE 'Steuerdaten folgen
Const Sbsteuerdaten2 = &HEF 'Steuerdaten ende

'vom Modell ausgehende SB
'* Steuerbytes *
Const Sbsteuerdatenanfordern = &HD1 'Modell benötigt aktuelle Steuerdaten
Const Sbburnerror = &HD3 'EEprombrennen fehlerhaft
Const Sbburnwell = &HD5 'EEprombrennen erfolgreich
'* Start- /Stopbytes *
Const Sbmessdaten1 = &HB1 'Meßdaten folgen
Const Sbmessdaten2 = &H1B 'Meßdaten ende
Const Sbtrimmsend1 = &HF1 'Trimmdatensatz zum editieren folgt
Const Sbtrimmsend2 = &H1F 'Trimmdatensatz zum editieren ende
Const Sbtrimmpruefen1 = &HF3 'Trimmdaten zum überprüfen folgen
Const Sbtrimmpruefen2 = &H3F 'Trimmdaten zum überprüfen ende
Const Sbfssend1 = &HF5 'Failsafedatensatz zum editieren folgt
Const Sbfssend2 = &H5F 'Failsafedatensatz zum editieren ende
Const Sbfspuefen1 = &HF7 'Failsafedatensatz zum überprüfen folgen
Const Sbfspuefen2 = &H7F 'Failsafedatensatz zum überprüfen ende

Ich habe extra Hexwerte genommen, die etwas Abstand zueinander haben und die im Betrieb nur selten als Daten vorkommen - also nicht in Neutral oder Endstellung sondern irgendwo dazwischen wodurch ein versehentliches Durcheinanderwürfeln nur in extremen Ausnahmefällen vorkommen könnte.
Grüße Dani.

Dieser Beitrag wurde bereits 3 mal editiert, zuletzt von »Bruchflieger« (19. November 2007, 20:58)


wurpfel1

RCLine User

Wohnort: CH-rheintal

  • Nachricht senden

114

Montag, 19. November 2007, 22:49

Hi leutz

nutzt doch den APImode des XBEE, da ist schon vieles sicherheitsrelevantes pfannenfertig gelöst worden. werden dann noch die knüppelbefehle mit FEC (fehlerkorrektur) codiert kann kaum mehr was passieren.
der rückkanal bleibt dann von irgendwelchem failsafegeschwätz befreit!


gibt irgendwann neue HW schreibt man einen anderen funkframedecoder...



nochmals :D
je kürzer die info desto grösser die chance dass sie ankommt :w

es ist reine verschwendung mehr als die vier knüppelstellungen und ne handvoll schalter zu übertragen :wall:

beim ansatz "alle intelligenz im modell" ist es ne kleinigkeit 10stk QRservos sinnrichtig ausschlagen zu lassen.. die übertragung der achseninfo reicht zusammen mit der gespeicherten konfiguration vollkommen dazu aus ==[]

mit FEC kann sofort entschieden werden ob die info korrekt, korrigierbar oder noch viel wichtiger, FALSCH ist. dazu muss nicht nachgefragt werden, diese info ist in FEC enthalten..


failsafe würde ich zwingend in HW lösen: AVRs besitzen einen HWwatchdog, ne ablaufende zeituhr. das rettet ein modell nach programmabstürzen oder EMCproblemen UND beim ausbleiben korrekter funksignale :shy:



um das EEPROM zu brennen schalte ich vom live-betrieb in einen konfigurationsmodus. der freischaltcode benutzt die HW-ID des funkmoduls zum verifizieren. nun können weg, drehrichtung und failsafe eingestellt und ins EEPROM geschrieben werden.
mir reicht ein vierwegschalter und ne (zweifarbige)LED auf dem sender. ein grafikdisplay ist zwar nett, lieber ist mir wenn ich direkt am modell sehe was geht :shy:
will man nach der landung nur die trimmung speichern gibts einen zweiten code.


PS
ihr könnt soviele voreingestellte trimmpositionen und flugphasen wie ihr wollt ablegen: auf einem 1.-€ I2C-EEPROM haben mehrere zehntausend platz :angel:
bin schon zu alt zum spielen.. macht aber gleichwohl spass ;-)

Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

115

Montag, 19. November 2007, 22:52

Hallo Dani,

danke für deine Mühe für die Dokumentation deines Formates. Das Protokoll ist sehr schlank, so das wenig Bytes durch die Luft gehen.
Was mich aber ein wenig stört ist, vorbehaltlich das ich alles richtig verstanden habe, es werden Vorgänge mit einem Datenpaket "vorbereitet" und im nächsten folgt die "Aktion´" mit den Daten (z.B. trimmdaten folgen......trimmdaten ende).
Mir fehlt da ein wenig die Transaktionssicherheit. Was passiert wenn Paket 1 fehlerfi empfangen wird und Paket 2 nur verstümmelt empfangen wird?
In welchem Stati befindet sich da der RX?

Ich halte es für sinnvoller Aktionen wie Trimdaten/Failsavedaten/Servodaten in einem Frame zu übertragen und durch die Checksumme über den kompletten Frame die Integrität der Aktion sicher zu stellen.

Ich habe die Ideen/Wünsche aus diesem Thread nun mal in den ersten ordentlichen Entwurf für das Openformat formuliert und dokumetiert. Ich hoffe das sich möglichst viele dort wiederfinden und aktiv an der Gestaltung mitarbeiten.

Thomas
Gruß

Thomas

Bruchflieger

RCLine User

Wohnort: 18km südl. der Lutherstadt Wittenberg

Beruf: Energieelektroniker / HWK-Meister E-technik

  • Nachricht senden

116

Dienstag, 20. November 2007, 04:37

Hi Space,

hab jetzt noch nicht den Link gelesen.. nur soviel als erstes:
Im Prinzip (weiß jetzt nicht wie du Frame definierst) hab ich auch einen Frame:
Startbyte 5 Datenbytes und Stopbyte - die StartBytes in Kombination mit den Stopbytes definieren den Inhalt des Frames für den jeweiligen Empfänger.

Steuerdaten, die falsch ankommen da hab ich erstmal keine Fehlererkennung bei - hatte aber auch noch keine Probleme.
Modelldaten (Trimmung Failsafe etc. werden nach dem Senden zum Modell wieder zum Sender zurückgesandt und überprüft. Wenn richtig wird ein Steuerbyte allein geschickt, was die Zwischengespeicherten Werte in das Array der verwendeten Werte umspeichern läßt (blöd umschrieben)... - Wenn Daten falsch zurückkommen werden nochmal korrekt hochgesandt und wieder zurück und neue Prüfung - bis irgendwann korrekt zurückgekomen sind...

Wie gesagt - ist nicht unbedingt die eleganteste Lösung, aber mir ist nichts anderes eingefallen....
Grüße Dani.

Space

RCLine User

  • »Space« ist der Autor dieses Themas

Wohnort: Hasloh b. Hamburg

  • Nachricht senden

117

Dienstag, 20. November 2007, 22:07

Meine Rückmeldung zu der von mir erstmalig verwendeten Direkt Toner Methode zur Leiterplatten Herstellung:

Die Qualität des Ergebnisses hätte ich nicht so gut erwartet. Auch die erzielbare Deckungsgleichheit zwischen Oper/Unterseite ist nicht schlecht. Lässt sich schwer messen, aber mehr als 0,2mm ist die Abweichung an den Bohrlöchern bei beiden bisher erstellten Platinen nicht.
Ich habe beim "Aufschmelzen" des Toners auf die rohe Leiterplatte vorher eine Tasche aus dem Ober und Unterseiten Ausdruck auf einer von unten durchleuchteten Glasplatte geklebt. In diese Tasche wurde dann die Leiterplatte gesteckt und das ganze 4-5 mal durch den gepimpten Laminator gesteckt --> Super, ablösenden Toner vom Kupfer ist kein Thema.

Ich habe bei dem TX Modul als Test die Masseflächen als feines Raster definiert. Das war kein Problem, kommt alles sauber raus nach dem Ätzen.

Als Papier hat sich das Aviator Papier bewährt. Es produziert durch seine Festigkeit keinen Papierstau im Drucker. Durch die Fotobedruckung, mit grossen gelichmässigen hellen (Himmel-)Flächen, lassen sich Ober/Unterseite bei Durchleuchtung sauber aufeinander scheiben. Und der Hochglanz saugt den Toner nicht auf.
»Space« hat folgendes Bild angehängt:
  • RX-TX.jpg
Gruß

Thomas

wurpfel1

RCLine User

Wohnort: CH-rheintal

  • Nachricht senden

118

Donnerstag, 22. November 2007, 09:22

perfekt!

das argument der schwierigen platinenherstellung trifft nicht mehr zu.


jetzt fehlt dir nur noch ein VIAs-verkupferer ;)





ich benötige einen SMDmanipulator zum löten. linearführungen, motoren und kameras habe ich mir schon mal besorgt :D
bin schon zu alt zum spielen.. macht aber gleichwohl spass ;-)

Dante

RCLine User

Wohnort: Rheinknie

  • Nachricht senden

119

Sonntag, 9. Dezember 2007, 11:49

Na, wie sieht es denn aus mit den SMDs???

Leo
Trollfilter: Ein

Bruchflieger

RCLine User

Wohnort: 18km südl. der Lutherstadt Wittenberg

Beruf: Energieelektroniker / HWK-Meister E-technik

  • Nachricht senden

120

Sonntag, 9. Dezember 2007, 21:12

Hi,

ich habe gestern auch mal wieder was ätzen müssen, und in Ermangelung von Reichelt-Katalogen etc. hab ich mal ganz frecher weise ganz stinknormales Kopierpapier für die Direk-Toner-Methode genommen, das Bügeleisen auf die höchste Temp. eingestellt und dann in warmen Fitwasser abgerubbelt - hat auch tadellos funktioniert - O.K. die Massefläche ist schon etwas angegangen, aber die Leiterbahnen selber sind top...
Grüße Dani.