MPGuino release one workspace

[awillard69]

Good news, bad news.

I got my board all assembled, all my hookups for the display and buttons, and it looks good.

However, I can't seem to interface it via serial to any PC. My main workstation is Ubuntu 8.04, but also tested on WinXP. On Linux, I get "programmer is not responding", on Windows, I get some "not in sync" message.

Nothing in the troubleshooting seems to help me. Any ideas? Any quick "check this" tips?

Basically, I have the power light on, and the #13 led blinking away about every 2-3 seconds. The 7805 is getting warm (11v input), but nothing else is hot. I don't have any solder bridges that I can tell. I need to know how to tell if maybe I have a dud board or something else.

[dcb]

the 7805 should not be even warm. I don't know if that is a clue. Were you able to run blinky without the buttons and lcd attached?

Also, the serial board (and/or my choice in pins) doesn't like to load with everything powered, I have to disconnect the power to the lcd/component board when I upload (pull off orange wire circled in red in bottom picture below). The usb one doesn't exibit this behavior for some yet unexplained reason.

[Nerys]

Depending on the car has anyone thought of a way to insure equal fills of the tank? I have a few ideas.

One is to drill a hole in the side of the tank and install your own little float level thingy rigged to an LED when it lights you at "that point" in the fill.

OR if the room permits it better IN the neck of the fill tube.

You could always fill it till a tiny bit of gas comes out the tube :-) hehe that will get you to within a few ml or so easily enough.

A less complicated but messier way is to get a kerosene squeeze pump.

Fill your tank to the say second click. Now shove the pump in there and suck (pump)

Pour the gas back in and keep shortening that pump feed till it can JUST barely take gas out of the tank and then you suck air. There you right at the top of the fuel pool. (always park in the exact same spot when you do this)

NOW each time you fill purposely overfill. When you get home use your calibrated sucker to suck all the fuel it can get out. Bingo your now at precisely (for our purposes) the same amount of fuel as the last time you did this. Now reset your gizmo.

Measure the fuel you sucked out and subtract that from the amount you put in.

You guys also have another problem. The pumps themselves can be QUITE a bit off in how much gas they actually PUT in your car. as much as 5% off !! (reporting too much or too little) Thats gonna really mess with your numbers.

There is only one way I know of to handle this. Fuel Cells. not the rip off hydrogen variety but like they use in racing cars. Its basically a small durable TANK. Instead of using your gasoline tank you use your FUEL cell and now you can determine "precisely" how much fuel is in the tank and precisely how much you have to add etc..

go with 5 gallon tank and its easy to measure and control and enough to let you go 100-200 miles depending on your car.

This is not for everyone. this would be for people "testing" this thing IE to get it calibrated.

Just some ideas. I am not likely to ever have one of these (my soldering skills suck) maybe when I can get one of these boards preassembled. It looks like I could handle most of the soldering except the duino board. :-)

[mosier]

Didn't have much chance to do testing today. The only thing I remember from today, is in current trip, my MG would increase by 15 every second until it hit 360 i think, then would roll over to around 180, and go back up, but at a slower rate. I noticed a few things in the code though..

unsigned long Trip::mph(){
//  if(seconds<2) //i.e. instant
//    return vssPulsesPerMile*10000/(currentVSS*36);
  if(vssPulses<1000)
    return (vssPulses*3600000)/(vssPulsesPerMile*seconds);
  return (vssPulses*3600)/(vssPulsesPerMile*seconds/1000);
}

both returns return the same value, unless I'm completely going about it the wrong way. The 1000 in the second return is the same as just multiplying the (vssPulses*3600) by 1000..

Same goes with the

unsigned long  Trip::gallons(){
  if(injHiSec<4000) //will overflow here
    return ((injHiSec*1000000) + injHius)/(microSecondsPerGallon/1000);
  else  
      return ((injHiSec*1000))/(microSecondsPerGallon/1000000);
}

other than adding in injHius, i'm pretty sure it's the same thing. I don't think it is behaving as intended..

I added my car to the garage. It's a 95 Saturn SL1, 5spd.

Currently i'm using 9980 as my vss calibration, although I should probably just change it to 10000 as per dcb's find of the factory spec (x2).

For the injector constant, I'm using 296052632. I believe this should be a good starting point for my car. I figured it using:

19lb/h injectors, 6.25 lbs per gallon of gas.

((60 minutes * 60 seconds * 10^6 microseconds) / (19/6.25) )/4 injectors

or you can just divide 22,500,000,000 by injector lbs per hour, and then divide by number of injectors. I guess we'll find out if the math is close or not..

[Mr. Cheap]

I'm testing with a 89 Caravan 2.5 TBI. I'm getting sensible data with 15500 pulses per mile and 72.5 seconds per gallon.

My board also has intermittent serial operation and intermittent loading. This is a serial v1.0 board. I also bought a serial v2.0 board which I will build when I get time. The v2.0 is claimed to have more reliable serial communications.

I forgot the 10k resistors when I built my board. I didn't see the line that said to install them. The board blinked but didn't respond to serial programming.

[dcb]

Originally Posted by mosier

unsigned long Trip::mph(){
//  if(seconds<2) //i.e. instant
//    return vssPulsesPerMile*10000/(currentVSS*36);
  if(vssPulses<1000)
    return (vssPulses*3600000)/(vssPulsesPerMile*seconds);
  return (vssPulses*3600)/(vssPulsesPerMile*seconds/1000);
}

both returns return the same value, unless I'm completely going about it the wrong way. The 1000 in the second return is the same as just multiplying the (vssPulses*3600) by 1000..

It's a little tricky, it is a 32 bit integer number and scaling thing. The largest number we can can represent is 2^32, or a little over 4 billion. The general rule of thumb with integer math (as far as I know) is to do your multiplications in the numerator first and then the divisions. i.e. If I wanted 2*3/2, and I did the (3/2) first, the answer would be 2, but if I do the (2*3) first, I get the correct answer, 3.

As long as vssPulses is less than 1000, we are safe to multiply it by 3600000 without overflow, as it will be less than 4 billion, and we don't lose any resolution in the deniminator.

if vssPulses is greater than 1000, we have to scale down the equation so the numerator doesn't overflow. We can also better afford to scale down the denominator since we *should* have a larger number there, but it isn't perfect. There are some intermediate values there that could close the gap, or a modification that predicts how much to multiply the numerator and/or divide the denominator by to preserve accuracy and prevent overflow.

We are here because the 64 bit libraries are huge. I suppose we could just go look and see how they do it too

[dcb]

Originally Posted by Mr. Cheap

I'm testing with a 89 Caravan 2.5 TBI. I'm getting sensible data with 15500 pulses per mile and 72.5 seconds per gallon.

Nice You probably have 8000 pulses/mile (16000 vssPulsesPerMile) per the specs.

[mosier]

Originally Posted by dcb

It's a little tricky, it is a 32 bit integer number and scaling thing.

Oops, yeah, I just now ran through it, using 60mph as an example, and things got huge fast.. i was hoping i could edit some of that out before anyone replied

[awillard69]

Originally Posted by Mr. Cheap

My board also has intermittent serial operation and intermittent loading. This is a serial v1.0 board. I also bought a serial v2.0 board which I will build when I get time. The v2.0 is claimed to have more reliable serial communications.

I forgot the 10k resistors when I built my board. I didn't see the line that said to install them. The board blinked but didn't respond to serial programming.

I'm using the v2.0 serial board and installed all the items, and have no spare parts.

My board is blinking, but won't respond. What did you do to get communications?

DCB: my 7805 is warm because my only input is 11v, so it's working a bit harder to bring it down to 5v. Check out yours when powered up with car power, that will be pushing almost 13v, so yours will get warm, too. I'll have to poke around with my DVM to check the inputs and outputs. But, I think my prob is identical to Mr. Cheap's.

[Yoshi]

Hello from Japan,
I'm an author of the unfamous SuperMID.
SuperMID portal
Prius DIY
SuperMID M-1
My project is open hardware and open binary software.
The program is written in AVR assembler and my source is very dirty now, so it is not open-source yet.
However, you can dis-assemble my binary (intel hex file), then you'll be able create the assembler source.

Anyway, let me explain how I built it.

* interface
I place an interface box for injector and VSS signals as close as the ECU, because I don't want to pass noises to 5V logic part.
The Prius VSS signal is very clean, but we'll need some filter circuit to clean up the mechanical chattering used on some vehicles.

* signal capture
- VSS signal
I use INT1 falling edge interrupt.
Prius, Honda and others, VSS specification is 637*4=2548 pulses per km, or 4100 pulses per mile.
I would like to get 10 meter increment of distance, so I need 25.48 pulses per 10m.
I use 16bit register and add some distance parameter on every interrupt, then increment 10m counter when 16bit(65536) number overflows.
The some distance paramter is 65536/25.48=2572.
I assign 18bits for the 10m counter, so the max trip distance is 2621.43 km.

- injector signal
There is a very good feature in the ATmega8(ATmega168 as well) called "input capture" using pin#14 and 16bit timer1.
The rising edge trigger is detected by INT0, then clear the timer1.
The timer1 is driven by 1/64 of clock (12.8MHz), so the unit is 5 usec.
As soon as the injector pulse goes low, the timer1 count is stored in a register.
There are some mechanical delay of injector, so I assume it is 500usec, then the pulse count - 100 becomes the effective pulse width for proportional to real fuel usage.
I would like to get 1 cc (milli-liter) count, so I set some fuel parameter for that.
After a lot of experiments, I found the accumulated timer1 value becomes 14052 (fuel parameter) Prius shows 1 cc usage.
I assign 16bit for the 1cc counter, so the max trip fuel usage is 65.535liter.

That's all as of today.

Regards,
Yoshi