AGT BLE Support - using v2.1 of the Apollo3 core

[PaulZC]

I would like to use this issue to define how I should implement BLE on the AGT. As current or future users of the AGT, this is your chance to define how you want to be able to interact with the AGT over BLE.

Any new examples I write for the AGT, using v2.1 of the core, will use the ArduinoBLE library to provide BLE functionality.

The biggest question is: how do you want the features of the AGT to be mapped onto the services and characteristics of BLE?

Or, more simply, what you you want to be able to do using BLE on the AGT?

Will you be carrying the AGT with you, paired with your phone or laptop, and want to be able to use it as an Iridium modem for sending and receiving messages? Perhaps with a simple way of copying in or attaching the data from the GNSS and pressure/temperature sensor, but the main focus being free text which you type manually?

Or, do you want to be able to use an App or a Java-enabled web browser page to be able to configure the AGT before you deploy it? Think Example16 but where the configuration is done over BLE instead of - or as well as - using the configuration tool?

Or, the simplest option for me, is just to get the existing examples working with v2.1 of the core and not add any new BLE examples - leaving that up to you?

Without guidance, my plan will be to concentrate on:

• upgrading the examples so they work on v2.1 of the core
• when time permits, add an additional example to which adds configuration via BLE to Example16

and not concentrate on any examples showing how the AGT could used as a phone/laptop accessory.

Over to you!

Best wishes, Paul

[jerabaul29]

My personal 2 cents: I am mostly interested in:

• being able to use bluetooth for configuration as you say (I guess setting some simple parameters, getting the parameters to double check them, etc)
• being able to use bluetooth to "check functionality and health". For example, when the AGT is embedded in a large oceanic buoy, and access is a bit inconvenient, would be great to be able to ask for a "heartbeat" that the thing is well and alive just before deployment
• being able to send some data in real time from the AGT to the receiving bluetooth device. For example, sending a few floats (heave, surge, sway, yaw, pitch, roll in my case) at a frequency of 10 Hz. That would be very convenient for a wide variety of "debugging" purposes of the final instrument
• similarly, being able to 1) send quite a bit of magnetometer data, 2) get back some soft and hard iron configuration value, in order to be able to perform fully "sealed calibration" of built-in magnetometer for some instruments based on the AGT. That would be really great, i.e. be able to do a careful magnetometer calibration in the "true, final" configuration including all components and magnetic disturbances

Another possible application would be, if possible (but that would require the possibility to have a "super, super low power mode"), to use the bluetooth as "on / off" switch between a super low power mode (where only bluetooth is available, maybe looking once a minute for a wake up signal or something like this and sleeping otherwise), and the "normal, working mode". Currently I use a reed switch for that (advantage: guarantee that 0 power consumption when turned off; disadvantage: yet a component to source, put in place, and something to test before deployment).

[PaulZC]

Thanks JR, A lot of what you are requesting depends on additional hardware and sensors - and is very application-specific. I'd like to concentrate on what you need from the AGT as-is - without extra bells and whistles attached. But I can certainly look at implementing a software switch of some kind to disable BLE functionality just before you deploy. Please keep the ideas coming. All the best, Paul

[jerabaul29]

I agree with you. Sorry, this may be a bit too specific, and the idea was never that you would implement all of this of course :) (should have been clearer :) ). What would be amazing from my side is if you could provide some building blocks / examples that make it easy for me to implement these points on my specific application.

I guess this would mean:

• data in both directions of the BLU, making sure "reasonable data rates" can be consistently achieved
• a "super low power mode" checking periodically through the BLU if it should wake up to a higher power mode

[razvandragomirescu]

For our particular use case, we simply need to send and receive binary messages, nothing else. We are not (currently) using the GPS or any sensors on board the AGT. We have these fixed (kiosk-like) terminals that are based on Android (so have BLE on board) and normally communicate back to base using GSM or 3G, but some locations are without terrestrial coverage while others have intermittent coverage (moving boats for instance) or could lose connectivity in case of natural disasters.

We can code our own application on the Arduino side because it may retry sending by itself multiple times or receive and store incoming messages even when the Android terminal is disconnected.