J. Mike Rollins (Sparky) [rollins@wfu.edu]
  CISSP, GIAC GPEN
Hyperbola New
My Cats New
Kitty New
Mike is on
  LinkedIn
  FaceBook
BackYardGreen.Net
HappyPiDay.com
Green Cycle Design Group
CamoTruck.Net
  Resume  
  My Stuff  
  Art  
  My Truck  
  People  
Electronics
   AC Inverter
   Taz (My EV)
      On/Off
      Tachometer
      RPM Sensor
      Data Meter
         Overview
         Construction
         Downloads
         Future Improvements
   Ethernet
   PIC Switch
   LM3524 Motor Control
   Microcontroller
   PWM and MOSFET
   SMP with 317
   Power Supply
   Function Gen
   Simulator: Zener
   Charge Controller
   IR Audio
   PWM with 555
   Solar
   Entertainment Center
   BLDC
   GPS & WD-C2401P
Jacob's Ladder
Scripts
Math
Notes
My House
My Cars
My Cats New
My Jokes
Pi Poetry
pumpkin
Toro Mower
Development
Speed of a Piston
Not a Pipe
Linux
















Future Improvements

Jun 24, 2010

Future Improvements

I am researching the following potential hardware improvements.
  • Precision op amps ( TI, Linear )
  • Filter? I'm wondering whether I need any kind of filter on the op amp.
  • Fast analog to digital converters ( TI, Microchip )
  • Fast external, nonvolatile memory. (I haven't found many viable alternatives to the SD Memory Card. I believe my current card is one of the slower cards. I tested one fast card, but had very inconsistent results. Here is some info on the speed of SD Cards.)
  • Faster SD Card (Ultra II)
  • SD Sockets (example)
  • Headers: I'll probably make the DC-DC a reusable module that connects to the circuit with a header. This will make it reusable in other application that need a DC-DC converter. ( Molex: M and F, 90 ) ( 4 pin F (sp .1") and 4 pin M 90 (sp .1") ) ( more + + + )
  • SPI Bus (SN74ALS240AN) >
The average sample rate is about 4.4 kHz. This rate could be about 50% faster except that it takes a significant amount of time to write the data to the SD Card. The graph here illustrates the effect of the write time.

I've explored ways to work around this issue. I cannot safely compensate for this without double-buffering. But, there is not enough usable RAM on the PIC18F4550 chip to do this.

click to enlarge/reduce
I am contemplating a few methods to implement double-buffering. One method will have the measuring performed on one PIC with lots of RAM. The data will be buffered in one of many buffers. When the buffer is full, a concurrent task will send the data to another PIC chip. This chip will interface with the SD card. A challenge with this is to interface the two PICs. I would probably use SPI.

A second idea uses Ethernet instead of USB. I would use a PIC18F4620 and an ENC28J60. I could connect many devices to a wireless access point located in the vehicle. I would download the data using wireless Ethernet from inside my house. The double-buffering could be implemented in the same manner as the above idea, or it is possible that I could perform the operation on the same PIC chip since it has more memory. Additionally, the Ethernet could be used for communication between multiple devices.