Vorstellung meines Fernsteuerpojektes

[adrock]

Hey Super!

Vielleicht wird da ja mal ein "richtiges" Projekt draus an dem sich noch mehr Leute beteiligen... interessant wäre wohl zu allererst, ob der verwendete Standard in der von Dir verwendeten Form wirklich völlig unproblematisch bzgl. der Bestimmungen ist. Dann wie Du die Reichweiten getestet hast usw.

Aber das alles macht auf jeden Fall Lust auf mehr!

Ciao...
Markus

[Rex-Pilot]

Hi Markus,

die Chips (Transceiver) sind für den Industriestandard IEEE802.15.4 hergestellt, dieser Standard ist auch Grundlage für ZigBee,
nur ist mir der ZigBee-Stack zu aufwendig und überladen.
Ich habe ein 802.15.4-Protokoll im Einsatz.

Mit diesen Bausteinen kann man eigentlich nur sinnvolle Signale erzeugen die dem Standard entsprechen,
da fast alles in Hardware realisiert ist.
Die Zeitliche Abfolge wird dann zum Teil per Software gemacht, und natürlich der Dateninhalt.
Zeitkritische Abläufe sind auch schon in Hardare integriert, somit auch keine Chance am Standard
vorbei etwas zu machen, was nicht vorgesehen ist.

Funkmäßig ist alles Regelkonform, so das dieses System kooperativ zu anderen Funkstandards arbeitet,
z.B. wird vor dem Senden geprüft ob jemand anders bereits auf Sendung ist, dann wird eine
(sehr kurze) Zeit gewartet, und dann in den freien Zeitslot hinein gesendet.

Grundlage bietet die Norm ETSI EN 300 328 Version 1.7.1 gültig seit Juli 2008.
Sendeleistung bis 100mW bei Frequenzhopping möglich, Aufspreizung des Sprungbereichs und max. Verweildauer auf einer Frequenz halte ich selbstverständlich ein.
Bin von den Grenzen weit weg, sollte kein Problem sein.

Der Industriestandard IEEE802.15.4 ist von Anfang an so gestaltet das er koexistent zu anderen IEEE-Standards ist, hier im 2.4GHz Bereich.
(z.B. WLAN, Bluetooth, ...)

Martin

[tracer]

ZigBee

Die stecken doch auch im XPS/iFS?

[Rex-Pilot]

ZigBee

Die stecken doch auch im XPS/iFS?

Ja, ich meine die verwenden XBee-Pro-Module. (XBee ist der Produktname, Module arbeiten mit ZigBee Stack).
ZigBee ist ein Protokoll um Netzwerke aus einzelnen Funkeinheiten aufzubauen, die sich selbst organiesieren,
um Daten von einem Punkt über Zwischenschritte (Router) zum Ziel zu bringen.
Es wird immer eine Routingtabell aufgebaut und verwaltet, auch wenn man diese nicht benötigt, zudem sind die Datenpackete größer.

Beim Steuern von Modellen haben wir nur eine Punkt-zu-Punkt Verbindung, der Protokolloverhead ist nicht nötig und belastet eigentlich nur den Funkkanal,
da mehr Sendezeit benötigt wird.

Martin

[adrock]

ZigBee

Die stecken doch auch im XPS/iFS?

Ja, ich meine die verwenden XBee-Pro-Module. (XBee ist der Produktname, Module arbeiten mit ZigBee Stack).
ZigBee ist ein Protokoll um Netzwerke aus einzelnen Funkeinheiten aufzubauen, die sich selbst organiesieren,
...

Du musst die etwas geschockte Reaktion verstehen Durch das Graupner IFS-Fiasko hat ZigBee nicht mehr den besten Ruf. Die Frage ist, ob denn Dein System ein aktives (permanentes) Frequenzhopping unterstützt (oder unterstützen kann), um quasi immun gegen Störungen zu sein.

Die Idee mit den kleinen Datenpaketen hast Du ja schon realisiert. Jetzt müsste nur noch nach jedem Datenpaket zu einem anderen Kanal im 2,4GHz Bereich gesprungen werden. Können das die Module in der kurzen Zeit?

Habe mal den Standard überflogen, also im 2.4GHz Bereich können ja wohl 16 Kanäle verwendet werden. Den ganzen Protokollschnickschnack kann man ja eigentlich weglassen. Wir wollen ja nur kleine Datenpakete mit minimalen Informationen verschicken, das aber mit möglichst wenig Verzögerung und möglichst sicher (wenig Paketverluste).

Habe mich ansonsten damit bisher nicht beschäftigt, falls Du das alles schon bedacht hast, umso besser...

DIe Probleme des IFS (welches wohl auch auf ZigBee basiert) in der ersten Version waren wohl, dass nur auf einen (?) Ausweichkanal gesprungen wurde, wenn der Empfänger der Meinung war, das Signal ist zu schlecht (bei diversen Tests im Labor ist es den Leuten m.W. nicht gelungen, das System zum Springen zu bewegen)...

Ciao...
Markus

[Rex-Pilot]

Die Frage ist, ob denn Dein System ein aktives (permanentes) Frequenzhopping unterstützt (oder unterstützen kann), um quasi immun gegen Störungen zu sein.

Die Idee mit den kleinen Datenpaketen hast Du ja schon realisiert. Jetzt müsste nur noch nach jedem Datenpaket zu einem anderen Kanal im 2,4GHz Bereich gesprungen werden. Können das die Module in der kurzen Zeit?

Habe mal den Standard überflogen, also im 2.4GHz Bereich können ja wohl 16 Kanäle verwendet werden. Den ganzen Protokollschnickschnack kann man ja eigentlich weglassen. Wir wollen ja nur kleine Datenpakete mit minimalen Informationen verschicken, das aber mit möglichst wenig Verzögerung und möglichst sicher (wenig Paketverluste).

Das ist auch der Grund warum ich kein ZigBee einsetze, ich verwende lediglich IEEE802.15.2, das ist die untere Netzwerkschicht auf die ZigBee aufbaut.
ZigBee ist ein eigener Standard.
In IEEE802.15.4 ist lediglich die Modulation, Packetdefinition, Zeiten für einen ACK-Frame (Bestätigungs-Datenpacket), Kanalzuordnung, und Verfahren zur Kollisionsvermeidung definiert.

Mein System verwendet alle 16-Kanäle, und nach jedem Datenpacket (Frame) wird der Kanal (Frequenz) nach einer pseudo-Zufallsfolge gewechselt. (aktives (permanentes) Frequenzhopping )
Die Folge ist von Gerät zu Gerät unterschiedlich und einmalig, so das sich die Systeme, wenn man mehrhere am gleichen Ort betreibt, nicht in die Quere kommen.

Zudem werden alle Kanäle überwacht, wenn ein Kanal öfters Störungen hat, wird dieser Kanal für einige Zeit
(einige Sekunden) nicht angesprungen, danach wird wieder getestet ob der Kanal wieder OK ist, und wird in die Sprungreihenfolge aufgenommen.
Wenn zuviele Kanäle Störungen melden (z.B. einige WLANs mit viel Datenverkehr in der Umgebung) bekommt man eine Warnung, es besteht zwar weiterhin eine sichere Verbindung und man kann sicher landen bevor noch mehr Probleme auftreten.

Martin

[schöli]

Mein System verwendet alle 16-Kanäle, und nach jedem Datenpacket (Frame) wird der Kanal (Frequenz) nach einer pseudo-Zufallsfolge gewechselt. (aktives (permanentes) Frequenzhopping )
Die Folge ist von Gerät zu Gerät unterschiedlich und einmalig, so das sich die Systeme, wenn man mehrhere am gleichen Ort betreibt, nicht in die Quere kommen.

Zudem werden alle Kanäle überwacht, wenn ein Kanal öfters Störungen hat, wird dieser Kanal für einige Zeit
(einige Sekunden) nicht angesprungen, danach wird wieder getestet ob der Kanal wieder OK ist, und wird in die Sprungreihenfolge aufgenommen.
Wenn zuviele Kanäle Störungen melden (z.B. einige WLANs mit viel Datenverkehr in der Umgebung) bekommt man eine Warnung, es besteht zwar weiterhin eine sichere Verbindung und man kann sicher landen bevor noch mehr Probleme auftreten.

Da würd ich jetzt schlicht und einfach mal: genial! dazusagen

[Rex-Pilot]

Hallo,

anbei schon mal der Schaltplan.
Die C-Quellen kommen nächste Woche, bin 1 Woche weg.

Und ein paar Bilder vom Senderpult mit den Antennen, sind std. WLAN-Antennen mit SMA-Stecker.
Ein Bild vom Programieradapter um den ICD2 mit dem Board zu verbinden.
Die Ferderkontakte werden einfach auf die Pads auf dem Board hehalten. (in der Mitte zwischen den Modulen)
Und zum Schluß noch ein Bild der Lötanlage mit der die SMDs gelötet sind.
2 x 500W Halogenscheinwerfer. Ist preiswert (je 5 Euro) und gibt super ergebnisse.

Gruß
Martin

[Rex-Pilot]

Hallo,

war ein paar Tage im Urlaub, und danach hatte ich leider wenig Zeit da mich der Job sehr gefordert hatte.

Aber hier nun noch der Schaltplan der Transceiver-Module.

Die Quellcode-Dateien uss ich noch etwas aufräumen, da dort noch viel auskommentierter Quellcode von Versuchen drinn, der nur verwirrt.
Zudem muss ich noch einige Stellen besser dokumentieren.

Martin

[dl7]

*HutZieh*

Darf man denn sowas? "Einfach" Zertifizierte Bauteile in ein Eigendesign stopfen und dann benutzten? Wäre schade, wenn sowas dann an (unendlich teuren) Zulassungs-Pflichten, Küren und Torturen scheitern würde...

Grüsse Wolfgang

Auch ich habe Respekt vor dem Eigenbau und gratuliere (auch wenn ich, speziell für Segler) weiter bei 35MHz bleibe. Aber rein rechtlich hat Corvolus da einen entscheidenden Punkt. Der Bau von Sendeanlagen ist nur geprüften Funkamateuren auf den ihnen zugewiesenen Amateurfunkfrequenzen gestattet. Ansonsten ist das für Privatleute tabu und nicht legal. Industriell gefertigte Anlagen bedürfen einer Betriebsgenehmigung mit all den finanziellen Konsequenzen. Deswegen kommen bei allen Sendern und Empfängern auch immer diese Unmengen Papiere mit, die wir alle kaum anschauen und im günstigsten Fall ungelesen abheften, wenn nicht wegwerfen.
Gruß Reiner

[Doc Heli]

Hi Martin,

klasse gemacht! Nochmals Hut ab! Sieht wirklich sehr gut aus! Aktuell erlaubt es meine Zeit leider nicht, daran mitzuwirken, obwohl ich das gerne machen würde. Ich arbeite aber selbst viel mit den PICs.

Mein Vorschlag wäre, ein Bus zu integrieren, um an den Empfänger/Sender direkt andere Module anschließen zu können: ähnlich hat es Spectrum gemacht, auch ich habe einen Bus implementiert in meinen Modulen. Evtl. ließe sich der ja kompatibel machen? Allerdings schreibe ich rein in Assembler.

Frage daher: ist der von Dir verwendete C-Compiler denn frei? Ich kenne nur den recht teuren kommerziellen für die PICs.

Viele Grüße,
Roger

[Flieger84]

Hut ab...echt genial!

[Rex-Pilot]

Mein Vorschlag wäre, ein Bus zu integrieren, um an den Empfänger/Sender direkt andere Module anschließen zu können: ähnlich hat es Spectrum gemacht, auch ich habe einen Bus implementiert in meinen Modulen. Evtl. ließe sich der ja kompatibel machen? Allerdings schreibe ich rein in Assembler.

Ja, einen Bus habe ich bereits integriert, ist ein IIC (3,3V-Pegel, interface zu 5V ist kein Problem, man braucht nur 2 FETs und 4*R) der an der Steckerleiste angeboten wird, kann auch für http://www.OpenServo.org verwendet werden.
SPI ist auch noch frei, nur zur zeit nicht herausgeführt.
Zusätzlich liegt auch rs232 (3,3-Pegel) an der Buchsenleiste an.
rs232 habe ich schon für die Übertragung von GPS-Daten genutzt.

Frage daher: ist der von Dir verwendete C-Compiler denn frei? Ich kenne nur den recht teuren kommerziellen für die PICs.

Ich nutze den C30, der ist zunächst 60 Tage in der 'Voll-Version' verfügbar, danach 'nur' in der normal-Mode.
D.h. die Optimierungslevel (Code-Größe <=> Speed) ist nicht mehr einstellbar, da ich aber sowiso lieber selber die Kontrolle über den Code habe stört mich das nicht.
Sonst ist er frei zu nutzen.
Gibt es von Microchip auf der Website.

Der Code (übersetztes C => ASM) (kann man sich anzeigen lassen) ist sehr kompakt geschrieben.

Der Compiler erlaubt auch Inline-ASM, so kann man kritische Passagen auch in Assemler schreiben.

@Roger: Was machst Du mit PICs, auch Komponenten für den Modellbau?


Gruß
Martin