Go Down

Topic: Talking to a USB nRF24L01 (Read 10227 times) previous topic - next topic

Southpark

#15
Sep 18, 2016, 10:35 pm Last Edit: Sep 20, 2016, 05:05 am by Southpark
Hi there JuanchoM,

I was taking a look at the possibility of getting some basic data sending (eg. ascii character) from arduino to this ch340T/nrf24L01 combination.

At the moment, I notice that the ch340T/nrf24L01 combo has AT commands for setting up communications parameters.

One barrier that I see right now is the 8 bit or 16 bit CRC check feature on the CH340T side.

I'm not an expert etc in the RF24 library (that I am using for usual arduino to arduino communications using nrf24L01 modules)......... at the moment, not sure if the RF24 library examples are using CRC or not. And if so.... what is the default setting etc. I'm still taking time to learn more about the RF24 library.

So, if the ch340T/nrf24L01 has fixed options for either 8 bit CRC or 16 bit CRC, then maybe the only way for arduino (and RF24 library) to send information to the ch340T/nrf24L01 is to use CRC.

I noticed that - using the command...   AT?    for grabbing ch340T/nrf settings, the line that has the garbled message "УÑ鷽ʽ£º16λCRCУÑé" shows the value "16" among the garble. That "16" is corresponds to the CRC length.


Another thing that sort of confuses me is the RF24 library 'RF_CH' or (rf channel) numbering. I did try to look at documentation for the RF24 library. And it 'looks like' the RF24 library channel starts from channel 1, and ends at channel 126 according to these guys .....click here......

So RF24 library 'channel 1' would correspond to 2400 MHz
RF24 library 'channel 2' would correspond to 2401 MHz etc.
So looks like channel N corresponds to 2400 + (N-1) MHz......  maybe.

[UPDATE] --- I found that the details/information regarding RF24 library channel numbers at ....click here..... is erroneous, unless the RF24 library they're talking about is some other version.

I have now found and tested for myself that RF24 library channel '4' actually corresponds to 2.404 GHz (aka 2404 MHz). So as far as my testing is concerned, the channel number "N" actually corresponds to frequency (2400 + N) MHz. Eg. RF channel N = 4 will be 2.404 GHz.


Also, the default radio frequency transmission data rate for the ch340/nrf is 2 MHz. But it looks like the default radio transmission data rate for RF24 library examples is 1 MHz.

So.....in the arduino code using the RF24 library, I think I need to put this in.....

radio.setDataRate(RF24_2MBPS);

Southpark

#16
Sep 19, 2016, 06:07 pm Last Edit: Sep 24, 2016, 11:25 pm by Southpark
After tinkering with nrf24L01 channel (frequency) settings, the nrf24L01+ communications eventually worked between the MEGA2560 (fitted with nrf24L01+) and the desktop Windows 8.1 computer (fitted with the ebay USB ch340T/nrf24L01+ module).

I managed to use the arduino to send the string "abcdefghijkl" to the PC. The PC side receives "[02]abcdefghijkl".

So far, not sure where the "[02]" comes from. But at least there's communications happening. The desktop side is also able to send text back to the arduino.

The RF24 library is used. The main thing to remember is that the channel number "N" will set a frequency of {2400 + N} MHz. So N = 4, which is set by:  radio.setChannel(4);   will make the nrf24L01+ module operate at 2404 MHz.

The code I used is just something from the internet that I modified a little bit. I used a MEGA2560, but the code would also work for UNO's etc.

I can later add a diagram for the pin connections that I used between NRF24L01+ and the MEGA2560.







The code below let's me send the basic text string from the MEGA 2560 to the desktop computer (via nrf24L01+ communication). In the arduino Serial Monitor window, I type the letter 'T' (and then hit the Enter key) to start the sending of the text to the desktop.

Code: [Select]
/* Modified by Kenny - Mon-19-Sep-2016 - for the purpose of getting an arduino MEGA2560 (with NRF24L01+ wifi module) to communicate with a Windows desktop PC fitted with a CH340T/NRF24L01+ USB module */

/*
* Getting Started example sketch for nRF24L01+ radios
* This is a very basic example of how to send data from one node to another
* Updated: Dec 2014 by TMRh20
*/

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

char * outchar = "abcdefghijklmnopqrs\r\n\0";


/* Hardware configuration: Set up nRF24L01 radio on SPI bus plus pins 9 & 53, which are CE & CSN pins  */
RF24 radio(9, 53);
/**********************************************************/

byte addresses[][6] = {"AAAAA", "AAAAB"};  //with radioNumber set to zero, the tx pipe will be 'AAAAA', which is basically HEX'4141414141', which is remote DESTINATION address for our transmitted data. The rx pipe code is the local receive address, which is what the remote device needs to set for the remote devices 'tx' pipe code.

// Used to control whether this node is sending or receiving
bool role = 0;

void setup() {
  Serial.begin(9600);
  Serial.println(F("RF24/examples/GettingStarted"));
  Serial.println(F("*** PRESS 'T' to begin transmitting to the other node"));

  radio.begin();
  radio.setDataRate(RF24_2MBPS);   //choosing 2 Mega bit per second radio frequency data rate   //radio frequency data rate choices are:  //RF24_250KBPS    //RF24_2MBPS  //RF24_1MBPS
  radio.setChannel(4);   // this channel '4' will set a RF frequency of 2.404 GHz, aka 2404 MHz.


  // Set the PA Level low to prevent power supply related issues since this is a
  // getting_started sketch, and the likelihood of close proximity of the devices. RF24_PA_MAX is default.
  radio.setPALevel(RF24_PA_LOW);


  radio.openWritingPipe(addresses[0]);
  radio.openReadingPipe(1, addresses[1]);

  // Start the radio listening for data
  radio.startListening();
}

void loop() {


  /****************** Ping Out Role ***************************/
  if (role == 1)  {  //transmit role

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


    Serial.println(F("Now sending"));

    unsigned long time = micros();                             // Take the time, and send it.  This will block until complete
    if (!radio.write( &outchar, strlen(outchar)+2)) {
      Serial.println(F("failed"));
    }

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

    unsigned long started_waiting_at = micros();               // Set up a timeout period, get the current microseconds
    boolean timeout = false;                                   // Set up a variable to indicate if a response was received or not


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



  /****************** Pong Back Role ***************************/

  if ( role == 0 )   //initial role is '0', ie. listening
  {
    unsigned long got_time;

    if ( radio.available()) {  //'available' means whether valid bytes have been received and are waiting to be read from the receive buffer
      // Variable for the received timestamp
      while (radio.available()) {                                   // While there is data ready
        radio.read( &got_time, sizeof(unsigned long) );             // Get the payload
      }

      radio.stopListening();                                        // First, stop listening so we can talk
      radio.write( &got_time, sizeof(unsigned long) );              // Send the final one back.
      radio.startListening();                                       // Now, resume listening so we catch the next packets.
      Serial.print(F("Sent response "));
      Serial.println(got_time);
    }
  }




  /****************** Change Roles via Serial Commands ***************************/

  if ( Serial.available() )
  {
    char c = toupper(Serial.read());
    if ( c == 'T' && role == 0 ) {
      Serial.println(F("*** CHANGING TO TRANSMIT ROLE -- PRESS 'R' TO SWITCH BACK"));
      role = 1;                  // Become the primary transmitter (ping out)

    } else if ( c == 'R' && role == 1 ) {
      Serial.println(F("*** CHANGING TO RECEIVE ROLE -- PRESS 'T' TO SWITCH BACK"));
      role = 0;                // Become the primary receiver (pong back)
      radio.startListening();

    }
  }


} // Loop

Southpark

#17
Sep 19, 2016, 06:11 pm Last Edit: Sep 24, 2016, 11:15 pm by Southpark
The settings used on the PC side nrf24L01+ are shown in this picture :



The pins I used between the nrf24L01+ and the MEGA 2560 are shown in this picture :



The reason for connecting SCK pin of the NRF24L01+ to pin 52 of the MEGA2560 is only because the MEGA2560 schematics says digital pin 52 is associated with "SCK". That section of the MEGA2560 (ie pins 50, 51, 52, 53) are associated with SPI communications.

So, if the UNO board or some other arduino board is to be used (instead of a MEGA 2560), then that's no problem....... would just need to find out the corresponding (relevant) SPI communications pins on the UNO, and everything should be fine.


At the moment, for my testing - I notice that - depending on what string is transmitted, there will be extra characters at the receiving side like [02] on the front end of the string, and [00] symbols on the back end. This is probably because I'm using the wrong character array structure, or not accessing/addressing the character array or pointers correctly. The [02] could also be a 'start of text' string pattern.

Also, at the moment, the incoming characters on the computer (PC) side are noticed to be limited to 13 characters. I'm expecting the NRF24L01+ can handle up to 31 or 32 characters. I need to track down my mistakes in coding, and hopefully sort that out.


What I found so far is ...... while the PC side is unfortunately receiving only 13 characters at a time when the arduino side is sending more than 13 characters, the ARDUINO SIDE is able to receive 31 text characters at a time when the PC side sends it.

Other tests I've done are: two CH340T/NRF24L01+ modules (each fitted to a PC) --- they are able to send and receive 31 text characters to each other. No problem.

Also, two arduinos, each fitted with NRF24L01+ --- also able to send and receive 31 text characters (to each other). Also no problem.

So, at the moment, it will be nice to find out why a desktop computer fitted with a USB ch340T/nrf24L01+ truncates incoming message to 13 characters (ie. discards the rest of the characters that are meant to be incoming) only for the case where the incoming message comes from an arduino/nr4f24L01 unit. For example, if the arduino side sends 'abcdefghijklmnopq', then the computer side (fitted with the usb ch340T/nrf) will receive [02]abcdefghijklm, which is like an escape character (hex 02, maybe a start of text character that gets added in from somewhere), followed by 13 characters.

Southpark

#18
Sep 25, 2016, 07:11 pm Last Edit: Sep 27, 2016, 05:35 am by Southpark
Hi folks!

.....at the moment, still trying to figure out why arduino/nrf24L01+ sending to a computer (fitted with usb ch340T/nrf24L01+) only receives 13 text characters (and the rest of the characters go missing). ie.... the arduino side transmits correctly, while the PC side (with the usb ch340T/nrf) only gets 13 of the characters.

The following picture shows this truncation thing that's happening :

arduino/nrf (transmitter) to usb ch340T/nrf (receiver) :

Could certainly get by with sending a maximum of 13 bytes at a time from arduino/nrf24L01+ to computer/ch340T-NRF24L01+. But would be nicer if the reason for truncation can be explained and fixable (if possible).

For other test cases (mentioned below), the incoming message gets received with no problem (ie. no truncations) such as.......

- usb ch340T/nrf (transmitter) to arduino/nrf (receiver)
- arduino/nrf (transmitter) to arduino/nrf (receiver)
- usb ch340T/nrf (transmitter) to usb ch340T/nrf (receiver)


The following screenshots are examples of the above 3 cases, where receiving is no problem. ie. no truncation of incoming message.

usb ch340T/nrf (transmitter) to arduino/nrf (receiver) :
Here, a USB ch340T/nrf at the computer transmits text to the arduino/nrf. The text is correctly received. Interestingly, in Termite serial monitor, the very first received incoming byte is equal to the 'number of bytes' received. Not sure why this byte is present. It may be a feature of Termite serial monitor - but....on the other hand, this only occurs when monitoring ARDUINO/nrf RECEIVED (decoded) data while the transmitter is a ch340T/nrf module (fitted to a computer). Also, that first byte (equal to number of received bytes) doesn't show up in Arduino Sketch serial monitor, and also doesn't show up in PuttY serial monitor. So not sure what's going on here yet.





arduino/nrf (transmitter) to arduino/nrf (receiver) :
NOTE UPDATE: I noticed that the very last character 'e' was not actually received, which is supposed to be the 31st text character. This seems to be due to a hex 0E and a hex 02 character appearing as the first two received characters. So somewhere, along the line, a hex 0E and a hex 02 got injected into the front end of my text data. Those two characters would then leave room for thirty (ie. 30) text characters (since NRF24L01+ transmits a max of 32 bytes at a time). So the presence of the non-text characters, 0E and 02 would mean no room for the 31st 'e' character. Hence my 'e' character got cut off.




usb ch340T/nrf (transmitter) to usb ch340T/nrf (receiver) :
This involves straight computer-to-computer communications with USB ch340/nrf dongles on both sides (ie. no arduino involved).



A quick summary about what is found so far........the computer with the USB ch340T/nrf24L01+ 'dongle' can certainly send up to 30 text characters at a time to the arduino. But it appears that - at the moment - the Arduino/nrf24L01+ combination can only send up to about 13 text characters at a time to the computer - due to the observed truncation behaviour on the computer (ch340T/nrf) side. Sending 13 bytes at a time to the computer is quite ok in many cases. If somehow we can overcome that limitation, then it would be most excellent.

pidge

Regarding the "garbage" you get in response to the AT commands--it's in a Chinese character set, which unsurprisingly doesn't display well as ASCII. Python will decode it with the gb18030 encoding, eg:


print(ser.readline().decode('gb18030'))


You can also try the gb2312 or gbk encodings if your platform/language doensn't have gb18030.

The response to the AT? command is:

Quote
OK
系统信息:
波特率:9600
目标对方地址: 0xFF,0xFF,0xFF,0xFF,0xFF
本地接收地址0:0xFF,0xFF,0xFF,0xFF,0xFF
工作频率:2.400GHz
校验方式:16位CRC校验
发射功率:0dBm
空中传输速率:2Mbps
低噪声放大增益:开启
which Google translates to:

Quote
OK
system message:
Baud rate: 9600
Target address: 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
Local receive address 0: 0xFF, 0xFF, 0xFF, 0xFF, 0xFF
Operating frequency: 2.400GHz
Calibration method: 16-bit CRC checksum
Transmit power: 0dBm
Over the air transmission rate: 2Mbps
Low Noise Amplification Gain: On

Southpark

#20
Sep 27, 2016, 05:16 am Last Edit: Sep 27, 2016, 05:18 am by Southpark
Hey thanks pidge! I'd certainly rather look at the chinese characters rather than the garbled stuff..... even though I don't know how to read the chinese characters. Better than the garble that's for sure. Thanks for the tip about the gb18030.

Who knows why they pushed these units with chinese characters onto us. Would be nice if they also sell english language versions. Thanks again!

Southpark

#21
Oct 02, 2016, 11:35 pm Last Edit: Oct 07, 2016, 06:32 am by Southpark
Finally identified (by stumbling across it) something associated with the unwanted truncation of ASCII strings sent FROM the Arduino/nrf24L01+ combination TO the USB CH340T/NRF24L01+  dongle transceiver.

Earlier, I mentioned that if I were to use the arduino to try send "abcdefghijklmnopqrstuvwxyz" from arduino to the computer, the incoming message at the computer (dongle) side would be truncated.... like "abcdefghijklm".

However, doing the reverse by sending "abcdefghijklmnopqrstuvwxyz" from the computer (dongle) to the arduino was not a problem (ie. no truncation).

Interestingly (but not understanding it yet), the problem so far appears to be in the code where I set transmit and receive pipe addresses. I'll briefly discuss what I found as follows:

The original code I used for setting pipe addresses was like this:

Code: [Select]
byte addresses[][6] = {"AAAAA", "AAAAB"};  //with radioNumber set to zero, the tx pipe will be 'AAAAA', which is basically HEX'4141414141', which is remote DESTINATION address for our transmitted data. The rx pipe code is the local receive address, which is what the remote device needs to set for the remote devices 'tx' pipe code.

Anyway, note the '6' in [][6]. I used that value of '6' because the code I used is obtained from RF24 library tutorials. It's something to do with the maximum number of pipe addresses for NRF24L01+.

Interestingly, if I change the '6' to a larger value such as '14', then the number of text characters than can be received (in one hit) at the USB ch340T/NRF dongle (computer side) grows to 29.

But, 14 is the highest value I can use right now. If I use a value like '15' or higher, then communications won't occur - ie. transmission from the arduino no longer occurs. I need to stick with '14' for now.


So, at the moment, if I send 32 text characters "abcdefghijklmnopqrstuvwxyzabcde" from computer (USB ch340T/NRF dongle) to arduino, then the arduino receives the full payload.

And, if I use the arduino to send "abcdefghijklmnopqrstuvwxyzabcde" to the USB dongle, then the USB dongle will receive 1 non-text character, and 29 text characters.... such as "[02]abcdefghijklmnopqrstuvwxyzabc". So, basically, it's missing the last "d" and "e". The [02] could be a start of text character, but don't yet know how that got in there.

Anyway, the dongle being able to receive 29 text characters in one hit is certainly much better than previously receiving 13 text characters.


If anyone can explain how transmit and receive address configuration can cause this message truncation effect, then that would be tremendous. What I mean is ... if I use this declaration:

byte addresses[][6] = {"AAAAA", "AAAAB"};    

then the message received by the USB ch340T/nrf dongle gets clipped to 13 text characters.

If I then change the line to:

byte addresses[][7] = {"AAAAA", "AAAAB"};  

then the message received gets clipped to 15 text characters.

If I then change (again) the line to:

byte addresses[][8] = {"AAAAA", "AAAAB"};  

then the message received gets clipped to 17 text characters.

So whatever the value (eg. N)  I put into the square bracket, the incoming message gets clipped to (N-6)*2 + 13 characters.

This means.....

byte addresses[][14] = {"AAAAA", "AAAAB"};  

would correspond to (14-6)*2 + 13 = 29 text characters received only (if the incoming message were to have more than 29 text characters).


The interesting thing is .....  if I go back to my original line, with a '6' ie....

byte addresses[][6] = {"AAAAA", "AAAAB"};  

..... then there is no truncation issues for plain arduino/nrf to arduino/nrf communications. The truncations only occur when the USB dongle receives from an arduino/nrf. And, I didn't ever expect that the settings of TX and RX pipe addresses would be linked to message truncations.


Overall, the situation is pretty good now. Much better than before.



I'll just include the code that I'm now using for the transmitting arduino MEGA2560 (with it's NRF24L01+ module, using digital pin 9 for "CE", and digital pin 53 for "CSN").


Code: [Select]

/* Modified by Kenny - Mon-3-Oct-2016 - for the purpose of getting an arduino MEGA2560 (with NRF24L01+ 2.4GHz transceiver module) to communicate with a Windows desktop PC fitted with a CH340T/NRF24L01+ USB module */

/*
* Getting Started example sketch for nRF24L01+ radios
* This is a very basic example of how to send data from one node to another
* Updated: Dec 2014 by TMRh20
*/

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

char * outchar = "abcdefghijklmnopqrstuvwxyzabcde\0";


/* Hardware configuration: Set up nRF24L01 radio on SPI bus plus pins 9 & 53, which are CE & CSN pins  */
RF24 radio(9, 53);
/**********************************************************/

byte addresses[][14] = {"AAAAA", "AAAAB"};  //with radioNumber set to zero, the tx pipe will be 'AAAAA', which is basically HEX'4141414141', which is remote DESTINATION address for our transmitted data. The rx pipe code is the local receive address, which is what the remote device needs to set for the remote devices 'tx' pipe code.

// Used to control whether this node is sending or receiving
bool role = 0;

void setup() {
  Serial.begin(9600);
  Serial.println(F("RF24/examples/GettingStarted"));
  Serial.println(F("*** PRESS 'T' to begin transmitting to the other node"));

  radio.begin();
  radio.setDataRate(RF24_2MBPS);   //choosing 2 Mega bit per second radio frequency data rate   //radio frequency data rate choices are:  //RF24_250KBPS    //RF24_2MBPS  //RF24_1MBPS
  radio.setChannel(4);   // this channel '4' will set a RF frequency of 2.404 GHz, aka 2404 MHz.


  // Set the PA Level low to prevent power supply related issues since this is a
  // getting_started sketch, and the likelihood of close proximity of the devices. RF24_PA_MAX is default.
  radio.setPALevel(RF24_PA_LOW);


  radio.openWritingPipe(addresses[0]);
  radio.openReadingPipe(1, addresses[1]);

  // Start the radio listening for data
  radio.startListening();
}

void loop() {


  /****************** Ping Out Role ***************************/
  if (role == 1)  {  //transmit role

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


    Serial.println(F("Now sending"));

    unsigned long time = micros();                             // Take the time, and send it.  This will block until complete
    if (!radio.write( &outchar, strlen(outchar)+2)) {
      Serial.println(F("failed"));
    }

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

    unsigned long started_waiting_at = micros();               // Set up a timeout period, get the current microseconds
    boolean timeout = false;                                   // Set up a variable to indicate if a response was received or not


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



  /****************** Pong Back Role ***************************/

  if ( role == 0 )   //initial role is '0', ie. listening
  {
    unsigned long got_time;

    if ( radio.available()) {  //'available' means whether valid bytes have been received and are waiting to be read from the receive buffer
      // Variable for the received timestamp
      while (radio.available()) {                                   // While there is data ready
        radio.read( &got_time, sizeof(unsigned long) );             // Get the payload
      }

      radio.stopListening();                                        // First, stop listening so we can talk
      radio.write( &got_time, sizeof(unsigned long) );              // Send the final one back.
      radio.startListening();                                       // Now, resume listening so we catch the next packets.
      Serial.print(F("Sent response "));
      Serial.println(got_time);
    }
  }




  /****************** Change Roles via Serial Commands ***************************/

  if ( Serial.available() )
  {
    char c = toupper(Serial.read());
    if ( c == 'T' && role == 0 ) {
      Serial.println(F("*** CHANGING TO TRANSMIT ROLE -- PRESS 'R' TO SWITCH BACK"));
      role = 1;                  // Become the primary transmitter (ping out)

    } else if ( c == 'R' && role == 1 ) {
      Serial.println(F("*** CHANGING TO RECEIVE ROLE -- PRESS 'T' TO SWITCH BACK"));
      role = 0;                // Become the primary receiver (pong back)
      radio.startListening();

    }
  }


} // Loop




Southpark

#22
Oct 03, 2016, 12:21 am Last Edit: Oct 03, 2016, 11:17 am by Southpark
Also, for those wondering how to set up the USB CH340T/NRF24L01+ transceiver module ..... I have some details here....

For this particular test....the USB ch340T/nrf24L01+ 'dongle' connected to the computer will be used to receive messages from the arduino wirelessly (even though it has absolutely no trouble sending messages to the arduino).

Once this USB dongle is plugged into the computer, such as a Windows Operating system computer, it's necessary to then use a Serial Communications terminal software like PuttY or Termite to check out the communications settings. I believe that the default baud rate for the dongle is 9600 baud. But obviously, it's also necessary to know which serial communications port is assigned (automatically) to this dongle. So might need to use Device Manager (in windows) to see what 'COM' port was assigned to the dongle in order to communicate with it through the serial monitor terminal.

Can assume that everybody will be able to use a serial communications terminal window to link up with the USB dongle (if they have one of these devices). Let's assume that the serial link is established.

So, in the terminal window, type    AT?    and hit the enter key. Hopefully some garbled characters will show up, with some recognisable values like '9600' (for baud rate), and '16' (for default CRC length), and '2Mbps' (for 2 Megabit per second radio frequency data rate), etc.

I set the receive pipe address by typing:

AT+RXA=0x41,0x41,0x41,0x41,0x41     then hit enter

Note that the above hex code is really "AAAAA" in ascii


Next, I set the transmit pipe address by typing:

AT+TXA=0x41,0x41,0x41,0x41,0x42    (which is "AAAAB" in ascii), then hit enter


Noting in the above that the "transmit pipe address" that we set in the dongle is really the DESTINATION address. So basically, it is the 'transmit to WHERE?' address.

Then, I'm using channel '4', which is 2.404 GHz or 2404 MegaHz.

To set this in the dongle.... type this:

AT+FREQ=2.404      then hit enter.

In the end....just type    AT?    again (and remember to hit enter key) to check on the settings.


A list of settings will pop up.... like..


ϵͳÐÅÏ¢£º
²¨ÌØÂÊ£º9600
Ä¿±ê¶Ô·½µØÖ·£º 0x41,0x41,0x41,0x41,0x42
±¾µØ½ÓÊÕµØÖ·0£º0x41,0x41,0x41,0x41,0x41
¹¤×÷ƵÂÊ£º2.404GHz
УÑ鷽ʽ£º16λCRCУÑé
·¢É书ÂÊ£º0dBm
¿ÕÖд«ÊäËÙÂÊ£º2Mbps
µÍÔëÉù·Å´óÔöÒ棺¿ªÆô

Ignore the garble, as the encoding is reported to be chinese characters.


The first pipe address is the TRANSMIT pipe address (ie. the destination address for the message to be sent, which is going to be the address that the arduino is going to be listening at). So..... at the USB dongle CH340T/NRF, the transmit pipe address is set to "AAAAB" (aka hex 0x41,0x41,0x41,0x41,0x42), and the receive pipe address is set to "AAAAA".

The address on the line below it is therefore the receive pipe address, which is what the dongle will be listening on.

By default, the USB dongle will already have a CRC length setting of 16, and will already have a 2 Mbps radio frequency data rate. So once these settings are ok, then it will be just a matter of focusing on the OTHER (ie. arduino) side of things.....eg... loading the sketch, and making sure you have the "RF24" library included with your arduino library. After loading the arduino code to the arduino, just use the arduino IDE serial monitor terminal, and hit 't' (and enter key) to start transmissions. Then, using another serial monitor window to monitor the activity on the USB dongle side, the incoming characters should start coming in every 1 second or so.

developandplay

#23
Oct 04, 2016, 12:09 am Last Edit: Oct 04, 2016, 10:25 pm by developandplay
First of all thank you Southpark. Based on your instructions I was able to connect the nrf24l01+ arduino combo to the nrf24l01+ to usb adapter. However in the current current firmware the payload size is fixed to 32 bytes. Having a smaller size would allow better stability of transmition whilst a bigger size would be more comfortable to use.
Therefore I tried to flash the firmware from that french ebay seller onto the adapter but I failed horribly at doing so. On my way to achieve my goal I reverse engineered the adapter. The only part I could not identify is the microcontroller that is used on the adapter.
Here is my current status:
  • -The microcontroller is not the stc11l04e as claimed by the french ebay seller. The adapter does not have an external crystal that one would need to use the stc11l04e. Scanning datasheets of microcontrollers by the same manufacturer(stc) I found out that the microcontroller could be one their current stc15 series. Except from the upper mentionded missing crystal my reasons to assume this are:
    • -the Ground and Vcc pins are located on the bottom left and are exactly one pin apart
    • -RX and TX are located on the bottom right

    However using their own stc-isp tool I did not manage to flash the firmware on to the microcontroller let alone identify them. So they might be from an entirely different manufacturer.
  • -I think that I managed to find the initial distributor or even manufacturer. Using the link in the provided code you get to this chinese web shop. There you can by the usb to nrf24l01+ adapter as well as an uart to nrf24l01+ adapter which is essentially the same device without the ch340t for usb to uart conversion.
  • -Searching for devices that use a microprocessor of the stc15 series i came accross this usb nrf24l01+ dongle which uses the stc15w404AS.
  • -There is an adapter that uses the upper mentioned stc11l04e. To me it seems like the predecessor to the adapter in this forum thread.
  • -If you compare the pins in the code to the pins of either the stc15w404s or the stc11l04e they don't match. This led me to the assumption that the code was just copied from another device and is therefore not the code thats running on the adapter. However I did not manage to find out the origianl device.

Overall I think I figured out quite a lot. However the main question still remains: What is the microcontroller that is used in this adapter? If someone has allready found out and wants to share it with me I would be more than happy. I would also be happy if someone wants to help with this task.

If my english doesn't sound all that great please be aware of the fact that I'm German and I had to rewrite this entire post since my browser crashed.

Southpark

#24
Oct 06, 2016, 11:20 pm Last Edit: Oct 07, 2016, 01:05 am by Southpark
However in the current current firmware the payload size is fixed to 32 bytes. Having a smaller size would allow better stability of transmition whilst a bigger size would be more comfortable to use.
Therefore I tried to flash the firmware from that french ebay seller onto the adapter but I failed horribly at doing so. On my way to achieve my goal I reverse engineered the adapter. The only part I could not identify is the microcontroller that is used on the adapter.
Most welcome D.a.p.

Excellent work in tracking down those sources and the reverse engineering.

When you tried to flash new firmware, did that involve plugging in the ch340T/microprocessor dongle and then attempting to use the "stc-isp-15xx-v6.85p.exe" software to check the MCU etc?

I plugged in that ch340T dongle device (the one that is in the photo of the opening post in this thread). I selected 'stc11L04' for the MCU type. Then I clicked on 'CheckMCU' button, but no reports or information returned. Looks like communications between their software and the device isn't working yet.

I ordered a few of those ch340T/nrf dongles from ebay - just for tinkering. So I figured I'd see what happens (following your post) if I tried to use that "stc-isp-15xx-v6.85p.exe" software to link up with the MCU. No activity so far, so thought I'd ask what procedure you used to at least link to it - even though the flash appears to have done something bad (according to your good attempt at it). Thanks for posting your findings. What you did was tremendous - like finding out those details, and getting to the stage you're at. Nice work.

steronydh

Hi all,

I've been trying to set up a USB to nRF24L01+ adaptor, with almost no success. If I enter AT?, I get:

²¨ÌØÂÊΪ  9600
Ä¿±êµØַΪ  0xff,0xff,0xff,0xff,0xff,
±¾µØµØַΪ  0xff,0xff,0xff,0xff,0xff,

so it's working a bit, but I don't get the full list of system info, and none of the other AT commands do anything.

I'd be grateful for any suggestions!

Southpark

#26
Oct 07, 2016, 10:17 pm Last Edit: Oct 07, 2016, 11:03 pm by Southpark
I've been trying to set up a USB to nRF24L01+ adaptor, with almost no success. If I enter AT?, I get:

²¨ÌØÂÊΪ  9600
Ä¿±êµØַΪ  0xff,0xff,0xff,0xff,0xff,
±¾µØµØַΪ  0xff,0xff,0xff,0xff,0xff,
I'm assuming you have a ch340T/NRF24L01+ "dongle-type" device..... the same one shown in the picture of the very first post in this forum thread.

The first thing to try is to grab another module of the same kind. Eg.....  test out a spare module (ie. ch340T/nrf24L01+). They are super cheap from ebay (free shipping as well). In this way, you will be able to conveniently work toward where the problem lies.

You will even be able to do mix and match testing. That is, if the spare hardware works, then see what happens if you interchange nrf24L01+ boards etc.

At the moment, the nice thing is that you're at least getting some activity when you type AT? So that's a good sign. Just go ahead to see what happens if you try the same thing with spare CH340T/nrf24L01+, to see if any board from the current combination is faulty (or not).

developandplay

Sorry Southpark for not responding for over a week.

One reason for that is that I didn't get any email notification that there is a response in the thread. Is there any option to automatically get notified when there is a new response to one of my posts?

The main reason is that I was pretty busy since I designed a completely new usb to nrf24l01+ adapter based on the atmega328p-au. Sizewise they are comparable and I can post the design files as well if someone is interested in them. However since the PCBs are currently produced by Shenzen2U I've not tested their functionality yet.
You can probably imagine why I chose to go that route: I didn't make any progress and I felt like wasting over 2 days on trying to solve the problem. But time is a critical factor since the adapter and the micro quadrocopter that it connects to are part of a physics research paper. I have to publish that in order to get my Abitur (final exams of secondary education in Germany).


Now to your questions Southpark:
  • I used the software that you attempted to use as well.
  • Your procedure seems about right. One thing I did was to desolder the microcontroller because in the datasheet(page 177) they claim that you have to reset it before trying to flash the firmware or reading the MCU type. Therefore you need to do a hard reset by disconnecting power. At least thats how I understood it.
  • If you connect the tx line of the ch340t to an oscilliscope you will see that the software continously sends out data. So the problem seems to be within the transmitted data or the microcontroller. The microcontroller doesn't seem to respond to any of the commands that the isp software sends.
  • If you have some time to further tinker with the adapter I would suggest selecting different microcontrollers in the software(e.g. stc15w404AS). At least that's what I did but it didn't lead to success. Maybe I have not tried enough possible stc chips. Another option is that it is simply a microcontroller from another company or even worse just an unprogrammable chip.
  • Just to make it clear: I didn't get any further than you. No successful MCU check or flashing. It didn't even corrupt the flash or did affect the chip in any way. That's why I finally gave up on it.


During the next month I have to write my research paper so I will be just as busy as I was this week. If there are any easy questions I will answer them of course. After that time period I will try again to identify the microcontroller since I hate not completing projects.

Servus(=colloq. German for bye and hi :D ) developandplay

Leah77

#28
Oct 16, 2016, 04:57 pm Last Edit: Oct 16, 2016, 05:03 pm by Leah77
I have purchased similar hardware (nrf and USB dongle) with hopes of getting a PC-to-Android wireless system going.

I can plug the USB dongle into a my PC or my laptop and Windows 7 is able to locate and load the driver.  My terminal programs are able to communicate with the dongle without issue.

However, when I attach the nrf to the dongle, plug the dongle into a USB port, and connect,  I get a "Serial port access" denied.

This error occurs...

  • regardless of the type of terminal software
  • no matter which USB port is used
  • on both the PC and laptop.
  • after swapping the dongle and nrf boards with each other
  • after swapping the dongle and nrf boards with the PC or laptop


nrf boardhttps://www.amazon.com/Makerfocus-Wireless-NRF24L01-Antistatic-Compatible/dp/B01IK78PQA/ref=cm_rdp_product

usb dongle: https://www.amazon.com/gp/product/B01IK9GGRS/ref=oh_aui_detailpage_o02_s02?ie=UTF8&psc=1

I have not attempted to set up the nrf boards with any Arduinos yet. I'd just like to get simple wireless communication going between two PCs first, which others here seem to be able to do.

TLDR:  I keep getting "Serial Port access denied errors" when using a terminal  program to access the nrf via USB

developandplay

Servus Leah77
To me what you are describing sounds either like a simple software problem or a power delivery problem.
I would do the following steps:
  • "Serial Port acces denied errors" are usually a result of opening more than one terminal window. So make sure you are just trying to connect from one terminal window. Your adapter can't handle two simultaneous connections!

->If that was not the case it might be a hardware problem...
  • Go to the device manager. Watch what happens when you connect the usb adapter on its own. Follow the next step while your adapter is plugged into your PC! Plug the nrf24l01+ module into your adapter and check whether something changes.
  • What exactly happens when you access the adapter from your Serial Terminal? Does the adapter respond to any commands when the nrf24l01+ is unplugged? (My adapter doesn't but they might be different...)
  • Try the adapter with the low power version of the nrf24l01+ module. For me the amplified version worked well but that doesn't guarantee that yours will as well. The modules seem to be hit or miss since even some of my low power ones don't work with the adapter.


I hope that one of those tips helped you solve your problem.
If they didn't help post the results that you got while trying them. That makes troubleshooting way easier.
Servus developandplay ;)

Go Up