I've taked a few times about 'decoding the bits' so I thought I would finally get around to putting up a spreadsheet for anyone to see. A quick refresher of how I'm counting/tracking the output from the light strike devices: 65 'signals' come from the device. They come in two types: Pulses or Spaces. This is what the LIRC software refers to them as, so I just continue that. If it's wrong, it's GIGO from LIRC to me to you. The first signal is a large pulse, typically double the value of all other pulses you will get. This is the 'frame start' if you want to think of it in terms of a networking packet. The next 64 'bits' of information are alternating pulses and spaces. The pulses are constant. They're the markers between spaces to let you know when a space starts and ends. Since the pulses are simply borders for your spaces, you are left with 32 bits of data in your frame. Because I cheat and take the output from one of the LIRC utilities rather than reading the pulses directly, I count the pulses and spaces together for 64 'bits' in my coding (mostly because when I started I wasn't 100% sure if the pulses might have a hidden significance). So when you view the spreadsheet, even numbers are the spaces, odds are the pulses.
Here is the google docs spreadsheet of my light strike bit decodes. There are four tabs, one for the rifles, one for the pistols, one for the ITS and bit math where convert the bits from binary to base10 numbers to see the relative values. The pistols sheet is a work in progress, I only took one stab at decoding the only pistol anyone in my group has. It had surprising results. A laser strike from a pistol is different than the laser strike from the rifle. It makes sense in a way. The rifle bits add up to the number 1344, but the laser strike on the pistol is only 258 it seems. They seem drastically different which means I should probably revalidate the values coming out of the pistol.
I'll probably create a code.google.com project to dump my simple perl code into at some point too, with the hopes that someone who is an actual developer can take it further.
Ok I just thought of something that can add to the gameplay. Who has an Iphone/andriod phone? How about hooking the sound output to the phone creating a app that uses the sound to track deaths setting it up to network through wifi and display game data for review/bragging rights later. Anyway Just found your blog and posted on a older post. Anyway hope the ideas help.
ReplyDelete@ Sirodesto: That sounds like a lot of work for score keeping. I'd like to look into hacking the vests (which give you 24 points of health, I have heard) to either keep track or require you to go back to a respawn point to reactivate. As I haven't received any of my hardware yet, I'm only speculating, but I believe you just have to press the shield button the vest to reactivate. So if you could introduce something in between that could regulate if you could hit the shield button or not, might work.
ReplyDeleteHopefully I can join Rich in hacking on these toys.
'lo. I picked up a pair of LightStrike rifles on clearance today, just to see what the "competition" can do. Having used the LTTO line by Hasbro/STM, this doesn't quite meet my needs/expectations, but I did do some poking around with the shot signals. Don't know if you'll find it very useful, but my findings are at http://privatepaste.com/5092f7ddac . That'll only be up for a month, but if you find it useful, feel free to copy it elsewhere. I think it's safe to ignore the "on" times in your bit counting and decoding routines, this protocol doesn't use the on times for anything more than sync and spacing, and it'll probably make your counting a bit easier.
ReplyDeleteI'd add your data to mine and see what else I could figure out, but I'm rather lazy and this spreadsheet is along the wrong axis to fit easily into my stuff.
Anyways, hope you get some use out of those notes.