Automatyczne zestawianie połączenia DUN

Witam.

Chciałbym się, podzielić moim rozwiązaniem problemu automatycznego nawiązywania połączenia DUN po każdym uruchomieniu i wybudzeniu urządzenia. Rozwiązanie testowałem na NR460BT i działa zadowalająco. Być może da się je zastosować także w innych modelach. 

Jak wiadomo nawigacja automatycznie nawiązuje połączenie typu HFP.  Aby zestawić połączenie DUN, należy w nakładce NavRoad nacisnąć przycisk „Połączenie DUN”. Co ważne, połączenie DUN zostanie nawiązane tylko, jeśli aktywne jest połączenie HFP.  Poniższe rozwiązanie automatyzuje ten proces. Kluczowe są dwa elementy – odczytanie aktualnego stanu Bluetooth i aktywacja profilu DUN. Jak się okazuje stan Bluetooth można odczytać z rejestru (klucz HKLM\Platform\BluetoothStatus), a aktywację profilu DUN można wykonać za pomocą programu PhoneLinkMsg.exe obecnego w katalogu \ShellDisk\Shell\ANW.  Pozostaje stworzenie skryptu, który w przypadku wykrycia aktywnego profilu HFP, uruchomi program PhoneLinkMsg.exe, naciśnie przycisk „Connect GPRS”, i zakończy działanie programu. Poniżej przykład takiego skryptu, dla  narzędzia MortScript:

Sleep(30000)
While (True)
   #sprawdzenie stanu Bluetooth
   bs=RegRead("HKLM","Platform","BluetoothStatus")   
   if(bs=3)   
      # HFP profile active   
      SleepMessage(1,"Starting DUN...","Wait...",TRUE)
      #symulacja naciśnięcia "GPRS Connect"
      #w programie Phonelinkmsg.exe
      While(WndExists("PhoneLinkMsgWnd"))
         Close("PhoneLinkMsgWnd")
         Sleep(500)
      endwhile
      Run("\ShellDisk\Shell\ANW\PhoneLinkMsg.exe")
      WaitFor("PhoneLinkMsgWnd",10)
      Repeat(18)
         SendDown("PhoneLinkMsgWnd")
      EndRepeat
      SendCr("PhoneLinkMsgWnd")
      Minimize("PhoneLinkMsgWnd")
      Sleep (1000)
      Close("PhoneLinkMsgWnd")
   endif
   #przerwa między kolejnymi sprawdzeniami stanu Bluetooth
   Sleep(60000)
EndWhile

Pozostaje kwestia uruchamiania tego skryptu przy starcie urządzenia. Można to oczywiście zrobić na kilka sposobów. Chyba najprościej jest wywołać  go za pomocą nakładki NavRoad – w pliku \ShellDisk\Shell\APShell.ini:

      [LaunchonInitial]
      FileName1=<ścieżka do programu>

Wykorzystuje się tu cechę MortScript, polegającą na tym, że program Autorun.exe, po zmianie jego nazwy wywołuje skrypt o odpowiadającej mu nazwie. (Dzięki temu można uniknąć potrzeby podawania parametrów wywołania) .
Do powyższego skryptu można dorzucić  (na jego początek) automatyczne uruchamianie programu do nawigacji po uruchomieniu urządzenia  - na przykład tak:

# czas inicjacji sprzętu (GPS)
#dobrany doświadczalnie - przy zbyt małym czasie mogą wystąpić
#problemy z inicjacją GPS w programie do nawigacji
Sleep(20000)
# czas uruchamiania menu NavRoad, Bluetooth i
#zestawienia połączenia HFP
#dobrany doświadczalnie - przy zbyt małym czasie aktywne
#pozostaje okno menu NavRoad
Sleep(10000)
#uruchomienie AutoMapy
Run("\SDMMC\navroadmaps.lnk")   
#oczekiwanie na otwarcie okna przez AutoMapę
WaitFor("AutoMapa",30)
#jeśli AM uruchomiona zbyt wcześnie, ukrywaj inne okna
repeat(30)
   if(NOT WndActive("AutoMapa"))
      Show("AutoMapa")
   endif
   Sleep(1000)
endrepeat

i już można zapomnieć o istnieniu nakładki NavRoad i systemu Windows CE. Pozostaje tylko pytanie dlaczego urządzenia nie można tak skonfigurować za pomocą paru opcji w menu NavRoad?

Jeśli ktoś potrafi ustalić w jaki sposób program PhoneLinkMsg.exe przekazuje polecenia do modułu sterującego Bluetooth (program Phonelink.exe?) , to można by uniknąć uruchamiania programu PhoneLinkMsg.exe, co niestety jest widoczne na ekranie. 

Pozostaje też kwestia dokładnego momentu całkowitego uruchomienia  się nakładki (jest to mniej więcej chwila pojawienia się zegara), tak aby uniknąć niepotrzebnej zwłoki przy uruchamianiu programu do nawigacji.

Pozdrawiam.

super robota
mam nadzieje, że na NR560BF też będzie działać

Chciałbym się, podzielić moim rozwiązaniem problemu automatycznego nawiązywania połączenia DUN po każdym uruchomieniu i wybudzeniu urządzenia. Rozwiązanie testowałem na NR460BT i działa zadowalająco. Być może da się je zastosować także w innych modelach. 

Niestety w pokrewnych sprzętach (BLOW 50YBT i GC 506X) nie występuje wpis Bluetooth status w "platform", a próby odczytania statusu z innych wpisów pozwalają tylko wykryć samo włączenie modułu BT, a nie połączenie z telefonem.
Niemniej podobną metodę próbuję zastosować do połączenia DUN w Blow.
Może się orientujesz (ja do tego nie doszedłem) dlaczego Live Drive w AM działa po połączeniu z fabrycznego DUN'a, a nie działa jeśli utworzy się połączenie Dialup w Win CE (wszelkie inne programy, w tym i Miplosync i Miploloc działają bezbłędnie na takim połączeniu)?
Pytam, bo pozwoliło by to uniknąć używania okienka MSG (czy samego dunconnect), a użycie tylko rnaapp.exe w tle.

Może się orientujesz (ja do tego nie doszedłem) dlaczego Live Drive w AM działa po połączeniu z fabrycznego DUN'a, a nie działa jeśli utworzy się połączenie Dialup w Win CE (wszelkie inne programy, w tym i Miplosync i Miploloc działają bezbłędnie na takim połączeniu)?
Pytam, bo pozwoliło by to uniknąć używania okienka MSG (czy samego dunconnect), a użycie tylko rnaapp.exe w tle.

a pytałeś się w supporcie AM?

Niestety nie mam specjalnego doświadczenia z DUN w Windows CE. Parametr BluetoothStatus odkryłem przez porównanie kopii rejestru wykonanych w różnych stanach Bluetooth. Może w innych urządzeniach też coś takiego się znajdzie? Można też sprawdzić czy stan Bluetooth nie jest zapisywany w jakimś pliku. Musi przecież być jakaś komunikacja między Phonelinkiem a nakładką, która prezentuje stan Bluetooth.

Pozdrawiam.

Parametr BluetoothStatus odkryłem przez porównanie kopii rejestru wykonanych w różnych stanach Bluetooth. Może w innych urządzeniach też coś takiego się znajdzie? Można też sprawdzić czy stan Bluetooth nie jest zapisywany w jakimś pliku. Musi przecież być jakaś komunikacja między Phonelinkiem a nakładką, która prezentuje stan Bluetooth.

Też robiłem porównanie i wszelkie zmiany jakie występowały znajdowały się w kluczu HKLM\Software\ANWsoft i dotyczyły danych identyfikacyjnych telefonu. Wszelkie statusy BT (a jest ich aż 3 w rejestrze) sygnalizują tylko włączenie i wyłączenie modułu BT, nic natomiast nie mówią o połączeniu z komórką.
Nakładka owszem, sygnalizuje połączenie odpowiednią kontrolką, ale wygląda na to, że dynamicznie sprawdza jakieś parametry stosu BT (Kolega Mnjacentymn z Forum nad tym pracuje).

a pytałeś się w supporcie AM?

Owszem już nie raz, ale nie chcą się dzielić tą wiedzą. Szkoda, bo może by się udało uruchomić Live drive na znacznie większej ilości urządzeń.

Na Navroad NR560BF skrypt działa bez pudła. 

Szkoda tylko, że skrypt nie przewiduje sytuacji, kiedy dochodzi do zerwania połączenia urządzenia z telefonem. Np gdy nawigacja zostaje w samochodzie, a telefon wyjdzie razem z nami na spacer :-) Po powrocie, automatycznie odtwarzane jest tylko połączenie HFP.

To dziwne, że coś takiego ukrywają. Rozumiem, że algorytm wyznaczania trasy jest strzeżony, ale sposób łączenia z netem - to już przesada.

Pewnie jest tak, że support nie wie - bo to mu nie potrzebne i musiałby się spytać innego działu, a po co się pytać skoro nie musi.
Może w końcu trafisz na kogoś bardziej ambitnego w supporcie

Szkoda tylko, że skrypt nie przewiduje sytuacji, kiedy dochodzi do zerwania połączenia urządzenia z telefonem. Np gdy nawigacja zostaje w samochodzie, a telefon wyjdzie razem z nami na spacer :-) Po powrocie, automatycznie odtwarzane jest tylko połączenie HFP.

Zaraz - to by znaczyło, że ten status w rejestrze też do końca nie jest wiarygodny. Czyli jeśli podczas jazdy na przykład, telefon zgubi sygnał GSM (wiadomo - zdarza się) i nastąpi rozłączenie, to ponownego połączenia już nie będzie?
Jeśli tak, to mamy taką samą sytuację jak na Blow 50YBT i GC 506X, gdzie też udało się zautomatyzować łączenie po wykryciu telefonu, ale nie udało się jak na razie zapewnić odtworzenia połączenia w przypadku jego zerwania (obojętnie czy przez zanik sygnału GSM, czy wyłączenie BT).

To dziwne, że coś takiego ukrywają. Rozumiem, że algorytm wyznaczania trasy jest strzeżony, ale sposób łączenia z netem - to już przesada. Pewnie jest tak, że support nie wie - bo to mu nie potrzebne i musiałby się spytać innego działu, a po co się pytać skoro nie musi.

Pytałem conajmniej dwa razy - po raz pierwszy, gdy Traffic online (jeszcze wtedy nie Live drive) był dostępny tylko dla urządzeń Navroad (mówimy o nawigatorach na Win CE oczywiście). Dostałem odpowiedź w stylu "nie udzielamy informacji na temat szczegółów rozwiązań technicznych".
Po pewnym czasie pojawiła się nowa wersja AM w której Traffic Online zaczął działać także na innych urządzeniach na platformie MTK (sam zgłaszałem podczas testowania Bety, że "załapało"). Przy okazji znów spytałem o szczegóły dotyczące połączenia i znów dostałem odpowiedź, że "pracują nad rozszerzeniem funkcjonalności Traffic Online na inne urządzenia, jednak nie ujawniają szczegółów technicznych na ten temat. 

Zaraz - to by znaczyło, że ten status w rejestrze też do końca nie jest wiarygodny. Czyli jeśli podczas jazdy na przykład, telefon zgubi sygnał GSM (wiadomo - zdarza się) i nastąpi rozłączenie, to ponownego połączenia już nie będzie?

Wydaje się, że skrypt powinien dodatkowo sprawdzać cyklicznie czy połączenie DUN jest aktywne. A najbardziej wiarygodnie i do tego z pominięciem rejestru, jeśli to tylko na tym urządzeniu jest możliwe, dało by się zrobić np. pingiem.

No i właśnie nad takim sprawdzeniem (po pierwsze czy jest podłączona komórka, po drugie czy nie zostało zerwane połączenie) pracuje Kolega Mnjacentymn - jak się uda, to z pewnością dzieło ukaże się na Forum.

to trzymam kciuki aby się koledze udało

Na Navroad NR560BF skrypt działa bez pudła. 

Szkoda tylko, że skrypt nie przewiduje sytuacji, kiedy dochodzi do zerwania połączenia urządzenia z telefonem. Np gdy nawigacja zostaje w samochodzie, a telefon wyjdzie razem z nami na spacer :-) Po powrocie, automatycznie odtwarzane jest tylko połączenie HFP.

Skkrypt cyklicznie sprawdza stan połączenia, natomiast urządzenie niestety nie wykrywa zerwanego połączenia Bluetooth w stanie DUN (co widać w statusie w menu NavRoad). Co ciekawe w stanie HFP zerwanie połączenia Bluetooth jest wykrywane.

Dla mnie nie ma to jednak większego znaczenia, ponieważ gdy wychodzę z samochodu, nawigacja usypia (standardowa funkcja NavRoad po wyłączeniu zewnętrznego zasilania). Gdy nawigacja ponownie się obudzi  połączenie się automatycznie zestawia.

Zaraz - to by znaczyło, że ten status w rejestrze też do końca nie jest wiarygodny. Czyli jeśli podczas jazdy na przykład, telefon zgubi sygnał GSM (wiadomo - zdarza się) i nastąpi rozłączenie, to ponownego połączenia już nie będzie?

Nie sprawdzałem jak to jest przy braku zasięgu, ale mam nadzieję, że w takim przypadku telefon sygnalizuje problem i NavRoad przełącza się w HFP, co skrypt wykryje. Jeśli nie, to rzeczywiście należałoby cyklicznie sprawdzać rzeczywistą drożność połączenia (np. ping albo czas ostatniej synchronizacji danych Traffic)  i w przypadku problemu rozłączyć połączenie i nawiązać je ponownie. (Należałoby jednakże przewidzieć dodatkowe zabezpieczenia na wypadek problemów z komunikacją leżących poza naszymi urządzeniami, aby nie doprowadzić do ciągłego reinicjowania połączeń).

Pozdrawiam.

Witam.
Zgodnie z obietnicą kolegi Angler22 ukończyłem program do detekcji połączeń BT oraz połączeń internetowych.
Do pobrania tutaj:

http://pdaclub.pl/forum/nawigacje-pna-pnd-ogolnie/pare-programow-do-nawigacji-pna/

Kolega Angler22 wrzuci tutaj skrypt morta wykorzystujący wspomniany program i opisze swoje boje
z automatycznym zestawianiem połączenia internetowego.

Pozdr.
mnjacentymn

Nie będę wklejał drugi raz tego samego, podam tylko linka do tematu : http://pdaclub.pl/forum/nawigacje-pna-pnd-ogolnie/nawigacja-blow-gps50ybt-z-win-ce-5-0/msg1371674/#msg1371674 . Uprzedzając ewentualne pytania Kolegi Tomek 666 - tak wiem, że skrypt btconn.mscr jest "pokręcony", ale tak się stało po kilku dniach testów. Wszelkie dziwne "sleep" i pętelki wynikają tylko z konieczności poprawy stabilności i ponownego łączenia w przypadku zerwania transmisji BT.

Jak rozumiem na skrypt dla NR560BF od Tomek 666 ciągle czekamy?

Kolega pewnie wyjechał i trzeba poczekać aż zaglądnie na Forum. Mogę spróbować coś robić na bazie wcześniejszego skryptu, ale na prawdę ciężko jest zrobić coś działającego, bez możliwości natychmiastowego testowania.

Witam,

Dzięki pomocy Kolegi Mnjacentymn i Jego programowi mnjBTConnections.exe, mogłem zmodyfikować mój skrypt, tak aby nie korzystał z parametru BluetoothStatus, który nie do końca oddaje rzeczywisty stan BT, a ponadto nie jest dostępny w NR 560.

Sposób uruchamiania pozostaje bez zmian, dodatkowo wgrać należy program mnjBTConnections.exe.

Uwaga! skrypt nie działa przy aktywnym połączeniu AS (program mnjBTConnections.exe wykazuje wtedy obecność połączenia)

Zastrzeżenie: Skrypt nie był jeszcze testowany w warunkach rzeczywistych - może nie przewidywać wszystkich sytuacji. W dalszym ciągu nie wiem jak się zachowa w przypadku zaniku sygnału GPRS.

Skrypt w załączniku.

Pozdrawiam

Nareszcie ten system działa tak, jak sobie wyobrażałem, że będzie działać jak go kupowałem  Wielkie dzięki.
Jedna uwaga: po wybudzeniu z uśpienia, zanim NR złapie połączenie HFP, skrypt zdąży wykonać "stopping DUN". Może to bardzo nie przeszkadza, ale wydaje się, że w tym przypadku robi to zdecydowanie nadmiarowo.

Jedna uwaga: po wybudzeniu z uśpienia, zanim NR złapie połączenie HFP, skrypt zdąży wykonać "stopping DUN". Może to bardzo nie przeszkadza, ale wydaje się, że w tym przypadku robi to zdecydowanie nadmiarowo.

W tym przypadku nadmiarowo, ale nie ma możliwości odróżnienia tej sytuacji od zerwania połączenia BT. Obie sytuacje są sygnalizowane przez mnjBTConnections w ten sam sposób (BTConnections=0, InternetConnections=0). Po zerwaniu połączenia BT (oddalenie się z telefonem od włączonej nawigacji) NR pozostaje w stanie DUN i po powrocie z telefonem nie przechodzi do stanu HFP. Oczywiście można po prostu  cyklicznie próbować zestawić połączenie DUN niezależnie od obecności HFP (BTConnections=1, InternetConnections=0) - to też powoduje "odwieszenie" NR, ale to będzie powodować ciągłe wyskakiwanie "Starting DUN" gdy telefon nie będzie dostępny.

Poza tym "Stopping DUN" zostanie wywołany, tylko jeśli NR nie zdąży nawiązać połączenia HFP. (Można zwiększyć czas bezcztnności po każdej iteracji - prawdopodobieństwo się zmniejszy)

Myślę, że możliwość rozbudowy skryptu przez obsługę zdarzenia wybudzania urządzenia, ale szczerze mówiąc nie widzę takiej potrzeby.


Pozdrawiam

Uwaga! skrypt nie działa przy aktywnym połączeniu AS (program mnjBTConnections.exe wykazuje wtedy obecność połączenia)

Poniekąd jest to prawda gdyż połączenie przez AS z PC daje połaczenie z internetem , stąd i InternetConnection = 1. Można by filtrować nazwę połaczenia i z niej wydedukować czy mamy rzeczywiście to co chcemy tzn. połączenie przez DUN'a a nie połaczenie przez AS. Niestety ja nie mam mozliwości zestawienia połaczenia przez DUN'a dlatego mnjBTConnections działa tak jak działa. Jestem :"ślepy" i kolega Angle22 jest moimi oczami .
Sa tam jeszcze pewne flagi zwracane ale trudno mi powiedzieć czy różniłyby się czymś te zwracane przy połaczeniu AS od tych zwracanych przez DUN'a.

Pozdr.
mnjacentymn

W tym przypadku nadmiarowo, ale nie ma możliwości odróżnienia tej sytuacji od zerwania połączenia BT. Obie sytuacje są sygnalizowane przez mnjBTConnections w ten sam sposób (BTConnections=0, InternetConnections=0). Po zerwaniu połączenia BT (oddalenie się z telefonem od włączonej nawigacji) NR pozostaje w stanie DUN i po powrocie z telefonem nie przechodzi do stanu HFP. Oczywiście można po prostu  cyklicznie próbować zestawić połączenie DUN niezależnie od obecności HFP (BTConnections=1, InternetConnections=0) - to też powoduje "odwieszenie" NR, ale to będzie powodować ciągłe wyskakiwanie "Starting DUN" gdy telefon nie będzie dostępny.

Dokładnie w ten sam sposób musiałem to u siebie zrobić (w skrypcie dla BLOW), bo inaczej połączenie BT nie było wznawiane. Nie ma się co przejmować, że czasem coś dziwnie wygląda - ważne, że działa tak jak powinno

Poza tym "Stopping DUN" zostanie wywołany, tylko jeśli NR nie zdąży nawiązać połączenia HFP. (Można zwiększyć czas bezcztnności po każdej iteracji - prawdopodobieństwo się zmniejszy)

Najlepszy to byłby taki "PhoneLink" co to przyjmuje polecenia z command line i  go nie widać 

Dziś miałem jazdę miejską z częstymi przystankami i wysiadaniem. NR z automapą wybudzał się za każdym razem i skrypt też robił swoje. Jestem przeszczęśliwy 

Gratulacje 

Czyli mamy już idealne rozwiązanie dla Navroad'a i Blow, oraz Goclevera z "podmienionym" systemem. Zrobię jeszcze wersję dla czystego GC 506X, tylko potrzebuję testera.
Przy okazji sprawdziłem, że mnjbtconnections działa tak samo dobrze na sprzętach z prockiem Atlas III, jeśli więc AM rozszerzy dostępność Live Drive na inne urządzenia, będziemy mieli bazę do robienia kolejnych skryptów!

Witam,

Rozwiązanie wcale nie jest idealne, ale cały czas nad tym pracuję . W załączeniu ulepszona wersja skryptu.
Oto lista najważniejszych zmian:

- Zamiast jednego skryptu jest kilka specjalizowanych procedur.
- Zmieniony został sposób wywoływania PhoneLinkMsg.exe. Wysyłane są odpowiednie kody zamiast wirtualnego klikania.
   Dzięki temu okno nie musi być na pierwszym planie. W efekcie okno tego programu jest widoczne tylko raz
   po pierwszym uruchomieniu (po wybudzeniu pozostaje niewidoczne).
- Dodany został mechanizm opóźnienia zestawienia połączenia HFP po wybudzeniu urządzenia. Pozwala to na
   zestawienie połączenia między telefonem a zestawem głośnomówiącym wbudowanym w radio samochodowe.
   Technicznie jest to wykonane przez czasowe wyłączenie BT po wybudzeniu. Niestety nie jest to w 100%
   skuteczne - niekiedy PhoneLink jest szybszy .
- Modyfikacja podziału pamięci - dodatkowe 3,5MB dla AutoMapy! - przy synchronizacji z Miplo nie do przecenienia.   

Uwaga: załącznik nie zawiera programów *.exe. Do znalezienia na forum lub w internecie (polecam MioPacket 4.0)


Wkrótce trzecia wersja - bez udziału menu Navroad, co powinno oszczędzić ok. 2MB pamięci bardzo potrzebnej AutoMapie.

Pozdrawiam

Phonelinkmsg występuje we wszystkich nawigacjach z phonelinkiem, więc zasadniczo rozwiązanie bazujące na wysyłaniu kodów (czy jak się to tam zwie) przycisków do niego, jest bardziej uniwersalne, niż używanie dialera. Jakoś nie chciało mi się w tym reshackiem grzebać, ale skoro piszesz, że działa ładniej, to może też się w wolnej chwili przyglądnę.

Rozwiązanie wcale nie jest idealne, ale cały czas nad tym pracuję . W załączeniu ulepszona wersja skryptu.

Nie wiem dlaczego, ale po restarcie urządzenia, skrypt pozostawia pod automapą aktywne okno PhoneLinkMsg. Widać je po zminimalizowaniu automapy. Ale, gdy wpiszę w autostart.ini disable=1, żeby się AM nie uruchamiała, to po restarcie okno PhoneLinkMsg chowa się, że tak powiem,  samo.

Nad tym nie idzie zapanować, ale już znalazłem rozwiązanie - program WindowHide (z TroNik):

   if(NOT ProcExists("\ShellDisk\Shell\ANW\PhoneLinkMsg.exe"))
      Run("\ShellDisk\Shell\ANW\PhoneLinkMsg.exe",10)
      WaitFor("PhoneLinkMsgWnd",10)
      Run(SystemPath("ScriptPath") & "\WindowHide.exe", """PhoneLinkMsgWnd""")
   else
      WaitFor("PhoneLinkMsgWnd",10)
   endif

i jest super.

PS. Wersja bez menu NavRoad jest obiecująca -  5MB więcej wolnej pamięci!

Jednym słowem - jesteś Master! 

Witam, tak naprawdę nie wiem co mam skopiować i gdzie aby mieć w/w automatyczne zestawienie DUN. Ostatni skrypt (MortScript) gdzie skopiować zawartość, czy trzeba coś jeszcze dodać? Proszę o możliwie dokładną instrukcję, gdyż nie jestem tak mocny jak Koledzy z wątku.
Pozdrawiam.