Friday, March 25, 2005

TAG2020 Evolution

I've been considering the TAG2020 system.

We're looking at major reuseable software components of:

  • IR TX
  • IR RX
  • LED muzzleflash
  • LED hit signaling
  • CANbus
  • 802.15.4

Uses of the above:

  • Hit tracking
  • Weapons fire
  • Intelligent weapon linking to user
  • Remote intrusion sensors
  • Squad Area Network

The 2020 weapon is being redefined. We're reconfiguring them into several major parts.

  • IR LED Transmitter: CAN equipped microcontroller that's dedicated to IR transmission
  • Gun controller: Most likely also the IR LED Transmitter, manages the CAN network, integrated 802.15.4 transciever for linking to the larger network. May have an LCD and buttons or headers for low cost triggers and readouts. May also have a hot-swappable "side ID" for games that use user removeable modules to allow changing of sides.
  • Trigger module: Each trigger module is CAN networked to the Gun controller on a common bus. This allows multiple weapons to use one transmitter. Weapon types may be ordered by priority. The trigger module may be used as a weapon type controller to allow modular reconfiguration on the fly.
  • Reload bay: CAN networked bay that controls ammo feed. Has optocoupled links to ammo clips as used.

2020 Hit Sensors will either have CAN or CAN and 802.15.4. They will use the same substrate, just varying in equipped parts to allow for mass production. Bus power may be provided to reduce battery numbers.

2020 intrusion sensors will share a standard 802.15.4 interface. This may be merged with the Hit Sensor board and have specific sensors (acceleration, tripwire, etc) added on via daughterboard connection. CAN may be provided as an alternate long range option (at 20kbps 1km range)

2020 Base packs will be made to communicate with 2020 LCD/UI units. The LCD/UI units will be mostly dumb, acting as a detached wired/wireless link to the Base pack. Standard Base pack options:

  • Player ID
  • Statistics tracking
  • 802.15.4 controller master
  • Hit sensor location tracking (for "realistic damage" games)
  • Automatic configuration
  • Basic hit detection (extra sensors not needed to play)
  • Expansion slots/headers (bussed?)

Basic game setup will be:

  • 1 gun (1x IR Transmitter, 1x Gun Module, 1x Trigger, 1x reload bay)
  • 1 Base pack (backpack, rear hit detection)
  • 1 LCD/UI module
  • 2 hit sensors (front torso hit detection), CAN interface.

Optional future Base pack modules:

Saturday, March 19, 2005

Modular Parts

In the little time that I actually code and test the RC core, I've come up with a list of modules that it's running.

  • A to D conversion with reading to output transform
  • R/C servo control
  • 2.4GHZ transciever
  • Brushed Motor Control
  • CAN network

Now, as I look at the MilesTAG2020 system, I have these modules:

  • A to D conversion
  • IR encoding
  • IR decoding
  • 2.4GHz Zigbee transciever
  • CAN Network
  • Brushed motor control (feedback, cyclic operation)
  • R/C servo control (turrets, drive motors)
  • Human Interface design (LCD menus)

Although not initially intended to be used together, the RC core will become a stepping stone for the MILES2020 system. I suspect I might make a few target drones and recon UGV's eventually, maybe even put a turret on a UAV.

Now, I need a name that isn't TM the MilesTAG guys, but relates to being compatible...

Friday, March 11, 2005

Yet more projects?

A lot of my projects are things for me to mess with, and many that are high speed logic need a few more intermediate projects thrown in before they should be attempted. So, I ran across a very cool project page.

http://www.lasertagparts.com/mtdesign.htm

I'm thinking of breadboarding their basic circuits for a little fun, then going for a high tech Zigbee upgrade. Every player would have a gun, a backpack, a helmet/hat, and a few other sensors. Many sensors would just be a Zigbee unit, LED's, an IR sensor, and a PIC for logic control. The gun would be similar to the designs above. The backpack would be used for radios and some high tech gadgets. The helmet may have a comm headset, but would otherwise be there for protection/team identification.

I'm considering giving it a larger LCD (2x16?) and using capacitive switches for user interface, keeping the box sealed and possibly a bit more watertight.

For another trick, a serial bidirectional optocoupled box would be used for a magazine. A simple pulse request for one round of ammo would be flashed to the box, it would respond with a pulse if it has one. I'd either put a battery inside with a switch to restart it, or use a very low speed loop wireless system to reset (like 125KHz). There would be microswitches to turn on/off the interface. If field reloads are possible, timing lockouts and a reload field back at base would be used. This would keep people from sitting in the reload area with infinite ammo. The interface itself would be small and universal, the changes in the box would be different for different weapons.

Hmmm... more later....

Friday, March 04, 2005

DSOs and Compilers

Still finding time here and there that I feel I can code. So, some new things I've drummed up or run across.

Oscillopen

I still would like to build a DSO for my computer eventually. For this, I came up with a different method that may still be compatible with the original Bitscope. Instead of using a CPLD to feed SRAM data from a ADC, why not use a FIFO? TI sells a nice reconfigurable one that'll be useful for porting data anywhere from 8 to 16 bits wide into an 8 bit serial port on a PIC. The 64K/128K buffer is about the same as available on the bitscopes. I may configure it to have an 8 bit ADC and an 8 bit logic capture, or maybe a 12 or 16 bit ADC. I like both options, maybe I'll build both. I can run the FIFO up to 167MHz, far exceeding the capture rate of the Bitscope, but I lose the Bitscope's flexibility and mode triggers made available by the CPLD. Still might be a good project, especially since I don't have to run it at 167MHz. A USB PIC can live on the output end of the FIFO to provide a USB control and transfer interface to a PC. If I build it with a slower 16 bit ADC, I might consider using a dsPIC and doing a live digital filter or micro-based SRAM transfer instead.

As for Oscillopen? I'd like to try to fit it all into the format of a fat marker, and either make it battery powered or a USB port on the far end with either a single BNC or similar connector on the input end.

Free Compiler

Wll, Microchip's at it again. They've released their C18 C compiler for the 18F series for free now. Sorta. It's the student edition. It will stop being it's most optimized after 60 days IIRC, however, it will continue to work. Win win situation for hobbyists in my opinion. If you need better speed and smaller code, go assembly. I still plan to code my R/C core in assembly first, as a learning experience.