Double TV programs on the same screen?

Posted on September 15, 2011 by Hangas | Permalink 0

Manufacturers are moving into different approaches to deliver 3D content at home. The goal is simple; to deliver different images to the left and right eye, then out brain does the rest. 3D is after all stereo image.  In the past the stereo audio was simple to achieve. Just place one headphone in each ear or a speaker on each side of the room. With image the principle is the same.

Some vendors opted by “active glasses”. These are special electronic glasses that block the image to each eye, alternately, while the TV displays the right and left image in sync. Other vendors, like LG, took a simpler (and cheaper) approach. Polarization or passive 3D.

On passive 3D each line of pixels, alternately,  is polarized in a different angle, with about 90 degree difference between them. This is no big deal at all as LCD and LED displays are always polarized. Just rotate the lens of a polarized sun glasses in front of your TV to check what I’m talking about. The trick for 3D is to make a pair of glasses with a different angle on each lens.  This is the same technique used in 3D cinema, exactly!

Now, this is where I began having ideias.  Imagine for a second that you have two pairs of passive glasses, but one has two lenses with one angle and the other has two lenses with another angle with a 90º phase difference. What do you get? Right! One person sees only the left image and the other only sees the right image. Now imagine that the right and left image are two different TV programs and not two stereoscopic versions of the same image. One person watches one program and the other watches a completely different program. On the same TV set!!  You could be watching a football match, while the Mrs could be watching a soap while sitting next to each other on the living room couch!

Now you ask. How about the sound? Well, an obvious solution would be to use different headphones. But there is a more “advanced” technology that could be adopte by TV manufacturers. Directional, or polarized sound! Some time ago I watched a TED Talk about a guy that invented this concept. Watch this video to get a detailed explanation by its inventor.

 This would be a very good extended use of a 3D set. Its like having dual mono instead of a stereo image. I gave this example with passive 3D technology, but this can be done with any technology. Active, passive or parallax. But with passive 3D you can build an home made prototype easily and cheaply.

First you have to prepare the content. Just prepare a side-by-side video source with two different video sources. Also, instead of a stereo audio track, mix the corresponding two mono audio tracks into a stereo one.  Next you must build or change two 3D cinema glasses and place the two right lenses into one set and the two left lenses on the other. Now send the “3D” content to your passive 3D TV set, put the glasses for the “channel” you want to watch, plug some headphones and choose the corresponding audio channel by placing only one the the phones.

3D, Idea , ,

Packing the project

Posted on August 10, 2011 by Hangas | Permalink 0

This project is progressing slower then I expected, but every now and then I can find some time keep it going forward.

I have now a vary basic prototype that can query the ELM interface for some values and display it on the LCD.  For development purposes I’m not using the actual ELM interface, as it would imply that I did my coding on the drivers seat. So I found a good substitute, OBDSim, that allows me to do my prototyping a bit more comfortably.  I used an FTDI breakout board to interface the simulator with the Arduino.

This was as good help for implementing the OBD parsing code, but it turned out somewhat limited. Apparently, the simulator does not support the AT command to change the baudrate. The ELM interface must be initialized at 9600bps, but after initialization the other end can negotiate a faster speed, which is needed to acquire large amounts of data with a good sampling rate. The lack of this feature in the simulator forces me to acquire all data at 9600, which translates to about 4 values per second. I need to get at least 4 or 5 times that to get a good refresh rate.

The next step is to test it on the car with the real OBD interface, and verify that the parsing is working, and implement the baud rate increase routine. After that I can recompile the simulator to run always at the desired speed and continue the developments at home.

In order to take the whole prototype to the car in a tidy way, I looked for a way of packing the parts so it could be easily transported and still allow development and debugging.  It happen to be that it all fits just nicely into an LTO tape case I had laying around at work.


OBD Logger , , , ,

OBD II PIDs

Posted on July 10, 2011 by Hangas | Permalink 0

OBD II protocol can provide literally tens of engine parameters, but not all are particularly interesting to consider in a real time logging application.  I’m only interested in values that can be used to determine if the engine is running efficiently and driving style.

The OBD standard defines a number of PIDs and operation modes.

  • Mode 0×01 – Request Live Data
  • Mode 0x02 – Request Freeze Frames
  • Mode 0x03 – Request Stored Trouble Codes
  • Mode 0x04 – Clear/Reset Stored Emissions Related Data
  • Mode 0x05 – Request Oxygen Sensors Test Results
  • Mode 0x06 – Request On-Board System Tests Results
  • Mode 0x07 – Request Pending Trouble Codes
  • Mode 0x08 – Request Control of On-Board Systems
  • Mode 0x09 – Request Vehicle Information
  • Mode 0x0A – Request Permanent Trouble Codes

Mode 0×01 is probably the most interesting one for real time data logging as it provides real time data from the engine’s ECU.  This is a list of the PIDs I find interesting. For a more comprehensive list of the PIDs and modes available on the OBD bus,  check the wikiest of pedias here.

  • PID 0×04 – Calculated engine load value  (%)
  • PID 0×05 – Engine coolant temperature (ºC)
  • PID 0×06 – Short term fuel % trim Bank 1 (%)
  • PID 0×07 – Long term fuel % trim Bank 1 %)
  • PID 0x0A – Fuel pressure – (kPa)
  • PID 0x0B – Intake manifold absolute pressure (kPa)
  • PID 0x0C – Engine RPM (rpm)
  • PID 0x0D – Vehicle speed (km/h)
  • PID 0x0E – Timing advance (º relative to #1 cylinder)
  • PID 0x0F – Intake air temperature (ºC)
  • PID 0×10 – MAF air flow rate (grams/sec)
  • PID 0×11 – Throttle position – 0 to 100%
  • PID 0x1F – Run time since engine start (seconds)
  • PID 0×45 – Relative throttle position (%)
  • PID 0×46 – Ambient air temperature (ºC)

Example: Reading the engine’s RPM

 Engine RPM  is the PID 0x0C in mode 0×01, so we should send ’010c’ to the OBD interface.

>010C
SEARCHING: OK
41 0C 0F A0

The interface returns something like ’41 0c 0F A0′.  The first two bytes indicate the type of response; 0×41 means a response to mode 0×01 and 0x0c means that the response is for PID 0x0c, the one we requested.  The next two bytes, ’0F 0A’ are the value for this response, the actual engine rpm value,  according to the specific value formula  ((A*256)+B)/4 in this case (check wiki).

A: 0x0F = 15
B: 0xA0 = 160
(A*256)+B)=4000
4000 / 4 = 1000 rpm

In order to send this commands to the car OBD bus we need an interface to translate the signals from the car protocol (there are 5 protocols in OBD) and the more common RS232 signals.

For this project I’ll be using a module from Sparkfun Electronics. Its a OBD-II to UART converter, based on the STN1110 chip that converts data from all OBD protocols to serial, using the LM327 AT command set (PDF datasheet).

This make it very easy to connect it to an Arduino and read the data from using the SoftSerial library.

 

OBD Logger , , ,