I'm trying to implement a BLE master to read data from a custom BLE device, and am trying to run the BGLIB_scanner demo to scan for the device.
I notice that after scan response from the device of a few packets, I see a "system boot" message, which indicates that the ble112 device restarted?
I have tried the scanner with a TI Sensor Tag and it can read scan responses all day long.
The only difference I see with this device is that the address type is "1" (random) (whereas the TI Sensor Tag has an address type of "0" (public) ).
I'm wondering if there is anything different in the code path in the device/library for address type of "1", where there might be a bug or issue?
������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������������BLE112 BGAPI Scanner Demo
Operations Menu:
0) Reset BLE112 module
1) Say hello to the BLE112 and wait for response
2) Toggle scanning for advertising BLE devices
Command?
--> system_hello
<-- system_hello
--> system_reset: { boot_in_dfu: 0 }
### system_boot: { major: 1, minor: 4, patch: 2, build: 82, ll_version: 3, protocol_version: 1, hw: 1 }
--> system_reset: { boot_in_dfu: 0 }
### system_boot: { major: 1, minor: 4, patch: 2, build: 82, ll_version: 3, protocol_version: 1, hw: 1 }
--> gap_set_scan_parameters: { scan_interval: 0xC8, scan_window: 0xC8, active: 1 }
<-- gap_set_scan_parameters: { result: 0 }
--> gap_discover: { mode: 2 (GENERIC) }
<-- gap_discover: { result: 0 }
### gap_scan_response: { rssi: -49, packet_type: 0, sender: 3C1F4932ACF7, address_type: 1, bond: FF, data: 0201050D09536D617274204D6F64756C65 }
### gap_scan_response: { rssi: -49, packet_type: 4, sender: 3C1F4932ACF7, address_type: 1, bond: FF, data: 110700000000000000B00040510421AA00F0 }
### gap_scan_response: { rssi: -49, packet_type: 0, sender: 3C1F4932ACF7, address_type: 1, bond: FF, data: 0201050D09536D617274204D6F64756C65 }
.....
### gap_scan_response: { rssi: -48, packet_type: 0, sender: 3C1F4932ACF7, address_type: 1, bond: FF, data: 0201050D09536D617274204D6F64756C65 }
### gap_scan_response: { rssi: -49, packet_type: 4, sender: 3C1F4932ACF7, address_type: 1, bond: FF, data: 110700000000000000B00040510421AA00F0 }
### gap_scan_response: { rssi: -49, packet_type: 0, sender: 3C1F4932ACF7, address_type: 1, bond: FF, data: 0201050D09536D617274204D6F64756C65 }
### gap_scan_response: { rssi: -49, packet_type: 4, sender: 3C1F4932ACF7, address_type: 1, bond: FF, data: 110700000000000000B00040510421AA00F0 }
### gap_scan_response: { rssi: -48, packet_type: 0, sender: 3C1F4932ACF7, address_type: 1, bond: FF, data: 0201050D09536D617274204D6F6475801C }
### system_boot: { major: 6, minor: D0, patch: 1F3C, build: 3249, ll_version: F7AC, protocol_version: 1, hw: FF }
The interesting thing is that the system_boot message at the end shows a different major/minor versions than the initial message.