pcbbc

Amundsen units (MIB2 Standard) - Maps stored permanently on SD card Fix possible only for maps up until 2020 (V12) Requires hacking about with MIB2Toolbox Columbus units (MIB2 High) - Maps copied to internal flash storage (after which you can remove SD card) Fix possible with all maps up to and including latest 2023/2024 (P330) Simple coding adaptation (Requires VCDS, OBDEleven, etc)

For anyone in or around SE London (Bromley) and prepared to bring me their MIB2 High equipped vehicle I’m happy to make the coding change for you*. Send me a PM. * I reserve the right to withdrawn my offer if I get snowed under with requests.

Nowhere. The values are all the same setting for IDE501111. Different MIB2 units are coded differently with different settings… 32783 is online traffic permitted + Trafficmaster RDS TMC 32782 is online traffic permitted + ITIS/INRIX RDS TMC 15 is NO online traffic, Trafficmaster RDS TMC 14 is NO online traffic, ITIS/INRIX RDS TMC So for MIB2 High you will need to code either 32782 (if your current setting is 32783) OR code 14 (if your current setting is 15).

For MIB2 High… Replace 15 with 14 Replace 32783 with 32782 Yes, you will lose some services abroad when in Finland or Hungary. Of course you can code back to your original value if you ever visit there. For reference the TMC json configuration file for MIB2 are in the Mib2\NavDB\mapStyles_eu\0\default\x\navigation_styles_XX_EU.iso and look in folder Ti for file paytmc.json

You need to look in your maps TmcProviderSets.xml and then reference to TmcProviders.xml to determine the correct coding values to use for Set ID. Note the above links are for AUS/NZ maps, and so are probably not the same as current EU maps. In TmcProviders you’ll find which provider ID you need… <tmc_provider name="Trafficmaster" id="2"> <tmc_provider name="Inrix" id="12"> And then in TmcProviderSets you find the adaptation value you need to code to enable that provider ID. From the above example (which almost certainly isn’t correct for Europe) you can see that Set ID 15 includes provider Trafficmaster (2) but not INRIX (12)… <tmc_provider_set id="15" use_free_tmc="true" use_online_traffic="false"> <provider_ref id="1" mode="non-exclusive" /> <provider_ref id="2" mode="non-exclusive" /> <provider_ref id="5" mode="non-exclusive" /> <provider_ref id="9" mode="non-exclusive" /> <provider_ref id="13" mode="non-exclusive" /> </tmc_provider_set> You’ll either need to find a Set ID to code that includes INRIX (fairly safe modifying only coding) or modify the map xml configuration files like catatonicShrimp did for AUS/NZ (here be dragons if you don’t know what you are doing).

My understanding for MIB2 Standard is that it should be possible with the Here maps used up until 2020 (V12). After that I am told the map supplier was changed to TomTom and therefore only includes the now defunct TrafficMaster. I don’t have access to a MIB2 Standard system to test with however. So basically you’re on your own with that. Sorry. A starter for 10 can be found here where the AUS/NZ maps were modified to add support for Here traffic.

…I only think everyone is out to get me?

They don’t even need a connected app. Base stations can triangulate your phones location as it hops through cells on their network. They use this anonymised data to detect traffic jams on major roads. If a set of phones are travelling 50-70 miles an hour and all slow or come to a halt in roughly the same location, that’s a jam. For those of you with MIB2 High systems there’s a solution. MIB adaptation channel IDE05111 - Fee based traffic information needs to be set to 32782. This is tested and working on Audi TT and I presume other MIB2 High systems as well. https://www.ttforum.co.uk/threads/fixed-rds-tmc-no-longer-working-in-uk.2032197/#post-9622197

And yet just last year INRIX stumped up £20,000 to Ofcom in order to submit their licence renewal bid for the period ending April 2031. And that’s just the price for submitting your bid proposal. There is an annual fee due if you are the winning bidder. For the previous licence period the per annum fee was £200,000.

As far as I can ascertain Trafficmaster contracted directly with Global Radio to broadcast on their “local” station networks Capital and Heart. The Trafficmaster service has never been part of the competitive tendering process run by Ofcom, which is solely for the nationally available bandwidth on Classic. That contract has been won by itis/INRIX for at least the last two tendering periods. So it’s not a contractual problem, it’s entirely a financial decision to stop the Trafficmaster service.

For serviceable parts the manufacturer already has an obligation under national/EU laws. I think it’s something like 10 or 15 years after production ceases that parts must continue to be available. That’s a reasonable timeframe if you ask me. For many vehicles these parts are available for a significant period after that. For example my 2002 Audi TT (which ceased production 17 years ago in 2006) still has zero issues with parts availability for service purposes. That legislation is there to stop manufacturers prematurely obsoleting out their vehicles before the end of their natural life expectancy. There has been ample advanced warning of analogue TV and Radio, and end of life of Windows products, so those are hardly comparable. Unfortunately with connected devices manufacturers, can, and often do, terminate platform support as soon as a few years down the line with no legal recourse for the consumer. Similar legislation is required in this area to stop consumers getting ripped off. As is, brand new VAG (and other manufacturers vehicles) were sold as of a few months ago with a working service that has now been withdrawn with zero notice. The fact that may be due to a contracted VAG supplier terminating their service isn’t the consumers problem, it’s down to the manufacturer that sold them that product and service.

For serviceable parts the manufacturer already has an obligation under national/EU laws. I think it’s something like 10 or 15 years after production ceases that parts must continue to be available. That’s a reasonable timeframe if you ask me. For many vehicles these parts are available for much after that. My 2002 Audi TT (which ceased production 17 years ago in 2006) still has zero issues with parts availability for regular services.

There should be a legal requirement for devices which provide key functions via connected services (cars, smart TVs, other domestic appliances) to be sold with a minimum supported lifetime quoted in the showroom at time of purchase. Then at least consumers would know where they stand when buying a product and have some legal recourse when service providers prematurely stop supporting their “old” platforms. Otherwise all too soon service providers cut the cost of supporting what they regard as “legacy” systems. Until we as consumers stop accepting as the norm that “technology moves on” nothing will change. Perhaps the EU should take a lead on that as they are keen to reduce electronic waste? Won’t help us in the UK, but it would be a start.

Updated that copy also. No change in TMC message status unfortunately.

None, unless the configuration is copied somewhere else on uploading new maps? My assumption was that as the PayTMC + online traffic node already included providers 2 and 12, that the map data would also. Otherwise what was the point of specifying provider 12 INRIX? The way I read those sections is that the online section is combined TMC and online data. But I’m not certain and really have no experience of looking at anything in regular MIB2. I’m just going by what was done in Australia/New Zealand https://github.com/catatonicChimp/mib2-tmc-ANZ You could be right that these are for online only. Does online traffic also use location tables? If so, are they the same as RDS? I have no idea. I’ve also realised that the file I changed in MIB2 high in the ISO may not be the correct one. There seems to be a copy located in /mnt/app/navigation/resources/app/vw/<region>/tti/paytmc.json I need to check if updating the ISO caused that version to be updated, and if not modify it separately.

I waited quite a while. It only takes a couple of minutes tops to populate on other platforms. The TMC messages are transmitted as a rolling carousel, sort of like old school teletext. So usually you have to wait for the whole database to be transmitted at least once before anything is displayed.

The MD5 checksums file in root isn't used. It's only purpose is (I assume) for the java tool that downloads the update to verify its integrity. The actual car doesn't use it at all. I just opened the ISO file in a hex editor and looked for "PayTMC UK" and replaced the subsequent occurance of "trafficmaster" with "itis". After some fiddling with metainfo2.txt I managed to get it to load onto my MIB2 High unit in my Audi TT. Unfortunately still no traffic messages displaying. 😞 Either I didn't do something right, this isn't the config I need to change, or the maps don't contain the INRIX location tables.

I was avoiding fiddling. The mib2 standard if it's in the map files can be hacked. Mib2 high they are signed so can't be edited. Actually there may be a way around that. I've uploaded some modified navigation database files in the past. If you change a file, but keep the file size exactly the same, it appears MIB2 high doesn't bother with re-checking the signing. At least not on the file I modified. Presumably re-checking the entire database for correct signatures on every boot would be prohibitively expensive. Seems MIB2 high TMC config is perhaps in... \Mib2\NavDB\mapStyles_eu\0\default\?\navigation_styles_??_EU.iso There are separate ISOs in separate folders for Audi (1), VW (2), Skoda (3), Seat (4), Bentley (5) and Porsche (6). Then look in file... \tti\paytmc*.json "itis" was what the service with location table 0xA was called befire being acquired by INRIX. I probably need to go do some testing.

From the Skoda MIB2 configuration files I’ve seen it appears units are configured to use TrafficMaster over FM and either the service from TrafficMaster or INRIX via internet. https://github.com/catatonicChimp/mib2-tmc-ANZ TmcProviders.xml TmcProviderSets.xml Assuming the online traffic uses the same, or compatible, tables with the RDS system (big assumption) and that the maps therefore already include the necessary tables for both systems, perhaps modifying TmcProviderSets.xml to change the provider_ref id for FM (the first section with tmc_provider_set id=“21”) from 2 (TrafficMaster) to 12 (INRIX) will restore TMC service over RDS?

Fairly much how it works. TMC codes messages are highly compact, the objective being to fit most messages into the 37 bits that were still available in the RDS message group. Have a read of chapter 7 here.

Be very careful there. Your company will have a NDA in place with those suppliers. Better sources of location tables are available. For example other navigation products. It’s still quite a task to integrate them into a different system.

RDS transmits a country code (CC) and extended country code (ECC) which uniquely identify the country the FM station is broadcasting from. Additionally every TMC provider within a country is assigned a location table number (LTN) to identify the table they are using (only 6 bits so not unique between different countries). Typically TMC receivers use a combination of CC, ECC and LTN to decide which table to use. If they don’t find a matching table with the correct CC, ECC and LTN in the map database they ignore the received TMC messages. My only reason for hacking the firmware (rather than modifying the map data) was just that was a lot quicker to do. I’d already modified the firmware to capture all the TMC messages and save to SD card so I could inspect them, so I knew just where to make that change. Modifying the map data and changing the TrafficMaster LTN (0x07) to the INRIX one (0x0A) would have had the exact same result, but would have needed much more work.

I think the firmware update is probably a miscommunication. Having looked in detail at the maps for Audi’s RNSE system (also supplied by Here) the TMC tables are located entirely in the map data, and so no firmware update would be required to change supplier. So you are correct - to embed this kind of data in the firmware would be a crazy design decision. Especially as I imagine TMC providers update their tables fairly regularly as new junctions and roads get added.

Map update only I would have thought. Very unlikely to require new software. Does sound positive, but we don’t know how negotiations will go with INRIX.