search

vshymanskyy / TinyGSM

A small Arduino library for GSM modules, that just works
GNU Lesser General Public License v3.0
1.91k stars 708 forks source link

Help me with the issue with SIM800l MQTT and Water Flow Sensor. #716

Open Squirrelbd opened 1 year ago

Squirrelbd commented 1 year ago

I have read the Troubleshooting section of ReadMe. And made sure that the connection is ok and also mqtt data communication is ok. I am facing issues with SIM800l and Waterflow sensor garbage data. I need help with the following issue:

I am using ESP32, SIM800l, and YF-S401. The idea is to send water consumption data through mqtt protocol using sim800l. Without the sim module, I am getting almost accurate data, but suddenly getting random consumption values if the gsm module is connected. Is there any interconnection between the hardware serial and digitalPinToInterrupt process? By the way, I am also using the water flow sensor library mentioned below: https://github.com/hafidhh/FlowSensor-Arduino

droidblastnz commented 1 year ago

How are you powering the ESP32, SIM800l, and YF-S401? Keep the ESP32 and SIM800l separated physically. Assume MQTT works over wireless without GSM enabled? What does the MQTT responses looking in the serial console?

I using a all in one board and was given the following advice.

Most of the interference issues appear on 2G boards, due to their 2W TX power. You might remember the click-click noises early cell phones induced into nearby audio equipment. LTE uses maximum 23dBm (200mW), so interference is much less common (but not impossible, especially if the board is badly routed, which is not uncommon on cheap boards). You can only change TX power on 2G, 4G has fully automatic power control that you can’t change. What you can do is reduce the baud rate to the modem. By slowing it down, interference induced errors will be less common.

There’s still the possibility that this is due to some buffer overrun or un-terminated string bug in the MQTT implementation. To rule this out, redirect the modem output (from the modem UART) to the debug console directly, bypassing the MQTT entirely, and see if there are strange chars appearing there too. If yes, it’s interference. If not, it’s a software bug.

Hope it helps.