The site is built for easy load balancing and scalability. Currently split into 4 servers (Front End Web, SQL, Media Storage and Web Server, and Worker (Video Encoding, DB Writes, Image scaling and branding).

This is typically how I keep up to date with latest tech. Rather than spending time going over books, I build these projects utilizing the actual technologies. I still spend a lot of time reading documentation but I find this a lot more fun and engaging.

I should note that I’m not a web designer. Hence the minimalistic approach to the site design. I can develop anything in code but it’ll just not look very good.

I’ve spent at least 3 days converting my Amp Delay Service from Serial communication to Raw HID communication protocol. My CarPC was using at one point 5 COM ports for the various devices connected to it. Iw was becoming a real pain keeping track of each COM port and the actual device that it represents. So I decided to convert my devices to plain USB devices rather than Serial.

Everything was going great until I tried sending data to Teensy while converting the Amp Delay box. The Amp Delay service needs to ping the Teensy device but for some reason (which is still unknown to me) sending data to the Emulated Serial device doesn’t work.

I’ve tried a handful of 3rd party USB libraries, tried rolling my own, tried synchronous vs overlapped IO. Nothing worked. I just could not send data to the device.

After hours of Googling, I finally stumbled on a solution. Turns out that when Teensy operates in Raw HID mode it presents itself to the PC as two devices:

The “Serial” object in Arduino can send data to the Emulated Serial device which is the method I used to send the Gauge Pod Sender data to the PC. There seems to be a problem however sending data from the host to the device over this protocol.

The correct solution was:

1. Connect to the RAW HID Device instead.
2. Use RawHID.send and RawHID.read in Arduino code to communicate with the host.

I completely accidentally stumbled upon the RawHID object. It is not documented ANYWHERE. The difference is that Serial.print sends data to the Emulated Serial device and RawHID.send sends it to the RAW HID device.

holds the VendorID and ProductID that can be changed. When the sketch is uploaded to the device the values are changed on it. This makes it easy to distinguish multiple Teensy devices on the same PC. By changing the Product ID I can have the Amp Delay box and the Gauge Pod sender uniquely identified and don’t have to worry about the program connecting to the wrong box.

Been busy coding away on the Gauge Pod software. It’s coming along nicely. I’ve taken a slightly different approach from the first version and the code is turning out to be a lot simpler. Still using layered architecture to separate Sensors, Gauges, Communication and UI but I changed how the layers interact with each other. The update performance has gone up dramatically. Using the Gauge Pod Sender in USB mode has also greatly reduced overhead and feeds data incredibly fast.

I’m currently in the testing phase of the software but looking good so far. The gauges are VERY stable compared to the last version. Will start testing the software on the car in the next few weeks as time permits. Can’t wait to try this in the car.

I’ve spent about 2 days on dealing with the ADC (Analog to Digital Converter) of the Arduino platform. Turns out there’s more problems to overcome when dealing with taking analog signal from a sensor and converting it to meaningful digital reading.

The issue is that even with a constant input voltage the ADC reading sampling error rate is larger than I’d like (~1.2%) with some random spikes in excess of 3%.

I built a test rig to troubleshoot the issue. Using constant input voltage and a potentiometer to simulate the analog input from a sensor.

Things I found:
– Arduino Atmel chip uses a single ADC and multiplexes the input pins.
– Switching read pin on the ADC causes noise in the system. Solution to read the first value and totally discard it. Then wait at least 10ms before sampling actual data.
– Sample accuracy is inversely proportional to the delay between samples. Shorter delay between reads, less drift. But over a static period of time, the error rate is the same.
– ADC is quite sensitive to electronic noise. Adjacent pins seem to affect reading.

This is probably as close as I can get to get an accurate reading that doesn’t jump around too much. Filters most noise while giving a decent sample rate. Currently reading all 4 inputs. Technically could reduce to 3 inputs since 4th won’t be used for a while. Will see how well Gauge Pod software deals with current feed rate.

I’ve been spending a lot of time lately thinking about how to best redo my GaugePod program for my Carputer project.

Existing Problems (and potential solutions):

Program sometimes crashes on resume from hibernate.
Need to determine what causes this. This started when upgraded from Atom to I3 Motherboard/CPU. Perhaps Mobo not sending proper signal to Windows?

Current Arduino implementation isn’t very accurate.
This one is major. Had to fudge the voltage numbers to get semi-accurate reading. This needs a rewrite. Right now the Arduino box simply sends the raw value from the ADC (0 to 1023) as input into GaugePod. Perhaps a better solution would be to have the Arduino send the actual voltage. In fact, I could monitor the reference voltage to make sure it doesn’t drop below 5V. Arduino could detect any drop in reference voltage and adjust reading before sending to the Carputer. Could even add an LED to indicate a condition where reference voltage is not 5V, though it wouldn’t know if input voltage is >5V. Though that is highly unlikely as the reference voltage is coming from a 5V voltage regulator.

Change how GaugePod stores settings locally.
Right now the settings are stored in a DataSet that’s stored in the user profile. Can’t migrate settings or even hand edit. Need the ability to import/export settings. Switch to XML Format. Will have to write a custom library to deal with this. Won’t be difficult. Already did this kind of implementation in the UltraDMM project.

The Arduino box is too big and wiring too complex.
Need to simplify wiring, switch to Teensy for smaller footprint. Perhaps add chokes to eliminate electronics noise. Rev 2.0 of the Arduino box uses Molex connectors for the sensors.
Better to use barrel connectors. Need 3 Pins.
1 – 5V Input
2 – Ground
3 – Sensor Return
Something like this would work:
Additional advantage of using round connectors. Easy enough to drill holes for them rather then cut square holes for the Molex connectors. The enclosure would be nicer looking. The screw-in connectors would deal better with vibration in the car.

Program runs in foreground, blocks access to Centrifuse
Possible solution to implement as plugin for Centrifuse. Though it might be possible to simply run the program inside a Centrafuse window. I vaguely remember reading that this can be done. Drawback of this approach is reduced screen real-estate.

Installing ffmpeg under CentOS with all the plugins enabled is no easy task apparently. The only way to get it working properly is to build it from scratch. This process was compiled from lists and forums on the internet

Add DAG Repo to your Yum Repo list if it’s not already added. Run Update to make sure everything is in sync.