{"id":696,"date":"2016-07-16T18:05:29","date_gmt":"2016-07-17T01:05:29","guid":{"rendered":"http:\/\/zethus.ca\/wp\/?p=696"},"modified":"2017-01-01T22:43:16","modified_gmt":"2017-01-02T05:43:16","slug":"obdii-car-gauge","status":"publish","type":"post","link":"https:\/\/zethus.ca\/wp\/?p=696","title":{"rendered":"OBDII Car Gauge"},"content":{"rendered":"

Jan 1:<\/p>\n

The project that will never get done. \u00a0 Due to my new intense dislike for vmware on osx,(probably as a result of vmware letting go of the whole team a while back) I’ve switched to docker. \u00a0It took about a week of my spare time to get things more or less the way I want them.<\/p>\n

The Dockerfile I ended up with is: (ymmv):<\/p>\n

FROM wolfeidau\/esp8266-dev:1.4.0\r\n\r\nRUN apt-get update && apt-get install -y \\\r\n zlib1g-dev \\\r\n default-jdk \\\r\n curl\r\n\r\n# add all the SDK stuff to the PATH\r\n ENV PATH=$PATH:\/opt\/Espressif\/crosstool-NG\/builds\/xtensa-lx106-elf\/bin\r\n\r\n# this needs the trailing slash\r\n ENV XTENSA_TOOLS_ROOT=\/opt\/Espressif\/crosstool-NG\/builds\/xtensa-lx106-elf\/bin\/\r\n ENV SDK_BASE=\/opt\/Espressif\/esp_iot_sdk_v1.4.0\r\n\r\n# Path which contains your esp8266 project source code\r\n WORKDIR \/Volumes\/MacHD\/Users\/chuck\/Organized-Projects\/CarGauge\/Build\/esp-gauges\r\n\r\n# pass -v \/Users:\/Users to ensure your shared folder is available within\r\n# the container for builds.\r\n VOLUME \/Users\r\n VOLUME \/Volumes\/MacHD\/Users\r\n\r\nRUN echo \"root:Docker!\" | chpasswd\r\n\r\nUSER ubuntu<\/pre>\n
I’m also using obdsim on mac using the obdgpslogger-0.16.tar.gz<\/strong> version (in the Tarball section) from this link<\/a>.<\/p>\n
You need to navigate to the downloaded folder and then run the commands:<\/p>\n
mkdir build\r\ncd build\r\ncmake .. (I installed this with brew, which needed the newest xcode)\r\nmake\r\nmake install # optional<\/pre>\n
This whole digression is very reminiscent of yak shaving<\/a><\/p>\n
 <\/p>\n
Oct 31:<\/p>\n
More minor progress. \u00a0Communication is better, but slow. \u00a0Gauge PIDs are selectable through the U\/I. \u00a0Now to just pretty up the displays a bit.<\/p>\n
\"lex\"<\/a><\/p>\n
Oct 6:
\nNow with case… I spent a couple of nights CNCing, and now have a case, 1\/8″ acrylic in front and a spacer for the boards to fit into and a back, that has some pocket cuts for \u00a0some of the larger parts, the LDO, usb mini jack esp8266, and a slot for serial port access, in case I really mess up an pooch the OTA capability. \u00a0Back to writing S\/W I guess.<\/a>Oct 4:<\/p>\n
It’s getting there. I’ve got five displays daisy chained now; selectable with the demultiplexer. Just tonight I’ve folded the displays over to the back of the board and held them down with 3M VHB double stick tape. \u00a0For development, I’m talking to\u00a0obdsim\u00a0<\/code>on a linux vm to write the software. \u00a0So far, software-wise, I can initialize the controller, and query the OBD for the available PIDs. \u00a0I got a little bored of the SW and want to start building a case for the displays now. \u00a0Since the wifi OTA updates work great I’m confident that having the displays “case-ified” won’t be a problem at this stage of the game.<\/p>\n
\"img_1826.jpg\"<\/a><\/p>\n
 <\/p>\n
\"img_1845.jpg\"<\/a><\/p>\n
Sept 6:<\/p>\n
As you can see (way) below I’ve added the ELM 327 dongle to setup the and hooked up the UART through the mini USB connector. After booting the module, connecting to the AP and telnetting in :<\/p>\n
mac-mini:~ chuck$ telnet 192.168.4.1 23<\/span>\r\nTrying 192.168.4.1...<\/span>\r\nConnected to 192.168.4.1.<\/span>\r\nEscape character is '^]'.\r\n<\/span><\/pre>\n
And setting the baud rate on the web page:\u00a0I’m talking to the dongle:<\/p>\n
>01\r\nSEARCHING... UNABLE TO CONNECT\r\n>ATZ\r\nELM327 v1.5 \r\n>atrv \r\n11.9<\/pre>\n
Here is the web page log, along with the baud-rate selection buttons:<\/p>\n
\"Screen<\/a><\/p>\n
Here is the current hardware setup. It is a little more stable now that it is glued down!<\/p>\n
\"img_1664.jpg\"<\/a><\/p>\n
Sept 5:<\/p>\n
I’ve done a bit more investigating on the power up problems. \u00a0So purely empirically, when the display is running, if I cut and reconnect power before the 13V supply charge pump cap drops below about 12V, the display works. \u00a0Failing that I need to wait about 90 seconds before applying power (when the voltage at the cap is at about 6V). What is weird is that if I short the cap to discharge the 13V supply it still does not come up, so it seems that the display is rather particular about how it is powered on.<\/p>\n
This could easily still be a software problem. More digging is required! There are power up timing constraints in the data sheet which I am completely ignoring:<\/p>\n
\"Screen<\/a><\/p>\n
Oh well.<\/p>\n
Another Update Sept 4:<\/p>\n
The board is getting really messy now. \u00a0I reworked the board to use the hardware SPI chip select, instead of bit banging. This required using an inverting input on the HC138 (decoder\/mux). \u00a0After a bit of software rework,\u00a0voil\u00e0, we’ve got an image. \u00a0So it occurs to me that the reason the software CS probably didn’t was that the signal was inverted going through the mux. Oh Well. \u00a0I’m not out of the woods yet however, since there is a power up sequencing issue that I need to solve. \u00a0The upshot is that I need to leave the display unplugged a couple of minutes before the display boots correctly. More to come. \u00a0Long weekends rock!<\/p>\n
<\/a><\/strong><\/p>\n
 <\/p>\n
 <\/p>\n
Update Sep 4<\/p>\n
I soldered on the OLED display. It’s alive. \u00a0Sort of. \u00a0So I think electrically it is probably ok, I suspect the chip selects, or startup timing. Baby steps.<\/p>\n
\"\"<\/a>
\nUpdate Sep 3<\/p>\n
Work is slowly progressing on board bring up. \u00a0So far there have been two errors in the board design.<\/p>\n