SparkFun Forums 

Where electronics enthusiasts find answers.

Have a good idea for a new product for SFE or Olimex? Let us know!
By artem88
#96022
Dmitri wrote:I hope you can get a replacement.
On what basis? I'm sure I killed it with ESD. Because I perfectly remember all the time I worked, I always discharged on house heating battery. But yesterday it was first time when I finished erecting work and loundged on armchair for coding. My fluffy cat jumped on my knees and I stroked her a long enough. Then I turned off my device and computer and went sleep. It was last time my cam worked... Now I'll use antistatic wrist strap...
By KreAture
#96026
This happens sometimes to one of my cams too. To get it working again I have to disconnect power to it for a bit, then restart my app and re-init the camera.
By Dmitri
#96027
artem88 wrote:
Dmitri wrote:I hope you can get a replacement.
On what basis? I'm sure I killed it with ESD. Because I perfectly remember all the time I worked, I always discharged on house heating battery. But yesterday it was first time when I finished erecting work and loundged on armchair for coding. My fluffy cat jumped on my knees and I stroked her a long enough. Then I turned off my device and computer and went sleep. It was last time my cam worked... Now I'll use antistatic wrist strap...
Put your cat on a "mice and water" diet for a month. This might help to save money for a new cam :P

I never had ESD problems in my long long electronic career.
By Dmitri
#96028
KreAture wrote:This happens sometimes to one of my cams too. To get it working again I have to disconnect power to it for a bit, then restart my app and re-init the camera.
Sometimes, the cam stops accepting I2C commands. I had to disconnect it from the power as well.
By artem88
#96051
It's hard to hold cam powered during a whole disconnection and testing, and connecting back and so on... I think it was being disconnected at least 1000000 times. Isn't enough ? ;)
I very lucky, that microcontroller outputs are ok. They didn't expected that other-side inputs (reset and extclk) magically became outputs.
By Dmitri
#96067
I measured the power consumption of my design. It is about 100mA from a 3VDC source which is good indeed. Since the firmware is interrupt-driven, some more miliamps could be saved by going IDLE where CPU is stopped while DMA, SPI & Co are still running.

BTW, SPI clocks the SD card at incredible 40MHz (FCY of the chip). I don't know why but it works with many different SD cards of different flavors (noname included).

2.5MBytes/s are possible. Practically, not theoretically :)
By Dmitri
#96109
Another TCM8230MD example video showing the German city of Constance by night.
The weather was pretty ugly.

XviD, 43 Mbytes, 4:25

Image
The city of Constance by night captured with TCM8230MD @ rapidshare.com

I'm pretty sure that this cam has a built-in IR light blocker as many do. Just a piece of cyan colored glass. If removed, the low light performance will get better dramatically, although weird colors might occure.
By artem88
#96134
Thanks for video ! What framerate and extclk frequency was used during capture (not in resulted video) ?
By Dmitri
#96136
artem88 wrote:Thanks for video ! What framerate and extclk frequency was used during capture (not in resulted video) ?
Privet Artem!

The cam is configured to output 30 frames per second. Since EXTCLK frequency is 13.33MHz - around a half of what it should be, the framerate is down to 16 fps. EXTCLK is generated by the PIC24 itself, so it is 100% synchronous with the program execution flow.

13.33 MHz is one third of the PIC24's internal execution clock (40 megaops per second). In this QVGA mode (320x240), the resulting DCLK is a half of EXTCLK. Thus, I have 6 machine clocks to store an incoming byte in the DMA buffer array.

I noticed that the resulting DCLK and EXTCLK are equal in frequency in modes with higher resolutions. It is not a half of it any more.

/Dmitri
By artem88
#96137
Hmm... I suppose, you have duty cycle of extclk is not equal 50%. It is 1/3 or 2/3, isn't it ? I'll be happy, if so, because I can't produce 50% at desired frequency.
I noticed that the resulting DCLK and EXTCLK are equal in frequency in modes with higher resolutions. It is not a half of it any more.
Let's send these 23 pages of topic to toshiba for their datash*t best replacement :)
By Dmitri
#96139
artem88 wrote:Hmm... I suppose, you have duty cycle of extclk is not equal 50%. It is 1/3 or 2/3, isn't it ? I'll be happy, if so, because I can't produce 50% at desired frequency.
That's correct. The duty cycle is not 50%. It worked even with 10% as I increased the period w/o caring about DC, so it is not critical.
artem88 wrote:
I noticed that the resulting DCLK and EXTCLK are equal in frequency in modes with higher resolutions. It is not a half of it any more.
Let's send these 23 pages of topic to toshiba for their datash*t best replacement :)
This seems to be an everlasting problem with good and cheap things coming from Asia. They are offered undocumented.
User avatar
By rmann
#96878
[quote="Dmitri"]Hello everybody!
KreAture, I don't like YT fo this purpose because YT will re-compress the already compressed file.
[/quote]

Dimitri, I've uploaded H.264-encoded video to Vimeo, and then re-downloaded the file (you can allow users to do that) and compared them byte-for-byte. They were identical, despite Vimeo's post-processing of the video after upload.
User avatar
By rmann
#96879
Dmitri, have you had any luck using the camera module's JPEG compression? I'm considering building a board around an Atmel AT91SAM3U4C (ARM Cortex-M3), but I need to send slow video across a slow wireless link (sequential still video). I'd like to take advantage of the JPEG compression.

Also, can you talk more about how you interfaced to the PIC? I haven't found where you talk about that, but this is a rather long thread at this point. I'd like to know what approach to take when designing my board.

Thank you!
By Dmitri
#97248
rmann wrote:
Dmitri wrote:I don't like YT fo this purpose because YT will re-compress the already compressed file.
Dimitri, I've uploaded H.264-encoded video to Vimeo, and then re-downloaded the file (you can allow users to do that) and compared them byte-for-byte. They were identical, despite Vimeo's post-processing of the video after upload.
Hi Rick!

Thank you for your advice. I'll give it a try.
By Dmitri
#97250
rmann wrote:Dmitri, have you had any luck using the camera module's JPEG compression? I'm considering building a board around an Atmel AT91SAM3U4C (ARM Cortex-M3), but I need to send slow video across a slow wireless link (sequential still video). I'd like to take advantage of the JPEG compression.

Also, can you talk more about how you interfaced to the PIC? I haven't found where you talk about that, but this is a rather long thread at this point. I'd like to know what approach to take when designing my board.

Thank you!
Rick,

I did not try TCM8240MD yet. I wonder if I will after so many people had no luck with it.

I will update you all about my design very soon. I have managed to achieve 24 frames per second with audio (it was 18 fps w/o audio before). All streamed to a sd card as before.

As far as JPEG compession is concerned, you can make a DCT for 8x8 pixel area in 25 microseconds (0.024ms) with PIC32. 320x240 picture will fit into the RAM of the newest PIC32.

/Dmitri
  • 1
  • 21
  • 22
  • 23
  • 24
  • 25
  • 31