Profiles
Bluetooth profiles provide different types of services, such as Hands-Free Profile (HFP), Headset Profile (HSP), and Serial Port Profile (SPP) on top of a core set of Bluetooth capabilities. In general, they are not tied to a particular hardware implementation since they are implemented in firmware. Sometimes a particular profile will have hardware associated with it, for example the Advanced Audio Distribution Profile (A2DP) will usually have a stereo codec but most profiles do not require extra hardware.
Profiles are defined and adopted by the Bluetooth SIG. This article in Wikipedia defines 28 different profiles. Most modules implement many but not all of them.
Classes
Generally, hardware differences in Bluetooth devices are more associated with the class of the device:
- Class 1: 100 mw or 20 dBm, range approx. 100m
- Class 2: 2.5 mw or 4 dBm, range approx. 10m
- Class 3: 1 mw or 0 dBm range approx. 1m
(seldom used)
Some manufacturers have modules that fall between Class 1 and 2, i.e. they have a longer range than Class 2 but don't have the power amplifier (PA) needed by Class 1. These are informally sometimes called Class 1.5 but that is not a standard term nor defined by the Bluetooth SIG.
As mentioned in a comment below by Kortuk, some manufacturers pay for a higher class but then actually radiate a lower level of power. So check the power level in the module's specification.
Core Specification Level
These classes are often confused with the core Bluetooth specification level, which may be 1.0 (original), 1.1 (1st IEEE standard), 1.2 (many enhancements), 2.0+EDR (enhanced data rate, released in 2004), 2.1+EDR (simple pairing enhancement, 2007), 3.0+HS (high speed, 2009) or 4.0 (low power, 2010). Most current devices conform to level 2.1.
Note that classes (1,2,3) have a single digit and specification levels always have a decimal point and tenths digit (e.g. 1.2, 2.1).
Since the specification levels are also defined by firmware, older devices can often be updated to support a newer level of the specification, except where new hardware features are supported. Levels in general are backwards compatible; the same profile may exist on several different core specification levels (with perhaps different capabilities), depending on when it was first introduced.
Other differences
Besides the Bluetooth class, another major difference between modules is whether the module supports the higher level profiles internally, or just provides a low-level Bluetooth Host Controller Interface (HCI), which means the host microcontroller must implement the Bluetooth software stack. Although these modules are generally a few bucks cheaper, since the processor requirements for the Bluetooth module are lower, this generally is a lot of work unless you have a Bluetooth stack provided by the manufacturer of your microcontroller, or you are doing a high-volume product where you can amortize the cost over many units. You may also need to go this route if you need to support profiles not implemented by the module.
Whether implementing a high or low-level interface, Bluetooth modules may physically connect with the host microcontroller using either a UART, SPI, I2C or SDIO interface -- another potential hardware difference. A few modules allow you to run additional applications of your own on them, so that you can get by with not having to have a separate microcontroller in the your system.
Here is an example of five different Bluetooth modules (i.e. different hardware), all running the same core Bluetooth specification (2.1) and the same 14 profiles (except the one with an HCI interface) but providing different hardware features as described above.
Has anyone done any work in this field?
Wireless data acquisition is quite common in many different industries. I am doing some work in industrial computing and am actually using both bluetooth and cellular data networks simultaneously in an embedded solution. Just google something along the lines of "Sensor Data Acquisition" and you can find a plethora of articles.
Can you give me any information on what works and what does not?
I could give you information on what worked and didn't work with my specific application - but beyond that I wouldn't be helpful. The problem is this question is incredibly vague and you would need to specify operational constraints, design specs, goals, etc in order for any of us to give you an idea of what you need to head. Luckily however I can kind of point you in the right direction.
You are doing something that has been done many different times and in many different ways - use that to your advantage. Before you design anything you need to explicitly record what you are trying to accomplish. From there you can start designing. Generally speaking this project is going to be broken up into generic parts:
Device Communication
How exactly does your device need to be communicated with? You need to understand what protocol it uses and the hardware needed to communicate with it. Once you can get data back from your device you have your foot in the door and are ready to go.
Data Transmission
Once you have your data are you going to send it in raw form? This could be in binary, hex, octal, etc. Or are you going to put it into a nice parse-able XML format that separates sensors and registers into a logical grouping.
Data Viewing
How are going to view this data? Are you going to just use a Bluetooth serial link and read off of it like a virtual serial port? Is there going to be an intermediary database? Etc.
Will the electrical fields from the motorcycle engine interfere with
the Bluetooth data?
There is a good chance that the loud signals from the ignition,alternator and other noise generators could affect your device. But like we said above, this has been done before so there is tons of information out there on EMI shielding, EMI measurement techniques etc. Also, many different types of modular EMI enclosures exist to house your project.
In Conclusion
Figure out what you want your project to do and how you want it to perform. Don't be afraid to do some research, even if you don't know exactly what you are looking for. Here are some good starting points though:
Best Answer
This is the RX bandwidth very rough estimate: We have to assume few assumptions:
Bluetooth 5 datarate can be anywhere from 250Kbps to 50Mbps. Lets pick a reasonable 2Mbps, that gives a rough duty cycle of 12.5%. Actual duty cycle will be higher (protocol overhead, network overhead).
TX Bandwidth will be lower than that, it is mainly control and network management frames. Usual keep alive period for a BT device is 1 sec, but it is highly dependent on the device and power saving settings.