Mindboards

Hi everyone, new here to the forum. Hopefully I'll be a positive addition
I've been tinkering with the idea of making a fuel efficiency gauge for my old car (1968 firebird if you'd like to know) with my NXT. It will compare data from a flow sensor inline with the fuel line to rpm data from an NXT motor inline with the speedometer cable. I'd like to have it give a running average every second if possible. I went ahead and bought a flow sensor from adafruit ( here's the link if you'd like to see: https://www.adafruit.com/products/828 ) and luckily it seems to work great hacked together with a spare sensor cable. I have made a little program that counts up the number of pulses coming from the sensor (each pulse is approx. 2.25 ml btw) so it shows promise. I also found a program online someone had made for an rpm gauge. So what I'm struggling with is how to put the two together. I will have the NXT motor reading revs per minute (or per second), which with some math (knowing gear ratios in the transmission, rear axle, and tire diameter) can become miles per second, and have the flow sensor reading pulses per minute (or second), which with a little math becomes ml, liters, or gallons.
Despite my efforts, I haven't quite figured out how to
1. count pulses per second from the flow sensor
and 2. divide my revs per second data by my pulses per second data to ultimately achieve miles per gallon. Then of course have it give me an updated running average displayed on the screen every second or so.

Does this seem feasible, practical, sane? Any fatal flaws? I'd love some input and help, I might be being a little overambitious here.

Thanks!
-Matt

Hey, cool project!

Take a look at this. It's a way for the NXT to read frequency (like the pulse from the flow sensor). Actually, I would revise the program so that it's absolute instead of relative, and I would then use an offset to determine relative speed if necessary (instead of resetting the tacho count).

How is the speedo setup in that car? Is it mechanical (implied, but not explicitly defined), or is it electrical (pulses)? The speedo should be connected at the output of the tranny, or at the differential, so the gear doesn't make a difference. If it is mechanical, I would use a rotation sensor instead of an NXT motor. An NXT motor will introduce a significant mechanical resistance compared to a rotation sensor (harder on the speedo drive).

Since you probably don't know the exact gear ratio between the speedo drive and the tire, here is how I would measure it. Connect the rotation sensor to the cable, and record how many degrees it spins when you push or drive the car X distance (if you drive it, no burn-outs ). For example, if the speedo cable spins around 27.3 times when the car moves 100 feet, you can calculate how many times it spins per mile, which in this example would be 1,441.44 rotations. So, you don't really want the speed, you want an odometer.

If you want miles per gallon (I'll go with SAE gallon), then you can calculate it using something like this:

Gallons since last reading = (pulses * 2.25lm) / 3785.41178ml
Miles since last reading = rotations / 1441.44
MPG = Miles since last reading / Gallons since last reading

Floating point math isn't as accurate as integer math, and so due to such small numbers, from dividing by huge amounts, I recommend doing the math in something like ml per mile, or OZ. per mile, or something smaller than a gallon, (and maybe something smaller than a mile). You can always calculate MPG based on that, and then the results will be more accurate.

Also, I would recommend experimenting with different update rates. The longer time window allowed to take the readings (longer measurement intervals), the more accurate the readings. 2.25ml precision probably won't be good enough to update every second, unless you keep the throttle wide open

BTW, be sure to keep us informed, and please post pictures of the final setup

Thanks for the help! I've actually been programming in nxt-g (I know, I know, embarrassing) so I don't know a whole lot of what you're talking about It seems like NXC, which is the language I assume you're using, gives you a lot more to work with as far as programming options so I think I'll start reading up on that.
Thanks for the frequency reader idea. I did think of using an encoder wheel that wasn't part of an NXT motor considering the huge drag an nxt motor has, but decided against it considering I didn't know how quickly the nxt can count pulses and I didn't want to try to recalibrate it to work with a different encoder wheel. Your freq reader would make it much easier to do that though.
The speedometer is mechanical, and there is a speedometer gear output at the rear of the transmission, so I plan on hooking up my encoder there where I can use the same method you described. I'm trying to make it as accurate as possible, so I'm thinking I'd have it update more like every five to ten seconds or so. I'm not worried about the accuracy of the distance as much as I am the flow rate. The distance should be pretty accurate depending on the rpm of the speedo cable (which should be pretty high I think) per mile, so there is a lot of clarity there. The flow sensor however is only reported as about 10% precision, so I'm a bit worried about its accuracy. Having it measuring smaller amounts over a larger length of time should help though right? Anyway thanks for the help, now I'm going to start reading up on NXC

Using NXT-G isn't embarrassing (even if the SW itself is ). It's great for people who are getting started with programming. I used it for about a year before moving on (and have never looked back ).

You can do this project with NXT-G, but NXC is certainly more flexible. If you want to download BricxCC and NXC, you can do so here: BrixcCC. Once you have it installed, I recommend installing the latest test release over it. Once you have done that, I would also recommend that you update your NXT's FW to the latest enhanced version (included in the test release of BCC). Included are some documentation files, and the one called "NXC_tutorial" is a great place to start learning NXC.

As far as using a different encoder, take a look at the speed calculations I made at the bottom of that article I linked to (last two paragraphs). The NXT FW's tacho count is setup assuming you're using a 1 degree precision encoder. However, it really just measures the logic transitions (every-other change), so it doesn't matter the encoder resolution. Just recently, I've been using a mechanical encoder with 48 "degrees" per rotation. The NXT has built-in debounce circuitry, so mechanical, magnetic, optic, or simulated encoders should all work fine.

I don't think I really explained in the last reply why I linked to that article. I think it would provide a good way to measure the pulses from the flow sensor. The NXT motor port encoder inputs expect quadrature input, and the flow sensor only outputs a single pulse. The circuit with the 4017 and four diodes would convert that pulse into a quadrature signal. For reading an encoder connected to the speedo cable, you just need to physically connect the encoder to the NXT motor port, and then read the tacho count (no special circuitry, and no special software).

I'm a bit confused. How does the resolution of the encoder wheel make no difference? Could you explain that a little further? If I have an optical encoder wheel with 24 "ons" and 24 "offs" per rotation where as the encoder wheel in the NXT motor has 12 "ons" and 12 "offs" per rotation the nxt would think the new encoder is spinning twice as fast as it really is right? Would I just have to account for that in the program? Also, I think I'm starting to get what you're saying about the quadrature signal for the nxt motor input. I need a quadrature "translator" to work with a motor port. It would allow for much higher frequencies to be measured from the flow sensor, but I wouldn't be working with frequencies too high for a sensor input to measure on the flow sensor end would I? What if I just used a sensor input port? Then I can just have it set up like the standard touch sensor right? That's how I have it set up currently and it seems to count the pulses correctly and quickly enough. Thanks again for the help, sorry if I'm a pain!

Right. You just need the program to match the physical encoder (only a difference in the math).

You could connect the pulse sensor to a sensor port, but then you would need to constantly poll the value, so that you don't skip a pulse. If you used the encoder inputs, the FW would take care of reading it, so you wouldn't skip any. The FW updates the analog readings at about 300Hz.

Having it as a touch sensor should work fine. The NXT has a built in 10k pullup resistor connected to the analog line, so you might need to buffer the input from the sensor (I'm not sure how the sensor is set up).

You're welcome, and certainly not a pain Be sure to ask any other questions you might have