BC68 - Reports NUESTATS:BLER,MAC DL BLER,33 and +CME ERROR: 4 after a while

I use a BC68, Revision:BC68JAR01A10.

That works quite reliable using PSM and exchanging every 2h a UDP message pair with my cloud-server. But then (this time after about 9 days / 220 h) it stops sending data and I see in my logs:

Last stats of successful exchange:

[2022-01-17 23:10:25] >AT+NUESTATS=BLER
[2022-01-17 23:10:25] res-1: ‘NUESTATS:BLER,RLC UL BLER,0’
[2022-01-17 23:10:25] res-3: ‘NUESTATS:BLER,RLC DL BLER,0’
[2022-01-17 23:10:25] res-5: ‘NUESTATS:BLER,MAC UL BLER,0’
[2022-01-17 23:10:25] res-7: ‘NUESTATS:BLER,MAC DL BLER,0’
[2022-01-17 23:10:25] res-9: ‘NUESTATS:BLER,Total TX bytes,3232’
[2022-01-17 23:10:25] res-11: ‘NUESTATS:BLER,Total RX bytes,10078’
[2022-01-17 23:10:25] res-13: ‘NUESTATS:BLER,Total TX blocks,74’
[2022-01-17 23:10:25] res-15: ‘NUESTATS:BLER,Total RX blocks,176’
[2022-01-17 23:10:25] res-17: ‘NUESTATS:BLER,Total RTX blocks,0’
[2022-01-17 23:10:25] res-19: ‘NUESTATS:BLER,Total ACK/NACK RX,2’

Then it stops sending messages:

[2022-01-18 01:10:20] >AT+NSOSTF=1,???,???,0x400,126,19FEFD0001000000000087373FC179E274006B000100000000008751AED9369B94775F1ADB77BDE967D75D77C3A8840E4FCEC1C7F4956E46543448653D234A46EB24F2D6A5869DF18687AA7ED41541F50E82F4CBED6B34DD96D975776FA4AFE483B737C15944A7B304E093835F28DBD8DF7E32C939621F98535568AB692A,138
[2022-01-18 01:10:20] res-1: ‘1,126’
[2022-01-18 01:10:20] res =>: OK
[2022-01-18 01:10:21] power saving: 0
[2022-01-18 01:10:22] network connection: 1
[2022-01-18 01:10:36] >AT+NQSOS?
[2022-01-18 01:10:36] res =>: OK
[2022-01-18 01:10:36] >AT+NSOSTF=1,???,???,0x400,126,19FEFD0001000000000088373FC179E274006B0001000000000088153FA008AB7E1687C560EDA43AC0096D1653D0196F0DDEE01F45521D5309BEC71F1A8B38EE688E247094C29BFBFCE0135C78E7EFAAF653D2A99F29C68393ADF451284419DAA74CF454AF29155306C52EFA9846E0DC0D66220C16D7B0CDE49200DD91E3,139
[2022-01-18 01:10:36] res =>: +CME ERROR: 4
[2022-01-18 01:10:43] network connection: 0
[2022-01-18 01:11:15] power saving: 1
[2022-01-18 01:12:06] >AT+NQSOS?
[2022-01-18 01:12:06] res =>: OK
[2022-01-18 01:12:06] >AT+CSQ
[2022-01-18 01:12:06] res-1: ‘+CSQ:7,99’
[2022-01-18 01:12:06] res =>: OK
[2022-01-18 01:12:06] >AT+NUESTATS=BLER
[2022-01-18 01:12:07] res-1: ‘NUESTATS:BLER,RLC UL BLER,0’
[2022-01-18 01:12:07] res-3: ‘NUESTATS:BLER,RLC DL BLER,0’
[2022-01-18 01:12:07] res-5: ‘NUESTATS:BLER,MAC UL BLER,0’
[2022-01-18 01:12:07] res-7: ‘NUESTATS:BLER,MAC DL BLER,33’
[2022-01-18 01:12:07] res-9: ‘NUESTATS:BLER,Total TX bytes,3752’
[2022-01-18 01:12:07] res-11: ‘NUESTATS:BLER,Total RX bytes,10218’
[2022-01-18 01:12:07] res-13: ‘NUESTATS:BLER,Total TX blocks,85’
[2022-01-18 01:12:07] res-15: ‘NUESTATS:BLER,Total RX blocks,185’
[2022-01-18 01:12:07] res-17: ‘NUESTATS:BLER,Total RTX blocks,0’
[2022-01-18 01:12:07] res-19: ‘NUESTATS:BLER,Total ACK/NACK RX,2’
[2022-01-18 01:12:07] res =>: OK
[2022-01-18 02:10:44] power saving: 0
[2022-01-18 02:10:45] network connection: 1
[2022-01-18 02:10:46] network connection: 0
[2022-01-18 02:11:18] power saving: 1
[2022-01-18 03:10:20] >AT+NQSOS?
[2022-01-18 03:10:20] res =>: OK

If I restart the modem, it works again.

What causes “NUESTATS:BLER,MAC DL BLER,33” and “+CME ERROR: 4”?
Is there a simpler/faster way to overcome that error then restart the modem?

Thanks in advance!

Is it easy for you to grab the log via Debug_Tx/Debug_Rx? I don’t think error4 caused the restart.

I’m not sure, if I’m able to grab the log.
Is there any guide tutorial, how to do so (without Windows PC :slight_smile: )?

I don’t think error4 caused the restart.

Obvious. I have restarted it by sending “AT+NRB” via my serial client.
Without that restart, it stucks in that “+CME ERROR: 4” for several hours and retries.

Log capture tool, please download:
Please capture logs through the Debug port

Without Windows PC :-).

So I guess, this is not possible. My current setup is a ubuntu raspberry pi and the issue occurs usually after a couple of days. With that, I would need to find a “Windows PC”, which then can run several days, hope your tool will also do.

I’m also not sure, what the outcome should be. I use a firmware version (BC68JAR01A10), which could not be updated by my self. At least, that’s what I got told.
In the end, if you fix the firmware, I will still be not able to apply that to my BC68JAR01A10 device, or?

According to your description, I am still not clear about your problem, so I need you to grab the Log for analysis

Sure, usually such logs are required.
But my question is: does that log capture tool run for several days?
If not, it is not only to get the captures, it’s also to make first that tool running.
My test setup exchanges every 2h a message pair (CoAP/DTLS CID), and switches to PSM.
So that itself should not cause problems when capturing. But I don’t know, what else may break a capture over a couple of days? Any experience with long time capturing? Any recommendations?
(I don’t want to spend a couple of a couple of days to find out, the capture tools can’t run for that long)

I managed to install UE Monitor on windows 10.

Unfortunately, it seem to use the same COM interfaces as my application would require to send AT cmd to the modem in order to execute the test.

If I use the other COM, I don’t see data in the UE monitor.
If I start the monitor with the right COM, I see data in the monitor, but my serial at-cmd client stops working.

(I use a BC68-DVK / BC68-TE-B)

Sorry, I mixed up the COMs.
In fact, my client doesn’t work proper on Windows 10. So, I’m currently only able to execute it on Linux.

Edit (again):
I remembered, that it takes an USB-driver for Windows. With that, my serial at-cmd-client works.
Using UE Monitor I get now “Access COM4 denied”.
The serial at-cmd-client is able to open COM4 (even it it’s the wrong for at-cmd).
The USB driver is from 8/17/2015 version 2.2.0. Is there a newer one?

Edit (again):
I updated the driver to 2.6.0 - same behavior. serial at-cmd-client works, UE Monitor complains about “Access COM4 denied”.

Does UE-Monitor work on Windows 10?
Is there a instruction manual for the UE Monitor and Windows 10 (other then the BC95-G&BC68_UEMonitor_User_Guide_V1.0, 2017-12-14, that’s the one I have)?

I think your understanding and use of BC68 is very professional,you are great.
1)UE-Monitor can work for win10 and win7;
2)UE-Monitor supports tracking logs for a long time;
3)Use DEBUG_RX, DEBUG_TX, GND pins, or DEBUG ports.

I don’t understand, what to do next.
On my Win 10, UE Monitor sticks in the error “Access COM4 denied”.
I can’t see your guidance to overcome that.

Let me try to sum up, what I use:
BC68 on a QuecTel DevKit BC68JATEB-KIT von Quectel | Entwicklung | NB-IoT | tekmodul
Firmware version BC68JAR01A10
I connect that via USB dual channel UART (XR21V1412) to a Win 10 PC.
According https://www.tekmodul.de/wp-content/uploads/2018/04/Quectel_BC68_TE-B_User_Guide_V1.1.pdf I installed the USB Driver 2.6.0 for that (without that USB driver, UE Monitor works, but not my serial at-cmd-client. With that USB driver, the UE Monitor stops working and reports “Access COM4 denied” and the serial at-cmd-client works).

So, what need to be done, that I can use the UE Monitor with that XR21V1412 driver (version 2.6.0, or 2.2.0) on a Windows 10 PC?

I recommend you directly weld the outgoing Debug_Tx, Debug_Rx, GND and then use TTL to connect the outgoing wire to the computer.

In other words, UE Monitor is not longer working with windows 10 and the USB driver.

OK, I give up. That “reset” once a couple of days is then less pain.

I’m sorry I couldn’t help you,but I think you are capable of solving the trouble, or a program restart is also a good solution

It’s OK for me. The BC68 is pretty old, so it’s not that important.
And I just don’t want to solder my BC68 DevKit.
What I would have liked to know in advance is, that the UE Monitor on Windows 10 requires to “hard adapt/solder” the DevKit, because the Toolchain (UE Monitor - USB XR21V1412 driver) is not working. With that, I would have saved some hours …