PPP Forum

Information and discussions about our products
Welcome to PPP Forum Sign in | Join | Help
in Search

Breaking changes: our new Navigation solution partner is Sygic

From TomTom to Sygic:
Over the years our former navigation provider reduced his SDK more and more to drive his own business solutions.
Finally a SDK is no longer available!
Looking for an alternative solution we found www.sygic.com/tomtom-sdk.
Why we recommend Sygic:
  • Good support at first hand
  • A modern Navigation Solution (with actual maps)
  • Native .NET support in the SDK (no need for third party solutions)
  • Many operating systems support including Linux and Android
  • A partner which is even able to adapt the Navigation solution to your needs.

TomTom slowdown when using TTNCF

Last post 12-11-2006, 15:37 by ManniAT. 8 replies.
Sort Posts: Previous Next
  •  12-11-2006, 11:49 770

    TomTom slowdown when using TTNCF

    Hi there,

    I'm using TTN 6.010 and TTNCF6.  I began noticing a problem a few weeks ago where TomTom would slow dramatically.  TTN wouldn't respond to stylus taps for about 5 seconds and also, on the GPS Settings screen, the rotating circle would only update around every 8 to 10 seconds or so.  This made navigation also impossible.

    Nothing I changed or messed with fixed it, and so I hard-reset my device and installed TTN again.  It works perfect again.  I use an other NMEA device, 38400 Baud and GPS Device in settings.  The circle updates once per second and TTN is fast and responsive.

    When I installed my application that uses TTNCF6 again and use that for a short while, TTN slows again.  It will stay slow until the next hard reset.  Whether my program runs again in the future or not, it will stay slow.

    It's driving me insane that a hard reset is required.  Have you come across this before?  Do you know what causes TTN to slow down and more importantly, do you know how to fix it?

    It seems strange why TTNCF would cause it to slow down, but after a week of not using my application with TTNCF it was fine and shortly after it broke it seems like it is the thing responsible.

    My application pretty much starts tomtom, sends GPS data over GPRS and will sometimes create routes.  I can provide code snippets if required.

    Thanks a lot for any assistance and if you need more info I can happily supply.

    Daniel

     

  •  12-11-2006, 12:45 771 in reply to 770

    Re: TomTom slowdown when using TTNCF

    Hi,

    first of all three things:
    a.) there is a commited lon/lat bug in TTN
    ---maybe something else is also not fine
    b.) we don't habe any problems except if we use ExternalGPS which slows down TTN
    c.) TTN6 "reintroduced" a startup problem - well knwon from TTN5 (early versions)
    ---we built StartTTN to overcome this problem

    Anyhow - I would like you to:
    a.) tell me the exact TTN version (including build number)
    b.) when TTN is slow - please check (after TTN shutdown) if there are files in \TomTom\SdkFilecalls

    Regards

    Manfred

  •  12-11-2006, 13:33 772 in reply to 771

    Re: TomTom slowdown when using TTNCF

    Hi there,

    Thanks for the quick response.  There's 1259 files in the SDKFileCalls folder..

    I use StartTTN (with the 15,3 parameters), I don't send NMEA sentences to TTN, only retrieve.

    The TTNbuild (using TTNTest) says Ver: 7720, StrVer: 6.010

     

    Thanks a lot.

     

    (I'm not liking the look of those 1259 files)

  •  12-11-2006, 13:45 773 in reply to 772

    Re: TomTom slowdown when using TTNCF

    Hi,

    the version is the correct one - as suggested by TomTom.

    You say that you retrive NMEA from TomTom - this means you use "RawGPS"?

    Anyhow - about the massive number of files.
    Do you use any "Async" functions in you program?

    Or even better - could you (simply by search for "TTN.") list the functions you use in your app?
    And another thing - since those files are very small - could you pleas take a number of them (100-200) zip them and post it here.

    Regards

    Manfred

  •  12-11-2006, 13:58 774 in reply to 773

    Re: TomTom slowdown when using TTNCF

    Hi again,

     

    Most of them (99%) begin TomTomNavigationServer.TTNCF6.xxxxxxxxxx.xxx

    The others begin TTNCF6.TomTomNavigationServer.xxxxxxxxxx.xxx.

     

    I don't retrieve raw GPS data.  I use Async functions for retrieving gps info.

    intReturn = TTN.GetCurrentPositionAsync(lngSession, 1)
    ' Sleep for a second or so to give it time to get the result.
    Thread.Sleep(1500)
    If TTN.ReturnAvailable(lngSession) > 0 Then
        ' Can get position
        intReturn = TTN.GetCurrentPositionAsyncRetrieve(lngSession, errInfo, posInfo)
    End If

    I'll add the attachment in a moment (in Quick Reply mode you see)

  •  12-11-2006, 14:03 775 in reply to 774

    Re: TomTom slowdown when using TTNCF

    Thanks very much
  •  12-11-2006, 14:47 777 in reply to 775

    Re: TomTom slowdown when using TTNCF

    Hi,

    your attachment is empty :)

    BUT - I got your problem.

    Think about how SDK communcation works: (not for all but for some function)
    a.) Files with the command (and parameters) are created in ....\SdkFileCalls
    b.) TTN periodicly scans this directory - and reads the files (and deletes it)
    c.) The answer is generated and also placed in such files
    d.) The SDK read the files and gets the result (and deletes the files)

    If you make a synchronious call the SDK does:
    a, WAIT INFINITE, d

    In other words if TTN does not process the file the call freezes your app.

    In asynchronius call the things are handled like this:
    1.) Call to xxxAsync
    a - and return imideately
    2.) Call to "ReturnAvail"
    - check if the file from point c exists
    3.) Call to "....AsyncRetrive
    - the work as in d

    So now to your code:
    1.) Call to async - a file is generated
    2.) Wait some fixed time (without a further condition)
    3.) Check if a result exists
    3a) YES - take the result
    3b) NO - does nothing

    3b is the problem - if anyhow TTN can not finish the call in the time you give you do not take the respone. Later TTN will process the call and unread answer files will be created - and stay there forever.

    So think about:
    a.) Why async?
    --this is only usefull if you run other threads in your programm
    --if you do not use more than one thread - USE SYNCHRONIOUS CALLs
    b.) If async is a must - expect getting no answer as a critical error!!!
    --Build the loop like this
    ........
    int nCnt=0;
    int nRetAvail=0;
    do {
       Sleep(300);   //to small nubers are not a good idea - to large number result in useless waits
       nRetAvail=TTN.ReturnAvail....
       nCnt++;   //try counter
       if(nCnt>30)   {   //I assume about 30 seconds are enough
          CRITICAL_ERROR_HANLDER
          break;   //terminate loop
       }
    } while(nRetAvail<=0);
    if(nRetAvail>0)   {   //got a result
       TTN......AsyncRetrive......
       }

    By the way - the filesystem in PPC (WM5) is pretty slow. So searching for a file like TTN does it
    takes much (!!!) longer in a directory with many files as in one which is empty.
    So you orphans (produced by your calls) result in more and more slower response of TTN.

    Regards

    Manfred

  •  12-11-2006, 15:20 780 in reply to 777

    Re: TomTom slowdown when using TTNCF

    Hi there,

    Confirmed.  I deleted the contents and all my devices are flying.  I will re-write that code as you suggest and monitor if any files are kept, but as long as I always do an async retrieve if a result is available... all is well.

    I had no idea the calls and results were done via the file system... I guess that explains it.

    Thanks very very much for the solution.  Will let you know how I get on.

  •  12-11-2006, 15:37 781 in reply to 780

    Re: TomTom slowdown when using TTNCF

    The thing is:
    ....but as long as I always do an async retrice.....

    There will ALLWAYS be a return (if TTN did not crash mean the call).
    So don't think about "will the be a return" - the only question is "WHEN will the return be there!"

    By the way - if you only worry about time for other threads in your programm - do it like this:
    nRet=TTN......Async
    if(nRet>0)   {   //no error
    Sleep(1500);   //if you thin 1.5 seconds are ok
    nRet=TTN......AsyncRetrive...
    }

    The idea is that AsyncRetrive does a sync. Or in other words you will get a return after the
    call has finished. There is almost no difference if you make an sync call or a combination of
    Async follow (imideately) by AsyncRetrive

    Regards

    Manfred

View as RSS news feed in XML
Powered by Community Server, by Telligent Systems