Go Down

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

Leah77

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

Southpark

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.

infinityab

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.

VladimirM

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.

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

Southpark

#35
Jan 16, 2017, 11:48 pm Last Edit: Jan 17, 2017, 08:07 am by Southpark
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!

adruha

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!

sakshi

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

Southpark

#38
May 28, 2017, 03:20 am Last Edit: Jun 09, 2017, 09:53 pm by Southpark
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)


Go Up