nrf24l01+ auf Atmega328/Uno

Hey,

ich bekomme die Module nicht auf dem Atmega328 zum laufen.

Aufbau und Pinbelegung im Anhang (Ist auch so nochmal durchgemessen)
Library und Sketch: Quelle: LINK

Sketch unten angehängt.

Output unten im zweiten Anhang.

Ich bekomme immer timed out.
Hab als einzige Änderung die zwei Pins CE /CSN von 9,10 auf 8,7, was ja kein Problem sein sollte. ??

Irgend eine Idee oder nen anderen Sketch/Link/Beispiel?

Nebeninfos:
Atmega328 intern 8Mhz @ ~4,8V (Vom Uno)
3,2V für den NRF (Nur Kondensator am Eingang des Spannungswandlers) Daher vll? Die Ausgangskondensatoren sind noch bestellt. Aber es geht selbst über längere Zeit nicht..
1.0.5r2 IDE

Sketch:

/*
 Copyright (C) 2011 J. Coliz <maniacbug@ymail.com>

 This program is free software; you can redistribute it and/or
 modify it under the terms of the GNU General Public License
 version 2 as published by the Free Software Foundation.
 */

/**
 * Example for Getting Started with nRF24L01+ radios. 
 *
 * This is an example of how to use the RF24 class.  Write this sketch to two 
 * different nodes.  Put one of the nodes into 'transmit' mode by connecting 
 * with the serial monitor and sending a 'T'.  The ping node sends the current 
 * time to the pong node, which responds by sending the value back.  The ping 
 * node can then see how long the whole cycle took.
 */

#include <SPI.h>
#include "nRF24L01.h"
#include "RF24.h"
#include "printf.h"

//
// Hardware configuration
//

// Set up nRF24L01 radio on SPI bus plus pins 9 & 10 

RF24 radio(8,7);

//
// Topology
//

// Radio pipe addresses for the 2 nodes to communicate.
const uint64_t pipes[2] = { 0xF0F0F0F0E1LL, 0xF0F0F0F0D2LL };

//
// Role management
//
// Set up role.  This sketch uses the same software for all the nodes
// in this system.  Doing so greatly simplifies testing.  
//

// The various roles supported by this sketch
typedef enum { role_ping_out = 1, role_pong_back } role_e;

// The debug-friendly names of those roles
const char* role_friendly_name[] = { "invalid", "Ping out", "Pong back"};

// The role of the current running sketch
role_e role = role_pong_back;

void setup(void)
{
  //
  // Print preamble
  //

  Serial.begin(57600);
  printf_begin();
  printf("\n\rRF24/examples/GettingStarted/\n\r");
  printf("ROLE: %s\n\r",role_friendly_name[role]);
  printf("*** PRESS 'T' to begin transmitting to the other node\n\r");

  //
  // Setup and configure rf radio
  //

  radio.begin();

  // optionally, increase the delay between retries & # of retries
  radio.setRetries(15,15);

  // optionally, reduce the payload size.  seems to
  // improve reliability
  //radio.setPayloadSize(8);

  //
  // Open pipes to other nodes for communication
  //

  // This simple sketch opens two pipes for these two nodes to communicate
  // back and forth.
  // Open 'our' pipe for writing
  // Open the 'other' pipe for reading, in position #1 (we can have up to 5 pipes open for reading)

  //if ( role == role_ping_out )
  {
    //radio.openWritingPipe(pipes[0]);
    radio.openReadingPipe(1,pipes[1]);
  }
  //else
  {
    //radio.openWritingPipe(pipes[1]);
    //radio.openReadingPipe(1,pipes[0]);
  }

  //
  // Start listening
  //

  radio.startListening();

  //
  // Dump the configuration of the rf unit for debugging
  //

  radio.printDetails();
}

void loop(void)
{
  //
  // Ping out role.  Repeatedly send the current time
  //

  if (role == role_ping_out)
  {
    // First, stop listening so we can talk.
    radio.stopListening();

    // Take the time, and send it.  This will block until complete
    unsigned long time = millis();
    printf("Now sending %lu...",time);
    bool ok = radio.write( &time, sizeof(unsigned long) );
    
    if (ok)
      printf("ok...");
    else
      printf("failed.\n\r");

    // Now, continue listening
    radio.startListening();

    // Wait here until we get a response, or timeout (250ms)
    unsigned long started_waiting_at = millis();
    bool timeout = false;
    while ( ! radio.available() && ! timeout )
      if (millis() - started_waiting_at > 200 )
        timeout = true;

    // Describe the results
    if ( timeout )
    {
      printf("Failed, response timed out.\n\r");
    }
    else
    {
      // Grab the response, compare, and send to debugging spew
      unsigned long got_time;
      radio.read( &got_time, sizeof(unsigned long) );

      // Spew it
      printf("Got response %lu, round-trip delay: %lu\n\r",got_time,millis()-got_time);
    }

    // Try again 1s later
    delay(1000);
  }

  //
  // Pong back role.  Receive each packet, dump it out, and send it back
  //

  if ( role == role_pong_back )
  {
    // if there is data ready
    if ( radio.available() )
    {
      // Dump the payloads until we've gotten everything
      unsigned long got_time;
      bool done = false;
      while (!done)
      {
        // Fetch the payload, and see if this was the last one.
        done = radio.read( &got_time, sizeof(unsigned long) );

        // Spew it
        printf("Got payload %lu...",got_time);

	// Delay just a little bit to let the other unit
	// make the transition to receiver
	delay(20);
      }

      // First, stop listening so we can talk
      radio.stopListening();

      // Send the final one back.
      radio.write( &got_time, sizeof(unsigned long) );
      printf("Sent response.\n\r");

      // Now, resume listening so we catch the next packets.
      radio.startListening();
    }
  }

  //
  // Change roles
  //

  if ( Serial.available() )
  {
    char c = toupper(Serial.read());
    if ( c == 'T' && role == role_pong_back )
    {
      printf("*** CHANGING TO TRANSMIT ROLE -- PRESS 'R' TO SWITCH BACK\n\r");

      // Become the primary transmitter (ping out)
      role = role_ping_out;
      radio.openWritingPipe(pipes[0]);
      radio.openReadingPipe(1,pipes[1]);
    }
    else if ( c == 'R' && role == role_ping_out )
    {
      printf("*** CHANGING TO RECEIVE ROLE -- PRESS 'T' TO SWITCH BACK\n\r");
      
      // Become the primary receiver (pong back)
      role = role_pong_back;
      radio.openWritingPipe(pipes[1]);
      radio.openReadingPipe(1,pipes[0]);
    }
  }
}
// vim:cin:ai:sts=2 sw=2 ft=cpp

Ich bin grad leider nicht fähig deinen Beitrag zu lesen und verstehen, weil ich mich grad null Konzentrieren kann, aber vielleicht hilft dir das:

Manawyrm:
die Module reagieren EXTREM empfindlich auf Spannungsschwankungen.
Am besten und stabilsten laufen Sie, wenn du einen 100nF Kondensator (Elko oder nochbesser Kerko) direkt unten auf Spannnungsversorgungspins des nRF lötest.

Danach sind alle meine seltsamen (und sehr ähnlichen) Probleme weg gewesen.

Hallo,

also vorweg, ich bin nicht sicher, dass ich Deine Problemstellung richtig verstanden habe.

Dein Bild erweckt den Anschein, als ob Du Deinen Controller über die Pins 20 und 22 mit Strom versorgst. Ist das tatsächlich so?

Da scheint irgendeine Art serieller Datenverkehr zu bestehen. Bist Du sicher, dass das Timing ohne Quarz, mit 8MHz funktioniert?

Also, ich bräuchte mehr Details, Schaltplan z.B.

Gruß,
Ralf

@Mrskuff
Ja hab jetzt 100nF noch reingesetzt. nicht direkt drauf, aber 2mm daneben.

@Schachmann

Ne, das täuscht. Von der Seite geht zwar Versorgung rein, wird aber auf der Rückseite zu den Beinen 7,8 und auch zum Spannungswandler geleitet.

Der Controller funzt soweit auch, kann ja seriell auslesen und programmieren. Nur irgendwie funzt die KOmm. nicht. Ich weiß halt nicht wie ich die Codes der Library interpretieren kann.

Ich mach mal nen Schaltplan und reiche nach.

//EDIT
Schaltplan (hoffe so aureichend) Ist auch so nochmal nachgemessen. Im Anhang

NRF -- Arduino(Pin) -- Atmega(Bein)
1 -- Masse -- Masse
2 -- 3,3V -- 3,3V
3 -- 9 -- 14
4 -- 10 -- 13
5 -- 13 -- 19
6 -- 11 -- 17
7 -- 12 -- 18

Diese beiden habe ich von 9,10 aud 8(14),7(13) geändert aber wie oben im Sketch angegeben.

dertester:
Nur irgendwie funzt die KOmm. nicht.

Wenn das bedeutet, dass die Kommunikation fehlschlägt, dann wundert mich das nicht. Du nimmst einen Sketch der offensichtlich für einen Controller mit 16MHz Takt geschrieben ist und lässt ihn auf einem Controller mit (im besten Fall) 8Mhz laufen (ich weiß nicht wie die Fuses gesetzt sind). Dann können die Timings eigentlich nicht mehr passen.

Wenn ich das richtig verstehe, hast Du doch zwei Controllerboards, ein selbst gebasteltes und einen Arduino, oder? Falls das so ist, verbinde mal RX und TX der beiden Controller über Kreuz und teste, ob über längere Zeit eine fehlerfreie Datenübertragung mit 57.600bps möglich ist. Mir scheint das zuviel zu sein. Bei 8MHz hättest Du rund -3,5% Abweichung und bei 16MHz rund 2,4% Abweichung. Da wäre so ca. jedes 20. Bit fehlerhaft.

Gruß,
Ralf

Ich verstehe das leider nicht ganz.

Zusatzinfo:
2x 328p @ 8Mhz (also kein Uno also "Partner")
Serielle Ausgabe erfolgt über den UNO @4800 (softserial auf Serial Monitor) und dann auf den PC.
Das serielle geht gut soweit, nur eben die Com über nrf nicht.

A) Seriell läuft, aber besser auf nur 4800, also das stimmt schon. Seriell benutzte ich aber nur um zu kontrollieren welche Ausgaben mir die BEIDEN!! 328 machen. Das ist ja der zweite Anhang oben im ersten Post.

B)Das Sketch läuft nicht auf 8Mhz? Ich bin davon ausgegangen, dass wenn ich den Bootloader @ 8Mhz installiere, die Timings auf 8Mhz soweit angepasst sind, das jedes Sketch usw. wieder passen sollte.

Wie kommst du auf diese %-Abweichungen? Was sagen mir diese? Nur bezogen auf Serielle Comm?

Was mache ich jetzt am besten?

Hatte auch keine Anpassung für folgendes Tut vom Sketch Dev gesehen:

Dachte daher es läuft problemlos @8mhz

//////////////////////////////
Okay habe jetzt ein Scanner example auf dem Breadboard laufen, nochmal alles neu aufgebaut.

Ich weiß nicht wozu CS und CE da sind, aber hatte es so verstanden, dass die nur H/L sind um Modus zu wählen.
Da ich die von zwei PWM pins auf zwei normale gewechselt hatte wird wohl hier mein Fehler liegen.

Ich werde meine Boards nochmal umlöten und sehen, ob es dann geht.

dertester:
Hatte auch keine Anpassung für folgendes Tut vom Sketch Dev gesehen:
Low-Power Wireless Sensor Node | maniacbug
Dachte daher es läuft problemlos @8mhz

Und Du hast dann auch boards.txt wie in dem Text angegeben auf 8MHz?

Gruß,
Ralf

Naja fast. Bis auf die Werte für die Fuses ist es gleich. Da ich @5V arbeite und die 8Mhz ja passen, sollte das soweit kein Problem sein.

Ich muss jetzt aber eh nochmal neu starten. Ich bau jetzt zwei sauber auf dem Breadboard auf und seh dann weiter.

Ich kann leider nicht mehr unterscheiden ob meine 3,3V unsauber sind, oder mir der Scanner nur Mist ausgibt , oder es meine Pinbelegung ist. Jetzt geht der Scanner aber mit dem Pingsketch bekomme ich nur Schrott..

=== Ich mach erstmal Neustart hier und meld mich wieder wenn es dann nicht geht ==

dertester:
B)Das Sketch läuft nicht auf 8Mhz? Ich bin davon ausgegangen, dass wenn ich den Bootloader @ 8Mhz installiere, die Timings auf 8Mhz soweit angepasst sind, das jedes Sketch usw. wieder passen sollte.

Theoretisch ja, aber beim setzen der Fuses geht auch immer wieder mal was schief.

Das kann man Testen wenn man eine LED dran hängt und die in einem bestimmten Takt blinken lässt. Das heißt man überprüft ob z.B. delay(1000) auch wirklich 1 Sekunde ist.

Wie kommst du auf diese %-Abweichungen?

Weil diese Baudraten eigentlich bei diesen Prozessor-Frequenzen nicht genau gehen. Die Baudrate wird aus dem Prozessor-Takt abgeleitet und um die Baudrate wirklich exakt zu haben, müsste man Takte wie 11,059 MHz und ähnliches haben. Diese Quarze gibt es genau dafür. Das geht aber trotzdem mit gerade Frequenzen da die serielle Schnittstelle Toleranzen hat. Aber die reale Frequenz weicht von der theoretischen Frequenz ab. Je nach Takt und Baudrate mal mehr, mal weniger.

Wenn du jetzt noch den Prozessortakt änderst und/oder eine ungenaue Takt-Quelle wie in einen internen RC-Oszillator hast (statt einem Keramik-Resonator oder gar in Quarz), dann wird das noch ungenauer. Und bei hohen Baudraten bekommt man dann tatsächlich Probleme.

Serenifly:
Theoretisch ja, aber beim setzen der Fuses geht auch immer wieder mal was schief.

Muss ja noch nicht mal was schief gehen. Auch so macht es einen Unterschied wie CKDIV8 gesetzt ist.

Serenifly:
Das kann man Testen wenn man eine LED dran hängt und die in einem bestimmten Takt blinken lässt. Das heißt man überprüft ob z.B. delay(1000) auch wirklich 1 Sekunde ist.

Solltest Du auf jeden Fall machen. Lade den Blink-Sketch und schau, ob die LED eine Sekunde an und eine Sekunde aus ist.

Gruß,
Ralf

Okay 2 Updates!

Update 1:
Das Ping/Pong geht nun!
-Folgende Lib: GitHub - gcopeland/RF24: Arduino driver for nRF24L01
-Extra Kondensatoren
-Eins von den 3 Vorbereiteten Boards scheint defekt..

Anscheinend ist bei der Orginal-Lib von den Adressen doof, oder was weiß ich. Der Scanner hat mir immer Werte angezeigt, Ping/Pong ging aber nicht. Ich war dann halt nicht sicher ob mir der SCanner nur random Quatsch anzeigt. Die neue Lib ist da wesentlich übersichtlicher und ich hab auch gemerkt das ein Board nicht geht.

Naja Ping geht jetzt schon paar minuten :slight_smile: Freu mich.. und sooo viele kleine doofe Fehler.

Update2: ==> SCHON GELÖST! DANKE AN SKORPI
Ich hab probiert oben die Boards.txt aus dem Forum zu brennen und es ging nicht. Jetzt kann ich aber auch nicht mehr die normale brennen. Normal blinkt der ja nach dem brennen auf 13 und ich seh das auf dem Uno board. Jetzt leuchtet es dauerhaft.
Fehlermeldung:
avrdude: Yikes! Invalid device signature. Double check connections and try again, or use -F to override this check.

Weiß jetzt nicht genau was ich machen soll :frowning: Hoffe hab den nicht zerschossen. Er hat mit der Boards aus dem Post nicht lange geladen wie normal sondern wie angefangen und dann nicht weiter :confused:

Ich ha 328p-pu, sollte doch passen...

avrdude: Yikes! Invalid device signature. Double check connections and try again, or use -F to override this check.

Hatte ich bei den Tinys als ich die zerschossen hatte.

Bei 8MHz hättest Du rund -3,5% Abweichung und bei 16MHz rund 2,4% Abweichung. Da wäre so ca. jedes 20. Bit fehlerhaft.

Und bei hohen Baudraten bekommt man dann tatsächlich Probleme.

Wenn die richtigen CPU Taktraten verwendet werden, sollte 6% Abweichung noch kein Problem sein,
da ja alle 8 Bit Stop/Start-Bits kommen ...

Hey,
ist das Problem eigentlich gelöst? Wenn nicht....

Der PIN 10 ist der CSN (SS) beim MEGA2560 ist es PIN 53. Den kann man wohl nicht verlegen. Den CE kann man frei wählen.

http://arduino-info.wikispaces.com/Nrf24L01-2.4GHz-HowTo

Ich benutze für mein RC Projekt (noch nicht fertig) einen NANO als Transmitter und der MEGA sitzt im Quadrocopter (fliegt noch nicht). Ich habe das Example "pair_IRQ" als Grundlage genommen. Alles Bestens bis jetzt.

Gruß Kucky