Digging deeper (Recoil: Part 4)

So in the previous IR digging, I decided upon a decoding scheme(Short bits are less than 0.575ms, and are "0"s, long bits are longer than 0.575ms and are "1"s). So let's go through all these captures and see what we find.

Pistol, single shot

<START>
<SYNC><SYNC DELAY>00000010000111000000000000001100001<6.865ms delay>
<SYNC><SYNC DELAY>00000010000111000000000000001100001<10.87ms delay>
<SYNC><SYNC DELAY>110010000111000000000000001000011<13.84ms delay>
<SYNC><SYNC DELAY>110010000111000000000000001000011
<END>

Huh, so there's actually multiple packet lengths. Hadn't noticed that before. I'll have to keep an eye on that.

Pistol, trigger held

<START>
<SYNC><SYNC DELAY>00111000011100000000000000100000000<12.86ms delay>
<SYNC><SYNC DELAY>00111000011100000000000000100000000<60.9ms delay>
<END?>
<START>
<SYNC><SYNC DELAY>100110000111000000000000001100100<22.87ms delay>
<SYNC><SYNC DELAY>100110000111000000000000001100100<26.9ms delay>
<SYNC><SYNC DELAY>00001000000111000000000000001110000<21.87ms delay>
<SYNC><SYNC DELAY>00001000000111000000000000001110000<47.89ms delay>
<END?>
<START>
<SYNC><SYNC DELAY>111000000111000000000000001001100<24.89ms delay>
<SYNC><SYNC DELAY>111000000111000000000000001001100<11.89ms delay>
<SYNC><SYNC DELAY>00100000000111000000000000001001001<19.87ms delay>
<SYNC><SYNC DELAY>00100000000111000000000000001001001<46.95ms delay>
<END?>
<START>
<SYNC><SYNC DELAY>100000000001110000000000000011111<13.09ms delay>
<SYNC><SYNC DELAY>100000000001110000000000000011111<55.98ms delay>
<END?>
<START>
<SYNC><SYNC DELAY>00000010000111000000000000001100001<12.89ms delay>
<SYNC><SYNC DELAY>00000010000111000000000000001100001<23.9ms delay>
<SYNC><SYNC DELAY>110010000111000000000000001000011<15.87ms delay>
<SYNC><SYNC DELAY>110010000111000000000000001000011<62.93ms delay>
<END?>

(Note for myself, this only gets up to 2500ms into the capture, so I can come back and get more if I need to later)

Grenade, button held

This is pairing mode. Probably going to be the same set of packets over and over again, since the grenade has no receivers.

<START>
<SYNC><SYNC DELAY>101000010000001000010011110000100<28.46ms delay>
<SYNC><SYNC DELAY>101000010000001000010011110000100<28.44ms delay>
<SYNC><SYNC DELAY>101000010000001000010011110000100<46.01ms delay>
<Stray 54us pulse><32.74ms delay>
<SYNC><SYNC DELAY>101000010000001000010011110000100<28.46ms delay>
<SYNC><SYNC DELAY>101000010000001000010011110000100<28.43ms delay>
<SYNC><SYNC DELAY>101000010000001000010011110000100<28.45ms delay>
<SYNC><SYNC DELAY>101000010000001000010011110000100<28.43ms delay>
<SYNC><SYNC DELAY>101000010000001000010011110000100<28.46ms delay>
<SYNC><SYNC DELAY>101000010000001000010011110000100<28.45ms delay>
<SYNC><SYNC DELAY>101000010000001000010011110000100<30.04ms delay>
<Stray 0.1827ms pulse><0.3892ms delay><Stray 77us pulse><18.23ms delay><Stray 0.1823 pulse><29.68ms delay>
<END>

The grenade repeats the same packet forever in pairing mode, it looks like. It looks like it sends the packet 16 times, with a ~28ms delay between packets, and then stops transmitting for half a second, then begins the cycle again. The transmitting time total is ~776ms, and then it waits for ~480ms.

I also wonder about the noise I seem to be seeing. It looks like it's always in the fourth and twelfth packets in a burst. This could be either the AGC in the three-pin receiver I'm listening with, or it could be a glitch in the grenade itself, but it's /very/ regular.

I should capture another one of these and see if it still happens, and if the packet it sends changes between pairing instances.

Grenade, firing after countdown

<START>
<SYNC><SYNC DELAY>1100000000000010000100111100111<28.46ms delay>
<SYNC><SYNC DELAY>1100000000000010000100111100111<28.43ms delay>
<SYNC><SYNC DELAY>1100000000000010000100111100111<78.79ms delay>
<END?>
<START>
<SYNC><SYNC DELAY>1100000000000010000100111100111<28.46ms delay>
<SYNC><SYNC DELAY>1100000000000010000100111100111<28.43ms delay>
<SYNC><SYNC DELAY>1100000000000010000100111100111<28.46ms delay>
<SYNC><SYNC DELAY>1100000000000010000100111100111<28.43ms delay>
<SYNC><SYNC DELAY>1100000000000010000100111100111<28.46ms delay>
<SYNC><SYNC DELAY>1100000000000010000100111100111<28.43ms delay>
<SYNC><SYNC DELAY>1100000000000010000100111100111<28.46ms delay>
<SYNC><SYNC DELAY>1100000000000010000100111100111<78.8ms delay>
<END?>
<START>
<SYNC><SYNC DELAY>1100000000000010000100111100111<28.46ms delay>
<SYNC><SYNC DELAY>1100000000000010000100111100111<28.43ms delay>
<SYNC><SYNC DELAY>1100000000000010000100111100111<28.46ms delay>
<SYNC><SYNC DELAY>1100000000000010000100111100111<28.43ms delay>
<SYNC><SYNC DELAY>1100000000000010000100111100111<28.46ms delay>
<SYNC><SYNC DELAY>1100000000000010000100111100111<28.43ms delay>
<SYNC><SYNC DELAY>1100000000000010000100111100111<28.46ms delay>
<SYNC><SYNC DELAY>1100000000000010000100111100111<78.8ms delay>
<END?>

It seems to repeat this 7-signature burst and delay cycle for ~22s, then it switches to a constant stream of signatures for another 10s. The constant stream is the same signature, just with only ~28.5ms delays, no ~79ms delays.

Grenade, turned off early

<START>
<SYNC><SYNC DELAY>1110010000001000010011110000001<29ms delay>
<NOISY PACKET><30.54ms delay>
<SYNC><SYNC DELAY>1110010000001000010011110000001<28.5ms delay>
<END>

It basically just repeats the packet with a 28.5ms delay between them for 2.5s. Possibly an "unpair" command?

The grenade also sends the longest long bits I've seen, at 1.088ms. Possibly need to revise the maximum allowed length up to 1.1ms...

Contrast and compare...

Blaster shots seem to consist of two signatures, adding up to a total of 68 bits of data... Possibly only the 35-bit signatures are shots, and the 33-bit signatures are a general "data" packet? I don't see any 35-bit signatures that start with anything other than two 0 bits, and I don't see any 33-bit signatures that don't start with a 1... So let's take another pass at this data and see what patterns come out from these observations.

Well, just putting the bit patterns into notepad and removing all the duplicates, I realize that both the grenade being turned off early and the grenade "firing" both send 31-bit packets, so there's a third packet length to consider.

I'm gonna go capture another set from the grenade and see what if anything changes, and what stays the same.

More captures from the grenade

I took another set of captures in this order: Pair, fire, turn off early. Let's see what the data is.

Pairing: <START><SYNC><SYNC DELAY>101000010000001000010011110000100<delay><END>
Firing:  <START><SYNC><SYNC DELAY>110000000000100000010011110010000<delay><END>
Off:      <START><SYNC><SYNC DELAY>1110010000001000010011110000001<delay><END>

So the pairing and off-early packets are the same, but the shot packet is different... Alright... I really wish I had a second grenade here, to see if the pairing/off-early packets are the same between grenades, or unique...

.........WAAAAAIT A SECOND... That grenade shot packet is a different length from the previous one! The heck..? Now I need to capture a couple more of these...

But for now, I'm going to go get lunch, and let the confusion simmer for a bit. Maybe I'll have some insight into what might be going on.

Would you like to play a game? (Recoil: Part 3)

Boot the hub, install the app on the coworker's phone, fiddle with it's wifi settings, connect to the hub, connect my phone to the hub...

Not a whole lot of options to setting up a game, but both devices join and get into the game easily. The countdown to the beginning of the game is /way/ out of sync between the two devices, but once in-game the time seems to catch up... The Indoor Skirmish seems straightforward enough, being a free-for-all with timed respawns. It allows you to pair the grenade, but it doesn't actually do any damage. If the host exits the game, the other players get kicked out, and they get a scoreboard, but the host doesn't. In Outdoor Skirmish, the grenade seems to function as expected. There seems to be some feedback via the app when you hit other players, which is neat. The back button is supposedly a voice chat button, and it makes a chirp when you press it, but I can't actually hear anything coming out of either device when I talk into the other while holding the button down.

After running around outside with it for a while, the only notable weirdness we ran into was that the voice chat thing never seemed to work. We brought in a third device, and all three of them just gave static on the other devices. When you get close to the edge of WiFi range(Which is actually surprisingly hard to do, we were a good 300-400 feet away from it in a straight shot), it warns you to return to the area. If you don't and actually manage to leave WiFi range, it will pop up and say you're disconnected from the hub, and to check your wifi connection and get closer to the hub. At this point, I did have to reconnect to the hub's wifi network manually, but once I did, it put me right back into the game. While in the "edge of connectivity" and "disconnected" states, you don't appear to be able to take damage. We didn't check whether you could still give damage, but I would assume(Or hope, at least) not...

We did play with the grenade while outside, too. It's... Rather underwhelming. It does the ten second countdown, and then does a single burst of damage(About a segment and a half  of the health bar?), and... That's it. It's still blatting out a /ton/ of IR, but you don't take any more damage from it for the rest of it's 45-second firing spree.

None of the devices we played with had an accurate compass in the game. We would have to move opposite to the way it told us to get to the respawn zones. This is... Kinda annoying, because so much of what Recoil has to offer needs you to be able to navigate to an invisible point in the real world. There's ammo boxes, health boxes, special ammo types, extra armor, airstrikes, and probably other powerups scattered around the world, but if the game can't guide you to them easily, you're just going to get frustrated with it. When you're "killed" in an outdoor game, you need to find your way to a respawn zone, and it gives you a compass arrow and a range. If the compass arrow is useless, you're left with a range, and both of us had to wander back and forth a bit to figure out which direction we needed to go.

Perhaps the coolest feature we found, though, is that even if you miss a player, if you're aiming in their direction, they'll hear shots whizzing past them from their phone.

All in all, we're pretty impressed with what the system has to offer so far. There's a few issues that need worked out, but for as short a period as we've been testing it, and how thoroughly thought out everything's been so far, there's a pretty good chance they'll manage to fix the rest(Well... Except the no-functionality-without-a-phone bit... That's something that can't really be worked around, at this point.).

Waiting for a device, digging into the IR (Recoil: Part 2)

Well, none of the devices I have available to me at work are new enough to run the Recoil app, so digging into the gameplay will have to wait until tomorrow. Instead, I'll dig into the IR protocol a bit, and see what info can be gleaned from it.

The setup

I have a Saleae Logic that works great for things like this, and a little IR receiver gadget that's not much more than a 38KHz 3-pin IR receiver, a resistor, an LED, and a battery pack. So by connecting the Logic to the IR receiver's output, and the battery pack's ground, I have a nice little visual indication on whether I'm receiving anything at all, and the Logic captures it to my PC for analysis.

So let's grab some signals!

Capturing 

Thanks to having had the IR gadget on earlier, I already know the various ways to get things to send IR. There's a whole five captures I need to do: Grenade with countdown, turning the grenade off early, holding down the grenade button, a single shot from the blaster, and holding down the trigger on the blaster. A few minutes of setup and renaming files, and that's done. So what do we have?

What it looks like

What I believe to be the basic unit of data in the Recoil IR protocol

Keep in mind that 3-pin IR receivers tend to be active low, so the signal goes down towards the bottom when signal is present, and back to the top when there isn't. So, right off the bat, we have a nice long SYNC pulse(3.3ms), and then a delay(1.5ms), and then a bunch of data. Data looks to be encoded in both the high and low states, so you'll need to be able to capture times on both edges.

You'll also note that I captured two "packets" in a row, and that these are identical "packets". Everything that's sent from the blaster seems to be sent like this, probably for error checking purposes. The grenade seems to send the same packet over and over and over.

Now, back to the encoding. It looks like there's a "short" and a "long" bit, with short bits being (very) roughly 0.4ms, and long bits being 0.8ms. Tolerances are /very/ wide on these timings, with anything from 0.276ms to 0.927ms being seen.

I'm arbitrarily setting the threshold between a "short" and a "long" bit at 0.575ms, a minimum valid period of 0.25ms, and a maximum valid data bit period of 1ms.

I'm also arbitrarily saying that a "short" bit is a 0, and a "long" bit is a 1.

So the packet shown in the screenshot above would decode as 00000010000111000000000000001100001, or 00000010 00011100 00000000 00001100 001. This seems a bit weird, that it's 35 bits... But for now, I have no better ideas on how to decode it, so I'll stick with a 35-bit packet for now.

For the moment, a coworker lent me their phone for the purposes of trying out the actual gameplay, so let's switch gears again!

Another day, another tag system (Recoil: Part 1)

It's been a while since I've done a laser tag post! There's a new contender on the block, and it's time to run it through it's paces! This time, I've got the Recoil Multi-Player Starter Set in-hand.

The Recoil Multi-Player Starter Set box

The things inside the box

The right side of the RK-45 SPITFIRE Recoil Weapon

The left side of the RK-45 SPITFIRE Recoil Weapon

The front of the Wi-Fi Game Hub

The back of the Wi-Fi Game Hub

The front of the FRAG Grenade Recoil Weapon

The back of the FRAG Grenade Recoil Weapon

As I did with the Lightstrike gear, I want to do as in-depth of a look at this stuff as I can. I'm going to start with the basics(How it feels, whether it plays well), and then dive into the technical details. So let's get going!

Impressions (Before batteries)

The blasters have a good weight to them already, which has me a bit worried that they might be heavy once I actually put the batteries in. There's a whole four buttons, which is reasonable enough. A trigger, a reload, and two other buttons that I'm not actually sure what they are yet. The buttons themselves feel good, though there's no tactical feedback on when the trigger actuates. It's got several three-pin IR receivers poking through the case around the front end, so it should have a fairly decent field of vision. This blaster actually has a three glow-dot iron sight(Two red dots on the rear, one green dot on the front) on it, which is awesome. The iron sight is about as long as they could make it and still fit on the blaster, so if it's well-aligned with the optics in the blaster, it should actually be reasonably accurate.

The blaster's iron sights

The grenade is a pretty good size for throwing, and is pretty rubberized so it should survive the being thrown. It still probably wouldn't be pleasant to get hit with, though, so still be careful where you're throwing it. It's got a lot of LEDs on it, which bode well for either IR coverage or blinkiness.

The Wi-Fi Game Hub is a box with an antenna, a power button, and a battery compartment. There's also a MicroUSB B port on the side. Not a whole lot to say about it, though the built-in handle is a nice touch.

Impressions (After batteries)

As I feared, the blaster is a bit heavy now that I've put batteries in it. Specifically, it's front-heavy. You can use the... Well, it looks suspiciously like a GoPro mount, now that I look at it... You cna use the GoPro mount as a hand-rest for your opposite hand, and it still feels decent, but using it one-handed is probably going to be tiring on your wrist. The round button on the side is the power button, apparently, as it lights up green when I press it, and turns off if I hold it for a few seconds and let go. Even without pairing a phone in, the tagger appears to launch into an "active" mode, where you can pull the trigger to fire in a fully-automatic mode. There's a fairly nice recoil effect, too. Kinda noisy, but it's got a good feel to it. Turning on an IR receiver gadget, I can see that it does send an IR packet with every trigger pull. Somewhat... Questionable... Is that it also has a red LED on the front that blinks as a "muzzle flash" with every shot...

The frag grenade's button appears to have three "modes". Pressing it once turns the grenade on, and it starts blinking a 10-second countdown on the LED, and then sends a flood of IR packets out for 45 seconds. Holding the button blinks the LED off and on until you let go, and it sends IR packets for one second, then doesn't for one second, and repeats this two-second IR cycle until you let go of the button. Pressing the button to start the countdown, then pressing it again before it finishes seems to turn it off, and then it sends about three seconds worth of IR.

The Wi-Fi Game Hub seems to have a couple different button states, too. The first press turns it on, and the LED starts doing a pulsing fade-in-and-out thing. Pressing it again after that will make the LED blink on and off for a bit, then turn off. I assume this is a "safe shutdown" thing. Holding down the button while it's doing the pulsing will make it start to do a "half-pulse", where it goes between 50% and 100% brightness. The hub doesn't appear to have an IR capability.

Turning on various combinations of blasters and the grenade, none of them appear to respond to each other at all yet. So there doesn't appear to be any "simple" games that don't need an app. Though on closer inspection, I notice that there's no speaker on the blaster, so there's not really any way to give feedback for the game progress... Can't tell a person they've gotten hit when the only feedback method is the rumble/recoil motor, which is already used for firing.

Starting up the app

My phone's an LG G5, running LineageOS(Android 7.x). Starting up the app, it asks for location, SD card storage, camera, and microphone access. It asks for me to agree to an EULA, and for a nickname, then tells me to turn on the Wi-Fi Game Hub. Apparently I never waited long enough for it to finish booting up, because it says to wait 30-45 seconds for the LED to stop blinking before going on to the next step.

It then walks me through connecting to the hub, and warns me to disable cell data and that I might need to tweak other settings to get my phone to stay connected to the hub(This is a known problem with cell phones trying to connect to ad-hoc networks made by devices that don't have an internet connection, so nothing unexpected, just unfortunate).

It then asks me what kind of blaster I want to use, and then turns on Bluetooth and connects to it.

I wander through the menus for a bit, and there's options to change your nickname, and little help things for how to use the grenade(Which tells me that the "hold button" mode I found earlier is for claiming the grenade by a player during the game).

I hit the "Battle" option, which then starts a firmware update on the hub, and tells me to restart it by pushing the button, waiting for the blinking to stop, then push the button again to turn it back on and wait for the pulsing to stop. This goes well, and my phone automatically reconnects to the hub.

There's a few game types available currently, split into "Indoor" and "Outdoor", with the note that outdoor games require GPS. I'll get to the outdoor stuff later, for now I just want to see what Indoor does, so I pick the only Indoor option currently available, "Skirmish". It then asks me how long of a game I want, with a default of 2 minutes, and a score limit, which defaults to unlimited. It then drops me into a lobby, and I remember that the hub has no IR functionality, and there doesn't seem to be a way to use a blaster with no device paired to it... So I go start digging for another device to use with the other blaster...

And the work devices need to charge, so I'm gonna have to take a break here while that happens.

Current impressions

That there doesn't seem to be ANY no-device functionality, the build quality seems pretty good, and the hints I'm getting from what I've seen seem to imply that things were well thought through before implementation. Impressions of the app are minimal yet.

USB Charger Notes

So while I've been working on a project at work, I've been doing some stuff with USB ports and drawing safe amounts of power from them.

There's a lot of information out there on this subject, and the official standard (Battery Charging Specification Revision 1.2, by the USB Implementers Forum, is the latest version I could find, and the one I used for my work project. Get in touch if you can't find a copy of it!) contains a very good runthrough on identifying standards-compliant USB ports.

But there's some very big names that are /not/ standards compliant, and historically have very little chance of becoming standards compliant in the near future(coughcoughApplecough). There's a lot of information about these chargers, as well, but not quite enough, as I've managed to find a seemingly undocumented variant of an official Apple charger. Apple chargers put specific voltages on the data pins that are used for determining the amount of current that the attached device is allowed to draw. I also include Apple model numbers, for easy reference to see if you've found a "new" device that's not on here, though there's actually not room left in this non-standard-standard for new ones...

Description	Apple Model #	Rated Output	D+ Voltage	D- Voltage
2.5W Charger	None	0.5A	2.0V	2.0V
5W Charger	A1102	1.0A@5.0V	2.0V	2.7V
5W Charger	A1205	1.0A@5.0V	2.0V	2.7V
5W Charger	A1265	1.0A@5.0V	2.0V	2.7V
10W Charger	A1357	2.1A@5.1V	2.7V	2.0V
12W Charger	A1401	2.4A@5.2V	2.7V	2.7V

The 2.5W charger values are not actually found in an Apple-sold charger, but was found in third-party Apple-compatible products.  It may or may not work on an Apple device at this point, but there are chargers floating around that use those values to indicate that they are a 2.5W charger.

Building off of that and including the Battery Charging Specification Rev1.2, we can build a table of states that can identify both standard and Apple chargers. For each column in this table, if a given row is not filled, that test does not need to be done to determine whether this port is that type. For each row in this table, all filled columns' tests should be done in a left-to-right manner. The rows should be tested for from top to bottom, and the first match will be the limit used. Terms used here that have not been mentioned previously are most likely referring to the Battery Charging Specification.

Description	Allowed Current	Primary Detection, CHG_DET state	Secondary Detection, DCP_DET state	D+ Voltage	D- Voltage
Standard Downstream Port	0.1A for 45 minutes	False	-	-	Below 2.0V
Apple 12W Charger	2.4A	False	-	2.7V	2.7V
Apple 5W Charger	1A	False	-	2.0V	2.7V
Apple 10W Charger	2A	False	-	2.7V	2.0V
Apple 2.5W Charger	500mA	False	-	2.0V	2.0V
Dedicated Charging Port	At Least 500mA	True	True	-	-
Charging Downstream Port	1.5A	True	False	-	-

Note that this does NOT cover every type of charger covered in the Battery Charging Specification! These are only the states that can be tested for with only the main four USB pins, and without actually enumerating as a device. The fifth pin available on mini/micro USB ports adds a whole lot of configurability to devices that support using it, and enumerating opens up a lot of possibilities(Like the ability to be denied power), but for the purposes of my work project, this is as far as I am able to go with this.

Please be careful, especially with the SDP state! We don't want to burn up people's USB ports! Read the Battery Charging Specification for a lot more details, but this table is one that I ended up building just to double-check my program against, so hopefully someone else finds it useful.

Random Blaster from Amazon

Last week sometime, Jammer found an Amazon listing for a blaster by Simply Addictive Games, that they're calling CALL OF LIFE. It looked suspiciously similar to the Lightstrike gear of days-gone-by, and I bought a pair of them to sate my curiosity.

Advertised setup:

• 4 weapons in each blaster with different sounds/damage amounts
• 4 teams, no friendly fire
• Single sensor, facing forward

They came in today, and it really looks like this is a heavily cost-reduced version of another product, whether it was Lightstrike or something else. There's a transparent piece on the top side of the blaster where they could have put additional sensors, and a floating piece on the back of the top with a fake display that was probably originally supposed to be a real LCD.

They don't exactly promise much, but they do deliver on the features they talk about, and there's also a rumble motor that gets used when firing and I assume when you get hit that they don't mention on the Amazon listing.

Now, onto the juicy protocol details!

Despite looking suspiciously like a Lightstrike recase, it's got an incompatible protocol.

Probably a bit hard to see in there, but it looks like there's five different time increments involved in this protocol. There's a ~1.65ms SYNC pulse, and then different long and short pulses for the active and inactive side of each cycle after that. It looks like both the active and inactive sides are used for data.

SYNC: 1.65ms
Inactive short: 0.33ms
Inactive long: 0.73ms
Active short: 0.45ms
Active long: 0.85ms

I don't actually know what the tolerance of these signals is, so I'm just cutting it off at hundredths of milliseconds after averaging a bunch of the various timings I see in the signals I captured.

I'm going to assume that both of the "shorts" are 0s, and both of the "longs" are 1s.

So decoding the various shots this way, you get...

Blue team, pistol: SYNC/00000000 10101010 00000001 00000001 00000110
Blue team, shotgun: SYNC/00000000 10101010 00000001 00000010 00000111
Blue team, submachine gun: SYNC/00000000 10101010 00000001 00000010 00000111
Blue team, missile launcher: SYNC/00000000 10101010 00000001 00000011 00001000

Green team, pistol: SYNC/00000000 10101010 00000011 00000001 00001000

Red team, pistol: SYNC/00000000 10101010 00000010 00000001 00000111

White team, pistol: SYNC/00000000 10101010 00000100 00000001 00001001

I didn't do an exhaustive capture of every combination, but I think this is enough to pull out the pattern.

The 5th byte looks like a checksum. 3rd and 4th bytes added together plus 0x04 looks to match these examples. The 1st and 2nd bytes are probably just extra syncing stuff, though it's odd that they don't have any examples of the active long pulse in there for clock adjustment. 3rd byte looks to be team, 4th byte looks to be weapon type.

Seems simple enough. The high nibble of the 3rd and 4th bytes could hide more features, but I'm going to guess at the moment that they don't. Maybe at some point I'll poke at it some, and see if I can generate some oddball signatures to throw at it.

Second hand stores

I love going through second hand stores. I find all sorts of neat trinkets and toys from years ago. Most recently, I found a Skannerz toy, from sometime in 2000. Still works, and it even had batteries in it.

I got to playing with this, and I got to thinking... Nothing really similar has been done lately, to my knowledge. With smartphones booming, the majority of them including cameras, there's no reason you couldn't do everything this toy does and more with the hardware that people are already carrying around.

And so an idea was born. I love when this happens.

I know there's barcode reader apps out there for Android, and if I remember correctly, you can take advantage of those apps from other apps. So I don't even need to write the barcode reader side of things. That's a huge portion of the work gone, right there.

So now we need a way to get a monster out of an arbitrary barcode. The first thing that came to mind is just using the numbers in the barcode itself. But then I remembered that those barcode reader apps also do QR codes, and NFC tags are starting to become more common. So we need a way to do it from not just an arbitrary barcode, but an arbitrary string, of arbitrary length and content.

New plan. Hash whatever data we get, so we get a fixed length and a fixed set of characters, and then use that hash to do your monster generation. Easy enough. MD5 has a fixed length, and is hexadecimal, and has been around long enough that there's implementations is pretty much every programming language out there.

Now, we need a way to get a monster out of that hash. MD5 isn't collision proof, but for what we're doing, it might as well be. This means we can't just use the raw MD5 hash to say "hey, this is monster". We need a way to make collisions happen. So we start dividing up the hash.

The easiest way to do this is to just grab specific characters and look at those. But that still leaves us with way too much room to work with in some ways, and not enough in others. My current thinking is that I'll grab a few bytes(MD5 results in 16 bytes. I'm thinking groups of four.), add those bytes together, and modulo 256 that result. This gives us much smaller numbers, and gives us a few "fields".

I'm thinking the first field would be a "type" or "group"(Or "expansion set") thing, so you could have different groups of monsters, items, etc.. Second field would be which actual item/monster that one is. Third field could be a "variation"(Think shiny pokemon). Fourth field could be a seed for a random number generator, for battle stats and things like that. This gives you room for expansion, down the road.

The problem here is that same expandability, though. The way I see it, there's two options here. You either leave a good chunk of hashes useless at the start(If you managed to fill out 64 full groups, you're still only using a quarter of all possible hashes out there. That's a lot of failed scans.), or you start out "wrapping" the hashes, and when you expand it later, some of your previous scans no longer lead to the same thing...

I don't really like either of these options. The first one leads you to a lot of failed scans(That using 64 full groups example? That's 16,384 items/monsters.), and the second one leads to confusion when you release the expansions, 'cus all these barcodes people had found don't necessarily point to the same thing anymore.

One option is to reduce your expandability, so there's less failed scans. This is probably a good idea, 'cus I really don't think you're going to use 65k item/monster slots(Even pokemon hasn't gotten that far yet). But there's still the problem of not maintaining a consistent successful scan rate, or causing confusion when all your barcodes change meaning with new expansions...

This is where I'm at at the moment. I'll need to think on this more.