Wednesday, May 11, 2016

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.

Monday, January 25, 2016

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.

Monday, August 27, 2012

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.

Sunday, July 29, 2012

Back to Tag

I haven't posted much here lately, but things have been happening.

TagFest came and went, and with it the first public hands-on(Well, second. That one was under an informal non-disclosure agreement, though, so not exactly public.) with the shiny new LTAR.

While there, we got to play with the first 12 production-model LTARs off the production line. It was a blast.

While others have already posted their thoughts on this tagger before, I'd like to put mine out there as another set of datapoints.

Tuesday, June 12, 2012

Game Design Log - Entry #14 - Final

Got the highscore stuff done. When you land successfully, if you beat the best time, it says "New highscore!". If you didn't, it shows you what the best time is. Either way, it shows you your time.

This isn't exactly fair, though, as the random terrain generation lets you just keep going until you get one that's straight down and not very far from your starting point. But, it'll work.

The code is at http://code.meldaire.net/lunarlander. I don't have the current version up at the moment, but when I get home, I'll make sure and push it up there.

Game Design Log - Entry #13

Whoops. Forgot about this again...

The game is functional now. It generates a random landscape(Which is guaranteed to have a flat section on it), starts you in the top center of the screen, and lets you have at it. When it sees that the ground is within a 1-pixel boundary of your lander, it runs a bunch of checks to see if you can land successfully at that moment. If yes, you win. If no, it changes the lander graphic to an explosion, plays an explosion sound, and you lose.

The only requirement I haven't met is disk access. I'm not familiar enough with C# to do things the way I want to, and I haven't had the time this last week to familiarize myself with the bits I need. Or think I need, anyways.

Attached is a scan of the explosion graphic.

Thursday, May 31, 2012

Game Design Log - Entry #12

The last few weeks have been crazy. I've started work on several projects in addition to what I'm doing for school, and a lot of stuff has been going on besides that... But, things are still progressing with the game, and I think I'm in the home stretch now.

The current state of the game is that most of the "required" things are there. The controls work, there's enough feedback from the HUD to be able to finish the game(As soon as the game can be finished, anyways), and I've got a working way to detect when I hit the ground.

All that's left(I think) is to do the game logic for when I hit the ground, a few graphics tweaks(Have it show something when the engine is firing, an explosion when you crash), some kind of options thing when you start it up, so you can change difficulty stuff... And I think that's it.

Of those, the only one that seems even remotely difficult at the moment is the options thing. Mostly because I have no idea how to work with multiple forms. We'll see if that happens.