- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have implemented the OTA update on my board.
In fact, the update by HCI or OTA works fine (by Android or Windows example provided by the SDK). The functionalities of the firmware are correctly updated.
But I would to check the firmware version by the Android application. So with the Android update application I check the characteristic Application Info, the issue is that the version returned by the firmware is false: the value is always Major=1, Minor=1, even the right value is 1.2 or 1.3 (defined by: #define MY_APP_ID 0x0476, #define MY_APP_VERSION_MAJOR 1, #define MY_APP_VERSION_MINOR 3, for WS_UPGRADE_CHARACTERISTIC_APP_INF definition).
Note: the application ID is correct.
What do you think I have forgotten or wrongly done ?
Solved! Go to Solution.
- Labels:
-
Over The Air Upgrades - OTA
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello.
The adv and scr are separate packets so they can each be 31 bytes.
But remember each field has two bytes header (length and value).
So that leaves 29 bytes for actual data.
You can find more about adv packets in the following link:
James
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I did hardware resets and power resets without any success.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I couldn't reproduce this issue but I am working on a tag3 board. Can you use the OTA update sample app available in the SDK and try it out on your board?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have implemented the update functions from this application, but OK, I will try to test the OTA update sample app "as is" on my board this week
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I tested today the OTA update sample on my board, and it works.
I compared the 2 applications, and I discovered that I declared the device name with 24 characters. I reduced the length to 16 char and it works ! It feels as a side effect !
What is the maximum authorized length for the device name (I saw in the forum that it is also limited by the advertising length) ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
There are constraints on the advertising packet and scan response payloads. The maximum size is 31 octets each as per the BT Specification but it can be shorter. I'm not sure where the payload length is defined in the SDK code, but lets take a look.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
So, if I understand (it is not so clear in others topics), each field of advertising or scan response can be 31 bytes long.
For example, if I use this classical function to define and start advertising:
void my_start_ADV()
{
// advertise first vendor specific service
if (sizeof(my_uuid_main_service) > 1)
{
ble_trace0("my_start_ADV...");
// total length should be less than 31 bytes
BLE_ADV_FIELD adv[3];
BLE_ADV_FIELD scr[1];
// flags
adv[0].len = 1 + 1;
adv[0].val = ADV_FLAGS;
adv[0].data[0] = LE_LIMITED_DISCOVERABLE | BR_EDR_NOT_SUPPORTED;
adv[1].len = sizeof(my_uuid_main_service) + 1;
adv[1].val = sizeof(my_uuid_main_service) == 16 ? ADV_SERVICE_UUID128_COMP : ADV_SERVICE_UUID16_COMP;
memcpy(adv[1].data, &my_uuid_main_service[0], sizeof(my_uuid_main_service));
// Tx power level
adv[2].len = TX_POWER_LEN+1;
adv[2].val = ADV_TX_POWER_LEVEL;
adv[2].data[0] = bleprofile_p_cfg->tx_power_level;
// name
scr[0].len = strlen(bleprofile_p_cfg->local_name) + 1;
scr[0].val = ADV_LOCAL_NAME_COMP;
memcpy(scr[0].data, bleprofile_p_cfg->local_name, scr[0].len - 1);
bleprofile_GenerateADVData(adv, 3);
bleprofile_GenerateScanRspData(scr, 1);
}
blecm_setTxPowerInADV(0);
// start device advertisements. By default Advertisements will contain flags, device name,
// appearance and main service UUID.
bleprofile_Discoverable(HIGH_UNDIRECTED_DISCOVERABLE, NULL);
}
in this case, could the local_name be 31 bytes long (as scan response payload), or should the total adv fields + scr length be less than 31 bytes ?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hi Yves,
I think the relevant part of the BT spec. is in Volume 6 - Core system package for Low Energy - section 2 details Air Interface Packet format.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello.
The adv and scr are separate packets so they can each be 31 bytes.
But remember each field has two bytes header (length and value).
So that leaves 29 bytes for actual data.
You can find more about adv packets in the following link:
James
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks guys. It confirms that I understood.