Go Down

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

m_bear

Jul 03, 2016, 09:58 am Last Edit: Jul 03, 2016, 12:59 pm by m_bear
Hi guys,

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

eBay
DealExtreme
AliExpress

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

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

Has anyone had luck getting this working?

Any pointers for getting started?


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

Thanks :)



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.

jremington

#1
Jul 05, 2016, 03:31 am Last Edit: Jul 05, 2016, 03:37 am by jremington
I've never heard of a NRF24L01 that will respond to RS232-type serial commands and a few attempts with Google couldn't find any examples.

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

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

MarkT

It _won't_ work from serial, the nRF24 needs a microcontroller to drive it directly via SPI and possible an interrupt line too.
[ I will NOT respond to personal messages, I WILL delete them, use the forum please ]

Southpark

#3
Jul 07, 2016, 09:16 am Last Edit: Jul 07, 2016, 09:52 am by Southpark
Check this out ...... click here

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

m_bear

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

jremington

#5
Jul 07, 2016, 03:59 pm Last Edit: Jul 07, 2016, 04:00 pm by jremington
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.

Southpark

#6
Jul 21, 2016, 04:07 am Last Edit: Jul 21, 2016, 07:48 am by Southpark
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)





jremington

#7
Jul 21, 2016, 04:51 pm Last Edit: Jul 21, 2016, 05:15 pm by jremington
@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?

Southpark

#8
Jul 21, 2016, 09:44 pm Last Edit: Sep 27, 2016, 05:27 am by Southpark
@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!

atreyu_inthebog

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.

jremington

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.

Southpark

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.

JuanchoM

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!

Southpark

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)

JuanchoM

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.

Go Up