Arduino Forum

Topics => Robotics => Topic started by: m_bear on Jul 03, 2016, 09:58 am

Title: Talking to a USB nRF24L01
Post by: m_bear on Jul 03, 2016, 09:58 am
Hi guys,

I'm interested in controlling my robot from my laptop, and the CH340T USB to Serial + nRF24L01 combo looked promising:
(http://i.ebayimg.com/00/s/OTc0WDk3NA==/z/dPMAAOSwAvJW9TDC/$_57.JPG)
eBay (http://www.ebay.com.au/itm/CH340T-USB-to-Serial-Port-Adapter-Board-2-4G-NRF24L01-Wireless-Module-GH/351686713688?_trksid=p2047675.c100005.m1851&_trkparms=aid%3D222007%26algo%3DSIC.MBE%26ao%3D1%26asc%3D20140106155344%26meid%3D003305d8578744588c785931ce136c71%26pid%3D100005%26rk%3D1%26rkt%3D3%26sd%3D351706858101)
DealExtreme (http://www.dx.com/p/nrf24l01-usb-wireless-serial-data-transmission-module-blue-379934)
AliExpress (http://www.aliexpress.com/item/CH340T-USB-to-Serial-Port-Adapter-Board-2-4G-NRF24L01-Wireless-Module/32603537354.html?ws_ab_test=searchweb201556_7,searchweb201602_4_10037_10017_10033_406_10032,searchweb201603_3&btsid=5455aad6-c2e3-48a1-a4c4-391c6824497f)

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



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:
Code: [Select]
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.
Title: Re: Talking to a USB nRF24L01
Post by: jremington on Jul 05, 2016, 03:31 am
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 (https://www.pololu.com/product/1336), which incidentally is a programmable microcontroller with its own IDE.
Title: Re: Talking to a USB nRF24L01
Post by: MarkT on Jul 07, 2016, 12:29 am
It _won't_ work from serial, the nRF24 needs a microcontroller to drive it directly via SPI and possible an interrupt line too.
Title: Re: Talking to a USB nRF24L01
Post by: Southpark on Jul 07, 2016, 09:16 am
Check this out ...... click here (http://www.ebay.com.au/itm/NRF24L01-USB-adapter-adaptateur-USB-2-4Ghz-pour-NRF24L01-UART-2-4G-NRF24L01-/272081225026)

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.
Title: Re: Talking to a USB nRF24L01
Post by: m_bear on Jul 07, 2016, 01:50 pm
@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.
Title: Re: Talking to a USB nRF24L01
Post by: jremington on Jul 07, 2016, 03:59 pm
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.
Title: Re: Talking to a USB nRF24L01
Post by: Southpark on Jul 21, 2016, 04:07 am
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.

Code: [Select]

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)




(http://forum.arduino.cc/index.php?action=dlattach;topic=410574.0;attach=174572)
Title: Re: Talking to a USB nRF24L01
Post by: jremington on Jul 21, 2016, 04:51 pm
@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?):
Quote
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?
Title: Re: Talking to a USB nRF24L01
Post by: Southpark on Jul 21, 2016, 09:44 pm
@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!
Title: Re: Talking to a USB nRF24L01
Post by: atreyu_inthebog on Jul 26, 2016, 12:02 am
Hey all,

I've been doing a lot of research on this combination. First of all, it should work as expected, plug in the nrf into the usb debugger and if your addresses are set up properly they should talk. I've only done cursory tests in communication between two of these as I've focused more on actually configuring and developing for the board itself. Check out my terminal application on github, see below. The one for Windows works fine, but Linux has issues so I'd avoid it at the moment.

https://github.com/neptunedockyard/CH340_interface/

So basically the device uses a CH340T usb to uart converter. The CH340T feeds the commands into an STC11L04E microcontroller, which converts the uart commands to SPI. I've looked all over the web for any hint of firmware or sources and found crappy demos or garbled text. I believe when you look at those corrupted source files you're actually looking at extended ASCII for chinese characters, or something like that. Regardless, the actual code is there and should compile. The problem is that the code seems incomplete. I'm no expert at this but am and Electrical Engineer so have some experience with micros. The main code looks like it basically reads uart commands and converts them for spi to be used with the nrf module, however, there's no indication of interpreting AT commands. Where it makes the decision between incoming strings being AT commands or data to send, I have no idea. Maybe it's coded into the CH340T or its driver, but I have no idea how to determine that. The other option is that the STC code in the link provided on this page is not the actual firmware used by this STC chip.

The interesting thing about this usb device is that it's used by a lot of different devices. There are isp programmers using the CH340T and STC but probably with different firmware. So, at the moment I'm doing my best to find all the available sources for the firmware so I can do some hacking around. From a user point of view, the software I developed above is just a basic terminal application that connects over the serial COM port, with selectable baud rates. I've included some setting stuff where you can enter the RX and TX addresses, bitrate, and frequency. These just do the simple AT commands listed above, which you can do yourself. I've also seen the garbled text (show up as ? in my app) when doing AT? and have no idea what it is, I'm investigating. They seem to be actual text (look at it in HEX) that is reproducible so it's not random garbage or memory dumps. For fun I added a simple DES encryption scheme that encrypts your text when you send it (if you want it to) as well as username option so you can talk between each other (think offline IRC).

Anyway, enjoy. Hopefully I'll find more information and some source code, if I do I'll post it here for you all to mess with. Let me know what you think of my application and if it's any use to you or if it's the dumbest thing you've ever seen, all opinions are welcome.
Title: Re: Talking to a USB nRF24L01
Post by: jremington on Aug 01, 2016, 01:50 am
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.
Title: Re: Talking to a USB nRF24L01
Post by: Southpark on Aug 01, 2016, 07:35 am
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.
Title: Re: Talking to a USB nRF24L01
Post by: JuanchoM on Aug 05, 2016, 12:10 pm
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:

Code: [Select]

    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!
Title: Re: Talking to a USB nRF24L01
Post by: Southpark on Aug 08, 2016, 02:46 am
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)
Title: Re: Talking to a USB nRF24L01
Post by: JuanchoM on Sep 13, 2016, 07:49 am
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+:

Code: [Select]
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:

Code: [Select]
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.
Title: Re: Talking to a USB nRF24L01
Post by: Southpark on Sep 18, 2016, 10:35 pm
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...... (https://forum.mysensors.org/topic/4721/nrf-frequency-and-channels/5)

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..... (https://forum.mysensors.org/topic/4721/nrf-frequency-and-channels/5) 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);
Title: Re: Talking to a USB nRF24L01
Post by: Southpark on Sep 19, 2016, 06:07 pm
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.


(http://forum.arduino.cc/index.php?action=dlattach;topic=410574.0;attach=180904)

(http://forum.arduino.cc/index.php?action=dlattach;topic=410574.0;attach=180906)


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
Title: Re: Talking to a USB nRF24L01
Post by: Southpark on Sep 19, 2016, 06:11 pm
The settings used on the PC side nrf24L01+ are shown in this picture :

(https://forum.arduino.cc/index.php?action=dlattach;topic=410574.0;attach=180952)

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

(http://forum.arduino.cc/index.php?action=dlattach;topic=410574.0;attach=180936)

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.
Title: Re: Talking to a USB nRF24L01
Post by: Southpark on Sep 25, 2016, 07:11 pm
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) :
(http://forum.arduino.cc/index.php?action=dlattach;topic=410574.0;attach=181587)
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.

(http://forum.arduino.cc/index.php?action=dlattach;topic=410574.0;attach=181589)



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.
(http://forum.arduino.cc/index.php?action=dlattach;topic=410574.0;attach=181591)



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).
(http://forum.arduino.cc/index.php?action=dlattach;topic=410574.0;attach=181593)


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.
Title: Re: Talking to a USB nRF24L01
Post by: pidge on Sep 27, 2016, 04:19 am
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
Title: Re: Talking to a USB nRF24L01
Post by: Southpark on Sep 27, 2016, 05:16 am
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!
Title: Re: Talking to a USB nRF24L01
Post by: Southpark on Oct 02, 2016, 11:35 pm
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



Title: Re: Talking to a USB nRF24L01
Post by: Southpark on Oct 03, 2016, 12:21 am
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.
Title: Re: Talking to a USB nRF24L01
Post by: developandplay on Oct 04, 2016, 12:09 am
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:

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.
Title: Re: Talking to a USB nRF24L01
Post by: Southpark on Oct 06, 2016, 11:20 pm
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.
Title: Re: Talking to a USB nRF24L01
Post by: steronydh on Oct 07, 2016, 03:18 pm
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!
Title: Re: Talking to a USB nRF24L01
Post by: Southpark on Oct 07, 2016, 10:17 pm
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).
Title: Re: Talking to a USB nRF24L01
Post by: developandplay on Oct 15, 2016, 01:11 am
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:


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
Title: Re: Talking to a USB nRF24L01
Post by: Leah77 on Oct 16, 2016, 04:57 pm
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...



nrf board:  https://www.amazon.com/Makerfocus-Wireless-NRF24L01-Antistatic-Compatible/dp/B01IK78PQA/ref=cm_rdp_product (https://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 (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
Title: Re: Talking to a USB nRF24L01
Post by: developandplay on Oct 16, 2016, 08:00 pm
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:

->If that was not the case it might be a hardware problem...


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 ;)
Title: Re: Talking to a USB nRF24L01
Post by: Leah77 on Oct 17, 2016, 12:36 pm
> Your adapter can't handle two simultaneous connections!

True, haha.  I learned this lesson a while back when I first got into Arduino. I have double-checked to make sure that only a single terminal program is running and accessing the COM port of the USB dongle.

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

I tried that and I don't get any errors.  My guess is that the adapter is working in that it accepts data from the PC.  But without any loopback or receiver, I obviously won't get anything back.  If I plug the nrf back into the USB dongle, then I get the same error again.


> 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 only have the two that I ordered from Makerfocus, but I'll procure some other brands today to see how it goes.
Title: Re: Talking to a USB nRF24L01
Post by: Southpark on Oct 26, 2016, 05:40 am
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.

Thanks for getting back to me on that DAP! I tried tapping into the MCU with that software, but no signs of communications - such as pulling out mcu info etc.

I'd certainly be interested in your design files, as I'd learn a lot from building it and at least have some more control over the behaviour or performance of the transceiver.

I recently ordered a machine for doing some fine pcb milling, so I would try your design in future. All the best with your thesis writing.
Title: Re: Talking to a USB nRF24L01
Post by: infinityab on Dec 01, 2016, 01:20 am
I'm not sure if this is useful now but at least the info is all in one place, I found an English explanation from a Chinese seller who seems to know what he's talking about  -

# Arduino driver for nRF24L01 2.4GHz Wireless Transceiver

Description:
USB wireless serial data transmission module, support AT commands
With a stable CH340T do USB to serial
Built-in anti-crash watchdog procedures, under the harsh environment of industrial control occasions.
With this module you can do wireless serial transmission distance farther (100 ~ 1100m, depending on the use of the wireless module), far higher than Bluetooth (10m) serial transmission distance
Parameters and commands:

1. The number of bytes in a single transmission valid: 1-31 bytes.
The first 0 byte system reserved for each transmitted packet length statistics; for example serial port to send "123" (ASCII code, 3 bytes), the actual transfer when the first byte 0 to 3, the receiving end of the actual should be handled to determine the packet length byte received under this number.

2. Module Baud Rate: 4800,9600,14400,19200,38400,57600,115200.
Covers common baud rate, (factory default 9600)
Baud rate modification command: send ASCII code [AT + BAUD = x] (x is 1,2,3,4,5,6,7 4800,9600,14400,19200,38400,115200 the corresponding baud)
Such as: Modify the baud rate to 115200, the serial debugging assistant sending ASCII [AT + BAUD = 7], the system replies:
Baud rate setting success !!
Baud Rate: 115200
At this baud rate of 115200, serial debugging assistant need to switch to 115 200 to communicate with the module.
Note: The command must be in uppercase letters!

3.NRF24L01 module transmission rate: 1Mbps, 2Mbps (factory default 1Mbps)
Transmission rate setting command: send ASCII code [AT + RATE = x] (x 1,2 respectively 1Mbps, the transmission rate of 2Mbps)
Such as: modify the transmission rate of 2Mbps, then sending ASCII serial debugging assistant [AT + RATE = 2], the system replies:
Transmission rate setting success !!
Transmit power: 0dBm
Transfer rate: 2Mbps
Low-noise amplifier gain: open

4, NRF24L01 module address setting: 5 address, local address and the receiver address matches 0 (factory default 0xFF, 0xFF, 0xFF, 0xFF, 0xFF)
Address Set command: Send ASCII code [AT + ADD = 0x ??, 0x ??, 0x ??, 0x ??, 0x ??] (0x ?? address you want to set a comma, the comma must be in English half-width )
Such as: change the address for 0x11,0x22,0x33,0x44,0x55, then sending ASCII serial debugging assistant [AT + ADD = 0x11,0x22,0x33,0x44,0x55], the system replies:
Address Setting Success !!
Local Address: 0x11,0x22,0x33,0x44,0x55
Receiving end address 0: 0x11,0x22,0x33,0x44,0x55

5, System Information inquiry:
Query: sending ASCII [AT?], The system replies:
AT?
System Information:
Baud Rate: 115200
Local Address: 0x11,0x22,0x33,0x44,0x55
Receiving end address 0: 0x11,0x22,0x33,0x44,0x55
Transmit power: 0dBm
Transfer rate: 2Mbps
Low-noise amplifier gain: open

 ....................................................................


I thought a pair of these might be useful for using with quasi pro-weather stations which have a USB output to PC connection used to chart the data and to upload to the wunderground.com weather website. The idea being to allow the flashy Weatherstation unit to be placed anywhere within the house and communicate to the PC somewhere else. Not sure about the CH340 interface though, may have to have a Nano or something on the WS side and power of course - tests will tell.
Title: Re: Talking to a USB nRF24L01
Post by: VladimirM on Jan 13, 2017, 08:03 pm
NRF24l01p are great little ships. I managed to send data with it at almost 200m. But strangely did not see any big difference in range when using advanced version with PA+LNA on board..

When working with it from Serial port connection, it is useful to use some more advances RS232 serial terminal program such as http://docklight.de/  to be able to read and send binary formatted data (not only ascii) since amount of data per package is very limited.
Title: Re: Talking to a USB nRF24L01
Post by: developandplay on Jan 16, 2017, 11:17 pm
Hi Southpark
I gave the final presentation on my thesis today. It went really well.
Now that this last step is completed I can upload the schematics and board layout. I hope that you can still make some use out of it. In my opinion trying to reverse engineer the adapter wasn't worth it.

Here are the files:
https://drive.google.com/open?id=0B_xNPJq9f4HSZUg3TEFVNDlvZWM

Servus
developandplay
Title: Re: Talking to a USB nRF24L01
Post by: Southpark on Jan 16, 2017, 11:48 pm
Hi Southpark
I gave the final presentation on my thesis today. It went really well.
Now that this last step is completed I can upload the schematics and board layout. I hope that you can still make some use out of it. In my opinion trying to reverse engineer the adapter wasn't worth it.

Here are the files:
https://drive.google.com/open?id=0B_xNPJq9f4HSZUg3TEFVNDlvZWM

Servus
developandplay
Thanks D.A.P ! Great to hear that your presentation went well. And thanks for uploading the files.

I reckon that your reverse engineering of the adapter could indeed come in handy in the future, either for you, or for somebody. I reckon I'll learn a lot from your schematics and design, and will be able to use it as well. Sometimes, spending effort in doing something like this could have so-far unforeseen benefits in the future. It could become an advantage in some way. For example, what you learned out of it might help for something later. But it looks like your electronic skills are right up there, which is excellent. Nice work!

Good luck, thanks, and all the best!
Title: Re: Talking to a USB nRF24L01
Post by: adruha on Mar 10, 2017, 03:49 pm
Hello everybody. The problem I have bought two modules USB nRF24L01. It works only one team AT ?.

In response to it, I get:

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

No more command does not work! What can I do like to change the configuration? I would be grateful for any help!
Title: Re: Talking to a USB nRF24L01
Post by: sakshi on May 23, 2017, 07:33 am
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) :
(http://forum.arduino.cc/index.php?action=dlattach;topic=410574.0;attach=181587)
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.

(http://forum.arduino.cc/index.php?action=dlattach;topic=410574.0;attach=181589)



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.
(http://forum.arduino.cc/index.php?action=dlattach;topic=410574.0;attach=181591)



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).
(http://forum.arduino.cc/index.php?action=dlattach;topic=410574.0;attach=181593)


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.
hey southpark, thanks a lov for vhe arduino code that you have attached, can you please give the other part  of the code i.e. the python one which is controlling the other side.

thanks in advance.
our help will be very valuable for my project
Title: Re: Talking to a USB nRF24L01
Post by: Southpark on May 28, 2017, 03:20 am
hey southpark, thanks a lov for vhe arduino code that you have attached, can you please give the other part  of the code i.e. the python one which is controlling the other side.

thanks in advance.
our help will be very valuable for my project
Hi sakshi.

Of course I can include the python script I used.

Here it is..... it's pretty short.

Below is the python script..... definitely works in python V3.0 and V3.5
Just change the 'com' port number to whichever your device is assigned to.

Code: [Select]

import _ctypes
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_NONE,
    stopbits=serial.STOPBITS_ONE,
    bytesize=serial.EIGHTBITS
)

ser.isOpen()

input = 1
while 1:
    # input = str(1)
    ser.write("abcdefghijklmnopqrstuvwxyz".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).decode()

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

Title: Re: Talking to a USB nRF24L01
Post by: wormuz on Aug 30, 2017, 12:48 pm
Only registered to thank you Southpark  :)
Title: Re: Talking to a USB nRF24L01
Post by: Southpark on Aug 31, 2017, 01:29 am


You're most welcome wormuz. Thanks for your message.