Hi,
I am using DA14580 with sdk 3.0.10 to Tx/Rx iBeacon. sometimes the iBeacon will not be correct because of losing byte.
(The product has been released, so it can not be updated to sdk 5 or 6 easily. )
e.g.
/*
* PUBLIC ADDR : 479c3d89f160;
* UUID: 002e2e4fbd5443f7a2feec6d86da0bdb
*/
/* this is what I sent*/
0000 479c3d89f160 1e 0201061aff 4c000215 002e2e4fbd5443f7a2feec6d86da0bdb600000010000 5f(format is struct adv_report)
/* this is what I received at Rx side occasionally , 0xdb and 0x01 is lost and a weird 0x1c is generated. */
0000 479c3d89f160 1e 0201061aff 4c000215 002e2e4fbd5443f7a2feec6d86da0b60000000001c00 5f(format is struct adv_report)
/*
int gapm_adv_report_ind_handler(
ke_msg_id_t msgid, /**<[in] Message Id */
const struct gapm_adv_report_ind *param, /**<[in] Message Parameter */
ke_task_id_t dest_id, /**<[in] Destination Task Id */
ke_task_id_t src_id /**<[in] Source Task Id */
)
*/
I print the gapm_adv_report_ind at the head of function gapm_adv_report_ind_handler , which is called in TASK_APP.
I can't go further because of the patch_objs. so do you have any advice for me?
Expecting your reply, any words will be appreciated!
Best Regards,
Bin
Hi bin,
There is no such issue on the SDK 3.0.10 as far as i am aware, also what you have mentioned on the post has a length of 40 bytes, the advertising string can only fit up to 31 bytes which 3 of them are reserved, i suppose that on post you have record the entire structure, is that correct ? Also i dont quite get where the problem is identified, is it on the 580 central side and the advertising string that the device receives is incorrect or is it on a peripheral side, the advertising string that the 580 device emmits is incorrect ? You will be able to see that via using a generic application on an android phone and check where the issue is located. So please make sure that the peripheral is advertising what is that you are instructing it to advertise and verify that the issue occurs either to the 580 central or the 580 peripheral.
Thanks MT_dialog
Hi, MT_dialog
thanks for your advisement, and I will try to use other device to scan the iBeacon from 580 peripheral device. to see whether I can capture the weird iBeacon.
If I can see the weird iBeacon, that will not be the problem in Rx side(central device). otherwise, I have to continue to do the current debugging.
the structure is as follows, and the Rx side is central side.
struct adv_report
{
///Event type:
/// - ADV_CONN_UNDIR: Connectable Undirected advertising
/// - ADV_CONN_DIR: Connectable directed advertising
/// - ADV_DISC_UNDIR: Discoverable undirected advertising
/// - ADV_NONCONN_UNDIR: Non-connectable undirected advertising
uint8_t evt_type;
///Advertising address type: public/random
uint8_t adv_addr_type;
///Advertising address value
struct bd_addr adv_addr;
///Data length in advertising packet
uint8_t data_len;
///Data of advertising packet
uint8_t data[ADV_DATA_LEN];
///RSSI value for advertising packet
uint8_t rssi;
};
Hi bin,
Please check which of the two devices has the issue in order to focus our attention on this, also if you could try to replicate this on Dialog's dev kits would help as well in case you are testing only on custom boards.
Thanks MT_dialog