Messages posted by: jorlando

Jerry,

yes, I think that there is something related to the amount of lines. In portrait the height is 640 lines, in landscape is 480 lines. If you have some routine depending on the line count to calculate the frame rate and that routine was made for portrair mode we would have a lower frame rate in portrait.

This is plausible, since the "true" orientation of the screen is landscape (480 lines) and it is rotated to portrait (640 lines)

Napkin math for landscape mode:

480 lines x 60 frames/second = 28800 lines/second

If this value is fixed in portrait we have

28800 lines/second / 640 lines = 45 frames/second

From my late JBL I could perceive the flicker more on the left side, but I think that impression is caused due the left-justified text. We have mor blanks on the right side, so we tend to notice the artifact first on the left side.

In landscape mode I could not perceive the flickering, using the same text that flickered in portrait

Also I believe that the flicker is not due "frequency beating" from flourescent lighting, since I could have flicker under sunlight or incandescent lighting

Jerry,

talk to your tech people and ask what is the frame rate for the display when in portrait and landscape modes.

If they are using the same rate (I think they are), to check if it really is being upheld.

I am suspicious that the frame rate may be related to the quantity of lines. So when in landscape you have fewer lines, the intended frame rate is fullfiled.

When in portrait you have more line and gets a lower framerate.

Also, in my case, the flickering used to start a few seconds after the page turn. Maybe a lower clock rate is selected to save the batteries when not in use (in use: responding to user commands, turning, pages, etc)

I could see from configuration files that the JBL is never really turned off, only put on suspended state with blanked screen and very low clock rate.

I also found also settings for contrast and frame rate (refresh) that are not used. Maybe the engineers have selected some fixed values that should work for 100% of the devices, but this clearly does not happen.

Maybe a configuration entry, where the user could select contrast and frame rate to a flicker free visualization at the cost of a lower battery life.

If I remember correctly the upgrade file at Ectaco's website is a 7zip executable file. You will need a Windows computer to open it and copy the files to a SD card.

Jerry,

I already left a suggestion to leave the update files in zip format. zip is almost a de facto standard.

Executable files are OS dependant or rely on some fancy interaction from the user to openit on another OS.

By any chance, do you have parentheses "(" or ")" in the filename?

Jetbook have problems opening files that have parenthesis in the filename. If that is the problem, the solution is easy: rename the filename, removing parenthesis.

HTH

Thanks for the offer, jerry!

But I live in brazil and the cost of an international parcel from here would turn to nothing any financial advantage from the offer, it would just consume time and paperwork in the end.

I think that the battery compartment does the damage, with the batteries weight pressing the LCD glass against the plastic frame. Anyway, I also suggest to change the way the batterie cover closes. Even if the device does not break with a fall the batterie cover tends to open and there goes the cover and batteries around the floor.

It is not nice inside our house, imagine that happening inside a bus or train full of people...

Maybe some latch in the battery cover like the portable nindendos have.

Better construction:

- the case does not offer shock dampening at all. My jetbook lite fell face down today, the screen cracked leaving large black blotches. The height is wasn't too much, around 1 meter.

maybe some rubber around the frame where the glass screen is mounted.

Anyway, time to look for another reader.

There are lots of free games for linux. At jcnips (manufacturer of Ectaco's Jetbook hardware) there are some screenshots of readers with a sudoku game.

Sudoku, checkers, chess, solitaire and other puzzles could be implemented.

An extra line in the selection screen wouldn't hurt.

One image worths a thousand words...

Almost there...

There is really extra 128 bytes (1024 bits) at the end of each line in the image dump.

I wrote a small bash script to strip the extra bits.

To the resulting file I added the 118 bytes header of a 4 color 640x480 bmp image

I could open the resulting file without adding the header with irfanview as a raw image file, but since it can only open raw files with a minimum of 256 color the resulting image has the lower half empty and the upper half with two duplicate images of 320x240.

I will try to find a way to add extra bits to the raw image and to compare the stripped bytes to see if it is a constant value or something else.

====================================

#!/bin/bash

VALIDO=320

# extract image from jetbook`s internal image.bin files

for i in {0..214592..448}

do
dd bs=1 skip=$i count=$VALIDO if=4.bin.raw of=saida > /dev/null 2>&1
cat saida >> dump4.raw
done

exit 0

I don't think so. I think that the extra bytes are due to some quirk of the LCD controller.

I found that 448 value looking some pattern repetition in the dump file.

The best that I could manage was to copy the first 256 bytes from a 4 bit grayscale bitmap and overwrite the dump. The result umas a rough quality image, with some artifacts that seems to indicate that some parts of the image are offset from the actual position.

The dump is 480x640, the problem is to figure the meaning of the extra bytes.

If the screen has 16 gray tones, it needs 4 bits.

640x480x4 = 1228800 bits

215040x8 = 1720320 bits

1720320-1228800 = 491520

491520 / 1024 = 480

So each line needs 1024 extra bits. Why? Addressing? Mode setting?

Let's hope that someone from support can give us the answer.

Thanks, I'll ask. The format is confuse...

640 x 4 (16 gray tones, 4 bits) = 2560
448 x 8 = 3584

3584 - 2560 = 1024 bits.

I can't figure how these extra bits are used...

I was looking the file structure of Jetbook Lite and found some files with .bin extension with a size of 215040 bytes

They are the fullscreen images of option menus, the bookpile picture, etc. They are dumped directly to the screen like this:

cat filename.bin > /etc/fbdev0

I am trying to do some translations but I can't figure how to transform to that screendump format.

215040 bytes don't translate directly to a 640x480, 8 bits per pixel image. In fact, it doesn't translate to a integer depth color

Due some observations I think that they are 448x480, 8 bits per pixel stretched to 640x480.

Anyway, someone from Ectaco can point me to what tool was used to convert images to that file dump format and/or give more details about that raw image type that is being used?

A converter plug works. Just check if the power adapter is 110V, 220V or auto. I think that you can use the USB cable to charge it through your computer.

It is a solid bar o a flickering one? This flicker is a knowm problem. It becomes visible in some (all?) units under strong lighting.

Some people sent their units for replacement in warranty but I don't know if the received units doesn't have this problem too.

I think the flickering is a software problem. In my unit if I rotate the screen to landscape viewing the flicker disappears.

Try viewing some pictures, rotate the text. Do some tests to identify if you have a defective screen. But if the problem really bothers you, use the warranty to ask for a new unity.

How many reader apps are used in jetbook and jetbook lite?

It seems that pdf and epub files are managed by fbreader.

And what abou txt and rtf? It seems that different applications are being used.

If you reset JBL and the first book that you try to read have parenthesis in the name (eg. test(file).txt), JBL freezes and you need to reset the device again. This bug does not happen if the first file read is a .pdf (eg. test(file).pdf)

It seems that two different reader apps are being used.