Thread: GTM36 and GTM26 problem with TMC on nuvi series 2xxx and 3xxx

Then it's possible that the GTM35 has maxed out the allowed number of FM Tables. I don't recall offhand what that is, something like 11 or 13 i think. The point is if the maximum number has been reached in the past then that stops further successful additions. Even if existing unrequired subs are 'deleted' from the GTM receiver they still stop others being added properly. Do you know for certain the history of the 35? If you obtained it 2nd-hand it's maybe maxed out.

Edit: Correction. It's a total of 15 subs that max out the FM Tables, not so easy to reach normally.

A friend of mine found this in a drawer and asked me for help, and I read a few forums and thought I'd sort it out.
He also got it second hand with no known history. I checked the subscriptions and there are 13.
In the file TrafficProfider.xml is this
<providerName>Radio SI/TrafficNav (SI)</providerName>
<pay>true</pay>
<tuning ltn="33" sid="1"/>

[Only registered and activated users can see links. ]

But the receiver receives the number 35 and the provider names ist Not Named also on working GTM 36.

Well i don't have any further suggestions i'm sorry, other than this: You can read up over in another [Only registered and activated users can see links. ] about maxed out subscriptions although there does seem to be conflicting information about the accuracy of that preventing further additions even when some are removed, i.e. they're just hidden and not really deleted so still count towards the supposed 15 maximum. Read [Only registered and activated users can see links. ] there in particular and there're many others on that subject. However, many services such as Suna Australia where there are 8 for each individual State/Territory aren't treated as 8 but rather as a single subscription. So, in combination that 23/24 count of Angelozip's might really be 15 or less 'related' subs anyway.

The "Not Named" placeholder for a TMC service is merely an artifact of a temporarily weak FM signal at connection and is of no great concern as far as i can recall. I think it just means that some identifying information was not fully received or was jumbled initially. Apologies, i've not had to think about this TMC stuff for many years so you probably know as much or more than me presently.

A friend of mine tried the GTM35 and nuvi 3490LM in Austria with the privider 10/e4/128/1 0 4 and it worked fine, received the information and displayed it
But when he came back the receiver under traffic provider found 9/e4/128/1 h and stopped receiving the information.
If I turn on TEST RDS under Traffic reveiver and manually enter the frequency the GTM 35 receiver starts to receive and also count traffic information , but does not display it on the map. When I connect GTM 36 the receiver accepts the 9/e4/2/35 0 4 and automatically starts receiving and displaying traffic information.

Would it help if I correcting the xml ?

Spoiler: xml

<country name="Slovenia" cc="9" ecc="228" fmTuningGrid="World">
<boundary desc="slovenia">
<scposn lat="555084094" lon="163669924"/>
<scposn lat="553662964" lon="173528587"/>
<scposn lat="559177545" lon="192221320"/>
<scposn lat="558851094" lon="195051474"/>
<scposn lat="554483074" lon="198139630"/>
<scposn lat="555134247" lon="194377181"/>
<scposn lat="551436788" lon="186821131"/>
<scposn lat="546928913" lon="187261883"/>
<scposn lat="545898222" lon="182724994"/>
<scposn lat="541951135" lon="181038330"/>
<scposn lat="544845641" lon="174301582"/>
<scposn lat="542670392" lon="171709201"/>
<scposn lat="542617782" lon="162155770"/>
<scposn lat="543256619" lon="161224182"/>
<scposn lat="544003240" lon="163440233"/>
<scposn lat="543964728" lon="163744526"/>
<scposn lat="544003872" lon="164007298"/>
<scposn lat="543838378" lon="164412740"/>
<scposn lat="543800723" lon="164761883"/>
<scposn lat="543827048" lon="165247336"/>
<scposn lat="544126291" lon="165473432"/>
<scposn lat="544421142" lon="166074954"/>
<scposn lat="545030202" lon="165037258"/>
<scposn lat="545300271" lon="165080554"/>
<scposn lat="545568242" lon="164692851"/>
<scposn lat="546381664" lon="163088433"/>
<scposn lat="546511121" lon="162206099"/>
<scposn lat="546835717" lon="162119964"/>
<scposn lat="546932917" lon="161922507"/>
<scposn lat="547306823" lon="162171663"/>
<scposn lat="547542582" lon="162257920"/>
<scposn lat="548032370" lon="162705928"/>
<scposn lat="548192019" lon="162645634"/>
<scposn lat="548599966" lon="162769912"/>
<scposn lat="548654031" lon="162078124"/>
<scposn lat="548425825" lon="161877806"/>
<scposn lat="548408679" lon="161407952"/>
<scposn lat="548560001" lon="161072916"/>
<scposn lat="548899885" lon="160764025"/>
<scposn lat="548979171" lon="161043958"/>
<scposn lat="549337039" lon="161201851"/>
<scposn lat="549377324" lon="161016072"/>
<scposn lat="549531712" lon="161025380"/>
<scposn lat="549565845" lon="161454017"/>
<scposn lat="550238112" lon="162517940"/>
<scposn lat="550908474" lon="163063207"/>
<scposn lat="551074239" lon="162674954"/>
<scposn lat="551022046" lon="161841040"/>
<scposn lat="551596688" lon="159997612"/>
<scposn lat="552320791" lon="159626491"/>
<scposn lat="555084094" lon="163669924"/>
</boundary>
<provider>
<providerName>Radio SI/TrafficNav (SI)</providerName>
<pay>true</pay>
<tuning ltn="33" sid="1"/>
</provider>

You can try, it's solely your decision.

My initial suspicion in Post #131 was that it was a partial failure due to either hardware or software. Likely the previous flaky behaviour was due to an intermittent board failure that has now manifest completely.