Talking to a USB nRF24L01

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.

First of all thank you Southpark. Based on your instructions I was able to connect the nrf24l01+ arduino combo to the nrf24l01+ to usb adapter. However in the current current firmware the payload size is fixed to 32 bytes. Having a smaller size would allow better stability of transmition whilst a bigger size would be more comfortable to use.
Therefore I tried to flash the firmware from that french ebay seller onto the adapter but I failed horribly at doing so. On my way to achieve my goal I reverse engineered the adapter. The only part I could not identify is the microcontroller that is used on the adapter.
Here is my current status:

  • -The microcontroller is not the stc11l04e as claimed by the french ebay seller. The adapter does not have an external crystal that one would need to use the stc11l04e. Scanning datasheets of microcontrollers by the same manufacturer(stc) I found out that the microcontroller could be one their current stc15 series. Except from the upper mentionded missing crystal my reasons to assume this are:

  • -the Ground and Vcc pins are located on the bottom left and are exactly one pin apart

  • -RX and TX are located on the bottom right

However using their own stc-isp tool I did not manage to flash the firmware on to the microcontroller let alone identify them. So they might be from an entirely different manufacturer.

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

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

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

developandplay:
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.

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!

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

Sorry Southpark for not responding for over a week.

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

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

Now to your questions Southpark:

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

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

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

I have purchased similar hardware (nrf and USB dongle) with hopes of getting a PC-to-Android wireless system going.

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

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

This error occurs...

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

nrf board: 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

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

Servus Leah77
To me what you are describing sounds either like a simple software problem or a power delivery problem.
I would do the following steps:

  • "Serial Port acces denied errors" are usually a result of opening more than one terminal window. So make sure you are just trying to connect from one terminal window. Your adapter can't handle two simultaneous connections!
    ->If that was not the case it might be a hardware problem...
  • Go to the device manager. Watch what happens when you connect the usb adapter on its own. Follow the next step while your adapter is plugged into your PC! Plug the nrf24l01+ module into your adapter and check whether something changes.
  • What exactly happens when you access the adapter from your Serial Terminal? Does the adapter respond to any commands when the nrf24l01+ is unplugged? (My adapter doesn't but they might be different...)
  • Try the adapter with the low power version of the nrf24l01+ module. For me the amplified version worked well but that doesn't guarantee that yours will as well. The modules seem to be hit or miss since even some of my low power ones don't work with the adapter.

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

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.

developandplay:
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.

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.

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.

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:

Servus
developandplay

developandplay:
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!

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!

Southpark:
Hi folks!

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

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

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


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

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

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

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

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

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

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

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

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

sakshi:
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.

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)

Only registered to thank you Southpark :slight_smile:

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