Talking to a USB nRF24L01

Hi guys,

I'm interested in controlling my robot from my laptop, and the CH340T USB to Serial + nRF24L01 combo looked promising:

eBay
DealExtreme
AliExpress

Unfortunately I can't seem to find example code on the internet, and I'm struggling to get it to respond to anything I send to it over PuTTY.

My backup plan is us plug an Arduino in to my laptop and have that drive the nRF24L01, but the CH340T us a much cleaner solution for me.

Has anyone had luck getting this working?
Any pointers for getting started?

I'm using the MIRF library on the robot, and I've tried translating MIRF to Python, and sending commands using the serial library, but like I said, no response.

Thanks :slight_smile:

Update:

I've written a simple bit of python code, and if I use two CHT340T's (the USB adapter's) the nRF24L01's can talk to each other:

import time
import serial

# configure the serial connections (the parameters differs on the device you are connecting to)
ser = serial.Serial(
    port='COM5',
    baudrate=9600,
    parity=serial.PARITY_ODD,
    stopbits=serial.STOPBITS_TWO,
    bytesize=serial.SEVENBITS
)

ser.isOpen()

input=1
while 1 :
        input = str(int(time.time()%60))
        ser.write(input + '\r\n')
        out = ''
        # let's wait one second before reading output (let's give device time to answer)
        time.sleep(1)
        while ser.inWaiting() > 0:
            out += ser.read(1)

        if out != '':
            print ">>" + out

The remaining bit is finding the channel, payload, etc. that the CHT340T's setup the nRF24L01's at, and I can get the Arduino configured to match.

I've never heard of a NRF24L01 that will respond to RS232-type serial commands and a few attempts with Google couldn't find any examples.

Normally one uses SPI data transfer with the radio. Why should this combo work at all?

In any case, there are a number of self-contained USB/radio modules that simply act as TTL serial links between a PC and any microcontroller. That would be a much simpler approach. One example is the Wixel, which incidentally is a programmable microcontroller with its own IDE.

It won't work from serial, the nRF24 needs a microcontroller to drive it directly via SPI and possible an interrupt line too.

Check this out ...... click here

There are absolutely zero links to a userguide for this thing. The links to the software appear to be micro-controller software.... and some of the files within seem corrupted. Doesn't look good.

@southpark you're right, that does look corrupted.

On the plus side, I think you've given me an amazing lead to get this working!

@mark & j: I've been looking in to it, the "CH340T board" has more than just a CH340T chip on it. It looks like it has a STC 11L04E microcontroller on board as well. When I send data over the COM port the CH340T translates, and the STC microcontroller will either accept some basic AT commands, or it will just send the data out.

I've looked at the wixel, it looks like a cool product, but to get it in to Australia the price is ~$40ea.
Unfortunately I've been given a $200 budget for this project, and I can't afford to spend 1/5th of my budget on one side of the tranceiver.

Even if the CH340T board does what you claim (reliably) it doesn't do much good without a user guide!

$3 Bluetooth modules also work as wireless serial links. I suggest to get the robot working with a wired connection before spending money on a radio.

m_bear:
I've written a simple bit of python code, and if I use two CHT340T's (the USB adapter's) the nRF24L01's can talk to each other:

I ended up ordering a set of two, and had frustrating moments in trying to install the serial communications package for python 3 in windows 8.1..... that's 'pyserial'. Eventually figured it out..... there is an executable .exe file that installs pyserial very easily. I spent heaps of time trying to install it within python...and kept encountering error messages. The executable installation sorted it out nicely in the end.

Python 3 has updated 'commands'.... like the print command now requires brackets... ie print("hello"). Also, to send data bytes.... I had to use this method..... ser.write("55".encode()) where the all-important part is the .encode() suffix. So if 'input' were a string ... then would need to do ser.write(input.encode())

Then..... I needed to plug in my two modules (each fitted with the NRF24L01) ..... and in my computer, the windows 8.1 system automatically assigned serial com ports 6 and 8 to them. For the receiving module ( that windows automatically assigned to com 8 ), I opened a PuttY window for com 8. Then for the python software, I set the com port to '6' (see my code attached). This sent the characters '55' (every 1 second) to the module that was listening on com 8.

The thing is..... there appears to be no way to configure the communications so that the serial messages are directed to a specific receiving module. They normally configure channel pipe codes etc using SPI instructions from the micro-controller program. I wonder if there's a software for Windows that can get access that area. Will look around.

So yeah..... the wireless serial comms is definitely working, since I don't get any serial communications occurring when I remove the wireless transmitters etc. [Also UPDATE: the wireless serial comms also worked when I put the receiver module into a different computer in a different room].

What surprises me is ..... no computer-side software to configure radio ID addresses etc. So the question is how to properly pair up transmitting and receiving modules? It's kind of weird.

Anyway, the code I used is attached.

import time
import serial
# configure the serial connections (the parameters differs on the device you are connecting to)
ser = serial.Serial(
    port='COM6',
    baudrate=9600,
    parity=serial.PARITY_EVEN,
    stopbits=serial.STOPBITS_ONE,
    bytesize=serial.EIGHTBITS
)

ser.isOpen()

input=1
while 1 :
        #input = str(1)
        ser.write("55".encode())
        out = ''
        # let's wait one second before reading output (let's give device time to answer)
        time.sleep(1)
        while ser.inWaiting() > 0:
            out += ser.read(1)

        if out != '':
            print(">>" + out)

@Southpark: Thanks for updating this thread!

From your work it appears that the CH340T (+) modules turn the radio into yet another dumb wireless serial link. These comments from the ebay site suggest that AT commands can set the module address, but I'm not sure what "address" means in this case (perhaps one of five pipes?):

AT Commands
Baudrate : AT+BAUD=n where n = 1-6 (1:4800,2:9600,3:14400,4:19200,5:38400,6:115200) (default 9600Kbps)
NRF Rate : AT+RATE=n where n = 1-3 (1:250K, 2:1M, 3:2M ) (default 2Mbps)
Local Address : AT+RXA=0Xnn,0Xnn,0Xnn,0Xnn,0Xnn where nn are the local receiving address (default 0xff,0xff,0xff,0xff,0xff)
Target Address : AT+TXA=0Xnn,0Xnn,0Xnn,0Xnn,0Xnn where nn are the target address
Operating Freq. : AT+FREQ=2.nnnG where nnn = 400 / 525 (default 2.400G)
Checksum mode : AT+CRC=n where n = 8 /16 (default : 16 bit)
System info : AT?

An interesting question is: how would one bypass the USB connection, for use with an Arduino serial connection?

jremington:
@Southpark: Thanks for updating this thread!

Hi Jremington! Most welcome! Thanks so much for your kind help with providing that extra information!

Tremendous stuff!

In the serial communications terminal window......when I typed usual ascii text, the NRF24L01 would send out the text characters as usual.

When I typed this command.... AT? the response was: leading garbled characters followed by recognisable values... like 4800 baud, receive address, transmit address etc (for each line).

Eg...

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

Then I typed AT+BAUD=2 (ie 9 characters in total) and the response was:

ϵͳÐÅÏ¢£º
²¨ÌØÂÊ£º4800

This is pretty good. I don't mind seeing the scrambled text.... the main thing was that the baud rate really changed to 4800 (as verified in that AT response message). But when that happened, my serial comms terminal (which was originally set at 9600 baud) stopped working as expected. So I then needed to alter the serial comms window settings to 4800 baud in order start communicating with the NRF24L01 again.

You were right about the pipes. For one of the modules, I used your commands to configure a local receiving address (ID) to 0x11 0x22 0x33 0x44 0x55 by sending this command.

AT+RXA=0x11,0x22,0x33,0x44,0x55

So the remote (OTHER) transmitter would need to SEND to the above address value. So on the other transmitter, I used:

AT+TXA=0x11,0x22,0x33,0x44,0x55

Actually, I decided to use the same receive and target address on both modules....so both had the same settings...... ie... on both modules, I just used the same commands...

ie AT+RXA=0x11,0x22,0x33,0x44,0x55
and AT+TXA=0x11,0x22,0x33,0x44,0x55

We can easily choose other address values....but I just used the above for simple testing. Works well.
They remember the address settings even after the modules are powered down, which is nice (except we'd need to remember what BAUD rate it's set to.... otherwise that could be a hassle, since it remembers baud rate settings too).

Thanks again Jremington. Greatly appreciated!

(deleted)

I bought a couple of the eBay CH340T/NRF24 sets for experimentation, and ran into a lot of trouble with the device drivers on a Win7 machine. I found three outdated versions of the CH340 driver, and none of them installed or worked properly.

The Win7 machine then began freezing up, so I fixed it by booting in safe mode and removing the drivers.

My conclusion: a learning experience, but overall a waste of time and not recommended for Windows machines.

I have used the pair on a win 8.1 machine talking to a winxp (sp3) machine without any problems at all.

However, I spent quite a while in searching for a driver for the CH340T (for the winxp SP3) machine. I downloaded various FTDI drivers from the 'FTDI' site....but didn't work.

I ended up getting a working driver from some site (for winxp). The FTDI site didn't have that driver (as stupid as that was).

I haven't done much more than just getting a python script to keep sending text characters from 1 module (in one room) to the other module (in a different room). Didn't have any issues with that.

But the lockups described by jremington due to driver issues could be a hassle.

I think long term testing for a particular application will be important - to ensure things behave/perform properly.

Thanks for the information on this thread. Very usuful, however, I still cannot use the USB adapter for my needs.

I have a dinamic network composed of several (from 2 to 30) arduinos with nrf24l01. I do not use pipes nor reliable communication. All the elements can comunicate to each other. The elements do move, so they sometimes stay in range and sometimes not (not a big deal, it is just a game).

This is the conf:
nrf24.setChannel(108) (above 100 to avoid Wifis)
DataRate250kbps (lowest rate to maximize RF range)

I use RadioHead library with it's simplest way:

    nrf24.send(datosRF, sizeof(datosRF));
    nrf24.waitPacketSent();

The data message is very small, just: "Msg:XX".

On another side I have a PC connected by USB to an Arduino and a nrf24l01. It acts as gateway from RF to the PC. On the PC I have a SW reading the serial port. This works fine and the PC receives all the messages.

So I purchased a USB adaptor module to simplify the PC gateway. The problem is that I cannot configure the nrf24l01 USB adaptor in any way (I only have one, so I cannot test with two) to receive these packages. I can send the AT commands to configure, but no messages from the nrf24l01 appear on the serial line. Shall I have to configure in any special way? Any help will be greatly appreciated!

JuanchoM:
So I purchased a USB adaptor module to simplify the PC gateway. The problem is that I cannot configure the nrf24l01 USB adaptor in any way (I only have one, so I cannot test with two) to receive these packages. I can send the AT commands to configure, but no messages from the nrf24l01 appear on the serial line. Shall I have to configure in any special way? Any help will be greatly appreciated!

Normally, once a suitable FTDI driver has been successfully installed in the PC, then plugging one of these USB adapter/ch340T combinations into the PC will result in a COM port getting assigned (which can usually be seen in DEVICE MANAGER of the windows operating system).

If the serial terminal program (such as Termite) is set up properly.... such as with correct data rate.... like 9600 baud..... then configuration is normally just a matter of typing the required commands accurately.....

eg.... need to type things like:

AT+RXA=0x11,0x22,0x33,0x44,0x55

AT+TXA=0x11,0x22,0x33,0x44,0x55

So you have to type the whole line (including the '+' symbol and '=' symbol as well as 'AT' at the front)

Thanks Southpark,

I have already the CH340 driver installed and the correspondant COM port appears. I use RealTerm and I can see the configuration with AT?:

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

But when I send from the Arduino Mega using another nrf24l01+ I see nothing on RealTerm, I guess I should receive the insformation I send there.

This is the code I have on the Arduino to configure the nrf24l01+:

uint8_t NetworAddress[] = {0xE7, 0xE7, 0xE7, 0xE7, 0xE7}; //  default pipe 1 address
  while (!Serial)
    ; // wait for serial port to connect. Needed for Leonardo only
  if (!nrf24.init())Serial.println("init failed");
  // Defaults after init are 2.402 GHz (channel 2), 2Mbps, 0dBm - Ponemos el Canal 108 para usar el rango de 2.508 GHz para evitar las Wifi (2400-2500)
  if (!nrf24.setChannel(108)) Serial.println("setChannel failed");
  if (!nrf24.setRF(RH_NRF24::DataRate250kbps, RH_NRF24::TransmitPower0dBm)) Serial.println("setRF failed");
  if (!nrf24.setNetworkAddress (NetworAddress, sizeof(NetworAddress))) {
    Serial.print("setNetworkAddress failed: ");Serial.println(*NetworAddress);
  }

I guess I am missing something related to Network address or pipes.

I must add that the communication between Arduinos using that code works like a charm with this reception code:

if (nrf24.available()) {
    // Should be a message for us now
    uint8_t buf[RH_NRF24_MAX_MESSAGE_LEN];
    uint8_t len = sizeof(buf);
    if (nrf24.recv(buf, &len)) {

It seems that the Arduino reception code works on promiscuous mode, so all the packages are received, but the USB interface does not.

Any suggestion to be able to view the arduino messages on the USB nrf24l01+ dongle?

Thanks in advance.

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

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.

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

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.

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.

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:

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

which Google translates to:

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