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)

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.

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

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

@  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

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

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.

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.

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.

Super, klingt ja gut :-)

Board Layout ist nun auch online.

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

Gruß

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

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?

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

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

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

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.

Das ist mein Modul!

Mit RS232 oder USB bestückbar!

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

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.

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.

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

Hallo an alle,

leider fehlt uns ja noch das aktuelle Terminalprogramm 1.0.2.

Ich hatte heute mit Florian einen kurzen Kontakt (ist momentan voll im
Streß), er hat mir zugesagt in 2 Wochen die Daten zu senden. Sobald die
zur Verfügung stehen gibt´s ´nen Link.

mfg

Bernd

Bernd Jung schrieb:
> Ich hatte heute mit Florian einen kurzen Kontakt (ist momentan voll im
> Streß), er hat mir zugesagt in 2 Wochen die Daten zu senden. Sobald die
> zur Verfügung stehen gibt´s ´nen Link.

Hat er gesagt warum die Website down ist?

Mfg,
Peter

immer noch keine neuigkeiten???

Das ist echt schade. Erst wird man auf das Projekt durch den Artikel in
Embedded Projects Journal heiß gemacht und dann gibts nirgends
informationen dazu :-(

schade naja ... weiter warten

Servus!

Da ich es schon sehr oft erlebte, dass Informationen, die man im
Internet erhält, jederzeit weg sein können, hab ich von diesem Projekt
natürlich alles abgespeichert.

So wie zum Beispiel die vielen "Mini-Projekte" von Elektor, die es als
.pdf gratis zum Downloaden gab. Da hatte ich vor 4 Jahren verabsäumt sie
zu speichern. :( (siehe Beitrag "Elektor-Miniprojekte" )

Aber hier Bitteschön, für Euch im Anhang, sind alle zu dem Projekt
zugehörigen Dateien.

Gruß

Daniel M.

danke die...
genau so bin ich sonst auch ..
aber die seite war ja schon off bevor der artikel raus war :-(

danke dir...
genau so bin ich sonst auch ..
aber die seite war ja schon off bevor der artikel raus war :-(

grüße Martin

Peter F. schrieb:
> Hat er gesagt warum die Website down ist?
>
> Mfg,
> Peter

Hi,

Providerprobleme.

Q amad

Danke für den Anhang. Wie ich vermutet hatte, ist der Link auf seiner
Seite zum Download des Terminalprogrammes noch auf die Version 1.0.1
gesetzt; dementsprechend wurde auch nur diese Version gesichert. Was uns
fehlt ist die 1.0.2 vom 23.11.2008 in dem die Bugfixes am DTR-Pin
beseitigt sind.

mfg

Bernd

Servus!

Das ist seltsam mit der Version 1.0.2 vom 23.11.2008, denn ich habe die
Sicherung am 04.07.2009 gemacht. Eventuell hatte er zu dieser Zeit eine
alte Kopie seiner Seite hochgeladen gehabt.

Da ja ohnehin der Sourcecode vorhanden ist, spricht aber nichts dagegen,
den Fehler selbst auszubessern. ;)
(Das Visual Studio Express fürs Kompilieren bekommt man ja sogar
gratis.)

Gruß

Daniel M.

Hallo!
Ich hab Florian mal angeschrieben und gefragt wie es um das Projekt
steht, hier die kurzfassung aus zwei Emails, zusammenkopiert:

> Das Projekt ist definitiv nicht tot. Ich werde mein Bestes geben!
> (...)
> Ich werde die Arbeit an dem Projekt sehr wahrscheinlich (im Rahmen
> meines Studiums) wieder aufnehmen.
> (...)
> Dadurch wird auch der Code erweitert und verbessert werden.
> (...)
> Ich habe mich auch wieder daran gemacht die Webseite online zu bekommen.
> Ich kann dir leider nicht sagen wie lange das dauern wird mit der
> Webseite.
(...)
> Ich denke, aber dass ich relativ schnell jemanden finden werde. Aber mit
> ca. 2 Wochen sollte man mindestens rechnen.

Das hört sich doch ganz gut an, bis dahin also noch etwas warten ;-)

Grüße,
Peter

ich hab irgendwann mal an Florian geschrieben und auch von Ihm die
Antwort bekommen, das er die Seite wieder online stellen will.

Leider ist das schon ne ganze Weile her. Ich glaube mitlerweile nicht
mehr daran, das die Seite noch mal wieder online geht.

Vielleicht sollte man einfach das vorhandene Wissen zusammentragen und
hier einen Artikel im Wiki erstellen?

Leider sieht es so aus.... echt schade.

Für alle die trotzdem etwas von diesem Projekt haben wollen...
Im Anhang findet ihr die benötigten Informationen.

grüße martin

Hast du denn generell die Funktionsfähigkeit deines selbst geätzen
Boards getestet?

Also ne eigene Hex aufspielen, die bei eingehenden UART befehlen mal die
unterschiedlichen LEDs zum Leuchten bringt.

Um auszuschließen, dass die UART Kommunikation auf deinem eigenen Board
klappt und das der Atmega sie auch versteht.

Baudrate 9600 8N1 alles soweit korrekt und kontrolliert am PC, gehe ich
mal von aus.

Hast du den wie beim Schnellstart beschrieben über MDSEL = 1 und 0x00
0x00 senden versucht das Statusregister auszulesen? Passiert dabei
etwas?

Soweit mal ein paar Denkanstöße,

Andun

Morgen,

gibts mittlerweile mal wieder was Neues zu diesem Projekt?
Mal nen neuen LP oder SW stand?

Die Seite ist ja nun schon fast ein Jahr down.
Die Dateien (brds) sind ja fehlerbehaftet.
Hat sich irgendwer mal intensiver damit beschäftigt und mal eine
lauffähige Version gebastelt?


Grüße

Mark P. schrieb:
> gibts mittlerweile mal wieder was Neues zu diesem Projekt?
> Mal nen neuen LP oder SW stand?
>
> Die Seite ist ja nun schon fast ein Jahr down.
> Die Dateien (brds) sind ja fehlerbehaftet.
> Hat sich irgendwer mal intensiver damit beschäftigt und mal eine
> lauffähige Version gebastelt?

Ich hab mehrere lauffähige Versionen hier im betrieb.
Die letzte Firmware die ich hab hatte 2 fehler, einen hab ich gefunden,
den andern, mit dem lebe ich ;-)

Für mich ist es zu spät ein anderes Funkmodul zu verwenden, deshalb werd
ich das mittelfristig auf meine eigene Seite nehmen und Forken.

Terfagter schrieb:
> Also das Statusregister habe ich noch nicht ausgelesen, werde ich aber
> mal versuchen.
> 9600 8N1 stimmt soweit.
>
> Werde dann mal berichten ob ich das Statusregister ausgelesen bekomme.

Dazu sollt man sagen, die letzte Firmware die ich von der Seite hatte
kennt den Befehl zum Status Register auslesen nicht!

Grüße,
Peter

kann jemand mal eine aktuelle und fehlerfreie version der software
posten?

Hat das Board schonmal bei einem von euch funktioniert? Ich würde mir
das Board gerne selber aufbauen und ätzen, aber vorher würde ich schon
ganz gerne wissen, ob sich der Aufwand lohnt! Welche Version
funktionierte?

Hallo,

es ist bei mir schon eine Weile her, dass ich es eingebaut habe, aber
ich benutze die Kombination als Funkbrücke.

Ich habe meine Erkenntnisse hier zusammengefasst:

http://www.subms.de/2009/09/17/flashcraft-funkboard/

Johannes Kreuzer schrieb:
> Hallo,
>
> es ist bei mir schon eine Weile her, dass ich es eingebaut habe, aber
> ich benutze die Kombination als Funkbrücke.
>
> Ich habe meine Erkenntnisse hier zusammengefasst:
>
> http://www.subms.de/2009/09/17/flashcraft-funkboard/

Funktioniert eigentlich bei euch noch die Seite vom TO?

TO???

Also die flashcraft.de Seite geht ja schon seid längerem nicht. Welche
Seite meinst du?

Johannes Kreuzer schrieb:
> TO???
>
> Also die flashcraft.de Seite geht ja schon seid längerem nicht. Welche
> Seite meinst du?

TO= Thread Openener

Ja genau die meinte ich. Hab jetzt zwar nicht explizit gesucht, aber
gibts da noch irgendwo Unterlagen und Code drüber?

Gruß, Sven

Martin J. schrieb:
> Leider sieht es so aus.... echt schade.
>
> Für alle die trotzdem etwas von diesem Projekt haben wollen...
> Im Anhang findet ihr die benötigten Informationen.
>
> grüße martin

In diesem Beitrag etwas weiter oben in diesem Thread. (Namen von Martin
J ist ein Link dahin)

Dankeschön!
Auch wenns jetzt so aussieht als ob ich zu faul zum suchen oder lesen
war;)

Hallo zusammen,

ich habe das Funkboard auf einem Steckbrett aufgebaut. Als Prozessor
benutze ich den ATMega32 und ich verwende keinen Max sondern habe eine
direkte Verbindung zu einem anderen ATMega32.
Wenn ich die Spannung jetzt zuschaltet, leuchten alle drei LEDs kurz auf
und danach leuchtet nur noch die "Power-Good"-LED. Der andere ATMega 32
sindet jetzt alle 3 Sekunden den String aus dem QuickStart-Dokument von
Florian.
0x55 0xFo 0x48 0x61 0x6C 0x6C 0x6F

Der String kommt auch beim ATMega des Funkboards an, aber die
Transmitt-LED zeigt nichts an. Auch auf den Pins NSEL, SCK, SDI, SDO des
RFM12s wird etwas übertragen, alle 3 Sekunden, wenn ich sende (Oszi).

Ich habe versucht das Statusregister auszulesen, aber da kriege ich
überhaupt keine Antwort. Ich weiß, dass das Auslesen nicht funktioniert,
aber ich habe gelesen, das schon irgendeine Antwort zurück kommt.

Das gleiche Problem hatte ich auch schon, als ich mir alles auf einer
selbst geätzten Platine vor einiger Zeit aufgebaut hatte.
Der mdsel-Pin liegt über einen 2,2MOhm-Widerstand auf +5V.

Die Fuses sind so gesetzt: hfuses: 0xD9 lfuses: 0xDF und es ist auch
kein JTag aktiviert.
Ich habe erst die eeprom-file gebrannt und dann die hex-Datei. Beides
habe ich nicht verändert.
Die Baudrate meines sendenden ATMegas ist 9600 und die des
Funkboard-ATMegas sollte ja auch standartmäßig bei 9600 liegen.
Warum zeigen die Übertragungs-LEDs nichts an? Was kann ich noch
überprüfen? Ich bin langsam etwas ratlos!
Vielen Dank für eure Hilfe.

Moin

Also so wie es sich jetzt für mich anhört, kannst du also gar nicht mit
deinem Atmega32 kommunizieren, oder?

Dann würde ich vorschlagen, dass du dir ein kleines Programm schreibst
und flasht, dass nur die Kommunikation testet. (Also z.B. jede Sekunde
einen Satz ausgeben oder bei eingehenden Zeichen eine LED togglen)

Damit könntest du erstmal ausschließen, dass es an deiner Schaltung
liegt. Die Software des Funkboards ist für solche grundlegende
Fehlersuche eher weniger geeignet.

Ich hab mal zwei Programme angehängt, die ich für so etwas benutzt habe.
(Ich habe jedoch damit das Funkboard angesprochen, als es lief, aber das
Prinzip ist das gleiche) Du musst natürlich im makefile die CLK und in
main.c evtl die Baudrate anpassen.
Einfache Fehler wie eine falsche CLK, aufgrund falscher Fuses oder
Crystals kann man so auch mit einer Uhr aufdecken und einer toggelnden
LED.

Viel Erfolg

Also, ich habe jetzt einen max232 direkt an RX/TX des ATMega32 des
Funkboards angeschlossen und sende von einem Terminalprogramm aus,
Auf den ATMega habe ich dein Programm (Johannes Kreuzer) gebrannt und
natürlich vorher im makefile den atmega32 und 8Mhz eingestellt.

Es passiert aber nichts. Das verwundert mich jetzt noch mehr.
Mit dem Oszi sehe ich das die Daten am ATMega ankommen, es üpassiert
aber trotzdem nix.
Ich habe dein Programm auch mal soweit abgeändert, das der ATmega mir
alles direkt als Echo zurück sendet. Er sendet aber nur ein Leerzeichen
zurück?!?
Die Baudrate von 9600 habe ich gelassen.

Ich nehme es zurück: Er sendet überhaupt nichts zurück!

So nach einigem Hin und Her funktioniert jetzt die Kommunikation
zwischen Terminalprogramm und Funkboard problemlos. Die LED lässt sich
auch am Board toggeln, wenn ich ein bestimmtes Zeichen über das
Terminalprogramm sende.

Eigentliche Software wieder aufgespielt:
Jetzt sende ich über das Terminalprogramm den String aus dem
QuickStart-Dokument, es wird aber trotzdem keine Aktivität angezeigt.
Mit dem Terminalprogramm vom Foob kann ich auch zum Board connecten,
wenn ich den MDSEL-Pin auf High ziehe.

Was könnte ich denn sonst noch probieren?

Die Transmitt-Aktivität der LEDs wird aber auch angezeigt, wenn kein
zweites Board in der Nähe ist oder?
Leuchtet die LED auch, wenn z.B. das RFM12 kaputt wäre?

Hallo,

also kannst du jetzt auch die Konfigurationsregister auslesen und
schreiben etc?

Das wäre ja schonmal ein gutes Zeichen!

Ich muss gestehen, dass ich im Moment nicht in der Materie drin bin,
dass ich dir die Funktionsweise genau wieder geben kann. Dafür müsstest
du sonst mal in den Quellcode des Funkboards schauen.

Vielleicht kann dir jemand anderes dabei aber auch helfen.

Also ich bin nicht weiter gekommen, bei meinem Problem.
Wenn ich in Foobs Terminalsoftware "Update Terminal" drücke kommen diese
Fehler rechts im Fenster:
Connection to Funkboard okay!
Device ID: 255
Channel number: 255
Startbyte: 255
DQD: 7
RSSI: -61dBm
Bandwidth: ERROR
RF12 baud: ERROR
LED state: False

Erscheint das bei euch auch?
Hat noch jemand eine Idee?

Und wenn ich versuche das Statusregister auszulesen, also bei MDSEL=high
0x00 0x00 sende, dann kommt nur 0xB0 0x1A zurück! Das kommt aber auch
zurück wenn ich irgendwas anderes sende und der MDSEL ist auf high...

Nabend,
Hat noch jemand eine Platine oder ein ein fertiges funkboard das er mir
verkaufen kann? Dann kann ich vllt besser verstehen wo mein Fehler ist.
Oder wüsste sonst jemand wie ich noch vorgehen könnte um den Fehler
einzugrenzen?

Langsam erreicht das Frustrationslevel seinen Höhepunkt.
Ich habe mir eine fertige Platine von jemandem besorgt, der mal die
Sammelbestellung durchgeführt hat. Hab dann ein neues! RFM12 Modul und
einen neuen ATMega32 genommen und das Board aufgebaut.
Ich habe aber keinen Max und auch den Spannungsregler nicht mit
aufgebaut.

Dann habe ich die Fuses auf 0xD9 (hfuses) und 0xDF (lfuses) eingestellt.
Dann habe ich die FUNKMODUL.eep vom 19.01.2009 gebrannt und dann die
FUNKMODUL.hex auch vom 19.01.2009.
Nachdem ich dann die Versorgungsspannung aus- und wieder eingeschaltet
habe, leuchten die LEDs ca. 1 sec auf und dann leuchtet nur noch die
PowerGood-LED.
Also genauso wie bei meinem auf Steckbrett aufgebautem Board auch.

Ich setzte jetzt einen MAX232 dazwischen. Dann starte ich das
Terminalprogramm und klicke unter "Commands(Prompts)" auf "Check
connection to Funkboard". Als Antwort erhalte ich Connection to
Funkboard okay!
Ich kann auch auf "Software-Reset" beispielsweise klicken, dann startet
das Board auch neu. Die meisten Sachen funktionieren nicht, aber das ist
ja bekannt! Z.B. kann ich unter "Command(Settings)" auf Update Terminal!
klicken und als Antwort erhalte ich:
Device ID: 16
Channel number: 255
Startbyte: 255
DQD: 7
RSSI: -61dBm
Bandwidth: ERROR
RF12 baud: ERROR
LED state: False
Also kann man ja sagen, dass eine Kommunikation generell zwischen PC und
Funkboard stattfindet und funktioniert.

Wenn ich das Statusregister auslesen will (Ich sende 0x00 0x00) und den
MDSEL-Pin auf 5V lege, erhalte ich als Antwort: 0x1A 0xB0
Ob das die richtige Antwort ist, sei mal dahin gestellt, aber es
antwortet.

Sende ich jetzt vom PC aus 0x55 0xF0 0x48 0x61 0x6C 0x6C 0x6F
(Ohne CR, LF, 0 oder sonst was) passiert nichts. Es leuchtet keine der
LEDs kurz auf. (MDSEL ist natürlich auf low!)
Ich habe auch versucht mit einem anderen ATMega8 diese Bytefolge jede
Sekunde einmal zu senden, es leuchtet aber auch hier keine LED auf.
Es wäre schön, wenn mir jemand helfen könnte oder mir zumindest sagen
könnte, ob es so ähnlich bei ihm ist?!?

Hallo,

also ich habe - wie auf meiner Seite beschrieben www.subms.de - das
Funkboard in Betrieb.

Also meine Ausgabe vom "Flashcraft Funkboard Terminal" lautet:
(MDSEL=1)
Connection to Funkboard okay!
Device ID: 16
Channel number: 5
Startbyte: 35
DQD: 3
RSSI: -103dBm
Bandwidth: 134kHz
RF12 baud: 38400 baud
LED state: True

Wenn ich mit 0x00 0x00 das Status Register anfordere erhalte ich 0xB8
0x1A (MDSEl=1)

Wenn ich sonst Daten sende, funktioniert das auch! Die LEDs leuchten
aber zugegeben, nicht jedesmal, auch wenn an der anderen Seite etwas
passiert. (Also die Recieve LED blinkt nicht jedesmal, auch wenn er
Daten empfängt)

Ich muss zugeben, dass ich nicht wirklich weiß, wie ich dir weiterhelfen
kann. Ich lade mal meine hex und eep aus dem Atmega32. Vll hilft dir die
EEP für die Konfiguration.

Also im Anhang mal der komplette Inhalt des Atmega32, wie er auf meinen
Funkboard verbaut ist. (Device signature = 0x1e9502)

Ich hoffe, das hilft!

Ok. Ich probiere es gleich mal aus. Danke schonmal.
Benutzt du das Terminal über die Adapter-Platine mit angeschlossener
CTR-Leitung, oder nur mit RX/TX?

Moin

Also ich benutze nur RX/TX und schalte MDSEL über einen Jumper und dabei
ne LED, die mir den Zustand signalisiert.

Übrigens habe ich jetzt mal ein bisschen auf die LEDs geachtet:

Versuche auf jeden Fall das Senden MIT Ankowledge, da dann auch jedesmal
die (bei mir gelbe) Recieve LED leuchtet. Die (rote) Transmit LED ist
nicht so zuverlässig bei mir.

Viel Erfolg

Ich habe noch was vergessen zu erwähnen. Ich habe kein zweites Funkboard
auf gebaut. Ich habs schon ein paar Beiträge vorher gefragt: Leuchtet
die Transmitt-LED trotzdem, auch wenn nur ein Board vorhanden ist?

@Andun:
Wenn ich mit ACK sende, aber nur ein Sende-Board zur zeit verwende,
leuchtet die Receive-LED dann trotzdem mit auf?

Hab deine funk.eep und danach die funk.hex gebrannt. Es bleibt aber
alles beim alten...
Kriege beim Terminalprogramm jetzt folgende Ausgabe:
Connection to Funkboard okay!
Device ID: 255
Channel number: 255
Startbyte: 255
DQD: 7
RSSI: -61dBm
Bandwidth: ERROR
RF12 baud: ERROR
LED state: False

Da muss es ja an der ext. Beschaltung fast liegen?!?
Aber es ist im Grunde ja nur der ATMega8 der jede Sekunde sendet
angeschlossen oder nur der MAX232 zum PC hin.

Aber es ist sehr merkwürdig, dass zwei Schaltungen die mit verschiedenen
Mitteln aufgebaut sind, den selben Fehler aufweisen?!?
Ich frage mich nur wirklich, was bei dir anders ist...

Wenn ich die Settings über die Terminal-Software auslese, dann sagt er
auch immer:
Received configuration data (bitfield 1) from Funkboard is invalid!

Ist das auch bei dir so?

Neuer Erkenntnisstand:
Wenn ich die Settings im Terminalprogramm (z.B. die Werte, die du ein
paar Beiträge vorher angegeben hast) an das Funkboard sende, dann
akzeptiert das Board die Werte. Wenn ich die Werte jetzt zurücklese,
stimmen sie mit den gesendeten Werten überein. Wenn ich jetzt MDSEL=0
lege, und irgendwas zum Board sende, dann flackert auch die
Transmitt-LED auf!
Wenn ich die Versorgungsspannung unterbreche und dann wieder zuschalte,
ist aber wieder alles beim alten und die Settings stimmen wieder alle
nicht.

Könnte das also an den Werten im EEPROM liegen, das die nicht richtig
gelesen und gespeichert werden?

Irgendetwas muss ich ja beim brennen falsch machen, weil wir das gleiche
Board haben, es aber bei dir läuft und bei mir nicht.

Hallo,

ich vermute auch, dass es am EEProm liegt, da du eigentlich meine
Einstellungen hättest übernehmen müssen, wenn du meine Eeprom Datei
einspielst.

Ohne Gegenstelle sollte natürlich nur die Transmit LED leuchten, da ja
kein ACK gesendet werden kann.

Wieso dein EEPROM sich nichts merkt, kann ich dir aber leider gar nicht
sagen! Die Fusebits hast du ja anscheinend richtig. Meine siehst du im
Archiv ja.

Wenn ich die Settings mit dem Terminal Programm ("Update Terminal")
auslese, zeigt er mir alles korrekt an. Da kommt keine Fehlermeldung ...

Nach Wochen habe ich die Lösung meines Problemes endlich gefunden.
In der Doku stand klar geschrieben, das zuerst die eep und dann die hex
gebrannt werden muss.
D.h. ich habe die eep gebrannt und danach die hex, aber jeweils einzelnd
im Brennprogramm ausgeführt.
Jetzt habe ich aber beide Dateien auf einmal gebrannt, als ein Schritt
und siehe da, ich kann die Settings ohne Fehler auslesen und bearbeiten.
Endlich!
Ich habs leider noch nicht ausprobiert, aber wenn ich die Settings
ändere, werden diese dann auch übernommen, wenn ich die Spannung
unterbreche? Ich hab hier mal irgendwas gelesen, das nichts im EEPROM
gespeichert wird?!?
Muss ich die Einstellungen, wie die ID dann vorher im EEPROM manuell
eintragen und dann brennen?

Also der EEPROM bleibt auch bei Spannungsverlust erhalten. Er muss aktiv
gelöscht werden. Dies geschieht zumeist beim flashen. (Also in den
flash)

Deswegen muss man den EEPROM hinterher befüllen.

Die Firmware des Funkboards sollte die Einstellung anschließend
permanent im EEPROM speichern und auch wieder abrufen können. Also
kannst du die ID problemlos im Betrieb über die Befehle bei MDSEL=1
ändern. (Wie auch alle anderen Einstellungen)

Funktioniert denn nun mit den richtigen Einstellungen das Board?

Ob es wirklich funktioniert, kann ich zur Zeit nicht überprüfen, weil
ich ja nur ein Board aufgebaut habe, aber ich gehe davon aus.
Jetzt flackert auch die Transmitt-LED immer auf, wenn ich etwas sende
und die Settings lassen sich auch ohne Probleme aus-/einlesen.
In den kommenden Tagen baue ich noch ein zweites Board auf, und dann
sehe ich ob die Kommunikation funktioniert.
Hast du eigentlich etwas am Code verändert? Weil dein Code 22kb groß ist
(nur die hex Date)und der orginal Code 25kb groß ist?!

Ich habe bisher nichts an dem Code geändert.

Ich habe ihn lediglich in den Atmega geflasht und dann anschließend
wieder ausgelesen. Vll. wurden dabei Nullen gekürzt oder dergleichen.

Ich habe aber noch ein Problem mit dem ACK - Modus:

Ich sende zum Beispiel 0x10 als Datenzeichen. (Jeweils immer mit ID und
ACK als führende 2 Byte)

Manchmal passiert nun folgendes:

Der Empfänger gibt ID+0x10 aus. Alles ok!
Ich sende ID+ACK+0xAA und der Empfänger gibt nochmals ID+0x10 aus.
Wenn ich jetzt irgendein Zeichen sende (ID+0x??), dann gibt mir der
Empfänger mein ID+0xAA aus.

Ich habe den verdacht, dass das ACK vom Empfänger nicht fehlerfrei zum
Sender gelangt und dieser daher das Zeichen erneut sendet. Der Empfänger
hat jedoch das Zeichen bereits ausgegeben und schreibt das nun doppelt
gesendete Zeichen in den FIFO-Puffer.

Wenn nun ein neues Zeichen gesendet wird, wird dem FIFO zuerst noch das
alte Zeichen entnommen und dann erst das Neue.

Kann diese Theorie irgendjemand bestätigen oder weiß dazu jemand was?

Wen Strauss schrieb:
> Beim anderen Board flackert auch die Empfangs-LED kurz auf, an der
> seriellen Schnittstelle kommt die Nachricht manchmal ganz, häufiger in
> Bruchstücken oder gar nicht an, dafür gelegentlich aber die vorletzte
> (!) Nachricht. Ich vermute eine Macke in den FIFOs. Leider sind meine
> Kenntnisse in C ähnlich ausgereift wie in anderen C-Sprachen
> (Chilenisch, Chinesisch...) und es wäre toll, wenn mal ein Insider
> einige Augen darauf werfen könnte.

Problem ist also bei anderen aufgetreten!

Vllt. könnte jemand der ausreichende C-Kenntnisse hat dieses Problem
beheben?!

Hallo,

ah, ok. Hab den Thread nochmal überflogen... Das sollte man öfters tun!

Ich habe mich in die Materie ein wenig eingearbeitet und der Firmware
folgende Veränderungen durchgeführt:

1. Hinzufügen der status_register.c zum AVR-Studio Projekt.
2. Das Status Register wird im Programm mit 0b1011 = 0xB kodiert!  => An dieser Stelle scheint die Doku nicht zu stimmen.

configuration.c
#306: uart_putc(0xD5); // anstelle von 0xD4, das dort falsch ist.
#363: hinzufügen des identifikationsbytes von 0xD8

received_data.c
#167:  auskommentieren der id, des senden boards.

Vorallem letztere Änderung hilft mit schon enorm, da ich das Funkboard
eher als Brücke einsetze und mich die ID des senden Boards nicht
interessiert. (Ist bei mir eh immer die 0x10). Diese ID wird in meiner
weiteren Schaltung aber teilweise als Nutzdatum interpretiert und
erzeugt dadurch einen Fehler.

Bei einem kurzen und nicht systematischen Test ist mir dabei nun der
FIFO-Bug auch nicht mehr begegnet. (Vll. ist er doch nicht so
gravierend, oder ich hatte nur Glück)

Vll. kann ja jmd an dem Code weiterarbeiten.

Hallo Wen,

mir ist noch nicht ganz klar, worin dein Problem besteht. Meinst du
Terminaladapter das Terminal-Programm für den Rechner oder meinst du
damit einen ganz normalen seriellen-(z.B.)USB-Wandler den du als Adapter
verwendest??

Wie gesagt, benutze ich jetzt die Dateien, die ich auch zuletzt
angehängt habe. (Die hex-Datei befindet sich dort - wie immer - im
Unterordner 'default'.

Diese Version ist meiner Kenntnis nach, die Aktuellste.

Zum Terminal-Programm auf dem Rechner: Das funktioniert bei mir auch
nicht fehlerfrei! (Allein schon aus dem Grund, dass ich MDSEL manuell
setze)

Der Einsatz als Funkbrücke mit 1 Byte Befehlen funktioniert bei mir
jetzt jedoch einwandfrei. (Wobei mein Test nur darin besteht, dass mein
Roboter Befehle bekommt, wie 0x03 = geradeaus, etc. das funktioniert
nun)

Schönes Fest wünsche ich auch!

Kann ich eigentlich auch irgendwie kontrollieren, ob eines meiner RFM12
Module kaputt ist?!
Ich sende von einem meiner Boards z.B. 0x00 0xF0 0x61 0x61
und die Transmitt-LED flackert, aber die Receive LED am anderen Board
leuchtet nicht auf. Wenn ich mit der Terminal-SOftware das Board auslese
steht bei ID 0. Sollte die nicht beim programmierfrischen Modul 0xFF
oder so sein?

@Wen Strauss:

Du hast natürlich recht, dass ich viele Funktionen verschenke. Da ich es
aber schonmal habe ...

@Bene Jan:

Die "voreingestelle ID" laut Doku ist falsch. Das hatte ich auch schon
mal festgestellt. (ich muss gestehen, dass ich nicht mehr genau weiß,
welche ID nun voreingestellt ist.

Aber ich würde an deiner Stelle versuchen die ID mal manuell zu setzen.
(Also MDSEL=1 und dann laut Doku in das passende Register schreiben)
1. Trau ich einer ID 0x00 generell immer nicht so ganz (Abgerglaube und
die Gefahr dass es mal als String-Ende erkannt wird)
2. Wenn du es erfolgreich ändern und über einen Spannungsverlust halten
kannst, dann weißt du das der Atmega richtig funktioniert.

Eine Möglichkeit die RFM Module zu testen ist mir nicht bekannt, muss es
aber eigentlich auch geben. Auf jeden Fall könntest du testen, ob dir
das Modul antwortest, in du es mit einer der Low-Level Funktionen direkt
ansprichst. (Das würde ich aber erst machen, wenn das mit der ID auch
nichts bringt)

Übrigens sind in meinem Archiv von weiter oben zwei EEPROM Dateien:
funk-s.eep => ID=0x11 und LEDs aus
und funk-j.eep => ID=0x10 und LEDs an

Falls du also mal eine fertige Konfiguration testen möchtest.

Hallo Wen,

ich habe nochmal ein wenig über unsere Probleme nachgedacht und habe
noch folgende Überlegung:

Die Funktion radio_receive_data kurz zusammengefasst:

Fülle die globalen Variablen gbl_radio_input_fifobuffer etc. mit den Daten aus dem RFM.

Falls alles ok ist:
-- Sende ein ACK falls nötig

-- Da nur Pollmodus: Sende direkt alles per UART

Sonstige Fehlerbehebung ... 

Zuerst dachte ich daran, dass vll. der UART schneller aufgerufen wird,
als die Daten verarbeitet werden. Dies würde dazu führen, dass Daten
verloren gehen und nicht wie bei uns doppelt gesendet werden.

Aber was passiert denn, wenn das ACK Signal gefordert wird, aber es bei
dessen Übertragung zu einem Bitfehler kommt?

Der Empfänger hat sein ACK vermeintlich gesendet und gibt den Inhalt der
Nachricht aus.

Der Sender empfängt das ACK nicht korrekt und sendet daraufhin seinen
Inhalt noch einmal. Dies müsste der Empfänger doch nun auch wieder
sofort ausgeben, oder? (Die beobachtete Verzögerung lässt sich in diesem
Szenarion also nicht erklären)

Dies soweit als Denkanstoß. (Ist ein Fehler im RFM Fifo denkbar?)

Hast du das Problem inzwischen weiter eingrenzen können? Taucht es auch
ohne ACK auf? Das würde helfen, dass Problem einzugrenzen.
Hast du wiederholbare Bedingungen gefunden, bei denen das doppelte
Senden auftaucht?

Einen Guten Rutsch wünsche ich allen!

Hallo Wen,

ja, diese plötzlichen Jahreswechsel kommen immer wieder unerwartet ...
zum Glück war diesmal eines Anderen Wohnung betroffen ... :D

Deine Ausführungen klingen schlüssig. Ich muss gestehen, dass ich jetzt
keine weitere kluge Idee habe. Ich werde mir die Sende-Routinen bei
Gelegenheit auch nochmal ansehen, bis dahin wünsche ich dir viel Erfolg!

Johannes

Hallo zusammen,

ist es möglich, dass die Webseite aktuell nicht (mehr) erreichbar ist?
Ich erhalte beim Aufruf von
"http://flashcraft.de/index.php/funkboard-uebersicht" nur eine leere
Seite...
Ich würde mich gerne näher über das Projekt erkundigen, da ich mit dem
RFM12 experimentieren möchte. Ist es möglich das Board irgendwo zu
kaufen und könnte mir jemand vlt. die erwähnte 60 Seiten Doku zukommen
lassen bitte?

Vielen Dank!
Markus

Hi,

ein bischen weiter oben in diesem Fred findest du alles:
Beitrag "Re: Nachbaubares Funkmodul auf Basis des RFM12"

Ebenso in der Artikelsammlung...

Gruß - Markus

Oh danke, da hatte ich wohl entweder zu wenig vom Ende zurück oder vom
Anfang nach vorne gelesen ;-)
Kann man denn das fertige Modul noch irgendwo bestellen oder muss man es
selbst zusammen bauen?

Ich hab das noch nie irgendwo fertig gesehen, also alles DIY ;-)

Gruß - Markus

Hallo wen
Ich verfolge deine Beiträge sehr aufmerksam, weil ich dieses funkmodul
auch benutze. Wollte mich nur mal bedanken, dass du dir die mühe machst
und alle Fehler versucht zu finden... stellst du bei Zeiten auch einen
Quelltext rein, bei dem die Fehler schon verbessert wurden?

Hi Wen,

vielen Dank für die Mühe die du dir machst. Hoffe ich komme jetzt bald
mal zum Testen, hab auch noch zwei Module für ein Projekt rumliegen das
ich hoffentlich bald mal umsetzen kann.

Danke dir!

Gruß - Markus

abo

Er hat noch nicht gesehen, dass es die Funktion "E-Mail Benachrichtigung
aktivieren" gibt. Um nun künftig Email-Benachrichtigungen bei neuen
Posts zu bekommen, schreibt er einen Beitrag mit "abo" drin.

--- Markus ---

Weil du uns so dankenswerterweise mit funktionierendem Code versorgt
hast! :D

Netter Nebeneffekt ist aber natürlich, dass du jetzt dadurch das ganze
Wissen über den Programm-Code hast.

Nutzt du jetzt eigentlich das ursprüngliche Platinen-Design oder hast du
es dir bereits angepasst und auf Lochraster aufgebaut?

Grüße,
Johannes

Hallo,

bin grad auf diesen Treat gestoßen und bin sehr neugierieg darauf. Kann
es sein das die Projektseite grad down ist?

LG Fabian

... einfach lesen ...
das haben in diesem thread schon viele vor dir festgestellt!
aber ja die seite ist down, aber schon seit 2 Jahren
inhalt siehe hier:

Beitrag "Re: Nachbaubares Funkmodul auf Basis des RFM12"

oder hier...
Beitrag "Re: Nachbaubares Funkmodul auf Basis des RFM12"

Hallo,

ich habe heute auch ein Funkboard aufgebaut und einen Adapter im FT232RL
als Adapter zum PC. Nach dem Programmieren leuchtet die Rote LED
dauerhaft und ich kann per Terminal nicht darauf zugreifen. Woran kann
das liegen? Ich habe jeweils RX mit TX und TX mit RX verbunden. Des
weiteren liegt MDSEL auf DTR am FT232.

Gruß Michael

Also am PC wir der FT232 erkannt. Ich kann auch über ein
Terminalprogramm auf das Funkboard zugreifen und Daten senden. Nur nicht
mit Florians Software. Ist aber auch nicht so schlimm, dann schick ich
die Befehle halt manuell.

Gruß Michael

Hi Michael,

das Problem mit der Software ist bekannt und das können wir leider nicht
ändern. Ich denke hier arbeiten alle direkt mit dem Terminal.

Grüße,

Johannes

Hallo Zusammen... ich hab mich vor einiger Zeit auh mit diesem modul
beschäftigt. ich glaube das problem war damals nicht das senden sondern
das empfange... hintergrund rauschen wurde dargstellt, sobald ich das
senden begann, wurden nur noch Nullen empfangen :( falls das ein
bekannter anfängerfehler ist, klärt mich bitte auf) naja wie dem auch
sei...

Nun wollt ich mich bald wieder damit beschäftigen und fand diesen
Thread.
leider funktioniert der link zu der so gelobten Doku von dem
Threadstarter nicht.
Würde auch gerne diese und etwaigen Datein und oder Quellcode haben
wollen.

Wäre jemand so freundlich ne entsprechende zip oder so zum download
bereitzustellen?
wäre super!

danke im voraus

Ha... besten dank!
hatte nicht den Ganzen Thread nach links durchsucht.. danke noch mal für
den hinweis^^