Hi,
I see so many posts which start with “I want to transmit video using XBEE/Bluetooth…”, but I am wondering did anyone ever do that? Was anyone successful?
My goal is the same now, and I want to transmit data wireless to my PC. I am open for any solution like XBEE, Bluetooth or even Wi-Fi.
But my question is all about Camera, what data I should plan to transmit (format), and how I decode/interpret this data on my PC, once i receive it. How do I choose my camera module? How, after transmitting, I should be handling the data on my PC? Do I have to write my own USB driver for this?
PS: I am aware we have products in the market which can transmit AV data to base using RF (which again needs TV tuner card for PC), but I want to build my own and later extend the functionality.
Thanks,
Rahul
XBee and common Bluetooth are relatively low speed - too low for motion video.
Using WiFi, just buy a network camera, a.k.a. IP camera. These can be had for $50 and up. Some use wired ethernet; those with WiFi cost more.
Another way is to buy a video to USB adapter for your PC. Connect this to the receiver end of an analog video “sender”. Lots of these for sale. X10 has an infamous one, cheap-o-cheap. SuperCircuits.com has many others.
You could potentially push some very low bitrate video through the 2.4 GHz Xbee Pro.
It has a max data rate of 250 kbps, that’s 32 KB/s. Today’s video codecs can do reasonably well with as little as 5 KB/s average (I’ll provide an example if you wish). The problem you’ll run into will be the encoding process, i.e. you’d have to be able to encode the video on the fly using some sort of a powerful processor (ARM or the like; definitely not an Arduino).
The PC side will be easy, you’ll write an application that reads the USB serial port (no need for a driver) and outputs the raw data into a decoder. You could do that on Linux with a little more than a simple command like this: ```
cat /dev/ttyS1 | mplayer -
I recommend you use the x264 codec - it can fit a watchable 512x384 30 FPS video into 3 KB/s! And it's opensource so no problem porting it to whatever board you pick.
(and to answer your question: no, I haven't tried transmitting video over an Xbee, only 802.11)
theridane:
You could potentially push some very low bitrate video through the 2.4 GHz Xbee Pro.
It has a max data rate of 250 kbps, that’s 32 KB/s. Today’s video codecs can do reasonably well with as little as 5 KB/s average (I’ll provide an example if you wish). The problem you’ll run into will be the encoding process, i.e. you’d have to be able to encode the video on the fly using some sort of a powerful processor (ARM or the like; definitely not an Arduino).
The PC side will be easy, you’ll write an application that reads the USB serial port (no need for a driver) and outputs the raw data into a decoder. You could do that on Linux with a little more than a simple command like this: ```
cat /dev/ttyS1 | mplayer -
I recommend you use the x264 codec - it can fit a watchable 512x384 30 FPS video into 3 KB/s! And it's opensource so no problem porting it to whatever board you pick.
(and to answer your question: no, I haven't tried transmitting video over an Xbee, only 802.11)
That’s a very explanatory answer, thank you very much.
Yes, I would like to give it my best try. Will it be possible for you to guide me further? I am pretty new to using ARM (or something like it), and program it to encode the video signals.
Long range Video transmission would be a wonderful idea for me (and I guess Xbees are best for long range).
XBee 2.4GHz is 802.15.4 is 250Kbps raw bit rate. Like 802.11, the net yield is about 70% of that. Also, the packet sizes in 802.15.4 are just 100 bytes. So it’s not a good choice for motion video.
stevech:
XBee 2.4GHz is 802.15.4 is 250Kbps raw bit rate. Like 802.11, the net yield is about 70% of that. Also, the packet sizes in 802.15.4 are just 100 bytes. So it’s not a good choice for motion video.
Is it not the final transmission rate that matters?
70% of 125Kbps (one way) ~ 11KBps which should be good enough for “theridane’s X264 Codecs compression ratings”.
rahulrl:
stevech:
XBee 2.4GHz is 802.15.4 is 250Kbps raw bit rate. Like 802.11, the net yield is about 70% of that. Also, the packet sizes in 802.15.4 are just 100 bytes. So it’s not a good choice for motion video.
Is it not the final transmission rate that matters?
70% of 125Kbps (one way) ~ 11KBps which should be good enough for “theridane’s X264 Codecs compression ratings”.
the speed is 250Kbps both ways. But 802.15.4 like 802.11 is half duplex (cannot simultaneously transmit and receive; basic concept of the physical layer).
If X264 is like H.264, I doubt it can work at less than about 400Kbps of “goodput”, where that means the net yield, after the communications overhead AND whatever other overhead, like H.264 headers.
But moreover, 802.15.4 uses 100 byte packets whereas IP with UDP/RTSP in video streaming is typically 1400 bytes.
My experience with 802.15.4 is that the net yield is 120Kbps or less, depending on application protocol, and with no retransmissions for error correction, and no media access delays due to WiFi or other RF sources.
Using WiFi, just buy a network camera, a.k.a. IP camera. These can be had for $50 and up. Some use wired ethernet; those with WiFi cost more.
Another way is to buy a video to USB adapter for your PC. Connect this to the receiver end of an analog video “sender”. Lots of these for sale. X10 has an infamous one, cheap-o-cheap. SuperCircuits.com has many others.
rahulrl, unfortunately I’ve never tried pushing video through an Xbee. I just ran the numbers 
[Here’s a 30-second sample of a video compressed down to 2.75 KB/s - that’s 22 kbps. Something the Xbee should handle. It’s a rough approximation of how a video pushed through an Xbee would look like.
It’s using an x264 codec, 312x176 resolution, and running at 48 FPS. Note that the file is 4 KB/s - the extra 1.25 KB/s is added by AVI container overhead (something not needed for streaming).
At 24 FPS it would probably reach 1 KB/s and still look the same.](http://www.mediafire.com/?mqymigmyzm2)
312x176 frame size - yes. good. huge reduction in data volume, versus “video” which is commonly 640x480 pixels
stevech:
But moreover, 802.15.4 uses 100 byte packets whereas IP with UDP/RTSP in video streaming is typically 1400 bytes.
Steve,
Can’t we overcome this byte packet problem (have a buffer logic or something like that at the receiver’s end) ?
I would like to give it a shot, and more over, could you please let me know where I can find additional information on this byte packet requirements for different kinds of things, and any other releated information to help me understand this situation better?
Thanks.
rahulrl:
stevech:
But moreover, 802.15.4 uses 100 byte packets whereas IP with UDP/RTSP in video streaming is typically 1400 bytes.
Steve,
Can’t we overcome this byte packet problem (have a buffer logic or something like that at the receiver’s end) ?
I would like to give it a shot, and more over, could you please let me know where I can find additional information on this byte packet requirements for different kinds of things, and any other related information to help me understand this situation better?
Thanks.
The XBees implement 802.15.4. That gives the packet size as about 100 bytes. The XBee buffer about two packets, the one currently being sent or received and the one being sent or received via the UART.
The series 1 XBees (not series 2) in transparent serial mode, will stream data coming from the UART to the distant end XBee and out its serial port, though the air link is packetized. In the absence of noise and interference, you should be able to get an average rate of 80K bits/sec or so. Series 2 are ZigBee oriented and have high overhead.
With series 1, your best speed comes if you use these in peer to peer mode, no PAN coordinator, no association. Kind of like 802.11’s ad-hoc mode.
Steve,
Do you think this is doable? Worth spending some time and money researching it?
I will workout and try to come up with a plan, would love to pursue this and find a solution.
I am planning to go for the below model. Any suggestions or improvements?
Camera → FEZ Domino → XBee → … → XBee → PC (stream over USB)
Do I need an additional Arduino at the receiver’s end?
I chose FEZ Domino to compress/encode video because it sounded easy to implement the code/logic.
You don’t need an Arduino, an [Xbee Explorer USB will do.
Are you sure the FEZ has enough firepower to compress video (and the ability to read from a USB camera)?](http://www.sparkfun.com/commerce/product_info.php?products_id=8687)
A 600MHz ARM Cortex A9 is just barely fast enough to process VGA video at semi-interactive framerates (~10 FPS).
I’m afraid you’re an order of magnitude off with your chip.
Edit: by “process” i ment x264 encoding. There could be more efficient encoders targeted at low power platforms, like the [On2 for example. No experience with that one though.](http://www.on2.com/index.php?599)
The very first versions of Surveyor(Surveyor.com) had an LPC2103 ARM connected to a serial camera and an Xbee.
You could get 10 fps at 320x240 and even faster at lower resolutions.