mikrocontroller.net

Forum: HF, Funk und Felder Funkmodul gleichzeitiges Senden und Empfangen


Autor: Franki C. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Leute!

Suche ein Funkmodul um ein Modellauto über RS232 zu steuern und vom Auto 
Daten wie Geschwindigkeit und gefahrene meter zu bekommen. Da das 
Autofahren nicht unterbrochen werden soll während ich die Daten vom 
Fahrzeug bekomme soll dies gleichzeitig geschehen.
Meine Frage gibt es einen stromsparenden Transceiver der gleichzeitig 
senden und empfangen kann oder brauche ich zwei mal Empfängermodul und 
zwei mal Sendemodul?

Das hatte ich gefunden, weiß aber nicht ob ich alles damit realisieren 
kann:

http://www.funkmodul.com/funkmodule/transceiver_da...

http://www.wirelessworldag.com/de/funkmodule/easyr...

Danke!

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eugenio C. schrieb:
> Meine Frage gibt es einen stromsparenden Transceiver der gleichzeitig
> senden und empfangen kann oder brauche ich zwei mal Empfängermodul und
> zwei mal Sendemodul?

Naja, wirklich gleichzeitig wäre extrem aufwändig.  Du müsstest
ja einigermaßen weit auseinanderliegende Sende- und Empfangsfrequenzen
wählen und die Antenne über einen sogenannten Diplexer anschließen.

Aber wenn du nur sequentiell senden und empfangen willst (so ein
Auto braucht ja nur alle vielleicht einige 10 ms neue Steuerbefehle),
dann gibt's genügend Transceiver-Module.  Die preiswertesten dürften
die bekannten RFM12 sein.  Alle Module, die IEEE 802.15.4 implemen-
tieren ("ZigBee") sind ebenfalls prinzipbedingt Transceiver.

Autor: Franki C. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Achso daran hab ich gar nicht gedacht, ich kann ja einfach alle z.B. 10 
ms umswitchen und das Signal (z.B. fahr geradeaus) für die Zeit halten.
Halten denn die Transceiver dieses ständide umswitchen von Empfang auf 
Senden aus oder wird es da Probleme geben?

Danke für die Antwort!

Autor: Besucher (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ein Tipp wäre noch: die Steuerung per Funkmodul bei 433MHz zu 
realisieren, während die Daten auf 866MHz o.ä. zurück gesendet werden.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eugenio C. schrieb:

> Halten denn die Transceiver dieses ständide umswitchen von Empfang auf
> Senden aus oder wird es da Probleme geben?

Ja, klar. ;-)  Da werden keine mechanischen Schalter hin und her
geworfen. :)

Besucher schrieb:
> Ein Tipp wäre noch: die Steuerung per Funkmodul bei 433MHz zu
> realisieren, während die Daten auf 866MHz o.ä. zurück gesendet werden.

Bringt nicht viel.  Die 1. Oberwelle des 433-MHz-Senders schlägt
voll in den 868-MHz-Empfänger rein, und selbst in der anderen Richtung
wird dank weggelassener passiver Vorselektion vermutlich auch der
Empfänger noch zugestopft.

Autor: Franki C. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke schon mal!

Eine Frage noch ein bisschen abschweifend. Auf der einen Seite befindet 
sich ein Altera Nios II Embedded Evaluation kit, auf der anderen Seite 
ein Starter Kit mit einem ATMega8. Das Altera Board schafft mit seinem 
FPGA und dem Nios Prozessor 50MHz der ATMega8 meines Wissens nur 8Mhz. 
Nun war es ja früher so dass man bei einer rs232 Verbindung und einem 
langsamen Modem RTS und CTS Leitungen benutzt hat, damit das Modem dem 
schnelleren Terminal mitteilen kann wann es nicht weiter aufnehmen 
kann(Geschwindigkeitsabhängig).
Im Softcore von Altera kann man die CTS und RTS Leitungen mit einbinden.
Ist das jetzt Sinnvoll? Oder besser gesagt ist das durch eine 
Funkstrecke auch realisierbar?

Autor: Helmut Lenzen (helmi1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Eugenio C. schrieb:
> Nun war es ja früher so dass man bei einer rs232 Verbindung und einem
> langsamen Modem RTS und CTS Leitungen benutzt hat, damit das Modem dem
> schnelleren Terminal mitteilen kann wann es nicht weiter aufnehmen
> kann(Geschwindigkeitsabhängig).

Das kann man aber auch ueber ein Datenaustauschprotokoll hin bekommen.
Das ganze mit RTS und CTS hat man nur gemacht bei Datenquellen die ohne 
ein Protokoll laufend Daten schickten. Wie z.B. Drucker oder Terminals.
Wenn man auf beiden Seiten ein Datenprotokoll ein fuehrt braucht man so 
was nicht. Du schickst z.B.  eine Anforderung an die Gegenstelle und 
wartest dann die Antwort ab. Eine weitere Anfrage kannst du erst dann 
vornehmen wenn die Gegegstelle geantwortet hat. Damit ist sichergestellt 
das die Anfrage in der Gegenstelle angekommen und verarbeitet worden 
ist. So kann in der Gegenstelle keine Speicherstellen uebrlaufen oder 
Informationen verloren gehen. Sollte die Gegenstelle mal nicht antwortet 
muss die die gleiche Anfrage wiederholen. So in der Art arbeitet z>B. 
TCP/IP.

Autor: Franki C. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Informationen!!

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Helmut Lenzen schrieb:
> So in der Art arbeitet z.B.
> TCP/IP.

Naja, leicht anders. ;-)

Das, was du da beschrieben hast, ist ein einfaches "request response
protocol".  Auf jede Anforderung wird eine Bestätigung abgewartet,
bevor die nächste Anforderung gesendet wird.  Der Hauptnachteil eines
solchen (sehr einfachen) Protokolls ist, dass die Verzögerung der
Übertragung massiv in die erreichbare Gesamtdatenrate eingeht.  Das
tut sie auch dann, wenn die Leitung zwar langsam im Antworten ist,
aber eigentlich eine hohe Datenrate schaffen könnte.

Daher hat man schon in der Anfangszeit der seriellen Kommunikation
(UUCP, Kermit) begonnen, ein sogenanntes window einzuführen: eine
Anzahl unbestätigt gesendeter Datenpakete, für die noch keine
Antwort eingetroffen ist.  Bleibt die Antwort ganz aus, muss ggf.
ein älteres Paket wiederholt werden (und der Empfänger muss die
Reihenfolge wieder zusammenbasteln), aber damit kann man auf einer
zwar schnellen, aber stark verzögernden Leitung trotzdem noch an
die Nettodatenrate der Leitung heran kommen, sofern die Leitung
zuverlässig ist (also letztlich [fast] alle Pakete ohne Neuübertragung
beim Empfänger ankommen).

TCP treibt dieses Prinzip nun noch etwas weiter, indem dieses window
dynamisch verändert wird.  Damit wird es beispielsweise bei einer
stark von Paketverlusten betroffenen Leitung automatisch kleiner,
sodass der Absender bereits gezwungen ist, die Datenrate zu drosseln.
Wenn andererseits die Leitung gut ist, können relativ große Daten-
mengen unbestätigt losgeschickt werden.  Damit passt sich das
Protokoll selbst gut an die tatsächlichen Gegebenheiten der Leitung
an.

Muss man sicher nicht alles selbst implementieren :-), aber manchmal
sollte man das im Hinterkopf behalten.  Ich habe zu viele schlechte
Protokolle erlebt, die erst Ende des letzten Jahrtausends entworfen
worden sind, als man um solche Zusammenhänge eigentlich schon hätte
gewusst haben sollen (AVR910 zum Beispiel).

Autor: Helmut Lenzen (helmi1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Jörg

ich schrieb ja auch in der Art.
Ich bin mir bewusst das TCP/IP noch weit davon entfernt ist ( Habe 
selber einen TCP/IP Stack geschrieben). Nur die Frage des TO war die ob 
er Hardwarehandshake dort einsetzen kann. Und da habe ich ihm mal ein 
ganz rudimentaeres Protokoll / Vorgehen geschildert. Nicht jeder 
Anfaenger ist direkt in der Lage ein Protokoll mit einem Sliding Window 
zu implementieren.
Fuer den Anfang kann er ja mal mit sowas anfangen damit ihm in der 
Gegenstelle keine Puffer ueberlaufen. Und wenn einem dann deine 
geschilderte Problematik bewusst wird kann er das immer noch weiter 
ausbauen. Das ganze CTS/RTS verfahren war mal gedacht irgendwelche 
dummen Terminals / Drucker zu bedienen wo ueberhaupt kein 
Softwareprotokoll gefahren wird. Die bekammen halt ihre Zeichen 
uebertragen bis der Datenbuffer fast am ueberlaufen war.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Helmut Lenzen schrieb:
> Nicht jeder
> Anfaenger ist direkt in der Lage ein Protokoll mit einem Sliding Window
> zu implementieren.

"Nicht jeder Anfänger" ist gut. :-)

Nein, ich wollte nur daran erinnern, dass request-response manchmal
eben auch Probleme bereiten kann.

Autor: Helmut Lenzen (helmi1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> "Nicht jeder Anfänger" ist gut. :-)

Es soll ja auch Ausnahmen geben die die Regel bestaetigen . :-)

Autor: Franki C. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo!

Also das mit den 10 ms oder mehr ist nicht ganz Zweck erfüllend. Ich 
habe noch mal im Internet gesucht aber nichts gefunden. Es sollte schon 
ein gleichmäßiges senden und empfangen sein, sprich wenn gesendet wird 
soll reagiert werden und wenn empfangen wird soll reagiert werden, ohne 
Wartezeiten.
Deswegen bin ich immer noch auf der Suche nach einem Transceiver der 
Vollduplex an einer RS232 Schnitstelle unterstützt. Also eigentlich 
nichts anderes machen als die Leitungen zu ersetzen.
Ich könnte natürlich auch 2 Sender und 2 Empfänger nehmen, aber das ist 
zu teuer und eigentlich auch nicht Sinn der Sache..

Sind die RFM12 denn auch Vollduplexfähig?

Autor: Helmut Lenzen (helmi1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Franki C. schrieb:
> Deswegen bin ich immer noch auf der Suche nach einem Transceiver der
> Vollduplex an einer RS232 Schnitstelle unterstützt.

Wenn es die gleichen Frequenzen zum Senden und Empfangen sind geht Voll 
Duplex nicht.

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Franki C. schrieb:

> Also das mit den 10 ms oder mehr ist nicht ganz Zweck erfüllend.

Dann erkläre mal, welche Reaktionszeit du denn wirklich brauchst.

Nicht, dass am Ende auch noch die Lichtgeschwindigkeit zu langsam
ist für dich. ;-)

> Es sollte schon
> ein gleichmäßiges senden und empfangen sein, sprich wenn gesendet wird
> soll reagiert werden

wie schnell muss reagiert werden?

> ohne Wartezeiten.

Ach, und deine Datenverarbeitung passiert auch ohne Wartezeiten?

> Ich könnte natürlich auch 2 Sender und 2 Empfänger nehmen, aber das ist
> zu teuer und eigentlich auch nicht Sinn der Sache.

Das und noch viel mehr sind die Bestandteile eines Vollduplex-
Transceivers.  Du musst nämlich noch Sende- und Empfangsfrequenz
voneinander trennen, damit sich Sender und Empfänger nicht in die
Quere kommen.  Dafür müssen beide Frequenzen erstens hinreichend
weit voneinander entfernt sein, und zweitens brauchst du eine
Frequenzweiche (auch "Diplexer" genannt), mit der du die Pfade
trennen kannst.

UMTS macht sowas.  GSM hat ob des Aufwands lieber drauf verzichtet.
DECT auch.  Trotzdem kann man auch mit GSM- oder DECT-Telefonen
scheinbar gleichzeitig in beiden Richtungen sprechen.  Warum bitte
sollte das dann mit deinen paar Fernsteuersignalen nicht gehen?

> Sind die RFM12 denn auch Vollduplexfähig?

Nein, natürlich nicht, und jenseits von UMTS auch sonst nichts an
Consumer-Elektronik.

Autor: Helmut Lenzen (helmi1)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Jörg Wunsch schrieb:
> Nicht, dass am Ende auch noch die Lichtgeschwindigkeit zu langsam
> ist für dich. ;-)

Dann kann man nur noch zur Subraumkommunikation raten ;-)

Autor: Franki C. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also das die 10 ms zu wenig sind ist falsch ausgedrückt ;-)

Nur hätte ich gerne 2 Tasks laufen lassen die jeweils auf interrupts 
warten und direkt reagieren, wäre in der "Theorie" halt einfacher 
gewesen.
Ok also kann ich dann ja eigentlich mit Tasks arbeiten und eine Abfrage 
machen ob senden oder empfangen erlaubt ist, so ungefähr wie bei 
Semaphoren?

Autor: Jörg Wunsch (dl8dtl) (Moderator) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du sprichst in Rätseln.

Was spricht dagegen, dass beide Seiten einfach standardmäßig auf
Empfang stehen und damit Daten empfangen können.  Wenn jemand
Bedarf zum Senden hat, dann schaut er nach, ob gerade empfangen
wird (muss ggf. bis zum Ende der aktuellen Übertragung warten),
danach sendet er sein Datenpaket.

Autor: Andreas Schweigstill (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Beschreibe doch erst einmal Deine Anforderungen. Welche 
Übertragungsraten und maximalen Latenzzeiten werden gefordert. Dann 
erläutere, warum dies scharfe Grenzen sind.

Wie schon an anderer Stelle erwähnt, ist ein Vollduplex-Sender/Empfänger 
wesentlich teurer als die Summe zweier Einzelstrecken.

Die große Kunst besteht nicht darin, möglichst harte, aber eigentlich 
fast willkürlich formulierte Forderungen aufzustellen, sondern im 
Gegenteil die Minimalstanforderungen zu definieren.

Autor: Franki C. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry habe mich vorher noch nie mit Funk beschäftigt, ist halt Neuland 
für mich.
Ich wollte halt das der Empfänger am Auto reagieren soll wenn er die 
Steuersignale bekommt, aber in bestimmten Zeitintervallen (c.a. alle 500 
ms) die Geschwindigkeit und die gefahrenen meter zum Bediener sendet. 
Wenn ich nun z.B. schnell zwischen den Richtungen wechsel, war ich mir 
nicht sicher, ob des Senden vom  Auto ständig geblockt wird, da er Daten 
vom Bediener Empfangen muss.

Autor: Markus DL8RDS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Franki, es hat nix mit Funk zu tun, sondern es hat mit den Eigenheiten 
Deiner Steuerung zu tun. Beschreib doch erst mal die Daten, die Dein 
Auto so liefert. Beschreibe bitte, wie die dortige Steuerung die Daten 
erfasst und wie sie diese speichert. Und beschreib bitte, wie weit das 
Auto in 100 ms bei voller Geschwindigkeit fahren kann.

Mit alter, langsamer Technik (Packet Radio) sind immerhin 960 Byte drin, 
die das Auto an Dich in 100 ms zurückschicken kann. Moderne Sendemodule 
sind deutlich schneller.

Interessant wäre noch, wie weit Dein Auto von Dir wegfahren wird, also 
ob Du ständig Sichtkontakt hast. In diesem Fall kannst Du dir mal 
überlegen, mit Arduino und einem WLAN-Board zu basteln. Dann hast Du 
ggf. sogar 54 MBit/s, also in den 100 ms gut 5 MBit an Daten.

Wieviele Daten fallen denn so an?

Für mich waren solche Überlegungen vor 20 Jahren der Anlaß, die 
Amateurfunkprüfung zu machen. Ich wollte ein Modellbau-Segelschiff mit 
40 Servos steuern. Pro Servo ein Kanal hätte niemals funktioniert. Hab 
mich daher mit Packet Radio und der Frage beschäftigt, wie man dem 
Schiff nur jeweils kurze Buchstab-Befehle mit Stellwinkeln schickt, und 
ein Rechner auf dem Schiff daraus die Servos ansteuert. Heute wäre das 
alles viel einfacher lösbar als damals. Ach ja, Packet Radio darfst Du 
inzwischen im CB-Band funken, soviel ich weiß. Aber mit einer AFU-Lizenz 
hat man mehrdimensional mehr Freiheiten.

Viele Grüße
Markus

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.