Navigation
User login
Upcoming events
Recent Events
- 48 weeks 1 day ago
- 50 weeks 6 days ago
- 1 year 8 weeks ago
- 1 year 10 weeks ago
- 1 year 10 weeks ago
Newest Games
Search
Decoding progress
It's going pretty smoothly, actually!
I wrote a little oscilloscope program in Python that interprets the raw pulse/space data from WinLirc (pasted into text files), then gathered the data for each of the buttons. Thankfully the encoding was easy to decipher (each bit has a short pulse to start, and then a short or long space indicating one or zero; a long pulse ends each batch of sixteen bits), so it's just a matter of looking at the picture and turning it into a code. I haven't really looked at how to write the configuration file properly quite yet, but I'm sure it won't be too hard after all.
Important findings for game designers:
- The codes are the same whether you roll the trackball up or down. :(
- The "release" code appears to be the same for all buttons, so there's no possibility of holding down multiple buttons simultaneously.
EDIT! For all the V.Smile Baby hackers out there, I've attached a text file detailing the codes associated with every button. If someone is ever crazy enough to try hacking the V.Smile console itself, knowing these codes could help you out.
| Attachment | Size |
|---|---|
| vsmile decode.txt | 796 bytes |
Comments
I'm attaching a
I'm attaching a configuration file for WinLirc (should also work with Lirc) that will work so long as the V.Smile is set to "PlayTime" mode. Unfortunately while I was testing it out, I hit a bit of a snag -- it looks like the first three bits of the code for every button are used to describe what mode you're in. I believe the reason for this is so that the system knows, when you press a button to advance past the title screen of each game, which mode you want to start from. This sucks pretty hard for Lirc, which really doesn't expect to do much interpretation beyond turning the pulses into bitstring and then matching them.
What's worse is that the last three bits of each code also vary based on the mode, but it'll take a lot more dumping and analysis of raw IR data to determine if there's a pattern to that. The last three bits are also used to determine repeat codes (they're XORed by 101 when repeating), and they differ depending on what button you're pressing, and I haven't been able to find any sense in them yet.
After a bit of testing, though, it looks like I can assign multiple bitstrings to the same name in WinLirc. So at least once I have the data, I'll have a brute-force solution that doesn't completely suck.