Receiving Coded Phy Adv with the TLSR825x SDK

[Ircama]

@pvvx let me ask your help: while with an Ai-Thinker TB-03F-KIT running a trivial code (borrowed from the Ai-Thinker Telink 825X SDK), I am able to receive standard advertising frames produced by a LYWSD03MMC device with your latest pvvx firmware, when setting CODED PHY on this device using your appropriate configuration, no advertisement is received any more.

Can you please advise which is the correct code for the TLSR8253 SDK to enable receiving CODED PHY advertising produced by your firmware?

I do this by now (which is clearly not enough):

...
blc_ll_init2MPhyCodedPhy_feature();                            // Coded PHY
blc_ll_setPhy(BLM_CONN_HANDLE, PHY_TRX_PREFER, PHY_PREFER_CODED, PHY_PREFER_CODED, CODED_PHY_PREFER_S8);
blc_ll_setDefaultConnCodingIndication(CODED_PHY_PREFER_S8);    // set Default Connection Coding
blc_ll_initChannelSelectionAlgorithm_2_feature();              // set CSA2
blc_ll_setScanParameter(SCAN_TYPE_PASSIVE, SCAN_INTERVAL_100MS, SCAN_INTERVAL_100MS, OWN_ADDRESS_PUBLIC, SCAN_FP_ALLOW_ADV_ANY);
blc_ll_setScanEnable (BLC_SCAN_ENABLE, DUP_FILTER_DISABLE);
...

With the above code, I receive standard advertisements (event callbacks) produced by sensors, but not the ones produced by the LYWSD03MMC in CODED PHY configuration.

Unfortunately, the Telink SDK Developer Handbook does not help enough.

Thanks a lot!

[pvvx]

To send or receive Extended Advertisements you must enable additional modules.

https://wiki.telink-semi.cn/tools_and_sdk/BLE/B85M_BLE_SDK.zip -> \b85m_ble_sdk\vendor\b85m_feature\feature_ext_scan

[pvvx]

To receive all options BT5.4 (including Coded PHY in primary_phy) will have to use CH32V208W.

[Ircama]

Interesting points. Considering that if I'm not wrong in Coded PHY mode the thermometer transmits BLE_PHY_CODED adv in both primary and secondary channels (with CODED_PHY_PREFER_S8 for long range), is the setting you are testing (Coded PHY in secondary_phy but not in primary_phy) enough to scan the thermometer in passive mode?

[pvvx]

Telink BLE SDK_VERSION = telink_b85m_ble_sdk_V4.0.1.3_patch0001

## V4.0.1.3_Patch_0001

### Bug Fixes
* Fixed: A very small number of chips rarely experience insufficient oscillation of the 24M crystal after waking up from sleep, leading to MCU abnormality.   
* Fixed: Pairing failure occurs when using Secure Connection with low power deepsleep retention mode.  
* Fixed: The primary Channel advertising packet can not be received when using Coded PHY in Extended Scan.  
* Fixed: The RSSI value is incorrect in the Extended advertising report event.  
* Fixed: The AUX_CONNECT_RSP PDU can not be received when initiating a connection request under Extended Scan Coded PHY S8 mode, resulting in creating connection failure.  

Fixed: The primary Channel advertising packet can not be received when using Coded PHY in Extended Scan. (!)

1. But, the primary PHY in extended advertising mode during connection only works on 1M PHY (!)
2. In advertising mode and simply when scanning, all PHY options work.

UART Log (TB-03F-KIT -> adv2uart.py):

Press 'ESC' to exit
Connecting to COM8 ...
Open COM8, 921600 bit/s... ok
be 01 01 0d8d3af1ad3b 1eff060001092006e71f093534d649ca171418639ce238181a13e22505fad8
ba 00 01 381f8d942ef9 020106030201a2141601a20154cf0451ebc77129c7b6647dfdaa27c4
b4 00 01 381f8d941e11 020106030201a2141601a2019d2de84dff21d8f26160e052d0d0b672
ac 00 01 1c90ffdc0cc6 020106030201a2141601a201d3496059d9146eded9e4d956127b7b6f
a9 00 01 381f8dd8b52d 020106030201a2141601a2013291499cc35a871c792b8e1772197a78
c8 01 01 75b7ce44e3ed 0303f3fe
...
ba 00 01 381f8dd93cb6 020106030201a2141601a2016db2d52cd37c86fa958e84fb795ead4e
a4 00 01 1c90ffdc0cc6 020106030201a2141601a201d3496059d9146eded9e4d956127b7b6f
ba 01 01 0d8d3af1ad3b 1eff060001092006e71f093534d649ca171418639ce238181a13e22505fad8
a3 00 33 a4c138ae3ebf 0201060e16d2fc40009401460218f703c3150b095448535f414533454246
be 00 01 381f8d942ef9 020106030201a2141601a20154cf0451ebc77129c7b6647dfdaa27c4

More than 27 advertisements per second..

And this is what was required:
a3 00 33 a4c138ae3ebf 0201060e16d2fc40009401460218f703c3150b095448535f414533454246

33 - Primary Coded РНY, Secondary Coded РНY

[pvvx]

u8 buf[EXTADV_INFO_LENGTH + EXTADV_RPT_DATA_LEN_MAX];

void ble_ext_adv_callback(u8 *p) {
	hci_le_extAdvReportEvt_t *pExtAdvRpt = (hci_le_extAdvReportEvt_t *)p;
	extAdvEvt_info_t *pa = NULL;
	int offset = 0;
	for(int i=0; i < pExtAdvRpt->num_reports ; i++) {
		pa = (extAdvEvt_info_t *)(pExtAdvRpt->advEvtInfo + offset);
		offset += (EXTADV_INFO_LENGTH + pa->data_length);
		if (pa->data_length && pa->data_length <  EXTADV_RPT_DATA_LEN_MAX && pa->rssi != 0) {
			buf[0] = (pa->data_length > sizeof(buf) - 10)? sizeof(buf) - 10 : pa->data_length;
			buf[1] = pa->rssi;
			buf[2] = (pa->address_type & 0x0f) | (pa->direct_address_type); 
			buf[3] = pa->primary_phy | (pa->secondary_phy << 4);
			memcpy(&buf[4], pa->address, 6);
			memcpy(&buf[10], pa->data, buf[0]);
			uart_send(buf, buf[0] + 10); // DMA, test for the previous one has been sent...
		}
	}
}

int app_controller_event_callback(u32 h, u8 *p, int n) {
	if (h & HCI_FLAG_EVENT_BT_STD) { // ble controller hci event
		u8 evtCode = h & 0xff;
		if(evtCode == HCI_EVT_LE_META) { //LE Event
			if (p[0] == HCI_SUB_EVT_LE_EXTENDED_ADVERTISING_REPORT // Ext ADV packet?
			|| p[0] == HCI_SUB_EVT_LE_PERIODIC_ADVERTISING_REPORT)
				ble_ext_adv_callback(p);
		}
	}
	return 0;
}

void start_adv_scanning(void) {
	blc_ll_setExtScanParam( OWN_ADDRESS_PUBLIC, SCAN_FP_ALLOW_ADV_ANY, SCAN_PHY_1M_CODED,
							SCAN_TYPE_PASSIVE,  SCAN_INTERVAL_30MS,   SCAN_WINDOW_30MS, 
							SCAN_TYPE_PASSIVE,  SCAN_INTERVAL_30MS,   SCAN_WINDOW_30MS);
	blc_ll_setExtScanEnable( BLC_SCAN_ENABLE, DUP_FILTER_DISABLE,
							SCAN_DURATION_CONTINUOUS, SCAN_WINDOW_CONTINUOUS);
}

void init_ble(void) {
	uint8_t mac_random_static[6];
	uint8_t mac_public[6];
	blc_initMacAddress(CFG_ADR_MAC, mac_public, mac_random_static);
	blc_ll_initBasicMCU();
	init_uart(921600);
	blc_ll_initStandby_module(mac_public); 
	blc_ll_initExtendedScanning_module();	//extended scan module
	blc_ll_initExtendedInitiating_module();
	blc_ll_initAclConnection_module();
	blc_hci_registerControllerEventHandler(app_controller_event_callback); //controller hci event to host all processed in this func
	blc_hci_le_setEventMask_cmd( HCI_LE_EVT_MASK_ADVERTISING_REPORT
			| HCI_LE_EVT_MASK_DIRECT_ADVERTISING_REPORT
			| HCI_LE_EVT_MASK_PERIODIC_ADVERTISING_REPORT
			| HCI_LE_EVT_MASK_EXTENDED_ADVERTISING_REPORT);
	blc_controller_check_appBufferInitialization();
	rf_set_power_level_index(MY_RF_POWER);
	start_adv_scanning();
}

[Ircama]

I'm a bit late to answer, I checked it now, but this is a good result indeed. I understand that you are in the end interested in the connections, but scanning both coded phy and legacy advertising concurrently is really quite interesting.

I'm amazed at your code as I found incomplete documentation and headers; also examples are missing.

I guess that primary_phy and secondary_phy refer to le_phy_type_t (there is nothing stating this anyway) so in your example 1 is BLE_PHY_1M and 3 is BLE_PHY_CODED. I understand that if the TB-03F-KIT module receives 01 and then 33 it means that it can scan BLE_PHY_1M and BLE_PHY_CODED concurrently.

[pvvx]

https://github.com/pvvx/WCHBLE2ETH

[Ircama]

wow, and are you able to scan Zigbee, BLE_PHY_1M and BLE_PHY_CODED concurrently to the UART?

[pvvx]

Uart can't handle BLE.
I made a BLE receiver with output to UART 921600 Baud with CRC16 (TB-03F-KIT).
Accepts 1M and Coded PHY. Software FIFO for 4 packets of 240 bytes, white or black list in 64 MAC. The (RED) LED indicates that sometimes the UART cannot keep up. (LEDs: Red - did not have time to transmit, Green - PHY 1M reception, blue - encoded PHY, white and yellow - UART reception/transmission)
UART also has problems with event processing time.
For example, the event of transferring a contact state from one BLE to another and controlling the GPIO output is 3..5 ms. And UART at low speeds introduces additional delay.

A UART without CRC16 will work as in rPi 3. Users often complain about several errors per day when receiving just a couple of devices that occur in HA when receiving from a BT adapter to a UART in rPi 3. On the graphs there are emissions and errors in the log... Linux does not а real-time system cannot work without errors (missing characters) with UART.

[Ircama]

This is an appropriate warning when using UART in principle. I imagine that in the case of the TB-03F-KIT, the problem could be related to the CH340 interface, which has limited throughput (so not the USB virtual serial port driver inside the host). I wasn't actually considering such intensive use: just a few devices transmitting quite infrequently (every minute). In my use case, the white list should reduce the amount of data to a throughput sustainable by the UART.

[pvvx]

UART problems are not related to speed, but to errors, character losses and lack of block synchronization.
The checksum is not transmitted to "AT".

For a normal USB, the maximum continuous flow in the UART for CH340 is 230400 Baud. At high speeds there will be losses due to the buffer size in CH340.

Plus, not all USB hosts have a large buffer (unless they are USB3.0). This limits the total continuous flow already via USB in CDC mode (by the size of the host buffer for receiving a burst of packets in 1 ms). If USB-USB equipment has everything to the maximum, then USB2.0FS in CDC is 800 kilobytes per second.

---

https://github.com/pvvx/TLSR825x_ADV_BLE2UART

[Ircama]

Bluetooth-Devices/bthome-ble#107 are not related to speed, but to errors, character losses and lack of block synchronization.

I'll do some load&stress tests with my setup to verify how many errors I get

[Ircama]

https://github.com/pvvx/TLSR825x_ADV_BLE2UART

Ah, thank you @pvvx, amazing!

I'm away from home but I'll test it for sure.

[pvvx]

There is a significant difference in the design of the antenna and its location.
When the module is on top of another PCB, things are bad:
pvvx/BLE_THSensor#9 (comment)

---

You may not get a clear difference in range if the radio broadcast is noisy.
LE Long Range wins at the minimum reception level. For other PHY options, reliable reception at -105..107 dBm is unattainable.

---

To receive my farthest thermometer working in LR, I had to place the receiving modules closer, excluding one wall.
Then the reception began.

WCH CH32V208W BLE->LAN
08 33 9c a4c138f7612b 0201060b16d2fc4000a80cd30b10010b094254485f463736313242
rssi -100 dBm
08 33 a3 a4c138f7612b 0201060e16d2fc4000ca016402260703d60f0b094254485f463736313242
rssi -93 dBm

TB-03F-Kit BLE->UART
adv: 9d 00 01 33 a4c138f7612b 0201060e16d2fc400062016402100703de0f0b094254485f463736313242
rssi -99 dBm

These modules are likely to have limited adoption rates.
And on the RTL8761BU the receiver operates at -110 dBm.

---

I wrote a receiver on CH582M in UART.
But he also doesn’t want to get the most distant thermometer next to the RTL8761BU (another house, 200m, 3 walls).
The CH582M documentation states:

Main features:

• Integrated with 2.4GHz RF transceiver, BaseBand and LLE link control.
• Support Bluetooth Low Energy (BLE), compatible with Bluetooth Low Energy specifications of version
  4.2/5.0 and above.
• Single-ended RF interface and simplified board design.
• 2Mbps, 1Mbps, 500Kbps and 125Kbps.
• -98dBm RX sensitivity.
• Programmable TX power from -16dBm to +6dBm, and dynamic adjustment is supported.
• When using the PCB onboard antenna, the wide communication distance is about 210 meters at 0dBm TX
  power, and it is about 500 meters at 6dBm TX power.
• The wide communication distance is about 1000 meters at 6dBm TX power and at 125Kbps.
• Support AES encryption/decryption.
• Support DMA.
• Optimized protocol stack and application layer API, and support networking.

---

Reoriented the CH582M module. The CH582M began receiving remote sensor levels as low as -99 dBm.
a4c138f7612b rssi -99 dBm
a4c138f7612b rssi -100 dBm

---

I tried it on ESP32-C3 on IDF.
At different positions of the module it turned out:

MAC          RSSI  FLG   BTHomeUUID  NN   DATA                 NAME
a4c138f7612b -96  020106 0e16d2fc400 06 60164028e0703d511 0b094254485f463736313242 BTH_F7612B
a4c138f7612b -106 020106 0e16d2fc400 06 80164028d0703d811 0b094254485f463736313242 BTH_F7612B
a4c138f7612b -104 020106 0e16d2fc400 06 a0164028f0703d211 0b094254485f463736313242 BTH_F7612B
a4c138f7612b -107 020106 0e16d2fc400 06 c0164028e0703cd11 0b094254485f463736313242 BTH_F7612B
a4c138f7612b -105 020106 0e16d2fc400 07 00164028d0703d411 0b094254485f463736313242 BTH_F7612B
a4c138f7612b -105 020106 0e16d2fc400 07 00164028d0703d411 0b094254485f463736313242 BTH_F7612B
a4c138f7612b -101 020106 0e16d2fc400 07 10164028d0703c111 0b094254485f463736313242 BTH_F7612B
a4c138f7612b -106 020106 0b16d2fc400 07 40cc00b1001       0b094254485f463736313242 BTH_F7612B
a4c138f7612b -99  020106 0e16d2fc400 07 7016402900703bf11 0b094254485f463736313242 BTH_F7612B
a4c138f7612b -97  020106 0b16d2fc400 07 80cc30b1001       0b094254485f463736313242 BTH_F7612B
a4c138f7612b -98  020106 0e16d2fc400 07 90164028f0703b811 0b094254485f463736313242 BTH_F7612B
a4c138f7612b -98  020106 0e16d2fc400 07 90164028f0703b811 0b094254485f463736313242 BTH_F7612B
a4c138f7612b -99  020106 0e16d2fc400 07 e016402930703b611 0b094254485f463736313242 BTH_F7612B
a4c138f7612b -95  020106 0e16d2fc400 07 f016402950703c011 0b094254485f463736313242 BTH_F7612B
a4c138f7612b -99  020106 0e16d2fc400 08 1016402950703d711 0b094254485f463736313242 BTH_F7612B
a4c138f7612b -102 020106 0b16d2fc400 08 60ccd0b1001       0b094254485f463736313242 BTH_F7612B
a4c138f7612b -103 020106 0b16d2fc400 08 80cc00b1001       0b094254485f463736313242 BTH_F7612B
a4c138f7612b -104 020106 0b16d2fc400 09 70cc10b1001       0b094254485f463736313242 BTH_F7612B
a4c138f7612b -99  020106 0e16d2fc400 09 8016402920703b311 0b094254485f463736313242 BTH_F7612B
a4c138f7612b -100 020106 0d16d2fc400 09 b11013e00000000   0b094254485f463736313242 BTH_F7612B
a4c138f7612b -105 020106 0d16d2fc400 09 b11013e00000000   0b094254485f463736313242 BTH_F7612B
a4c138f7612b -103 020106 0e16d2fc400 09 d016402940703be11 0b094254485f463736313242 BTH_F7612B

That is, the reception sensitivity is comparable to RTL8761BU. I used the receive setting to receive only encoded PHYs and cut out the nearest sensors from the log.

[Ircama]

I too can't get better reception than -100/-102 dBm on the TB-03F-KIT.

I noticed that also for the TB-03F-KIT the orientation is important to maximize reception (other than RF noise).

I imagine that in the case of mixed scanning (both "SCAN_PHY_1M" and "SCAN_PHY_CODED") the receiver gets configured to the sensitivity of BT 4.2 to avoid errors when PHY packets are not coded. Otherwise, it could be that the current SDK does not yet control the hw sensitivity (or the Telink hw is based on BT 4.2 and it is not designed to increase sensitivity).

[pvvx]

https://github.com/pvvx/TLB2Z

[Ircama]

I use Telink_Tools.py to flash the TB-03F-KIT firmware.

python3 Telink_Tools.py --port com10 burn filename.bin

It supports python3 and python2, Unix and Windows and does not need any jumper.

[pvvx]

This programmer requires firmware support. If you erase all Flash or write down any firmware, then the described programmer will not work.
Ai-Thinker copied my https://github.com/pvvx/TlsrComSwireWriter https://github.com/pvvx/TlsrComProg825x into its program for such cases
https://github.com/Ai-Thinker-Open/TBXX_Flash_Tool (https://github.com/Ai-Thinker-Open/TBXX_Flash_Tool/blob/master/UartBoot.py)

PS: And I haven't used Python 2 for a long time. I don't have it on any Linux board/computer ...