I am running gpsd on an ADS Graphics Master running Linux. I have a gps device attached to "serial" port. the Client class is reading this constantly (ok). BUT then i get NO mouse interaction!!! i think Client is hogging CPU and nothing else can happen....
any suggestions?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Communication is like this:
GPS->serialPort->gpsd<->socket,qpegps
gpsd is a daemon (=> check if the daemonizing works..)
the socket of qpegps is event driven => data is read, if data arrives. gpsd sends data after receiving a request from qpegps. This request is sent in a fix intervall of 500ms.
Please try the new gpsd of version 0.9.1 (from a previous post I assume that You are still using a former gpsd version together with a workaround in the client => remove this workaround). I don't know the ADS Graphics Master, but I assume that it is not much slower than a Sharp Zaurus.
I don't have such a problem, if I start gpsd and qpegps in a Qtopia framebuffer on my (old) laptop (running linux, too).
The only thing I can think of is, that the mouse is somehow connected to the serial port of Your GPS.
You may also try to use a different port for the communication with gpsd (adjustable in qpegps and gpsd; and may be, that there is another program sending data to used port or...).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have tried without using the mouse, but using touch screen. I have the same issue. When I change
void MapDisp::paintEvent( QPaintEvent *p )
{
/* pmc 6/2/03 this method is called for each "MapDisp->update()" AHHH!!
I think this is why the mouse interaction stops (mouse events cant get thru!)
*/
if (mBadpaint < 10) {
createMap();
mBadpaint++;
}
else {
QWidget::paintEvent( p );
}
bitBlt(this, 0, 0, mapdisp);
}
Then I do not loose control of the cursor. What I actually meant from the first was "Loss of cursor". sorry. The above code is NOT meant to be a "fix" for my problem. Just to help be diagnose. Do you have any suggestion as to what to do? (1) Have Client::socketReadyRead() emit newData(); "slower"? (2)have Qpegps::updateData() check lat/long and only call mapDisp->repaint(); if some predefined difference in values from last lat/long gathered by socketReadyRead()? (3) i am barking up the wrong tree and you have any other hint for me...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Whenever new data arrives from the gpsd, the new map is drawn (createMap) and the display is updated (bitBlt). The gpsd sends the data in a fix intervall (500ms) caused by a QTimer. You may try to change this to a higher value (10s for testing and up to 1s without loosing to much performance on the moving map => value is set in qpegps.cpp).
BTW I once had a test version, where the update intervall was calculated depending on the relation of speed and scale of the map => in theorie much better, but practically this causes only an improvement if You are using the wrong map for your movement (driving with a map for hiking, hiking with a street (car) map...).
One improvement would be, if createMap returns if the position (in pixels) has changed (except for pure altitude changes,Balloon,Heli;-)=> but then your cursor problem would depend on the current movement => a constant and unconditioned algrithm is much more reliable.
In client.cpp is a QPE_DEBUGTIMEDESC. You may use this, to analyse how long it takes to fetch the gps data and to draw the map (this is Qtopia specific, but there might be a similiar one for Qt/embedded or You write your own small function with gettimeofday).
If I'm completely wrong in this issue (e.g. setting the QTimer to 10s doesn't change anything) just post again and I'll think this over.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Also changed MapDisp::createMap() to follow "if createMap returns if the position (in pixels) has changed". This works fine. I will deal with the "cursor problem would depend on the current movement" later; if it is a problem. Here is my code change:
if (lastPos.longitude && lastPos.longitude) {
double lastLg,lastLt;
/* pmc Return if no position change */
lastLg = lastPos.longitude * M_PI / 180.0;
lastLt = lastPos.latitude * M_PI / 180.0;
if (lastLg == lg && lastLt == lt) {
return;
}
}
lastPos.setLat(gpsData->currPos.latitude);
lastPos.setLong(gpsData->currPos.longitude);
etc...
And I left the 500ms for the GPS time. Thanks for your advice.
maria
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am running gpsd on an ADS Graphics Master running Linux. I have a gps device attached to "serial" port. the Client class is reading this constantly (ok). BUT then i get NO mouse interaction!!! i think Client is hogging CPU and nothing else can happen....
any suggestions?
Some ideas:
Communication is like this:
GPS->serialPort->gpsd<->socket,qpegps
gpsd is a daemon (=> check if the daemonizing works..)
the socket of qpegps is event driven => data is read, if data arrives. gpsd sends data after receiving a request from qpegps. This request is sent in a fix intervall of 500ms.
Please try the new gpsd of version 0.9.1 (from a previous post I assume that You are still using a former gpsd version together with a workaround in the client => remove this workaround). I don't know the ADS Graphics Master, but I assume that it is not much slower than a Sharp Zaurus.
I don't have such a problem, if I start gpsd and qpegps in a Qtopia framebuffer on my (old) laptop (running linux, too).
The only thing I can think of is, that the mouse is somehow connected to the serial port of Your GPS.
You may also try to use a different port for the communication with gpsd (adjustable in qpegps and gpsd; and may be, that there is another program sending data to used port or...).
I have tried without using the mouse, but using touch screen. I have the same issue. When I change
void MapDisp::paintEvent( QPaintEvent *p )
{
/* pmc 6/2/03 this method is called for each "MapDisp->update()" AHHH!!
I think this is why the mouse interaction stops (mouse events cant get thru!)
*/
if (mBadpaint < 10) {
createMap();
mBadpaint++;
}
else {
QWidget::paintEvent( p );
}
bitBlt(this, 0, 0, mapdisp);
}
Then I do not loose control of the cursor. What I actually meant from the first was "Loss of cursor". sorry. The above code is NOT meant to be a "fix" for my problem. Just to help be diagnose. Do you have any suggestion as to what to do? (1) Have Client::socketReadyRead() emit newData(); "slower"? (2)have Qpegps::updateData() check lat/long and only call mapDisp->repaint(); if some predefined difference in values from last lat/long gathered by socketReadyRead()? (3) i am barking up the wrong tree and you have any other hint for me...
Whenever new data arrives from the gpsd, the new map is drawn (createMap) and the display is updated (bitBlt). The gpsd sends the data in a fix intervall (500ms) caused by a QTimer. You may try to change this to a higher value (10s for testing and up to 1s without loosing to much performance on the moving map => value is set in qpegps.cpp).
BTW I once had a test version, where the update intervall was calculated depending on the relation of speed and scale of the map => in theorie much better, but practically this causes only an improvement if You are using the wrong map for your movement (driving with a map for hiking, hiking with a street (car) map...).
One improvement would be, if createMap returns if the position (in pixels) has changed (except for pure altitude changes,Balloon,Heli;-)=> but then your cursor problem would depend on the current movement => a constant and unconditioned algrithm is much more reliable.
In client.cpp is a QPE_DEBUGTIMEDESC. You may use this, to analyse how long it takes to fetch the gps data and to draw the map (this is Qtopia specific, but there might be a similiar one for Qt/embedded or You write your own small function with gettimeofday).
If I'm completely wrong in this issue (e.g. setting the QTimer to 10s doesn't change anything) just post again and I'll think this over.
I changed time to 10s. There was an improvement.
Also changed MapDisp::createMap() to follow "if createMap returns if the position (in pixels) has changed". This works fine. I will deal with the "cursor problem would depend on the current movement" later; if it is a problem. Here is my code change:
if (lastPos.longitude && lastPos.longitude) {
double lastLg,lastLt;
/* pmc Return if no position change */
lastLg = lastPos.longitude * M_PI / 180.0;
lastLt = lastPos.latitude * M_PI / 180.0;
if (lastLg == lg && lastLt == lt) {
return;
}
}
lastPos.setLat(gpsData->currPos.latitude);
lastPos.setLong(gpsData->currPos.longitude);
etc...
And I left the 500ms for the GPS time. Thanks for your advice.
maria