Lately, I’ve been trying to figure out how a Tamagotchi’s gender is determined. There appear to be two indicators.

The first is byte 10, which appears to be set to 4 for female gotchis and 3 for male gotchis, but this doesn’t appear to influence the gender that the gotchi is recorded as under the friends menu.

After much fiddling, it turns out recorded gender is determined by bit 5 of the second byte of the UID (yes, really). If it is not set, the gotchi is male. If it is set, the gotchi is female. Note that appearance is not related to gender (there are ‘girl’ and ‘guy’ appearances, but they each have their own identifier in the appearance section of the request, and the gender bit does not affect how they are displayed.)

An update protocol diagram is as follows:

The UID seems like a rather strange place to indicate the gotchi’s gender. There are a couple of possible explanations. Perhaps it is more efficient (a device does not have to store an extra gender marker alongside each friend’s UID). Or perhaps gender is so deeply linked to a Tamagotchi’s identity that it is inextricable from it’s UID. Or perhaps a Tamagotchi’s UID is more than just a random identifier, maybe it has a role in detemining its future growth (this is consistent with observations on other communities that Tamagotchi’s tend to follow a number of set growth patterns). Maybe there is predetermination among Tamagotchis.

Deep and complicated are the questions of Tamagotchi life…

Tags: ir
Posted in Member Blogs | 3 Comments »

I took a closer look at the Tamagotchi protocol to try to figure out the block that controls the Tamagotchi’s appearance. I started by looking at this block for different ‘species’ of Tamagotchi, and then altering it and seeing what happened.

I noticed that byte 14 in the request/response tended to be larger for older Tomagatchis. Altering it and replaying the transaction made the position of the character on the screen change: starting low on the right of the screen at 0×10, moving higher on the screen as it reached 0×50, and then moving to the high left of the screen at 0×60, and then moving progressivly lower as the value gets higher. Older Tamagatchis are usually taller and larger, so they need a higher position value to be drawn properly on the screen.

Observing byte 15 and 16, these appear to change with the species of Tamagatchi. Looking at a few different transactions, only the top two bits of byte 15 and the bottom four bits of byte 16 appear to be used (I confirmed this by replaying transactions with the middle bits altered, and they didn’t seem to have an effect).

Going through all the possibilities, I got the following chart:

These are all of the Tomagatchi v4 characters.

Out of curiosity, I tried with a v4.5. I thought that it might make use of the middle bits, but instead it used bytes 20 and 21 for the character, setting bytes 15 and 16 to 40 0e. If bytes 20 and 21 were set to 1 ff, it would go into v4 mode, and use the character codes above.

Below are the v4.5 codes. A few are missing because they didn’t follow the logical pattern and I didn’t want to go through all ff ff possibilities.

What’s cool about this, is that with v4 I could speculate that some of the extra bytes were ‘room for expansion’, but with v4.5, you can see that they were actually used.

The revised request protocol is as follows:

Tags: ir
Posted in Member Blogs | No Comments »

I’ve managed to get a reliable circuit going for sending and receiving data from the Tamagotchi. I used an Arduino program written for interacting with the Lutron Maestro light dimmer and modified it to work with the Tamagotchi, plus an infrared LED connected to an output pin.

This program takes care of modulation, although I had to fiddle with the frequency a bit until it worked. I debugged it using a second Arduino running the decoding program I wrote in the last section, which turned out to be problematic, as the actual Tomagatchi is more sensitive than my receving program. I ended up tweaking timing variables blind until it worked with a Tamagotchi (this took maybe 25 attempts).

Circuit noise also became a problem once the IR LED was attached, so I soldered the components into a perfboard with short(ish) wires, which seemed to clean it up.

My set-up can now simulate a Tomagotchi interacting with a real Tamagotchi. The next few entries will explain what I’ve learned about the protocol from this.

Tags: ir
Posted in Member Blogs | No Comments »

Looking at the decoded IR signals, we can start to understand the protocol.

Tamagotchis can have three possibile interactions: visits, presents and games. Starting with the simplest, visits, I recorded a number of interactions. I noted that each visit involved either singing, playing ball or chatting. Below is a sample visit.

Singing visit between JANIE and HELEN

JANIE: ac 0 24 d6 a 1 e 9 5 0 4 88 0 0 20 80 9 0 0 ff 1 ff ff 0 (request)

HELEN: ac 1 1f 96 8 5 c 5 e 0 4 88 20 5 10 0 1 0 0 ff 1 ff ff 4e (response)

JANIE: ac 1c 24 d6 a 1 20 1f c (request confirmation)

HELEN: ac 1d 1f 96 8 5 20 24 cf (response confirmation)

Based on this (and several other samples)I theorize the following protocol:

Request and response:

Confirmations

When the Tamagotchis play a game instead of just visit, the request and response are the same, but the confirmations are different:

Likewise, when they give a present, only the confirmation is different.

So that’s a ten second guide to the protocol!

Up next:

• Set up IR to send stuff to Tamagotchi
• Put a Tamagatchi into debug mode to better understand the physical attributes portion of the protocol
• Play with the protocol

Tags: ir, personal projects, wireless
Posted in Member Blogs | No Comments »

Some success with decoding the IR signals in real time!

Read the rest of this entry »

Tags: ir, personal project, wireless
Posted in Member Blogs | 1 Comment »

Tamagotchis are keychain virtual pets. They communicate (“visit each other”) over IR. For the past few weeks, I’ve been trying to listen in on and understand this communication.

To start, I set up a liteon IR module to listen in on the transmission, and recorded the ouput with some help from DW and his digital signal analyser.

Plotting the signal, you can see a request and a response:

Looking more closely at the request:

Googling a bit, this appears to be similar to NEC encoding, athough the periods of the bits are stretched out (in normal NEC encoding, 0 is a cycle of equal size, 1 is a cycle that is low twice as long as it is high. In this case, 0 is marked by a cycle that is low twice as much as it is high and 1 is marked by a cycle that is low four times as much as it is high. Note that the graph above has 1 and 0 inverted, a feature of the IR receiver.) The main point is that if you look at the graph, there are some waveforms that are squished together, and those are zeros. The ones that are spaced out at ones.

Assuming this, it is easy enough to write a Python script that extracts the bytes of the request, which are:

ac 00 26 d6 0e 01 0e 01 00 01 33 87 00 00 33 c0 0b 00 00 ff 01 ff ff 7d

Looking at this, there are bytes in the same pattern as my Tamagotchi’s name (Nana):

ac 00 26 d6 0e 01 0e 01 00 01 33 87 00 00 33 c0 0b 00 00 ff 01 ff ff 7d`

Note that 0x0e = 14 and ‘N’ is the fourteenth letter of the alphabet. So 1, 14, 1, 14 could represent the name Nana.

Update

Trying this with a Tamagotchi named Anna gives the following output:

ac 00 39 d6 01 0e 0e 01 00 00 34 87 00 00 20 80 8 00

so this is almost certainly the case.

Tags: ir, personal project, wireless
Posted in Member Blogs | 1 Comment »