Post

Replies

Boosts

Views

Activity

CoreBluetooth and BLE AdvertisementData
Hi, We're receiving data via centralManager.centralManager.scanForPeripherals, with no options or filtering (for now), and in the func centralManager(_ central: CBCentralManager, didDiscover peripheral: CBPeripheral, advertisementData: [String : Any], rssi RSSI: NSNumber) callback, we get advertisementData for each bluetooth device found. But, I know one of my BLE devices is sending an Eddystone TLM payload, which generally is received into the kCBAdvDataServiceData part of the advertisementData dictionary, but, it doesn't show up. What is happening however (when comparing to other devices that do show that payload), is I've noticed the "isConnectable" part is false, and others have it true. Technically we're not "connecting" as such as we're simply reading passive advertisement data, but does that have any bearing on how CoreBluetooth decides to build up it's AdvertisementData response? Example (with serviceData; and I know this has Eddystone TLM) ["kCBAdvDataLocalName": FSC-BP105N, "kCBAdvDataRxPrimaryPHY": 1, "kCBAdvDataServiceUUIDs": <__NSArrayM 0x300b71f80>( FEAA, FEF5 ) , "kCBAdvDataTimestamp": 773270526.26279, "kCBAdvDataServiceData": { FFF0 = {length = 11, bytes = 0x36021892dc0d3015aeb164}; FEAA = {length = 14, bytes = 0x20000be680000339ffa229bbce8a}; }, "kCBAdvDataRxSecondaryPHY": 0, "kCBAdvDataIsConnectable": 1] Vs This also has Eddystone TLM configured ["kCBAdvDataLocalName": 100FA9FD-7000-1000, "kCBAdvDataIsConnectable": 0, "kCBAdvDataRxPrimaryPHY": 1, "kCBAdvDataRxSecondaryPHY": 0, "kCBAdvDataTimestamp": 773270918.97273] Any insight would be great to understand if the presence of other flags drive the exposure of ServiceData or not...
0
0
73
Jul ’25
Background Task Execution - Doesn't Seem Consistent
I have an app, that when enters the background schedules a task to run. The earliest possible time value is set, as is the completion handler when the task eventually runs. It seems to run pretty reliably for the 1st few interations and then (from looking at the streaming Console logs), doesn't seem to reach a high CP score to execute next time around. eg '......background.task:EDBC23' CurrentScore: 0.648418, ThresholdScore: 0.808034 DecisionToRun:0 looking at the previous entries before this, I can see the breakdown... {name: Application Policy, policyWeight: 50.000, response: {0, 0.35}} {name: Device Activity Policy, policyWeight: 5.000, response: {0, 0.50}} ], Decision: CP Score: 0.648418} and I understand certain elements are outside of our control; however, is there a preferred method to get a background task (which ultimately runs an API call) to trigger consistently? The silent-push method has come up a few times - but of course, if the user disables / doesn't consent to push notifications, that fails Any suggestions?
1
0
365
Dec ’24