Primo 2+bluetooth TMC, problems after resume.

[pippolippi]

After my in my device, I bought on dealextreme to connect a TMC receiver.
I used to create a virtual serial port (COM8) that goes through the bluetooth to serial adapter, and then I put this in sys.txt:

[tmc]
show_tmc=1
port="COM,8"
baud=9600
source="royaltek"
saved_config_available="1"
saved_config_classname="NMEA_GPSTMC_ROYALTEK"
seved_config_portname="COM"
saved_config_port="8"

I wrote a simple mortscript to start bt2com before starting primo.
It works very well, the problem is that, after a suspend/resume cycle (when I remove power and IGO primo automatically suspends) it doesn't reconnect, I have to restart primo.
Previously I simulated the TMC receiver using the bluetooth adapter of my computer and it always reconnected after a suspend/resume (it took 10-15 seconds to realize it had lost the connection but then it reconnected all by itself).

Do you know of any setting in sys.txt to solve this problem?

Maybe there's a timeout I can shorten or tell igo it's a bluetooth receiver so it knows it can lose the connection?

The funny thing is, if I remove power to the bluetooth to serial dongle and turn it on again, primo reconnects just fine, it's only after a suspend/resume that it doesn't work.

[pippolippi]

The plot thickens:

• sometimes igo reestablishes the connection to the bluetooth serial port
• sometimes it doesn't, if I try to open the virtual serial port with another serial test program, I can (meaning, the bluetooth is working). Note that at times I have to try and open the port several times before succeeding.
• sometimes the bluetooth controller isn't active after a resume: if I go to the control panel and try to do a bluetooth scan I get "bluetooth hardware error 10050 controller not present". The only way to turn on the bluetooth again is to reboot the device. (edit: actually I can use the main menu bluetooth option to turn it off then on again).

[pippolippi]

I solved the last problem (bluetooth inactive after a resume) by writing a simple brute-force program that simply turns on the bluetooth every 500ms.
I couldn't solve the second one , I need a way to instruct primo to retry opening the port at regular intervals but I don't know the right incantation to put in sys.txt.

[jwoegerbauer]

The funny thing is, if I remove power to the bluetooth to serial dongle and turn it on again, primo reconnects just fine, it's only after a suspend/resume that it doesn't work.

Each driver corresponds with the device it is written for via a so-called 'handle', a CE internally created numerical synonym, which becomes of course invalid, if the GPS is powered-of (sleep mode).

See also:

[pippolippi]

Yes, I know that, that's why I have to find a way for primo to retry. As it is now sometimes it does, sometimes it doesn't.
I suppose there's a suitable combination of parameters in sys.txt to achieve that, the problem is finding it.

[pippolippi]

I think I nailed it (or at least I hope).
I modified my brute-force program not to be brute-force: now it waits for a resume, and every time it detects a resume, it tries up to 10 seconds to activate the bluetooth and to open the com port.
Surprisingly, when it succeeds, the com port opened by primo keeps on working without disruption. It seems that my program opening the port pairs to the transceiver and that in turn revalidates the handle previously held by primo.

[pippolippi]

In case this is useful to somebody else , both exe and source.

Edit: and this is what I now have in the tmc section of sys.txt (I don't really know what's relevant and what's not)

[tmc]
show_tmc=1
port="COM,8"
baud=9600
source="royaltek"
init_on_startup=1
reinit_on_hardware_lost=1
sleep_init=10
sleep_selfdetect=10
internal_restart_timeout=5000
ignore_suspend=0
ignore_resume=0
override_saved_config=1

[pippolippi]

Reuploaded , since austech's mediafire account has been suspended.