Tiens bah c’est justement les robots que je regarde actuellement pour automatiser des manipulations sur les bancs de test.
Je vois que ça a l’air de plutôt bien marcher !

A+ !

Est-ce que ça marche avec un GPS ou un PDA ?

Si oui, quelles différences ? (En clair que faut-il faire sur le dispositif mobile ?)

D’avance Merci pour la réponse !

Je faisais des recherches au sujet des pannes TV LCD, à défaut, cet article m’a beaucoup intéressé.

Je souhaite faire connaitre cette vidéo :
« Story of electronics ». Pour la sous-titrer en français cliquez la case CC puis french. http://www.storyofstuff.org/movies-all/story-of-electronics/

What could be easily noticed is – each 16×24 character row is represented by the 32 bytes. The first 16 bytes correspond to the first 8 pixels, and the second 16 bytes describe the later 8 pixels in row. Seems as each pixel is represented by the three channels where the first channel has 8 bits per pixel and the other two channels have only 4 bits per the pixel (or 8 bits of the 2nd&3rd channel are for describing two pixels at once – it would be very easy to test which one is the case).

Here is the picture of what I mean:

http://img5.imageshack.us/img5/859/pixeldata.png

I have isolated the ‘zero’ character (the 32×24 green rectangle) from the representation of the hex dump. The character is divided into the left and right half – the left 8 and the right 8 pixels of the character. Let’s see how each of the first 8 pixels in a row is represented in the hex file (raw data):

As I’ve said – each pixel is represented by the three channels. We still don’t know what they are – they could be RGB, RBG, shifted RGB/RBG, RBG+alpha, … Let us assume the three channels are R, B and G. I have marked the R, B and the G data of the very first pixel of the character with the corresponding red, green and blue colors.

As can be seen, the green and the blue chunks of data control the first TWO pixels (marked with red). As said before – green and blue channels might be 2 times 4 bits per corresponding pixel, or they might be 8 bits per TWO corresponding pixels, someone will have to do the simple test if one of these assumptions is correct (as there are more than just these two possibilities).

After these assumptions I was trying to figure out what the B&G data might be so I took the data for the very first visible pixel of the character ‘zero’. I took the hex editor and looked at the corresponding offsets and the data for the first (yellow) pixel is:

0xe1, 0×01, 0×94

If we assume the B&G data controls two pixels at the time, then the data for the second pixel in a row is the same as for the first one. Why would we assume the B&G data is for the two pixels? After examining the font, I noticed not even one SINGLE pixel in a row. That is – every horizontal pixel we can find comes in a pair so there is probability the B&G channels control ‘double’ pixels.

The next was to try to compare the RGB representation of the yellow (0xff, 0xff, 0×00) with the (0xe1, 0×01, 0×94). What color would the data represent if it is not RGB but is RBG data (I think there are some picture file formats with the reversed G&B channels)? The color would be (0xe1, 0×94, 0×01) and that *is* some kind of the yellow (however not the same as in the timestamp).

As we can see, the very same pattern can be applied with the next 8 pixels (the right half) of the character data and the next thing I assume is – one of the colors is reserved as the transparent (similar to storing the index of the transparent color in transparent .gif’s file format). Looking at the raw data (from the img_extract_03_0x138000-0x13d000.raw hex dump) the transparent color is:

0×00, 0×80, 0×80

Unfortunately I couldn’t make any further assumptions without flashing the EN25F16 with the altered data and seeing the results. In fact, I don’t even have the camera we are talking about – I have a MD80 clone that has arrived just yesterday. But if someone would do a few experiments flashing the 0×138000-0x13d000 area with some altered values, I think it wouldn’t be too difficult to decipher the exact color coding of the timestamp font pixels.

The first thing I would do would be to change all 0xe1 values of the ‘R’ channel of yellow pixels to see what would be the resulting color. Then, by changing the B and the G data, and observing the results – more could be found about how the color is stored in the corresponding 24 bits of each timestamp pixel.

What could be even more interesting would be to see the disassembly of the whole .hex dump, trying to isolate the code which reads the 0×138000-0x13d000 area. After locating that code, it might be not to difficult to ‘poke’ the .hex altering just a small number of the instructions, so every pixel from the font table would have been ‘read’ as transparent – regardless of the actual data.

I hope someone who already has set everything to be able to read/flash the device, would find this interesting and do some experimentations.

Arnaud

notre philips catholique a bien fonctionné, hier soir nous l’avons éteinte normalement, et tout à l’heure j’ai voulu regarder une émission, j’appuye donc sur le bouton d’allumage, celui-ci s’allume rouge (normal) mais l’écran reste noir et aucun son… cette télé doit avoir 11 ou 12 ans.. quelle nature de panne ?? alimentation ?? fusible ? aucune idée..

je vois que beaucoup de gens ont des soucis, et que certains parmi vous sont des bricoleurs hors pairs.. bravo à vous..

j’ai une petite question pour vous: ma télé quand je l’allume fait un gros bruit (quand le décodeur est allumé) et n’affiche rien. Avant je la laissais constamment en veille et hier j’ai décidé de l’éteindre et à mon grand étonnement je n’arrive plus à la rallumer. Pouvez-vous m’aider svp? Croyez vous qu’elle soit morte?

merci à vous de partager avec nous vos connaissances et surtout merci pour votre aide.

J’ai un soucis sur ma TV, je n’ai que le son mais plus d’image. il s’agit bien du tube qui est mort n’est-ce pas?

Puis je faire le remplacement par moi même?

Merci