HUD thoughts part 2

So, I've revisited the original thoughts on the HUD. I've been learning rotating machinery vibration analysis lately and it put the idea of a piezo driver in my head. This is probably similar to what drove the original Virtualboy 50hz vibrating mirror.

Vertical update is no problem, but the high kilohertz horizontal update requires some alternate ideas. There is a MEMs 2D galvometer mirror that's used in both military prototypes and in a civilian mechanic HUD design from Microvision. Interesting idea, but I fear the drive complexity and cost! Optics always need high accuracy positioning, which makes this project a bit more difficult. I've been considering attaching a first surface mirror to a standard piezo buzzer to attempt a more cost effective solution, but I need to get that hardware first. If it works, I'll be limited by the buzzer rate and how much annoyance I can stand (although placing it in an evacuated chamber might help with this issue, or getting an ultrasonic transducer). Another option is a multi-faceted edged mirror that can provide a rotary multi-Khz rate. This would probably be easier to sync with, but again it'd take accurate machining (16+ facets) and a high speed motor (12K+ rpm) depending onconfiguration, placing a small gyroscope near someone's face if head mounted. If a faceted tube can be designed, this might work well with a very small high speed motor, however.

Other ideas from the scratchpad: Direct AC coupled magnetic field driven vibrating mirror, using a 2nd hand DLP array from a projector,

I'm thinking of experimenting with either a high output laser or a small bank of collminating LEDs (say 8?) to provide a picture. I think the LED's will be a parrallel array, as setting up a line would only give each LED an extended off time, switching and light output per pixel will remain the same, requiring high end hardware. This arrangement will hopefully be a good tradeoff between a single galvo laser and the bulky LED bar.

For the semi-technical curious, a little bit of the basic design idea behind this:

I'm attacking this project as two separate optical components, one provides the "screen refresh", low frequency signal, the other provides the "line refresh" high frequency driver.

The screen refresh will hopefully provide a 30 fps update. Progressive scanning is the current objective. However, via flexible software design, we can cheat. Since a vibrating mirror has to go through the same arc twice in one cycle, a mirror vibrating at 15 hz can provide a 30fps update rate. My current goal is a 60fps update rate for active updates.

The line refresh is a LOT more annoying. I'm hoping to use an SPI or similar buffered serial interface to provide the pixel information to the imaging device (if it's a single laser). These top out at 10 Mbps.

The characteristics above relate together like this:

bps = h-pixel x v-pixel x bpp x fps
screen refresh = fps
horizontal line rate = v-pixel x fps

Example calculations:
800 pixels x 600 pixels x 1bpp (monochrome) x 20fps = 9.6Mbit/s
600 pixels x 20fps = 12Khz horizontal line rate

Note, 12Khz = 720K cycles per minute, FAR faster than even small gas turbines and anything spinning this fast is highly dangerous!

This is possible safely with a small piezo driver or with a high accuracy multifaceted mirror on a small electric motor. The greater the number of faces the lower the RPM, but also the mirror complexity skyrockets. The piezo driver would prove simpler, but garaunteeing its dynamics is a far more complex problem than timing a rotating element.

For standard screen types, the horizontal width of the screen is usually the larger value. This is an advantage as it keeps the line refresh rate lower. Another useful function is that, for a fixed bit rate feed, you can trade off vertical resolution for higher framerates. It'll usually be easier to vary the slow frame update mirror than the high speed (and probably resonant) line mirror. If you turn this on it's side, though, a variable width system is possible, which might be more desireable than a variable height design.

Of course, the above information does not include areas where the mirrors may be out of position or highly distorted. These will in effect reduce the maximum possible video bitrate of the system and necessitate both a synchronization method for the data flow and possible padding of the bitstream with dummy values during periods of distortion.

I'm currently planning to attempt a 1 bit 248x160 display at 10hz update rate as a proof of concept. This is approximately one thirtieth the maximum data rate of the dsPIC SPI architecture and will allow much fine tuning. This requires only a 5hz window update mirror and a 1600hz line update mirror, which can be built from a motor running at 8000rpm with a 12 sided mirror. This will not be head mounted initially. Due to the need for 4.9kbytes of RAM for a video buffer, I plan to use a larger dsPIC (8Kbytes, 20 MIPS) as the video driver. I also hope to use it's DSP functions to both ease code development and update control calculations, and possibly drive a simple vector video engine to greatly reduce the bitrate and calculations required by a master processor. But that's for later.

Four Month Update

Due to being unsettled (moving, bought a house), I've had to put my projects on hold for a bit. Well, I'm back now.

New tools: Mini metal lathe. I can now form my mechanical components and get back to being an ME! Plans include components for my other projects below, and probably experiment with tool design. I'd actually love to build a CNC mill eventually, but I'll need a manual mill and lathe first. Halfway there.

Project Updates:
I'm refining ideas for the RC core to the hardware I have. I've got a few 2.4GHz point to point 250K/s or 1Mb/s transcievers that are simpler to control and will provide me with a good starting point in RF design. I'm still planning on having everything connect together via CAN bus. However, some designs have become easier as Microchip is now selling/sampling full speed 3.3V parts and is coming out with a wider array of 16 bit chips shortly.

New Projects:
IMU2: while I do have some gyros sitting around, I've recently ran across a paper about using accelerometers as an IMU, Active Tremor Compensation in Handheld Instrument for Microsurgery. While I've known about the theory for a while, what impresses me is that they've seen increased accuracy over common triple axis accelerometer-triple gyro configurations. I have a pair of Freescale MMA7260Q triple axis dynamically scaleable accelerometers I'm planning on building an "IMU Stick" with as an experiment. This should end up being smaller and lighter than any other IMU design, possibly allowing RC aircraft autopilots to shrink in size.

Air Cannon Launched Sensor Packages: I've always wanted to do this one. A 25mm bore aluminum barrel about 18" (460mm) long is used to launch (via CO2 or air pressure) a sensor package. The initial package will be sensor equipped to track various pieces of flight data. Useful sensors that may be deployed are for both search and rescue and laser tag games. Parachute deployed motion trackers, vibration and sound sensors, etc. The critical components of the design will be a concentric ring that will use a transformer effect to provide data to the microcontroller in the sensor package in barrel, non-contact. This will allow (with additional hardware) to sight a target zone, and have the electronics tell the operator where to aim to hit that target. Through controlled pressure and temperature in the expansion tank (Especially for CO2), muzzle velocity of the sensor package can be controlled. Various ways of triggering the descent parachute at the right time will be tested (timer, airspeed through air pressure sensors, etc).

Laser Rangefinder: Always wanted to build one. I've found information and effective hardware for the transmitter and reciever sensors. I've found a 25 year old schematic from an old TI optoelectronics book for a phase-difference rangefinder. With modern electronics, I can probably make a nice Time of Flight rangefinder work. This might be ideal, especially since a near IR diode was found on Digikey that has a CW output of 120mW, well above the safe range.

Parts to Buy for: Juicebox

Just for general imagery, you can't beat an LCD. Now, I've been planning on using a 9 bit (512 color) Sony TFT LCD for my large HUD in the future, and general purpose LCD now. In the last few days the hackability of the Juicebox has come out to mass media. Most people are focusing on hacking it to provide mobile video players. I'd love to myself, but I've always been a DIY guy and I wanted a different approach. Hence, I look at what's available. 8 MB RAM in the version I have. the 22 pin PCB molex board may be nice for some of my own I/O work. The processor is useless as it's a bare chip encased in epoxy. Now, the screeen... 240x160 12 bit (4096 color) LCD. Might be the same molex connector as my Sony LCD. I got my Juicebox for $12.48, which is less than the Sony LCD. Other than refresh rate, this is looking to be perfect for my projects. It might even interface with the Epson LCD driver that I've spec'ed out for the Sony!

Also included in this is a 22 pin LCD Molex connector (the other 22 pin board goes to the expansion slot) that might also work with the Sony. My source for the LCD's sells those for $3 each.

Thought Experiment: HUD

I was thinking about how to build a low cost, lightweight helmet mounted heads up display. Mono color, vector graphics. See through.

I happen to have some specially cut but scratched HUD glass sitting around here. Not to useful due to the scratches, but a good thought provoker. One common way to get a HUD working is to have a well backlit LCD or CRT at right angles to the glass. Problem? Size, you have to accomodate the entire LCD, which may be 2.7" or even 3.8" in common sizes. You can get color raster graphics then, but that's more distracting that I want. I'll just slide an LCD with focusing optics over my eye if I need that type of display. Professional units appear to use very VERY small monocrome LCDs with a high output backlight to provide such detail. Unfortunately, 320x240 or more preferrably VGA monitors of this size are expensive. A broken modern DV camcorder may be a better cheaper option off of Ebay for oneshot designs.

I happened upon the old Nintendo Virtual Boy a while ago. It cycled a 224 light LED bar in conjunction with a mirror. This provided vector graphics (in stereo) at 324 x 224? at 50Hz. It was disorienting to use, but I figure something similar providing "infinite depth of field" guide lines for highlighting and information providing would be better, especially since you can see out of the unit. Problem? I'd want 240 LED's. That's a LOT of space I'd have to fill in. Another issue is the complex circuitry. I'd need a high pinout FPGA to drive the LED's. I'd probably use a rotating octal mirror to provide scan lines instead of a vibrating mirror. This also gives the option of overlaying and syncing multiple color bars to provide RGB color graphics as cost permits.

I briefly considered a single LED with driven X-Y galvatrons (ala laser lightshow graphics) but those are highly limited in their flexibility and cost a bit. Also that would put vibration sensitive mechanisms on a mobile platform. I much prefer the spinning mirror of above since that only has to maintain speed and have an optical encoder onboard to provide timing characteristics.

Anyone else have any ideas? I'm looking for lightweight, low cost solutions. Camcorder eyepieces are a good option, but many of the older models I'd sacrifice use miniature CRT tubes. I do NOT want several kvolts on my head. Ebay Camcorder finding is very hit and miss, especially since I'd need two identical digital units to build each eye of the HMD.

CAN Module status update

Working on learning Eagle still to get the Zigbee-CAN module designed. Currently breadboarding a 4 DOF (2 accel, 2 gyro) IMU for camera stabilization and head tracking. I'll probably also throw in a CAN-USB adapter, too, so I can build a CAN network debugger/programmer for all my toys.

Found a few nice things over at the Electronic Goldmine website. They reminded me that I have a 2.7" diagonal Sony LCD (240x160, 512 color) that would make a good forray into HMD/monocle design for very little, if I can design a good driver for it (I see dsPICs in my future). Other than a 9 bit interface, it'd be a bit hard to control without 38400x9bit memory... so I think driving this with dual port RAM and a CPLD front end might be the best bet for me. We will see.

They also have a 16 grayscale 320x240 touchscreen that would be a good match for a forearm mounted control system.

CANMOD - A CANbus module system

Well, after some deliberation, I've gotten a bit of a grasp on the basic boards needed for my designs. All boards have a CAN interface:

• Zigbee and digital I/O
• Generic I/O with breakouts for specific interfaces (parrallel, UART, SPI, R/C?, Analog input)
• Brushed motor and R/C servos
• Brushless motor
• Audio I/O
• Video Input/analysis
• Video output/LCD
• High computation module (if needed)

Now, serial bus connections will be available for the basics. Some will just be a single digital connection. Many will be on several inches of dongle bundle so they may be separated from the controllers.

• I/R input
• I/R output
• IRDA transciever (UART)
• Flash config module (I2C)
• Button/slider input
• Single event touch sensors
• Accelerometer 3 axis?

These should allow me to build anything from small to midsize robots to high performance R/C vehicles (still need more range for aircraft, though) to Laser Tag systems

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:

• DSP voice command
• compressed digital voice communication
• GPS/IMU position tracking
• 900MHz long range datalink
• Camera tracking and targetting (shoulder mounted)

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...

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....

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.

Random electronics

Time flies when things go wrong. However, on a few good notes...

FPGA's
I've pretty much settled on trying to get Actel's ProASIC-3E starter board. List price for the lighter weight version is $250 (due in quantities 2Q 2005). What I do like about it is that it includes a Libero GOLD license, which is all I really want. That's worth twice the dev kit costs. They're highly rad tollerant, so good if I ever decide to send up high altitude balloon sensors. Just no dedicated hardware DSP features (Multipliers, MACs, etc). Still might be cheaper to implement myself given how cheap the chips supposedly are.

Now, second on the list is Lattice Semiconductor. Similar issues, but I like their low cost LatticeECP for DSP route (same or better hardware as the big Stratix and Virtex parts from the top vendors). IF I decide I need DSP that badly, I might chase them down. Too bad their expensive dev kit hardware and 6 month free trial don't really cut it for me. I don't want to drop 2K on something that I might use a handful of chips my entire hobby career. I hate it when my software expenses outweigh my hardware. I'll probably end up turning back to Xilinx's Spartan3 or Altera CycloneII eventually, given better "free" software (both support, licensing, and specialized IP availability) for complex hardware support (video DSP, etc). It's a balancing act.

Circuit Cellar Contest
Well, I got my Renesas contest hardware from CC. 32 bit CISC microcontroller with a CAN port. Should prove fun if I need higher hardware speeds for my work (probably only if I start doing on the fly IK calculations for robotics right now). Although samples are still available, the starter kit I got isn't.

Datalink
So, thinking about my upcoming vehicles has me plotting out datalinks. While my Nordic based RF-24G transcievers are good for burst (1Mb/s) low power communications, they're going to drop off after a 100 feet or so, even out in the open. Something new has come to my attention, though. The dev kits for Aerocomm are readily available online at Mouser. 900MHz and 80Kb/s isn't too bad, with decent range. Higher transmission speeds usually demands higher frequencies (due to channel limits imposed by the FCC), more power to get to the same range, and more complex hardware (both electrically and mechanically if it needs a steered antenna). I'd love to get a more complex DSSS system to reduce interference, but that takes more power and more importantly money. We'll see where I go from here.

Another option is finish getting my Ham license and go into the 10GHz range. 900MHz omni for commands, 10GHz transciever for 10Mbit data transfer. Might be fun. I'd rather build a radar around the 10GHz gunnplexer, though. Maybe with an FPGA rear end a dual mode unit would be feasible.

Polar Sight

I've been thinking about vision systems, and one idea popped into my mind. I know the intelligent weapons of the US army use this trick. Take a masked line CCD and spin it around a linear. By knowing the RPM and at least a single opto-trigger to track the RPM, an accurate polar image can be created. I've been thinking this could be interesting for vehicle guidance. Simply knowing the angle and the CCD that a "bright" target is lighting up, the position of an object could be detected. I might have to try this. Even with a single heat sensor, the ability of this design to easily zero in on a hot source could be interesting.

On a related note, how to do you control a spinning target? Especially if you don't have a stabe "zero reference"? One idea is to mount a microcontroller and a solid state gyro on a motorized plate. Spin the plate to correct for gross spin, and use the gyro for direction control and minor spin stabilization.

RC Core - CANoPIC and related

Well, I've got a few PIC's on order now. Some giant, some fast, some with USB. So, after I get back to the RC core and get all but the CANoPIC interface hammered out, my next step is to take an 18F2550 (or maybe the 4550, depends on how many I/O I want in the end), attach an SPI EEPROM and an SPI CAN Bus unit, and build a USB-CAN bridge/sniffer for developing and debugging my CANbus designs. Actually, I should probably look into SRAM just so I don't wear an EEPROM out. It's not like I'm searching for power-off persistant memory.

Of course, this means I need or order my ICD2 and hot air rework station soon.

Side note:
I've spent too much time plotting on the Silly scope, I need to get back to realistic projects that I can see real output from. Anyway, to build and debug the silly scope, I need an oscilloscope first. Let alone I don't think I'll be able to have a snowball's chance in hell of building it with double sided, or even a 4 layer board, especially if I throw on the DDR SDRAM DIMM slot. I'll attack it again later with concerns over external memory after I get a few surface mount PCB's designed and built. My ideas have taken it beyond a basic digital storage mixed signal scope to something that could be used for DSP, wireless base stations, radar, who knows. Just too much for someone who's still learning the basics and getting his feet under him.

Silly Scope - Returneth of the integrated card and DSP notes

So, I've been looking at the timing requirements for DDR SDRAM. Given the nature of the 100+MHz frequency domains, I'm starting to think a tiered structure with connecting pins just isn't going to work. So, back to a single card with DDR SDRAM, an FPGA, and the analog conversion equipment I'm working with. Oh well. I was hoping to avoid having to redesign my board to switch ADC and DAC hardware. The DDR I've considered building onto the card from the beginning simply because of the strict timing requirements.

Now, a longer term idea (for the heck of it) is ordering enough samples from Analog to put together a full wireless transciever interface. Just a thought, they do have parts for the whole datapath.

Now, for my NEXT trick...

Analog has a few good references online, for free, for DSP.

The Scientist & Engineer's Guide to Digital Signal Processing


Mixed Signal and DSP Design Techniques


They might be a bit Analog specific, but they're general enough and deep enough to get people going. The first one's over 650 pages printed, and I haven't looked at the second yet.

Silly Scope - Evolution to DataStack

This isn't a true evolution per se, but an extension I've been thinking about. I always wanted to loft some good hardware in my rockets, and the stack makes it strong enough and dense enough to do in a small-ish rocket.

A circular format of the boards will let us fit a bit more on them for the same hole spacing. I'm thinking of moving away from the four quadrant design to a two half design. Two digital power rails, two analog power rails, two pin grids. This will result in the need to control what uses what datalines to have more than 2 boards attached. A new addition will be a JTAG rail. This, when combined with a DIP or jumper on each board, will allow a single JTAG cable to program the entire stack. Going with 2 hookups leaves more space and "stack access" on each side for airflow or other situations (like access to a CF card slot).

Now, for the addon boards. Barring low latency parts like a SRAM/SDRAM board, all other boards will have a CPLD onboard. Probably a Coolrunner II. They can interface 1.5V to 3.3V and act like logic shifters, and also implement high speed interfaces (simplifying the databus to a single voltage requirement). I still plan to hook up only half the bus to the CPLD to keep two independent busses. A CPLD on each board will simplify reconfiguration for different stack designs. This does raise the cost a bit, though. The flexibility and I/O standardization is worth it, though. It also lets those do PCI or similar bus standards for those who want a true databus as opposed to my partitioned databus. Only other problem is that to get enough pins, the CPLD may have the same packaging as the FPGA!

Silly Scope - Research Break and future ideas

I've spent too much time on this already, especially since it's still out there in "pipe dream" territory.

Anyway, for future reference, I've decided to go with the Xilinx Spartan 3-400. Big enough for most applications, it's also the largest QFP format chip, so a user doesn't need either an IR oven or a hot air rework station (I want to buy/build both), so others can work this design.

It's fully supported, development hardware is available for low cost (Digilent-400 version of the starter board), and hopefully the free simulator will run it.

And hopefully I can run it off of batteries. One current idea is to build a tiered design (similar to PC/104). Fixed size (square, circuilar is considered for sealed tube applications). Radially symmetrical, it'll have 4 digital voltage busses (GND, 1.8V, 2.5V, 3.3V, 5V), 4 analog ground busses (AGND, 5V Regulated, Unregulated). There will also be each bank brought out to a databus. Only those components that need access to all the databusses (like the FPGA) will be connected to all of them. All other boards will have passthroughs for the signals, and be connected to only one databus. If multiple FPGA's need to be mounted, a spacer board that passes only one bus through (and all power lines) will be required. Turning any board will just put the sensor on a different bus without any major bus arbitration (important for high speed apps like 200MSPS ADC's). This means that for "generic" boards, the most that can be used are 4, one per bus block. Custom boards may be able to use a CPLD and a jumper to split the busses into inside and outside, or left and right, etc. to at least double the possible board count.

As soon as I remember my FTP passwords, I'll upload a GIF to illustrate, and a possible board "stack" idea (Digital camera control and DSP or a radar stack).

Anyway, this is going on hold. I'd love to spend the $100-$200 and get everything I want, but my R/C core is waiting.

(Edit!)

Basic board layout


Generic ADC sensor stack

Silly Scope - Digilent to the rescue!

So, I wander around thinking of how best to start prototyping my FPGA based silly scope. As much as I'd like to start designing my FPGA based super O-scope card PCB, I know I should build a breadboarded design. Well, a while ago when the Spartan3 was first released, I looked at the official Xilinx Spartan3 starter kit. From there I wandered to Digilent, the maker of the board and lots of add on boards for the hobbyist/student. My only disappointment was that it came with a 200K gate chip.

Well, I did a search. They now offer the same board with a 400K chip for $119 vs $99. Perfect.

Add in all their expansion boards (Wire wrap boards all the way up to 1MSPS D/A and A/D board), and you can probably get away with anything. I'm interested in the AD/DA board and their DIO5 computer addon board.

For a more compact version of that, and cheaper, Nuhorizons has their Spartan3 Development Board. A little cheaper, too.

Now, for the more extensive design work, I've looked at two different boards. One is made by AVnet. It's got a 1.5M gate FPGA on a PCI card. Nice, and it allows for a user to design direct access to the PCI bus in, bypassing any other work and allowing data to be dumped into main memory directly, greatly increasing capture bandwidth.

Another option is another Nuhorizons board, $450 for a 2M gate board designed for very high speed DSP. Fast, huge amount of space in the FPGA fabric, has ready made cards for A/D (135MSPS at 14 bit works for me, still looking for the price). I'd love to get one. I'll hold on, though, we'll see what my FPGA musings bring first. I sure don't plan to spend any money on software anytime soon for this hobby. It's got dual Ethernet, CAN, low speed A/D and D/A (audio speed), LCD panel support. Hmmm... it's just about perfect for a central processor for my large exoskeleton/robotics project. Must contemplate...

Silly Scope - Programmable Logic

Been researching a few of the FPGA's out there. Actel, Lattice, Altera, Xilinx. Mostly Xilinx. I know people who swear by Altera, but Xilinx has be most flexible free tools, and supports their entire low cost Spartan3 (to 4million gates and embedded multipliers!) line in their free software. Yeah, I'm not going above a surface mount design (400k gate model), but it's nice to know.

Yes, I am reading through the entire 192 page reference doc on the FPGA, and learning a lot.

R/C Core - Transcievers

I'm no RF guru. On the contrary, I'm a baby. Hence, I need a little... "help". I'm using a transciever based on the Nordic 2.4GHz chipset...

2.4GHz
http://www.nvlsi.no/index.cfm?obj=product&act=display&pro=64 ($5.40)
433/868/915MHz version
http://www.nvlsi.no/index.cfm?obj=product&act=display&pro=83 ($7.00)

These are available at http://www.sparkfun.com/ (along with lots of other very useful items). I bought some 3rd party 2.4GHz transciever boards from them for $20, which is plenty to get me going. I plan to eventually use both of these in my designs, and throw on power boosters for greater range with my own PCB's.

Until that time, I'm doing good as it stands. I considered Zigbee, such as those chips available from Chipcon, but they're a bit expensive at $9/chip and need external parts. However, they are true Zigbee parts and have integrated 128 bit encryption, which is intiguing. Still, I'll hold off on that. I'm not trying for a secure network, and I doubt I'll be hacked running my R/C car around since it's not 802.11b (great speed, range, oh dear look at that power drain...)

Silly Scope - Add On Board Layout prelim thoughts

So, my oscilloscope design's going to have a data/power backplane, one power supply board and I/O board (maybe the same board), and multiple data capture boards. I'm plannng on a VM state machine that's hopefully compatible with Bitscope (or at least ASCII streaming so I can capture the data to Matlab).

Mid level cards will be built similar to the Bitscope. A PIC for communication with the databus (and identifying itself, housekeeping, etc), a CPLD doing the ADC interfacing and data dumping to the capture SRAM. Also logic analyzer (again, Bitscope compatible PODs perhaps). I MAY base the databus on standard 3.3V PCI, which many CPLDs can be used as the data bus conversion, or maybe ISA (ditto).

High level cards will be a beefier version. PIC or maybe dsPIC for the housekeeping, CPLD for bus buffering, Xilinx Spartan3 (or maybe the Cyclone II from Altera) for a strong but inexpensive system. It's gotta be able to keep up with 100-200MSPS at 8-14 bit from 1 or 2 ADC's (not certain yet). I'm avoiding large ball grid/pin grids as you really need multilayer for that, limiting me to the PQFP-208's package, so the largest Spartan3 I can use is the 400,000 gate version. That gives us over 256k of buffer RAM onboard, which is as deep as the Midline Bitscope-310.

Now, the Spartan can do DDR RAM speeds, and a max speed of 326MHz, which should be fast enough to get the data out. There are DDR controllers out there. However, DDR DIMM's are 168 pins, which would devour ALL my I/O (141?). So, custom memory boards and individual chips are required. Easy enough, Hot air rework station and cheap DDR-333 DIMMs give me the RAM I need.

So, what's the backplane providing? I'm thinking:

• 16-32 bit bidirectional data path.
• Card Select
• Digital Ground
• Analog Ground
• Digital Power (5V)
• Analog Power (24V?)
• Capture Trigger Start (single signal)
• Capture Sync Line (continuous capture sync)

The card's will have to attenuate their power supplies down via linear regulators to what's required for the boards themselves. Although this wastes power, it'll provide a cleaner connection, reducing interference from adjacent lines. The analog power is designed to be attenuated down, as it is very susceptible to digital noise.

Now, back to looking through the Spartan3 spec PDF...

Digital Silly Scope - Analog research

Well, I've been looking at Analog to Digital Converters for my Oscilloscope project (freshest on my mind). Ran across 3 candidates:

TI ADS5500, 125 MSPS 14 bit ADC

National Semiconductor ADC 08200, 200MSPS 8 bit ADC

Analog Devices AD9430, 170MSPS 12 Bit ADC

All three are great, having examples on how to hook up the parts with high bandwidth op amps (their own of course) for stable operation and signal conditioning. Now, since I plan on having multiple boards for the Silly Scope, both are viable for their unique benefits. I'll probably start with the National ADC because it's a simpler package and more extensive notes (barring schematics for demo boards from Analog). However, I don't want the expense of a 4 plane board (when I get there), so maybe I can bend the rules for a 2 plane design? We'll see.

Speaking of analog, I realize more and more I need to hit my analog design books and hammer out more understanding of R/F and analog in general. Digital design frankly is easy (except FPGA optimization), everything always hangs on the real world analog design.

Since this is a VERY low cost operation for me, I can obviously get free samples of all of the above :) Some of the devices are very expensive(Analog, $88), some are fairly cheap (TI, $4), so production would affect these, but I'm looking for speed and resolution for my oscilloscope.

I know I really should buy an oscilloscope before trying to build one...

Anyone have good sources (web and textbook) on RF(airwaves and high speed PCB) design? (Yes, I expect to be told 4+ layers are REQUIRED).

Too many ideas, too little time...

So, I've started a little corner of the internet for posting my ideas. I'm not going to rant and rave about life, the world, or otherwise, but interesting projects I've run across online, useful websites, and ideas bouncing around my head. So, why Technical Alchemy?

(no, this is not LEGO related)

I went to college to be a mechanical engineer. I don't do that right now at work (still want to). However, I have an interest in learning, so I'm dabbling in ideas ranging through electronics and computer science. It's an easier pasttime than trying to get a machine shop into my apartment. However, I have only basic electricl/electronic knowledge, and a little programming skill, so it might as well be alchemy at this point. Situations like that tend to change very fast for me, though.

That machine shop will come when I get a house, then I'll start tackling plastics and composites.

So, for the moment, here's the current list of hopeful projects and some notes on them.

• 2.4GHz R/C basic control system (BCS) - Currently on my breadboard as I'm slowly working on the PIC code to implement this. The 2.4GHz transcievers are currently prepackaged, so no RF design headaches.
  
• Intertial Measurement Unit (IMU) - Haven't bought a GPS yet, it'll be part of an upgrade to the R/C BCS. Also haven't started on the codework.
  
• CANoPIC - CAN over PIC. Bascially a series of modules (which the R/C BCS will be one) that allow me to implement CAN based networking of a given common R/C function, such as a dedicated brushless motor controller. This is for my own ease of work and an experiment to reduce the interference common with R/C designs. More on the modules later.
• UGV - The UGV will be built as a custom vehicle body with a modular arm for poking cameras into crevases. It'll be the testbed for the R/C BCS. I could buy an R/C car for this, but where's the fun in that? Although that might happen later when the system needs to be more rugged.
  
• UAV - There's a whole bunch of ideas floating around here. Although all of them depend on the IMU for guidance and to tell the airplane where to circle, the plane itself is up for grabs. Standard fixed wing powered-glider, rocket boosted glider, and scissor wing rocket booster (I like this design on principle) are all possibilities, in increasing order of difficulty.
• VTOL - Electric or gas powered VTOL. Maybe similar in design to an Osprey, but I know to get ANY performance out of it, I'd need to keep the weight down, so no UAV stuff. I'd still need the IMU onboard as I'd like to make it computer controlled and docile (the IMU could react faster than I could). However, I'd definitely need access to a machine shop for this one. No one makes the variable pitch blade hubs I'd need and the chopper ones don't have enough pitch.
  
• Pan-Tilt-Zoom Camera - There's probably going to be 2 phases to this. First one will use a micro NTSC camera I have laying about. Second version would use a Panasonic Lumix DMC-FZ3 (3Mpixel, 12x optical, optically stabilized, about a pound for weight) that would be hacked apart and the controls attached to a microcontroller. In either case, the NTSC video out would be hooked into a frame grabber and hopefully something similar to the CMUCam (automated tracking of a target especially) could be worked out. The FZ3 would give the design a zoom lens, image stabilization, and a 3Mpixel photo capacity. I'd also like to hotwire the photo capacity to allow me to transmit the pictures back across the datalink without needing to land, but first things first.
• The Silly Scope - a modular oscilloscope. It'd have a power and computer access board plugged into a backplane. The remaining backplane slots could be logic analyzers, high speed ADCs, and the like. Power and databus back to the master (USB probably) controller would be provided along the backplane, as would be a sync/trigger line for simultaneous capture operations. I'd like to make it Bitscope compatible and open hardware.
  
• Phased Array Radar - I'd love to make a small radar for the UAV. Now, this is far beyond my ken right now (RF is still black magic to me). However, the Silly scope modules would be a good first start. One of the possibilities is a module running a PIC for control, having an Xilinx Spartan3 for onboard DSP and datacapture, and dual 200MS/s AD converters. Oh, and some very fast memory. My primary use is for ranging, although I'd love to be able to do synthetic apeture tricks with it. I'll probably start with a sonar system as it requires far less speed and cost, but doesn't have the effective range for use as a radar altimeter, for instance.
  
• Walking Robot - Very similar to the Robo-ONE designs, and therefore very expensive (30 R/C servos x $80 for high power digital ones? I think not). Maybe later, though.
• Exoskeleton - Definitely on hold till I have a garage. I'm not aiming for much strength. I was actually thinking of building a costume around it (therefore light weight) and just worrying about that weight. The control "suit" and the frame itself are to be separate, both for ease of application (may not be comfy, though) and so that the frame can be tested without risking life and limb of the tester. Seven feet of tubular bars, heavy batteries, pneumatics, and car window motors (cost!) is just too much for an apartment. The motion capture suit, however, can be built. Could be fed into a computer for animation purposes (for my brother).
  
• Digital Dustbunnies - Similar to Smart Dust, just my own needs, right now, not in the future. Small PICs with a few sensors and a 2.4GHz transciever get scattered about randomly from a UAV air drop of an air cannon "shot load". Heat/sound/motion/sesmic sensors allow for rapid scanning for anything alive in the area. Although good for Search and Rescue purposes, I'm far too cheap to allow them to just be thrown away right now, even for a good purpose. I'd have to go and pick them up.
• Aircannon - One of my original ideas from a long time ago. It'd be more like an air mortar. Short, wide barrel, high angle. It would have used smart ammo that would have communicated with the launcher via a 125KHz carrier (RFID tech) to specify what type of round it is. The ammo would be loaded either in a belt fed system or a revolver type magazine and would have been breech loaded. Very much fully automated. Primary loads would have been the Digital Dustbunnies, paintball cluster rounds, Brilliant Paintball Rounds (think parachute deployed self targetting single shot paintball round), the original UAV idea (Fast to high altitude, parafoil wing deployment), and a few more I can't remember right now. This one requires a farm away from the city to actually not be arrested, and who knows if even that is safe these days. Oh, hi Mr. Homeland Security Officer...

Ok, that's it for now, off I go. Wonder if I missed any?