Boards for lincomatic's open source "LeafCAN"

[TomT]

In stop and go rush hour traffic you have no choice but to use the friction brakes frequently... I'd rather not have to explain to my wife or passenger what is going on each time he/she hears a beep...

It only beeps when you screw up and it is pretty muted. I don't find it annoying. Putting it on the display is easy enough, but the thinking was you really should be looking at the road while you are braking. Maybe flashing the display would be noticeable from the corner of the eye...

 

[JeremyW]

It's alive! :mrgreen:

 

[TickTock]

Don't get me wrong, nothing wrong with the visual cue, but it doesn't even chirp in stop and go traffic. I actually made the beep rate proportional to brake pressure *times speed*. This is to make it in units of energy since that is what we really care about (for example you don't burn any energy when stopped regardless of how hard you press on the brake and we don't want it to make any sound). So in stop-and-go traffic you are moving slowly and, although the friction brakes are used, the energy is very small and doesn't break the squelch level - so no sound. I am able to go all the way to work without a chirp if I start below 100% charge although I do encounter quite a bit of traffic both on surface streets and freeway.

In stop and go rush hour traffic you have no choice but to use the friction brakes frequently... I'd rather not have to explain to my wife or passenger what is going on each time he/she hears a beep...

It only beeps when you screw up and it is pretty muted. I don't find it annoying. Putting it on the display is easy enough, but the thinking was you really should be looking at the road while you are braking. Maybe flashing the display would be noticeable from the corner of the eye...

 

[TomT]

OK, that sounds more than reasonable. What is required to modify my version 1.3 unit to add it...

Also, I am a little confused with the different firmware versions that have three or four columns of information on the top row... What is the fourth column and which version is which?

Don't get me wrong, nothing wrong with the visual cue, but it doesn't even chirp in stop and go traffic. I actually made the beep rate proportional to brake pressure *times speed*. This is to make it in units of energy since that is what we really care about (for example you don't burn any energy when stopped regardless of how hard you press on the brake and we don't want it to make any sound). So in stop-and-go traffic you are moving slowly and, although the friction brakes are used, the energy is very small and doesn't break the squelch level - so no sound. I am able to go all the way to work without a chirp if I start below 100% charge although I do encounter quite a bit of traffic both on surface streets and freeway.

 

[GlennD]

There are a lot of compile options so Ver 1.3 can look very different. The box I sent to you has on the top line energy remaining, gid, and enhanced bars. On the bottom line it is voltage, gid %, and instant energy used. This is Lincomatic's current vision.

 

[TickTock]

OK, that sounds more than reasonable. What is required to modify my version 1.3 unit to add it...

Unfortunately, quite a bit. I actually implemented this on Gary's gid-o-meter so my sourcecode would not work as-is on the Linocmatic but shouldn't be too hard to migrate since the microcontroller is the same. You would also have to attach a (cheap) piezoelectric disc to one of the output ports (hardware mod) to get sound. One of the challenges is the brake pressure message is sent on the carcan bus - not the evcan bus. So with a single channel processor (like the AVRCAN used by the lincomatic and gid-o-meter) you have to choose either battery information or braking information. If someone ever offers a dual channel meter, you could monitor both simultaneously.
In my implementation, I have three modes, sound off, sound hi, and sound lo. The hi and low setting don't really affect the volume, but rather the squelch threshold (it is very hard not to at least get a single chirp in the hi-sensitivity mode). I also have the display show an integer proportional to the amount of braking energy (technically power) whenever the brake is pressed so you can watch it in the sound_off mode. While the brake pedal is not pressed it displays a "score" (% of total braking force accomplished with regen for the current trip). I find it difficult to score much over 90%.

I made a crummy video demonstrating the operation here: hard to hear the chirp over the turn signal but I have two examples - one for light braking (no chirp) and one for moderate braking (high level of chirping).
http://www.youtube.com/watch?v=KL9kva1DNg8
Looking at the video again, I realize that this was taken on an earlier version - before I added the score feature so it always display friction braking power (zero when foot is off the brake).

 

[garygid]

I am working on an Mbed-based GID-Meter and Black-Box combination.

It reads two CAN buses simultaneously, so it is intended to read,
Log, and display from BOTH the EV and the CAR CAN buses.

Initial testing and development is encouraging.

Aso, one will be able to update the firmware with just a
Copy and Paste, no special hardware or software required.

Plug in an SDHC card or flash drive to the USB port, and it
records CAN-Do compatible ".alc" files each time the car
is operated.

It can also do real-time logging via a Mini-USB port to my
CAN-Do program running on a Windows PC.

 

[TomT]

Yeah, it sounds like more work than it would be worth, but thanks for the info nonetheless!

OK, that sounds more than reasonable. What is required to modify my version 1.3 unit to add it...

Unfortunately, quite a bit.

 

[TomT]

OK, thanks Glenn! I haven't yet actually looked at the source code. I assume that the "Mini USB AVR JTAG Programmer Debugger for AVR ATMEGA" that I got for my Gid meter is not suitable for reprogramming the Lincomatic version?

There are a lot of compile options so Ver 1.3 can look very different. The box I sent to you has on the top line energy remaining, gid, and enhanced bars. On the bottom line it is voltage, gid %, and instant energy used. This is Lincomatic's current vision.

 

[GlennD]

The lincomatic projects use a USBTiny ISP programmer available from ADAfruit or a Chinese clone for much less but no support. I started with the Adafruit unit but bought an exact surface mount copy from San Diego for $12 shipped. I thought there was a problem but it was a setup error. Since I did not need 2 programmers I sold one here.

If you get a programmer make sure it comes with a 6 and 10 pin cable. The proto board I used came with a 10 pin connector. 6 pin connectors are more common.

 

[TomT]

Yeah, Ebay has a couple for 10 bucks including shipping. One has both cables and the other just a six...

http://www.ebay.com/sch/i.html?_trksid=p5197.m570.l1313&_nkw=USBTiny+ISP+programmer&_sacat=0&_from=R40" onclick="window.open(this.href);return false;

The lincomatic projects use a USBTiny ISP programmer available from ADAfruit or a Chinese clone for much less but no support. I started with the Adafruit unit but bought an exact surface mount copy from San Diego for $12 shipped. I thought there was a problem but it was a setup error. Since I did not need 2 programmers I sold one here.
If you get a programmer make sure it comes with a 6 and 10 pin cable. The proto board I used came with a 10 pin connector. 6 pin connectors are more common.

 

[garygid]

Some of these ship from China, and might take a long
time to get here.

 

[GlennD]

I buy stuff from China all the time. It usually takes 10 days. The longest was 3 weeks. The prices are really amazing!

That said the one from San Diego took 2 days to receive and was only a couple of dollars more.

 

[GlennD]

I ordered a China obdII connector from Ebay for $3.49 shipped. It has a straight through hood that I will not use. It is of the kind where the pins are loose and held in place by a tiny PCB. The quality is acceptable, partially if you need a straight hood. For SOC use a right angle is preferred. For the price it is a great deal but i like the Sparkfan connector better.

 

[JeremyW]

Any chance of a 3d printed case avalible for sale?

 

[Deleted member 3147]

I'm trying to figure out what version I got on my board from chris1howell.

I have 4 values on the top row but the bottom row has volts, %GIDs and (fast changing) instant KW. It sounds like I got the buggy test version. Can someone please confirm?

Thanks

 

[TomT]

It looks like the third number on the top might be percent SOC... I'd kind of like to have that one actually...

I've noted a few oddities myself (I have the 1.3 version with three values on the top line):

I have noted a couple of oddities in the displayed data. The percent Gids seems to be about right at higher Gids (an 80% charge with 200 Gids shows 80% Gids which seems correct - though with my battery loss this percentage may be high as well) but as the Gids drop, the Gid percentage seems to be increasingly higher than it should be. 60 Gids, for example, shows about 36% which is well above what the percentage should be for that charge level...

Another oddity - though perhaps just I don't understand how it is supposed to work - is the extended fuel bars. At 100% charge it only shows about 10.2 bars rather than closer to 12... As the SOC drops, it becomes closer and closer to tracking the actual dash fuel bars and is dead on at the point the last bar goes away. It would also be nice if it showed the fuel bars as including the hidden reserve below the last dash bar but perhaps that data does not exist...

The last oddity - and I suspect this is related to the inherent inaccuracies in the Hall Effect sensor for the battery pack - is that the value shown for the pack Kw in/out always appears to be slightly negative at rest. In other words, when the car is on, but not moving, it shows a slight charge rather than a slight discharge... Anywhere from 0 to minus about 300 watts. The value is very noisey and jumps around a lot but is almost always negative.

I am also going to see about adding a dimmer circuit for night since it is pretty bright... A photo transistor and a couple resistors should do it.

I'm trying to figure out what version I got on my board from chris1howell.
I have 4 values on the top row but the bottom row has volts, %GIDs and (fast changing) instant KW. It sounds like I got the buggy test version. Can someone please confirm?
Thanks

 

[Deleted member 3147]

It looks like the third number on the top might be percent SOC... I'd kind of like to have that one actually...

I've noted a few oddities myself (I have the 1.3 version with three values on the top line):

I have noted a couple of oddities in the displayed data. The percent Gids seems to be about right at higher Gids (an 80% charge with 200 Gids shows 80% Gids which seems correct - though with my battery loss this percentage may be high as well) but as the Gids drop, the Gid percentage seems to be increasingly higher than it should be. 60 Gids, for example, shows about 36% which is well above what the percentage should be for that charge level...

Another oddity - though perhaps just I don't understand how it is supposed to work - is the extended fuel bars. At 100% charge it only shows about 10.2 bars rather than closer to 12... As the SOC drops, it becomes closer and closer to tracking the actual dash fuel bars and is dead on at the point the last bar goes away. It would also be nice if it showed the fuel bars as including the hidden reserve below the last dash bar but perhaps that data does not exist...

The last oddity - and I suspect this is related to the inherent inaccuracies in the Hall Effect sensor for the battery pack - is that the value shown for the pack Kw in/out always appears to be slightly negative at rest. In other words, when the car is on, but not moving, it shows a slight charge rather than a slight discharge... Anywhere from 0 to minus about 300 watts. The value is very noisey and jumps around a lot but is almost always negative.

I am also going to see about adding a dimmer circuit for night since it is pretty bright... A photo transistor and a couple resistors should do it.

I'm trying to figure out what version I got on my board from chris1howell.
I have 4 values on the top row but the bottom row has volts, %GIDs and (fast changing) instant KW. It sounds like I got the buggy test version. Can someone please confirm?
Thanks

Also, you noted your "extended fuel bars" having a value for 10.2 at full charge. Are you talking about the right-most value on the top row? Mine shows "12" at full charge but integer only. Sounds like the real version shows 10ths too.

It really sounds like mine came with the test version of code, even tough it was sent out after the discovery that he burned the wrong version. I guess I'll need to buy a programmer. (sigh)

 

[Deleted member 3147]

Further reading at Github, it looks like I do have 1.3, but with the option for the 55B SOC set.

Question: looking at Github, I see the precompiled HEX file but no sources. Where are the sources such that we can recompile with other options? I am an experienced embedded software engineer, but I have not worked with the Adurino-class devices.

Thanks

 

[TomT]

Yes, my extended fuel bars on the extreme right, top have three digits... I read that they actually go to 13 on my version (why I don't know) which may partly explain my extended bars being low at the higher SOCs... I think I'd be happier with a number of bars that matches the one in the car at the top but with increased precision and a range that went all the way to turtle... This may not actually be possible however since I don't know if that data is on the CAN buss...

I need to get a programmer too so that I can customize the software... I haven't had a chance yet to see what one needs to compile the firmware...

Also, you noted your "extended fuel bars" having a value for 10.2 at full charge. Are you talking about the right-most value on the top row? Mine shows "12" at full charge but integer only. Sounds like the real version shows 10ths too.

It really sounds like mine came with the test version of code, even tough it was sent out after the discovery that he burned the wrong version. I guess I'll need to buy a programmer. (sigh)