Can Teensy handle a camera?

Status
Not open for further replies.

BuckyKatt

Member
Hello.

Been very interested reading about Teensy, but I'm still new at this microprocessor stuff, so bear with my spotty ideas...

Since Teensy is considerably faster than the Arduino, I'm wondering if it has an interface that can keep up with a 4MP or 5MP camera taking a still picture. All I basically need is to get the Teensy to take the data and push it out over some sort of WiFi.

I would be extremely interested to use something like a OV5647 or OV4682, but I'm not sure exactly how to hook these up for maximum speed.

I would like to push 1.5~2MB of data in 2 or 3 seconds or less... but 5 or 6 would probably also work.

Any thoughts that might point me in a workable direction would be appreciated. Thanks.

BKNJ
 
I suspect it may be impossible for the Teensy, since it only has 64K of SDRAM (read/write memory), while the image coming off the camera would be much bigger (figure 12-15 megabytes of memory if the image is uncompressed by the camera). You would presumably need to buffer the entire image before sending it out via wifi. If you need to process it in any way, it is problematical to have to do it and shift it to/from temporary storage. In addition, if you need to do any image adjustment on the photo, it typically involves floating point, which the Teensy emulates in software.

It would be fairly simple to do this on the Raspberry Pi, using the Pi camera (or the faster 3rd party cameras that hook up to the same interface) and a wifi usb dongle. The Pi runs an order of magnitude faster than the Teensy (with 2 or 4 cores in addition to raw speed), has 256M - 1G of memory, hardware floating point, an off-board graphics processor, and the Linux networking stack is more mature. I've in fact done this, using the raspistill command to take a photo, and the ssh scp command to copy it to my laptop.

Or alternatively you might be able to get one of the wireless security cameras to deliver stills on demand (or get a video feed and extract still frames).

Now, you could use the Teensy to trigger a camera (which I've done in the past, and hoping to redo again for a Halloween hack), but I just don't think it is up to processing the image part of the equation.
 
Last edited:
Those sensors use 2 or 4 lanes of MIPI CSI-2 serial data interface. Mobile phone application processors and the Raspberry Pi have that kind of high-speed LVDS interface, the Teensy does not. You'd have to use a custom FPGA as an interface block which would be far more difficult / expensive than just using a R-Pi.

The Teensy could deal this with this type of camera, but it has far less resolution. http://www.adafruit.com/products/1386

The closest thing I've seen to what you want is the Arducam Mini project: http://www.arducam.com/arducam-mini-released/ which works with anything that has SPI and I2C interfaces.
 
Last edited:
The "2M LinkSprite JPEG" camera from SparkFun does look like it could work. But before you buy a camera, it's best to look at the image quality to see if it meets your requirements. In the SparkFun comments you can see someone who tested it:
Image taken by Linksprite: https://www.flickr.com/photos/timherzog/16187156492
Same taken by iPhone: https://www.flickr.com/photos/timherzog/16162104456

The OP mentioned the OV4682 sensor, but I've only seen one prototyping system available for that: http://www.e-consystems.com/OV4682-RGB-IR-MIPI-CAMERA-Module.asp?CU40
and that requires a USB3 connection.
 
Last edited:
I suspect it may be impossible for the Teensy, since it only has 64K of SDRAM (read/write memory), while the image coming off the camera would be much bigger (figure 12-15 megabytes of memory if the image is uncompressed by the camera). You would presumably need to buffer the entire image before sending it out via wifi. If you need to process it in any way, it is problematical to have to do it and shift it to/from temporary storage. In addition, if you need to do any image adjustment on the photo, it typically involves floating point, which the Teensy emulates in software.

Well, I didn't plan on doing any image manipulation, aside from sending some metadata along for the ride. As for memory, I've seen some circuits for adding memory to microprocessors to use... could Teensy interface with some FRAM?

As far as using a buffer goes, would a buffer be needed if I wrote to a SD card? Can one put together a buffer that is being read and written to at the same time... so the total time to get data from camera to WiFi is minimalized?

It would be fairly simple to do this on the Raspberry Pi, using the Pi camera (or the faster 3rd party cameras that hook up to the same interface) and a wifi usb dongle. The Pi runs an order of magnitude faster than the Teensy (with 2 or 4 cores in addition to raw speed), has 256M - 1G of memory, hardware floating point, an off-board graphics processor, and the Linux networking stack is more mature. I've in fact done this, using the raspistill command to take a photo, and the ssh scp command to copy it to my laptop.

Raspberry Pi would kill my power requirements (which I forgot to put into the OP... oops...). I would likely be running things off of battery or a small solar panel. Since this would need to be vandal-resistant, I'd prefer not to use a solar panel... or as small as possible.

Or alternatively you might be able to get one of the wireless security cameras to deliver stills on demand (or get a video feed and extract still frames).

Again, most of these seem to be quite power hungry.

BKNJ
 
Last edited:
Those sensors use 2 or 4 lanes of MIPI CSI-2 serial data interface. Mobile phone application processors and the Raspberry Pi have that kind of high-speed LVDS interface, the Teensy does not. You'd have to use a custom FPGA as an interface block which would be far more difficult / expensive than just using a R-Pi.

Yeah, I think this is part of my problem... is that I see various camera parts... but I'm understanding what has a workable interface.

The Teensy could deal this with this type of camera, but it has far less resolution. http://www.adafruit.com/products/1386

Yeah, saw that one... I wish someone made a higher resolution serial camera with a fast interface.

Or I understand how to make one. ;-)

The closest thing I've seen to what you want is the Arducam Mini project: http://www.arducam.com/arducam-mini-released/ which works with anything that has SPI and I2C interfaces.
[/quote]

I'm not sure how I missed that. Some of the stuff on the Arducam website drives me nuts. They rate SPI max speed at 8MHz... am I wrong if I read that as 8Mb/s? Again, I am WAY new at this.

It seems like the specs mention that its IR sensitive, so I'm thinking it has no IR filter. I wonder if this would work with the little IR LED add-ons they sell with the OV5647 camera...

This one works and could be attached to an ESP8266.

https://www.sparkfun.com/products/12804

What scares me here is the max 115200 baud rate. Its a shame they don't have a version of this that is a crossover with their low res IR camera. I find there camera boards a bit expensive, though.



Many things answered, and so many more questions brewing... ;-)

BKNJ
 
Right, SPI is a serial interface so SPI at 8 MHz gives you 8 megabits per second (max; probably minus some overhead, you may not be able to avoid some gaps between bytes unless you're running it via DMA controller). Teensy can actually do SPI faster than that ( https://forum.pjrc.com/threads/1156-Teensy-3-SPI-Basic-Clock-Questions?p=7915&viewfull=1#post7915 ), but the Arducam itself is apparently limited to 8 MHz SPI.

I have not seen any actual still image examples online taken by this Arducam Mini project, which would worry me... if they looked good, presumably there would be some you could download.
 
You can use a SD card/FRAM memory/etc. as a buffer, but you have to factor the time to write the buffer and later read it back in. It will make the code much, much more complex. Speaking as somebody who used to work on compilers on 16-bit host systems, a lot of the hair in doing anything on those systems was dealing with non-resident memory, and having to organize things so that you did not have to repeatedly have to read the whole data structure, over and over again. So, yeah it might work. But it might take a lot of time to implement (assuming you are an experienced programmer, if you aren't then you will need to learn quickly) that you have to judge whether it is worth it.

In terms of power, running the camera, writing/reading from a SD card, and sending out wifi signals will suck power.

You might want to think about learning how to program on Android or Iphone systems, and use an old phone as your starting platform (though given phones only last a day or two on current batteries, it may not meet your needs).
 
You can use a SD card/FRAM memory/etc. as a buffer, but you have to factor the time to write the buffer and later read it back in. It will make the code much, much more complex. Speaking as somebody who used to work on compilers on 16-bit host systems, a lot of the hair in doing anything on those systems was dealing with non-resident memory, and having to organize things so that you did not have to repeatedly have to read the whole data structure, over and over again. So, yeah it might work. But it might take a lot of time to implement (assuming you are an experienced programmer, if you aren't then you will need to learn quickly) that you have to judge whether it is worth it.

I am a experienced programmer, among other talents, I'm just not used to working at this level of hardware... so I'm not quite clear just how much functionality there is on these microprocessors.

I'm doubting that I can just start two processes... one reading from the camera to some sort of FIFO and one reading from the FIFO to push out on WiFi.

In terms of power, running the camera, writing/reading from a SD card, and sending out wifi signals will suck power.

You might want to think about learning how to program on Android or Iphone systems, and use an old phone as your starting platform (though given phones only last a day or two on current batteries, it may not meet your needs).

Well, I understand the WiFi and camera will use juice, but I'm hoping to be able to leave things in low power mode as much as possible. It will use a lot less power that a phone or Raspberry PI. Plus I can't add 6 smartphones to my contract and visit them every few day miles out in the woods.

The reasoning is that I currently have a $140 trail cam that can do much of what I want to do and it lives about 9 months on 8 AA batteries. I want to upgrade to a live system that have wireless trail cameras that talk to a wireless AP that is hooked to the internet... it also runs for months (supposedly) on a small pile of AA batteries... _but_ it costs $500 for the AP and $250 for each camera (which I'd need about 6)... and the reviews are awful. It can be done, its simply my opinion that I can likely roll my own system for a fraction of the price (not counting my labor) and have a better system... plus I've wanted to do a microprocessor project for quite some time.
 
a wireless AP that is hooked to the internet... it also runs for months (supposedly) on a small pile of AA batteries...
With some miles of range? That is interesting if true. If there is any significant data traffic through the AP, I would not expect battery life could be that good, whether it is based on a cellphone system or a long-range wifi repeater. Bluetooth devices might do that, at short range and low data rates.
 
I agree - lots of data will use lots of power. If pictures are rare (say triggered by infrared motion detection), then maybe. A solar panel charger might be another option.
 
With some miles of range? That is interesting if true. If there is any significant data traffic through the AP, I would not expect battery life could be that good, whether it is based on a cellphone system or a long-range wifi repeater. Bluetooth devices might do that, at short range and low data rates.

Sorry to imply the WiFi is going over miles... they aren't... the site is miles out... with no power... but it does get cellular. The WiFi cameras are 100~400 feet from the AP.

That said, the company selling the units is probably stretching the truth concerning range and battery longevity. That's why its getting awful feedback and reviews. There are units that are well reviewed, but the costs are prohibitive.

I agree - lots of data will use lots of power. If pictures are rare (say triggered by infrared motion detection), then maybe. A solar panel charger might be another option.

Pictures had better be rare. Most of the time I get 50~75 a month... but the existing unit does not have the ability to really fine tune its sensitivity.

I would prefer to not put solar panels on the cameras, as they can be vandalized. However, I will almost certainly put a solar panel on the main AP, since it will be easier to hide/secure.

In the end, I feel power use will be less than using a RPi...

BKNJ
 
Status
Not open for further replies.
Back
Top