RF modules which can handle high number of bytes per second

[Vizier87]

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

 

[For The Popcorn]

Interestingly, software handshaking results in maybe 20% faster transmission than hardware handshaking. Opposite of what I expected.

 

[For The Popcorn]

Here's my test setup. A long time ago, I had made some ESP32–display boards. I came across them, and with connectors for UART2 and I2C, it was perfect for this. One of the ESP32s sends out sample data (for testing) and the other transmits UART data by Telnet.

 

[For The Popcorn]

Re-reading some of the comments, I'm not sure we're quite on the same page. Just to be sure.....

I am taking serial data from a data logger and sending it to an ESP32 NodeMCU. The ESP32 sets up a WiFi access point, and sends the serial data via Telnet to a Telnet client running on a laptop or phone connected to the access point. See the pdf.

 

[Vizier87]

Oh dear. In my case it is actually much simpler. It's okay, I'm going through the tutorials for now.

And from your description, both the ESP8266 and the PC which receives the data have to be connected to the AP, am I correct?

Seems like there are many protocols we can use. Do you know if there are preferable ways other than Telnet? Because I'm seeing a lot of examples using UDP too.

 

[For The Popcorn]

The "WiFi link" ESP32 in my case is the AP (Access Point) because these data loggers are located in the middle of nowhere where there are no networks to connect to. It does not have to be an AP, but it and the receiving laptop must be connected to the same network.

These are very explicitly ESP32s, not ESP8266s. Several reasons for this:

1. ESP32s have two available UARTS. You can use one to transmit data, and the other for monioring/setup. On an ESP8266, you can SWAP the UART connections from the UART-USB converter to port pins, but then monitoring/setup is difficult. Just trust me on this.

2. ESP32 supports hardware/software handshaking. I don't believe the ESP8266 does. Handshaking is required for reliable data transmission.

3. The ESP32 has true EEPROM, which for me was easier to use to save setup parameters.


On the subject of UDP vs Telnet, it depends on your needs. My understanding, which may be lacking, is that UDP sends out messages "Here is some data if anybody wants it" without concern if a particular device received it. Telnet sends data to a specific device "here is the data, tell me when you've got it or I'll send it again." Telnet handles all the retransmission/error correcting automatically without any action on your part.


Did I do this the best way? Probably not. Did I accomplish my goals? Yep. At any rate, here's some details on implementing UART flow control, which were elusive.

 

[tumbleweed]

is that UDP sends out messages "Here is some data if anybody wants it" without concern if a particular device received it.

I think you're talking about a UDP broadcast packet there... you can send UDP packets to a single IP address too.

The main difference between UDP and TCP is that UDP is connection-less... when you send out packets they just go out (hopefully) and you don't get any sort of response as to if the packet was actually received by anybody, so it's up to you to implement some higher-level code if that's important.

TCP has the higher-level stuff for acks, timeouts, resends, etc. to "guarantee" delivery. Telnet typically runs on top of TCP.