Calling Budgie - Trip Meter

we

it.

when

Thanks for that.

It should give me a few more avenues of exploration... :)

Regards

Steve

Geez, that design was back in the days of four-bit microprocessors. In fact, we gutted some NatSemi four-function calculators and fed the pickup pulses via D-flip-flops (for direction sense/steering) to the +/- key inputs. I wouldn't do that again,even if you had the fossils\\\\\\\\\\\\\\\\bits available.

The next (and last) design was all 7400 glue logic - again not the way to do it. I'd suggest a decent micro. The only tricky bit (in hardware, and I guess in software too) was in determining direction. Needs a "quadrature" approach as you obviously can't determine direction from a single pulse stream. Apartf rom that, I don't have any doco or recoreds of that stuff - that was waaay back when I was single.

The above is all I can really offer.

we

it.

when

we

it.

rom

when

That's really a design decision you have to be happy with. I wanted the F/R pulse streams to be automagically steered to the +/- counter inputs, but if you're comfortable with a mug\\\\\\\\navigator-driven F/R switch then go that way as it is a tad simpler.

Bear in mind that two close-spaced pickups will give you direction info.

You need to replicate *two* counters in your machine. What the max-count is depends on what you are storing - metres, pulses_before_conversion, etc. But certainly don't go with a device that is on its limit.

Likewise, and you're welcome.

fact, we

wouldn't

do it.

in

as

rom

when

as

I'm on a bike - no reverse gear. Things will be going horribly wrong of the front wheel starts turning backwards :) Hence I need the switch.

Two counters? One for the input pulse and one for the distance? I'm thinking of only storing the meters in units of 10 metres The formula I have does this for me. Hence 1.43 km reads as 143 in the memory. Someone on the sci.electronics.basics forum suggested coutning a certain distance and then resetting the count, letting the LED display cascade the value as each small amount is added. Still trying to understand how to make this work programatically, but I think I'm getting closer.

Regards

Steve

(snips)

as

I see where you are coming from now ;-)

That's really processing the overflow into another form of counter to extend the count capability.

Apart from your pulse divider processing, normal practice is to use two registers/counters. One is for cumulative distance within a stage, the other the increment from the last instruction. The latter is obviously more accurate in locating the next instruction, but you need the cumulative to know how far you've done in the stage.

Back in the olde (pre-TerraTrip) days, the Halda units came in two basic flavours - Tripmaster (single counter) and TwinMaster (two counters). Having used a Twin, my approach to designing the electronic unit was very much biased towards the benefits of two counters. I would feel like I had lost an arm if I only had one counter. You may feel differently of course.

store 1,4,3 in memory not 143.

or don't store the number in memory use a display chip (or collection of chips) that does the counting.

any microcontroller with sufficient pins to interface with your hardware will likely have no problems keeping up with the tasks you need to do, especially if you arrange them so that you don'y need to do any division or multplication.

C pseudocode:

#include int16_t pulses_per_km=1432; // determined experimentally

int16_t scale_factor=1000; // what to divide kilometer by: 1000 for output in metres... void pulse_isr() // interrupt called when a pulse arrives { static int_16_t accum=0;

accum+=scale_factor; // if you can be sure that scale_factor = pulses_per_km) { accum -= pulses_per_km; moved_a_metre(); } }

where moved_a_metre() updates the display registers by adding or subtracting (depending on the direction) and propogating the carries...

output in metres may be excessive, but units of 10m may be useful, possibly as a bargraph?

you can scale to that by changing the 1000 to 100 or by dividing by 10 in the moved_a_metre code....

way as

But

the

I know what you mean. When I first started rallying with a mate in the car we had an old Halda Twinmaster with a complete set of gears too. We soon switched to a terratrip. At this stage I'm looking to jsut set up one counter and then when it works I'll either modify or duplicate it for cumulative distance (can still use the bike odo for cumulative, but it lacks the resolution needed for intermediate distances (0.01 km).

I've been doing some tarmac stuff lately and even got to navigatefor a former US champion (Jeff Zwart, absolute gentleman). Ultimately I'm trying to do exactly what you already did, but without the elecronics background.

Regards

Steve

If I used a PICAXE 18X I have something like 14 bits to play with in memory. If I can work the count so that it moves over say 9 of the bits I could count up to 10 million pulses.

I new there was a reason I did mech and not elec. :)

ATM this value is about 3,126 assuming a 24 inch wheel diameter (don't ask why in inches when I should be using mm or m). I have 6 studs holding the front disc, giving 6 pulses per rotation.

Man, C can go over my had sometimes (most of the time).

Can you email me offline?

Regards

Steve