Project Worth The Wait

[blake]

This is hopefully as arcane as this project's programming gets. I don't plan on making posts with hexadecimal values in them in future =)

I said I might post some Python code. I thought a simple example of the way I'm working with the display right now might be interesting. I have it connected to the mac via a USB/Serial adapter (0-3.3v TTL, not the usual voltages you get over your computer's connector, I had to order a different USB/Serial adapter for this).

saint-wifi:ezlcd blake$ python
Python 2.5.1 (r251:54863, Jan 17 2008, 19:35:17) 
[GCC 4.0.1 (Apple Inc. build 5465)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import serial
>>> s = serial.Serial()
>>> s.baudrate = 115200
>>> s.port = "/dev/tty.SLAB_USBtoUART"
>>> s.parity = serial.PARITY_NONE
>>> s.stopbits = serial.STOPBITS_ONE
>>> s.bytesize = serial.EIGHTBITS
>>> s.open()
>>> 
>>> from struct import pack
>>> v = pack("BBBB", 0x84, 0x00, 0xF0, 0x21)
>>> 
>>> s.write(v)
>>>

That's loading the Python interpreter, setting the serial config values and opening the serial port.

Then I make a string 'v' that's 4 characters long, the format of which is represented by the four "B" (for byte, kinda) in the first argument. The next arguments are the values I want. The first is the 'set color' command, 0x84. Then two bytes each half describing the color I want. Then finally the clear screen command, 0x21.

s.write(v) sends that to the LCD and the screen turns red.

 

[blake]

I wasted 2 days chasing an issue with the drivers for the UI-encoder crashing. After digging through their C code I think I know what it was. It would crash whenever I imported their drivers into any non-trivial codebase. So what I did is have my main program call a tiny little program that runs as a fully separate process for the sole purpose of watching the Phidget Encoder and relaying the results to the main process.

Short version: Crashy drivers, still don't know what the problem was, but I've worked around it and moved on in a not terribly elegant but nonetheless kinda neat way.

So now I've gotten a chance to work on what I meant to be doing 3 days ago before I got hung up on random crashes (I really need to find the charger for the real camera. The iPhone has a really hard time auto-exposing for this display).:

Each of those bars fills and empties in response to their appropriate channel. The top one is a potentiometer attached to the LabJack (via Ethernet), and the next 5 are the AEM Thermocouple Amp (via Serial->USB).

The AEM values are out of whack because I have different scales on the gauges to test what happens when the values are too low, too high, or unavailable.

This was the simplest gauge style I could think of (it's just two rects, one filled, one not) as a proof of concept. Prettier stuff to follow.

 

[SupraMaster]

I wasted 2 days chasing an issue with the drivers for the UI-encoder crashing. After digging through their C code I think I know what it was. It would crash whenever I imported their drivers into any non-trivial codebase. So what I did is have my main program call a tiny little program that runs as a fully separate process for the sole purpose of watching the Phidget Encoder and relaying the results to the main process.

Short version: Crashy drivers, still don't know what the problem was, but I've worked around it and moved on in a not terribly elegant but nonetheless kinda neat way.

So now I've gotten a chance to work on what I meant to be doing 3 days ago before I got hung up on random crashes (I really need to find the charger for the real camera. The iPhone has a really hard time auto-exposing for this display).:

Each of those bars fills and empties in response to their appropriate channel. The top one is a potentiometer attached to the LabJack (via Ethernet), and the next 5 are the AEM Thermocouple Amp (via Serial->USB).

The AEM values are out of whack because I have different scales on the gauges to test what happens when the values are too low, too high, or unavailable.

This was the simplest gauge style I could think of (it's just two rects, one filled, one not) as a proof of concept. Prettier stuff to follow.

I am enjoying your progress so far. I like the fact that you have chosen to test out the functions instead of building the programming first without testing. I can't wait to see more progress.

 

[blake]

More Progress:

The real camera is elsewhere at the moment, so you get blurry stuff for now.

Those are menu items, the phidget scrolls through them and selects them, press to activate. You can kinda see where I'm going with the user interface. However the concept hasn't totally solidified yet. If anyone has any feedback on that aspect I'd love to hear it, and soon.

 

[SupraMaster]

More Progress:

The real camera is elsewhere at the moment, so you get blurry stuff for now.

Those are menu items, the phidget scrolls through them and selects them, press to activate. You can kinda see where I'm going with the user interface. However the concept hasn't totally solidified yet. If anyone has any feedback on that aspect I'd love to hear it, and soon.

My major question as far as this goes, is : How dynamic can your interface be and still run reliably?

 

[blake]

My major question as far as this goes, is : How dynamic can your interface be and still run reliably?

My answer is: Very.

Are you doubting my mad coding skillz? =p

Seriously though, Python is really great about exception handling without crashing. I'm quite glad to have moved those C drivers out of my main code base so my main program is extremely unlikely to crash in a way that can't be caught and recovered. And even if the Interpreter does crash I'll have a watchdog program reset it.

Of course it's not magic. I do have to write the error handling code, but the code that handles the LabJack and other modules is already very robust. Once the display/interface code stabilizes some I'll start adding more error handling to it.

P.S. You don't need to quote a 3 paragraph post with images in your consecutive reply =p

 

[SupraMaster]

The reason for the question was to find out how far you could take it without any problems. The reason I replied with the previous post is because, although it's early in the programming, the set-up looks archaic. No offense if any is somehow implied.

There are so many places you can take this, due to your selection of Python, that I'm not sure how far is too far.

Mike

 

[blake]

It looks "archaic" because in a way it is. There's graphics library built into the display is very rudimentary. I'm building my own library on top of it in Python by drawing rectangles and lines and so on. But on top of that layer I'm adding another layer of intelligent elements like gauges.

Here's the code to add the top gauge:

		ain0Gauge = ezlcd.hGauge(self.w.ez, 10, 10, 180, 10)
		ain0Gauge.min = 50
		ain0Gauge.max = 100
		ain0Gauge.channel = self.w.chanForName("ain0")
		ain0Gauge.show()
		self.w.ez.elements.append(ain0Gauge)

Here's the code to add the menu:

		for i in range(10):
			self.w.ez.menu.addItem("Menu Opt%s" %i, None)

So when I added the code for the tick marks and the numeric readouts (I haven't posted a photo since those changes) all the gauges get that feature.

Forgive me if I'm wandering back and forth between too obscure/technical and borderline patronizing I'm not real sure of your background -- actually I just scrolled up and reread your first post in this thread. You'll recognize the drawing routines as not entirely dissimilar to your TI-85 or your Atari. But the code behind it is a totally different thing.

P.S. I actually want to keep it fairly rudimentary. I don't want to be interacting with a traditional desktop window environment or even a touch screen while I'm driving. I'm basing the interface loosely on Audi's Nav/Trip computer interface from their 98-2003 models.

 

[SupraMaster]

My experience with the TI-85 and the Atari computer were just minor examples. I understand the code you have presented, that's not a problem to read at all.

I like the fact that you are simply using rectangles and ticks. There's nothing more that you need, to convey the gauge readouts so they are understandable.

Now you can just dress it up a little, throw readout labels on it, and give it a test.

 

[blake]

Now you can just dress it up a little, throw readout labels on it, and give it a test.

I'd show you a photo of just that, but I'm at the office right now =)

 

[SupraMaster]

I'd show you a photo of just that, but I'm at the office right now =)

I can't wait to see it.

I'm gonna head out for the day, so I look forward to seeing the update when I return @ 4 A.M.

 

[blake]

Don't know if I'll get any coding in before I pass out tonight. Long day.

 

[blake]

I found the other camera. I'll have to play around with the settings a bit to see what comes out best, but a quick stab in the dark is still better than the iPhone:

Rough draft of a different gauge (there might be a better name for it but I'm calling it a Ramp Gauge). More suitable for at a glance viewing.

If anyone has any suggestions for different readouts I'd love to hear them now while I'm still tinkering with the drawing (and it's fresh in my mind). I can technically create any image on the screen but some are easier than others. So I may not end up doing exactly what you suggest but with luck it'll spark an idea for something practical.

 

[IJ.]

Blake: Can you give an example of what you'll actually use the Gumstick for?
(might have to dumb it down a bit I'm old)

 

[blake]

If I didn't have the gumstix with its display(s) I'd be installing an ADL. One of the data channels I haven't been demonstrating is the one from the M600. Since the M600 has been sitting in a box at SP I haven't had a chance to test with it.

The Gumstix + LCD + LabJack all together cost maybe half (or with the dollar tanking maybe more like a third) the price of the ADL. Since the ADL was on the plan from the start I can pretty much add displays until I run out of dash/gauge cluster space and still come in under the older budget.

I get a whoooole lot more flexibility even in just the ADL-like features. Like say, I can do as many PID controls as I like, I have no limit of 'channel maths', and so on. Not that I'd recommend you ditch your ADL. As complicated as it is to set up, it's still configuration of a preprogrammed system that someone's already thought through. If all I wanted was feature parity with the ADL this would be a monumental waste of time.

The thing I really like about the gumstix is, aside from not having a monitor, keyboard, and mouse: It's just a computer. It has USB, Ethernet, Wifi, and Bluetooth just like a normal computer. So my programming can interact with the world as if it was running on a pretty normal computer (my experience with python code is usually nested so deep inside an existing framework it doesn't actually interact with a normal KB/Mouse much anyways).

One of the random examples I gave earlier of what that means is that I can run a web server on the gumstix, which is acting as a WiFi hotspot. I can then display additional information on a web page on any web browser. My phone (an iPhone) has a pretty decent web browser. I can add controls to that web page. One of them could be 'unlock doors'. I press that button, the gumstix tells the LabJack to set channel FIO5 'high' for 0.2 seconds. FIO5 is connected to a relay bypassing the unlock switch. Tada: remote keyless entry from my phone.

Or remote start, or a engine cool down (turbo timer) function, or have the windows roll up, lights turn off, and doors lock whenever my phone is out of bluetooth range. And reverse that process when I come into range. Now it's the Mercedes Proximity Key thing (I think a few other makes have added that feature now).

For right now though it's just a fancy gauge. But I'll push that too. I plan to have a whole bunch of different screens I can select to show me different sets of readouts. All 6 EGTs side by side on one screen. A normal screen with RPM and ground speed (constantly calibrated against the GPS?) and an 'alert' space. Any channels that get out of range will pop up as a warning.

All of these feature take time to implement. But that's what hobbies are for =)

I was originally going to just use the gumstix to stay on all the time consuming minimal power and then wake a 'normal' computer (Mac Mini) from sleep mode (or boot entirely) when required.

But then they introduced a model with "USB-Host" so devices (like USB/Serial Adapters) can connect to it, instead of it just being the 'client' of a normal computer.

The gumstix also couldn't really display anything. But there are now displays (like the ezLCD you keep seeing) that I can drive with a USB port. Since the gumstix can now drive USB devices I can run as many of those as I like. They're actually touch screens too by the way, I just plan on the first one going in my gauge cluster and I don't expect to be reaching through my steering wheel to press buttons while driving.

Hopefully that gives a few more concrete examples of where I'm going with this. I wandered around a bit to try to touch on a few different aspects. Let me know if you want more on anything in particular.

I guess I tend to gloss over the specific functions right now because there have been a bunch rattling around in my head for a long time now and I really don't know which ones I'll implement first. "No Promises" =)

But I do love to hear new ideas. Even if I never implement them it's fun to work through if they're even possible, and then how I'd go about making it work. So speak up if you have any =)

P.S. Well that stab in the dark turned out to be pretty lucky. I can't seem to duplicate that clarity again. It's just a Canon SD110 from a few years ago. I wish atleast one of my buddies into photography was local still.

I end up looking at these photos on the computer for a while and then glance back at the actual display and it amazes me how bright and crisp it is =p

 

[SupraMaster]

I was just thinking, after reading your progress of course, that it would probably be easier to use the speed sensors on the car, rather than trying to screw with the GPS. Just a thought.

 

[IJ.]

Blake: (ummm was that the dumbed down version?)

Sounds perfect for my car!

NOT a big fan of the MoTeC displays and being able to pick and choose exactly what I want to display would be a huge benefit for me.

After you get it working I'd be very interested in duplicating it (or having you duplicate it for me I mean, me being an electronics Neanderthal)

 

[blake]

I was just thinking, after reading your progress of course, that it would probably be easier to use the speed sensors on the car, rather than trying to screw with the GPS. Just a thought.

You'd be surprised. Just plugging something like this into one of the serial ports gives me a data stream that includes my ground speed. It's something I've already tested with my Garmin eMap.

Where as the Vehicle Speed Sensors need to be attached to a frequency counter (not just a voltage input) and then need to be calibrated (how many 'clicks' per mile). Not real hard either, but more work to get right.

I expect to use both though. The GPS only updates once a second. I'll probably write the code to calibrate the VSS against the GPS and then just leave it self-calibrating all the time.

I just thought I'd point out how easy the GPS part really is

 

[blake]

Blake: (ummm was that the dumbed down version?)

Sounds perfect for my car!

NOT a big fan of the MoTeC displays and being able to pick and choose exactly what I want to display would be a huge benefit for me.

After you get it working I'd be very interested in duplicating it (or having you duplicate it for me I mean, me being an electronics Neanderthal)

There's not much to the 'electronics' of it. It's all software. Plug this into that, and a few bare wires here and there. Serial line between the Motec and the Gumstix. USB or Serial between the Gumstix and the Display.

As I develop the software I'll try to keep things so the Motec and Display software modules run sanely on their own. It's easy to let things get heavily interdependent but I've done a pretty good job of avoiding that so far. Some of the 'screen shots' I've posted don't show values for the Thermocouples because I just unplugged the AEM TC Amp, and it handles it cleanly.

I've had ideas about configuring my gauge pages in text files that get read by the main program at run time. So if I want to add a page with a different set of gauges I don't need to edit the code. No promises of course, but that would certainly make things more configurable for you.

 

[Chronus24]

I wish atleast one of my buddies into photography was local still.

I have a lens that can take that picture from here, just hold the screen up a little bit.:biglaugh: