3
\$\begingroup\$

I'm working a a project that currently works well but this year we want to expand it by collecting data from it, independent of its current functions. We have set up an iPad App to control an Arduino through Bluetooth. The next step is transmitting video through Bluetooth to the iPad.

With this question I would like to focus on how a microcontroller can send a video stream through Bluetooth. I can't seem to find any way to even start this project.

How do you interface the camera with the microcontroller?

How do you then send that stream over Bluetooth?

\$\endgroup\$
4
  • 3
    \$\begingroup\$ You likely won't be able to stream over bluetooth - not enough bandwidth. Any data transfer over bluetooth to an iPad is really tough as the type of data streams publically available are limited. Video over wifi is a better choice and off-the-shelf solutions already exist. \$\endgroup\$
    – spearson
    Nov 15, 2012 at 5:52
  • \$\begingroup\$ taking your guys advice and talking to my partner, it appears he already switched to wifi last week anyways. so using wifi, i made another question electronics.stackexchange.com/q/49045/15343 \$\endgroup\$
    – Tom Prats
    Nov 15, 2012 at 18:10
  • \$\begingroup\$ but can't he use a 32 pic, or a AVR microc controler for video streaming with a ttl camera (pic at fast rate)? \$\endgroup\$
    – user18923
    Feb 12, 2013 at 13:44
  • \$\begingroup\$ Anyone who comes here looking for an answer should check out Intel's new Curie microprocessor. The Arduino 101 uses it. I'm not yet sure if it can do it, but it's the newest tech right now. At ~$30 it has BTLE, gyro, and accelerometer built in. \$\endgroup\$ Apr 29, 2016 at 17:26

2 Answers 2

8
\$\begingroup\$

Unfortunately in my experience what you'll quickly find is that video is obnoxiously difficult to manipulate without a lot of cpu power. Let's start from the beginning: how much video do you want?

There are a lot of choices here, but start small. Let's say that, for simplicities sake, you wanted a 640x480 frame of 8-bit black and white video, at 24 frames per second.

That's 640*480 pixels = 307,200 * 8 bits per pixel = 307,200 kilobytes per frame * 24 frames per second = 7,372,800 bytes per second or ~7.37 megabytes per second

So that is a baseline for data throughput for a camera outputting raw frames, and that's not including sound or color. Now you have a few paths you can take: you can start encoding the video stream, or you can get a lot of bandwidth. I don't know the throughput of bluetooth, so I can't help you there.

Encoding unfortunately takes one of three things: a lot of processing power, or specialized hardware, or (possibly) FPGA knowledge that I also don't have. Encoding will reduce bandwidth concerns, but at a pretty hefty cost. You would need to research compression and whatnot to figure out whether you could even get this over your interface and still have the arduino do useful work.

If you want to connect a camera to a microcontroller you'll find that even simply taking stills can be a pain based on how the still frames are delivered. There was a sparkfun camera which gave jpeg frames but didn't have a fixed period for how long the encoding took, and then would suddenly start spitting out the encoded frame as fast as it could, and since the frames were too big to fit in RAM on the microcontroller it had to spend all it's time getting the frame and spitting it out over whatever interface they were using to transmit.

tl;dr: you should establish what you need and probably try and and figure out whether using the microcontroller as the go-between is the best choice.

Good luck! I hope that helps.

\$\endgroup\$
6
  • 2
    \$\begingroup\$ 7,372,800 bytes per second is actually just over 7.03 megabytes per second. Bluetooth is only rated at about 2.1Mbit/s or 0.26 megabytes per second. So you're exactly right to recommend an alternative, Bluetooth is not suitable for video. \$\endgroup\$
    – Samuel
    Nov 15, 2012 at 7:10
  • \$\begingroup\$ That would be 7.03 Mebibytes, would it not? Huzzah for weird semi-new binary prefixes... And as an additional comment: something you'll notice about a lot of designs for electronics using video is that they're frequently analog video, digital everything else. That's because it's a lot easier to not have to process anything and just have the person behind the controls do the hard work of interpreting the video. It's also because normally, not all the information is required, so lossy analog video is fine. \$\endgroup\$
    – Kit Scuzz
    Nov 15, 2012 at 7:39
  • \$\begingroup\$ Mebibytes, that is weird. IEEE is down with it, but Google isn't. I'm honestly a bit torn by that, I'm a member of both. \$\endgroup\$
    – Samuel
    Nov 15, 2012 at 8:01
  • 1
    \$\begingroup\$ The reason it's a problem is that there was a general perception in the community that kilo or mega, in front of "byte" meant that it was powers of 2. Then some unscrupulous individuals in some hard drive marketing group realized that they could sell in powers of 10 and not get sued for selling less space than was written on the box. Thus the discrepancy began, and because the usage "MB" on a hard drive is x10^6 bytes and not x2^20 and is technically correct by SI prefixes, a new prefix was created. The only point of using them now is for clarities sake in situations like these. \$\endgroup\$
    – Kit Scuzz
    Nov 15, 2012 at 8:12
  • 1
    \$\begingroup\$ By the way: is that bandwidth 2.1 Mibits/sec? Or 2.1 Mbits? The whole reason for the new prefix is to make sure that you shouldn't have to ask questions like this, but it'll be a long time before people start using them regularly. \$\endgroup\$
    – Kit Scuzz
    Nov 15, 2012 at 8:15
9
\$\begingroup\$

Bluetooth is a half-duplex radio technology that has a peak raw data rate of 1, 2 or 3 Mbps, depending on the specific modulation scheme being used. In practice, an application can get at most about 200 KB/s of data throughput.

Even if you reduce your video requirements to quarter-VGA (320 × 240) at 10 fps with 8 bits/pixel (768 KB/s), you'll still need to compress the data on the fly by at least 4:1 to transmit it in real time over Bluetooth.

That said, if this is still something you want to pursue, I would recommend looking at DSP chips as the microcontroller you select. Just as one example, the Analog Devices Blackfin (ADSP-BF561) is particularly well-suited to real-time video processing. The corresponding EZ-KIT is an easy way to get started with development.

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.