I also recently bought a micro camera (30fps and 720×480. Sunplus)
and I got the wrong timestamp of 2008 too.
After reading the the whole stack of information of all the gumpack-explorers
I found the hints of « where to save the « DATE.TXT » where solving
the timestamp-problem.
After the timestamp was saved in the right way and place, the testvideos
showed the correct date and time each day.
Here is my Howto :

Via USB you should see the memorycard
with its folder DCIM on your PC screen.
Opening this folder shows the next folder
(in my card 100MEDIA) In this folder
I have the testvideo-files and
a saved example of the timestamp-file « prototype ».
It should look as the manual wants

TAG.TXT
(in this textfile I wrote in) :

[date]

2011/10/26

17:15:00

Of course you write your
actual date and time
and you made the blank lines
after each written line.
Now you save this « prototype »
in this last folder.

Now you copy the new created file « TAG.TXT »
and you save/paste it parallel
to the folder DCIM.

Insert the memorycard back to the camera.
If you take a video with the camera,
it grabs the actual date+time and delete the the file after,
because the camera keeps the new date and time
as a computer and from now it writes the daily correct timestamp
on each new video that is taken.
If you check the camera-memorycard with your computer,
you see no TAG.TXT file together with DCIM-folder. The camera
did the job.
If you ever need the TAG.TXT again (Battery down,or you reset the camera) find the first saved file, change the actual date+time or write completely new and copy as mentioned.

Happy gumpacking !

Connect the camera to your PC, then create a file « time.txt » in the root directory of the camera, with contents e.g. « 2011.01.01 00.00.00 N ». No quotes and no line breaks; file size must be exactly 21 bytes. This has already been documented in various places; the only remaining problem is that the firmware deletes the file upon booting.

But there is a trick to prevent that pesky delete from happening: just make the file read-only! It’s really that simple…

Dan

I’ve read through the datasheet on the SPCA533A camera controller and there doesn’t appear to be a way to control the frame rate there. It’s streamed through an almost completely hardware path from sensor to SD card. The CPU on there is just looking after the UI (on cameras that have one) and a few minor housekeeping tasks. Initialization is handled by this CPU, which I guess is why I managed to alter the sensor configuration.

In hacking rather than reading, I’ve experimented with the close_frame setting on the module again, but I can’t get that to do anything. I can get a video of the sensor test signal, which looks like a TV test card, by setting a bit in a debug register.

The really bad news is that I’ve now bricked my camera in a permanent looking way. It seems like the unbricking pads are permanently shorted, so I think I’ve zapped it with static. I wasn’t taking any precautions so I wouldn’t be surprised by that.

If I can get the datasheet for the Sunplus SPCA1528 or SPCA1527a then I’d love to read it and see what more can be done. Failing that, I think I’m going to go for the hardware (555 timer or PIC) option to take one still image every 4 seconds.

Cheers,
Geoff.

Now it’s daylight an issue with the low frame rate hack has come to light. The camera seems to be too sensitive, pretty much anything filmed in daylight gives a complete whiteout.

I guess it’s back to the drawing board to see if I can figure out some other frame rate control system.

Meanwhile, the 6 FPS hack seems fin indoors.

Geoff.

The programming tool works MUCH better on my old XP laptop than it does on my nice shiny Windows 7 one. Even though it is 32 bit Windows 7. Only killed the camera once all night, and revived it with the short the two pads technique anyway.

Now down to details…

The sensor configuration is about 256 byes along from the word SENSOR. It’s laid out as two byte pairs. The first byte is the address in the GC0308, the second is the value they put there. The address byte generally increment while the data bytes can be anything. Anyway there’s a sequence like this…
0×26 0×02
0×28 0×00
0x2F 0×01

The interesting part (to me) there is the middle row. Address 0×28 holds the clock divider, and duty cycle parameter. I think setting the second nibble to about half of the first is a good plan, but am ready to be corrected if anyone knows better. The first nibble will divide the clock by 1 plus the vlue set in here. If you push this too high, and therefore the clockrate too low, the camera won’t boot. I’ve found that I can set it to 0×42 and the camera will film at 6 FPS with the remaining frames filled in as dropped frames. Not completely sure, but I guess a 2Gb card will outlast the battery at that. There is a way to run the camera from the USB though. Just hold the record button down as you plug it in to do this.

Another experiment tonight was to try the frame rate setting parameters in the output section of the datasheet. I couldn’t make anything work with this though.

Finally, I played around with the « special » effects. I hijacked the bit in the configuration data that sets byte 0×18 labelled as unused in the document to be able to set values in the special effect control byte. This byte is at 0×23 and is a bit field, the bits enable the 3 effects independently. Presumably you can use multiple effects at the same time. anyway here’s my results.

0×01 – should be Invert colors – The image was in negative.
0×02 – should be CbCr fixed – The image was in black & while.
0×04 – should be edge map – The image was all white.

Anyway, that’s my research so far. I’m sure I can make it do more if I try, it’s just a matter of finding the time.

Feel free to post any questions and I’ll try to answer them.

Happy Hacking.
Geoff.

That’s great achievement ! You are not alone here, I am really following your work. Please keep us informed of your progress
Cheers,