Question about AT+BTEN and AT+PAIR SET Command Behavior

mehmet

+A2DPSTAT=1
+AVRCPSTAT=1
+HFPSTAT=1
+SPPSTAT=1
+DEVMOD:SLAVE
+VER=FSC-BT1058,V2.1.0,20260603
+PROFILE=169
+DEVSTAT=3

AT+BTEN=0
<<
+DEVSTAT=1
OK
AT+BTEN=1
<<
+DEVSTAT=7
OK
AT+BTEN
<<
+BTEN=1
OK
AT+PAIR
<<
+PAIR=1
OK
AT+PAIR=0
<<
+DEVSTAT=1
OK
AT+PAIR=1
<<
+DEVSTAT=7
OK
AT+BTEN=1
<<
OK
AT+BTEN=1
Hi,
When these commands are used as GET commands (e.g. AT+BTEN or AT+PAIR), the module correctly returns the current status:

AT+BTEN
+BTEN=1
OK

AT+PAIR
+PAIR=1
OK

However, when they are used as SET commands, the module does not return +BTEN=<value> or +PAIR=<value>. Instead, it reports only the corresponding +DEVSTAT event, for example:

AT+BTEN=0
+DEVSTAT=1
OK

AT+BTEN=1
+DEVSTAT=7
OK

AT+PAIR=0
+DEVSTAT=1
OK

AT+PAIR=1
+DEVSTAT=7
OK

Is this the expected behavior? Should these SET commands report only the +DEVSTAT event, or should they also return the updated +BTEN=<value> / +PAIR=<value> status?
In addition, during our tests we observed another issue.
Sometimes, after sending a SET command such as AT+BTEN=1, the module returns only:
OK
without any +DEVSTAT event.
After checking the behavior, we found that although the module returns OK, the Bluetooth enable state has not actually changed. We have observed the same behavior with the AT+PAIR command.
This suggests that the OK response does not always indicate that the requested operation has been completed successfully.
We have attached several logic analyzer captures showing this behavior.
Could you please confirm whether this is expected behavior or if it may be a firmware issue?

FAE_Gavin

mehmet

The behavior of AT+BTEN=<value> and AT+PAIR=<value> is normal.
For SET commands, the module does not return +BTEN or +PAIR status. The actual status change is reported through the +DEVSTAT event.
The OK response only indicates that the command has been accepted by the module. It does not mean the operation has been completed.

Please use the +DEVSTAT event to confirm the actual Bluetooth status change.

Example:

AT+BTEN=1

OK
+DEVSTAT=7

The +DEVSTAT event should be treated as the final status confirmation.

mehmet

During our testing with the DB200 evaluation board, we observed an unexpected behavior related to the AT+BTEN status after powering the module off and on using the onboard ON/OFF button.

The test sequence and UART log are shown below:

+DEVMOD:SLAVE
+VER=FSC-BT1058,V2.1.0,20260603
+PROFILE=169
+DEVSTAT=3

AT+BTEN
<<
+BTEN=1
OK

(The module was powered off using the ON/OFF button on the DB200 board.)

+DEVSTAT=0

(The module was powered on again using the ON/OFF button.)

+A2DPSTAT=1
+AVRCPSTAT=1
+HFPSTAT=1
+SPPSTAT=1
+DEVMOD:SLAVE
+VER=FSC-BT1058,V2.1.0,20260603
+PROFILE=169
+DEVSTAT=3

AT+BTEN
<<
+BTEN=0

At this point, +DEVSTAT=3 indicates that Bluetooth is enabled, but AT+BTEN reports +BTEN=0.

We then attempted to disable discoverable mode using the AT+PAIR command, but the command had no effect.

From our observations:

After power-on, +DEVSTAT=3 is reported correctly.
However, AT+BTEN reports 0, which does not match the actual Bluetooth state.
While BTEN=0, the AT+PAIR command does not work.
After executing AT+BTEN=1, the AT+PAIR command starts working again, and discoverable mode can be enabled and disabled normally.

Could you please confirm whether this is expected behavior?
Best regards.

FAE_Gavin

mehmet
We checked this behavior internally. After power-on, the Bluetooth function is actually enabled (+DEVSTAT=3), but the internal BTEN status is not synchronized correctly, so the query result may still show:

AT+BTEN
+BTEN=0

Since the AT+PAIR command depends on the BTEN status, it cannot work normally in this condition.

Sending:

AT+BTEN=1

will synchronize the BTEN status again, after which AT+PAIR will work normally.

We have noted this behavior and will consider it in future firmware improvements.