Digital Photo Frame type DPF018 / Sitronix Digital USB keychain

Digital Photo Frame type DPF018 / Sitronix Digital USB keychain

Main Index

Goal for this page is to collect data about this device and use it with linux.

Info, links, documents

1. DPF018
2. Sitronix, usb bridge
3. Display aansturing, Sitronix???
4. mscustomercare, Photo Viewer package version 2.3
5. wififinder Sitronix debug
6. Gentoo forum: sitronix usb keychain
7. Spritesmode Forum
8. Home page Spritesserver TomTec/ Coby DP-151
9. lcd4linux
10. example Ultrachip CSTN-LCD UC1681U
11. sitronix-dpf sourceforge

digital photo album (flasdisk) with clock, usb vendor id 1403 and product id 0001.

globale specs:
    * DPF018 Portable Digital Photo Album
      (SITRONIX MULTIMEDIA USB Device)
    * General Features:
    * Stylish blue design
    * Keychain
    * 3.7V lithium battery or USB 5V power supply
    * USB 1.1 interface
    * BMP, JPG, PHG, GIF file formats
    * Manual and automatic play back modes
    * Auto power shut off
    * 1.1-inch color CSTN-LCD display 94 x64 pixels 
      (CSTN- "Color super-twist nematic"),xxxx colors?, 4096 colors equals 12 bit data.
    * 2 MB built-in flash memory	(device which i have)
    * Holds up to 186 pictures 
      (.bmp file 24.6kbyte then about 80, hardware limit??, software limit??)
    * Unit Dimensions:
    * 2.25 x 2 x .75-inches (H x W x D approxmate)
    * Unit Weight:
    * 23.3 grams
    * Regulatory Approvals:
    * FCC
    * CE

Other device with 1.5-inch display (128x128)
digikey fr manual
digikey nl manual
Different names: Coby DP-151

For my dpf018 and other digital photo frame some checks are done, The device that show up as
a mass storage device doesn't even have a file system. It is just an interface for the device

16-10-2007 .. 16-10-2007 .. Added dpf018 back
                                  dpf018 front 
                                  dpf018 memory 
                                  dpf018 battery

16-10-2007 .. 16-10-2007 .. dpf018.txt

Progress


27-11-2008 udev rule sitronix for coby.tar.gz, (specific for sweex keychain photoframe) from Johnny OngStreum:
           KERNEL=="sd*[!0-9]", SYSFS{idVendor}=="1403", SYSFS{idProduct}=="0001", SYMLINK+="sitronix", SUBSYSTEMS=="usb", NAME="sit_%k", MODE:="0660", GROUP:="sitronix"

           The rule also renames sd device to sit_sd because there is no valid filesystem.
           However block device characteristics are preserved.
           Place for example rule in file: /etc/udev/rules.d/10-personal-rules
           Add user to group sitronix, so user can use the device.

11-01-2008 Program coby.tar.gz from Miguel Marte.
           With program you can dump the images using the get_image function. 
	   It takes in the file descriptor, an buffer to write the image to, and which image block
	   you want to retrieve. Code is just for test, use at your own risk.
	   Open point is image format!
	   
05-01-2008 Size of the stored pictures on the device can depends on image size, supported colors
           4096 supported colors equeals 12 bit data for each pixel.

04-01-2008 Text from amazon review by Paul Wehr
	TAO device:
	- Display is 128x128 pixels in 24 bit color
	- USB interface is NOT a standard block file device (e.g. does not show up as a disk drive), but uses
  	a proprietary interface, so you MUST use the included software, which is not available for Linux.

	Also, if you think you should be able to fit a lot more than 30 128x128 pixel JPG images into 8MB,
	you would be right, but the software limits you to a fixed 30 pictures, which you can (re-)extract 
	from the device as a entire batch (for re-use later) into a (seemingly proprietary) ".itc" file 
	(which is actually 66 bytes of header followed by the images in 49,152-byte blocks (128 x 128 x 3byte color) 
	in simple RGB bitmap format. Even if the device stores the images in the uncompressed bitmap format (which it
	probably does), it is using no more than 1.5MB of the "8MB internal memory" to store your pictures.

03-01-2008 Some information from Gentoo forum added below (from GroovBird (Dave))

	Then I used Hexviewer to take a look at all the blocks on the drive, because my second 
	guess was that it would just expose the whole Flash memory as a single big block with 
	a propietary format easier to read from the cheap-o flip-chip microcontroller on the board.
	But every sector read exactly the same.

	So then I used Sysinternals' Process Monitor to see what kind of interaction takes place
	between the Photoviewer.exe app and the drive, and it seems that it uses the block device
	as a two-way communication with the microcontroller.

	The application writes 512 bytes to offset 25088 on the device, and it then reads 64KB from
	45056. It does this several times on startup. I don't have a tool handy to find out the bytes
	that are sent and those that are read, so I'm not going further into that right now. 
	When synchronizing, it writes as follows:

	* 512 bytes to offset 25088
	* 32758 bytes to offset 26112
	* 512 bytes to 25088
	* reads 512 bytes from 45056

	and does so for every picture added.

	From the screen it looks like a 32x32 graphical screen, and while it's possible there's a 
	32-bit image in each block of 32KB, I think 32KB (32x32x32) seems a bit much for one image.
	Maybe not all of that space is used to write the picture.
           
30-12-2007 copy device image to test image
	   dd if=/dev/sda of=./copie-pv.img
	   and tested with fdisk:
	   fdisk ./copie-pv.img
28-12-2007 11-01-2008 .. cat /dev/sda >dpf018-cat.txt will give dump of data (2Mbyte) 
                          dpf018-cat.zip
	   using gvim dpf018-cat.txt with menu option hex mode, data can be checked.
27-12-2007 Test with dosfsck (Remi Suinot)
	   dosfsck /dev/sda
	   dosfsck 2.11, 12 Mar 2005, FAT32, LFN
	   Currently, only 1 or 2 FATs are supported, not 0.
           
	   So, the usb-storage module can't read the fat:
	   Information from /var/log/dmesg file at startup:
 	   usb-storage: device found at 8
   	   usb-storage: waiting for device to settle before scanning
	   scsi 2:0:0:0: Direct-Access     SITRONIX MULTIMEDIA       0.09 PQ: 0 ANSI: 0 CCS
	   sd 2:0:0:0: [sda] 4096 512-byte hardware sectors (2 MB)
	   sd 2:0:0:0: [sda] Write Protect is off
	   sd 2:0:0:0: [sda] Mode Sense: 0b 00 00 08
	   sd 2:0:0:0: [sda] Assuming drive cache: write through
	   sd 2:0:0:0: [sda] 4096 512-byte hardware sectors (2 MB)
	   sd 2:0:0:0: [sda] Write Protect is off
	   sd 2:0:0:0: [sda] Mode Sense: 0b 00 00 08
	   sd 2:0:0:0: [sda] Assuming drive cache: write through
 	   sda: unknown partition table
	   sd 2:0:0:0: [sda] Attached SCSI removable disk
	   usb-storage: device scan complete

	   It is maybe possible to repair with dosfsck -a, but output is not know yet. 

08-12-2007 dpf018-2.bgl logfile
           use Beage usb analyser gui for reading
05-12-2007 Test with: 
	   lsscsi 
	   [5:0:0:0]    disk    SITRONIX MULTIMEDIA       0.09  /dev/sdg
	   Fileformat??,
	   fdisk /dev/sdg
	   Device contains neither a valid DOS partition table, 
	   nor Sun, SGI or OSF disklabel
	   fdisk command: 
	   p
	   Disk /dev/sdg: 2 MB, 2097152 bytes
           1 heads, 4 sectors/track, 1024 cylinders
           Units = cylinders of 4 * 512 = 2048 bytes
           Device Boot      Start         End      Blocks   Id  System
	   disktype /dev/sdg

	   --- /dev/sdg
	   Block device, size 2 MiB (2097152 bytes)

16-10-2007 Start of webpage, some test done (lsusb -v,).
	   Status: Not mounted on system yet.

TO DO list
1. Check dpf018-2.bgl file for comparision with analysis information from 03-01-2008.
2. User program using libusb to read/write to device, maybe writing a camlib for 
   libgphoto is or a standalone program.