Recently, I bought some FTDI breakout boards as USB to serial converter. At first, everything works, but later after a driver update, nothing works any more. After a little bit search, it turns out the chips are actually fake chips (f..k)!
I don’t want to throw away the chips just as that (meanwhile, I’ve placed another order from another seller, let’s cross fingers), so I did a little bit search and then come across this post:
Update for a fake cable
However, the procedure is much simpler:
1. Download the driver from FTDI official website
2. Change the PID in the two INF files to the one you see in the Hardware Properties of the fake chip when connected to the PC
3. Turn off the “Driver Signature Validation” on Windows, restart, install the driver from device manager. And then it’s working as before.
(Sorry, FTDI, I didn’t expect they also make fake copies of the chip which is already at a low price.)
Now the communication is more or less okay.
With ACK with Payload, two way communication can be done without change the role of PRX and PTX.
BUT: with send ACK with Payload length >= 18 bytes. the PRX won’t be able to receive anything. I’m not sure whether it’s a problem in Arduino+NRF24L01(PTX)
or the STM32+NRF24L01(PRX).
31/03/2014: The problem turns out to be with the Arduino Mega board I’m using, when I use Serial.print to print the ACK package out with baudrate == 115200, arduino will halt after a while. I don’t know what’s the cause of this behavior. I decreased the baudrate to 57600 and reduce the data to be printed out, I can receive ACK package with payload length up to 32 bytes. However, I need to test what will happen when the distance increases. Anyway, next step is to design the two-way protocol.
And as for performance, I’m using interrupt on Arduino, but still I need to wait at least 8ms before sending another packet, so that I’m not quite sure this way is much better than the PRX-TX-switch-role solution.
I will try to implement the switch role solution and compare to see the exact results. I’m okay with the performance of the ACK-WITH-PAYLOAD now, I don’t want to spend extract time for implement approach (for now). (Maybe I will try with pcDuino).
01/04/2014: Arduino+nRF24L01 + STM32
The first past for Arduino to retrieve MPU6050 data from STM32 is done.
The step for Dynamic Payload for nRF24L01+ module has finished. The communication is done with STM32 and a C51 board. The Dynamic Payload length varies from 1 to 32.
There are still some glitches in the code (could be the UART I’m using now for debugging).
Next step, ACK package with Payload (tried, but not working, could be problem in C51 board, however, the flow for sending ACK with payload is not clear at STM32 end neither).
It’s been a long time since I worked on this.
As recently I got two new USB2Serial converter plus an Android Uno acting like a USB2Serial Converter also (this can be done by connecting RST to GND [credits by someone else on the web, can’t find the source now]), besides I also have two C51 (STC12XXX) boards with working example for nRF24L01, I’m at a good position to start working on nRF24L01 with STM32 board now.
And today, since the example code of the C51 board for nRF24L01 is only for fixed-size payload communication, I’m able to do point to point communication with fixed-size payload using nRF24L01+ on STM32.
The next step would be change the code running on C51 and STM32 to use Dynamic Payload size.
[Previous problem causing nRF24L01+ not working with STM32 is that I made a typo mistake using a wrong register name macro in one of the helper functions]
[The code style is not so good: a lot of registers => a lot of register macro definition (register name, bits in the register, mask etc.). I’m wondering if there’s a better way to do this]
I’m using the HMC10 bluetooth with UART interface along with my STM32F103 board. Now I’m trying to make it work with interrupt mode, however, as there’s another sensor MPU6050 taking up a lot of CPU time to read/write I2C interface to get YawPitchRoll data also using interrupt, the UART interrupt can not reach a high data rate. So I need to change it to DMA mode, which I have no idea to make it work right now. I will figure it out tomorrow.