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_daten/RT868F5.pdfhttp://www.wirelessworldag.com/de/funkmodule/easyradio-funkmodule/
Danke!
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.
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!
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.
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?
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.
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).
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.
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.
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?
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.
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 werdenwie 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.
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 ;-)
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?
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.
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.
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.
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
