- Dirk, Deine Platine schaut gut aus, wie willst Du weitermachen? Welche Kreuzknüppel? Eine zweite Platine zum draufstecken? - mit lauter Probiererei und Versuchen, das DOGS-Display zum Laufen zu bringen, hab ich den Lipo-Akku leer gesaugt. Zellspannungen 2,3V. Konnte ihn zwar mit Gewalt wieder laden, bin aber gespannt wieviel er gelitten hat. Jetzt überlege ich, ob Konsequenzen nötig sind. Evtl. eine Warn-LED die bei einer Spannungsgrenze angeht, oder den Betrieb komplett zu verweigern, was mir aber eher nicht gefällt. - Irgendwie stimmen jetzt mit dem neuen Aufbau die Timings fürs IR-Senden nicht mehr, obwohl der Atmega der gleiche ist. Sehr komisch! - Mein Fräser hat gerade keine Zeit für mich um die Durchbrüche ins Gehäuse zu machen. Schade. Muß ich wohl noch warten.
Hallo, die Kreuzknüppel habe ich mir bei Reichelt mitbestellt. Ich bin mir aber noch nicht sicher welches Gehäuse ich mir zulegen soll. Vielleicht baue ich auch einen kleinen 2 Kanalsender um.
hab heute mal nach Faltenbälge zur Abdeckung des Loches bei den Kreuzknüppeln beschäftigt. Konnte aber keine in der Größe finden. Hab darauf dann Kontakt mit Andreas von den Regensburgern aufgenommen. Er stellt selbst welche her. Hat aber leider zur Zeit keine auf Lager, wird mir aber einen Satz herstellen. Wenn noch jemand welche will, bitte melden, dann geht´s in einem Rutsch.
Hallo, die Platine ist so weit fertig aufgebaut und getestet. Die Software läuft auf einem ATmega 16. Die PWM für das Display müsste bei den vom mir angepasst werden, da die Hintergrundbeleuchtung zu dunkel ist. Leider habe ich die Software auf dem ATmega 644 bis jetzt noch nicht ans laufen gebracht. Auf dem Display erscheinen nur wirre Zeichen an.
Gruß Dirk
Angefügte Bilder:
Aufgrund eingeschränkter Benutzerrechte werden nur die Namen der Dateianhänge angezeigt Jetzt anmelden! senderplatine_v1.0.1-komplett-klein.png senderplatine_v1.0.1-lcd-klein.png
Hallo, nach vielen probieren und testen bin ich zu dem Schluss gekommen das es an der Hintergrundbeleuchtung meines LCD Display liegt. Ich habe den Timer0 für die Hintergrundbeleuchtung auskommentiert und ein Poti an Pin 15 des LCD gelötet. Jetzt funktioniert die Software mit beiden ATmegas. Weiter mit dem testen geht es nächste Woche.
Gruß Dirk
Angefügte Bilder:
Aufgrund eingeschränkter Benutzerrechte werden nur die Namen der Dateianhänge angezeigt Jetzt anmelden! display-pwm.jpg display-pwm1.jpg
das nennt man dann wohl "Sommerloch" !!! Ziemlich ruhig geworden die Tage. Baut keiner was?
Darum schreib ich einfach mal, was ich so treibe. Bin momentan dabei, die Kommunikation zwischen zwei RFM-Siebzig (absichtlich so geschrieben, um den Suchmaschienen auszukommen) zu programmieren. Diese Transceiver-Module sind echt schön klein (12,8mm x 16,8mm x 3mm) und für sehr günstige 3,50 Euro zu haben. Sie arbeiten im 2,4 GHz Bereich, in 72 unterschiedliche Frequenzen eingeteilt. Leider gab es dafür keine Vorlage in Bascom, Studium vom Datenblatt war angesagt. Und die Teile haben wirklich viele Funktionen. War alles andere als Einfach, aber: Heute hab ich endlich den Durchbruch geschafft, die Kommunikation läuft.
Zwischendrinn musste ich die Ansteuerung meines Displays auch "zu Fuß" programmieren, denn das Display und das Funkmodul werden beide via SPI-Schnittstelle angesprochen. Wobei ich fürs Display eine fertige Library verwendet habe, die die Spi-Schnittstelle so konfiguriert hat, daß die Verwendung für beide Module nicht funktionierte.
Als nächstes werde ich meinen Sender-Code vom Siku-Sender erweitern, er soll sowohl Siku als auch RFM-Siebzig bedienen können. Das heißt dann auch, daß viele Menüpunkte hinzu kommen, die Verarbeitung der Potis und Schalter aber viel einfacher und schneller laufen wird, da die Modulation des IR-Signals wegfällt. Dafür möchte ich die Erzeugung der Blinker-Signale, Blaulichter, Bremslicht und Rückfahrscheinwerfer im Sender machen, um die Zeiten im Menü verstellen zu können.
Danach werde ich mich mit dem Bau eines kleinen Empfängers beschäftigen. Dabei werde ich mich vorerst mal auf eine H-Brücke, eine Servosteuerung und ein paar Lichtausgänge beschränken. Sollte wenn möglich noch in einen PKW passen, evtl wird die Platine als Bodenplatte des Fahrzeugs mißbraucht.
Den Code für den Sender will ich aber nicht mehr veröffentlichen.
ich hab mich jetzt auch dazu entschieden, von Bluetooth wegzugehen und die RFM siebzig zu verwenden. Einige Gründe kennst du ja selber
Weshalb ich das hier poste: Ich fände es sehr sinnvoll, wenn wir das Protokoll (also wie die übertragenen Daten aufgebaut werden usw.) gemeinsam entwickeln könnten. Wenn jeder so sein eigenes Süppchen kocht, hat niemand etwas davon, von Kompatibiliät und eventuell auch Offenheit würde jeder profitieren können. Es geht mir also nicht um das, was der µC macht und dessen Quellcode (ich programmiere in C, du soweit ich weis in Bascom), sondern allein um die Kommunikation zwischen den Modulen.
Bei dem Empfänger könnte wir uns eventuell auch gegenseitig behilflich sein. Ich habe, unter Berücksichtigung meiner Erkenntnisse und teilweise auch Fehlern der BT-Steuerung, schonmal angefangen eine Schaltung sowie ein Layout zu erstellen. Auch recht simpel: RFM + ATMega48 im MLF32 + H-Brücke (selber Baustein wie von Klaus) + ein paar Pads für Lichter & Servos. Mit den Umrissen des rfms als Maximaldimensionen. Diese Platine würde ich wieder Professionell fertigen lassen, wenn du möchtest können wir gemeinsam bestellen.
Arg weit bin ich mit alldem noch nicht, werde die Tage erstmal ein paar rfms bestellen und sie in C ansteuern. Arg eilig hab ich es mit dem ganzen nicht, vorallem da ich "nebenher" noch ein Abi schreiben sollte...
Das hier ist jetzt nur ein Vorschlag, wenn du lieber alleine arbeitest ist das völlig ok für mich. Überlegs dir einfach mal.
freut mich einen Mitkämpfer zu haben. Bin aber auch noch nicht wirklich weit. Musste die Ganze Ansteuerung der RFM in Basic überstzen. Und das bei meinem Anfängerwissen... Hat aber letztendlich auch funktioniert. Bin momentan dabei, mein Sender-Programm um die neuen Funktionen zu erweitern. Als Empfänger hab ich ne Platine mit Attiny84 und der H-Brücke entworfen und auch schon geätzt. Ist aber noch nicht gelötet, Bauteile liegen aber auch schon hier.
Das Protokoll und Sendeverhalten hab ich mir mal überlegt. Ich wollte das Modell nicht auf einen bestimmten Kanal festlegen. Die RFM können ja gleichzeitig auf 6 Kanäle empfangen. Ich wollte jeweils nur auf einem senden. Bei Empfangsproblemen dann auf einen der 5 restlichen senden. Das Protokoll hatte ich mir so vorgestellt: - erst mal 2 Adress-Bytes (oder mehr?) - 4 Bytes mit den Daten der 2 Kreuzknüppel (8-Bit-Auflösung sollte reichen) - 1-2 Bytes mit den Schaltfunktionen (8 bzw. 16 Schaltbits)
Bin aber noch für alle Vorschläge, Wünsche, Anträge, Verbesserungvorschläge und Tipps offen !!!
Gruß Gerhard
Edit: Deine Empfängerplatine würd mich auf alle Fälle interessieren. Wäre da mit ein paar Stück dabei. Hab nämlich im nachhinein gelesen, daß es Probleme mit dem Attiny24/44/84 und der PWM gibt. Und 3 Schaltkanäle sind auch nicht der Brüller.
Angefügte Bilder:
Aufgrund eingeschränkter Benutzerrechte werden nur die Namen der Dateianhänge angezeigt Jetzt anmelden! RFM-Empfänger_Attiny84.png
Ich hab gerade das gesamte Datenblatt des RFMs komplett durchgelesen. Dazu gleich mal eine Frage: Hast du schon Erfahrungen, wie gut die Module mit den (bis zu) 4,2V einer LiPo-Zelle klarkommen? Die BTMs sind auch bis 3,6V spezifiert, aber die halten 4,2V noch ganz gut aus, die RFMs auch? Mit den Kanälen: Vielleicht verstehe ich das auch falsch, aber ist es nicht so beschrieben, dass es folgendermaßen funktioniert: Die Module (PTX & PRX) sind beide auf dieselbe Frequenz, denselben Funkkanal eingestellt. Davon kann man gleichzeitig genau einen verwenden. Auf dieser einen Frequenz kommunizieren die Module in bis zu 6 (ich nenn sie mal) "virtuelle Kanälen", die einzig und allein durch eine ID, eine Adresse unterschieden werden können. Von diesen IDs kann man jetzt dem PRX 6 Stück geben, bei deren Empfang er "zuhört", alle anderen werden schlicht ignoriert. Wenn das soweit richtig ist, zum Problem das sich daraus ergibt: Die jeweiligen Endgeräte (Sender & Modell) müssen sich auf einer Funkfrequenz treffen um kommunizieren zu können. Diese verwenden dann einen "virtuellen Kanal" auf dieser Frequenz. Jetzt kommen andere hinzu. Ich weiß nicht wieviele (ich weis nicht wie lange es dauert, ein Paket zu übertragen), aber eben so wies auf Treffen sein kann. Dann wird langsam der echte Kanal immer voller und irgendwann stören sich die Teilnehmer gegenseitig. Das ganze wäre jetzt kein Problem, wenn sich die Module absprechen würden und auf unterschiedliche Frequenzen ausweichen. Woher wissen die Module aber, welche Frequenz noch frei ist, und welche nicht?
Hoffe ich habs so geschrieben, dass das rauskommt was ich sagen will.
Das Protokoll an sich find ich gut, hab ich bisher auch so ähnlich gemacht. Überlegen könnte man vielleicht noch, ob wirklich immer der komplette Datensatz übertragen werden soll. Bei einem einfachen Fahrzeug könnte man ja fast die hälfte der Daten weglassen. Ob sich das aber auf irgendwas besonders auswirkt weis ich nicht, bei den BTMs wars zumindest sehr ratsam.
Am Empfänger muss ich noch einiges arbeiten, weil die ATMega48 im Vergleich zum Mega8 etwas anders sind. Weißt du jemanden oder eine Firma, der/die halbwegs bezahlbar 2-seitige Platinen mit 0,5mm Basismaterial macht? Da du ja so an PKWs gedacht hast und so wäre das bestimmt keine schlechte Idee.
mit den 4,2V hab ich noch keine Erfahrung. Hab diesbezüglich auch nix im WWW gefunden. Das muß mal ein Bauernopfer testen. Mit mit den Kanälen und Adressen hab ich wohl irgendwie was durcheinandergebracht. Wird wohl wieder mal meine Abendlektüre :-( Zur Übertragungsgeschwindigkeit: sie sollen laut Datenblatt 1-2 MBit/s schaffen. Das sind 1.000.000 Bits pro Sekunde, sprich 125.000 Bytes pro Sekunde. Dann kommt noch die Zeit drauf, bis das ACK zurückkommt. Ich glaub nicht daß es sich rentiert hier irgendwas wegzulassen. Mit Platinenhertsellern kann ich nicht dienen, da bin ich zu frisch auf dem Gebiet. Hab meine selbst gebügelt und geätzt. Ist halt nur einseitig.
ich muß Dir recht geben, die Frequenznutzung und Adressierung läuft wie von Dir beschrieben. Somit kann man die zwei Adressbytes eigentlich weglassen, da die RFMs eh mit 5 Bytes Adressierung angesteuert werden. Man kann also reine Nutzdaten übertragen. Daher sollten wir nicht nur übers eigentliche Protokoll reden, sondern auch noch die Frequenz und die Adressen mit aufnehmen.
also meine RFMs sind heute angekommen, bin aber nächste Woche schon voll ausgelastet, komme also nicht zum damit spielen . Ich probier also frühestens übernächste Woche mal wie das so läuft mit der Ansteuerung und dann sehen wir was dabei raus kommt.
Wir müssen insbesondere definieren, was passiert wenn Sender & Empfänger eingeschaltet werden: Wie diese sich finden und einen freien Kanal finden, auf dem sie bleiben können. Für ersteres könnte mal eine (+ eine Backup?) Frequenz definieren, die nur für das gegenseitige finden der Geräte da ist. Auf der könnten aber auch in einen Standby-Modus versetzte Modelle darauf warten, wieder angesprochen zu werden und so Sachen. Für die Suche nach einem freien Kanal müsste man mal schauen, ob die RFMs erkennen können, ob auf einem Kanal schon jemand funkt.
Was ich zum Protokoll hinzufügen würde: Du schreibst ja irgendwo in diesem Thread was von verstellbaren Blinkfrequenzen, einstellbare Servowegbegrenzung und so weiter. Diese Daten würde ich im Empfänger-Atmel im EEPROM speichern. Nehme mal an, du würdest das auch so machen. Die Daten müssten ja dann auch in irgendeiner Form gesendet werden, das wäre also auch zu beachten. Zusätzlich wärs aber auch cool, Daten wie Name des Modells und/oder Besitzer und so Informationen zu speichern und an den Sender übertragen zu können. Was sagst du dazu?
wenn ich mich recht erinnere gabs zumindest bei den RFM12 usw eine Emfangspegelauswertung die man dann über ein Register oder einen analogen Ausgang auswerten konnte. Ob das bei den RFM70 auch vorhanden ist, müsste man mal nachschauen.
Darüber könntest du dann aber auswerten ob auf dem Kanal schon ein anderer Sender funkt und zum nächsten Kanal Springen.
Im Prinzip müstest du mit dem Sender einen freien Kanal suchen, den Empfänger in eine Schleife schicken, der zyklich alles Kanäle durchläuft. Hat nun der Sender einen freien Kanal gefunden, sendet er auf diesem ein spezielles Komando mit Senderadresse. Trifft der Empänger auf dieses Komando und die Adresse passt zu seinem Sender wählt er diesen als Betriebskanal und verwendet diesen bis z.B. zu einem Verbindungsabbruch.
Sie sind vermutlich noch nicht im Forum angemeldet - Klicken Sie hier um sich kostenlos anzumelden
Mikromodell-Chat
3
Offline
. Ich probier also frühestens übernächste Woche mal wie das so läuft mit der Ansteuerung und dann sehen wir was dabei raus kommt. 
