Arduino tones to earbuds via bluetooth

I am using an Arduino Nano to produce basic tones (high and low) and outputting to a small piezo speaker. That's easy, but I would like to send those basic tones to a bluetooth headset so you'd hear the tones in the headset rather than the piezo speaker. Is the general idea of that possible? I know I would need a bluetooth board, I was looking at the Bluno Nano since it has the same pin layout. Any advice would be helpful.

To pair and send audio to a headset you need a Bluetooth module that has an audio stack. Most arduino BT modules have a serial port protocol stack so you need to be sure of the BT module you get. I don't think (but not 100% sure) the Bluno is suitable as it mentions HID & iBeacon in the manual but nothing about audio. It does mention firmware update so maybe you can load an audio stack instead of HID.

Even if you had an audio stack, how would the Arduino send a sound? tone() won't work. The Bluetooth is expecting digital audio like the bitstream from a .wav file.

This seems like a tough problem to me. My first suggestion is to find a headset which comes with a transmitter, like grandpa might plug into the headphone jack on his TV.

Thanks for the replies. I thought it would be simpler, but looks like I'll need to learn a thing or two about bluetooth. Oddly enough this is for my grandpa. I made a device that he can attach to his walker and lets him know (by beeps) if he's near a drop off. (He doesn't see that well). Problem is, he doesn't hear that well either and it's hard to find a speaker that's loud enough. So I was hoping he could hear the beeps in a headset or ear buds. I'll keep thinking about this, thanks for your help.

Could you make it to go in a pocket and vibrate as the indication?

How about using something like this connected to something like this that's controlled by your arduino.
The arduino detects the drop (the more difficult thing in this project IMO) and triggers a suitable MP3 audio track/sound to play that the BT transmitter sends to headphones.

wildbill:
Could you make it to go in a pocket and vibrate as the indication?

I thought about that, but I didn't want him to deal with wires. But instead of the pocket I thought about attaching something with a vibration motor to the handlebar where he grips the walker. At least then he could turn it on and off from there as well, and wouldn't have to remember to put something on like earphones. I know that's probably the better solution than sending sounds via bluetooth (and easier). I just wanted to explore the bluetooth idea though.

Riva:
How about using something like this connected to something like this that's controlled by your arduino.

Thanks for the links, I'll definitely check that out, especially since those two pieces are so cheap.

Careful about those DFPPlayer modules!

I love them and use them a lot.. but be aware of CLONES (almost all of them) that do NOT use the YX5200 chip set.. but some generic version of said serial/audio chip..

I have found/read that they do not support looping and/or querying of the chip (current track, completed..etc)

if you do decide to use a DFPlayerMini, check out the optimized DFPlayerMini library.

This may be stupid, but I was reading about the HC-05. Could I connect one HC-05 to the Nano which also has the sensor I'm using for the dropoff detection (which is all attached to the walker), and then a second HC-05 to a second Nano which has a piezo speaker attached to it (attached to the head somehow), and then when a drop off is detected the first HC-05 (master I suppose) sends a signal to the second HC-05 (slave), which tells the second Nano to produce a tone through the piezo speaker?

I think I'll get a pair of HC-05s and test it out in any case since they are cheap enough.

1 Like

Yes that will work.

I got a hold of 2 HC-05s, and that does indeed work. I at least now have a working version of my original question. So thanks for all of the help!

Power_Broker:
if you do decide to use a DFPlayerMini, check out the optimized DFPlayerMini library.

This is your -new- library... (right?)

What has changed from the DF library? (as what are the main differences? why choose one over another?)

Also.. (I think at least) last time you mentioned no querying of the chip in your lib? Is that still the case?

Knowing when a track is complete or what track is playing..etc..etc..etc.. are great features.

Are they absent in your approach/lib?

If you have questions, you should check out the repo! :wink:

Querying is on the todo list, but the library has been updated to include all the commands have been implemented (previously only had a subset). If you're interested in these features and would like to use them with my library, I can bump it up on the todo list.

Even still, it works exceptionally well for basic MP3 functionality.

You are the author... why not just explain? :slight_smile:

ok.. so no querying (yet)..

What would be the main difference between the two libs then?

Why would/should someone pick one over the other?

xl97:
What would be the main difference between the two libs then?

Why would/should someone pick one over the other?

The original library is actual garbage. Very difficult to read/understand and seems to be extremely inefficient.

A few years ago I was working on a 3D printed RC Arduino tank with my roommate. We wanted to add sound to the vehicle so I decided to go with the DFPlayer and tried out the library it came with. Because of the unnecessary latency in playing/switching tracks I opened up the library to see what was going on. It was so difficult to understand I just decided to write my own simple library using the commands listed on the DFPlayer wiki. I've since expanded its functionality.

With my new library all functions have virtually no delay compared to the original one.

xl97:
You are the author... why not just explain? :slight_smile:

I write my code so that anyone (even a beginner) can understand it. I assume it will not be difficult for you to open GitHub, glance at the code, and have a good idea of how it works. It's really quite simple.

Delay!

That I understand.

For me.. I havent had issues with switching audio clips immediately.. (seamlessly)

But the querying of the chip to know exactly when a clip has completed seems very buggy.... so (for me) that would be a reason to switch and use exclusively once those features are added.