www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Funk-AVR-Eva-Board und RFM12


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

Bewertung
0 lesenswert
nicht lesenswert
hallo,
habe versucht das Funk-Avr-Eva-Board und einem 868MHZ RFM12 zu testen.
dafür benutze ich die Software von Benedikt K. die Sofware habe ich 
einiges geändert weil ich ein Mega16 und ein 868MHZ Modul benutze.

bei den Sender und Empfänger auf die Pins SDI,CLK und nSEL kommt das 
selbe Signal mit einem frequenz von 100K

und auf dem Pin SDO bei Empfänger gibt überhaupt nichts auf dem 
Oszilloskop zu sehen.
im Anhang steh das geänderte programm.

gibt es etwas, dass ich falsch mache? oder übersehe ich irgendetwas?
ich danke Ihnen in vorraus
Chryst

Autor: Dummschwätzer7093 (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>gibt es etwas, dass ich falsch mache?

Wenn Du so arbeitest wie Du schreibst wird das eh nichts!
Also nerv uns nicht.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Grundsätzlich interessiert mich das Thema, da ich sowohl zwei solcher 
Boards als auch zwei RFM12 habe. Allerdings die RFM12 noch nicht 
ausprobiert und erst ein Board aufgebaut.

Deine Problembeschreibung verstehe ich allerdings nicht.

Mir fällt es schwer mir den Experimentieraufbau vorzustellen, wenn du 
von "das Funk-Avr-Eva-Board und einem 868MHZ RFM12" schreibst.

Ich hätte erwartet, dass du eine Funkstrecke aus zwei 
Funk-Avr-Eva-Boards mit je eine 868MHZ RFM12 gegeneinander testest, 
wobei ein RFM12 als Sender und einer als Empfänger arbeitet.

In der nur kurz überflogenen Source kommt mir spanisch vor, dass der 
Atmega16 mit 10 MHz laufen soll. Hast du einen anderen Quarz Q3 
eingesetzt, als von Pollin vorgesehen (16 MHz)? Stimmt die UART-Ausgabe 
über Kabel?

Länger bin ich in die Source nicht eingestiegen, weil ich keine 
Änderungskommentare und nicht den alten Code sehe. Dadurch geht 
verloren, was richtig war und was potentiell falsch ist und man müsste 
ALLES kontrollieren. Aber nicht am Freitagnachmittag ;-)

Im Artikel Pollin Funk-AVR-Evaluationsboard ist der 
Erfahrungsbericht von Marco Schmoll zitiert, bei dem ein möglicher Bug 
im Zusammenhang mit dem RFM12 erwähnt ist. Es könnte sein, dass schon 
kein vernünftiges Funksignal aus dem sendenden RFM12 herauskommt, weil 
der sich beim Senden mit Hilfe des komischen Optokopplers auf dem Board 
selbst den Saft abdreht. Der empfangende RFM12 hätte so keine Chance...

Hast du deine Versuche mit angestecktem ISP-Programmierkabel (an 
RS232-ISP oder J2) gemacht oder hast du das ISP Kabel abgezogen?

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

Bewertung
0 lesenswert
nicht lesenswert
Danke für die antworten

@  Dummschwätzer7093
wie du siehst ich bin kein Deutscher. ich lerne diese sprache seit 5 
monaten aber ich weiss es ist keine entschuldingung. wir können wenn du 
willst auf Französisch schreiben.

Stefan wrote
>Ich hätte erwartet, dass du eine Funkstrecke aus zwei
>Funk-Avr-Eva-Boards mit je eine 868MHZ RFM12 gegeneinander testest,
>wobei ein RFM12 als Sender und einer als Empfänger arbeitet.

ja stimmt das meinte ich.

Stefan wrote
>> Hast du einen anderen Quarz Q3
>> eingesetzt, als von Pollin vorgesehen (16 MHz)?
ja ich habe die Platine von Pollin zusammen gebaut wie es im dem klein 
heft steht und die Q3 (16 MHz) habe eingesetzt

Stefan wrote
>> Stimmt die UART-Ausgabe über Kabel?

die UART Ausgabe Stimmt. ich habe die UART mit einem kleinem programm 
getestet.
Das Programm sollte ein klein Text auf dem Hyperterminal per RS232 
ausgeben. und es hat richtig geklappt

Stefan wrote
>> Hast du deine Versuche mit angestecktem ISP-Programmierkabel (an
>> RS232-ISP oder J2) gemacht oder hast du das ISP Kabel abgezogen?

das habe ich mit dem RS232-ISP gemacht.

Stefan wrote
>> Länger bin ich in die Source nicht eingestiegen, weil ich keine
>> Änderungskommentare und nicht den alten Code sehe. Dadurch geht
>> verloren, was richtig war und was potentiell falsch ist und man müsste
>> ALLES kontrollieren. Aber nicht am Freitagnachmittag ;-)

den alten code steht im Anhang. und für Freitagnachmittag verstehe ich 
ganz klar.

Vielen Dank nochmal Stefan
MFG
Chryst

Autor: Stefan Salewski (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>@  Dummschwätzer7093
>wie du siehst ich bin kein Deutscher. ich lerne diese sprache seit 5
>monaten aber ich weiss es ist keine entschuldingung.

Woran sollte ich sehen, dass Du kein Deutscher bist?

Dass man im Deutschen Substantive und am Satzanfang groß schreibt lernt 
man eigentlich ganz zu Anfang. Und gerade wenn man nicht in seiner 
Muttersprache schreibt sollte man vielleicht eine Rechtschreibkorrektur 
einsetzen.

Und man sollte versuchen, sein Problem verständlich zu beschreiben.

Benedikt K. hat an der Software sicher lange gearbeitet, Du wirst Dich 
mit dem Thema auch schon einige Zeit beschäftigt haben. Dann sollte man 
doch auch eine gute halbe Stunde für ein ordentlich Posting aufbringen 
können. Das wäre auch in Deinem eigenen Interesse, denn viele Leute 
lesen so lieblos dahingeschmierte Beiträge nicht und antworten erst 
recht nicht.

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
So einfach wie du die Anpassung gemacht hast, ist es nicht.

Ich sehe vor allem Anpassungsbedarf in rf12_setfreq in rf12.c. Es reicht 
nicht nur den Kommentar dort zu ändern. Du musst die für 433 MHz 
ausgedachten magischen Zahlen in die passenden Zahlen für 868 MHz 
ändern. Den "Trick" in main.c einen float Wert an eine Funktion zu 
übergeben, die einen unsigned short Prototypen hat, verstehe ich nicht.

Desweiteren kann Anpassungbedarf dadurch entstehen, dass du von 8 MHz 
Takt beim originalen Atmega8  auf 16 MHz bei deinem Atmega16 wechselst. 
Du musst aufpassen, dass die SPI Datenübertragung AVR<>RFM12 nicht zu 
schnell wird (FAQ <= 2,5 MHz). Ich erwarte, dass das Timing in 
rf12_trans jetzt nicht mehr stimmt und dass mehr Warteschleifen 
asm("nop") und nötig sind.

Insgesamt müsste man nahe am Datenblatt des RFM12 (bzw. des ICs RF12) 
kleben und dann die komplette Source auf Sinnhaftigkeit beim Wechsel 433 
=> 868 MHz abklappern.

Den ISP-Programmer würde ich beim Testen abziehen. Er hängt ja an den 
SPI Leitungen und ich würde Beeinflussungen möglichst vermeiden.

Autor: Chryst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für die Antworten.
um deine Frage über die magischen zahlen für 868MHz habe ich schon 
geändert vielleiecht hast du es übersehen.

du kannst se in der main function sehen. noch mal hier unten

int main(void)
{
    uart_init(UART_BAUD_SELECT(19200, F_CPU));
  rf12_init();
  rf12_setfreq(RF12FREQ(868.92));

  rf12_setbandwidth(4, 1, 4);
  rf12_setbaud(19200);
  rf12_setpower(0, 6);

  sei();
  uart_puts_P("Empfaenger laeuft !\n");

  for (;;)
  {
    receive();
  }
}

>Den "Trick" in main.c einen float Wert an eine Funktion zu
>übergeben, die einen unsigned short Prototypen hat, verstehe ich nicht.

damit werden die Decimalstellen weggelassen.

Ich mach mich schlau im Datenblatt des RF12 IC´s aber wenn du oder 
jemand eine Lösungsansatz für die Kommunkation zwischen den Sender und 
den  Empfänger mit einem 868MHz hast/hat, es wäre für mich sehr 
hilfreich.

Danke

MFG
Chryst

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du meinst diese Zeile?

> rf12_setfreq(RF12FREQ(868.92));

Das bewirkt "nichts". Die hardcodierten magischen Zahlen, die ich meine 
stehen in der Funktion rf12_setfreq selbst. Dort wird der übergebene 
Wert auf eine Untergrenze und eine Obergrenze abgeprüft. Solche Grenzen 
an sich sind aus dem Datenblatt bekannt.

// aus rf12.h
#define RF12FREQ(freq)  ((freq-430.0)/0.0025)  

// aus rf12.c
void rf12_setfreq(unsigned short freq)
{  
  if (freq<96)             // 430,2400MHz
    freq=96;
  else if (freq>3903)      // 439,7575MHz
    freq=3903;
  rf12_trans(0xA000|freq);
}

Wenn du diese beiden Grenzen 96 und 3903 und das Makro nicht auch 
verändert hast (was ich im Moment nicht sehe), kommt deine 868.92 gar 
nicht zum IC durch, weil diese Grenzen sicher für die andere Frequenz 
gelten. Wenigstens habe ich jetzt entdeckt, wie die Zahlen zustande 
kommen.


Und so genau habe ich das Datenblatt noch nicht gelesen, als dass ich 
sagen könnte, nur die Frequenz zu ändern reicht aus. Ich meine du kannst 
auf dem Chip etliches mehr einstellen und ob dann z.B. die folgenden 
Zeilen ohne Anpassung übernommen werden können... ein Unterschied bei 
den 433 und 868 Modulen ist z.B. das Kanalraster (s.o. 0.0025 => 2,5 KHz 
bei 433 MHz und 5(?) KHz bei 868 KHz)...

> rf12_setbandwidth(4, 1, 4);
> rf12_setpower(0, 6);

Ich werde frühstens übernächste Woche tiefer in das Thema einsteigen 
können. Zum Glück konnte ich damals in einer Sammelbestellung hier 
sowohl 433 MHz als auch 868 MHz Module erstehen. Ich plane schrittweise 
vorzugehen, d.h. zuerst einen Aufbau mit 2x 433 MHz und wenn das 
fehlerfrei klappt, wechseln auf die Module mit der höheren Frequenz.

Autor: Chryst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke stefan.

Stefan wrote:

>Die hardcodierten magischen Zahlen, die ich meine
>stehen in der Funktion rf12_setfreq selbst. Dort wird der übergebene
>Wert auf eine Untergrenze und eine Obergrenze abgeprüft. Solche Grenzen
>an sich sind aus dem Datenblatt bekannt.

da haast du recht.
Auf der Datenblatt hat man diese Formel:
f0=10*C1*(C2+F/4000)[MHz]
f0 ist hier die Unter- und die Obergrenfrequenze abhängig von der 
Parametern C1, C2, und F.
F befiden sich zwischen 96 und 3903 egal für welche Band.
aber C1 und C2 sind von dem Band abhängig.
Für ein 868MHz Band C1 hat der wert 2 und C2 der wert 43.

Und nach der Formel, für einen 868MHz Band, die Untergrenze ist 860,4800
und die Obergrenze ist 879,5150.
Daher kommt meiner Kommentare.

void rf12_setfreq(unsigned short freq)
{
  if (freq<96)             // 860,4800MHz
    freq=96;
  else if (freq>3903)      // 879,5150MHz
    freq=3903;
  rf12_trans(0xA000|freq);


}

mein macro habe ich so verändert
// aus rf12.h
#define RF12FREQ(freq)  ((freq-430.0)/0.005)

Und für diese funktionen:
> rf12_setbandwidth(4, 1, 4);
> rf12_setpower(0, 6);
weiß ich nicht ob man sie ändern muss
Wenn ja welche parametern kommen hier vor?

Danke in voraus
Chryst

Autor: Manuel Stahl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
> mein macro habe ich so verändert
> // aus rf12.h
> #define RF12FREQ(freq)  ((freq-430.0)/0.005)

und was ist mit der 430.0? Die musst du natürlich auch verändern.
Am besten du gibst deinem Macro auch einen neuen Namen, z.B. 
RF12FREQ886, dann kann man die Bibliothek später mit beiden Bändern 
verwenden.

Wenn du vom SDO gar nichts zurückbekommst, ist entweder die SPI Frequenz 
zu hoch (> 2,5MHz, was aber mit Software SPI nicht möglich sein sollte), 
nFFS liegt nicht auf VCC (sehr wichtig!) oder die Pegel des SPI passen 
nicht.

Autor: Chryst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
War meine fehler.
Richtig es ist so:
#define RF12FREQ(freq)  ((freq-860.0)/0.005)

>Wenn du vom SDO gar nichts zurückbekommst, ist entweder die SPI Frequenz
>zu hoch (> 2,5MHz, was aber mit Software SPI nicht möglich sein sollte),
>nFFS liegt nicht auf VCC (sehr wichtig!) oder die Pegel des SPI passen
>nicht.

wie ich es ganz oben gesagt habe, das RF12 Funkmodul habe ich auf die 
Platine der Funk-AVR-Evaluationboard gelötet.
kannst du bitte auf den code nachschauen und sagt mir Bitte wie ich es 
verbessern könnte.

MFG
Chryst

Autor: Manuel Stahl (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
>>nFFS liegt nicht auf VCC (sehr wichtig!)

Du solltest den Code folgendermaßen erweitern:
void rf12_init(void)

{

  RF_DDR=(1<<SDI)|(1<<SCK)|(1<<CS);

  RF_PORT=(1<<CS);

  DDRB|=(1<<PB3);          // (Pollin Board) nFFS als Ausgang
  PORTB|=(1<<PB3);         // (Pollin Board) nFFS auf VCC
...

Autor: Chryst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke!

Ich versuche wieder mit der Erweiterung der Code und melde mich später 
nochmal an.

Chryst

Autor: Chryst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ich habe den Code erweitert aber es gibt keinen änderungen im Oszi 
Bildschirm.
immer das selbe signal mit einer Frequenz von 1MHz auf der Pins nSEL, 
SCK und SDI beim Sender und Empfanger. Das Signal ist Sinusformig. Ist 
es normal?

Und auf den Pin SD0 kommt immer gar nichts zurrückt.

Chryst

Autor: Chryst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
hallo!!!!!
hat niemand eine Idee??

Autor: Stefan B. (stefan) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Stefan "stefb" B. wrote:

> Ich werde frühstens übernächste Woche tiefer in das Thema einsteigen
> können.

Autor: Chryst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Stefan!
hast du schon mit dem modul angefangen zu arbeiten?
Oder weisst jemand wie ich meine oben genannte problem lösen kann.
Ich bitte auf Ihre hilfe leute.
Vielen Dank!
MFG
Chryst

Autor: Chryst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Halloo!!!!

Keine Idee??

Autor: Chryst (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
am 03.07.08, wrote Stefan "stefb" B.:

> Ich werde frühstens übernächste Woche tiefer in das Thema einsteigen
> können.


Hi Stefan!
hast du schon mit dem Thema angefangen?
wenn ja, sagst mir wie weit du bist.
MFG
Chryst

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.