Replacing HM-10 with RAYTAC MDBT42TV-DB-05 for Transparent UART

[masasaSA]

I'm trying to replace HM-10 module with a RAYTAC MDBT42TV-DB-05 for a transparent UART (serial passthrough) application. I've configured all the parameters and GATT settings to be identical to the HM-10, but I'm unable to achieve successful data transmission and can't make the replacement work. Has anyone had a similar experience or any suggestions on what might be causing the issue?

[Hung Bui]

Hi Mark, 

You would need to explain to us what's firmware was on the HM-10 module and what you implemented on the Raytac. Having the same GATT table doesn't guarantee that it will be functional. 

[masasaSA]

Hi,

The HM-10 was running its default firmware (AT command set + transparent UART function).

For the MDBT42TV-DB-05, I started from the SDK v2.9.2 peripheral_uart sample and modified it. For example, in ble_write_thread() I changed the behavior so that, instead of waiting for a newline character ("\n")before sending, the code directly calls bt_gatt_notify() to immediately forward any data received from UART  as a GATT notification (to better match the HM-10 behavior). I also adjusted the GATT table to align with the HM-10 characteristics, and implemented custom read_cb, write_cb, and ccc_cfg_changed handlers to manage GATT operations.

With this setup, both TX and RX are working. However, the key difference I observed is that the HM-10 does not require the central (e.g., nRF Connect) to explicitly enable notifications. After connection, simply typing in a serial terminal (like PuTTY) seems to automatically activate notifications and data transmission. In my implementation, the central must explicitly enable notifications before data can be exchanged. This causes my existing app (which expects HM-10–style behavior) to fail to communicate with the Raytac device.

One possible difference I suspect is that the HM-10 firmware may implicitly modify the CCCD or otherwise enable notifications on the peripheral after a connection (or react to some implicit central behavior), whereas the Nordic sample follows the BLE spec more strictly and requires the central to write the CCCD to enable notifications.

My final goal is to keep the original HM-10 transparent UART functionality while adding some simple DI/DO features. Right now I can’t get the basic transparent UART behavior to be fully compatible.

[Hung Bui]

Hi Mark, 
By spec, the peripheral can only send notification when the CCCD is enabled. CCCD can be automatically enabled if the central previously enables it and the central has been bonded with the peripheral. 
So in your case, if the HM-10 does that it's not according to the spec. 
But this can be fix easily by having the central/client automatically write to the peripheral/server when connected. I don't see why it would be a problem ?

[masasaSA]

After replacing the Bluetooth module, my original central (Android app) stopped receiving any data. Based on standalone module tests, I initially suspected that the observed differences might be related to the issue, but they may not necessarily represent the root cause.

It may be necessary to consult the app developer to clarify how the app handles notifications and data reception, as it could be relying on the HM-10’s implicit notification behavior. Understanding the app’s expectations could help determine whether the problem lies on the peripheral side or stems from assumptions made by the app.

[Hung Bui]

HI Mark, 
I agree. You should consult with the app developer. Having an extra write command to enabled CCCD should be the correct way of doing it. 
I think you can test with our nRF connect on Mobile app.