Datum: 02.11.2008 14:52
Hallo Ich habe auf Basis des RFM12 und einem ATmega32 ein kleines, leistungsfähiges und preiswertes Funkmodul entwickelt, das ich auf meiner Webseite für andere Bastler zur Verfügung stellen will. Bitte nicht falsch verstehen, ich will an dieser Stelle keine Werbung machen oder irgendeinen Profit herausschlagen! Das ganze ist ein reines Hobbyprojekt von mir. Ich habe nur immer wieder gesehen, dass hier viele Bastler Probleme mit dem RFM12 haben. Um der Community quasi etwas zurückzugeben habe ich Dokumentation, Schaltpläne und Sourcecodes online gestellt. -------------------------- Um was handelt es sich? Das Funkboard ist eine kleine Platine und setzt sich im Wesentlichen aus dem RFM12, einem ATmega32 und etwas Peripherie zusammen. Der AVR übernimmt die komplette Ansteuerung und verwandelt die Schaltung in eine Art Funkmodul-"Blackbox". Dieses kann man dann sehr einfach in den verschiedensten Projekten wiederverwenden. Externe Mikrocontroller (und ihre Programmierer ;-) ) müssen sich nicht mit der Ansteuerung des RFM12 auseinandersetzen. Das alles übernimmt der AVR. Man übergibt der "Blackbox" lediglich die zu übertragenen Daten. Initialisierungen, Puffern, Checksummen, Empfangsquittierungen, etc. läuft alles intern ab. Das ganze lässt sich natürlich in vollem Maße konfigurieren. Man hat per Software über den AVR Zugriff auf fast alle Einstellungen des RFM12 und des AVRs. Kernmerkmale: - 434MHz Sende-/Empfangsfrequenz - Halbduplexfähig - Reichweite bis einige hundert Meter - SMA Antennenanschluss vorgesehen - 32*34mm Abmessungen, steckbar durch 2 Stiftleisten im 2,54mm Raster - Funknetzwerk mit bis zu 125 Modulen möglich! - Ansteuerung über UART, I2C und SPI in Planung - Konfigurationen des AVRs und RFM12 ohne Neuprogrammierung änderbar - Übertragungssicherheit von nahezu 100%! - Schnelle Sende-Empfang-Umschaltzeiten von ca. 1,5ms - PC Terminalprogramm zum Testen und Konfigurieren - 3,2V - 5,4V Betriebsspannungsbereich - Ca 10mA Stromverbrauch (nicht gemessen), 2 Schlafmodis bis 25µA! Das ganze ist noch nicht ganz fertig. Funktionieren tut aber alles so weit wie beschrieben. Hoffe damit dem ein oder anderen helfen zu können. Über konstruktive Kritik freue ich mich natürlich besonders :-) Alles weitere unter: http://www.flashcraft.de Ein Bild der mit EAGLE 3D gerenderten Platine: http://flashcraft.de/images/user_images/funkboard/... (Oberseite, RFM12 nur mit Bestückungsdruck sichtbar)
Datum: 02.11.2008 15:21
Hallo, das sollte keine prinzipielle Kritik sein, jedoch wäre es nicht zielführender, einen Mega48 oder so zu verwenden, als einen Mega32, der doch einiges mehr kostet. Ich denke nicht, daß für die einfache Aufgabe der Speicherplatz des Mega32 wirklich gebraucht wird, und daß ein Mega48 das auch problemlos schaffen könnte.
Datum: 02.11.2008 15:22
also deine Seite ist wirklich Spitze, vor allem die 57 seitige Doku, Respekt! Das ist eine gute Referenz wenn du dich nach dem Studium irgendwo bewirbst.
Datum: 02.11.2008 15:27
>Ich denke nicht, daß für die einfache Aufgabe >der Speicherplatz des Mega32 wirklich gebraucht wird, und daß ein Mega48 >das auch problemlos schaffen könnte. Na dann setz Dich mal hin und mach mal.
Datum: 02.11.2008 15:35
Nach dem ersten Überfliegen: Hochachtung: Sauberes Projekt und mehr als gut dokumentiert. Da kann sich so mancher einer eine Scheibe von abschneiden. Frage 1: Warum können die Datenpakete denn nur 50 Byte lang sein ? Damit wird der Anwendungsbereich doch ein wenig eingeschränkt (Okay, gebe zu, 10 Pakete a 50 Bytes gibt auch ca. 512 Bytes). Frage 2: CRCs sind ja schon implementiert. Gibt's noch Platz im Flash um z.B. Manchester encoding einzubauen, um die Clock and Signal recovery zu verbessern ? Gruß Manni
Datum: 02.11.2008 16:07
RESPEKT !!!! Tolles Projekt. Ich habe auch so ein paar Module rumliegen und hatte eine ähnliche Idee, aber keine Zeit ...
Datum: 02.11.2008 16:29
Vielen Dank erst einmal für eure Kritik :) gast wrote: > Hallo, > das sollte keine prinzipielle Kritik sein, jedoch wäre es nicht > zielführender, einen Mega48 oder so zu verwenden, als einen Mega32, der > doch einiges mehr kostet. Ich denke nicht, daß für die einfache Aufgabe > der Speicherplatz des Mega32 wirklich gebraucht wird, und daß ein Mega48 > das auch problemlos schaffen könnte. So einfach wars dann doch nicht ;) Ich habe auch lange überlegt welchen µC ich verwende. Ein Mega48 ist definitiv zu klein. Da kommt schon etwas an Code zusammen. Der Flash des Mega32 ist zu ca. 70% voll, macht also ca. 23kB. Kleinvieh macht auch Mist, und die Datenpufferung sowieso. Weil ich sowieso noch einige Mega32 in DIL herumliegen hatte und damit sofort mit einem 1:1 Testaufbau starten konnte fiel die Wahl dann auf den. Manni wrote: > Frage 1: Warum können die Datenpakete denn nur 50 Byte lang sein ? Damit > wird der Anwendungsbereich doch ein wenig eingeschränkt (Okay, gebe zu, > 10 Pakete a 50 Bytes gibt auch ca. 512 Bytes). > > Frage 2: CRCs sind ja schon implementiert. Gibt's noch Platz im Flash um > z.B. Manchester encoding einzubauen, um die Clock and Signal recovery zu > verbessern ? Zu 1: Ich werde beim Überarbeiten des Codes die maximale Paketgröße auf ca. 70-80 (oder höher) anheben. Das ist schnell gemacht. Ich wusste anfangs noch nicht wie ich mit dem Flash hinkomme. Darum habe ich die Paketgröße (die gleich mehrfach reserviert wird wegen interner Pufferung) anfangs recht moderat gewählt und sie bis zum Ende so belassen, auch weil ich meist nur kleine Paketlängen benötige. Aber wie gesagt, kein großer Akt die nach oben zu schrauben. Zu 2: Ca. 30% des Flashes sind noch frei. Da gibts noch viel Platz für Erweiterungen :) Manchester wäre denkbar. Ebenso wie eine Verschlüsselung der gesendeten Daten.
Datum: 02.11.2008 17:24
wär gut wenn das eindrücke bild einen link zum prject hätte
Datum: 02.11.2008 17:49
>So einfach wars dann doch nicht ;) >Ich habe auch lange überlegt welchen µC ich verwende. Ein Mega48 ist >definitiv zu klein. Da kommt schon etwas an Code zusammen. >Der Flash des Mega32 ist zu ca. 70% voll, macht also ca. 23kB. >Kleinvieh macht auch Mist, und die Datenpufferung sowieso. >Weil ich sowieso noch einige Mega32 in DIL herumliegen hatte und damit >sofort mit einem 1:1 Testaufbau starten konnte fiel die Wahl dann auf >den. Verstanden, code ist auch konfortabel geschrieben. Sollte interesse bestehen, ich wäre interessiert, so ein modul im 2-3 Euro bereich (ohne RFM12) zu entwickeln, und auch abzugeben, mit RFM12 aufgelötet.
Datum: 02.11.2008 22:44
Hallo Florian - klasse Projekt! Aber wie kommst du darauf, daß der Flash des Mega32 bereits zu 70% voll ist? Habe deine Sourcen gerade mal bei mir compiliert und ich komme da nur auf ca. 9KB!
Datum: 03.11.2008 00:05
Wenn Volker recht hat, dann passt ja noch ne Menge rein. Ist wohl nur eine Frage, welche Compiler Optionen man verwendet (-O0 bis -Os). Du hast den richtigen Weg gewählt: erst mal sehn, wie groß der Gesamtcode wird, und dann kann man die Datenpaketgröße immer noch anpassen !! Bin gerade dabei einen FEC Algorithmus mit Convolutional Encoder mit Constraint Length von bis zu 7 auf TX Seite und auf RX Seite mit einem Viterbi Dekoder zu entwickeln. Sollte schon in einen ATmega32 passen. Vielleicht kann man den dann noch da rein packen. Nochmals: Tolles Projekt und Respekt !!!! Gruß Manni
Datum: 03.11.2008 08:59
Hi, super Projekt! Hast Du vor, die Eagle-Files bereitzustellen oder bietest Du gar Platinen zum Kauf an? Ich hätte starkes Interesse ;-) Danke und Grüße, Jürgen
Datum: 03.11.2008 09:40
Schönes Projekt. Wie wäre es, den extra Quarz für den ATmega weg zu optimieren? Es ist ja ein Quarz beim Funkmodul vorhanden, dessen Taktsignal ja genutzt werden kann. Gruß
Datum: 03.11.2008 14:24
@ Volker Wie hast du den Code denn auf 9KB gebracht? Habe bei meinem AVRStudio Optimierung -Os eingestellt, dennoch bleibe ich bei 23kB hängen. aber in jedem Fall ist noch Platz für Erweiterungen :) @ Jürgen A. Habe im Moment selbst nur einen 1:1 Aufbau auf Lochraster und warte noch auf meine Prototypenplatinen die diese Woche kommen sollten. Funktionieren sollten sie sicher, allerdings sind sie noch nicht "für die Masse" ausgelegt, da werden noch Überarbeitungen anstehen um die Platinen einfacher und billiger herstellen zu können. Vorerst macht es also keinen Sinn das Layout freizugeben. @ 123 Der Quarz wurde absichtlich als externes und bedrahtetes Bauelement draufgepackt. Hintergrund ist vor allem die UART-Baudrate. Die auswählbaren Takte des RFM12 eignen sich für viele Baudraten nicht, mit einem externen Quarz kann man die Baudraten frei wählen. Betreibt man außerdem das Modul mit 3,3V darf der Takt des AVRs 8MHz nicht überschreiten. Dann müsste man den RFM12 Takt am DCLK auf (max) 5MHz setzen...wieder Problem mit Baudraten und 3MHz verschenkt falls man diese will/braucht
Datum: 03.11.2008 14:54
@Florian:
>Wie hast du den Code denn auf 9KB gebracht?
Ich gar nicht - habe nur das Makefile ausführen lassen ;-)
Das ist die Ausgabe von avr-size:
text data bss dec hex filename
8982 50 1456 10488 28f8 FUNKMODUL.elf
Okay, es sind dann doch etwas mehr als 10KB - hatte nur das reine
Textsegment betrachtet - aber 23?
Oder habe ich da was übersehen?
Gruß, Volker
Datum: 03.11.2008 15:08
@volker, welche libs hattest du benutzt ?
Datum: 03.11.2008 15:25
@Florian: Vielleicht hast du eine von den verbuggten AVR-GCCs erwischt. Ansonsten: Super Projekt! Die Doku ist ja Wahnsinn.
Datum: 03.11.2008 15:45
Ich habe mir auch so ein Funkboard gebaut! Allerdings nur mit nem Mega8 und nem RS232 on Board : http://defencemercury1.dyndns.org/AlexanderDW/Bild... Bestückt werden kann diese auch mit nem USB-Port. Spannungsversorgung kommt dann vom USB-Anschluss des PCs. Die Einzellplatine hat mich knapp 12 Euro zzgl MwSt. gekostet! Falls Interesse besteht, kann ich ne Ladung Platinen bestellen lassen! Grüße Alex
Datum: 03.11.2008 15:50
Florian Scherb wrote: > @ Volker > > Wie hast du den Code denn auf 9KB gebracht? > Habe bei meinem AVRStudio Optimierung -Os eingestellt, > dennoch bleibe ich bei 23kB hängen. > > aber in jedem Fall ist noch Platz für Erweiterungen :) Habs mir grad mal angeschaut. Dein .hex file aus dem rar ist ja nur 25kb gross, da kann dein Code garkeine 23kb sein. Das .elf aus dem rar sagt mit avr-size bei mir auch: text data bss dec hex filename 9058 50 1456 10564 2944 FUNKMODUL.elf Trotz allem, sieht nach ner netten Sache aus. Hab heute meine RFM*-Module bekommen, werde da wohl gleich mal was mit rumspielen. :)
Datum: 03.11.2008 16:14
Hast du evtl. Lust das Protokoll kompatible zu http://www.mikrocontroller.net/articles/RFM12_Prot... zu machen? An dem verlinken Stack ist natürlich auch noch nicht alles fix, kann man sich also in der Mitte treffen. Dein AVR würde dann quasi Layer 1 und 2 übernehmen. Die PC Seite lässt sich auch günstig mit einem USBprog realisieren, falls man schon einen hat.
Datum: 04.11.2008 06:24
@ Manuel Stahl Euer Stack sieht sehr interessant aus, konnte Ihn aber aus Zeitgründen gerade nur überfliegen. Beteiligen kann ich mich leider aus Zeitgründen schon gar nicht. Mein Projekt ist zwar fast schon fertig, aber eben nur fast ;-) Und die letzten paar Prozent kosten immer noch deutlich Zeit. @ Simon K. und Volker Danke dass ihr da nochmal geschaut habt. Wegen der Größe muss ich wirklich mal schauen. Mir kommen da auch schwere Zweifel auf ob meine 23kB stimmen. Allerdings zeigt mir das auch mein Compiler an.
Datum: 04.11.2008 16:37
Nochmal ich ;-) Weil es einige Anfragen zur Platine gibt habe ich nun dazu einen kleinen Abschnitt auf meiner Webseite angefügt. Dort werde ich das dann laufend aktualisieren wenn sich in der Richtung etwas tut.
Datum: 05.11.2008 08:17
Hallo Florian Scherb Super Projekt! Habe versucht das Terminal herunter zu laden... Die Datei wird nicht gefunden. Schaust Du Bitte mal danach? Danke
Datum: 05.11.2008 14:00
Hallo Das Terminalprogramm ist noch in Entwicklung. Die erste zur Veröffentlichung freigegebene Version wird vermutlich erst zum Wochenende hin downloadbar sein. Solange ist der Link leider tot. Hat sich leider etwas hingezogen, darum verweist die Seite auch auf einen Deathlink. Aber die Zeit zum Ändern der Seite stecke ich dann doch lieber ins Programm ;-)
Datum: 06.11.2008 17:48
Respekt! finde das Projekt wirklich sehr gelungen. Vor allem die ausführliche Dokumentation ist sehr schön! Soetwas findet man nicht alzu oft. Wenn es Platinen dazu geben würde hätte ich auch Interesse!
Datum: 08.11.2008 09:46
Danke :) So, Terminalprogramm ist nun auch fertig :) Zwar noch etwas umständlich programmiert, da kann man noch gut was wegoptimieren aber es funktioniert soweit mal ganz gut. In den nächsten Tagen und Wochen beginnt dann der Feinschliff. ------- Zum Projekt: http://www.flashcraft.de
Datum: 15.11.2008 18:23
Soooo :-) Die Prototypen sind eingetroffen und getesetet worden. Gibt noch ein paar Bugs und Dinge die noch verbessert werden können aber im Großen und Ganzen bin ich doch recht zufrieden, die Spezifikationen erfüllt es :-) Was mir mehr Kopfzerbrechen bereitet ist der Verkauf von Leiterplatten (bestückt + restliche Komponenten zum selber Löten). Das lasse ich nun sehr wahrscheinlich bleiben, es wird also keine Leiterplatten oder teilweise fertige bis komplett fertige Funkboards zum Kaufen geben. Die ganze Rechtslage ist mir doch etwas zu heiß. Ich kenne mich mit dem Verkauf von "Bastlerzeug" nicht genug aus um einen Verkauf zu wagen. In jedem Fall wäre wohl ein Gewerbeschein nötig, da sich der Verkauf nur bei etwas größeren Stückzahlen lohnt (>50, die hätte ich jedoch wohl). Dazu kommen noch die EMV-Richtlinien, die bei einem Funkmodul ja mal mehr als heikel sind...usw. Unterm Strich zu viel Aufwand und Risiko für das Ganze,... Eigentlich schade,...
Datum: 15.11.2008 18:46
Wer auf ATMega 8 in DIL gehen möchte kann folgendes nachbauen Testboard: http://comwebnet.weimars.net/index.php?option=com_...
Datum: 15.11.2008 23:34
Schade, Florian! Vielleicht kannst du dich ja noch mit dem Gedanken anfreunden, dass ein Anderer die Boards verkaufen kann/darf. Einen Tipp habe ich dir ja schon per Email gegeben ;-) Falls nicht, stellst Du wenigsten das Layout zur Verfügung? Danke und Grüße, Jürgen
Datum: 16.11.2008 11:04
Hallo Wenn die Boards nicht verkauft werden werde ich auf jeden Fall das Layout online stellen, soviel ist sicher :)
Datum: 16.11.2008 12:02
Du könntest ja auch die nackten Platinen verkaufen...
Datum: 16.11.2008 12:32
abo .. mit der Hoffnung das jemand von dem Teil unbestueckte Platinen verkauft :D ..
Datum: 16.11.2008 16:51
Es steht letztendlich natürlich allen frei sich zu Sammelbestellungen für die Platinen zusammenzuschließen ;-) Genaueres werde ich dann aber auch nochmal durchgeben, wenns so weit wäre. Ich werde die Sammelbestellungen auf jeden Fall nicht koordinieren. Sorry. Ich bin schon mit der Entwicklung gut beschäftigt. Nebenher dann noch reihenweise Pakete zu verschicken, Überweisungen zu kontrollieren und Rabatte rauszuschlagen ist mir dann wirklich zu viel. Bei fertigen oder halbfertigen Modulen wäre das was anderes gewesen, aber weil mir das eben zu heiß ist lass ich das bleiben.
Datum: 16.11.2008 19:08
Wäre evtl. auch interessiert! Wurde das Layout für die Verbindung zwischen Funkmodul und Antenne für 433MHz optimiert? Beste Grüße, Tiga
Datum: 16.11.2008 20:22
Hallo Bei meinen Prototypen nicht. Kommt aber auch darauf an, was du genau meinst. Viel zu Optimieren gab es da jetzt nicht. Der Antennenausgang des RFM12 ist praktisch direkt an der SMA-Buchse dran. Nur ca. 3mm Leiterbahnweg, der so weit es ging mit Masseflächen vor anderen Signalleitungen abgeschirmt wurde. Von da an hängt dann alles weitere an der Antenne selbst. Die Massefläche selbst wurde nicht als Gegenpol ausgelegt, ist bei dem kleinen Ding auch kaum vernünftig zu schaffen...das ist dann dem SMA-Antennenaufbau überlassen.
Datum: 16.11.2008 20:56
Leider kenne ich mich mit dieser Problematik auch nicht besonders gut aus... Ich habe nur im Schaltplan gesehen das Du auch eine Stichleitung zum CON2 gezogen hast. Wie viel das schadet weis ich aber auch nicht genau. Aber die Lötbrücke vom RFM zum Board ist ja auch eher nur suboptimal (ich weis, "irgendwie" muss man das Signal ja rüber bringen ) - wahrscheinlich fällt es somit gar nicht so sehr ins Gewicht.
Datum: 17.11.2008 11:25
Achso, das meinst du. Die Lötbrücke ist denke ich weniger problematisch. Das RFM12 liegt direkt auf den verzinnten Kontakten der Platine auf. Das Lot muss keine lange Brücke bilden. Ja, die Stichleitung zu den Stiftleisten habe ich mit eingebaut wenn man andere Antennen verwenden will. MMCX-Stecker, BNC oder ein einfaches Drahtstück auf Lochraster. Wenn diese Möglichkeiten nicht verwendet werden, so kann man diesen "Stift der Stiftleiste" auch einfach weglassen. ;-)
Datum: 17.11.2008 13:58
Hast du mal überlegt, deine Entwicklung an das "Embedded Projects Journal" zu schicken? Eventuell könnte man ja auch über diesen Weg die Platine bzw. den Bausatz vertreiben. Ist nur so eine Idee, da es schade wäre wenn das Modul für andere nicht nutzbar / nachbaubar wäre. Sven
Datum: 17.11.2008 16:03
Das ist eine tolle Idee! Vielen Dank für diesen Hinweis :-) Sobald das ganze "Marktreife" angenommen hat werde ich mich mal damit befassen. Wäre wirklich klasse wenn sich darüber etwas erreichen liese.
Datum: 20.11.2008 09:44
Hallo zusammen, ich beabsichtige RFM-Funkmodule (vielleicht auch die DIL-Varianten) zu kaufen und suche aber noch einen passenden Aufbau (Layout, Bausatz,...) damit man nicht von "0" anfangen muß. Ziel ist die Anbindung an den µServer von Simon Küpper, das Board sollte also schön klein sein. Da mir das Pollin-Board zu groß ist, habe ich bisher 2 Möglichkeiten. 1) Board zu dem Artikel "AVR RFM12" http://www.mikrocontroller.net/articles/AVR_RFM12 2) Funkboard von Florian Scherb http://www.flashcraft.de/index.php/funkboard-uebersicht Die 2 wichtigsten Fragen: @Florian Wird es in naher Zukunft (vor Weihnachten:-) eine Platine in einem Shop geben oder wenigstens das Layout? @all Ich würde gerne die 8xxMHz Module verwenden. Läuft da die ganze Software auch mit? Jetzt bin ich natürlich etwas ratlos. Auf welches Pferd soll ich setzen? Für 2) spricht, dass mehr Leute dran mitgewirkt haben und es mehr Community-Unterstützung gibt. Dafür besticht 1) durch sehr gute Doku und macht daher einen wirklich soliden Eindruck. Gerne würde ich mal Eure Meinung dazu hören (ich hoffe, dass kann ich im Rahmen dieses Threads anstossen, es geht ja auch um technische details des Funkboards). Vielen Dank Grüße Jörg
Datum: 20.11.2008 13:41
@ Jörg T. Für was du dich letztendlich entscheidest hängt auch von deinen Ansprüchen und Wünschen ab. Die 2 Dinger sind zwar recht ähnlich, aber haben halt schon gewisse Unterschiede. Ich möchte da nicht buhlen ;-) @ All (und @ Jörg T.) Fakt ist, dass ich mein Layout in den nächsten Tagen online stelle. Dann kann es jeder verwenden. Ich hoffe, zumindest gibt es schon Interessenten, dass manche das Layout so abändern, dass man es auch durch einfachere (Ätz-)Prozesse herstellen kann. Ziel ist in jedem Fall, dass es nach einer Zeit verschiedene Layouts für verschiedene Ansprüche gibt. Zur Not setze ich mich selbst daran ;-) Arbeite gerade an einer endgültigen Version der Doku in der einige Käfer noch behoben werden. Selbiges beim Quellcode. Danach werde ich das ganze dann mal Embedded Projects o.ä. vorlegen. Evtl. wird es dann dort auch eingestellt werden. Wenn nicht als fertiger Bausatz, dann zumindest "einfach so". Ihr könnt gerne jetzt schon daran mitwirken und das Projekt für euch nutzen :) Aber ich muss hier nochmal ganz klar sagen, dass das Projekt noch nicht abgeschlossen ist. Der Faktor "Unbekannt" ist also noch da. Soll aber niemanden abhalten ;) Ich werde in den nächsten Tagen/Wochen erste Stresstests machen und mal schauen wie sich die Dinger im harten Bastleralltag so erproben ;-) Ob die 868-Module funktionieren würde mich ebenfalls interessieren. Ich besitze leider keines. Wäre super, wenn sich da jemand melden könnte der das weis.
Datum: 20.11.2008 14:37
Hallo Florian, was genau heisst "einfacherer Ätzprozess"? Das ist doch eine doppelseitige Platine, oder? Ist das Bild auf Deiner Website die Platine, die Du kürzlich aus der Fertigung erhalten hast? Ja, dass mit den 868MHz Modulen interessiert mich am meisten, da ich diese jetzt als erstes in Kürze bestellen will. Mit dem Board würde ich zur Not noch warten können (bis das Layout und die Doku bugfixed ist). Vielleicht gibt es ja eine Aussage von den Machern des anderen Boards und deren RFM12-Stack Implementation. Ich weiß ehrlich gesagt nicht einmal, ob die 400 und 800er Pin-kompatibel sind... Gruß Jörg
Datum: 20.11.2008 14:59
Von mir ist das andere hier genannte Board. Wichtig war dabei möglichst kleiner Footprint (deshalb ist der AVR auf der Rückseite) und dass man es direkt an USB anschließen kann. Allerdings sind mir ein paar Fehler (auf der Wikiseite dokumentiert) aufgefallen, die erst beim Fertigen zu sehen waren. Wenn jemand das Board nachbauen will sollte man da erst nochmal drübersehen.
Datum: 20.11.2008 15:06
Hallo Manuel, vielen Dank für die Infos. Die Hinweise bzgl. der kleinen "Bugs" hatte ich gelesen. Könntest Du Dich denn zu einer Aussage hinreissen lassen, ob man auch (ggf. mit welchem Aufwand) die 800er Module verwenden kann :-) Mir scheint, als gibt es mit den 800er Modulen allgemein noch nicht viel Erfahrung, oder? Gruß Jörg
Datum: 20.11.2008 15:08
Jetzt auch mit Photo: http://www.mikrocontroller.net/articles/AVR_RFM12#Platine
Datum: 20.11.2008 15:12
Das Datenblatt ist jedenfalls das gleiche für alle Bänder: http://www.hoperf.com/pdf/RFM12.pdf Daher sollte auch das Pinlayout gleich sein und die Ansteuerung sowieso. Gibt sogar ein Register in dem das Band festgelegt wird.
Configuration Setting Hex = 80 & xx Bit-Syntax: 10000000 | el | ef | b1 | b0 | x3 | x2 | x1 | x0 el (TX FIFO) = Sendepuffer für Datentransfer nutzen (1 = An / 0 = Aus) ef (RX FIFO) = Empfangspuffer für Datenspeicherung nutzen (1 = An / 0 = Aus) b... = Zu nutzende Basisfrequenz (00=315MHz / 01=433MHz / 10=868MHz / 11=915MHz) x... = Interner Clock des Chips kann durch verschieben einer Kondensator-Anpass-Stufe bestimmt werden. 0,5pF pro Schritt. Basis ist 8,5pF -> (0000=8,5 / 0001=9,0 / 0010=9,5 / ...) |
Datum: 20.11.2008 15:50
@Manuel, kommt denn eigentlich auch ein Normalsterblicher an einen svn-Zugang? Wegen Eagle-Layout etc. Gruß
Datum: 20.11.2008 15:53
Für das SVN hier? (-> Andreas Schwarz fragen) Oder willst du ein eigenes SVN? (Sourceforge)
Datum: 20.11.2008 16:12
ein eigenes SVN wollte ich nicht vielleicht habe ich das auch falsch verstanden mein Verständnis nach, ist ein Zugang in diesem Projekt auch erforderlich, wenn man "nur" Sourcen, Layout, etc. lesen will - ist das richtig? oft ist ja auch so, dass man ein Zugang benötigt, wenn man konstruktiv mitwirkt...
Datum: 20.11.2008 16:17
Richtig
Datum: 20.11.2008 16:26
Wegen dem 868 RFM12 Modul nochmal... Ja, die Datenblätter, Pinlayout, Platine etc ist genau gleich. Aber bevor ich da jetzt einfach sage "433 Modul zu 868 Modul äquivalent" wäre eine Bestätigung von jemand der das tatsächlich schon ausprobiert hat natürlich besser. Dass die Datenblätter bisschen...naja...sind ist ja bekannt.
Datum: 20.11.2008 16:29
Habe beide Module hier, sind Pinkompatible.
Datum: 21.11.2008 18:33
Super, klingt ja gut :-) Board Layout ist nun auch online.
Datum: 21.11.2008 20:09
Hey alle miteinander!! Ich wusste bis eben nichts von dem Thread hier, ich hab das hauptsächlich im Roboternetz verfolgt, dort gibt es quasi "den gleichen" thread. Da ich dort eine Sammelbestellung organisiert habe, möchte ich das natürlich auch hier anbieten. Angeboten werden original Flashcraft-Funkmodul-Platinen und zusätzlich biete ich an die Bauteile (ohne das RFM12) an. die Bauteile kosten etwa 10 euro (reichelt.de halt den einkaufspreis+versandanteil) das RFM12 gibts auch zu haben, werden auch nochmal für die mitbesteller bei pollin.de bestellt. das mit den bauteilen: entweder alle, oder keins, zwischendinger machen mir zu viel arbeit sorry... ansonsten, einfach die "bestellungen" an Pr0gm4n ( ät ) gmy.de (gmx.de halt...) ich hoffe, ihr nehmt zahlreich teil, dann können wir den preis noch weiter senken!! denkt bitte daran, bestellungen, die nicht per e-mail erfolgen kann ich leider nicht wahrnehmen und ihr habt mit dieser e-mail auch noch keinerlei verpflichtungen uns gegenüber auch wirklich teilzunehmen... LG Pr0gm4n
Datum: 21.11.2008 23:54
Hallo, verstehe ich nicht. Ich dachte das Layout wäre heute erst online gestellt von Florian? Gruß
Datum: 22.11.2008 00:10
Verstehe an vielen Stellen nicht warum das so geroutet ist. Warum nicht die richtigen Pads für die SUB-D9 Buchse? Gibts doch als fertiges Bauteil.. Und ich verstehe nicht ganz warum da über den Antennenstecker geroutet wurde..nicht sehr elegant..
Datum: 22.11.2008 08:49
@Jörg T. Ist es auch. Zu dem Design selbst noch: Es funktioniert, allerdings ist es nicht gerade optimal geroutet, muss ich selbst zugeben. Mir ging es damals mehr darum das Ding überhaupts mal auf meinem Tisch liegen zu haben ;)
Datum: 22.11.2008 10:20
@Max: Ja das Routing ist nicht so toll geworden. Die SUB-D Kontakte sind aber Absicht (siehe Photo im Wiki) da man direkt eine Buchse anlöten kann.
Datum: 22.11.2008 17:58
Hallo, könnte bitte noch wer die "Top Seite" als Bild anhängen. Die "Bottom Seite" ist ja schon hier im Thread. Danke Peter
Datum: 22.11.2008 18:04
Schau doch einfach hier: http://www.mikrocontroller.net/articles/AVR_RFM12#Platine
Datum: 22.11.2008 18:04
@Florian heisst das, man hat Dein Board layoutet und in einer Sammelbestellung in Auftrag gegeben? Warst Du auch daran beteiligt? Ist das dasselbe Board?
Datum: 22.11.2008 18:16
Oh, sorry, dachte das Layout sei das von Florian. Kann bitte wer Florians Board als Bilder einstellen. Ober und Unterseite. Vielen Dank, Peter
Datum: 22.11.2008 19:24
Hi Puchi, Florian hat sein Layout auf seiner Homepage http://www.flashcraft.de/index.php/projekt-funkboa... bereitgestellt. @all Sorry, dass ich hier mit meiner Anfrage doch etwas Verwirrung und Verwechselungen hereingebracht habe...
Datum: 22.11.2008 19:33
Hallo, danke, das wusste ich schon, hab jedoch kein Eagle. Also kann die schnell wer hochladen? Wäre euch sehr dankbar, Peter
Datum: 23.11.2008 13:58
Hab mir grad mal die Doku zur Datenübertragung durchgelesen. Ich persönlich finde Florian lehnt sich hier mit manchen Formulierungen etwas weit aus dem Fenster: -Sehr kurze Umschaltzeiten zwischen Senden/Empfangen (ca 1,5ms). Das entspricht bei 38400 Baud immerhin mehr als 7 Byte, also etwa ein kurzes Paket. (Ich weiß, das liegt am RFM12) -Nahezu 100% Datensicherheit. Bei Funk grundsätzlich nicht möglich. Nahezu 100% Sicherheit, dass Fehler erkannt werden? Naja, siehe Checksummen. Startzeichen: Warum wird nicht die RFM12 Startsequenz erwähnt? Wird sie nicht verwendet? Checksummen: -Checksummen nach jedem fünften Byte. Was soll das bringen? Wenn der Empfänger früher abbricht, merkt der Sender das nicht und sendet trotzdem das komplette Paket. -Checksummen durch Quersummenbildung. Sehr problematisch bei Funk. Stichwort Büschelfehler. Angenommen alle Nutzdaten sind 0x00, dann ist auch die Quersumme 0x00. Das kann durchaus mal zufällig passieren. Blackbox: Beim Empfang wird das ACK in der ID untergebracht -> lässt sich nicht mehr nachträglich ändern. Das alles ist nicht böse gemeint, soll nur konstruktive Kritik sein.
Datum: 23.11.2008 14:31
@Manuel Stahl Da hast du stellenweise natürlich recht. Ich arbeite gerade auch noch an der Doku, dass sie formal passt und nicht "zu abgehoben" klingt :) Ich habe mich bei allen formulierungen auf andere Funkmodule in der Preisklasse um ca. 50€ pro Stück bezogen, von denen ich selbst welche hier habe. Quasi als Referenz. >> -Sehr kurze Umschaltzeiten zwischen Senden/Empfangen (ca 1,5ms). >> >> Das entspricht bei 38400 Baud immerhin mehr als 7 Byte, also etwa ein >> kurzes Paket. (Ich weiß, das liegt am RFM12) Ein Punkt wo ich die Doku überarbeiten werde, da gebe ich noch genaue Werte an. Grob kann man sagen 1,5ms. Ist im Vgl. zu anderen Modulen relativ wenig. Habe hier welche mit 2ms und 4ms. >> -Nahezu 100% Datensicherheit. >> Bei Funk grundsätzlich nicht möglich. Nahezu 100% Sicherheit, dass >> Fehler erkannt werden? Naja, siehe Checksummen. Muss ich dir auch recht geben. Mit dem Satz beziehe ich mich darauf, dass gesendete Daten mit allen Sicherheitseinstellungen nicht falsch am Empfänger interpretiert werden und dass "normale Bastlerumgebung" verwendet wird. >> Startzeichen: >> Warum wird nicht die RFM12 Startsequenz erwähnt? Wird sie nicht >> verwendet? Welche Startsequenz meinst du genau? Das Startzeichen als Sicherheitsmerkmal ist natürlich nicht der Reisser. Aber, und das kommt auch noch in die Doku, sie macht die Arbeit beim Debuggen enorm leichter, da man sehr schnell einen Einstiegspunkt in die Übertragung findet. >> -Checksummen nach jedem fünften Byte. >> Was soll das bringen? Wenn der Empfänger früher abbricht, merkt der >> Sender das nicht und sendet trotzdem das komplette Paket. Richtig. Wenn man jedoch Pakete mit 40, 50 Bytes versendet und "Bitdreher" passieren merkt das der Empfänger (und kann immer noch ein NACK senden). Sie werden immerhin dann nicht falsch interpretiert. >> -Checksummen durch Quersummenbildung. >> Sehr problematisch bei Funk. Stichwort Büschelfehler. Angenommen alle >> Nutzdaten sind 0x00, dann ist auch die Quersumme 0x00. Das kann durchaus >> mal zufällig passieren. Den Punkt will und muss ich auch noch ändern. Die Checksumme soll dann aus zusätzliche arithmetischen Operation gebildet werden. Multiplikation, Addition usw. Dadurch wird sowas zumindest weitgehend unterbunden. >> Blackbox: >> Beim Empfang wird das ACK in der ID untergebracht -> lässt sich nicht >> mehr nachträglich ändern. Da kann ich dir nicht ganz folgen? >> Das alles ist nicht böse gemeint, soll nur konstruktive Kritik sein. Finde ich super!! :) Das Ding ist ja auch nur ein Hobby-Projekt, also nichts in sich perfektes :) Und um zusätzliche Ideen und Vorschläge bin ich immer wieder froh.
Datum: 23.11.2008 14:42
Florian Scherb wrote: >>> Startzeichen: > >>> Warum wird nicht die RFM12 Startsequenz erwähnt? Wird sie nicht >>> verwendet? > > Welche Startsequenz meinst du genau? > Das Startzeichen als Sicherheitsmerkmal ist natürlich nicht der Reisser. > Aber, und das kommt auch noch in die Doku, sie macht die Arbeit beim > Debuggen enorm leichter, da man sehr schnell einen Einstiegspunkt in die > Übertragung findet. 0x2D 0xD4, darauf kann man das RFM12 triggern lassen. Vorher fängt es gar nicht an was zu empfangen -> der µC muss nicht aufwachen. Vor den Sync sollte man aber noch zweimal 0xAA senden um den Takt auf die Flanken zu synchronisieren. >>> -Checksummen nach jedem fünften Byte. > >>> Was soll das bringen? Wenn der Empfänger früher abbricht, merkt der >>> Sender das nicht und sendet trotzdem das komplette Paket. > > Richtig. Wenn man jedoch Pakete mit 40, 50 Bytes versendet und > "Bitdreher" passieren merkt das der Empfänger (und kann immer noch ein > NACK senden). Sie werden immerhin dann nicht falsch interpretiert. Aber NACK kann er doch auch erst nach dem kompletten Paket senden. Eine (evtl. auch längere) Checksumme tuts genauso. >>> -Checksummen durch Quersummenbildung. > >>> Sehr problematisch bei Funk. Stichwort Büschelfehler. Angenommen alle >>> Nutzdaten sind 0x00, dann ist auch die Quersumme 0x00. Das kann durchaus >>> mal zufällig passieren. > > Den Punkt will und muss ich auch noch ändern. Die Checksumme soll dann > aus zusätzliche arithmetischen Operation gebildet werden. > Multiplikation, Addition usw. Dadurch wird sowas zumindest weitgehend > unterbunden. Nimm doch einfach nen Standard. In der util/crc16.h der avrlibc findet sich die Funktion _crc_ibutton_update() welche eine 8-bit CRC implementiert. >>> Blackbox: > >>> Beim Empfang wird das ACK in der ID untergebracht -> lässt sich nicht >>> mehr nachträglich ändern. > > Da kann ich dir nicht ganz folgen? Du kannst z.B. den Addressbereich nicht nachträglich vergrößern oder ähnliches, da man bei der Verwendung einen Teil des Protokolls (in diesem Fall zwar nur ein kleiner) kennen muss.
Datum: 23.11.2008 14:57
Manuel Stahl wrote: > Florian Scherb wrote: > >>>> Startzeichen: >> >>>> Warum wird nicht die RFM12 Startsequenz erwähnt? Wird sie nicht >>>> verwendet? >> >> Welche Startsequenz meinst du genau? >> Das Startzeichen als Sicherheitsmerkmal ist natürlich nicht der Reisser. >> Aber, und das kommt auch noch in die Doku, sie macht die Arbeit beim >> Debuggen enorm leichter, da man sehr schnell einen Einstiegspunkt in die >> Übertragung findet. > > 0x2D 0xD4, darauf kann man das RFM12 triggern lassen. Vorher fängt es > gar nicht an was zu empfangen -> der µC muss nicht aufwachen. Vor den > Sync sollte man aber noch zweimal 0xAA senden um den Takt auf die > Flanken zu synchronisieren. > Achso jetzt, das ist bereits drin. >>>> -Checksummen nach jedem fünften Byte. >> >>>> Was soll das bringen? Wenn der Empfänger früher abbricht, merkt der >>>> Sender das nicht und sendet trotzdem das komplette Paket. >> >> Richtig. Wenn man jedoch Pakete mit 40, 50 Bytes versendet und >> "Bitdreher" passieren merkt das der Empfänger (und kann immer noch ein >> NACK senden). Sie werden immerhin dann nicht falsch interpretiert. > > Aber NACK kann er doch auch erst nach dem kompletten Paket senden. Eine > (evtl. auch längere) Checksumme tuts genauso. > An eine längere Checksumme dachte ich auch schon, ja. Und mit deinen Einwänden/Vorschlägen ist das wirklich eine Überlegung wert. >>>> -Checksummen durch Quersummenbildung. >> >>>> Sehr problematisch bei Funk. Stichwort Büschelfehler. Angenommen alle >>>> Nutzdaten sind 0x00, dann ist auch die Quersumme 0x00. Das kann durchaus >>>> mal zufällig passieren. >> >> Den Punkt will und muss ich auch noch ändern. Die Checksumme soll dann >> aus zusätzliche arithmetischen Operation gebildet werden. >> Multiplikation, Addition usw. Dadurch wird sowas zumindest weitgehend >> unterbunden. > > Nimm doch einfach nen Standard. In der util/crc16.h der avrlibc findet > sich die Funktion _crc_ibutton_update() welche eine 8-bit CRC > implementiert. > Dass es dafür einen quasi-standard gibt wusste ich noch nicht. Werde ich mir aber anschauen. Danke! >>>> Blackbox: >> >>>> Beim Empfang wird das ACK in der ID untergebracht -> lässt sich nicht >>>> mehr nachträglich ändern. >> >> Da kann ich dir nicht ganz folgen? > > Du kannst z.B. den Addressbereich nicht nachträglich vergrößern oder > ähnliches, da man bei der Verwendung einen Teil des Protokolls (in > diesem Fall zwar nur ein kleiner) kennen muss. Ja richtig. Allerdings, so denke ich mir, werden 125 IDs dicke für praktisch alles ausreichen. Das ist schon eine ganze Menge. Bin über deine Ratschläge auf jeden Fall sehr dankbar. Gerade wenn man da noch mehr Leistung rauskitzeln kann. Die meisten Änderungen, gerade CRCs und sowas wären ja auch relativ schnell gemacht. Ich teste gerade die Module auf Funktion. Die Kette PC-Terminal -> Funkboard ~~~~ Funkboard -> µC + Logic Analyzer funktioniert schon einmal ganz gut. Da kann man langsam an die Verbesserungen gehen.
Datum: 23.11.2008 15:04
Noch ein Nachtrag: Genau aus diesen Gründen bitte ich da manche auch (speziell "Pr0gm4n", soll kein Angriff sein!) etwas das Tempo runterzufahren. Solange die Software hier noch in der Entwicklung ist, ist es meiner Ansicht nach zu früh sich schon darauf richtig fest zu satteln und jetzt schon Bestellungen machen. Natürlich freut mich das, aber noch ist es einfach zu früh.
Datum: 24.11.2008 08:54
Habe mir das mit den Checksummen nochmal angeschaut und muss dir absolut recht geben. Stellenweise etwas sinnfrei ;) Ich werde das nun bei Zeiten mal umändern. Die "Zwischenchecksummen" werden rausgeworfen, spart Bandbreite. Stattdessen werden alle Pakete komplett abgerufen und die (evtl. größere) Checksumme am Ende ausgewertet. Rest bleibt unverändert. Durch die Kappselung (soweit man das bei C so nennen kann) bleibt das ganze aber nach außen hin komplett unverändert. Vielen Dank nochmal für die Tipps :)
Datum: 03.12.2008 11:50
Hallo Florian gibt es denn schon neues? Wie weit ist denn die software nun? gruß
Datum: 04.12.2008 07:01
Hallo Ludwig, in ein paar Tagen gibt es wieder Neuigkeiten. Die überarbeitete Dokumentation ist so gut wie fertig. Der Code (mit den neuen CRCs) ist ebenfalls fertig. Zum Wochenende hin gibts dann ein Update. Das Funkboard dürfte damit dann über die Betaphase hinauskommen. Die größten Unsicherheitsfaktoren sind nun beseitigt. Ich werde vielleicht ebenfalls am Wochenende mal Kontakt mit Embedded Projekts aufnehmen.
Datum: 04.12.2008 09:55
Hallo Florian, das mit embedded Projects wäre wirklich eine super Idee. Ich habe mir ersteinmal Funkmodule (868MHz) gekauft, in den Weihnachtsferien wollte ich mich wieder näher mit den Boards beschäftigen. Und natürlich irgendwann auch mal etwas aufbauen. Grüße Jörg
Datum: 06.12.2008 09:07
Neuigkeiten :-) Ab heute ist die überarbeitete Dokumentation online, die übersichtlicher, umfangreicher und leichter in der Handhabung ist. :-) Außerdem ist eine neue Version des Quellcodes online. Damit würde ich nun sagen hat das Projekt die Beta-Phase nun endlich hinter sich :) Oh und, bitte stört euch nicht an dem Datum in der Doku, eigentlich wollte ich sie erst morgen online stellen aber ich war dann doch zu faul das jetzt nochmal umzuändern.
Datum: 08.12.2008 09:29
Respekt! Wirklich ein sehr sauberes Projekt! Wie läuft das denn mit dem Terminalprogramm... kann man das in andere Visual Studio Programme miteinbinden? Würde es evtl. gerne als Grundgerüst in ein eigenes Programm einbauen wollen, was ich nach Weihnachten mal anfangen wollte. Ist das einfach zu machen? Ada83
Datum: 08.12.2008 21:51
Hallo und danke auch für das Lob :) Prinzipiell ist das natürlich ohne Weiteres möglich und auch dafür vorgesehen. Genau das Selbe habe ich später damit auch vor. Es ist schon eine gute Erleichterung, wenn man bereits die Routinen zum Auslesen der Konfigurationen drin hat und das nicht für ein spezielles Projekt nochmal schreiben muss. Das Programm ist aber nicht alzu dolle programmiert. Besonders die Routine für das Empfangen von Bytes ist momentan mehr provisorisch.
Datum: 08.12.2008 23:29
Hallo, auch von mir ein großes Lob. Selten ein so gut dokumentiertes Hobbyprojekt gesehen. Aber mal eine Frage. Nach dem Überfliegen der Doku habe ich gelesen, dass noch ein PIN des Atmega frei ist (PC5?). Könnte man diesen Pin nicht als Interruptquelle in den Betriebsarten I2C und SPI benutzen? Damit wäre es doch möglich auch in diesen Betriebsarten nicht nur zu pollen, sondern dem angeschlossenen µC mitzuteilen, dass neue Daten im Puffer liegen und diese abgeholt werden können. Mich würde ja in erster Linie die I2C Variante interessieren, da meine Schaltung, wo ich mir das Funkmodul gut vorstellen könnte schon 3 I2C Bausteine hat. Wann könnte man denn mit I2C rechnen? Gruß Sven
Datum: 09.12.2008 07:19
Hallo Die Idee ist sehr gut! Das wäre mit dem "überschüssigen Pin" machbar, ja. Und damit ein Pollmodus fast hinfällig. Wann es I2C geben wird kann ich leider nicht sagen. Momentan bin ich froh, dass ich die UART soweit abgeschlossen habe. Habe im Moment echt sehr viel um die Ohren. Es ist aber gut möglich, dass sich I2C und SPI noch etwas hinziehen wird. Muss erst wieder Zeit finden, demnächst stehen Prüfungen an, danach Seminare...puh :)
Datum: 13.12.2008 14:08
Ich kann nun sicher sagen, dass sich I2C und SPI noch ziehen wird... Ich schätze vor Mitte Februar werde ich da nicht dazukommen. Habe neben Studium vor allem auch noch ein kleines Miniprojekt welches ich noch durchboxen will ;-) Interessant zu wissen wäre auch viele Leute an einer I2C und SPI Lösung interessiert sind. Bisher scheinen die Meisten auf die UART abzuzielen??
Datum: 13.12.2008 14:43
Hi Florian, erstmal möchte ich mich den ganzen Lobesreden anschließen ... echt gut gemachtes Projekt =) Zu Schnittstellen: Wenn ich das in der Form nutzen würde, würde ich wohl auch U(S)ART bevorzugen, einfach schon wegen der von Haus aus gegebenen asynchronen Verwendbarkeit. SPI wäre für mich nur interessant, wenn das Modul selber irgendwie Pakete überträgt, so dass ich auf uC-Seite keine Pakete mehr von Hand auseinanderfriemeln müsste (bei USART habe ich ja erstmal normalerweise nur einen Byte-Stream). Wobei ich zugeben muss, dass ich mir das Protokoll bei dir noch nicht genau angeschaut hab ;) Was aus meiner Sicht noch interessant wäre, wäre die Frage, ob man quasi das ganze FW-Seitig relativ einfach in ein eigenes Projekt einbinden könnte, so dass man für den Funkteil kein dediziertes Modul (/Controller) braucht? Grüße, Chris
Datum: 13.12.2008 16:50
Christian Illy wrote: > Was aus meiner Sicht noch interessant wäre, wäre die Frage, ob man quasi > das ganze FW-Seitig relativ einfach in ein eigenes Projekt einbinden > könnte, so dass man für den Funkteil kein dediziertes Modul > (/Controller) braucht? Was meinst du mit "FW-Seitig". Komme gerade mit dem Kürzel nicht klar ;-) Wenn ich dich richtig verstanden habe willst du wissen, wie leicht sich der komplette Aufbau+Code, der für ein selbstständiges Board ausgelegt ist, in ein anderes Projekt komplett integrieren lässt? Im Prinzip sehr einfach. Was man beachten muss sind natürlich die Schnittstellen/Pinbelegung und die sonstigen Hardwareressourcen des Ziel-AVRs (Timers etc.). Von der reinen Softwareimplementierung sollte es kaum Probleme geben. Der Programmdurchlauf in der main besteht im Wesentlichen aus einer Init-Funktion und einer Endlos-Schleife die 2 Funktionen beinhaltet. Hier kann man sehr leicht neuen Code hinzufügen, der dann komplett abgekapselt vom Rest arbeitet. Man sollte lediglich darauf achten keine Zeit mit irgendwelchen delays zu vergeuden....
Datum: 13.12.2008 17:05
Hi Florian, mit FW-Seitig meinte ich, dass man die Firmware um eigene Funktionen erweitert bzw umgekehrt in eigene Firmware deine Routinen einbaut, damit das eigene Projekt um Funk erweitert wird (eben ohne die dedizierte Funk-Modul-HW von dir ;) ). Gerade bei sehr kleinen Aufgaben könnte ich mir vorstellen, dass man damit etwas an Kosten spart (eg Funk-Temperatur-Sensor). Die Antwort bestätigt das ja schon =) Grüße + schönes Wochenende noch, Chris
Datum: 13.12.2008 18:16
Also ich würde mich schon mal für I2C anmelden ;-) Ich bastle seit einigen Monaten an einer Alarmanlage für Einbruch, Brand, Bewegung und noch andere nette Sachen. Da ich allerdings bei den PICs in Assembler zu Hause bin und die UART schon verwendet wird (für RS485) würde ich das Funkmodul über I2C einbinden wollen. Das ganze eilt aber nicht, da es für mich mehr ein Zeitvertreib ist als ein Projekt unter Termindruck. Februar wäre also in Ordnung ;-) Gruß Sven
Datum: 14.12.2008 20:34
Ich hätte auch Interesse an einer I2C-Lösung. Die oben schon genannte Sache mit dem Interrupt-Pin wäre wirklich fein. Dann könnte man die Master-Slave-Topologie des Bussystems zumindest etwas "austricksen". Auch bei mir eilt es nicht, würde sowieso erst in einigen Monaten afür Zeit finden. Gruß Paul
Datum: 19.12.2008 09:27
Danke für euer Feedback. Das Interesse an I2C und SPI scheint erwartungsgemäß nicht so hoch zu sein wie für die UART. Trotzdem gibt es ja doch einige, für die die Lösung interessant wäre, und das ist ja die Vorraussetzung für die Implementation. Werde auch sehr wahrscheinlich die beiden Schnittstellen noch implementieren. Momentan ist es einfach nur ein Zeitproblem...
Datum: 19.12.2008 22:39
Die RS232 ist sicher erst mal wichtiger, da man diese problemlos an den PC bekommt und so erst mal mit dem Modul herumspielen kann. Möchte man das Teil aber durch einen anderen µC steuern würde ich I2C oder SPI für die Kommunikation benutzen. Die RS232 wird ja meist zum Flashen benutzt (bootloader) oder wie in meinem Fall um daraus einen Bus zu machen. Aber noch was anderes: Hier stand die Tage irgendwo, dass es die RFM12 nur noch bei Pollin geben soll. Sterben die jetzt aus? Gibt es einen Nachfolger? Weist du da was genaueres? Wäre ja dumm wenn es die in Zukunft nicht mehr geben sollte. Sven
Datum: 21.12.2008 11:40
Hallo Das habe ich auch gelesen und mich beunruhigt das auch etwas. Die RFM12s sind nunmal ziemlich preiswert und es wäre wirklich sehr schade wenn diese nun vom Markt verschwinden würden. Aber sind ja (noch) alles Gerüchte, die meines Wissens teilweise schon widerlegt worden sind.
Datum: 21.12.2008 11:50
Die Elektor hat die Dinger in einer der letzten Ausgaben drin, wär mal interessant wo die sie her haben. Ich weiß aber auch, das einige hier aus dem Forum schon direkt in China bestellt haben.
Datum: 21.12.2008 12:40
Den Artikel in der ELEKTOR habe ich auch gelesen. Ich denke nun nicht, dass die ELEKTOR einen Artikel über ein Produkt bringt, welches zu dem Zeitpunkt schon "vom Aussterben bedroht" ist.
Datum: 21.12.2008 13:01
ein anderes projekt... http://www.ulrichradig.de/home/index.php/avr/usb-funk http://shop.ulrichradig.de/product_info.php?cPath=... und wenn schon seriell... warum nicht gleich... http://shop.ulrichradig.de/product_info.php?cPath=...
Datum: 28.12.2008 12:39
gibt es denn schon mehr bilder von den Modulen um sich einen besseren eindruck darüber machen zu können? Leider sind auf der Webseite immer noch keine verfügbar. gruß Ralf
Datum: 28.12.2008 15:17
Das ist mein Modul! Mit RS232 oder USB bestückbar!
Datum: 30.12.2008 08:17
@ Ralf Ja, einige Bilder werde ich bald online stellen sobald ich dazu komme :) Die Platine von Alex W. sieht gut aus ;)
Datum: 31.12.2008 13:08
Ich kann mich komischerweise nicht mehr im µ-Forum anmelden? Nunja... Also bezüglich der RFM Module habe ich mit deinem Vertriebler von HOPERF aus China geredet. Quasi direkt mit der Quelle. Er hat mir zugesichert, dass die RFM Module definitiv NICHT vom Markt genommen werden. Auch Pollin ist und bleibt ein Distributor dieser Module. Ich werde das auch noch einmal in einem extra Thread aufmachen, da ich schon einige Mails wegen der Thematik bekommen habe. An diewser Stelle auch einen herzlichen Dank an den User 'embedded', der mir die E-Mail-Adresse gegeben hat. Leider kann ich momentan keine PMs bearbeiten wegen meinem Login-Problem.
Datum: 09.01.2009 07:45
Hallo Florian, finde dein Projekt super. Nach genau soetwas habe ich gesucht. Ich hätte da eine Frage wegen dem MAX3221. Kann man da auch andere MAX-ICs verwenden oder muss es genau dieser Typ sein? Habe noch massenhaft andere Typen (MAX232) rumliegen und würde diese gerne verwenden wenn das möglich wäre... der Morgenmuffel
Datum: 10.01.2009 08:52
Es ist auch möglich andere Typen zu verwenden. Den MAX3221 habe ich desshalb verwendet, weil er die Aktivität des RX-Pins der Gegenstelle (zum Beispie ein PC) überwacht. Das eröffnet die Möglichkeit, den MAX bei nicht angeschlossener Gegenstelle zu deaktivieren. Außerdem lässt ishc der IC auch manuell über Steuerleitungen deaktivieren. Solche Möglichkeiten bietet ein "normaler" MAX232 einfach nicht. Will man die RS232 sowieso nicht verwenden kann man den MAX natürlich einfach weglassen. Will man nur die RS232 verwenden, so kann man einfach an RX/TX des AVRs den MAX232 klemmen. Die Anschlüsse INVALID, FORCEON, FORCEOFF sind dann irrelevant. Es reicht INVALID irgendein festes Potential zu spendieren. Will man RS232 und TTL UART verwendet wirds kniffliger. Entweder man löst alles über Jumper oder man nimmt zumindest einen MAX3222. Der lässt sich wenigstens noch manuell deaktivieren. Dann kann man den INVALID-Eingang am AVR mit Jumpern zu GND/VCC nachbilden und den ENABLE, der für den MAX3221 gedacht ist an den MAX3222 hängen. Sollte genauso funktionieren. Hoffe es ist etwas klarer geworden. Das Datenblatt des MAX3221 hilft auf jeden Fall weiter.
Datum: 10.01.2009 16:50
Moin zusammen, ich habe die Sammelbestellung für das Board verpasst. Ich würde das Board aber gerne nutzen. Mir ist die Boardgröße nicht ganz so wichtig. Daher würde ich auch ein einseitiges Board nutzen. Ich bin aber beim routen und designen von Platinen absolut unerfahren - daher frage ich hier, ob es schon Leute gibt, die die Schaltung auf eine einseitige Platine gebracht haben? Gruß Martin
Datum: 12.01.2009 21:30
Hallo Pr0gm4n bin vor kurzem dazu gestoßen. Wie weit ist Deine Sammelbestellung gediehen? Kann man sich noch beteiligen? Gruß Altprog
Datum: 12.01.2009 22:06
Moin, > bin vor kurzem dazu gestoßen. Wie weit ist Deine Sammelbestellung > gediehen? Kann man sich noch beteiligen? Ich hatte Ihn angeschrieben und war schon zu spät. Das scheint schon gelaufen zu sein - schade!
Datum: 13.01.2009 10:02
Hallo, sieht gut aus , das Modul ich bin im Moment dabei auch so etwas ähnliches zu machen. Gibt es eine Sammelbestellung für Platinen, hätte Interesse. Gruß Altprog
Datum: 14.01.2009 14:51
Gute Nachrichten! :) Ich habe ein Angebot eines Webshops erhalten (Name und Adresse möchte ich zunächst nicht nennen, da hier noch keine Nägel mit Köpfen gemacht werden), die mir anbieten die Funkboard-Hardware in Ihrem Webshop zum Verkauf anzubieten. Das ist natürlich eine sehr tolle Sache und sicherlich für einige hier attraktiv :) Gerade in den letzten Beiträgen kam die Frage dazu ja wieder auf. Bis zur Umsetzung würde es allerdings mindestens noch einen Monat oder länger dauern. In dieser Zeit bin ich doppelt froh um jedes Feedback! So kann schon vor dem eventuellen Verkauf ein gewisses Maß an Qualität durch andere User gewährleistet werden, was sicher im Interesse aller ist :-) Es trudeln immer mal wieder Feedback-E-Mails bei mir ein. Es wäre schön, wenn das so bleibt oder auch mehr werden. Eure Erfahrungen fließen direkt in das Projekt mit ein. So, dann noch wegen den Sammelbestellungen: Die laufen komplett ohne meinen Eingriff. Anfragen dazu also am besten direkt an die User hier schicken :-) Gruß Florian
Datum: 14.01.2009 15:05
Hallo Florian, gut Ding will Weile haben. Ich wäre auf jeden Fall an einem Board über einen Shop interessiert. Eine Sammelbestellung, die hier parallel zu dem Shop laufen würde, käme für mich nicht so in Frage. Da bei mir im Moment noch andere Projekte (schleppend) laufen (Dachbodenausbau, Rollosteuerung, AVR-Kamera), reicht mir die Aussage, dass es in absehbarer Zeit etwas "Offizielles" in einem Shop geben wird. Die Funkmodule (886MHz) habe ich zwar bereits in der Schublade, aber kurzfristig noch keine Zeit die mal (per STK500 o.ä.) anzuschließen, d.h. viel Unterstützung werde ich nicht leisten können (abgesehen von meiner fehlenden Kompetenz:-) Aber ich hoffe bei den anderen sieht es zeitlich besser aus... Grüße Jörg
Datum: 18.01.2009 10:12
eine tolle sache! wäre auch an dem board über den webshop interessiert.
Datum: 22.01.2009 17:06
Hallo Leute, ich habe mir die Software von Flashcraft.de mal runtergeladen. Mein AVRStudio prangert eine nicht gefundene Funktion namens configuration_status(unsigned char send_status) an. Die ist in Global.c extern deklariert aber in der configuration.c ist sie nicht zu finden. hab ich was verpeilt oder ist da ein Fehler ??
Datum: 22.01.2009 17:30
ok hat sich erledigt, ein c file war nicht mit eingebunden
Datum: 22.01.2009 20:14
Hallo, ich habe mehrere DIP RFM 12 Module zuhause liegen, und jetzt wollte ich fragen, ob es vielleicht auch eine DIP-Version geben könnte. das wäre super... sonst muss ich probieren mir selber eine platine zu machen. Ist es eigentlich eine schlechte idee sich die platine selber zu ätzen?, oder sollte sie schon professionell erzeugt werden?
Datum: 23.01.2009 11:01
Hallo Daniel, ich habe mit ein paar Leuten Kontakt gehabt, die vor hatten eigene Leiterkarten zu entwerfen. Teils für reine THT-Bestückung, teils für Mischbestückung, genaue Details kenne ich da selbst nicht. Einige meinten, dass sie Ihr Design evtl. als OpenSource bereitstellen würden. Allerdings kenne ich nichts genaueres, ob momentan damit Leute beschäftigt sind oder ob es bei dem Vorhaben blieb. Zur Not muss man dann doch selbst Hand anlegen. Selbst ätzen ist eigentlich kein Problem. Solange man seine benötigten Strukturbreiten schafft geht das natürlich. Das Design ist da nicht so anspruchsvoll. Viele hier (ich auch) haben mit einem Steckbrettaufbau begonnen. Und die parasitären Effekte darauf kann wohl keine selbstgeäzte Leiterkarte noch toppen ;-)
Datum: 23.01.2009 15:20
Hallo! Ich bastel derzeit an etwas das eine Drahtlose UART Verbindung benötigt. Das "Funkboard" ist genau das was ich suchte, vielen dank! Da aber RS232 uninteressant für mich ist bin ich gerade dabei ein Reines RFM12 Board mit Mega32 und FTDI-USB Wandler zu entwerfen, auf der andern Seite befindet sich dann ein RFM12 mit Mega32 und RS485 Baustein. Hat sich vielleicht schon jemand soetwas gebaut? Mfg, Peter
Datum: 23.01.2009 16:08
Peter F. wrote: > Hallo! > Ich bastel derzeit an etwas das eine Drahtlose UART Verbindung benötigt. > Das "Funkboard" ist genau das was ich suchte, vielen dank! > > Da aber RS232 uninteressant für mich ist bin ich gerade dabei ein Reines > RFM12 Board mit Mega32 und FTDI-USB Wandler zu entwerfen, auf der andern > Seite befindet sich dann ein RFM12 mit Mega32 und RS485 Baustein. > > Hat sich vielleicht schon jemand soetwas gebaut? > > Mfg, > Peter USB mit RFM12 gibt es schon knapp ein Jahr von mir! Falls Interesse an solch einem Modul bzw der Platine besteht, könnt Ihr mich auch anschreiben. Ich bin auch dabei ein Prototyp mit dem RFM12BP zu entwickeln. Amateurfunker können dann ganz ganz einfach ein "PacketRadio" bauen. Ist halt ein anderes Übetragungsverfahren, aber mit 115kb. Die 10mW-Variante arbeitet seit 10 Monaten einwandfrei (Modem im Auto und im Haus, beim herfahren Protokollaustausch und Türöffner an der Eingangstüre ist angezogen...) Wenn sich genügen Leute finden lassen, kann ich auch mal ne Serie bestellen.
Datum: 23.01.2009 18:09
Hallo, da ich auch gerade an solchen Modulen interessiert bin, würde ich gerne näheres erfahren. USb-Anschluß wäre super. DC9JG (altprog)
Datum: 23.01.2009 21:24
Alternativ geht auch ein USBprog + RFM12. Ist halt möglicherweise nicht ganz so billig, dafür auch für andere Zwecke verwendbar.
Datum: 26.01.2009 17:32
Hallo! Alex W. (a20q90): Falls ich mich für deine Lösung entscheide lass ich von mir hören ;) Nen USB-Prog habe ich hier, nur noch keine RFM12, ich habe mir Florians Schaltplan mal genau angeschaut und habe ein paar Dinge gefunden die ich nicht verstehe bzw nicht in der Doku finde: Wofür ist der Jumper von PC4 zu VCC gedacht? Der 10k Pullup am Pin3 (FSK) des RFM12 aktiviert/deaktiviert den fifo des Moduls? Sollte man dem RFM12 nicht noch nen 100nF Kondensator spendieren? Vielen Dank schon einmal! Mfg, Peter
Datum: 01.02.2009 07:04
Ahoi Hoi. Ob es so auch wirklich funktioniert kann ich nicht sagen, das wird sich zeigen wenn ich die Platine hab ätzen lassen. RFM-12 mit FT232 und Mega32 in THT, Quartz und USB-Buchse sind leider nicht mitgerendert, PovRay kennt die wohl nicht. Warum? Ich mag THT, SMT ist zwar schön aber irgendwie nicht mein ding ;-) Leider etwas groß aber irgendwas ist ja immer. Mfg, Peter
Datum: 07.02.2009 19:32
Nach langer Zeit melde ich mich auch einmal wieder zu Wort... Definitiv gibt es noch einige kleine Bugs. Habe mittlerweile eine Liste zusammen, die ich sobald ich Zeit finde ausmerzen möchte. Im Großen und Ganzen nichts gravierendes, aber auch Kosmetik muss sein ;) Der versäumte 100nF C am RFM12 gehört auch dazu. Dachte zunächst, dass ich ihn nur im Schaltplan falsch platziert habe, aber er fehlt wohl komplett. Kommt noch rein. Die Lösung mit dem FT232 finde ich super! Ähnliches habe ich mir auch schon einmal überlegt, aber mangels Zeit wieder verworfen. Vielleicht könnte man sich da ja mal kurzschließen, eine PM hast du jedenfalls einmal Peter ;) Werde vermutlich Anfang März wieder genug Zeit finden um das Projekt auf den neuesten Stand zu bringen.
Datum: 11.02.2009 16:52
So, ich habe mir nun vorgenommen, das bestehende Projekt um ein USB-Interface zu erweitern. In Zusammenarbeit mit Peter F. gibts dann vielleicht in absehbarer Zeit neben der bisherigen Version eine weitere mit USB :)
Datum: 22.02.2009 22:52
Hallo, plant jemand eine Sammelbestellung zu dem wirklich gelungenen Funkboard von Florian Scherb? Hätte großes Interesse :) Gruß Frank
Datum: 27.02.2009 15:08
Frank Spliethoff wrote: > plant jemand eine Sammelbestellung zu dem wirklich gelungenen Funkboard > von Florian Scherb? > > Hätte großes Interesse :) Es muss nicht unbedingt ein fertiges Board sein ;-) Wenn man nicht unbedingt auf die größe achten muss kann man das ganze auch sehr einfach auf Lochraster Zaubern, siehe Anhang. Florians Funkboard auf Lochraster inklusive USB-Interface (FT232 in grundbeschaltung nach Datenblatt). > Gruß > Frank Mfg, Peter
Datum: 27.03.2009 15:39
Hallo Florian! Zur info, du hattest in diesem langem thread ja mal nach feedback gebeten: Hatte deinen code schon mal runtergeladen, dank einiger fehler habe ich mich dann mit einem anderen code (rs-232 von benedikt) gespielt. Jetzt wollte ich mir aber auch mal dein werk ansehen, also nochmal runtergeladen, aber fehlerfrei kompiliert bei mir leider nix. geladen habe ich diesen hier: funkboard_quellcode_090109.rar das ganze mit - avr studio 4.16 build 628 - winavr20090313 geöffnet und kompiliert. Erst wurde bemängelt das eine configuration_status funktion fehlen würde, die ist auhc in der global.h definiert. diese habe ich dann in /misc/status_register.c gefunden und einfach unten in der configuration.c angehängt. nächster fehler: die funktion configuration_clkfrequency(void); wird in configuration.c erst implizit durch einen aufruf definiert, dann kommt die funktion weiter unten auch, steht aber in auch nicht in der global.h, also dort hinzugefügt: extern void configuration_clkfrequency(void); anschließend kompiliert mal alles fehlerfrei, warnings gibts es aber 19 stück. die sind mir jetzt mal egal, erst baue ich den code für die 868mhz version der module um, dann schau ich mir das weiter an! Grüße, Martin.
Datum: 16.04.2009 21:47
Hallo Florian, Auch von mir ein großes Lob: Projekt und Doku machen einen sehr guten Eindruck. Gibt's was neues zum Funkboard? Zum Modul mit und ohne USB? Ich habe mir die Eagle-Daten (Schematic und Layout) runtergeladen. SCH und BRD sind nicht konsistent. Ist das Absicht oder wirst Du die Daten noch aktualisieren? Im BRD sind Leitungen aus einzelnen Elementen zusammengesetzt, die unterschiedliche Namen haben. Liegt das daran, weil ich das BRD mit Eagle 5.5 öffne? Oder ist das so gewollt? Macht es Sinn, diese Platine herstellen zu lassen oder gibt es bald ein Update (evtl. mit USB)? Viele Grüße und Danke für die Mühe Der Manuel
Datum: 17.05.2009 11:37
Super Sache dein Funkboard, Florian Ich habe mich mit dem Funkmodul RFM12 beschäftigt und bin so zu einem Projekt gekommen. Nun interresiert es mich ob es eine Ätzbare Version gibt? Oder ob es jemand zufällig neu geroutet hat? Ätzbar bedeutet für mich: -Durchkontaktierungen durch selbstgelötete Silberdraht ersetzbar -Stiftleisten/Quarz etc. nur von der "unteren" Seite anlötbar -Doppelseiteig/Einseitig wäre dann egal
Antwort schreiben
Die Angabe einer Email-Adresse ist freiwillig. Wenn Sie automatisch per
Email ü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
- JPEG-Dateien (.jpg) nur für Fotos und Scans verwenden
- Schaltpläne, Screenshots usw. als PNG oder GIF anhängen
Formatierung (mehr Informationen...)
- [c]C-Code[/c]
- [avrasm]AVR-Assembler-Code[/avrasm]
- [pre]vorformatierter Text (z.B. Code in anderen Sprachen)[/pre]
- [math]Formel in LaTeX-Syntax[/math]
- [[Titel]] - Link zu Artikel