Feeler: Open Source OBC Firmware

[Mefis]

m2pc: I count 12 bits at 250bps. if you read 10 or 11 at times, probably you are seeing spaces at the end.

The first must be a start bit and there may be a zero at the end serving as a stop.

As far as i can remeber the most common situation is that low voltage is a one (remote pulldown on) and a high voltage is a zero (remote pulldown off) except for start and stop bits where start obviously has to be a mark (0V) and stop has to be a space (hi v)

it could be that we have 8 bits for the fuel and 3 as checksum, or parity.

benemorious reported 3 chains, maybe he can clarify, but they all start with a zero so let's asume for a moment he was reading 0v as a zero, so they all are inverted and i will type yours from the picture inverted. The last bit matches as a parity in all cases.


01 0111 0101 000 == 0 1000 1010 11 1
00 1111 1110 001 == 1 0000 0001 11 0
01 0110 0110 001 == 0 1001 1001 11 0

01 0010 1110 001 == 0 1101 0001 11 0

[m2pc]

Wow this looks awful like RS-232 (with a start and stop bit, and parity)... I wonder if I could slow the PIC UART down to 250 bps and it would read this for me?

[benemorius]

Back to the fuel tank level signal, Benemorious, I tied this to +5V with a 10K pullup, but I'm having a difficult time decoding the bits, particularly how to distinguish between a logic "1" and "0".
Are you sure this is 12 bits? Often times I could only count 10 or 11 bits visually on my scope, unless the last bit is the same as the "idle" state between transmissions.

Is this interpretation correct?

I'm making a few assumptions about the signal in order to read it. None of them are necessarily correct. If your observations are in conflict with any assumption I've made, trust your observations. I'm assuming that the first bit is a start bit and is therefore always low. I'm also assuming that there are 13 bits total because I have seen up to but never more than 13. Clearly if there are one or more contiguous high bits at the end then they wouldn't be evident on a scope. Going forward I am less certain about my assumptions. I assume that logic 1 is high because doing so has provided readings that could be considered valid. For the same reason, I assume that the middle 8 bits (the third through the tenth) are the ones we're interested in. I assume we read those bits LSB first once again for the same reason. Finally, I assume that the last bit (13th) is an even parity bit because I have never seen an odd number of 1 (high) bits and because one would expect a parity bit to be placed at the end rather than anywhere else.

If I were to read your signal as I've been reading mine, I would interpret it the same as you did, but with the bits inverted and an extra high bit at the end. That is, 0100101110001b. That would give us 0x74. Assuming that the range is approximately 0-ff, we could expect such a reading to correspond to about 50% on your analog fuel gauge. If not, we'll have throw some assumptions out the window and start over.

Wow this looks awful like RS-232 (with a start and stop bit, and parity)... I wonder if I could slow the PIC UART down to 250 bps and it would read this for me?

Certainly it will if you can set it for >8 bits. I don't believe you can.

Regardign the supply for the display, the logic may be fine but you need to bias the LCD with a reasonable voltage. 3.3 as LCD bias may be cutting your maximum contrast signifcantly.

I saw a ~6V on pin 3 if i am not mistaken, and I just tied it to +5. I presume this is for LCD biasing.

Have you noticed whether the factory OBC has any means of varying the LCD bias voltage? I was planning to drive a switched capacitor regulator from the 12v rail for this so that adjustments can be made to keep up with varying temperatures.

[Mefis]

Regarding the LCD bias, yes the stock OBC has a capacitor and a transistor to switch it, but not clear on how you would calibrate such a device, unless you read back to the ADC.

Now regarding the fuel tan signal, i can relatively easily add another analog switch to the fuel signal in the diagnostic uart input, however i don't see how we would know that there is an incomming byte. It will be able to run 250 bits for sure. (it will run 5bps).

Let's give this some thought. It should be possible to use some code in a generic pin to read the signal as well.

[m2pc]

You bring up a good point; I've been thinking of ways to multiplex the hardware UART using analog switches; I think it may be possible if the code is designed to context switch between modes. For example, check the fuel tank, then get a packet from the GPS, then check in with the vehicle data bus, etc.

[johnf]

Now regarding the fuel tan signal, i can relatively easily add another analog switch to the fuel signal in the diagnostic uart input, however i don't see how we would know that there is an incomming byte....

If you are restricted to powers of two, use a software UART updated at 150 x 8 = 2 khz. I used one about 25 years ago to add characters to a serial stream. The code took less than 40% of the processor time on a processor, rescaled by the receive rate, that was more than 300 times slower than the ones you guys are using. (That coroutine was sampling the input pin every 16th instruction.)

[m2pc]

If you are restricted to powers of two, use a software UART updated at 150 x 8 = 2 khz. I used one about 25 years ago to add characters to a serial stream. The code took less than 40% of the processor time on a processor, rescaled by the receive rate, that was more than 300 times slower than the ones you guys are using. (That coroutine was sampling the input pin every 16th instruction.)

I thought about using a software UART. It would be especially trivial for the slower comm links like the cluster's fuel level signal. With a PIC I can either use one of the timers prescaled to 2KHz, or connect the fuel level signal to the timer clock input where I can measure the on/off duration and determine the bit timing. I may take the latter approach as it's interrupt-driven and guaranteed to produce accurate results.

[johnf]

I thought about using a software UART. It would be especially trivial for the slower comm links like the cluster's fuel level signal. With a PIC I can either use one of the timers prescaled to 2KHz, or connect the fuel level signal to the timer clock input where I can measure the on/off duration and determine the bit timing. I may take the latter approach as it's interrupt-driven and guaranteed to produce accurate results.

I don't consider anything guaranteed until it has been verified. (Or as Lenin said, trust is good, control is better. ) The former, polling scheme would be easier to verify. I assume you'll have a timer running, anyway, to schedule your tasks.

---- merge ---- merge ---- merge ---- merge ---- merge ---- merge ---- merge ---- merge ---- merge ----

I just realized I stuck a controller I developed some years back in the wrong place. Rather than placing it next to the ZKE, I should have put it near or in the OBC, and hacked the latter to get some of the I/O I needed. This would have also tied in with a project Jim Conforti was working on. The other thing I should have done was not write its code in PIC assembler.

Keep up the good work, guys!

[benemorius]

Hey m2pc, how about hooking us up with openobc.org email addresses for sample ordering?

I guess it's my turn to post a schematic. It's almost complete. The text is far more legible in the pdf than the png. Kevlar needs to raise the image size limit a bit.

[Mefis]

Cool! But what is your vision on the ISM radio module? Can you elaborate?
is it anything similar to the bluetooth thing?

Update on my PCBoard drawing. Some progress, so far verified up to U4 out of U16. By the way found a nasty error on U4 (darlington array), you may notice the bases are to the outputs and the collectors to the MCU... what a goof!

Another update is that i am not liking the original GPS module, the manufacturer is not posting data for their device, and they are slow to reply. I will switch to the fastrax ITU520, which is smaller and they already sent me the protocoll details. It will be a PITB to modify the drawing for the different footprint, but they have to learn to improve their customer service. Screw those guys !!

[benemorius]

That's there for evaluation. I don't yet know whether I want it or not. The uses might include keyless/alarm transceiver, garage door opener, and perhaps other things I haven't considered yet. I don't intend for it to replace bluetooth. I'm just not putting bluetooth on this board yet.

[Mefis]

OK... finishing deleting that stupid SiRF III product, yet another lawer-driven time waste. Just finished drawing the PCB for the new GPS module.

I do not understand these stupidities.... motorola and rockwell implemented the GPS system and they do provide their datasheets openly... but some dumbass lawer needs a job at sirf.

"...Access to the SiRF Customer Zone is limited to those developers who have purchased a SiRF Evaluation or System Development Toolkit and who have signed the appropriate confidentiality and license agreements..."

[benemorius]

Indeed. Bluetooth was the same way when it was introduced and for all I know it still is. For the most part, this mentality is the last remaining obstacle to small projects like ours. It's hard to imagine it ever going away, but I do look forward to seeing that happen.

[tejawxyz]

Good luck to you, Please make this happen.

[m2pc]

OK... finishing deleting that stupid SiRF III product, yet another lawer-driven time waste. Just finished drawing the PCB for the new GPS module.

I do not understand these stupidities.... motorola and rockwell implemented the GPS system and they do provide their datasheets openly... but some dumbass lawer needs a job at sirf.

"...Access to the SiRF Customer Zone is limited to those developers who have purchased a SiRF Evaluation or System Development Toolkit and who have signed the appropriate confidentiality and license agreements..."

Haha, that reminds me of the time I tried to get a data sheet (or even just a pinout) for a laser barcode scan engine. No documents at all online, and I could barely get someone to email me a document without signing an NDA or purchasing 1000 units.

Very annoying to say the least, and yes, a huge obstacle for small projects.

[Mefis]

Hi All!

I am still drawing and verifying the board, but I was thinking it might be time to define some software functions to move forward the development.

What i mean is to separate the high level functions like the user functionality, and the lower level functions like measurements from devices. As an example let us take the fuel level data. let us define a C function fuel_level(&val), which the high level programmer can call, and have the most current data copied over to val. On the other side, I will be writing the function, probably in assembler, that will probably be an interrupt driven routine to decode every byte that comes in from the fuel tank, and store the data in some location ready for the user to call the function.

Another function I can already see is printscn("Hello openOBC"); to dismplay any string on the screen.

In this way, we may accomodate different hardware versions (maybe even MCU??) and having the same high level code for user functionality written in friendly C and that hopefully others can take it from there and come up with a nice and comfortable user interface.

Now we probably need a better place to document these. Perhaps a google documents spreadsheet? is easy to share/edit. Any thoughts?

[m2pc]

Good timing! I have started the Wiki here: http://www.openobc.org/wiki/ and we can use that to document everything.

FYI, I took snapshots of the fuel level signal at various resistances and tank indicators; it's just a matter of decoding the bits.

[benemorius]

In this way, we may accomodate different hardware versions (maybe even MCU??) and having the same high level code for user functionality written in friendly C and that hopefully others can take it from there and come up with a nice and comfortable user interface.

I've been putting some thought in to this also. I was thinking we might do well to use something like freeRTOS as a means of encouraging this kind of development.

Good timing! I have started the Wiki here: http://www.openobc.org/wiki/ and we can use that to document everything.

Yay! Do you have a forum up yet? Discussing this entire project in a single thread is most cumbersome. Never before have I ever had so many bookmarks for one thread.

Ah, you may of course disregard the previous inquiry. It was hiding in plain sight!

[m2pc]

Haha, no let me get the forum up today if possible. TikiWiki also has one built-in, so it should be trivial to enable it.

Regarding the whole code structure/OS, my plan is:

a) Build a function library for all the basics (writing to the LCD, reading the keypad, reading the fuel level, reading the instantaneous fuel consumption, etc.)
b) Build a "reference design" as it were, in code, that emulates the standard OBC functions.
c) Release this code and allow others to expand on it.

My thoughts are to build the reference design to be as close to the original OBC design as possible. For example, pressing TEMP multiple times cycles through the various temps, while some clever key sequence (maybe holding the button down for 4 seconds and using the SET/RES key) allows the user to set which temps to show onscreen together when the TEMP key is pressed once like the stock OBC.

As was mentioned before, it would be nice to remap the keypad to be more generic and have arrows and a select button and such. A simple workaround in the meantime would be to utilize the arrows to the left and right of the main display, which line up with the "1000" and "CHECK" buttons. That could facilitate scrolling through a menu of choices, with the SET/RES key acting as a "SELECT" button.

Also, the arrows would light to indicate more menu options were to the left or right of the current one, with the arrow turning off once the extremes of the menu were reached.

Another thought along these lines is to use the secondary display to show the value that corresponds to the current menu item. We could even "side scroll" the small display to allow the user to see values > 4 chars long. A press of the SET/RES key would take you into "edit" mode where the value would be on the main display along with a label.

Just some random thoughts...

[Mefis]

Maybe we can start with a simple PC console application to make it easier and staightforward, i.e. printscn() is just printf(), but then we can port the thing to the real product....

In terms of the drawing... i am done routing, but need to optimize some things. The worst problem i see is that i can't find space for the fourth screw of the expansion board. I only have 3 screws and i don't like it...

[Mefis]

OK, so i made space and solved the problem if we use metric M3 screws and standoffs instead of the common 4-40. Sorry to all my American friends, but i do need those 2 extra millimeters in the board.

[m2pc]

M3 screws FTW!

[m2pc]

So I'm beginning to rethink my choice of the PIC microcontroller for the following reasons:

a) Compilers are expensive (over $1000 for a good optimizing compiler)
b) Requires proprietary programmer from Microchip
c) Not really open-source friendly

Any thoughts on a better choice? So far I'm leaning toward the AVR line since there is a GCC-compiler for free (WinAVR), and tons of other tools available. Plus their 32-bit AVR32 series are extremely powerful for the price ($11 in single quantities for a 144-pin beast with 110 I/O pins and 66MHz clock speed.

[benemorius]

AVR definitely gets my vote for 8 bit.

[m2pc]

What about the new AVR32 series? From my research it seems those are well supported, cheap, and powerful. I think I saw one with like 5 USARTs onboard!