I am scoping out a small project and I am in need of a reality-check on basic framework. The project is a remote camera transmitting over zigbee to a pc-based receiver. After some research, I think this is what I need:
2 x zigbee units, one wired to the cam, 1 wired to the PC 1 x camera with UART interface
Steps:
- wire up the cam to the zigbee -- this is simply a matter of connecting the UART out of the cam into the UART input on the zigbee, correct?
- Connect the other zigbee to USB port on the pc (easy)
- make the zigbees talk to each other (per zigbee unit documentation)
- use Processing's "Serial" library to parse the info from the camera coming based on the camera's specs for the data structure for its visual frame output (the camera I am looking at outputs jpeg-encoded frames)
I would have to write a custom parsing script for this in Processing, correct?
- theoretically, the result from that should be an image in jpeg format, so at that point I am thinking that I could output the parsed data from Processing as a file, slap a "jpg" extension on it, and then I am in known territory.
Is this generally the right way to think about this?
Thanks very much for any help, advice, suggestions.
Consider the speed of your zigbee link and check it against your camera's specs. Zigbee may not be speedy enough to support real time video with the resolution you are looking for. You may have to settle for low resolution and/or a slow frame rate.
> I am scoping out a small project and I am in need of a reality-check > on basic framework. The project is a remote camera transmitting over > zigbee to a pc-based receiver. After some research, I think this is > what I need:
> 2 x zigbee units, one wired to the cam, 1 wired to the PC
> 1 x camera with UART interface
> Steps:
> - wire up the cam to the zigbee -- this is simply a matter of > connecting the UART out of the cam into the UART input on the zigbee, > correct?
> - Connect the other zigbee to USB port on the pc (easy)
> - make the zigbees talk to each other (per zigbee unit documentation)
> - use Processing's "Serial" library to parse the info from the camera > coming based on the camera's specs for the data structure for its > visual frame output (the camera I am looking at outputs jpeg-encoded > frames)
> I would have to write a custom parsing script for this in Processing, > correct?
> - theoretically, the result from that should be an image in jpeg > format, so at that point I am thinking that I could output the parsed > data from Processing as a file, slap a "jpg" extension on it, and then > I am in known territory.
> Is this generally the right way to think about this?
> Thanks very much for any help, advice, suggestions.
> - Michael
> -- > You received this message because you are subscribed to the Google > Groups "NYCResistor:Microcontrollers" group.
> To view this discussion on the web visit > https://groups.google.com/d/msg/nycresistormicrocontrollers/-/6Rqzhas....
> To post to this group, send email to > nycresistormicrocontrollers@googlegroups.com.
> To unsubscribe from this group, send email to > nycresistormicrocontrollers+unsubscribe@googlegroups.com.
> For more options, visit this group at > http://groups.google.com/group/nycresistormicrocontrollers?hl=en.
On Thu, Oct 4, 2012 at 4:59 PM, Michael Cooper <mbcoope...@gmail.com> wrote:
> Greetings Resistors,
> I am scoping out a small project and I am in need of a reality-check on
> basic framework. The project is a remote camera transmitting over zigbee
> to a pc-based receiver. After some research, I think this is what I need:
> 2 x zigbee units, one wired to the cam, 1 wired to the PC
> 1 x camera with UART interface
> Steps:
> - wire up the cam to the zigbee -- this is simply a matter of connecting
> the UART out of the cam into the UART input on the zigbee, correct?
> - Connect the other zigbee to USB port on the pc (easy)
> - make the zigbees talk to each other (per zigbee unit documentation)
> - use Processing's "Serial" library to parse the info from the camera
> coming based on the camera's specs for the data structure for its visual
> frame output (the camera I am looking at outputs jpeg-encoded frames)
> I would have to write a custom parsing script for this in Processing,
> correct?
> - theoretically, the result from that should be an image in jpeg format,
> so at that point I am thinking that I could output the parsed data from
> Processing as a file, slap a "jpg" extension on it, and then I am in known
> territory.
> Is this generally the right way to think about this?
I've looked at just about every type of consumer, security, and machine
vision camera out there, and don't recall seeing any that have a serial
interface. Firewire, ethernet, USB, or cameralink are your available
options.
Also, zigbee tops out at 256Kbps. A single raw 640x480 truecolor frame will
tale 3.6 seconds to transfer. With JPEG compression expect 1/10 of that.
You won't be pushing any meaningful video over zigbee any time soon.
I'd say your best bet would be to find an inexpensive network security
camera and a wireless bridge/client, and focus on the application side.
this webcam from DX seems to do well cross platform, because it doesnt inherently need directX (as most low-end ethernet based security cams do) - but you still need a way to screengrab the data and shove it into processing... syphon maybe?
> On Thu, Oct 4, 2012 at 4:59 PM, Michael Cooper <mbcoope...@gmail.com> wrote:
> Greetings Resistors,
> I am scoping out a small project and I am in need of a reality-check on basic framework. The project is a remote camera transmitting over zigbee to a pc-based receiver. After some research, I think this is what I need:
> 2 x zigbee units, one wired to the cam, 1 wired to the PC > 1 x camera with UART interface
> Steps:
> - wire up the cam to the zigbee -- this is simply a matter of connecting the UART out of the cam into the UART input on the zigbee, correct?
> - Connect the other zigbee to USB port on the pc (easy)
> - make the zigbees talk to each other (per zigbee unit documentation)
> - use Processing's "Serial" library to parse the info from the camera coming based on the camera's specs for the data structure for its visual frame output (the camera I am looking at outputs jpeg-encoded frames)
> I would have to write a custom parsing script for this in Processing, correct?
> - theoretically, the result from that should be an image in jpeg format, so at that point I am thinking that I could output the parsed data from Processing as a file, slap a "jpg" extension on it, and then I am in known territory.
> Is this generally the right way to think about this?
> I've looked at just about every type of consumer, security, and machine vision camera out there, and don't recall seeing any that have a serial interface. Firewire, ethernet, USB, or cameralink are your available options.
> Also, zigbee tops out at 256Kbps. A single raw 640x480 truecolor frame will tale 3.6 seconds to transfer. With JPEG compression expect 1/10 of that. You won't be pushing any meaningful video over zigbee any time soon.
> I'd say your best bet would be to find an inexpensive network security camera and a wireless bridge/client, and focus on the application side.
> -spec
> -- > You received this message because you are subscribed to the Google Groups "NYCResistor:Microcontrollers" group.
> To post to this group, send email to nycresistormicrocontrollers@googlegroups.com.
> To unsubscribe from this group, send email to nycresistormicrocontrollers+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nycresistormicrocontrollers?hl=en.
A frame or two per second would be plenty for my purposes so I think the zigbee bandwidth is fine. Do I have the architecture on the receiving/Processing side right?
Interesting. What are you doing with the received image? These CMOS chip
cameras can be pretty grainy/noisy, especially in low light.
> A frame or two per second would be plenty for my purposes so I think the
> zigbee bandwidth is fine.
If the resolution and image quality work for you, there isn't much more
than to interface it.
> Do I have the architecture on the receiving/Processing side right?
The camera's resource
page<http://www.electronics123.com/s.nl/it.A/id.3010/.f> includes
an Arduino sketch which models the protocol. I imagine you could adapt that
code work in processing. From what I can tell, once you initialize the
camera, and request a picture, it just spews a JPEG. Just write it to a
file, then reopen the file using whatever image handling tools processing
has.
I plan to use this to monitor some gauges on equipment in the basement from the 5th floor--power supply and range are issues, so zigbee seems well-suited (if I can get around the concrete floor). Plus it seems like a fun bit of tinkering, so if I can get it to work as a proof-of-concept, I will be happy, even if the image is poor. Thanks!
> Interesting. What are you doing with the received image? These CMOS chip > cameras can be pretty grainy/noisy, especially in low light.
>> A frame or two per second would be plenty for my purposes so I think the >> zigbee bandwidth is fine.
> If the resolution and image quality work for you, there isn't much more > than to interface it.
>> Do I have the architecture on the receiving/Processing side right?
> The camera's resource page<http://www.electronics123.com/s.nl/it.A/id.3010/.f> includes > an Arduino sketch which models the protocol. I imagine you could adapt that > code work in processing. From what I can tell, once you initialize the > camera, and request a picture, it just spews a JPEG. Just write it to a > file, then reopen the file using whatever image handling tools processing > has.
Generally speaking, the only time you want to use zigbee is if you *need* a mesh network. Point-to-point applications are better off using 802.15.4 or bluetooth or some other radio link.
> I am scoping out a small project and I am in need of a reality-check on basic framework. The project is a remote camera transmitting over zigbee to a pc-based receiver. After some research, I think this is what I need:
> 2 x zigbee units, one wired to the cam, 1 wired to the PC > 1 x camera with UART interface
> Steps:
> - wire up the cam to the zigbee -- this is simply a matter of connecting the UART out of the cam into the UART input on the zigbee, correct?
> - Connect the other zigbee to USB port on the pc (easy)
> - make the zigbees talk to each other (per zigbee unit documentation)
> - use Processing's "Serial" library to parse the info from the camera coming based on the camera's specs for the data structure for its visual frame output (the camera I am looking at outputs jpeg-encoded frames)
> I would have to write a custom parsing script for this in Processing, correct?
> - theoretically, the result from that should be an image in jpeg format, so at that point I am thinking that I could output the parsed data from Processing as a file, slap a "jpg" extension on it, and then I am in known territory.
> Is this generally the right way to think about this?
> Thanks very much for any help, advice, suggestions.
Now I'm confused: I thought zigbee used 802.15.4 and added an abstraction layer for meshing.
I suppose I could use a 802.15.4 device without the zigbee layer, but what is the downside to using zigbee here since it is (supposed to be) easy to set up?
On Friday, October 5, 2012 10:33:50 AM UTC-4, Tedb0t wrote:
> Agreed.
> Generally speaking, the only time you want to use zigbee is if you *need* > a mesh network. Point-to-point applications are better off using 802.15.4 > or bluetooth or some other radio link.
> —t3db0t
> On Oct 4, 2012, at 4:59 PM, Michael Cooper wrote:
> Greetings Resistors,
> I am scoping out a small project and I am in need of a reality-check on > basic framework. The project is a remote camera transmitting over zigbee > to a pc-based receiver. After some research, I think this is what I need:
> 2 x zigbee units, one wired to the cam, 1 wired to the PC > 1 x camera with UART interface
> Steps:
> - wire up the cam to the zigbee -- this is simply a matter of connecting > the UART out of the cam into the UART input on the zigbee, correct?
> - Connect the other zigbee to USB port on the pc (easy)
> - make the zigbees talk to each other (per zigbee unit documentation)
> - use Processing's "Serial" library to parse the info from the camera > coming based on the camera's specs for the data structure for its visual > frame output (the camera I am looking at outputs jpeg-encoded frames)
> I would have to write a custom parsing script for this in Processing, > correct?
> - theoretically, the result from that should be an image in jpeg format, > so at that point I am thinking that I could output the parsed data from > Processing as a file, slap a "jpg" extension on it, and then I am in known > territory.
> Is this generally the right way to think about this?
> Thanks very much for any help, advice, suggestions.
> - Michael
> -- > You received this message because you are subscribed to the Google Groups > "NYCResistor:Microcontrollers" group.
> To view this discussion on the web visit > https://groups.google.com/d/msg/nycresistormicrocontrollers/-/6Rqzhas... > .
> To post to this group, send email to nycresistormi...@googlegroups.com<javascript:>
> .
> To unsubscribe from this group, send email to > nycresistormicrocontrollers+unsubscribe@googlegroups.com <javascript:>.
> For more options, visit this group at > http://groups.google.com/group/nycresistormicrocontrollers?hl=en.
> Now I'm confused: I thought zigbee used 802.15.4 and added an abstraction layer for meshing.
> I suppose I could use a 802.15.4 device without the zigbee layer, but what is the downside to using zigbee here since it is (supposed to be) easy to set up?
> On Friday, October 5, 2012 10:33:50 AM UTC-4, Tedb0t wrote:
> Agreed.
> Generally speaking, the only time you want to use zigbee is if you *need* a mesh network. Point-to-point applications are better off using 802.15.4 or bluetooth or some other radio link.
> —t3db0t
> On Oct 4, 2012, at 4:59 PM, Michael Cooper wrote:
>> Greetings Resistors,
>> I am scoping out a small project and I am in need of a reality-check on basic framework. The project is a remote camera transmitting over zigbee to a pc-based receiver. After some research, I think this is what I need:
>> 2 x zigbee units, one wired to the cam, 1 wired to the PC >> 1 x camera with UART interface
>> Steps:
>> - wire up the cam to the zigbee -- this is simply a matter of connecting the UART out of the cam into the UART input on the zigbee, correct?
>> - Connect the other zigbee to USB port on the pc (easy)
>> - make the zigbees talk to each other (per zigbee unit documentation)
>> - use Processing's "Serial" library to parse the info from the camera coming based on the camera's specs for the data structure for its visual frame output (the camera I am looking at outputs jpeg-encoded frames)
>> I would have to write a custom parsing script for this in Processing, correct?
>> - theoretically, the result from that should be an image in jpeg format, so at that point I am thinking that I could output the parsed data from Processing as a file, slap a "jpg" extension on it, and then I am in known territory.
>> Is this generally the right way to think about this?
>> Thanks very much for any help, advice, suggestions.
>> Now I'm confused: I thought zigbee used 802.15.4 and added an abstraction layer for meshing.
> That's correct. ZigBee is mesh, "bare" 802.15.4 is not. The "S1" XBee modules (formerly known as "Series 1") are just 802.15.4. (Comparison chart: http://www.digi.com/pdf/chart_xbee_rf_features.pdf)
> Mesh networking adds lots of overhead since it has to maintain routes between nodes. The downside is throughput.
> ―t3db0t
> On Oct 5, 2012, at 12:49 PM, Michael Cooper wrote Now I'm confused: I thought zigbee used 802.15.4 and added an abstraction layer for meshing.
>> I suppose I could use a 802.15.4 device without the zigbee layer, but what is the downside to using zigbee here since it is (supposed to be) easy to set up?
>> On Friday, October 5, 2012 10:33:50 AM UTC-4, Tedb0t wrote:
>> Agreed.
>> Generally speaking, the only time you want to use zigbee is if you *need* a mesh network. Point-to-point applications are better off using 802.15.4 or bluetooth or some other radio link.
>> ―t3db0t
>> On Oct 4, 2012, at 4:59 PM, Michael Cooper wrote:
>>> Greetings Resistors,
>>> I am scoping out a small project and I am in need of a reality-check on basic framework. The project is a remote camera transmitting over zigbee to a pc-based receiver. After some research, I think this is what I need:
>>> 2 x zigbee units, one wired to the cam, 1 wired to the PC >>> 1 x camera with UART interface
>>> Steps:
>>> - wire up the cam to the zigbee -- this is simply a matter of connecting the UART out of the cam into the UART input on the zigbee, correct?
>>> - Connect the other zigbee to USB port on the pc (easy)
>>> - make the zigbees talk to each other (per zigbee unit documentation)
>>> - use Processing's "Serial" library to parse the info from the camera coming based on the camera's specs for the data structure for its visual frame output (the camera I am looking at outputs jpeg-encoded frames)
>>> I would have to write a custom parsing script for this in Processing, correct?
>>> - theoretically, the result from that should be an image in jpeg format, so at that point I am thinking that I could output the parsed data from Processing as a file, slap a "jpg" extension on it, and then I am in known territory.
>>> Is this generally the right way to think about this?
>>> Thanks very much for any help, advice, suggestions.
> -- > You received this message because you are subscribed to the Google Groups "NYCResistor:Microcontrollers" group.
> To post to this group, send email to nycresistormicrocontrollers@googlegroups.com.
> To unsubscribe from this group, send email to nycresistormicrocontrollers+unsubscribe@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/nycresistormicrocontrollers?hl=en.
