# RF modules which can handle high number of bytes per second

#### Vizier87

##### Active Member
Hi guys.

I'm wondering if there are better RF modules than Xbee, which can handle say 4 kbps (that's BYTES, not bits) data?

The current Xbee Pro I'm working on have some issues with missing data when I'm dealing at high transfer rates.

Even at 10 milliseconds delay per byte transmission, I don't get all of the data.

Thanks!
Vizier87

#### Nigel Goodwin

##### Super Moderator
Faster data means higher bandwidth, which means shorter range - how about using WiFi modules?.

#### Vizier87

##### Active Member
Faster data means higher bandwidth, which means shorter range - how about using WiFi modules?.
I do have the Wi-Fi variant of the Xbee (S6).. but I was having problems using it so I stopped. It had a completely different XCTU interface and guess what.. the support has ended!

Now that you mention it.. I guess I'll have to give it a try!

Vizier87

#### rjenkinsgb

##### Well-Known Member
The XBee Pro is supposedly rated for up to 200Kbit/sec; that's 20,000 bytes/sec (less overheads), so rather above the 4K Bytes/sec??

What's the range, what antennas are you using, is it bidirectional and what type of encoding or protocol are you using?

Also, how good and stable is the power supply to the RF module? The current varies tremendously between transmit and receive.

#### kubeek

##### Well-Known Member
4 kbps (that's BYTES, not bits)
nope, 4 kbps is 4 kilobits per second. 4 kBps is 4 kilobytes per second.

#### Vizier87

##### Active Member
nope, 4 kbps is 4 kilobits per second. 4 kBps is 4 kilobytes per second.
Thanks, I stand corrected.

Nevertheless, I mean as you mentioned, kBps.

#### Vizier87

##### Active Member
The XBee Pro is supposedly rated for up to 200Kbit/sec; that's 20,000 bytes/sec (less overheads), so rather above the 4K Bytes/sec??

What's the range, what antennas are you using, is it bidirectional and what type of encoding or protocol are you using?

Also, how good and stable is the power supply to the RF module? The current varies tremendously between transmit and receive.
Well it has this stubbly antenna but no coaxial socket.

Not bidirectional, I'm just receiving data. The protocol is just a simple UART.

But yikes! I discovered that the Xbee pulls 220 mA when the Tx pin is active! No wonder the regulator was heating up. Luckily nothing's damaged...

Ok I'm gonna have to rethink my setup and test with a separate power supply. Thanks for the input!

Vizier87

#### For The Popcorn

##### Active Member
I'm using an ESP8266 or ESP32 to get 230,400 baud over a Telnet link, with the ESP set up as an AP (Access Point).

I want to crank it up to 480,800 baud (where I lose a few characters in a transmission of about 40k characters) or even 921,600 baud. My current thinking is to use hardware handshaking between the serial source and ESP32; it seems to be a doable thing, but I haven't found concise instructions on setting it up so far.

#### For The Popcorn

##### Active Member
I'm using an ESP8266 or ESP32 to get 230,400 baud over a Telnet link, with the ESP set up as an AP (Access Point).

I want to crank it up to 480,800 baud (where I lose a few characters in a transmission of about 40k characters) or even 921,600 baud. My current thinking is to use hardware handshaking between the serial source and ESP32; it seems to be a doable thing, but I haven't found concise instructions on setting it up so far.
I have tested with both hardware (RTS/CTS) and software (XON/XOFF) to feed serial data to an ESP32, and then sent by Telnet (TCP/IP) via WiFi. I have 100% reliable data transfer at 921,600 baud (I haven't tried to go faster, as the source of the data can't go faster).

I was somewhat surprised that software handshaking has less overhead than hardware handshaking.

#### Vizier87

##### Active Member
I have tested with both hardware (RTS/CTS) and software (XON/XOFF) to feed serial data to an ESP32, and then sent by Telnet (TCP/IP) via WiFi. I have 100% reliable data transfer at 921,600 baud (I haven't tried to go faster, as the source of the data can't go faster).

I was somewhat surprised that software handshaking has less overhead than hardware handshaking.
I'm just recently getting more news about the ESP32. Thanks, will have a look into it.

Edit: Do you know any ESP32-based modules that can be tied to the UART of a different microcontroller? Because the ones I see are already integrated with a NodeMCU and whatsits.

Last edited:

#### For The Popcorn

##### Active Member
The ESP32 NodeMCU have two accessible UARTs. I'm using the normal USB UART for monitoring and setup (using a terminal emulator) and UART2 to interface to the serial port on a high speed data logger. It works great!

Hardware and software handshaking is actually very easy to implement but it's a pain in the back side to find any good references.

#### Vizier87

##### Active Member
The ESP32 NodeMCU have two accessible UARTs. I'm using the normal USB UART for monitoring and setup (using a terminal emulator) and UART2 to interface to the serial port on a high speed data logger. It works great!

Hardware and software handshaking is actually very easy to implement but it's a pain in the back side to find any good references.
So does this mean I can directly hook up my other microcontroller's Tx output and bypass the NodeMCU?

I'm ordering the LoLin v3... in a few days I'll check in here to update.

#### For The Popcorn

##### Active Member
No. The NodeMCU provides the WiFi link.

#### Vizier87

##### Active Member
Okay I've got my NodeMCU and making preparations to receive data.

The ESP32 NodeMCU have two accessible UARTs. I'm using the normal USB UART for monitoring and setup (using a terminal emulator) and UART2 to interface to the serial port on a high speed data logger. It works great!

Hardware and software handshaking is actually very easy to implement but it's a pain in the back side to find any good references.

May I have some of the pain-in-the-ass-to-get references of yours?

My aim is just to stream data from the ESP (I think I'll just loop 1's and 255's through UART or something) so that it can be read from the PC's COM Port, if possible. Or any way which you might suggest?

Thanks!

#### For The Popcorn

##### Active Member
Oops. Sorry I missed this last night. I'll post the info later today.

#### Vizier87

##### Active Member
Oops. Sorry I missed this last night. I'll post the info later today.

Thanks.

#### For The Popcorn

##### Active Member
I'll post info later tonight. Today I met with the client for "show and tell". He was suitably impressed Of course there was plenty to do at the last minute, and the "just a few simple things" to do never are!

#### For The Popcorn

##### Active Member
Here are my notes. Hope this will save you some effort locating info. The reference below explains things in some detail. Turns out serial handshaking is pretty easy to implement.

At 921,600 baud, I can reliably send about 36,000 characters in around 1.5 seconds via Telnet without errors. Some groups may take up to about 4 seconds. This happens if Telnet (TCP/IP) has a missed packet and requires retransmission. But no data is lost thanks to the serial handshaking.

Code:
#define RXD2 16         //define Serial2 pins.  These are the standard pins for UART2
#define TXD2 17

#include "driver/uart.h"      //Need this for hardware or software handshaking

Serial.begin(115200);       //Standard serial port - USB via UART-USB chip.
//Very handy for monitoring activity

Serial2.begin(BaudRate, SERIAL_8N1, RXD2, TXD2);      //Do this prior to the following

//ref: https://github.com/espressif/arduino-esp32/issues/6185  <--- reference

//Setting hardware flow control must go after the Serial.begin statement
//add #include "driver/uart.h" at program start

uart_set_pin(UART_NUM_2, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE, 22, 21);
//I used the I2C pins for hardware handshaking as I had connectors on the board for them.

//uart_set_hw_flow_ctrl(UART_NUM_2, UART_HW_FLOWCTRL_RTS, 64);
//^^^ for hardware RTS/CTS handshaking.  64 is buffer size.

uart_set_sw_flow_ctrl(UART_NUM_2, true, 64, 96);
//^^^ for Xon/Xoff software handshaking.  64 and 96 are points in the buffer to say
//          enough, stop sending, ok, send more.  See the reference about.

#### Vizier87

##### Active Member
Here are my notes. Hope this will save you some effort locating info. The reference below explains things in some detail. Turns out serial handshaking is pretty easy to implement.

At 921,600 baud, I can reliably send about 36,000 characters in around 1.5 seconds via Telnet without errors. Some groups may take up to about 4 seconds. This happens if Telnet (TCP/IP) has a missed packet and requires retransmission. But no data is lost thanks to the serial handshaking.

Code:
#define RXD2 16         //define Serial2 pins.  These are the standard pins for UART2
#define TXD2 17

#include "driver/uart.h"      //Need this for hardware or software handshaking

Serial.begin(115200);       //Standard serial port - USB via UART-USB chip.
//Very handy for monitoring activity

Serial2.begin(BaudRate, SERIAL_8N1, RXD2, TXD2);      //Do this prior to the following

//ref: https://github.com/espressif/arduino-esp32/issues/6185  <--- reference

//Setting hardware flow control must go after the Serial.begin statement
//add #include "driver/uart.h" at program start

uart_set_pin(UART_NUM_2, UART_PIN_NO_CHANGE, UART_PIN_NO_CHANGE, 22, 21);
//I used the I2C pins for hardware handshaking as I had connectors on the board for them.

//uart_set_hw_flow_ctrl(UART_NUM_2, UART_HW_FLOWCTRL_RTS, 64);
//^^^ for hardware RTS/CTS handshaking.  64 is buffer size.

uart_set_sw_flow_ctrl(UART_NUM_2, true, 64, 96);
//^^^ for Xon/Xoff software handshaking.  64 and 96 are points in the buffer to say
//          enough, stop sending, ok, send more.  See the reference about.

Ah many thanks for this. I'm digesting and retrofitting the code now.

Replies
1
Views
13K
Replies
8
Views
1K
Replies
3
Views
872
Replies
7
Views
3K
Replies
21
Views
2K