Notices

I don't know how maemo mapper works. If maemo mapper tries to reconnect periodically to the gpsd port (2947), you can turn minigpsd on or off anytime.

Maemomapper could itself start (and/or stop) minigpsd - it is just "/usr/bin/minigpsd", and "killall minigpsd" shell commands.

I'd recommend using the status bar applet. It has an indication of a lock (bluefill = off, redfill = starting, redcircle = not locked, greencircle (with sat dots) = locked).

maemo mapper works very well with minigpsd .. In maemo mapper point yout gps under setings to 127.0.0.1 2947 that will connect to minigpsd on port 2947 raw output .. Have mini gpsd loaded 1st .

computerfreek274

Ummm, I am not sure if this is the problem, but after installing minigpsd, my WiFi has been working very poorly. I don't know if this is the cause, because the tablet has been "acting up" recently. On another note, I caught some sort of ping tool using, and I quote, "1507%" of the processor. This is weird, very weird, and I am wondering if it is related to this.

Maybe I tried it too late last night, and I was too tired, but I didn't understand how this is supposed to work :-)

I installed bluez-utils-test with apt-get then your two deb packages with app manager.
I didn't find minigpsd in the menus, only the standalone python app, so I launched it from xterm. It did show up in htop but nothing appeared in the status bar and the test app did not seem to lock, at least not any faster than with the usual applet.

So I left it at that and went to bed. This morning the tablet was turned off with an empty battery, although it was almost full.

What am I doing wrong ? :-)

The first two entries on the statusbar or standalone applet start and stop minigpsd. If you leave it on overnight it might drain the battery (depending on what else is on - when locked without backlight I get 10 hours+, but YMMV).

There are three debs. minigpsd itself, the statusbar applet, and the standalone applet.

minigpsd runs in the background, so doesn't appear in any menu. It is controlled by the other applets. If you start minigpsd via the applet, a red circle should appear.

l2ping will continually search for a bluetooth device if one is configured. If misconfigured it might interfere with wifi. But nothing should use over 100% cpu.

Thanks a lot, it's clearer now... I think my problem is just that I missed the statusbar applet altogether, I'll try again :-)

I had same wifi problems after istalling minigps. Unistalled and the wifi works just fine.

which one is the statusbar applet deb ? I see only two ?...

http://www.zdez.org/tzgps-0.30-pre1.tar contains the whole package.

http://www.zdez.org/TZGPSD-Statusbar...-0.30-pre2.deb is the fixed SB applet

http://www.zdez.org/TZGPSD-Setup-Applet-0.30-pre1.deb is the standalone setup applet - not updated.

http://www.zdez.org/minigpsd_0.30-pre4.tar.gz is minigpsd

I have another OOPS - If you aren't using a BT GPS, use the setup apps to erase the entries for BT GPS. Everyone (who doesn't have my harley interface), needs to erase the entry for the BT OBD. Get the menu, tap the entry, and blank-out the box.

Apparently if you haven't paired a BT device, the BT layer does a lot of stuff that interferes with the wifi. I've noticed it at times but couldn't pin it down since I normally have paired devices. I don't know if it is RF or just the BT and wifi sharing some resource.

My deb postinit needs work - I intended to erase/fix these entries, but didn't remember when I packaged it.

Interestingly enough, if I haven't paired the device using the hildon BT applet, but have the right address, it will still connect if the address is right.

I'll have to look further into the wifi degradation. I submitted a bug report (but I thought l2ping was better - doing rfcomm and letting it fail I remember killed the wifi).

https://bugs.maemo.org/show_bug.cgi?id=3238

Maybe the bug should get a few more votes.