BLE large Write turns to gibberish

RE: BLE large Write turns to gibberish

Jonas Lien — Thu, 24 Jun 2021 15:00:47 GMT

Thanks for your reply Susheel.

I get what you're saying about the offset, but I don't see you using it in your loop function, same as me. What i call buffer[i] you call ptr[i], and there is no relation to the offset other than the first print?

Since you manage to get it running, I'll see tomorrow if I've done something else to not make mine run correctly.

Best regards,

Jonas

RE: BLE large Write turns to gibberish

Susheel Nuguru — Thu, 24 Jun 2021 11:54:56 GMT

It works as it should. Offset is normally seen as a hint on the receiver side to note that if offset != 0 then this transaction is the continuation of the previous data sent (long/reliable writes)

RE: BLE large Write turns to gibberish

Susheel Nuguru — Thu, 24 Jun 2021 11:54:01 GMT

I did a quick test on UART_Peripheral and UART_Central examples on NCS v 1.5.1.which your config changes set into proj.conf on both devices

I see that the following output

[00:00:07.010,070] [0m<inf> peripheral_uart: Bluetooth initialized[0m
Starting Nordic UART service example
[00:00:07.443,695] [0m<inf> peripheral_uart: Connected E9:A8:9F:95:91:83 (random)[0m
[00:00:07.745,269] [0m<inf> peripheral_uart: Security changed: E9:A8:9F:95:91:83 (random) level 2[0m
[00:00:09.044,982] [0m<inf> bt_nus: Received data, Offet = 0X0 : BLE Msg:[0m
[00:00:09.045,013] [0m<inf> bt_nus: 01  [0m
[00:00:09.045,013] [0m<inf> bt_nus: 02  [0m
[00:00:09.045,013] [0m<inf> bt_nus: 03  [0m
[00:00:09.045,043] [0m<inf> bt_nus: 04  [0m
[00:00:09.045,043] [0m<inf> bt_nus: 05  [0m
[00:00:09.045,043] [0m<inf> bt_nus: 06  [0m
[00:00:09.045,043] [0m<inf> bt_nus: 07  [0m
[00:00:09.045,043] [0m<inf> bt_nus: 08  [0m
[00:00:09.045,074] [0m<inf> bt_nus: 09  [0m
[00:00:09.045,104] [0m<inf> bt_nus: 0a  [0m
[00:00:09.045,104] [0m<inf> bt_nus: 0b  [0m
[00:00:09.045,104] [0m<inf> bt_nus: 0c  [0m
[00:00:09.045,104] [0m<inf> bt_nus: 0d  [0m
[00:00:09.045,135] [0m<inf> bt_nus: 0e  [0m
[00:00:09.045,135] [0m<inf> bt_nus: 0f  [0m
[00:00:09.045,135] [0m<inf> bt_nus: 10  [0m
[00:00:09.045,135] [0m<inf> bt_nus: 11  [0m
[00:00:09.045,135] [0m<inf> bt_nus: 12  [0m
[00:00:09.045,166] [0m<inf> bt_nus: 
[0m
[00:00:09.045,288] [0m<inf> peripheral_uart: Received data from: E9:A8:9F:95:91:83 (random)[0m
[00:00:09.045,349] [0m<inf> bt_nus: Received data, Offet = 0X12 : BLE Msg:[0m
[00:00:09.045,379] [0m<inf> bt_nus: 13  [0m
[00:00:09.045,379] [0m<inf> bt_nus: 14  [0m
[00:00:09.045,379] [0m<inf> bt_nus: 15  [0m
[00:00:09.045,379] [0m<inf> bt_nus: 16  [0m
[00:00:09.045,410] [0m<inf> bt_nus: 17  [0m
[00:00:09.045,410] [0m<inf> bt_nus: 18  [0m
[00:00:09.045,410] [0m<inf> bt_nus: 19  [0m
[00:00:09.045,410] [0m<inf> bt_nus: 1a  [0m
[00:00:09.045,440] [0m<inf> bt_nus: 1b  [0m
[00:00:09.045,440] [0m<inf> bt_nus: 1c  [0m
[00:00:09.045,440] [0m<inf> bt_nus: 1d  [0m
[00:00:09.045,440] [0m<inf> bt_nus: 1e  [0m
[00:00:09.045,440] [0m<inf> bt_nus: 1f  [0m
[00:00:09.045,471] [0m<inf> bt_nus: 20  [0m
[00:00:09.045,471] [0m<inf> bt_nus: 
[0m

Changes on the peripheral side nus.c->on_receive

static ssize_t on_receive(struct bt_conn *conn,
			  const struct bt_gatt_attr *attr,
			  const void *buf,
			  uint16_t len,
			  uint16_t offset,
			  uint8_t flags)
{
	uint8_t *ptr = (uint8_t *)buf;
        LOG_INF("Received data, Offet = 0X%x : BLE Msg:", offset);

        for(uint8_t i = 0; i<len; i++)
        {
          LOG_INF("%02x  ", ptr[i]);
        }
        LOG_INF("\n");

	if (nus_cb.received) {
		nus_cb.received(conn, buf, len);
}
	return len;
}

Changes on the central side, main.c

uint8_t write_test_data[32] = { 0x01, 0x02, 0x03, 0x04, 0x05, 0x06, 0x07, 0x08,
                                0x09, 0x0a, 0x0b, 0x0c, 0x0d, 0x0e, 0x0f, 0x10,
                                0x11, 0x12, 0x13, 0x14, 0x15, 0x16, 0x17, 0x18,
                                0x19, 0x1a, 0x1b, 0x1c, 0x1d, 0x1e, 0x1f, 0x20,
                              };

void main(void)
{
	int err;

	err = bt_conn_auth_cb_register(&conn_auth_callbacks);
	if (err) {
		LOG_ERR("Failed to register authorization callbacks.");
		return;
	}

	err = bt_enable(NULL);
	if (err) {
		LOG_ERR("Bluetooth init failed (err %d)", err);
		return;
	}
	LOG_INF("Bluetooth initialized");

	if (IS_ENABLED(CONFIG_SETTINGS)) {
		settings_load();
	}

	bt_conn_cb_register(&conn_callbacks);

	int (*module_init[])(void) = {uart_init, scan_init, nus_client_init};
	for (size_t i = 0; i < ARRAY_SIZE(module_init); i++) {
		err = (*module_init[i])();
		if (err) {
			return;
		}
	}

	printk("Starting Bluetooth Central UART example\n");


	err = bt_scan_start(BT_SCAN_TYPE_SCAN_ACTIVE);
	if (err) {
		LOG_ERR("Scanning failed to start (err %d)", err);
		return;
	}

	LOG_INF("Scanning successfully started");

	for (;;) {
		/* Wait indefinitely for data to be sent over Bluetooth */
		//struct uart_data_t *buf = k_fifo_get(&fifo_uart_rx_data,
		//				     K_FOREVER);

		err = bt_nus_client_send(&nus_client, write_test_data, sizeof(write_test_data));
		if (err) {
			LOG_WRN("Failed to send data over BLE connection"
				"(err %d)", err);
		}

		err = k_sem_take(&nus_write_sem, NUS_WRITE_TIMEOUT);
		if (err) {
			LOG_WRN("NUS send timeout");
		}
	}
}

RE: BLE large Write turns to gibberish

Susheel Nuguru — Wed, 23 Jun 2021 13:32:36 GMT

Jonas, I will try to do a quick test of this tomorrow and come back to you. Thanks for your patience.

RE: BLE large Write turns to gibberish

Jonas Lien — Tue, 22 Jun 2021 13:21:37 GMT

Hi again Simon,

I think I've basically already given you the relevant code snippets in the top post, but maybe you can use any of your NCS samples that does BLE writes and just increase ATT MTU? I'm fine with any example of writing a bigger object than what the DLE is set for.

I know your throughput sample operates with varying degree of data length, but there it is used bt_gatt_write_without_response, where as I'm interested in bt_gatt_write which also gives a response/ack. The throughput sample also just uses "offset=0" in its params, so I'm not sure what differently I should do.

Hope to hear from you soon 🙂

Best regards,

Jonas

RE: BLE large Write turns to gibberish

Simonr — Tue, 22 Jun 2021 12:57:05 GMT

Hi again Jonas

I'm sorry about the delayed reply, but I've discussed this with a colleague, and it seems that, honestly, it doesn't seem like we've tested long prepared writes like this properly. Can you upload your project or the necessary code snippets to do a long write so we can test this on our end, as we'd like to give the correct explanation on how to handle this offset.

Best regards,

Simon

RE: BLE large Write turns to gibberish

Jonas Lien — Thu, 17 Jun 2021 07:44:39 GMT

Hi Simon, and thanks for your reply 🙂

beacon_data.fw is just a struct stored in RAM at runtime.

How do I account for the offset that you are talking about? It seems there is something about the transmit process im not fully getting.

BR,

Jonas

RE: BLE large Write turns to gibberish

Simonr — Thu, 17 Jun 2021 07:40:02 GMT

The send function seems to be done correctly, but the way you receive and interpret the data is what's causing these garbage values in the second packet.

It seems like you're ignoring the offset that tells the receiver what to look for in the second packet, which is why you only see the first packet correctly. You'll need to take the fact that this is a continuation of data so the data from the second packet is what is printed, and not just random data. Also, where do you store this incoming data beacon_data.fw? Is it stored in RAM or Flash?

Best regards,

Simon

RE: BLE large Write turns to gibberish

Simonr — Wed, 16 Jun 2021 12:10:00 GMT

Hi Jonas

I'm sorry about the poor response, but I have not had sufficient time to take a good look at your issue today, and will do so first thing tomorrow morning. I should be able to provide some better assistance/support by tomorrow. Thank you for your patience!

Best regards,

Simon