I downloaded the last firmware 0.6.0 but my version bluez is still 5.50 and not 5.52. Anyway, I am not sure it is the origin of my problem.
Concerning your previous message :“I looks like not all functions in bluetoothctl work on the yellow. The connect function is classic Bluetooth and it does not appear to work.” Do you mean it is normal that it doesn’t work but the BLE apps can work even if devices are not connected? Could you try to make a connect to one your device please and let me know if it works?
BLE doesn’t connect the way Bluetooth Classic does, it’s a different protocol in many respects. So connect working (or not working) on one does not apply to the other. Using bluetoothctl I get different errors trying to connect from either side:
Ubuntu->mangOH
[bluetooth]# connect 3C:E1:A1:E8:B6:E1
Attempting to connect to 3C:E1:A1:E8:B6:E1
Failed to connect: org.bluez.Error.Failed
[bluetooth]#
mangoh->Ubuntu
[bluetooth]# connect 5C:F3:70:98:69:EC
Device 5C:F3:70:98:69:EC not available
[bluetooth]#
gatttool connecting to bluetoothServices. I have found that sometimes it terminates due to a registration timeout but if you power cycle the mangOH it’s ok.
BluetoothServices is a Legato application that implements a BLE server, i.e. peripheral. The name means that it implements certain BLE-defined services for a connected BLE client, i.e. host, as can be seen in the traces above. It does not provide anything to other applications on the mangOH. There is a bluetooth daemon which runs on Linux systems and supports all apps using Bluetooth but it’s not a Legato app itself.
I noticed this concerning the bluetoothServices app in the related README :
“Most of this code was originally written outside of the context of a Legato application, so the code is not formatted or named according to Legato style conventions.”
Does it mean that I cannot consider this app to help me develop on BLE?
They are just talking about the C coding style. The interface to BlueZ though glib is correct and it works. I used bluetoothServices as a starting point for my transparent UART BLE application.
Depends on what you are trying to do. My understanding is that bluetoothSensorTag is a BLE host (i.e. client) which communicates with a sensor tag device (i.e. server). bluetoothServices is a BLE device (i.e. server) which communicates with a host (i.e. client).
Ok. It is quite similar indeed. There is only the notion of proxy in bluetoothSensorTag. I you don’t mind it could be interesting to see your app you developed.
I cannot make our code public but I can tell you that the coding involved changing the service and characteristic definitions previously made within battery_register_services() in battery_service.c . You can see the changes in the output of gatttool posted about.
Also, what value take these values (services_om and num_services_registered)? It must come from somewhere to be injected in battery_register_services, right?
It appears that you could use L2CAP sockets with BLE. It’s a low level interface that doesn’t use D-Bus. I have never tried it.
battery_register_services() is found in battery_service.c and is called from primary.c . It sets up the service and characteristics and you would modify these to support a different BLE service.
Thanks a lot!! That’s helping a lot! I don’t understand how are introduced ‘io_AddNumericPushHandler’ or ’ dhubAdmin_AddNumericPushHandler’. Is it coming from a library?
These are Legato dhub routines that are defined in the api section of Component.cdef . They don’t have anything to do with Bluetooth itself, they are just used to periodically generate simulated
battery level data.
