If you are asking a question, please follow this template:
My goal is: [determine hardware and software limitation]
My actions are:
[Hardware : ESP8266 (Fanstel BWG832FX)
Hardware : nRF52 connect UART to ESP8266
Software : Mongoose build using MQTT
Server : [Eclipse Mosquitto in local Laptop ]
The result I see is: [Using the nRF52 to send data (40 bytes) in UART every 140ms and this packet would then do MQTT.publish in ESP8266. After a few packet is sent, ESP will show “MQTT FIFO overflow” error. If changed the timing from 140ms to 180ms, then FIFO error disappear]
My expectation & question is: [Will this be the limitation of this configuration ESP8266 + Mongoose ?? My hope for the project is sending BLE data (20bytes) packet at 20ms sampling rate from BLE sensors.
Is the limitation inside ESP8266 chip or configuration for Mongoose ??]
This is not a pipe nor an X.25 PAD, MQTT was not designed for taking constant speed serial in but to decouple complex systems by using the publish-subscribe design paradigm.
One possibility here is to buffer several samples in order to maximize packet length to protocol overhead and minimize latency by doing only so many MQTT transactions: get 1K serial data and send 1 1K MQTT message, it takes very similar time to send a 1-byte MQTT message than a 1K-byte message because usually the handshake dominates the transaction time. BTW, you can try QoS=0 to just fire a message and hope, that will have more throughput if you can spare msgs lost.
Other is to process data and send only differences or important changes every now and then (I guess there is an underlying application besides “sending UART data”).
Eventually you will get in trouble and intermediate queues will mitigate that, but yes, it may eventually overflow because it was not designed to have a sustained throughput. Ever wonder no one sends voice nor music nor video over MQTT ?
If you need constant throughput you need to design that from the ground up and MQTT is not for that.
There are no hardware nor software limitations here, you need to understand what you are trying to do and learn how to properly do it.
On a related issue. Do you know how I could optimize when UART.setDispatcher is called ?
I try not enable WiFi router, so ESP is not connected.
The ProcessUartData() would just reply a [ACK] packet in UART.
I place a timer measurement and it takes 70ms to response. Any way I can change the Dispatcher to return per byte for quicker response ?
You seem to be trying to do something funky.
Usually one does not want to work that way. The UART buffer is there to decouple your application from the serial nuances, you get a fair amount of data and then process it in chunks, the bigger the chunk usually the more efficient you are, but that depends on what you are doing.
The dispatcher is usually triggered by a buffer full or enough time without data (or room for transmission), you can toy with that by observing the driver code, iirc the “lingering” time might help, but these systems are not for time sensitive serial operation, usually you process a frame which is delimited by a particular data value or carries a frame length indication; you sync to the stream first and then process data in frames.
Not too funky.
“usually you process a frame which is delimited by a particular data value or carries a frame length indication; you sync to the stream first and then process data in frames.”
This is what I want to change.
Where I can locate this code and make changes & rebuild online ?
Since I am new Mongoose, any link to info be excellent help.
I have written a C function to process UART data from JS and able to response within 15ms on received packet (40 bytes) compare to 70ms using JS to process data. Which is Good start.
However, when packet size increased to 90 bytes, the receiving packet is corrupted.
I have defined
UART.setConfig(uartNo,
{
baudRate: 115200,
rxBufSize: 256,
}