So I decided I should mess with those darned tamagotchis again after discovering my local walmart had v4.5 tamas on "sale" for $15. I bought one, brought it home, and got busy. First, I set up my ir reciever on my breadboard as usual. I then plugged it in and fired up xoscope. It lets me use my soundcard as an oscilloscope. Luckily it has a rather nifty feature; It can detect a change in the signal (like the start of some interesting data for example) and freeze the display. Apparently, back when I was messing with this last december, I had my LED in backwards so I couldnt pick up anything.
So, now that I had some captured tama data, I saved it off into a file and started writing some code to parse it. I started off blundering around trying to figure out how to turn that data into 1s and 0s. At first, I thought that the "on" pulses were 1s, and that the "off" pulses were 0s, and that the differing lengths of 1s simply meant that there were two 1s next to each other. So I wrote some code to read that sample data and produce some binary, find "magic patterns" that might mean something (repeated patterns), as well as producing a mnemonic form by representing common patterns with letters.
That led me to realize that I had a sequence that was like so: 0101...1010
That obviously means nothing, but I soldiered on. I noticed that there were some areas of doubled 1s that didnt fit the pattern. I attributed this to static/corruption in the samples.
Then I did some reading. Turns out IR transmits:
a start bit, which I had observed as a really long 1, and just had my script note it as "1111"
zeroes, which I had thought were the "off" areas, but really were the shorter of the two types of "on" pulses.
ones, which I had thought were the "on" areas, but really were the longer of the two types of "on" pulses.
and "off", which I hadnt even thought of. Turns out "off" is the "off" areas. It occurs between all digits in the stream. so instead of 010101101, I really had: _0_0_1_0, or 0010.
After re-writing my software to recognize this (and cut out that magic code finding bit) I was suddenly faced with a binary representation of the binary data my v4 tama spit out while in "Other" mode.
I have yet to make sense of it.
Now I can read tama data. Yay.
Now how do I write it back to the tama?
Well, turns out you have to send a 38-40khz signal, silenced between bits, and the ir detector on the device should pick it up. Should.
I wrote another little python module to generate sine waves for me, and through some rather simple math, I'm able to generate what should be the correct signal. The thing is, that sound cards can only produce about 20khz. Luckily there is a technique that allows one to transmit summed signals so that their combined signal adds up to their collective hz. My code provides for that, but for some reason, the tama wont respond. Perhaps its because I dont have data to send back from a genuine <v4 tamagotchi, and only the "compatibility mode" data from a v4. I'll have to try with the v4 data.
You can find the latest code here: https://launchpad.net/irbinarisizer
I've still got a bit to go with it yet, but it should shape up nicely.
At the very least, I might duplicate the efforts of the LIRC project and make my computer into an expensive remote control.
So, now that I had some captured tama data, I saved it off into a file and started writing some code to parse it. I started off blundering around trying to figure out how to turn that data into 1s and 0s. At first, I thought that the "on" pulses were 1s, and that the "off" pulses were 0s, and that the differing lengths of 1s simply meant that there were two 1s next to each other. So I wrote some code to read that sample data and produce some binary, find "magic patterns" that might mean something (repeated patterns), as well as producing a mnemonic form by representing common patterns with letters.
That led me to realize that I had a sequence that was like so: 0101...1010
That obviously means nothing, but I soldiered on. I noticed that there were some areas of doubled 1s that didnt fit the pattern. I attributed this to static/corruption in the samples.
Then I did some reading. Turns out IR transmits:
a start bit, which I had observed as a really long 1, and just had my script note it as "1111"
zeroes, which I had thought were the "off" areas, but really were the shorter of the two types of "on" pulses.
ones, which I had thought were the "on" areas, but really were the longer of the two types of "on" pulses.
and "off", which I hadnt even thought of. Turns out "off" is the "off" areas. It occurs between all digits in the stream. so instead of 010101101, I really had: _0_0_1_0, or 0010.
After re-writing my software to recognize this (and cut out that magic code finding bit) I was suddenly faced with a binary representation of the binary data my v4 tama spit out while in "Other" mode.
I have yet to make sense of it.
Now I can read tama data. Yay.
Now how do I write it back to the tama?
Well, turns out you have to send a 38-40khz signal, silenced between bits, and the ir detector on the device should pick it up. Should.
I wrote another little python module to generate sine waves for me, and through some rather simple math, I'm able to generate what should be the correct signal. The thing is, that sound cards can only produce about 20khz. Luckily there is a technique that allows one to transmit summed signals so that their combined signal adds up to their collective hz. My code provides for that, but for some reason, the tama wont respond. Perhaps its because I dont have data to send back from a genuine <v4 tamagotchi, and only the "compatibility mode" data from a v4. I'll have to try with the v4 data.
You can find the latest code here: https://launchpad.net/irbinarisizer
I've still got a bit to go with it yet, but it should shape up nicely.
At the very least, I might duplicate the efforts of the LIRC project and make my computer into an expensive remote control.
