We setup a TCP Server, waiting for a message, receive a message, close the connection. Open a TCP Client, send a message, close the connection. Every 5 minutes this sequence will loop.
Every once in a while, once or twice a day, we do not receive a message when in TCP Server. The only solution to receive a message again is to reboot the BG77.
We have integrated the ‘Jamming’ functionality into the code, but we have not seen any jamming. Therefore, it is impossible for us to know when the module is not functioning.
We use buffer access-mode for the TCP server, there is no +QUIRC: recv message when we expect there to be one.
The Client sent the data successfully, but we did not receive anything. I have monitored the UART lines and there is no data received. I do not see a +quirc: recv .
Right now I integrated a ping feature in my state machine to check if something is wrong.
I have received the DFOTA files from your colleagues. But it does not solve the issue. I still occasionally not receive a +qiurc message. This happens every now and then. Rebooting the module solves it most of the time, but in that case I have missed a message.
BTW: A too weak power supply can cause this effects. (I’ve seen similar issues in the past with all kind of modems which went away with a proper power supply.)
Have you double-checked the layout of your PCBA? Is the power supply strong enough and the traces wide enough to deliver the necessary current?
According to the BG77 Hardware Design document a power supply which can deliver 700 mA or more is recommended.
The PSU is capable of delivering 1A continuously. The 3V3 is a complete copper plane. So the voltage drop is unlikely over there. The wires after the Ferrite Bead are really short and not longer than 5mm and around 0.6mm wide.
I have added an extra 10000uF capacitor to this 3V3 line near the BG77. This didn’t change anything.
I have measured the voltage and it dropped a maximum of 0.2VDC. So the voltage was 3.1VDC at minimum. Which is significantly higher than the 2.8VDC stated in the Hardware Design document.
I have measured it again and came to the conclusion that I’ve measured noise instead of an actual signal. So the voltage drop is so insignificant that it is unnoticeable.
After some extensive testing, I came to the conclusion that a reboot is required to regain full functionality.
Furthermore, when executing a AT+QISTATE it can occur that an +QIURC messages happens between my command and the response. Is there a way to give priority to the command and postpone the QIURC message?
In the past few days I ran some tests with setups similar to yours (server and client; server only) and I can confirm that after about 99 successful iterations my BG77 stops reporting reception of new data.
I can also confirm that when my BG77 is in that state only a reboot (power-cycle) or AT+CFUN=1,1 seems to get BG77 out of that state.
That said, I still have a test setup running, which recently surpassed about 1000 successful iterations. The setup is like yours with the difference that I started the local server once and keep it running instead of starting and stopping it for ever iteration. E.g.
start local server (if not already running)
wait for external client to connect
external client connects
external client sends data
local server read data
external client disconnects
local server disconnects as well
(leave local server running - do not stop local server)
local client connects to external server
local client sends data
local client disconnects
start over with step 1
Hope this helps.
Note: BG77 firmware used for testing: BG77LAR02A04_01.201.01.201
Admin note: I will probably hit the max number of posts to a given topic limit as a new user after this post - so I might not be able to respond any further for some time.
for me