Active Topics
-
Error after installing Leste on sdcard (18)
to Maemo 7 / Leste by Maemish - 12 hrs, 15 mins ago -
Maemo 20th Anniversary (4)
to Brainstorm by teroyk - 2 days, 7 hrs ago -
Nokia Booklet 3G (RX-75) Drivers (64)
to Alternatives by teroyk - 2 days, 7 hrs ago -
Porting apps to Leste (46)
to Maemo 7 / Leste by teroyk - 4 days, 11 hrs ago - more...
|
2006-05-29
, 03:15
|
|
Posts: 182 |
Thanked: 3 times |
Joined on Mar 2006
|
#42
|
Originally Posted by gnuite
Thanks for the update! I just wanted to let you know that I used the program this weekend on my vacation - 250 mile drive! It's excellent! New release: Maemo Mapper v0.2.2
Device-Installable .DEB File
Source Code
To those of you who have tried adding the "hciconfig reset" line to the sudoers file and found that it didn't work: I join you today. I was in the car today for more than an hour when the bluetooth connection paused, and I noticed that the hciconfig reset did not work. I found out why by fiddling on the command line (while I was driving - not recommended!), and I fixed the source and released the fix in v0.2.2.
You will need to modify the sudoers line slightly. from "/usr/sbin/hciconfig reset" to "/usr/sbin/hciconfig hci0 reset" - I forgot the intermediate "hci0" argument.
I confirmed during my debugging that executing this command when the bluetooth connection "pauses" does in fact successfully reset the radio and allow Maemo Mapper to reconnect to the GPS receiver. That means that v0.2.2 should actually be able to recover from this erroneous state, hopefully with only 30-60 seconds of lost communication. I think that's the best I can do for now, but I'll keep looking into it.
Also, I added armin's "previous two center points define the default top-left/bottom-right points in Download-By-Area" patch. I don't use it personally, and in fact I find it a little annoying to have to delete the defaults in order to replace them with my own values (not to mention that it's unintuitive), but let's see how others feel about it. Does anybody actually use armin's patch? Should I keep it as the default behavior? Or maybe add a secret button in the corner (like the pi symbol from The Net) that would populate the fields with those values?
In any case, I'll probably still remove the feature when I implement the "select download area via stylus" code, although I'll never use that either (Google Earth is so much easier to use).
Those are the only two changes in this release.
Personally, I think this feature should be defaulted. It's much easier than having to write down the first lat/lot and then put it back in after doing the other corner. So yes, I believe it is a necessary feature. Thanks once again!
 |
|
2006-05-29
, 04:50
|
|
Posts: 1,245 |
Thanked: 421 times |
Joined on Dec 2005
|
#43
|
Could anyone with a Socket GPS receiver please verify (with GPSD or rfcomm/cat) that their receiver does in fact emit the RMC sentence of the NMEA protocol? I can't find any information on the web about the messages it sends. The closest thing I can find is a datasheet for some "Trimble Recon GPS Card edition" that claims that it emits RMC and that it includes the "Socket Communications Bluetooth kit", which is a pretty weak connection.
You can check by looking at the NMEA output (with GPSD or rfcomm/cat) and checking if any of the output lines starts with "$GPRMC". If not, it would be helpful if you could tell me all of the message types that the Socket GPS receiver emits (such as the $GPGGA or $GPGSV messages).
It might turn out that the Socket GPS receiver only supports the GGA sentence (not the RMC sentence), which would explain why it's not working with Maemo Mapper. If that is the case, I will retool Maemo Mapper to use GGA instead of RMC (since I think all receivers use GGA). I would prefer to avoid having to support both, since most receivers emit both messages, which would mean doubling CPU usage by having to process both messages.
Last edited by gnuite; 2006-05-29 at 04:54.
You can check by looking at the NMEA output (with GPSD or rfcomm/cat) and checking if any of the output lines starts with "$GPRMC". If not, it would be helpful if you could tell me all of the message types that the Socket GPS receiver emits (such as the $GPGGA or $GPGSV messages).
It might turn out that the Socket GPS receiver only supports the GGA sentence (not the RMC sentence), which would explain why it's not working with Maemo Mapper. If that is the case, I will retool Maemo Mapper to use GGA instead of RMC (since I think all receivers use GGA). I would prefer to avoid having to support both, since most receivers emit both messages, which would mean doubling CPU usage by having to process both messages.
Last edited by gnuite; 2006-05-29 at 04:54.
|
|
2006-05-29
, 05:17
|
|
Posts: 182 |
Thanked: 3 times |
Joined on Mar 2006
|
#44
|
Gnuite, can you explain how the route regeneration works? Do you have to be connected to the internet? Because on my trip this weekend, I decided to take an alternate route than the one Maemo-Mapper generated (to avoid traffic). I did not get any route regeneration. Would it have worked if I was connected to the internet or how does this work?
|
|
2006-05-29
, 05:52
|
|
Posts: 23 |
Thanked: 0 times |
Joined on May 2006
|
#45
|
I wonder if it might be worthwhile to not do your own binding, but instead to simply read a /dev/rfcommX device, and let rfcomm do the binding for you?
|
|
2006-05-29
, 05:59
|
|
Posts: 1,245 |
Thanked: 421 times |
Joined on Dec 2005
|
#46
|
Originally Posted by kutibah
Yes. Route generation uses the GPX Driving Directions web service to generate directions, so you must be connected to the internet.
Gnuite, can you explain how the route regeneration works? Do you have to be connected to the internet? Because on my trip this weekend, I decided to take an alternate route than the one Maemo-Mapper generated (to avoid traffic). I did not get any route regeneration. Would it have worked if I was connected to the internet or how does this work?
|
|
2006-05-29
, 06:02
|
|
Posts: 1,245 |
Thanked: 421 times |
Joined on Dec 2005
|
#47
|
Originally Posted by RussNelson
Yes, as I've said, this will be supported in the next version of Maemo Mapper. GPSD will also be supported. But as others have stated, they suffer the same issue of random, mysterious GPS dropouts. This leads me to believe that it is a deeper issue that Maemo Mapper cannot solve, only mitigate.
I wonder if it might be worthwhile to not do your own binding, but instead to simply read a /dev/rfcommX device, and let rfcomm do the binding for you?
|
|
2006-05-29
, 07:31
|
|
Posts: 13 |
Thanked: 0 times |
Joined on Feb 2006
|
#48
|
Originally Posted by gnuite
Hello,Yes. Route generation uses the GPX Driving Directions web service to generate directions, so you must be connected to the internet.
first of all, great application!!!!
I have tried in the 0.1 and now in the 0.2.1 versions the route menu and i always have the same gpx parser error.
I'm from spain so, I tried Murcia, Spain to Barcelona, Spain. It works in the gpx web page generation the route, but I always have the gpx parser :-(
Regards
|
|
2006-05-29
, 08:24
|
|
Posts: 39 |
Thanked: 13 times |
Joined on May 2006
@ Bonn, Germany
|
#49
|
Originally Posted by gnuite
Maybe we could add a button to clear the input fields.Also, I added armin's "previous two center points define the default top-left/bottom-right points in Download-By-Area" patch. I don't use it personally, and in fact I find it a little annoying to have to delete the defaults in order to replace them with my own values
Originally Posted by gnuite
I aggree. Visually selecting the rectangle with a rubber-band would be more intuitive.(not to mention that it's unintuitive),
But if you consider, how I used Download Area before my patch (set the view center to the upper left of imaginary rectangle, then go to Menu -> Maps -> Download Area, note down current view point latitude and longitude on a piece of paper, press Cancel, now set the view center to the lower right of the imaginary rectangle, again go to Menu -> Maps -> Download Area, type in the two values you noted down before, and the two values that constitute the current view center, optionally select Zoom levels to download, press OK), then it becomes clear, that my patch simply automates this terribly time consuming and error-prone action sequence and gets rid of the pencil and paper.
Originally Posted by gnuite
Starting with empty input fields and having a button that fills in the two last view center coordinates as default values would be good. The other way around - always fill in the last two view center coordinates as default values and have a button to clear the fields would be better.but let's see how others feel about it. Does anybody actually use armin's patch? Should I keep it as the default behavior? Or maybe add a secret button in the corner (like the pi symbol from The Net) that would populate the fields with those values?
Originally Posted by kutibah
This was exactly my motivation.
Personally, I think this feature should be defaulted. It's much easier than having to write down the first lat/lot and then put it back in after doing the other corner. So yes, I believe it is a necessary feature. Thanks once again!
|
|
2006-05-29
, 08:40
|
|
Posts: 39 |
Thanked: 13 times |
Joined on May 2006
@ Bonn, Germany
|
#50
|
Originally Posted by gnuite
Unfortunately this release still contains the bug in the Download Area confirmation dialog, which was fixed by http://armin-warda.de/maemo-mapper-0.2.1-aw-0.1.patch, too. (Should be 'GTK_RESPONSE_OK', not 'GTK_RESPONSE_ACCEPT'.)
New release: Maemo Mapper v0.2.2
Device-Installable .DEB File
Source Code
To those of you who have tried adding the "hciconfig reset" line to the sudoers file and found that it didn't work: I join you today. I was in the car today for more than an hour when the bluetooth connection paused, and I noticed that the hciconfig reset did not work. I found out why by fiddling on the command line (while I was driving - not recommended!
You will need to modify the sudoers line slightly. from "/usr/sbin/hciconfig reset" to "/usr/sbin/hciconfig hci0 reset" - I forgot the intermediate "hci0" argument.
I confirmed during my debugging that executing this command when the bluetooth connection "pauses" does in fact successfully reset the radio and allow Maemo Mapper to reconnect to the GPS receiver. That means that v0.2.2 should actually be able to recover from this erroneous state, hopefully with only 30-60 seconds of lost communication. I think that's the best I can do for now, but I'll keep looking into it.
Also, I added armin's "previous two center points define the default top-left/bottom-right points in Download-By-Area" patch. I don't use it personally, and in fact I find it a little annoying to have to delete the defaults in order to replace them with my own values (not to mention that it's unintuitive), but let's see how others feel about it. Does anybody actually use armin's patch? Should I keep it as the default behavior? Or maybe add a secret button in the corner (like the pi symbol from The Net) that would populate the fields with those values?
In any case, I'll probably still remove the feature when I implement the "select download area via stylus" code, although I'll never use that either (Google Earth is so much easier to use).
Those are the only two changes in this release.