D-DAQ

There have been numerous parts of D-DAQ that I've had to theorize in order for things to function as I desire. First order of business was figuring out the baseline hardware I'd need. I couldn't find any MCUs that had multiple parallel interfaces and it's be very costly in board space to implement 3 of them. Serial was next on the list and SPI was the best contender out of what was available due to its sheer speed. Since I was simplifying the workload and dedicating 1 SPI channel to each display, I didn't have a need to use the CS lines and I could tie the pin to ground plus there is no MISO pin on the SEPS525, thus I only need the CLK and MOSI lines from the PIC32MX.

As there are a few different configurations that the user would probably want to alter, I need some way for the user to interact with D-DAQ. The bare minimum number of buttons needed for a UI is 3, imho. Now, though the display has no use for the MISO line, it will stay active on the PIC32MX so I might as well use it for one of the buttons. I also need a few LEDs for accent lighting as I know part of the community this idea originates has a particular interest in indigo and I'm sure there are others as well. A set of visual warnings is needed for each display as well in case a parameter is exceed; tack on one control line. Also, a lot of driving occurs as night so tack on another control line for brightness adjustment of the accent and warning lights, of which will be PWM based. Cannot forget about power, both 3.3 V and 14 V for the display. Though I could do on-board 14 V generation for each display, or I could use 1 regulator on the main board and send it to each display. The latter of which I've chosen to do. Now when you sum this all up, there are 9 lines I need to run to each display. Ironically, this is just as cumbersome as a parallel interface, though only 2 lines are dedicated for data transmission.

I quickly figured out I needed to find a highly dense connector with 9 conductors or more. A custom solution was out of the question due to cost an proprietary nature. Though a 5x2 pin header could work, it'd take up more space than desirable; plus the cable wouldn't be shielded and a greater immunity to noise is is desired. With the introduction of a newer generation of Mac Minis, I became aware of the Mini DisplayPort connector. It's 7.4x4.5 mm which makes it nice and compact, which is a little larger than 2 MicroUSB terminals stacked on top of each other but with more than 2x the pin count. Long story short, it turns out that mDP to mDP cables are actually apart of the DisplayPort standard. Each cable has 20 conductors, 6 of which are dedicated grounds and are attached to shielding different parts of the cable. The next option was Mini HDMI, but the standard calls for royalties... Decent quality mDP cables can be had for less than $5 each. Receptacles are $3-$4 each, which is a little high, but worth the cost. Due to the newer interface name, Thunderbolt, several mDP receptacles are being phased out and replaced by Thunderbolt ones. The only difference is a standardized pin out which happily means no change to the plug.

Now, 3 displays. Each 160x128 pixels with up to 18-bits-per-pixel, though I'll only be running at 16-bpp. In order to not redraw an entire display, its simplest to only draw what has been changed. I'd need to compare what is already on the display and what will next be on the display in order to do this. On the PIC32MX795 and PIC32MX695 I have 128 KB of RAM. Ohhhh that much makes me all tingly :). Though to hold a copy of each display in RAM, I'd need 120 KB. Oops. Now I can avoid this by adding a whole bunch of complicated code and always having to draw out each display in it's current state and future state and then compare them, but I'm not fond of that type of inefficiency so I figured I'd have to store a copy of each display somewhere. Microchip documents a Low-Cost Controllerless solution for graphics display using DMA and their parallel interface. It turns out, 128 KB is 1 Mbit, which is a fairly standard size for SRAM, of which I can use in place of a display in their LCC setup. According to the datasheet, it takes 5 clocks of the PBus to do a 16-bit read and 6 clocks to do a write with the PMP (Parallel Master Port) which is plenty fast enough for the buffer.

Here is the fun that I encountered just before I started screen shots to document the evolution of my schematic capture... When I found out that I'd need the PMP interface, I was a little dismayed due to the extra complexity of the board layout. I quickly found out that the PMP interfaced, albeit with or without multiplexing the data and address lines, knocked out 2 of the 4 SPI interfaces on the 64-pin TQFP package since they occupied the same pins. I would then have to move up to the significantly larger 100-pin TQFP or use one of the 2 non-leaded packages; the latter 2 of which are highly undesirable at this point in time. So, I have to make the 100-pin TQFP package in Eagle and start anew. 

Next up were my analog inputs. Having a dozen or more makes things a bit cumbersome so I wanted a compact, robust, and preferably shielded. After establishing that there is a need to use amplifiers for certain types of sensing and the fact that other various sensors need power, it was clear that I'd have to figure out how to provide power and input lines in a compact form. Fortunately most USB cables are shielded and the Micro USB Type B fits the bill nicely. I have 14 inputs, a few of which are utilized on-board, so this nicely divides up into pairs. I'm using the standard pins of 1 and 4 for power and ground and then utilizing D+ and D- for the analog inputs.

My last additions to D-DAQ were to provide some alternate checks and balancing of pressure inputs and assisting with logging. I've previously mentioned logging in other lab posts and some might wonder what this is. When a car's performance is modified it usually becomes a custom application because each engine is different. As such, the tuner needs to know how fuel, air, timing, and maybe a few other things are behaving. 

14 Analog inputs using Micro USB Type B

Numerous digital I/O pins for buttons

Two I2C busses for barometer and temperature, accelerometer, and separately a Micro SD card

All 4 Output Compare pins (PWM pins) - Together these will control the accent light brightness and warning lights

JTAG via a Micro USB port

ICSP pin

Optional CAN connectivity

If you've read up on my notes thus far, you'll know that I am half expecting the SEPS525 to perform at 10 MHz. However, most datasheets document the serial speed as 16.667 MHz. Based on that, I decided to try and run my SPI bus as close to this frequency as possible.

Side note. I love accurate time. 0.5 second accuracy is a personal minimum requirement when working with various elements of my computers. I'm a photographer as well so tenths of a second and faster mean a world of difference for me. It bugs when My atomic wrist watch doesn't sync each night as it likes to skip ahead ~1 second per day. Thanks to our wonderful benefactors here at HaD, a few select articles, and Dave Jones' two talks, I knew I had a bit to learn in order to pick out a suitable oscillator.

Why does this matter? D-DAQ has a logging function. By nature of this, I want accurate time. I had to determine stability vs cost. I settled on a spec of no greater than 10 ppm and a frequency as close to a power of 2 as I could get. I ended up settling on a MEMS oscillator, the ASVMB-16.384MHZ-XY-T, initially. I may switch over to the XTC7009, but, though its a snippet, I don't want to have to add code to have it track time properly.

So, I have 2 options:

• High precision and lessor accuracy that requires manual correction
  
• High accuracy and poor precision requiring code to correct precision

About 10 months ago I started screen shot-ing my progress as a way to document what I've done. Here are those captures with a few notes

June 11th, 2013: Initial placement and move from 64-pin to 100-pin PIC32MX.

I know I do not follow proper procedure for drawing out a schematic, but I visualize things digitally, not with tactile means. My schematic capture also serves as initial placement for how devices would be arranged.

June 25th, 2013: When I established I would be working with 3, 160x128 displays at 16 bits per pixel, simplicity and math dictated that I needed an external frame buffer.

July 2nd, 2013: USB ports with LEDs for visual indication of cable being detected. Frame buffer adjusted for sanity.

July 5th, 2013: Additional I2C component spacing made and general cleanup as I learn Eagle

July 10th, 2013: USB Ports differentiated due to original need of a PWM controlled amplifier circuit. Solid state relays incorporated into the design.

August 6th, 2013: Discovered how to draw busses in Eagle, simplified traces and added additional USB ports. Research began on power subsystem.

August 21th, 2013: Initial draft of power subsystem implemented with 2 switching regulators. The thought process for this area will be discussed later. Added to schematic capture.

August 27th, 2013: JTAG added. 14V power added. Accelerometer added.

September 11th, 2013: I2C-to-SPI bridge and uSD card added. Digital POT added. 100 PSI sensor replaced with alternate with same range, accuracy, and resolution but 1/3rd the cost.

This project exists in my free time. I took a hiatus for a while

November 28th, 2013: EGT amplifier circuit added. 12V power + 5V power theoretically implemented. After experimentation I believe I created a dual stage, variable amplifier that uses the first stage as feedback to control and limit the gain in the 2nd stage. Removed additional USB ports and associated solid state relays. 

Amplifier circuit: https://www.circuitlab.com/circuit/pf72sz/2-stage-self-adj-gain-rtd-amplifier/

Holiday hiatus

February 25th, 2014: Updated to reflect errors in wiring and changes due to initial PCB layout work.

Work hiatus

April 18th, 2014: MEMS oscillator added for clock control, minor cleanup, and Octal latches updated to different logic family so it's speed matches the SRAM frame buffer. They have the same pinout and package footprint.

Following 9 months of research I became more aware of what I wanted and what hardware was available that I initially believed I could reasonably use to pull it off with:

Redraw rate of 60 Hz for one screen, 30 Hz for two. This is independent of screen refresh rate which is 75-150 Hz

Connection with OLED display over SPI

160x128 OLED display with a screen size of 1.8" or 1.56" w/ 65K colors displayed

Metric gauge faces for 1.5 bar, 2 bar, 3 bar, and 6 bar for diesel applications

Metric gage face for vacuum to 1.5 bar for petrol applications

Imperial gauge faces for 25 psi, 30 psi, 45 psi, and 85 psi for diesel applications

Imperial gage face for vacuum to 20 psi for petrol applications

PIC32MX695F512H MCU

100 psi, 0.25% error tolerance, absolute pressure sensors for Intake and Exhaust manifold pressures

10-bit A/D creates sensor resolution at ~0.8416 kPa or 0.1221 psi.

30 psi, 0.25% error tolerance, absolute pressure sensor for petrol IMP

Connectivity for K-type thermocouple for EGT readings

Electrical taps for stock IAT & MAP sensors of the 2.5 bar, 3 bar, and 4 bar variety.

User selectable colors for needle and gauge faces

Color choices for startup animation

2-board design. Primary board containing MCU & display hardware. Secondary board containing the breakout for sensor connectivity

Support for up to 7 sensor inputs such as: Boost, EMP, IAT, EGT, Oil Pressure, Oil Temperature, and Coolant Temperature

For top end model with logging capabilities, the requirement of a speed sensor via the bell housing of the transmissions will be in place

Logging will autonomously be initiated by user holding engine speed at 1500 (user adjustable) RPM for 2 seconds

Logging will cease when idle has been detected for 5 (user adjustable) seconds

Log files written in CSV format over USB or to microSD card to be downloaded later

Logging rate of all sensors at 10 samples per second, though adjustable from 1 sample/sec to 100 sample/sec.

When rapid acceleration has been detected via speed sensor or rapid increase of boost/emp, the all tick marks other than a whole number (Metric faces only) or those a multiple of 5 (Imperial faces only), will be faded to black in a manner that indicates a trail following the needle's sweep.

Ambient air pressure sensor with altimeter

Boost and EMP will be actual pressure greater than current air pressure. Ambient air pressure will be determined as a running average over the prior 60-65.5 seconds. Differencing can be disabled.

Artificial inertia added to needle movement.

Boost and EMP samples are taken 500/sec and averaged to across a running 32 ms buffer

Maximum EGT & Boost readout. Method of display has yet to be determined

Separate "Diagnostic" screen to display numeric & converted readout of the 7 data collecting and 2 relative sensors.

The following is from an email I wrote to two friends with my initial ideas back in August, 2011:

Designed over a 160 wide by 128 tall OLED display, slightly larger than what Doniol chose. This allows for a significantly larger face when using a 270˚ sweep

Gauge Faces:

1x270˚ sweep gauge face

Display 2 needles, one for Boost and one for EMP if desired (This is where I need your help, how high do EMPs get?)

2x135˚ sweep gauge faces, opposed in orientation, looking very similar to a full 270˚ sweep

User selectable display for each gauge. One EMP, one IMP, one vacuum (VNT actuator control), Mix and match 2 or 3 of those three on each face (if you don't understand I'll explain later)

Customizable between multiple color schemes

Pressure readings in PSI & Bar

Selectable boost ranges with max values at 15, 20, 25, 30, 35, and 40 PSI. For Bar readings, they are 2, 2.5, 3, 3.5, and 4 bar.

Optional EGT hookups via screw post terminations. K-Type probes only. $20 addition if this really is as simple as I'd like to think

Optional Vacuum sensor, to watch VNT actuator control. ~40-60 for the feature as the sensor is ~$20 and then I just need code

Optional taps to hook into existing MK IV IMP sensors for the old Doniol crowd. No charge, might not be a feature

Reprograming of Doniol's gauge with my software *if* I use his original controler.

Pressure Gauges will be constant self adjusting to current barometric pressure. Don't worry about mountain driving.