www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Nachbaubares Funkmodul auf Basis des RFM12


Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: JojoS (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Hannes (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Manni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bernd Rüter (Firma: Promaxx.net) (bigwumpus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
RESPEKT !!!!

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

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: !frau (Gast)
Datum:

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

Autor: gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>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.

Autor: Volker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Manni (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen A. (jaja)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: 123 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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

Autor: Volker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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

Autor: Chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@volker,
welche libs hattest du benutzt ?

Autor: Volker (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
avr-libc 1.6.2

avr-gcc ist noch der letzte 3er

Autor: Simon K. (simon) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Florian:
Vielleicht hast du eine von den verbuggten AVR-GCCs erwischt.

Ansonsten: Super Projekt! Die Doku ist ja Wahnsinn.

Autor: Alex W. (a20q90)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Nico Erfurth (masta79)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. :)

Autor: Manuel Stahl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  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.

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Florian Scherb

Super Projekt!

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

Schaust Du Bitte mal danach?

Danke

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Markus D. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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,...

Autor: Avr Nix (avrnix) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wer auf ATMega 8 in DIL gehen möchte kann folgendes nachbauen Testboard:

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

Autor: Jürgen A. (jaja)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo

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

Autor: Werner A. (homebrew)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du könntest ja auch die nackten Platinen verkaufen...

Autor: Michael Kentschke (mad_axe)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abo .. mit der Hoffnung das jemand von dem Teil unbestueckte Platinen 
verkauft :D ..

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tiga (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Wäre evtl. auch interessiert!

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

Beste Grüße,
Tiga

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Tiga (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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. ;-)

Autor: Sven Stefan (stepp64) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg T. (brause)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ 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.

Autor: Jörg T. (brause)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg T. (brause)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 / ...)

Autor: Jörg T. (brause)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@Manuel,

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

Gruß

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Für das SVN hier? (-> Andreas Schwarz fragen)

Oder willst du ein eigenes SVN? (Sourceforge)

Autor: Jörg T. (brause)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Richtig

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: chris (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Habe beide Module hier, sind Pinkompatible.

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Super, klingt ja gut :-)

Board Layout ist nun auch online.

Autor: Pr0gm4n (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg T. (brause)
Datum:

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

Gruß

Autor: Max (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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..

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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 ;)

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Puchi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

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

Danke
Peter

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Jörg T. (brause)
Datum:

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

Autor: Puchi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oh, sorry, dachte das Layout sei das von Florian.

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

Autor: Jörg T. (brause)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: puchi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

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

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

Peter

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Ludwig F. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Florian

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

gruß

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Jörg T. (brause)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Ada83 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Sven Stefan (stepp64) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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??

Autor: Christian Illy (alloc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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....

Autor: Christian Illy (alloc)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven Stefan (stepp64) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Paul W. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Sven Stefan (stepp64) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: jürgen (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Ralf (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex W. (a20q90)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Das ist mein Modul!

Mit RS232 oder USB bestückbar!

Autor: Florian Scherb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Ralf

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

Die Platine von Alex W. sieht gut aus ;)

Autor: Florian Scherb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: morgenmuffel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin B. (methusalem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Rolf Becker (altprog)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo  Pr0gm4n

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

Gruß

Altprog

Autor: Martin B. (methusalem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: altprog (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Florian Scherb (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jörg T. (brause)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus (Gast)
Datum:

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

Autor: Michael (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ??

Autor: Michael (Gast)
Datum:

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

Autor: Daniel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ;-)

Autor: Peter F. (piet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Alex W. (a20q90)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: altprog (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

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

DC9JG
(altprog)

Autor: Manuel Stahl (thymythos) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Alternativ geht auch ein USBprog + RFM12.

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

Autor: Peter F. (piet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter F. (piet)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian S. (buddl)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 :)

Autor: Frank Spliethoff (pappa)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

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

Hätte großes Interesse :)

Gruß
Frank

Autor: Peter F. (piet)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin S. (smartinick)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stefan S. (elektronik-freaks)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Gast (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Florian Scherb,

Deine Projektseite ist down:
http://www.flashcraft.de
...laut denic aber noch in Deinem Besitz.

Kannst Du hier mal für die Nachwelt den letzten Stand ins Forum 
uploaden?
(Doku, Source Code, Layout)

Danke

Autor: Bernd Jung (bernd_j)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter F. (piet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin J. (bluematrix) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Daniel A. Maierhofer (amad) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Martin J. (bluematrix) Benutzerseite
Datum:

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

Autor: Martin J. (bluematrix) Benutzerseite
Datum:

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

grüße Martin

Autor: Bernd Jung (bernd_j)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Daniel A. Maierhofer (amad) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: gonZoX (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Florian and all.

Gibt es Neuigkeiten über dein Projekt, würde mich 'brennend' 
interessieren :)

Habe ich es überlesen oder ist die Idee einen Bausatz bzw. ein fertig 
'montiertes' Element in einem Webshop anzubietenim Sande verlaufen ?

Als Anfänger gestattet mir bitte noch die folgenden 'dummen' Fragen :

Könnte ich dein Funkboard auf der Empfängerseite so an einen weiteren MC 
anbinden wie bisher bei mir den Max232 und die empfangenen Daten per 
UART wie gehabt über Kabel RS232 handhaben ???

MfG und danke im Voraus,
Oliver.

Autor: Peter F. (piet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: bluematrix (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
danke

Autor: Rudi (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
Leider ist die Seite noch immer off...
War sie zwischendurch schon mal wieder online? Oder ist das Projekt 
jetzt wirklich gestorben?
Wäre schade, ist ein super Projekt...

Grüße
Rudi

Autor: Martin B. (methusalem)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Manuel Stahl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Oder einfach die vorhandenen Seiten ergänzen:

RFM12

AVR RFM12

RFM12 Protokoll Stack

Pollin Funk-AVR-Evaluationsboard

Autor: Martin J. (bluematrix) Benutzerseite
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Würde auch die Möglichkeit bestehen, anstatt eines ATMega32 einen Atmega 
48 zu benutzen? Ich benötige nur die UART Schnittstelle. Ein ATMega16 
sollte doch auf jeden Fall gehen, oder?!?

Autor: Terfagter (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,
hat sich nochmal jemand mit diesem Projekt beschäftigt und kann mir 
helfen?
Ich bekomme das Board nicht zum laufen: Brick wall

Ich übergebe dem Funkboard von einem Board mit einem ATMega128 die Werte 
55 f0 48 61 6c 6c 6f in hex, so wie es im Quickstart Manual von Florian 
steht. Die Werte werden über die USART0 gesendet. Ich habe testweise 
einen max232 dazwischen gehangen und die Werte mit einem 
Terminalprogramm abgefragt. Es kommen genau die gewünschten Werte an! 
Also liegt es nicht an meinem sendenden Board!
Dann zum Funkboard. Zuerst habe ich die lee Datei gebrannt und dann die 
hex File. Lege ich Spannung an, leuchten die 3 LEDs kurz auf und dann 
leuchtet die PowerGood LED dauerhaft. Soweit alles wie im Handbuch. 
Verbinde ich jetzt aber das Funkboard mit meinem ATMega128 Board 
leuchtet keine der RX/TX LEDs beim senden auf. Ich lege den MDSEL_pin 
vorher auf 0. Eigentlich sollte eine der LEDs ja beim senden flackern.
Ich verwende ein selbst geätztes eigenes Funkboard mit einem ATMega32 
DIL. Die Fuse Bits des ATMega32 have ich so: Highfuse: 0xD9; Lowfuse: 
0xDF
Danke für eure Hilfe!

Autor: Johannes Kreuzer (andun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Terfagter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Mark P. (kellerkind)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Peter F. (piet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Peter F. (piet)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Martin J. (bluematrix) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
kann jemand mal eine aktuelle und fehlerfreie version der software 
posten?

Autor: hans peter (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

mich würde auch ein lauffähiger Softwarestand interessieren.
Hat jemand das Modul erfolgreich als Funkbrücke eingesetzt?

Mfg HP

Autor: Bene Jan (terfagter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Johannes Kreuzer (andun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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/

Autor: Sven W. (Firma: basement industries) (dj8nw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Johannes Kreuzer (andun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
TO???

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

Autor: Sven W. (Firma: basement industries) (dj8nw)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes Kreuzer (andun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Sven W. (Firma: basement industries) (dj8nw)
Datum:

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

Autor: Bene Jan (terfagter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johannes Kreuzer (andun)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bene Jan (terfagter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Bene Jan (terfagter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich nehme es zurück: Er sendet überhaupt nichts zurück!

Autor: Bene Jan (terfagter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Johannes Kreuzer (andun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wen Strauss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo, ihr da

Ich bastele auch am Funkboard rum und habe mir Platinen gewrappt.
Leider habe ich nirgendwo etwas über bekannte Fehler finden können, 
deshalb hier für alle meine Funde im Klartext:

1. Statusregister geht nicht
Im downgeloadeten Sourcecode ist zwar eine Datei 'status_register.c' 
vorhanden, sie ist aber nicht ins Projekt eingebunden. Dazu (im 
AVR-Studio) im linken Fenster rechten Mausklick auf 'Source Files' und 
'Add existing Sourcefile' auswählen und Datei zufügen. Neu kompilieren, 
ein Fehler weniger.

2. Das Terminalboard
Hier ist die Leitung RTS unmittelbar verbunden mit dem Resetpin des 
ATMega.
Bei einer Standard-RS232 Schnittstelle hat diese Leitung jedoch keinen 
TTL-Pegel. Hier muß unbedingt wie bei der DTR-MDSEL-Leitung ein 
Pegelwandler hin, wenn man neben den drei Leuchtdioden nicht auch noch 
einen Leucht-AVR haben möchte. Leider funktioniert das Terminalprogramm 
trotzdem nicht (Funkboard not connected).

In der Quelldatei 'Initialize.c' habe ich die beiden Zeilen 
configuration_saveineeprom und configuration_loadfromeeprom 
auskommentiert, da beim ersten programmieren die eigene ID noch auf FF 
steht. Stattdessen gebe ich den beiden boards erst mal feste Adressen 
(gbl_config_idown = 1 bzw. 2). Wenn ich also von Board 1 zu Board 2 
senden will, lauten die ersten beiden Bytes also 02 00, gefolgt von 
einigen wenigen ASCII-Zeichen. Hat der MDSEL-Pin 5V-Pegel, flackert auch 
die Sende-LED kurz auf, aber nicht immer, warum nicht, weiß ich auch 
nicht.
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.
Ok, das wars fürs erste,

Gruß, Wen

Autor: Wen Strauss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Sorry, muß mich korrigieren: Im normalen Sende/Empfangsbetrieb muß der 
MDSEL-Pin auf 0V liegen.

Wen

Autor: Bene Jan (terfagter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Bene Jan (terfagter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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...

Autor: Bene Jan (terfagter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Bene Jan (terfagter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?!?

Autor: Johannes Kreuzer (andun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johannes Kreuzer (andun)
Datum:
Angehängte Dateien:

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

Ich hoffe, das hilft!

Autor: Bene Jan (terfagter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Johannes Kreuzer (andun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Bene Jan (terfagter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Bene Jan (terfagter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Bene Jan (terfagter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Johannes Kreuzer (andun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ...

Autor: Bene Jan (terfagter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Johannes Kreuzer (andun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Bene Jan (terfagter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?!

Autor: Johannes Kreuzer (andun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Bene Jan (terfagter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?!

Autor: Johannes Kreuzer (andun)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Wen Strauss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Also auch bei mir türmt sich der Frust so hoch wie der Schnee vor der 
Tür.
Folgendes ist mir noch aufgefallen:
In der Funktion 'initialize()' wird 'init_twi_slave(slaveadresse)' 
aufgerufen, die das Hardware-TWI initialisiert und das Interrupt-bit 
setzt. Da hier TWI jedoch hier softwareseitig realisiert wurde, ist 
'init_twi_slave(slaveadresse)' komplett überflüssig und kann entfallen. 
Ebenso kann die Datei 'i2cslave.c' aus dem Projekt entfernt werden.
 Da ich vermutete, daß ein verfrühter Interrupt bei mir die 
Kommunikation mit dem Terminaladapter verhindert, habe ich alle 'sei()' 
in den von 'initialize()' aufgerufenen Routinen entfernt. Nur das letzte 
'sei()' in 'initialize()' bleibt stehen. Ob damit das Terminalprogramm 
funktioniert, werde ich später prüfen. Jedenfalls klappt das Schreiben 
auf und das Lesen vom Eeprom damit fehlerlos.
 Der Empfang von Daten klappt auch, aber das Senden...
Deshalb habe ich testweise eine neue 'main()' erstellt. Sie enthält 
außer 'initialize()' alles was in 'rf12_txdata(...)' steht, mit dem 
Unterschied, daß ich Daten (3 Byte) und eigene id fest vorgebe und nicht 
über *data auf einen Puffer zugreife. Noch ein Schleifchen ringsrum 
gebastelt, und siehe da, alle gesendeten Bytes kommen beim Empfänger 
auch an. Entfernung der beiden Boards: ca. 1m, Antenne: 2cm Draht.
Liege ich jetzt ganz falsch, oder müsste ich den Fehler im 
senderseitigen Puffer suchen? Aber wie kommt es, daß es bei einigen 
Leuten offensichtlich problemlos klappt, während Andere sich die Haare 
raufen? Sind da unterschiedliche Dateiversionen im Umlauf? Ich habe die, 
die in diesem Thread zweifach genannt wurde. Na, ich werde jedenfalls 
weiter basteln und raufen.

Fröhliche Weihnachten, Wen

Autor: Johannes Kreuzer (andun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Wen Strauss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Andun,

mit Terminaladapter meine ich eigentlich die komplette Kette von 
'Terminalprogramm' - 'USB-Seriell-Wandler' - 'Adapterplatine PC to 
Funkboard'. Eine Fehlerquelle ist möglicherweise auch der USB-Seriell 
Wandler, der mit seinem Timing halt doch nicht exakt einer 'echten' 
seriellen Schnittstelle entspricht. Den fehlenden Pegelwandler auf der 
Adapterplatine hatte ich ja schon erwähnt. Im Terminalprogramm bekam ich 
immer die Meldung 'Funkboard not connected', bis ich in der initialize.c 
die Zeile   //uart_puts("INIT"); mal testweise entkommentiert habe. 
Danach hatte ich gelegentlich das Erfolgserlebnis 'Funkboard connected', 
aber irgendwelche Einstellungen konnte ich trotzdem nicht ändern, obwohl 
ich sie teilweise auslesen konnte. Deshalb habe ich alle Einstellungen 
zunächst fest programmiert und verzichte momentan noch auf die 
Änderungsmöglichkeit mit dem Terminalprogramm. Möglicherweise hat man 
alle diese Probleme nicht, wenn man mit einem anderen Controller direkt 
mit TTL-Pegel auf den UART des ATMega zugreift.
 Mit Deiner Lösung verschenkst Du 99% der Funktionalität des Funkboards. 
Um ein Byte zu übertragen braucht man auch keine 32kB Flash. Ein kleiner 
Tiny2313 hätte allemal ausgereicht. Das soll jetzt keine Kritik sein, 
denn wenn man so ein Board hat, möchte man es ja auch nutzen. Und wenn 
man für seine Anwendung nur ein Byte braucht, ist das wohl auch in 
Ordnung. Jedenfalls besser, als Funkboard wegwerfen und ATTiny neu 
kaufen.
 Für das, was mir vorschwebt, brauche ich aber mehr Funktionalität. Ich 
möchte in jedem Raum meines Hauses die Temperatur messen, die 
Solltemperatur einstellen können und auch noch eine Rückmeldung von der 
Heizungssteuerung über ein LCD erhalten, und das alles drahtlos und 
fehlertolerant. Dazu braucht's nun mal adressierbare Knoten und eine 
bidirektionale Verbindung. Eigentlich sollte das Funkboard genau das 
können...
 Gruß, Wen

Autor: Bene Jan (terfagter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Johannes Kreuzer (andun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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.

Autor: Johannes Kreuzer (andun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!

Autor: Wen Strauss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Johannes,
Nachdem wir durch Herumstochern im Code tatsächlich die eine oder andere 
Kleinigkeit gefunden haben, aber das Board trotzdem noch nicht so läuft 
wie gewünscht, muß man wohl etwas systematischer vorgehen. Am 20.12. 
hatte ich ja schon damit begonnen und bin zur Vermutung gelangt, den 
Fehler im senderseitigen Fifo zu suchen. Ich war gerade dabei, diese 
Annahme zu vertiefen, als ganz ohne jede Vorwarnung und -ehrlich- ohne 
meine Schuld das Jahr plötzlich zu Ende war. In jedem Raum Matratzen und 
Schlafsäcke, der Geschirrspüler lief pausenlos und ein Stehplatz in der 
Küche war nur noch mit Ellenbogen zu ergattern. Aber auch dieses 
Naturereignis hatte mal ein Ende.
 Ich habe also Folgendes gemacht:
In der main.c habe ich nach dem Initialisieren unterschiedliche Pakete 
entsprechend den Vorgaben gepackt, also
den Startcharakter,
die Target-ID,
die eigene ID ohne ACK,
die Nutzdatenlänge (3),
die erste Checksumme,
drei Datenbytes,
zwei CRC-Bytes,
zwei Dummybytes, insgesamt 12 Bytes.
 Diese Pakete (ca. 100) habe ich versendet, indem ich die Funktionen in 
rf12.c unmittelbar aufgerufen habe. Zwischen den Paketen habe ich eine 
Pause gelassen, die groß genug ist, um alle Bytes aus dem 
empfängerseitigen Fifo zu schieben.
 Ergebnis:
Alle Pakete sind angekommen, keins war verstümmelt, keins doppelt. 
Senderseitig war nur der HW-Fifo des Funkmoduls beteiligt. Das scheint 
also zu funktionieren, ebenso wie sein Gegenstück auf der 
Empfängerseite. Dort folgt anschließend das SW-Paket-Fifo. Von hier 
gehts weiter in SW-UART-Fifo, nachdem Startcharakter, Checksummen etc. 
entfernt wurden. Das letzte Fifo ist das HW-UART-Fifo. Im Gegensatz zu 
den HW-Fifos, die nur sehr klein sind, sind die SW-Fifos nicht richtig 
gefordert worden, weil ja immer Pausen zwischen den Paketen waren. 
Deshalb der nächste Test: Drei Pakete ohne Pause dazwischen gesendet und 
anschließend eine dreimal so lange Pause wie oben. Ergebnis: das 
gleiche, alles einwandfrei empfangen, Fifo-Algorithmus scheint zu 
funktionieren. Jetzt wollte ich es genau wissen. Test drei: Alle Pakete 
pausenlos hintereinander gesendet. Ergebnis: Die ersten x Pakete 
einwandfrei, später dann fehlten jedes dritte bis fünfte Paket, aber 
keines war verstümmelt oder doppelt. Vom Timing hätte ich genau dieses 
erwartet. 12 Byte zu senden bei 57600 Bd dauert ca. 2,1 ms. Die 
Initialisierung zum Senden dauert auch noch jedesmal etwas. Von den 12 
gesendeten Bytes kommen am Empfänger-UART nur noch vier raus (die 
Sender-ID und die drei Nutzbytes). Das dauert bei 9600 UART-Baudrate ca. 
4.8 ms. Wenn der Fifo voll ist, sollte also etwa jedes dritte bis vierte 
Paket verloren gehen. Das stimmt ganz gut mit der Beobachtung überein. 
Anmerkung: Wenn man bei Sender- und Empfänger-UART mit der gleichen 
Baudrate arbeitet, sollte es zu einem solchen Fehler gar nicht erst 
kommen.
Mein Fazit: Empfangsseitig würde ich dem Funkboard die Absolution geben. 
Der uns so störende Fehler ist wohl im senderseitigen Paket-Fifo zu 
suchen. Da die mir zur Fehlersuche zur Verfügung stehenden Hilfsmittel 
lediglich aus einer Kaffeemaschine und einer Schüssel Gehirnschmalz 
bestehen (beides nicht mehr neuwertig), rechne ich nicht mit einer 
superschnellen Lösung.
 An Deinen Einwand bezüglich der ACK-Funktion habe ich auch zuerst 
gedacht, aber meine ersten Tests waren auch alle ohne ACK nicht ok.

Gruß, Wen

Autor: Johannes Kreuzer (andun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus _neu (markush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Markus D. (daubsi)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Markus _neu (markush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich hab das noch nie irgendwo fertig gesehen, also alles DIY ;-)

Gruß - Markus

Autor: Wen Strauss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo an alle!

Drei Sachen habe ich noch gefunden, die auch für andere interessant sein 
könnten.

1. Falsche Broadcastadresse
Wer seine Datenpakete an die in der Doku angegebene Broadcastadresse 
hex55 gesendet hat, braucht sich nicht zu wundern, daß sie nicht 
angekommen sind. Die Empfangsroutine prüft nicht auf hex55 sondern auf 
hexAA. Wer jetzt meint, er müsse einfach seine Pakete an AA statt 55 
senden, bekommt gleich die nächste Ohrfeige. AA liegt außerhalb des 
Adressbereichs und ist eigentlich ein 2A mit gesetztem ACK-bit. Und da 
2A was anderes ist als AA werden diese Pakete vom Empfänger verworfen.

Abhilfe:
In der Datei rf12.c in der Routine rf12_rxdata unter Punkt vier AA in 55 
ändern.


2. Streunende Timerinterrupts
Das sind Interrupts, die auftreten, wenn sie gar nicht auftreten 
sollten. Ursache: Beim Initialisieren beispielsweise werden die Timer 
gestartet und eine Interruptbedingung festgelegt (z.B. Output Compare 
oder Overflow) aber die Interrupts noch nicht enabled. Nach einer 
gewissen Zeit treten die Interruptbedingungen ein, die entsprechenden 
Flags werden gesetzt, aber ein Interrupt wird noch nicht ausgelöst, weil 
sie noch nicht enabled sind. Tut man das schliesslich, kommt sofort der 
Interrupt (das entsprechende Bit ist ja gesetzt) obwohl man eigentlich 
ein paar Millisekunden warten wollte. Beim Timer2, der erst feuern 
sollte, wenn ein neues Datenpaket über den Uart empfangen wurde, heißt 
das, daß ein neues Paket gemeldet wird, obwohl noch nicht ein Byte 
empfangen wurde. Der Müll, der sich noch im Datenpuffer befindet, wird 
jetzt weiterverarbeitet...
Vielleicht nicht schlimm, wenn man im Sende/Empfangsmodus ist, weil der 
Empfänger den Müll verwirft, aber im Konfigurationsmodus kann das 
allerhand Unsinn anstellen. Dieser Fehler tritt nicht nur einmal nach 
dem Initialisieren auf, sondern jedesmal, wenn zwischen disablen und 
erneutem enablen eine entsprechende Zeitspanne vergangen ist.Das 
betrifft alle verwendeten Timer.

Abhilfe:
Überall dort, wo ein Timer disabled werden soll, erst den Timer stoppen, 
dann den Interrupt disablen.
Überall dort, wo ein Timer wieder enabled werden soll, erst den 
Zählerwert auf null zurückstellen, den Interrupt enablen und dann erst 
den Timer wieder starten.

Ich habe das bei allen drei Timern gemacht. Seitdem leuchtet die 
Receive-LED viiiiel schöner.


3. Paketlänge
Eigentlich kein Fehler im Funkboard, sondern in der Peripherie. Bei 
einem Paket sollten die einzelnen Bytes lückenlos hintereinander kommen. 
Ist das nicht der Fall, weil man wie ich einen USB-Seriell-Wandler hat, 
der zwischen den Bytes wahllos und zufällig Pausen läßt, passiert 
folgendes: Das erste Teilstück kommt vielleicht noch an, weil es den 
richtigen Startcharakter, eine gültige Empfängeradresse und die richtige 
erste Checksumme hat. Bei den restlichen Bröseln trifft das nicht zu und 
sie werden verworfen. Hat man nur genug von diesen Bröseln, die ja alle 
den Fifo vollstopfen, kommt es schnell zu einem Pufferoverflow, und man 
wundert sich, daß auf einmal Datenfragmente ankommen, die man schon 
gestern gesendet hat. Übrigens, eine serielle Buchse am Rechner ist kein 
Garant dafür, daß man auch eine "echte" serielle Schnittstelle hat. Bei 
vielen Rechnern, besonders Laptops, findet man stattdessen schon auf dem 
Motherboard einen USB-Seriell-Wandler. Ist halt billiger.

Abhilfe:
Eine echte Abhilfe wäre, auf USB zu verzichten, wo das nicht geht, mag 
folgendes akzeptabel sein. Ich habe das Timeout von Timer2 vergrößert, 
zunächst auf das 16-fache des ursprünglichen Wertes, als das noch nicht 
langte, auf das 64-fache (beim Starten des Timers die 1 nicht in CS0 
sondern in CS1 resp. CS2 schieben). Auch zerstückelte Pakete kommen 
jetzt an. Natürlich hat diese Vorgehensweise auch große Nachteile. Man 
muß beim Senden die Pausen zwischen den Paketen entsprechend groß 
machen, sonst hat man das gleiche Problem mit umgekehrtem Vorzeichen. 
Bei 9600 Baud und 64-facher Timeoutzeit sind das immerhin 133 ms. Und ob 
das zusammen mit dem Acknowledge funktioniert, weiß ich noch nicht.


Ok, wenn ich noch was Schlaues zu berichten habe, melde ich mich wieder.

Gruß, Wen

Autor: Bene Jan (terfagter)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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?

Autor: Wen Strauss (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

Auf einfachen Wunsch eines einzelnen Mitglieds (Bene Jan) habe ich das 
Paket noch mal mit allen Änderungen/Verschlimmbesserungen neu gepackt. 
Es ist noch eine readme mit dabei, die nicht als Bedienungsanleitung 
verstanden sondern wirklich gelesen werden sollte. Über Rückmeldungen 
und Erfahrungen würde ich mich freuen.

Bis später,
Wen

Autor: Markus _neu (markush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Matthias S. (mat-sche)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
abo

Autor: Knüller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo mat-sche,

Was heißt'n abo?

Autor: Markus _neu (markush)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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 ---

Autor: Knüller (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aso              (Abkürzung für "ach so!°)

Autor: Wen Strauss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo an alle!

Ursprünglich war es meine Absicht gewesen, das Funkboard als black box 
hinter einen ATTINY 2313 zu schalten. Allerdings hat der ATMEGA noch 
jede Menge Ressourcen frei. Flash ohnehin reichlich. Da ich weder einen 
MAX3221 noch einen ZLDO habe, auch noch jede Menge Portpins, nur SRAM 
ist mager.
Florian hat zwei Arrays definiert (gbl_spi_receive_buffer und 
gbl_i2c_receive_buffer) die aber nirgendwo benutzt werden. Wenn man 
deren Definition im Quelltext auskommentiert, gewinnt man satte 140 
Bytes. Damit kann man schon was anfangen. Ich werde wohl auf den Tiny 
verzichten und seine Aufgaben an den Mega delegieren. Dann brauche ich 
auch den UART und seine FIFOs nicht mehr, das gibt noch mal jede Menge 
freies SRAM. Ohne UART gibt's auch keine Probleme mehr mit USB-Seriell 
Wandlern.
Kann mir vielleicht jemand verraten, warum ich mir die ganze Mühe 
gemacht habe?

Gruß,
Wen

Autor: Johannes Kreuzer (andun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Wen Strauss (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Johannes

Die Originalplatine habe ich nie zu Gesicht bekommen. Ich habe mir zwei 
Prototypen auf Lochrasterplatten gewrappt (ich bin ein Fan dieser 
Technik). Als RS232 Treiber dient ein stinknormaler MAX232 und als 
Spannungsregler ein ebenso normaler 7805.

Gruß, Wen

Autor: Fabian V. (fabian29)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

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

LG Fabian

Autor: Martin J. (bluematrix) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
... 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"

Autor: Martin J. (bluematrix) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert

Autor: Michael Mayer (eos400dman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Manuel (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du (ich geh mal davon aus, dass du Windows hast) mal im 
Gerätemanager geschaut, ob der FT232 erkannt wird und die Treiber 
passen?
Ich musste schon öffter mal den Treiber runterladen bei ftdichip.com
Normalerweise brennt erst die eine led, (dann blinken die beiden 
übertragungsleds kurz und schnell,) danach geht die eine aus und die 
andere an. das bedeutet dann, dass er bereit ist.
was sagt denn der pc?

Autor: Michael Mayer (eos400dman)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Johannes Kreuzer (andun)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Christian P. (peterfrosta)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Stryker_2k (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Christian Peskov schrieb:
> Wäre jemand so freundlich ne entsprechende zip oder so zum download
> bereitzustellen?
> wäre super!

Genau das was du suchst ist in diesem Thread verlinkt. Das ganze sogar 2 
mal ;-)

Autor: Christian P. (peterfrosta)
Datum:

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

Autor: Christian P. (peterfrosta)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
falls einer ein ähnliches problem wie das von mir oben beschriebene 
hat...
(empfänger empfängt hintergrundrauschen, wenn sender eingeschaltet wird 
nur noch nullen)
Es lag bei mir ausschließlich an den printf befehlen in der 
rfm-schreib-funktion - bei mir: spi_rfm().
hatte für debugging zwecke alles und jeden über printf rausgehauen...das 
hat wohl das timing im modul nicht mitgemacht...
ich war happy als dann endlich gesendet UND empfangen wurd!
mfg

Autor: Alex (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi,
hat einer für mich eine überarbeitete und funktionierende hex und eep 
Datei?

bitte  an alexius84.aw@googlemail.com

Danke

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.