Thanks for the input
I did read through these threads but couldn't find any new tweaks. In fact I had the receiver up and running after 10 minutes using another howto. Making it work reliably was the tricky part.
Right now I'm quite happy with the way the GPS works after further refining upon my script.
Turning on the receiver from stand-by, typing "gps 1" (script location entered into ~/.bash_aliases) into konsole and waiting a little more than 10 seconds until getting location data inside buildings is good enough for me.
If the receiver was cut off from power, it takes several minutes, but thats also ok with me since I still only have to turn it on and type "gps 1".
I don't want to derail this thread, so I'll just mention the important points I found out to make things work:
* the rfcomm bind option is a BIG NO NO to me as it freezes my system after suspend/resume (I think sometimes even during normal bind-release cycles), so I only use rfcomm connect instead
* after the bluetooth connection is terminated the receiver goes into stand-by after a short time, so I have to turn it back on manually whenever I want to use it again
* my script first kills any left over xgps, gpsd and rfcomm processes and then utilizes a loop with the
(sudo rfcomm connect [DEVICE_NUMBER]) &
command (started as background process in order to not interfere with the execution of the script) until the corresponding character device /dev/rfcommX is present and then calls
(sleep 2; sudo -u [USERNAME] gpsd -n -N -D 2 /dev/rfcommX) &
(sleep 10; sudo -u [USERNAME] xgps) &
Writing udev rules to automate this is possible, but I don't need nor want that.
If you're having trouble with your internal non bluetooth GPS, you might as well try a script