Renault Laguna 3 van bouwjaar 2010 Carminat problem time stamp

Yes Bristolian,
You only need
  1. to have Python Installed (Version 3.12 worked for me)
  2. to adapt the path ('/Volumes/TOMTOMDISK/PNDNavigator') to your own case each time needed in the python script
 
Yes Bristolian,
You only need
  1. to have Python Installed (Version 3.12 worked for me)
  2. to adapt the path ('/Volumes/TOMTOMDISK/PNDNavigator') to your own case each time needed in the python script
Thank you - I'll give it a whirl later.
 
Hello MacPat , I'm facing the problem --:-- with an original SDCard, I'm not able to find the PNDNavigator even after mounting -o loop the ext3 file located in loopdir

Any other suggestion? thanks again


fausto@fausto-HP-EliteBook-2530p:/media/fausto/tomtom$ find
.
./itn
./itn/temporary.iti
./LoquendoTTS
./LoquendoTTS/lib
./LoquendoTTS/lib/LoqAudioBoard.so
./LoquendoTTS/bin
./LoquendoTTS/bin/LTTS7AudioBoard.so
./LoquendoTTS/default7.session
./photos
./photos/thumbs.dat
./CurrentMap.dat
./lost+found
find: ‘./lost+found’: Permesso negato
./ttgo.bif
./Italia
./Italia/DeletedPoi.local
./Italia/MapSettings.cfg
./Italia/MapUserPatch.dat
./statdata
./statdata/allowtrip.dat
./art
./art/cars
./art/cars/thumbs.dat
./UserPatch.dat
 
Can the Python workaround be done under Windows too if needed?
Maybe it can. As I said, I've used Claude . ai to get to this solution. I think if you paste the python part to Claude, tell 'him' that this is the Mac OS way to do it and you want to do this on Windows, you will get a pretty good answer.

Make a backup of your SD card before doing any of this, that way you can always restore if needed. During troubleshooting I've had multiple boot loops 😉

On another forum I've also been made aware of someone else having the specific code at a slightly different offset, 0x402920 instead of 0x402928.

You can find the offset using Python:

python3 -c " data = bytearray(open('/Volumes/TOMTOMDISK/PNDNavigator','rb').read()) needle = bytes([0xd6, 0x07, 0x00, 0x00]) pos = 0 while True: p = data.find(needle, pos) if p == -1: break # The correct position is followed by 24 fa ff ff (second threshold in DoCurrentDateTime) if data[p+4:p+8] == bytes([0x24, 0xfa, 0xff, 0xff]): print(f'Correct offset: {hex(p)}') break pos = p + 1"
 
Last edited:
Hello MacPat , I'm facing the problem --:-- with an original SDCard, I'm not able to find the PNDNavigator even after mounting -o loop the ext3 file located in loopdir

Any other suggestion? thanks again


fausto@fausto-HP-EliteBook-2530p:/media/fausto/tomtom$ find
.
./itn
./itn/temporary.iti
./LoquendoTTS
./LoquendoTTS/lib
./LoquendoTTS/lib/LoqAudioBoard.so
./LoquendoTTS/bin
./LoquendoTTS/bin/LTTS7AudioBoard.so
./LoquendoTTS/default7.session
./photos
./photos/thumbs.dat
./CurrentMap.dat
./lost+found
find: ‘./lost+found’: Permesso negato
./ttgo.bif
./Italia
./Italia/DeletedPoi.local
./Italia/MapSettings.cfg
./Italia/MapUserPatch.dat
./statdata
./statdata/allowtrip.dat
./art
./art/cars
./art/cars/thumbs.dat
./UserPatch.dat
I haven't been able to mount this myself, it was an assumption. What you maybe can do is to use TTActivator-v1.20 to only patch navcore. That's what gives you an extracted version of PNDNavigator.
I hope it is allowed here to reference TTActivator as it can also be used for things that are certainly not allowed! 😉
 
Is it not a simple way... waiting on solution by TomTom? via TomTom Home?
Is there news about?
 
The other solution is to wait patiently for TomTom to fix the bug.

Not everyone is comfortable with modifying the system, which could cause other problems, all for a simple clock.
 
According to MacPat’s analysis, the incorrect date (caused by the week overflow) should reach 2007 around August 15 of this year, becoming “valid” again, and the clock should reappear on its own even without a fix... ¯\_(ツ)_/¯
 
According to MacPat’s analysis, the incorrect date (caused by the week overflow) should reach 2007 around August 15 of this year, becoming “valid” again, and the clock should reappear on its own even without a fix... ¯\_(ツ)_/¯


Yes, you're probably completely right. I find it amusing figuring out something like this and why shouldn't I share it? Everyone who finds it helpfull and is able to fix the issue will be happy I've shared it😉

Besides this, TomTom carminat isn't supported anymore by TomTom and Renault as far as I know. So, let's hope they will provide an update at all.
 
On Windows, using a hex editor like HxD:
  • Open PNDNavigator
  • Go to offset 402928 (hex)
  • Verify you see D6 07 00 00
  • Replace with B9 07 00 00
  • Save
Important notes
  • This fix applies to modified/unlocked SD cards where PNDNavigator exists as a standalone file
  • On original unmodified cards, PNDNavigator is embedded inside loopdir/loopback.ex3 (a Linux ext3 filesystem image) — patching that requires Linux tools to mount the filesystem and is more complex
  • The navigation itself continues to work correctly even without this fix — only the clock display is affected
  • The fix has been tested and confirmed working on a Renault Laguna with Carminat TomTom firmware version 8.843
Hello MacPat and thank you for your works.

I tried it on 8.843 and it worked. But I'm using version 8.841 which works fine with my TomTom rear view camera. Version 8.843 has some differences and my monitor board can't turn on on 8.843 but works fine on 8.841. So I looked closely at the neighboring bytes in PNDNavigator 8.843 and found them in PNDNavigator 8.841.

I can confirm that in version 8.841 you need to find byte 4085D4 and similarly replace D6 07 00 00 with B9 07 00 00, this combination occurs 4 times in the circle, so you need to replace it where there is D6 07 00 00 24 FA FF FF. This works 100% for my navigator
 
I have raised a ticket regarding this, and have attached a text file showing the discovery of the problem's cause, and of the 'fix'...
 
On original unmodified cards, PNDNavigator is embedded inside loopdir/loopback.ex3 (a Linux ext3 filesystem image) — patching that requires Linux tools to mount the filesystem and is more complex
Hi,

I have the original SD card for my TomTom Carminat in a Renault Scenic III. It contains a folder named “loopdir” with the following files:
- ext3_fix
- ext3_loopback

Using the explore2fs-1.08beta9 program, I can load the ext3_loopback file, but I don't know what to do next. I can't find any PNDNavigator in it:

001.png


002.png


003.png


004.png


005.png


The ext3_fix file cannot be opened with this program.

Does anyone know how to proceed? The lack of a clock display is driving my wife crazy :)
 
Ok, I have to say nothing in there looks like a file the patch can be applied to. Let's say, it was a false assumption, my apologies!

I don't know what I did exactly about 7-8 years ago to get an extracted version of PNDNavigator. It probably has something to do with the map updates I installed back than, probably not via an official way 😉

I used TT FastActivate back then. I took a look at how TT FastAcivate works and you indeed need to install/copy a version of PNDNavigator (and a lot other files) to your SD card manually. So, that's how I got it on my SD card I think...

For everyone else who has this file, here's A HTML file you can download to your PC. Open the file in your favourite browser and drag your PNDNavigator on there. Using Javascript the correct offset will be located and a patch will be applied. You can than save your patched file to your SD card. Be sure to make a copy of the original first, that way you can always go back.
Important to know, no files get uploaded anywhere, everything happens on your own PC.


The instructions on how to use TT FastActivate are still widely available online, so for those who only have an original SD Card maybe you can first get the needed files via those instructions. AND AGAIN, I can't say this enough: Make backups of your SD card before you start, if anything goes wrong, restore and retry...
 
Hello MacPat and thank you for your works.

I tried it on 8.843 and it worked. But I'm using version 8.841 which works fine with my TomTom rear view camera. Version 8.843 has some differences and my monitor board can't turn on on 8.843 but works fine on 8.841. So I looked closely at the neighboring bytes in PNDNavigator 8.843 and found them in PNDNavigator 8.841.

I can confirm that in version 8.841 you need to find byte 4085D4 and similarly replace D6 07 00 00 with B9 07 00 00, this combination occurs 4 times in the circle, so you need to replace it where there is D6 07 00 00 24 FA FF FF. This works 100% for my navigator
Version 8.843 is for a non-Live Carminat system.

This update, version 8.843, released on January 23, 2019, fixes the Week Number Roll Over issue from April 2019.

The title of this post: Clock problem on a Live Carminat.
The current version of the Live Carminat is 9.884.
 
Version 8.843 is for a non-Live Carminat system.

This update, version 8.843, released on January 23, 2019, fixes the Week Number Roll Over issue from April 2019.

The title of this post: Clock problem on a Live Carminat.
The current version of the Live Carminat is 9.884.
In 2010 there was already a Live version? My clock was repaired by MacPat, I have a flash drive with both 8.841 and 8.843. Cars from 2009-2010 have been without a clock for a week, the forum gave a concise description of why this happened and how to fix it. The official answer will probably be on 15th of September when the microcontroller will be 2007.
 

Attachments

  • IMG_8459.jpeg
    IMG_8459.jpeg
    649.3 KB · Views: 179
  • IMG_8460.jpeg
    IMG_8460.jpeg
    243.1 KB · Views: 179
Last edited:
Ineens geen tijdsindicatie meer. Wel 9 satelieten ontvangst. Tijd is aan te passen/synchroniseren maar houd het niet vast.
West Europa versie 11.65
alles opnieuw geinstalleerd en zelfs Quickfix verwijderd en opnieuw erop.
accu los gehad
oude kaart erin 10.02 maar ook daar zelfde probleem dat ik de tijd wel kan aanpassen /synchroniseren maar wil deze wijziging niet vasthouden.
op display --:--
Antenne los gehad maar geen oxidatie
GPS route planning werkt gewoon alleen aankomsttijden --:--

zijn er op middenconsole knoppen die ik gelijktijdig moet indrukken voor reset? ( verborgen gaget)?

hoop op oplossing



Hi, I have a 2010 Renault Scenic 3 with the Carminat TomTom system. I live in the Czech Republic and I've been having the same issue since last Sunday. The clock cannot be reset; it only shows dashes instead of the time.
 
In 2010 there was already a Live version? My clock was repaired by MacPat, I have a flash drive with both 8.841 and 8.843. Cars from 2009-2010 have been without a clock for a week, the forum gave a concise description of why this happened and how to fix it. The official answer will probably be on 15th of September when the microcontroller will be 2007.
All versions of Carminat Live start with 9.xxx, so I don't understand how you can have a Live version that starts with 8.xxx
 
All versions of Carminat Live start with 9.xxx, so I don't understand how you can have a Live version that starts with 8.xxx
You wrote that the topic of this post is about the Life version. And I provided screenshots that the author of the post writes that in nbogo it is not the Life version. And the problem with the Garazu clock in the Tom Tom version is not Life.
 
Hi all,
After extensive reverse engineering (together with AI, Claude) of the PNDNavigator binary on the Carminat TomTom SD card, I've found the root cause of the --:-- clock issue that many users are experiencing since around 19-20 April 2026, and more importantly, a fix.

What's happening - the root cause
The Carminat TomTom uses a SiRF Star III GPS chip (GSW3.2.4TT_3.1.00.12-C35B1.02) that stores the GPS week number in a 10-bit field, which can only count up to 1024 weeks before rolling over to zero. Around 19-20 April 2026, we crossed GPS week 2415. This is exactly 1024 weeks after GPS week 1391, which corresponds to 6 September 2006.
This means the chip's 10-bit counter has overflowed once, and the chip now thinks the date is somewhere in September 2006 — not the classic 1024-week rollover (that won't happen until November 2038), but rather the chip losing track by exactly one full 1024-week cycle.
We can confirm this because when the loopdir folder was deleted from the SD card during testing, the system recreated it with a timestamp of 6 September 2006 — exactly what the GPS chip was reporting as the current date at that moment.

Why the clock shows --:--
Through reverse engineering the PNDNavigator ARM binary using Ghidra, I found the function CClock::DoCurrentDateTime. This function retrieves the current date and time and returns it to the clock display. It contains a hard-coded year threshold check:


c if (year < 2007) { // return invalid / show --:-- }

Because the GPS chip reports a year of 2006, this check fails and the clock display always shows --:--. The navigation itself continues to work because position fixing doesn't rely on the absolute date.

The fix
The fix is to lower the year threshold from 2006 to 1977 (before the GPS epoch of January 1980), so the software accepts any year the chip reports — including 2006.
On cards where PNDNavigator is a standalone file on the SD card (this applies to cards that were modified using the FastActivate tool):
  1. Make a backup of PNDNavigator on your SD card first
  2. Find the following bytes at offset 0x402928 in the file:

d6 07 00 00
  1. Replace with:

b9 07 00 00

On Mac, using Python:

python data = bytearray(open('/Volumes/TOMTOMDISK/PNDNavigator','rb').read()) file_offset = 0x402928 assert data[file_offset:file_offset+4] == bytes([0xd6, 0x07, 0x00, 0x00]) open('/Volumes/TOMTOMDISK/PNDNavigator_backup','wb').write(bytes(data)) data[file_offset] = 0xb9 data[file_offset+1] = 0x07 open('/Volumes/TOMTOMDISK/PNDNavigator','wb').write(bytes(data)) print('Done!')

On Windows, using a hex editor like HxD:
  • Open PNDNavigator
  • Go to offset 402928 (hex)
  • Verify you see D6 07 00 00
  • Replace with B9 07 00 00
  • Save
Important notes
  • This fix applies to modified/unlocked SD cards where PNDNavigator exists as a standalone file
  • On original unmodified cards, PNDNavigator is embedded inside loopdir/loopback.ex3 (a Linux ext3 filesystem image) — patching that requires Linux tools to mount the filesystem and is more complex
  • The navigation itself continues to work correctly even without this fix — only the clock display is affected
  • The fix has been tested and confirmed working on a Renault Laguna with Carminat TomTom firmware version 8.843
Additional findings
We also patched the ephemeris files (packedephemeris.ee, ee_meta.tlv, ee_meta.txt) to correct their timestamps. While this did not fix the clock display by itself, it may help with GPS fix acquisition time.
Hi, MacPat

I have the same problem on a Carminat TT navcore 8.843. It displays the time as --:--

The information in your post is really good, but in my case I don't have the PNDNavigator file and I can't find where to download the FastActivate tool. Can it be done directly through ttsystem?

Thanks, Luis
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Latest resources

Forum statistics

Threads
30,342
Messages
209,018
Members
70,193
Latest member
archerynl

Latest Threads

Back
Top