TTTT-Platine EVO II

[Carsten]

@ Tanis, das hört sich nach einer langen Nacht bei Dir an

Wieviel sonder Kanäle wären möglich diese mit anzusteuern, z.B. Anhängerkupplung, Seilwinde, zusätzliches Servo, etc...

Ich bin schon weiter gespannt
_________________
Gruß Carsten

[leaner]

@Tanis
ja das klingt doch richtig nach Fortschritt! Freut mich
Bin gespannt wie das weiter geht ...

[Tanis]

Quote:

---

Wieviel sonder Kanäle wären möglich diese mit anzusteuern, z.B. Anhängerkupplung, Seilwinde, zusätzliches Servo, etc...

---

Zurzeit werte ich nur die ersten 4 Kanäle des PPM-Signals aus, es werden aber 5 Kanäle á 8 Bit übertragen. Somit wären bei 4 Propokanälen noch ca. 255 Schaltkanäle realisierbar..... man muss nur nen PIC mit sovielen IO's finden


Gruß

--- Tanis ---


_________________
---

Resistance is futile!

[Carsten]

Quote:

---

Quote:

---

Wieviel sonder Kanäle wären möglich diese mit anzusteuern, z.B. Anhängerkupplung, Seilwinde, zusätzliches Servo, etc...

---

Somit wären bei 4 Propokanälen noch ca. 255 Schaltkanäle realisierbar..... man muss nur nen PIC mit sovielen IO's finden


Gruß

--- Tanis ---

---

So 200 Schaltkanäle würden mir reichen, da kann ich gut auf 55 Schaltkanäle verzichten

Manomanoman... da kann ich schon wieder von zieg Projekten träumen

_________________
Gruß Carsten

[janniz]

Quote:

---

Ich habe bis jetzt einen einfachen 'IR-Sender' gebaut. welcher das Signal einer PPM-FB in ein PCM-Telegramm umwandelt

---

Jetzt mal für die ganz doofen wie mich: heißt das, es wäre somit möglich eine Art "IR-Modul" für die Helios zu bauen?
_________________
PROTECT ME FROM WHAT I WANT

[Tanis]

Quote:

---

Quote:

---

Ich habe bis jetzt einen einfachen 'IR-Sender' gebaut. welcher das Signal einer PPM-FB in ein PCM-Telegramm umwandelt

---

Jetzt mal für die ganz doofen wie mich: heißt das, es wäre somit möglich eine Art "IR-Modul" für die Helios zu bauen?

---

Ich kenne jetzt zwar die Anschlussbelegung der Helios nicht, aber ich sage trotzdem mal: JAPP!!!



_________________
---

Resistance is futile!

[ohrange]

kaum schaut man mal ein Wochenende nicht hier rein, schon passieren wunderbare Dinge!

Quote:

---

Quote:

---

- Es werden ‚Telegramme’ gesendet, welche eine ID, die Kanalwerte, und eine Checksumme bzw. Parity Bits enthalten.
- Die ‚Telegramme’ werden bei jeder ID ‚zeitversetzt’ mit unterschiedlichen Intervallen gesendet. Die Intervalle werden so gewählt, dass in einem bestimmten Zeitraum (sagen wir mal 50 mS) jede ID mindestens 1 mal ihr Telegramm ohne Kollision senden kann...

...Jetzt heißt es ein Muster oder Algorithmus zu finden, der selbst bei nicht synchronisierten Sendern 4 Telegramme (ich plane 4 ID’s) kollisionsfrei in 50 mS überträgt. Ein scheinbar unlösbares Problem…

---

Das lässt sich glaube ich so einfach nicht machen, habe ein bisschen geknobelt, aber bei 4 "Telegrammen" a 5 ms bei nicht synchronisierten Sendern klappts nicht, dass jedes der 4 Telegramme einmal je 50 ms ohne Überlagerung empfangen werden kann.

Wenn man jetzt aber den Sender mithören lassen kann, könnte man sich folgende Sequenz vorstellen:

- der Sender "hört", ob ein anderer Sender sendet. das tut er je nach ID mit unterschiedlicher Länge (z.B. ID1= 2ms;ID 2=3 ms; usw)
-wenn lange genug Ruhe war, sendet er sein Telegramm
-und ist dann still (für die maximale Zeit, die alle 4 Telegramme einschl. der entsprechenden Watrezeiten brauchen)

Die unterschiedliche Wartezeit stellt sicher, dass die Sender nicht gleichzeitig loslegen und so durcheinanderquatschen, die Wartezeit nach dem Telegramm, dass alle zu Wort kommen. Bei den o.g. Annahmen würde also eine ganze Sequenz also für z.B. ID 1 so aussehen:
2 ms Hören + 5 ms Senden + (3+5 + 4+5 + 5+5) ms Warten = 34 ms dauern, dann würde sie neu starten.

Und das hören müsste nicht mal besonders qualifiziert passieren, die gehörten telegramme müssen evtl. nicht mal auf plausibilität untersucht werden.

Nur so eine Idee, über irgendwas muss man ja nachdenken, wenn man arbeitet.
Gruß Florian




Zuletzt bearbeitet von ohrange am 20.04.2006, 19:01, insgesamt einmal bearbeitet

[Tanis]

Die Sender zu 'syncronisieren' (wie auch immer) ist die 'Ausweichlösung' . Ich knobel ja auch schon ein wenig...
Da sich ohne Syncronisation Kollisionen eh nicht vermeiden lassen, werde ich auch das 'zufällige' Senden der Telegrame in Betracht ziehen... . Sobald ich die 455Khz IR-Bauteile habe, weis ich ob die Übertragung überhaupt so schnell möglich ist, wie ich das plane. Wenn man nach dem Dateblatt geht, habe ich eine minimale 'On' Zeit von 22µ und eine minimale 'Off' Zeit von 26µs. Da ich mit 33µS breiten Pulsen arbeite, sollte das aber noch hinhauen. ( 33µS L / 33µS H = 0 ; 33µ H / 33µS L = 1)

Gut, das sich noch Jemand ein paar Gedanken zu der ganzen Sache macht. Da macht es gleich viel mehr Spass weiterzumachen!

Gruß

--- Tanis ---

PS: Bei Source Code immer schön darauf achten, das man Backup-Files hat!
_________________
---

Resistance is futile!

[ohrange]

Klar gibts Kollisionen, wäre ja auch nicht tragisch, aber ausgehend vom Rechenbeispiel (5 ms/50ms) klappts nicht jede ID alle 50 ms ein mal kollisionsfrei zu übertragen. Und auch mit 50 ms wäre man schon nur noch halb so schnell wie beim analogen PPM Protokoll, da gibts ungefär alle 21 ms neue Daten für den Empfänger.
OK für TTT(T) sicher noch kein Problem, aber wenn man eine universellere Lösung anstrebt (auch für fliegende Dinge) dann wirds langsam spannend.
Gruß Florian

[Tanis]

Quote:

---

Und auch mit 50 ms wäre man schon nur noch halb so schnell wie beim analogen PPM Protokoll, da gibts ungefär alle 21 ms neue Daten für den Empfänger.

---

... um genau zu sein alle 22,5 mS (wenn man dem 'Standard' vertraut) .

Quote:

---

OK für TTT(T) sicher noch kein Problem, aber wenn man eine universellere Lösung anstrebt (auch für fliegende Dinge) dann wirds langsam spannend.

---

...shit da hat mich wohl doch was Verraten ..... sollte doch geheim bleiben, das man den Empfänger nicht nur für TTTT einsetzen kann...
Na ja, für Flächenmodelle reicht mit Sicherheit auch noch eine Zeitliche Auflösung von 100 mS (10 Aktualisierungen/S), bei den Helis könnte das schon ein Problem geben, aber das nehme ich bei der ersten Version gerne in Kauf. Mir geht es in erster Linie darum, das ich das überhaupt gelöst bekomme...

@Florian : In welcher Sprache programmierst Du die PIC's ?

Gruß

--- Tanis ---


_________________
---

Resistance is futile!

[ohrange]

@Tanis: in Assembler, hat sich irgendwie so ergeben, da ich eigentlich vom Programmieren überhaupt keine Ahnuung hatte (und eigentlich auch noch habe, ist also auch in dieser Beziehung low level Programmierung).

[Fiddy!]

Kann mir einer von euch Freaks mal sagen wo ich Infos zum Proggen bekomme ??? Damit ich endlich verstehe um was es hier eigentlich geht

Ne ma im ernst - gibts eine gute I-Net Seite oder noch schlimmer ein empfehlenswertes Buch zu dem Thema ??
_________________

[Tanis]

www.sprut.de <- Die Seite für PIC's schlechthin!

Gruß

--- Tanis ---

_________________
---

Resistance is futile!

[Fiddy!]

Aha - danke dir
_________________

[Bitte-ein-BIT]

Quote:

---

www.sprut.de <- Die Seite für PIC's schlechthin!

Gruß

--- Tanis ---

---

Na, das ist doch mal was ... Fiddy! ich würde sagen, daß wir das heute abend mal eben bei einem Kaltgetränk und ner Stange Fritten lernen ... Tanis kann uns das ja im Crash-Kurs beibringen.

Mich interessiert das nämlich auch riesig, doch mich schreckt es ab schon wieder was zu lernen
_________________

[Carsten]

Dann paßt ihr beiden mal schön auf, falls ich auch nochmal Fragen haben sollte.
_________________
Gruß Carsten

[Fiddy!]

Wir werden Tanis heute Abend solange löchern, bis wir ihm erklären können wie er sein Problem lösen kann
_________________

[troubleman]

Hallo!

wird an dem Projekt noch gearbeitet?

Um das Problem mit Kollisionen zu lösen könnte man Ethernet-Protokol angucken. Da hat man im Prinzip dieselbe Situation - es gibt keine zentrale Steuerinstanz und alle senden "auf einer Frequenz" (in ein Kabel). Da macht man so, dass wenn eine Kollision erkannt wird, dann warten beide Sender (die Kollision verursacht haben) eine zufällig gewählte Zeitspanne. Nachdem die kürzere Zeitspanne abgelaufen ist guckt ein Sender ob der Kanal frei ist und fängt an zu senden. Wenn dann auch beim zweiten Sender die Zeitspanne abgelaufen ist guckt er auch nach und sieht, dass da schon jemand sendet und wartet dann bis der Kanal frei wird. Eigentlich funktioniert es ganz gut. Es gibt nur ein Problem - je mehr Sender senden wollen desto mehr Kollisionen gibt es und entsprechend ein grösserer Teil der Bandbreite wird verschwendet. D.h. auch wenn rechnerisch die Bandbreite z.B. für 10 Sender reichen würde können mit kurzen Antwortzeiten (z.B. die Zeit zwischen zwei erfolgreich gesendeten Paketen liegt unter 20ms mit 95% Wahrscheinlichkeit) z.B. maximal 5 arbeiten. Man kann dem ein bischen engegenwirken, wenn man versucht die Pakete so kurz wie möglich zu halten. Z.B. nur die Änderungen für die benutzten Kanele übertragen - wie bei irgendwelchen PCM-Anlagen gemacht wird, aber da benutzten sie es um grössere Auflösung zu realisieren.

[Tanis]

Das Projekt 'ruht' zu Zeit, kann jedoch bei Interesse jederzeit wieder aufgegriffen werden. CSMA/CD halte ich nicht für das richtige Protokoll. Ich habe nur ein unidirektionales Signal vorgeshen... Trotzdem danke für den Vorschalg!

Gruß

--- Tanis ---

_________________
---

Resistance is futile!

[edimax]

Hallo

Ich habe mir schon mehrer Tracktoren umgebaut und fahre mit ingesamt 3 trecker mit drei FB ohne Problehme