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)

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.

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.

>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.

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

RESPEKT !!!!

Tolles Projekt. Ich habe auch so ein paar Module rumliegen und hatte
eine ähnliche Idee, aber keine Zeit ...

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.

wär gut wenn das eindrücke bild einen link zum prject hätte

>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.

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!

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

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

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ß

@ 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

@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

@volker,
welche libs hattest du benutzt ?

avr-libc 1.6.2

avr-gcc ist noch der letzte 3er

@Florian:
Vielleicht hast du eine von den verbuggten AVR-GCCs erwischt.

Ansonsten: Super Projekt! Die Doku ist ja Wahnsinn.

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

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. :)

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.

@  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.

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.

Hallo Florian Scherb

Super Projekt!

Habe versucht das Terminal herunter zu laden... Die Datei wird nicht
gefunden.

Schaust Du Bitte mal danach?

Danke

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 ;-)

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!

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

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,...

Wer auf ATMega 8 in DIL gehen möchte kann folgendes nachbauen Testboard:

http://comwebnet.weimars.net/index.php?option=com_...

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

Hallo

Wenn die Boards nicht verkauft werden werde ich auf jeden Fall das
Layout online stellen, soviel ist sicher :)

Du könntest ja auch die nackten Platinen verkaufen...

abo .. mit der Hoffnung das jemand von dem Teil unbestueckte Platinen
verkauft :D ..

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.

Wäre evtl. auch interessiert!

Wurde das Layout für die Verbindung zwischen Funkmodul und Antenne für
433MHz optimiert?

Beste Grüße,
Tiga

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.

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.

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. ;-)

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

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.

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

@ 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.

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

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.

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

Jetzt auch mit Photo:
http://www.mikrocontroller.net/articles/AVR_RFM12#Platine

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 / ...)

@Manuel,

kommt denn eigentlich auch ein Normalsterblicher an einen svn-Zugang?
Wegen Eagle-Layout etc.

Gruß

Für das SVN hier? (-> Andreas Schwarz fragen)

Oder willst du ein eigenes SVN? (Sourceforge)

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...

Richtig

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.

Habe beide Module hier, sind Pinkompatible.

Super, klingt ja gut :-)

Board Layout ist nun auch online.

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

Hallo,
verstehe ich nicht. Ich dachte das Layout wäre heute erst online
gestellt von Florian?

Gruß

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..

@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 ;)

@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.

Hallo,

könnte bitte noch wer die "Top Seite" als Bild anhängen. Die "Bottom
Seite" ist ja schon hier im Thread.

Danke
Peter

Schau doch einfach hier:
http://www.mikrocontroller.net/articles/AVR_RFM12#Platine

@Florian
heisst das, man hat Dein Board layoutet und in einer Sammelbestellung in
Auftrag gegeben? Warst Du auch daran beteiligt? Ist das dasselbe Board?

Oh, sorry, dachte das Layout sei das von Florian.

Kann bitte wer Florians Board als Bilder einstellen. Ober und
Unterseite. Vielen Dank,
Peter

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...

Hallo,

danke, das wusste ich schon, hab jedoch kein Eagle.

Also kann die schnell wer hochladen? Wäre euch sehr dankbar,

Peter

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.

@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.

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.

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.

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.

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 :)

Hallo Florian

gibt es denn schon neues?
Wie weit ist denn die software nun?

gruß

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.

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

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.

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

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.

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

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 :)

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??

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

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....

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

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

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

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...

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

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.

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.

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.

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=...

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

Das ist mein Modul!

Mit RS232 oder USB bestückbar!

@ Ralf

Ja, einige Bilder werde ich bald online stellen sobald ich dazu komme :)

Die Platine von Alex W. sieht gut aus ;)

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.

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

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.

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

Hallo  Pr0gm4n

bin vor kurzem dazu gestoßen. Wie weit ist Deine Sammelbestellung
gediehen? Kann man sich noch beteiligen?

Gruß

Altprog

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!

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

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

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

eine tolle sache!
wäre auch an dem board über den webshop interessiert.

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 ??

ok hat sich erledigt, ein c file war nicht mit eingebunden

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?

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 ;-)

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

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.

Hallo,

da ich auch gerade an solchen Modulen interessiert bin, würde ich gerne
näheres erfahren. USb-Anschluß wäre super.

DC9JG
(altprog)

Alternativ geht auch ein USBprog + RFM12.

Ist halt möglicherweise nicht ganz so billig, dafür auch für andere
Zwecke verwendbar.

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

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

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.

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 :)

Hallo,

plant jemand eine Sammelbestellung zu dem wirklich gelungenen Funkboard
von Florian Scherb?

Hätte großes Interesse :)

Gruß
Frank

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

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.

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

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