I am not an electrical engineer doctor

I've been looking at boosting the output of the IR leds for the laser tag host transceiver using an SN754410 H-Bridge but the math isn't quite coming out right.

So, something about this doesn't look right:

1,2 EN = Arduino's 5V
1A = PWM control signal
1Y = 3 TSAL6200 IR LEDs in parallel -> 100 Ohm resistor -> Arduino's ground
VCC1,VCC2 = Arduino's 5V
GROUND = Arduino's ground

For one, I am just now noticing that the TSAL6200 is rated to a max of 1.6V while I've been running at 5V (Nothing exploded). Given that the SN754410 is rated for a minimum 4.5V (maybe not the most appropriate part) I might have to step down the voltage on the output like this.
Second, it appears while the digital IO pin on the Arduino (what I am currently using) maxes at 40mA, the 3.3V line only does 50mA. There is no max listed for the 5V pin but one can assume comparable. This would imply I really can't drive the max amperage for the 3x LEDS (100mA each).
So, lets start again for an easy to acquire ~4.5 V supply, divide by 3 to be within the TSAL6200's max voltage, and add a draw of 300 mA:
Ohm's law:

0.3 A = 1.5V / x Ohm
5 Ohm = 1.5V / 0.3 A

Voltage Divider:

1.5V = ( Z2 / ( Z1 + Z2 ) ) * 4.5V
1/3V = ( Z2 / ( Z1 + Z2 ) )

I am guessing here but I think we want Z1 = 5 Ohm. With little confidence that is correct lets keep going:
Update: I've been corrected and we want Z2 to be 5 Ohm, see the comments for the new result.

1/3V = ( Z2 / ( 5 Ohms + Z2 ) )
5/3 Ohms + Z2/3 = Z2
5/3 Ohms = Z2 * 2 / 3
5 Ohms = Z2 * 2
2.5 Ohms = Z2

This gives:

1,2 EN = Arduino's 5V
1A = PWM control signal
1Y = 5 Ohm resistor -> 3 TSAL6200 IR LEDs in parallel -> Battery ground
                    -> 2.5 Ohms -> Battery ground
VCC1 = Arduino's 5V
VCC2 = 4.5V Battery
GROUND = Arduino's ground

So, where did I do it wrong?

Less Lazy Code

I finally got around to getting rid of the UI glitches cause by TX in the laser tag host. New version here. Or you can grab the code here.

Yay lazer tag!

Lazer Tag Host Binaries part 2

Ok, I took the previous post of binaries down because I thought those binaries might have been broken but it was just me. Here is a new link. They are tested and work in ubuntu 10.10 and windows 7. I know in windows 7 I had to install gtk# as well to get it to open. If your arduino isn't programed the app may hang, if it isn't plugged in you should be fine but won't get past the setup menu.

Download gtk 2.22
More Versions

Update: You also need a recent version of GTK installed in addition to gtk#.
Update 2: It appears that the release version doesn't work for everyone. Try the debug version if you are having issues.

Patents?

Someone apparently located the LTTO patent (US7632187). That would have been totally useful.

Actually, reading it now it would have been super useful. It details all the bit fields. Most of mine just switch the whole byte on the game type because the LTTO only starts games with one set of settings. I guess there is quite a bit more I can do. Rapid tags? Neat!

This is how you build a laser tag hosting station

Official Note: This works better if ground is connected to something, I suggest the middle pin of the IR receiver.

Clearanced-based Hierarchical Pathfinding (HPA*)

Aigamedev.com seems to always have something interesting to read. This week it is using Annotated A* to find a path of at least minimum clearance through a graph. They also go into how you can reduce the graph to an annotated hierarchical pathfinding graph for near-optimal results at much greater speeds. The article is well explained and comes out with a very practical result.

If your not convinced maybe their talk on zombie brain AI from last month will convince you.

LazerTag Team Ops Packet - Part 4

I figured out the final scoring details and completed the GUI. You can host a complete game from the GUI now and get all the score readouts.

The fields worked out as follows:

COMMAND_CODE_PLAYER_REPORT_SCORE_RECORDS
0x041-0x043, //command code (last two bits are the team number)
0x00, //game id
0x10, // team_number << 4 | player_number
0xXX, //player hit mask
0xXX, //hits from player indicated by first set bit in mask
0xXX, //hits from player indicated by second set bit in mask
... (the hit bytes sum to count_ones(mask_byte)
0x100, //checksum

The secret to determine the SCORE_RECORD was noticing that COUNTDOWN varied more then I noticed in my initial testing.

COMMAND_CODE_COUNTDOWN_TO_GAME_START
0x000, //command code
0x00, //game id
0x30, //seconds left in digit hex
0x08, //players on team 1
0x08, //players on team 2
0x08, //players on team 3
0x100, //checksum

If t2p0 shoots t1p0 and "players on team 2" == 0, then t1p0's gun will ignore the shot. Hence, those shots won't show up in the score report.

The following packets still have unknown values:
COMMAND_CODE_SCORE_ANNOUNCEMENT
COMMAND_CODE_PLAYER_REPORT_SCORE
COMMAND_CODE_GAME_OVER

Hey you, decode!

As always, get the code here.