I have been looking into it, but it is way more difficult to find this than you could ever imagine.

It is definately obfuscated, but I cannot imagine that this was intentional by designers.

Originally, I tried finding refrence to the the string indices for the caution. I am 100% sure these strings are the ones (I know because I modded the strings and it shows the changes on the nag screen). Here is that thread: printing strings from language (.LNG) files

0823: CAUTION!

0824: This product provides Route Guidance information for reference purpose only. Rev

0825: OK

(those are in hex)

However, I only find about half of the strings im looking for referenced in the code. There are many strings (including) these which are using some other method (perhaps loaded by reference in Navi.rff menu file, etc?). So this has become a dead-end.

--------------

Anyhow, one interesting note, which is the current route that I am investigating, is that when there is an active route, the unit will bypass the warning screen and go straight to nav screen on startup.

I see this happens when USER\RW\PATH\ROUTESTG.DAT and USER\RW\PATH\PATHINF.DAT are present, and have the right flags/settings to indicate an active route in-progress.

So the next trick could be to try to determine what in these files indicates active route and then look for something in Navi.exe that is triggering this.

Thanks for the effort pionara. Hopefully we will get it one day.

Is there any electronic module that can simulate a "click", kind of like touching that stupid OK button once at start up?

yes - mortscript can send messages to other windows, etc.

Actually, i think i have found the section of code in navi.exe that manages the nag window, but the tough part is to figure out where this is triggered and the logic to bypass this.

Awesome pionara. I think we will get it eventually. It'll be a challenge but the victory will be so satisfying

ok, a call out to our more experienced tech-savvy folks that want to help me get the info i need to squash the nag screen.

I have successfully done this on u310bt, but now i need your help to get some info from logs on x/f 920+ or z110+ units (that have been upgraded to 4.001 i.e., 2012 software)

If you want to help:

1. download LogState.dat (below) and use testmode file explorer to replace the one in your unit at USER\RW\LOG\

2. put an empty file called "Log.ini" on an sd card in the unit (we'll call this the "log sd card"), and boot up normally.

3. navigate through the nag screen, and then go set a route (so that the unit has an active route).

4. restart your unit (with log sd card still inserted). This startup should have skipped the nag screen and gone straight to map screen with active route.

5. turn off your unit, remove sd card, and PM me the log file that is now on your sd card at SD\SYSLOG\LOG0000000.TXT (dont post it openly on this forum, as it contains some personal information, gps coords, in some log entries.)

6. if you want to stop logging, just remove the file at the top of the sd card called Log.ini - the unit should only log when this file is present.

I'll try to make a separate post with all the grisly details of logging. as promised: advanced topic: application logging

If the above instructions do not make sense to you and/or you are not familiar with testmode - just please ignore this post. At this point, I only need help from folks who know their way around testmode and the filesystem of these units.

I really only need one or two samples to figure this out.

Done & PM'd. Log is from a Z110 running CNSD310FM.

Should I also restore the original /USER/RW/LOG/LogState.dat? Or are you not through experimenting?

Thanks Ron!

as promised here is the post about logging:

advanced topic: application logging

If you want you can just delete LogState.dat - it will restore a default one that doesnt do any logging. However, that should only be logging to SD card when Log.ini is present on sd card. Can you help me verify that it is not logging to flash disk - i.e., there should be no LOG*.TXT files in USER\RW\SYSLOG folder.

Thanks Ron!

 

as promised here is the post about logging:

advanced topic: application logging

 

If you want you can just delete LogState.dat - it will restore a default one that doesnt do any logging. However, that should only be logging to SD card when Log.ini is present on sd card. Can you help me verify that it is not logging to flash disk - i.e., there should be no LOG*.TXT files in USER\RW\SYSLOG folder.

I've got a 400K file called PATHERR.txt in USER\RW\SYSLOG. Was written this afternoon. Any ideas? But no LOG*.TXT

hrmm. yeah that seems to be some logging from navi route calculations. Im not sure if it's always been there (you can look at timestamps in it?).

but anyhow, if you want to kill logging for sure - delete LogState.dat and restart.

However, see your PM - i need one more log session from you (one with active route at startup that doesnt show the caution screen).

we are very close

ok ron (or anyone else comfortable with editing and the like) - have an edit for you to try out:

navi.exe version 4.001 (2012 software aka cnsd-310fm):

offset bee20: 05 00 00 0a -> 00 00 a0 e1

Let me know how that works. Also try testing various startup modes such as starting with AV screen as the last view, or map as the last view and then various switches from av to navi, from navi to av and back to navi, etc. There are different startup paths depending upon what the last "view" was when the unit was shutdown (it remembers which screen it was on).

I'm trying to find a "single edit" solution so we dont have to make like half dozen edits

Success!!!!! Works fine. It seemed to stick on the splash screen longer - maybe just my imagination. Anyway, I tried setting and canceling routes, VR and other stuff, all good. I haven't done a full regression test of all modes. Will continue testing.

I was a little worried when I noticed my iPod VR dictionary rebuild ran 3-4 minutes the 1st time. But on the other reboots - it just ran the short "refresh" scan - 10-15 seconds.

I can't say for sure that there are no side-effects, so I'll just keep testing tomorrow. Speaking for myself, the biggest downside of the nag screen is that VR is unavailable until the iPod dictionary gets rebuilt - and the nag screen doesn't show up in iPod input until you switch mode. So I could of been driving for hours - decide I wanted to use VR, and then have to wait. Much better this way.

Thanks a million man! Now get ready to get deluged with people bricking their units trying to figure out testmode and a hex editor. Hint folks - always have a backup!!!!!

And there will be a rush of folks wanting to install CNSD310FM. Probably more people getting hosed by Condi's HackMode.

UPDATE: Continued testing - switching and shuting down with various sources active - sometimes while in NAV and sometimes in the current audio source screen. Sometimes with a route active, most of the time w/o route. Reboots are exactly as expected - never a nag.

Observation: the Voice Recognition engine starts-up in two parts. The 1st part is the basic VR command stuff - "Change source to ....". This engine takes about 10 seconds to get initialized. Untill then - the basic VR commands don't work. You'll either get no response - or or a "Wait" dialog box.

Then, if/when you switch to iPod, you also have to wait for the iPod's VR dictionary to load/rebuild before you can give any iPod VR commands (or any VR commands at all). I noticed that if I shut down in NAV with iPod source, on reboot - the NAV screen shows - the iPod in the background does its VR rebuild on it's own. That's just as expected.

One thing I think the hack does expose - probably an existing weakness w/ the hardware performance - is a lot of sluggishness in the user interface while the VR stuff is building. Since it now happens immediately on startup, instead of waiting for the nag screen "OK", the HU appears very lethargic right after a reboot. It clears up in about 10-15 seconds.

I've got a 400K file called PATHERR.txt in USER\RW\SYSLOG. Was written this afternoon. Any ideas? But no LOG*.TXT

hrmm. yeah that seems to be some logging from navi route calculations. Im not sure if it's always been there (you can look at timestamps in it?).

The timestamps in the PATHERR.txt log file go back to about the time I installed CNSD310FM. So it has nothing to do with your hack. The last log entry was related to a trip I took earlier today - before I tried your LogState.dat hack. I think I'll just delete it - but 400K in less than a month - with pretty light use - makes me wonder how long before it fills all available space.

Holy hell...we got rid of that navi "OK" screen???

Way to go pionara!!

 

navi.exe version 4.001 (2012 software aka cnsd-310fm):

offset bee20: 05 00 00 0a -> 00 00 a0 e1

 

does this work on BT-130 upgraded to 140 (4.001) ?

I used Condi Hackmode to search for that navi.exe...couldn't find it... Where is it located? Thx.

yes - this works on any of these units upgraded to 4.001. I would need to find the spot to patch this on previous versions - but not worth it just upgrade to the latest....

anyhow created a dedicated topic as this one is kind of comical in its earlier days...

http://avic411.com/index.php?/topic/35523-remove-caution-nag-screen-hack/

anyone have the instructions to do this? Unfortunately pionaras thread was deleted...

I dont have the instructions... you could try PM'ing the site admin (jason?) and asking him what happened. sometimes threads get randomly deleted around here...

If I remember correctly there was some indication that Pionaras was scamming people or something to that affect. I myself got several PMs from people requesting me to delete his threads. I wasn't the one however that made him disappear. JasonH is the one to contact on this matter.

If I remember correctly there was some indication that Pionaras was scamming people or something to that affect. I myself got several PMs from people requesting me to delete his threads. I wasn't the one however that made him disappear. JasonH is the one to contact on this matter.

That doesn't sound right and there was nothing in the Nag screen removal thread that even had the whiff of a scam or solicitation by Pionara.  But I have several times expressed frustration/anger saying Condi's hackmode should be taken down because it bricks lots of people's HUs. I hope that didn't get lost in translation.  All that was needed for the nag screen removal was Testmode.key and a hex editor.

Yup. Scamming thing is plain wrong. I've been using his nag screen bypass for over a year without issue. It's simple process if you have 1/2 a brain. People who bricked their device either doesn't have the same model and do it anyways or just didnt know what they're doing.

bring back the page for nag screen removal. rons and pionara are geniuses

+1 ... please bring back the nag screen removal thread for 4.x.  

I would like to upgrade the maps on my z130bt, have had nag screen removed for a year now and don't want to bring it back ...!!

Thanks.  John

does this hex code still work on the z130bt newest firmware? 
 
any help would be greatly appreciated
 
thanks!!