Bluetooth module and Teensy 3.1

Got for cheap some BT modules from LC Technology (not sure what model are they); and was wondering if they will work with Teensy, and how well they would actually communicate with a computer (planning to make a BT controller).

Does anyone has some info about such Bluetooth boards? IS there a library to use them, or they just go on the serial to send and receive data?

Bluetooth alone does nothing.
You need to choose a Bluetooth Profile such as serial data. With that on both ends you can exchange UART-type serial data. Called SPP.
Here's one of many vendors: http://gridconnect.com/industrial-w...|30488552353&gclid=CIbk0861iMECFU1cfgod8YoAeQ

Bluetooth not the best way to communicate data to a computer, esp. if there is a start topology - many-to-one and vice versa.
But it can work for simple cases.
Be aware too of the Bluetooth classes and the transmitter power for each, and thus the line of sight range.
And study up on BLE, the latest.

Got some homework to do?

Guess so thanks for the pointers

Does the data sheet contemplate the power for the BT module? Or is there a way to figure it out with a multimeter?
This is the guy that I am trying to use:
http://www.amazon.com/HOSSEN®-Bluetooth-Transceiver-Arduino-Antenna/dp/B00B1P1RGO

I have found a video on youtube, that show one of these BT module, but it is hooked up to a terminal program on Android, while I would like to use my mac to send and receive the data. Got plenty to read now, and hopefully I can make some sense of it.

I am aware that is not the greatest of the communication methods; but mostly I need to send in real time only numbers coming out from the buttons pressed on the controller; at most I may send 4 concurrent signals, which seems to be in the realm of feasible for BT transmission rate.

Thanks again !

Look at Bluetooth Class I, II, III. Each defines transmitter power.
BLE may differ; I've yet to study it.

An alternative to Bluetooth which is at 2.4GHz are the $4 FSK radios with smart packet controllers, encryption, addressing, etc.
see
http://www.anarduino.com/details.jsp?pid=145
and this really simple wireless serial UART extension http://www.anarduino.com/details.jsp?pid=138

It is a bit more pricey, but am I correct in believing you can just use the BlueSMIRF silver (https://www.sparkfun.com/products/12577) with the teensy 3.1? All you have to do is connect any of the serial rx and tx pins to the bluetooth module and everything should work fine?

Yes that module you can communicate to it over standard UART, and send a load of AT commands.

You might want to look at https://www.adafruit.com/product/1697 which is a SPI based BLE (Bluetooth4) device.

I want the teensy to basically receive the data via bluetooth and then dma the data from internal memory to gpio pins. I am going to be sending notes (16 bit data) over bluetooth to be dma'ed. Do you think this is better done via standard UART or using SPI and BLE?

What bitrate? The full 1meg of bluetooth or slower?

If your going full bitrate, then SPI for sure, UART will be more error prone. If your going slower under 115k then UART. At that speed, you don't even need to use the DMA.

I have not done the calculation yet, but it would be the highest frequency of 6 possible strings on a guitar (the 12th fret of each string). I believe there is a chance to reach the full bitrate.

Oooh interesting. Now you have peeked our interest. Please share your project when done, would be interesting to see.

So i just looked it up and it seems that if all 6 strings were played at the same time at its highest frequency (12th fret), it would never exceed a total frequency of 4 kHz. With this, I do not think I should need to use SPI, but I think DMA might still be a more efficient way to transfer the data (I'm new with teensy and using multiple channels of dma).

Yes but what else would you be using the teensy for?

If for nothing else then your can quickly and easily manipulate the io ports with the cpu vs the dma. Not saying that you should not look at doing it with the DMA, it's just a lot easier to code with the cpu than the DMA at the moment, until Paul releases his "DMA simplified for Noobs like me" Library

I mean int a=Serial.Read(); PortA=a; rinse and repeat. Can't be simpler than that!

I plan on having my teensy connected to a 6 channel (one for each string) analog synth. I believe I will have to have to go from gpio pins - shift reg - dac - channel of synth.

I believe that this deserve a new post; instead of highjack this one

Here is a post I started:

http://forum.pjrc.com/threads/26848-Streaming-Data-to-Analog-Modular-Synth-teensy-3-1

If you would like me to add more information about the project please let me know.

Thanks; in this way we don't mix up the posts. It sounds really interesting what you are planning to do.

I have used the BT device you linked to communicate serial data to my PC at 38400 ish. If my memory serves me correctly I had to set a strange speed to get it to work but apart from that it did what I needed it to.

So you are not limited to 9600?

My HC-05 chip is specifying to use 9600, or there could be incorrect transmission of data. I didn't experiment much on the subject honestly, since so far, 9600 is fine for me.

If you look at this page https://www.pjrc.com/teensy/td_uart.html you can see that if you are using a teensy 3.0 or 3.1, you should have no incorrect transmission of data up to a baud rate of 38400. I guess this would be why if someone is planning on using a higher baud rate, they should probably use SPI instead of UART.

zwm215 said:

If you look at this page https://www.pjrc.com/teensy/td_uart.html you can see that if you are using a teensy 3.0 or 3.1, you should have no incorrect transmission of data up to a baud rate of 38400. I guess this would be why if someone is planning on using a higher baud rate, they should probably use SPI instead of UART.

Click to expand...

The problem is not the UART transmission, but the Serial+Bluetooth. That page refer to the Teensy, not the HC-05

If the module is not rated for such speed, you are introducing the chance to loose data, because the transmitter can't do its job.

I will try to push it to the max limit and report my findings.

deelaleo said:

The problem is not the UART transmission, but the Serial+Bluetooth. That page refer to the Teensy, not the HC-05

If the module is not rated for such speed, you are introducing the chance to loose data, because the transmitter can't do its job.

I will try to push it to the max limit and report my findings.

Click to expand...

The device you have can communicate at speeds upwards of 382400, depending on which firmware is loaded. It is capable of very high rates of throughput.

It can easily match the highest rate the teensy uart can throw at it.

I use them a lot. Don't fuss too much about error rates, just push it up to the rate you need for the data you need to xmit.

It is an SPP device, purely meant for TTL traffic.

Thanks for the hint, Mike!

I did not run yet some data consistency test, to find out which is the limit; so I want to play safe, and most of the articles online suggest to use values that does not go higher than 40k baud.

Since this is UART, I am not aware of how do you actually check for consistency, since it is a much more rudimentary protocol, compared to I2C and SPI I believe.

deelaleo said:

Thanks for the hint, Mike!

I did not run yet some data consistency test, to find out which is the limit; so I want to play safe, and most of the articles online suggest to use values that does not go higher than 40k baud.

Since this is UART, I am not aware of how do you actually check for consistency, since it is a much more rudimentary protocol, compared to I2C and SPI I believe.

Click to expand...

UART is hardware, not protocol. I2C and SPI are buses. But... I see where you are coming from.

The protocol involved is Bluetooth 2.1EDR. It's pretty robust. The hardware is similarly robust - breaking bytes into bits, transmitting them serially and re-assembling them at the other end.

Be careful of articles that are talking about software serial implementations as opposed to hardware UARTs - the performance and reliability is very different.

On the Teensy3.1, there are three hardware UARTs - use those whenever possible. Obviously you only need to set the rate as high as the traffic you need to transmit (or receive).

If you are looking to find the highest rate the module can do, you will need to factor in a whole range of other stuff - like range, antenna design, voltage, host processor, etc.

The BC-417 module in the 'HC-05'-type bluetooth SPP modules marketed for hobbyist Arduino/maker use can transmit 1.3Mbps on its in-built UART. Bluetooth 2.1EDR can transmit 3Mbps between Bluetooth devices, in theory, but in reality it works out to 2.1Mbps (no relation). The Teensy can, like the Arduino, accept any number as a baud rate and 2Mbps has been achieved with a Mega, reliably. You just need to work out the trade-off between error rate and transmit speed.

And don't confuse error rate with false data - if it errors, it gets retransmitted. When you push the rate so high you introduce lots of errors, your effective baud rate actually goes down due to the retransmits. Also, you need to factor in the devices you are talking to and their maximum rates.

Windows, for example, has a relatively low maximum, completely unrelated to the actual hardware it is running on.

This is a good primer on asynchronous serial protocol. https://learn.sparkfun.com/tutorials/serial-communication

This is a good primer on serial protocol error correction: http://en.wikibooks.org/wiki/Serial_Programming/Error_Correction_Methods

But... Bluetooth itself will do the error checking and correction for the wireless link and the uart-to-uart connection will be 'free' from any but the most primitive ACK-NACK checks and responses.