Archive | August 2013

Polarity

It helps if you connect the converting bit on your universal 12v connector with the pins in the correct polarity. Otherwise you’ll kill your HDMI to LVDS board.

Pants.

Take it away, Picard.

Bullet bitten

The 8.9″ HSD089IFW1. Isn’t she a beauty?

Just about fits in the gap, with some clever fitting it should be perfect. Now to get an adaptor and turn on the Pi for the next step.

Here’s hoping it’s bright enough…

Size matters

Since the last post I’ve been doing some more browsing at screens. The Chalk Elec 7″ screen isn’t available for a little while, so I’m looking at other options.

A few days ago, I got my spare instrument cluster and I took it apart. It has four contact points and the largest usable rectangle is pretty much 250mmx125mm. This is quite wide screen and I’m not entirely sure whether 7″ will be big enough. The spare Nexus 7 I have pretty much disappears in it. I’ve found that there’s a few 8.9″ screens and they’re 213.36×129.55mm. That’s suspiciously close to what would be more filling to the hole. It’s every so slightly too big but 4.5mm isn’t insurmountable. Is it?

The downside is pretty big. The brightest screen I could find is the HSD089IFW1 at 220cd/m2 and a contract of 500:1. In comparison the (unavailable) 7″ one is 400cd/m2 and 800:1 contract ratio.

To quote Beelzeboss:

Fuck. Fuck! FUCK!

That’s a very sizeable difference. My Nexus 4 apparently goes up to 11608cd/m2.

Size > brightness?
Brightness > size?

It appears that when I look at the specifications, whenever there is a bright display, it is low resolution and the high resolution ones are less bright.

The alternative to getting a bigger, less bright, screen is to get TWO screens. The Pi has the HDMI out but it also has GPIO port to which you can attach a small screen, like so:

But that sort of ruins the vibe of the whole thing, I think. I want smooth and sleek and sexy. Nice smooth fonts. Sexy fonts. Crisp. It should pop out of the screen.

Pop.

On a more joyous note, I only just found out that the Pi does hardware accelerated OpenVG. This is so perfect for this project. Vectors make things crisp and pop. Pop. I shall have to spend some more time investigating the API but it looks fairly straightforward. All I need to do is somehow translate all of the icons and other bits I want to display into vectors. That’ll be a bit of tedious work but it should look awesome.

The downside from this is that I don’t have a screen to test with. See where this is going?

Display

After much searching for a decent high resolution screen, I think I’ve finally found a good candidate at a reasonably price.

The Chalk Elec IPS displays. They do a 10″ and 7″ variant, for $134.99 and $124.99 respectively. Unfortunately they have some problems with their 7″ one causing it to be out of stock:

“We assembled first batch of 12 displays and found that almost all of them have serious problem with video synchronization.”

Luckily, they are working on a fix and should have a new batch ready. As I’m in the EU, there’s a German distributor, which would mean I wouldn’t have to pay the VAT and import duty on top of the price but I wonder what their lead time on it would be once they Chalk have fixed the problem and new batches available.

The screens both have IPS and the 7″ is 1024×600 with the 10″ being 1280×800. Both much better resolutions than the scummy ones I found that are 800×400! I have sent them an email inquiring them about the physical dimensions as they don’t seem to be listed on their website.

Now I need to find out which version will fit best into the existing hole. I’ve ordered an extra instrument cluster that I can play with and modify to hold the screen and measure what dimensions I need.
If it turns out that I need a completely custom holder, that wouldn’t be too much of an issue as I know a guy with a 3D printer.

Time to get this out:

USB CDC & Boot times

My idea of using USB keyboard as a simple way of communicating that didn’t require anything special on the Pi side has had a bit of a knock as “because the USB interrupt transfer type is used, a maximum of 1000 packets per second can be sent”. Only a 1000 per second? Assuming I could express each data packet in 100 characters, that would be only every 1/10th of a second, or every 100ms. I would want at least an update every 20ms.

Luckily I realised I was being a bit apprehensive about the RAW USB connection, as I can just use Arduino Serial. Apparently this works through USB CDC, which is pretty standard and should be recognised by the Pi as a TTY. Phew! So that’s at least one potential problem taken care of.

Now, I have just done a quick test. The Leonardo has a simple image that just blinks an LED as soon as it can. During start up the LED stays on as a status indication. Starting as well as rebooting reveals that the Leonardo needs 10 seconds to get to the state of running the image. 10 seconds! Well, that’s a bit of a problem. 😦

The traditional software engineer’s solution would be to have it simply be always on and reset it as the ignition is lost. That would require a battery though and seems like a bit of a bad idea in general. Maybe I should get the flux capacitor extender and whenever you power it, it would go back in time 10 seconds to turn itself on. Sadly they seem out of stock every where.

Perhaps another Arduino board would fare better?

A quick search reveals that actually the boot loader is probably to blame, listing a few solutions:
– I can use a different version of the boot loader that is slightly quicker; or,
– burn images directly onto it. This can be done with a Parallel Programmer and Windows or a AVR programmer.

Ok, so that means the boot loader delay of 6-8 seconds can be removed. That should be better. 2 seconds (ish?). Anyway, for convenience I can continue using the boot loader and then strip it once speed becomes an issue. Good times. 🙂

Rough plan

arduinopi-outline
So that’s the plan. Fairly obvious too, I might add. The best plans are always obvious.

As per the previous post, the loom that comes in features 3 connectors. I need to determine the relevant inputs and which ones I can treat as a digital signal (obvious ones like turn signals, etc.) and which require analogue to digital (e.g. rev signal). It’s only wires, what could be simpler than that! :\

Possible problems:
– not enough input on the Leonardo
– Leonardo not precise enough
– Leonardo incapable of reading the range of inputs that the loom produces.

Once the Arduino has read all of it’s signals it needs to output those values. The easiest way might be to use the USB connection. The board has SPI output but sadly the Pi doesn’t. It is available as an extra GPIO addition, but that’s quite expensive. The interesting thing about the Leonardo is that it has one processor that does both the ADC and USB. So this means I can do whatever I want with the USB protocol. One way it can attach is through USB keyboard, that might be easiest.
If I do this I’ll need to design some custom protocol, should be easy enough, maybe something like a letter followed by the numerical value. Easy enough to parse and usable through a keyboard protocol. Could even input it manually for testing/debugging purposes.

Possible problems:
– USB not low latency enough
– USB keyboard approach not quick enough

So, now all is well, we have the Leonardo board reading some signals, able to pump some data over USB to the Pi. Now the Pi needs to be able to boot up quickly. There is at least one project that does this. I might borrow their work. An additional thing may be to use OpenGL ES without X. That might speed things up, though I don’t know what the RPI buildroot method uses.

“Just” need to create an image that boots into the mode where it parses the input and displays the data.

Possible problems:
– I don’t know OpenGL ES. Yet. Book ordered.
– Pi might not be able to boot up quickly enough.
– Don’t know buildroot. Yet.

Now all we need is a screen to display it. I’d like it to be fairly high resolution, something like the Nexus 7, which uses the Hydis HV070WX2 according the iFixit teardown. Sadly that seems hard to buy in low quantities for a reasonable price and with HDMI connection.

Of course, it all depends on what actually fits into the area of the instrument cluster. There are some useful screens from Lilliput UK but it takes 15 seconds from starting to displaying a picture over HDMI. 😦 How can it take that long? Anyway, there are some Pi specific screens but they all seem rather low res. Boo.

Possible problems:
– Don’t know what screen will best fit the instrument cluster area
– Might not have high resolution screens
– Screen might not start up quicker than the Pi.

Oh, and once I have all of this, I somehow need to create an enclosure for it that will fit into the current space. Damn.

Plenty of problems to overcome. Let’s see how far we get.