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.pdf http://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!
Ein Tipp wäre noch: die Steuerung per Funkmodul bei 433MHz zu realisieren, während die Daten auf 866MHz o.ä. zurück gesendet werden.
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.
Jörg Wunsch schrieb: > "Nicht jeder Anfänger" ist gut. :-) Es soll ja auch Ausnahmen geben die die Regel bestaetigen . :-)
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 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.
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.