Oddity with GPS Speedo Project ...

Hello enthusiasts,
I am attempting to make a GPS speedometer as a replacement for a defective and unobtainable unit in an older model but very faithful work ute. Although my grasp of programming is improving I must admit that it is not my strongest asset so the below code has been primarily scavenged from other posts on the web. Those sources have been acknowledged where possible at the beginning of the sketch.
Hardware is fairly basic, utilizing a 3v3 - 8MHz 328 Pro Mini, a ublox neo 6 gps module, 5110 lcd all powered by a 1 Amp 3V3 regulator feeding from the vehicles battery. I have chosen to use Nokia 5110 8448 lcd mainly because of cost and its ability to display a reasonably large font and not the least, it also runs on 3v3. This kept the project ‘clean’ without the need for dual regulators and/or level convertor circuitry cluttering the build. The prototype has been built on veroboard and mounted in a little plastic hobby box. I also added ldr control of the lcd back lighting to eliminate the need to find and splice into the ute’s instrument lighting wiring. I could be take some pics and scratch up a schematic if any interest is shown but it is fairly straight forward to build and all required info is already out there if you Google it
Whilst there are many excellent 1602 lcd gps builds and some beauties using little high res. oled gps examples on the web, the displayed reading is too small for practical automotive applications, there seemed to be very few ‘speedometer specific’ variations that I could find. HUD is all the rage nowadays!
The attached sketch and the hardware are at the testing stage now and I am happy with progress so far.
However I suspect an error in my code is causing a problem with my displayed speed.
everything is fine up to 99 km/h after which the tens digit ‘scrambles’ or ‘pixelates’? upon the appearance of the hundreds digit. I suspect this section below is the crook bit …

void setSpd(int num)
{
    byte c = num / 100;
    if (c > 0) setBigNum(c, 0, 0, BLACK);  // Set first digit if needed
    num = num - c * 100;    
       
    c = num / 10;                          
    setBigNum(c, 23, 0, BLACK);            // Set second digit 
    c = num % 10; 
    setBigNum(c, 46, 0, BLACK);            // Set third digit
    
    }

Apart from the above fault, the sketch compiles and runs well but I would really appreciate it if someone would have a look at the entire sketch and make any suggestions for improvement.
Thanks for taking time to read my post.

GPS_5110_lcd_speedo.ino (25.8 KB)

Well, I don't see a problem with your code right off. Your problem could be elsewhere though, I would hard code it to show a "1" as the hundreds digit to make sure it will show that correctly. Next I'd try to determine if the speed value coming in to the fn is stable. If that is changing rapidly it can look pretty funny on the lcd. I might also change the code around to see if that changes the symptoms. Try an if statement to see if the speed is greater or equal to 100 but less than 200 and use that to turn on the first digit.

Try to eliminate possible sources of the problem to narrow it down some. Your problem could be in the data coming in, in your code splitting up the digits, the code feeding the numbers to the lcd or even the lcd hardware itself.

Sounds like a cool project, I've driven cars without working speedometers in the past and found it frustrating. I've also driven cars with inaccurate speedometers due to tire changes. Your speedometer will be accurate so long as you have a good gps lock.

Thank you very much for your response walterr, I am pretty sure that the integrity of the 'lock' is not the problem with 9 or 10 satellites along with the correct time being displayed. Accuracy also appears to be very good, given the expected lag such systems inherently exhibit. The LCD hardware also appears to be OK as the same hardware works faultlessly when programmed with Tom Kuehn's SailLogV1 sketch referred to at top of my sketch, but not many sailing vessels attain 100km/h. XD It may be that where I have altered the code to display km/h (instead of knots) has been incorrectly implemented? Can anyone suggest a debugging routine that would allow bench simulation of an over 100km/h condition, as opposed to driving out of town to attain a 100+km/h condition to test my code alterations? I would like to explore further your suggestion with regard to 'hard coding' the hundreds digit but will require further coaching as this beyond my capability. I feel that this area of the sketch is the cause of my problem, the corruption to the tens digit cannot be construed as rapidly changing and immediately recovers from this condition as I decelerate to 99km/h and below. The display of speeds up to 99 is very smooth and legible. It could also be that the 'if' statement that keeps the hundreds digit blank until one hundred km/h is attained is the problem? Is there any possibility that such a condition might be caused by a crash of SRAM when being called upon to display three big fonts simultaneously? I dunno, clutching at straws, so near and yet so far! Anyway, thank you once again for your suggestions, walterr. Further comment is very welcome.

Hello again,
I think I have solved my problem by modifying the section of code referred to in my first post to:

void setSpd(int num)
{
    byte c = num / 100;
    (c > 0) ; setBigNum(c, 0, 0, BLACK);  // Set first digit 
    num = num - c * 100;    
    c = num / 10;                          
    setBigNum(c, 23, 0, BLACK);            // Set second digit 
        c = num % 10; 
    setBigNum(c, 46, 0, BLACK);            // Set third digit
}

But now I need help to dissect the following AnalogRead function

// Reading battery voltage. Vin is sampled using a 10k / 47k resistor divider
  bat = analogRead(batteryPin) * 613L / 1000L;
  sprintf(buf, "%i", int(bat));          
  setStr(buf, 0, 40, BLACK);            // Display battery voltage in mV
  updateDisplay();

This will allow me to make the required alterations for monitoring the car battery voltage in lieu of the lipo battery that it was previously monitoring. I am using R1/R2 values of 1k8 and 6k8 respectively. The 1k8 to GND, the 6k8 to 12v car battery and the junction of the two going to the A2 pin.
I have removed the heading feature that was in Tom’s original sketch that was using ‘smallNumbers’ (refer sketch).
It would be great if I could utilize these larger font smallNumbers to display the time into the location previously occupied by the heading display and remove the existing small clock altogether.
I have attached the amended sketch and look forward to any advice or assistance… almost there!
Thanks again.

GPS_5110_lcd_speedo2.ino (25.8 KB)