Choosing between BLE and Bluetooth "Classic"

Projects General Guidance
1

Question: Looking for guidance on continuing with Bluetooth "Classic" or switching to BLE in my project.

Project description: There is an Arduino sampling 5 different pins, doing Analog-to-Digital conversion, at a rate of 200 Hz. This data is then transmitted via Bluetooth to an Android application which records and plots the data. Ultimately, I hope to achieve this with a battery powered Arduino for >10 hours at a time, in a small form factor. If I've done my math correctly, this corresponds to transmitting ~4.2KB/s*. Data-rates could go higher, but probably not more than twice as much.

Current Status: I started prototyping with an UNO and HC-05 (BT 2.0 transceiver), which connects to an Android app written using Flutter. I simply used Serial.Write to transmit the data and this has worked succesfully, barring some unusual noise.

Recently purchased some Nano 33 IoT, which according to the documentation, supports BT "Classic" (v4.2) and BLE . To my dismay, BT "Classic" is not enabled by default and requires some flashing.

Maybe now is the time to switch to BLE as it would help with battery conservation. The first reason for not switching is the Android App has already been written for BT "Classic" and I've no idea the amount of work involved to change the back-end to work with BLE. In addition to this, the guides for flashing the Nano IoT to get BT "Classic" to work are not straight forward (to me). Ultimately, I want the project to be optimal, so if it requires more work now, so be it.

Concerns:

  1. Because of the data rate, switching to BLE does not really offer any significant improvement in energy conservation, and therefore is extra work with no benefit.

  2. Is there any difference in security between BT Classic (v4.2) and BLE?

Thanks for your help in advance!

*Math for above: 4.2KB/s = ( (5 pins * 4 bytes/pin) + start byte for transmission sequence) * 200)

2

why is the A to D conversion 4bytes/pin - I would expect 12 or 10bits ?
the would be two bytes/pin - you could also compress the data
what A to D precision do you require?

in a recent project I used BLE to reduce power consumption in a battery powered system- however, did have problems with BLE range and PCB layout

note that the Android application will have to be rewritten for BLE

3

I´m not a specialist on the topic, but I´ll give you my opinion anyway, based on a single project that I´ve developed (a dynamic BT scale to act as an uroflownmeter).

I followed the same steps you did. Started with UNO+HC-05 and then bought Nano IoT 33 to make the project portable. When I decided to do it, I was unaware that Nano 33 works with BLE, not classical BT.

I decided to go ahead anyway, but I had difficulties migrating from BT to BLE, because BLE is harder to deal with. It´s way of working is quite different from common BT.

It also brings some limitations on the amount of information that can be transferred. It was not a problem in my case, because the scale was transferring a single data each 0.5s for a total time of 1 minute on each run, but you may take this into account if you decide to go ahead using BLE.

I ended up finishing the project in an ESP32 with BT Classic.

4

Hopefully, this doesn't becoming a sticking point in this thread. I'm more concerned on which BT to use. You are correct that analogRead() stores the 0-1023 int as 10 bits (0-4095 int for 12 bits). But when transmitting over BT using the HC-05 I use:

Serial.Write(val)

where, from Arduino References, val : a value to send as a single byte.

For each ADC, the Arduino produces an int between 0-1023, which I convert to a "voltage" from 0-5, and then convert to a String. I have decided in this case to go to three decimal points of precision, so that each measurement is X.XXX (ie. 1.342, 2.892, 4.121, etc.). I then do a Serial.Write for each character in a measurement, skipping the decimal.

In the case of '1.342':

Serial.Write('s'); // Start BT transmission
Serial.Write('1');
//skip decimal
Serial.Write('3');
Serial.Write('4');
Serial.Write('2');

Each of these Serial.Write is 1 byte, so there are 4 bytes for each measurement. Obviously, I use loops and conditionals to do this.

To go more in depth and answer these questions preemptively:
(1) Why do you convert to a voltage (0-5) when you already have an int (0-1023)?
(2) And then why do you convert to a string?

To keep the transmission easy for the Android App, I send all the data in one go with a single starting character. For example: 'starting character', 'measurement 1', 'measurement 2', etc. On the receiving end, the expectation is that each measurement is exactly 4 characters long. Otherwise, measurements will get mixed up. The problem with using the int 0-1023, is it's possible to get values that are less than 4 characters long, anything less than 1000 in fact. The most efficient solution I found was simply converting this to a voltage between 0-5, but other multiplication scales will work just as well. I also did try front padding the int value with zeros, but this consumed more energy.

Just to give some examples so this is clear. If my measurements are the follow, and sent as such:

Measurement 1 = 1022 or 4.906V
Measurement 2 = 900 or 4.320V
Measurement 3 =  1010 or 4.848

Then on the receiving end these will be seen as:

'1022', '9001', '010' 
OR  
'4.906', '4.320', '4.848

You will notice for the non-voltage measures, the 2nd measurement, and therefore following measurements are wrong.

String conversion of the voltage is done to just loop through the values instead of doing loads of Serial.Writes.

5

I appreciate this comment, as after 2 days on this, I was already starting to look into switching to an ESP32 w/ BT. Encouraging to know I'm not the only person who encountered this and we're following similiar solution pathway.

6

I've worked with both BLE (Bluetooth Low Energy) and Bluetooth Classic, although I've rarely used Classic in the last 5 years. The only real similarity between the two is the name! They are very different protocols and the similar name leads to confusion all the time.

If you already have working code , the best suggestion I have is to either put the Nano into Classic mode or continue with the HC05. I have not used the Nano IoT so I don't know how complex this is. The communication code on both sides will need to be completely changed if you switch to BLE.

Using BLE isn't really "hard" but the concepts are different and I have seen people struggle with making the switch in mindset.

7

if you are not worried about power consumption stay with Bluetooth Classic as the application already works - converting to BLE could be a major task
I was dealing with a battery powered wearable system and battery lifetime between charges was critical. ADC data was transferred every second as a 1024byte array containing raw 12bit values compressed to use the 'spare' 4 bits of every sample. Having to implementing both the microcontroller and Android programs enabled development of a suitable protocol.

8

For an exercise like this, BLE is more trouble than it is worth. Indeed, it is probably unsuitable for your needs. About the only good reason for ever using BLE for this sort of thing is all the fake HC-05s out there, while I have never heard of fake BLE. You already have a working HC-05, so this does not apply.

9

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.