Tacho options for a petrol dash?

[CJH]

My Nano breakout boards arrived today, so I made a little bracket to mount one on above the right-hand pod. This makes it easily accessible for updating, and leaves the left-hand pod free to mount the GPS module on later, where it should get a decent signal through the windscreen.



The real-time clock is taped to the pod, on the right in that photo, but it interfered with the the master cylinder so I had to move it. I've powered the Nano from the ignition, rather than the permanent clock supply, because I measured about 35mA draw from just the Nano and the clock display, which would be a significant draw over a couple of weeks. With the battery-backed real-time clock it doesn't need to be powered all the time - it just fetches the current time from the RTC module whenever it powers up. The OEM clock draws only around 2-4mA - 2mA between ticks, and 4mA when moving the second hand!

The stubby little 4-way connector is where the screen connects - the wires are hidden under the cowling and feed up through the bottom of the dash. I managed to break my little screen during the install, so now I'm using my spare. This one has blue pixels. I definitely need to finish work on the mounting bezel so that I don't break any more.

[Cobra88]

Excellent Work Chris

[bigbadbob76]

Looking good.
Can you write the time to the RTC if you fetch it from the GPS and correct for local time zone?
So you don't have to set it with buttons, or use one button to synch RTC time to GPS time. (+/- zone)
I was thinking you could do without the RTC and just use GPS time, but the time the GPS takes to lock on might be too long.

[CJH]

Yes, if the GPS is powered down when the engine is stopped, then it may well take some time to lock on again, depending on where the van is parked and how long ago it was turned off. I much prefer the approach of using an RTC that's regularly steered by GPS. The RTC is an interesting thing - it doesn't 'intrinsically' know the time, so it needs a program (a 'sketch' in Arduino-speak) to write the time to its memory, but you can't leave that function in the sketch otherwise it will write the same time to memory every time the Arduino is powered. So the procedure is to put a pre-set time onto the software, upload that to the Nano, power it down, wait for that time to arrive and power it back up. That's what puts the correct time into the RTC. Then the sketch needs to have that 'write' line commented out, and re-uploaded. After that the RTC module can actually be completely disconnected from the Nano and stored away, and the button cell will maintain time for a year or more.

So my plan is to update the RTC with GPS time occasionally, and then have the main program simply read the time from the RTC at start-up. Thereafter, the sketch can maintain its own free-running clock for as long as it's powered up, maybe occasionally checking against GPS time, but vans rarely have the ignition on for so long that the clock would start to accumulate an error.

With GPS as the time reference, the only variable that the software needs to worry about is the difference between GMT and the current time, which will be an integer number of hours (0 or 1 in the UK). So a simple interface to set that will be needed. And it's just occurred to me that the Nano will forget that value every time it's powered down, so maybe it needs an SD card reader to store that and other variables. Ho hum.

I looked into the capabilities of the GPS module I have. It's a uBlox NEO-6M, which has the $GPVTG NMEA sentence. That sentence includes speed and heading. This means that the experts at uBlox will have programmed it to calculate a reliable speed regardless of the variability in the accuracy of the individual position fixes, so that will be better than anything I could calculate by looking at rate of change of position. So it should be a nice reliable speed indicator. And the integral of that will give distance covered.

[CJH]

And it's just occurred to me that the Nano will forget that value every time it's powered down, so maybe it needs an SD card reader to store that and other variables. Ho hum.

That's handy - the Nano has 1kB of EEPROM where I can permanently store information. I'll use a button to select an integer GMT offset (between -12 and +14) and I'll use 1 of those 1024 bytes to store the value. I looked up the full list of GMT offsets - there are several half-hour offsets, and even a few 45-minute offsets. They can wait for V2.0

[bigbadbob76]

Now you're digging deep.
I had already ordered the same GPS module and an RTC before you posted that, pure chance but keeps things simple when I steal your code.
I hadn't looked into how to set the time on the RTC, that seems very cumbersome.
how about this- from an arduino site.

There is a second library that comes with the Time library, called DS1307RTC. Once the system time is set, all that is needed is a call to RTC.set():


Code: [Select]

#include <Time.h>
#include <DS1307RTC.h>
#include <Wire.h>
...(get time from GPS)
setTime(hr,min,sec,day,month,yr);
RTC.set(now());




The GPS module claims 27s TTFF when cold which is pretty good.
I'm going to have an LCD clock somewhere on the dash that's always on as when camping we often want to know the time without turning on the ignition.
and possibly a separate trip computer that comes on with ignition.
You have seen the low price of GPS bicycle trip computers there days havn't you?
The down side to them I can see is the automatic backlight.
I'm tempted to order one and cut it open and re-box it in the dash with it's own power supply and the backlight circuit sorted out.
But your device would be programmable for my preferences so I might wait for yours.
Good find on the EEprom, You need to be able to store accumulated time and distance when you stop for fuel/food/pish etc during a trip.

[CJH]

Yes, writing the time to the RTC is easy enough, and with an attached GPS it would be simple to keep the RTC aligned to better than a second all the time. It's only that initial setup, possibly without a GPS, that's cumbersome.

That TTFF of 27s will be under open sky conditions. With an antenna that can only see out of the windscreen, and maybe a bit out of the door windows, visibility won't be as good, and if the van is parked under dense trees, or nose up towards a garage door for instance, then it could be longer. In an underground car park it won't work at all. But uBlox is a good brand so it'll cope well with most situations.

I hadn't looked at cycle computers - where's the challenge in that?!

Good point about storing trip computer data in the EEPROM - that'll have to be done continuously, otherwise there would have to be a shutdown procedure. That's probably feasible though - power it from the permanent clock supply, and if it senses that the IGN supply disappears then it should initiate a shutdown. But regular EEPROM updates will avoid the need for that.

[Cobra88]

fitted my Tacho

had to minor repair blue film pcb but all working apart from RPM (I left green wire off for now till I get board from Chris)

looks much better with digital clock too (I fitted new LCD from BW) as mine was black splodge

Regards
Rick

Need correct steering wheel now as mine had VWH woodrim when I bough the van but not my cup of tea so bought std early wheel for now.

[Cobra88]

Tacho board arrived from Chris today

Took about 15 minutes to fit after an hour to find my soldering iron

Works great
Many thanks Chris & BBB

http://rickpiper.cbfsim.org/images/C88_Tacho.mp4

[Tiny-T3]

Hows the tacho board kit going?

Money burning a hole here
Rick

I'd like one of available with the blue ribbon replacement kit

[CJH]

I'd like one of available with the blue ribbon replacement kit

PM sent.

[bigbadbob76]

I had a play with arduino/gps/lcd today.





I have it showing time (utc or bst depending on a switch position) on the top line and date or speed on the bottom line.

Trip Distance looks like being a difficult one.



Sent from my iPhone using Tapatalk

[CJH]

I have it showing time (utc or bst depending on a switch position) on the top line and date or speed on the bottom line.

Trip Distance looks like being a difficult one.

Good stuff. Is that speed reading from the $GPVTG sentence? Interesting that it's showing 1mph when (presumably) it isn't moving. Is that perhaps because you were indoors where the antenna had a limited view of the sky? Limited visibility and reflected signals will cause that sort of error. Under normal sky view conditions the speed reading will be more accurate than that.

Trip distance should just be the integral of speed (i.e. the sum of speed x time). The key to an accurate distance will be high rate updates. If the update is slow enough that the speed varies within an interval, then the calculated distance for that interval will be wrong.

[bigbadbob76]

Yes, VTG sentence, I was indoors, even outdoors the position drifts around and gives false speed readings, once out on the road it's good.
I could filter the speed or just ignore anything under 2mph.
One thing I've found is that arduino has issues with float or double values when you start doing maths or if/else statements.
I've gone a different route with distance, I've used a function of the Tinygps++ library that calculates distance to a waypoint so used it to store the previous position
every second and calculate distance to that, then sum it with the previous distance so it accumulates.
when I reset distance it stores the new waypoint and zero's the trip distance.
I'll have to look into storing time and distance to non volatile memory.

[CJH]

I've gone a different route with distance, I've used a function of the Tinygps++ library that calculates distance to a waypoint so used it to store the previous position
every second and calculate distance to that, then sum it with the previous distance so it accumulates.

That's a neat approach. There'll be a small error due to inaccuracies in the position. As you've noted, the position jumps around a little bit when you're static, so you'll appear to accumulate distance even when you're not moving. But on the open road the impact of small position errors will be negligible. And if the speed estimate also reflects those small errors in position, then the integral of speed x time will also have a similar error.

I meant to have a go with the GPS module before now, but there's been a bit of a run on the dash PCBs, and when I've not been working on those I've been sidetracked by recording my fuel gauge!