Active Topics
-
Is there a section to talk about Java ME? Apps, etc. (0)
to General by Kalatti - 3 days, 12 hrs ago -
Extra softwares in Sailfish using CLI, repositories, etc (117)
to SailfishOS by nieldk - 5 days, 9 hrs ago -
Firefox with Leste (6)
to Maemo 7 / Leste by teroyk - 6 days, 6 hrs ago - more...
 |
|
2006-06-20
, 15:46
|
|
Posts: 1,245 |
Thanked: 421 times |
Joined on Dec 2005
|
#152
|
Originally Posted by RussNelson
I have noticed this, too, but have no idea why this occurs. I thought that bluetooth connection occurred during the open() call, but it's possible that it's occurring during the read() call. I have no idea how to handle this, though, since I am already setting the non-blocking flag.
Yes. rfcomm bind doesn't survive a reboot.
BTW, I discovered a problem with opening /dev/rfcomm*. If the bluetooth GPS receiver is not turned on, the user interfce hangs while the kernel is attemting to bind to the device. Makes the user interface pause for the timeout period between every UI event. Click .... timeout .... click .... timeout .... click. I usually just turn off "Enable GPS" if I'm going to leave the GPS receiver off.
|
|
2006-06-20
, 15:59
|
|
Posts: 4 |
Thanked: 0 times |
Joined on Jun 2006
|
#153
|
Originally Posted by gnuite
OK, I tried the /etc/sudoers patch today. This didn't help - it still lost communication with my GPS - is there any way I can tell that I did the patch correctly?I have noticed this, too, but have no idea why this occurs. I thought that bluetooth connection occurred during the open() call, but it's possible that it's occurring during the read() call. I have no idea how to handle this, though, since I am already setting the non-blocking flag.
I'm now going to try the /dev/rfcomm solution to see if it works (i'm still on OS2006). If this fails I think i'll have to give up (!) unless someone can tell me how to debug this to find out exactly what's going wrong so that I can feed it back to guite.
Cheers,
MPH
|
|
2006-06-20
, 16:16
|
|
Posts: 1,245 |
Thanked: 421 times |
Joined on Dec 2005
|
#154
|
Originally Posted by mph070770
Modifying /etc/sudoers will not prevent communication loss - it will only allow Maemo Mapper to "recover" from that state by resetting the bluetooth radio and re-connecting. This "hack" is not technically guaranteed to work, since it relies on the bluetooth subsystem itself recognizing the fault condition and informing Maemo Mapper that the connection is bad (which is, in my experience, normally the case).OK, I tried the /etc/sudoers patch today. This didn't help - it still lost communication with my GPS - is there any way I can tell that I did the patch correctly?
If you don't modify /etc/sudoers, Maemo Mapper just tries to re-connecting, but the whole problem is that, in this particular crazy situation, the bluetooth radio stops working entirely until it is reset.
Short of enabling debug, the only way I can think of to verify that the bluetooth radio was actually reset is to keep another bluetooth device connected to the Nokia 770 and see if that device gets disconnected (due to the radio being reset).
|
|
2006-06-22
, 15:30
|
|
Posts: 23 |
Thanked: 0 times |
Joined on May 2006
|
#155
|
Hmmmm.... After I download maps in bulk, there are a dozen or so maemo-mapper processes.
|
|
2006-07-29
, 01:49
|
|
Posts: 2 |
Thanked: 0 times |
Joined on Jul 2006
|
#156
|
the quickest fix while driving a car was to go in offline mode and come back to normal mode , this fixes it for me, ofcourse this is also doable with a lil scripting, which i found and modified a lil bit over google, just need to run it along with maemo as root and it should work , i havent tested it extensively so will post if succesfull.
hciconfig hci0 reset will only reset bluetooth i suppose, resetting to offline and normal mode seems to solve the problem so instead of that we just need a lil piece of code to do just that automatically.
hciconfig hci0 reset will only reset bluetooth i suppose, resetting to offline and normal mode seems to solve the problem so instead of that we just need a lil piece of code to do just that automatically.
BTW, I discovered a problem with opening /dev/rfcomm*. If the bluetooth GPS receiver is not turned on, the user interfce hangs while the kernel is attemting to bind to the device. Makes the user interface pause for the timeout period between every UI event. Click .... timeout .... click .... timeout .... click. I usually just turn off "Enable GPS" if I'm going to leave the GPS receiver off.