Detecting internal TMC-receiver

I don't think it will work and also editing file names is how many of these devices end up bricked.

With all knowlegde and expertise within this forum and despite of all modern techniques available, it seems to be a problem that can not be solved which I find remarkable and hard to understand.
May I suggest to open up a new place on this forum called 'cold cases' where we can file this kind of unsolved issues, hoping someone will find it a challenge to work on it and will be able to solve it after all ?
One more piece of information I found: the SW_TMC driver connected to COM,1 is located in \drivers\build_in\ which is a location I am not able to explore with winCE or when the device is connected to my computer.
R/Ton

Ton wrote:With all knowledge and expertise within this forum and despite of all modern techniques available, it seems to be a problem that can not be solved which I find remarkable and hard to understand.
May I suggest to open up a new place on this forum called 'cold cases' where we can file this kind of unsolved issues, hoping someone will find it a challenge to work on it and will be able to solve it after all ?

Interesting suggestion. I'm sure the admin will see it.

Ton wrote:One more piece of information I found: the SW_TMC driver connected to COM,1 is located in \drivers\build_in\ which is a location I am not able to explore with winCE or when the device is connected to my computer.

Hidden directories CAN be browsed with total commander on the device, In the area at the top where the current directory is type in the directory name you want to go to but can't, make sure you get it 100% right and TC will go there, You usually only need the first level directory.

This trick is used all the time on windows mobile, On the Omnia 2 try typing "\basefolder\" into the box to see it's hidden files. It's the wince equivalent of a hidden partition on a hard drive.

OK,
being on the edge of giving up, another consideration.
Would it be a possibility to put the tmc-related dll-files next to the iGO.exe file so they would be activated if iGO is executed ?


Using TotalCommander I found in \\Plugins\Registry\HKLM\Drivers\BuiltIn the following two subdirectories related to TMC: SW_TMC en TMC_HWCOM.

Within SW_TMC I found the following files with their values:
CountryCode - 0
DeviceArrayIndex - 1
DeviceType -1
Dll - s3c2443_SW_TMC.Dll (to be found in \Windows)
ErrorCorrection - 3
Index -1
Irq- 42
Order - 52
PIChecking - 0
Prefix - COM
Protocol - 0
RadioEnable - 0
RFModuleType - 0

Within TMC_HWCOM I found the following files with their values:
DeviceConfig 10 00 00 00 05 00 00 00
10 01 00 00 00 48 00 00
00 00 08 00 00 00 00 00
00
DeviceArrayIndex - 1
DeviceType - 0
Dll- serial_smdk2450.dll (to be found in\Windows)
FriendlyName – TMC_COM
IClass – {CC5195AC-BA49-48a0-BE17-DF6D1B0173DD}
Index - 1
InterruptBitShift - 3
Irq - 23
MemBase- 1342193664
MemLen - 48
Order -53
Prefix - COM
Priority - 0
Tsp – unimodem.dll (to be found in \Windows)

As I mentioned earlier, using PortSplitter learned me that both TMC_com (being the 'friendly name' of TMC_HWCOM) and SW_TMC COM1 could be directed to the available ports 0, 3, 4, 6, 7 and 8.
Further may GPS_com and SirFNAVDRV directed to one of these available ports.
From my perspective, ports 1, 2 and 5 (and 9 ?) are in use by the mentioned elements.

Ton wrote:OK,
being on the edge of giving up, another consideration.
Would it be a possibility to put the tmc-related dll-files next to the iGO.exe file so they would be activated if iGO is executed ?

No as the iGO application doesn't call the dlls they won't be loaded

Ton wrote:Using TotalCommander I found in \\Plugins\Registry\HKLM\Drivers\BuiltIn the following two subdirectories related to TMC: SW_TMC en TMC_HWCOM.

Within SW_TMC I found the following files with their values:
CountryCode - 0
DeviceArrayIndex - 1
DeviceType -1
Dll - s3c2443_SW_TMC.Dll (to be found in \Windows)
ErrorCorrection - 3
Index -1
Irq- 42
Order - 52
PIChecking - 0
Prefix - COM
Protocol - 0
RadioEnable - 0
RFModuleType - 0

Within TMC_HWCOM I found the following files with their values:
DeviceConfig 10 00 00 00 05 00 00 00
10 01 00 00 00 48 00 00
00 00 08 00 00 00 00 00
00
DeviceArrayIndex - 1
DeviceType - 0
Dll- serial_smdk2450.dll (to be found in\Windows)
FriendlyName – TMC_COM
IClass – {CC5195AC-BA49-48a0-BE17-DF6D1B0173DD}
Index - 1
InterruptBitShift - 3
Irq - 23
MemBase- 1342193664
MemLen - 48
Order -53
Prefix - COM
Priority - 0
Tsp – unimodem.dll (to be found in \Windows)

You are in the WinCE registry here so be careful as you may stop TMC from working altogether or worse.

Ton wrote:As I mentioned earlier, using PortSplitter learned me that both TMC_com (being the 'friendly name' of TMC_HWCOM) and SW_TMC COM1 could be directed to the available ports 0, 3, 4, 6, 7 and 8.
Further may GPS_com and SirFNAVDRV directed to one of these available ports.
From my perspective, ports 1, 2 and 5 (and 9 ?) are in use by the mentioned elements.

I agree with Nabi that the original Mio application must be responsible for the TMC drivers, The drivers may look for a security key or licence that iGO doesn't have or the Mio app contains the driver. Hardware manufacturers are sometimes like that. There was a thread recently where the sound in WinCE would only work when the original application was running. Unfortunately my Mio M400 doesn't have internal TMC so i can't experiment with it.

Another thought is the data output from the TMC driver is in a propriety format that iGO can't understand.

About the dll's: I said before that all iGO programs need gpstmc.dll. When that doesn't do the trick, it's obvious that Mio software is responsible. Or the way the program addresses the TMC module.
On a side note the sound. The other day, I read NorbertBL's explanation (on the German forum) that iGO/Amigo/Primo addresses directly the device speaker, because it's designed to run on PDA and PNA. Some devices however use the serial port (or an other specific manufacturer home made port) to address the output device. This can be the car speaker when it's an indash. So a software designed to run on PDA/PNA always looses this battle and nothing can be done. In other words. Only the original software produces the sound.
Maybe it's the same for TMC?

@Fatboyfun: is there a way we can iGO instruct to call for the dll's and load them (by scripting, or in sys.txt) ?

Ton wrote:@Fatboyfun: is there a way we can iGO instruct to call for the dll's and load them (by scripting, or in sys.txt) ?

The instructions to call dlls would need to be written into the igo programme.

I'm willing to try whatever it takes to make ik possible, but I would need some suggestions as to where in the igo programme I should look for.
I do not mind if nobody knows, but rather say so instead of giving answeres that suggest a way to go, but in fact point to a dead end ...

I found this but i don't think it will be of any use...
[Please Register or Login to download file]
A bit more research on Mio Moov TMC problems reveals that internet activation is required for the original Mio software where TMC is not built-in (Models with built-in TMC are pre-activated at the factory)

I'm out of ideas now

This might help others, but my mio moov spirit has a built in TMC receiver and the problem is (again) how to get it working with iGO ...

It seems to me an issue that does not come to a solution here, despite all the knowledge spread out by all forum members. I suggest to open up a new element on this forum called 'cold cases' and file this apparently unsolvable problem there, hoping one day some bright member finds it a challenge to work on and solve it after all, helping a lot of mio moov spirit owners !
R/Ton