Re: [Qt Extended] Mapping Demo (was Re: [FSO] Stability and other problems)
Michael 'Mickey' Lauer wrote:
Am Wednesday 19 November 2008 12:18:28 schrieb superalex:
Hi, I'm using FSO since yesterday and found that the famous echo bug was
still appearing. I found a solution that is working for me based in the
2008.8 one.
In file
/usr/lib/python2.5/site-packages/framework/subsystems/ogsmd/modems/ti_calyp
so/unsolicited.py, function percentCPI, line 210 aprox
Where it says:
info = {}
I have:
devchannel =
self._object.modem.communicationChannel(DeviceMediator)
devchannel.enqueue( %N0187 )
info = {}
Guess we should make this configurable, FSO is using -6db, not -12db since
this sounds pretty harsh for many people.
That's a good idea, but I think the issue may be a bit different. With
Qtopia people were reporting no echo for the first call, but echo on
subsequent calls. Since we're using an undocumented feature of the modem
we don't know under what conditions it might be disabled, even though we
don't disable it explicitly. Currently we only set the echo suppression
in init, while this patch sets it on every call state transition. It may
be worth moving it down a few lines so it only happens when a call
connects, but this way we can be certain that echo suppression is
enabled for every call.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [Qt Extended] Mapping Demo (was Re: [FSO] Stability and other problems)
Well, I suppouse it may be better and it's more logical to execute the command only when a call connects but I was doing some testing and found that worked better setting the echo supression on every transition :) Guess we should make this configurable, FSO is using -6db, not -12db since this sounds pretty harsh for many people. That's a good idea, but I think the issue may be a bit different. With Qtopia people were reporting no echo for the first call, but echo on subsequent calls. Since we're using an undocumented feature of the modem we don't know under what conditions it might be disabled, even though we don't disable it explicitly. Currently we only set the echo suppression in init, while this patch sets it on every call state transition. It may be worth moving it down a few lines so it only happens when a call connects, but this way we can be certain that echo suppression is enabled for every call. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- View this message in context: http://n2.nabble.com/-FSO--Stability-and-other-problems-tp1479821p1557654.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Qt Extended] Mapping Demo (was Re: [FSO] Stability and other problems)
Hi, I'm using FSO since yesterday and found that the famous echo bug was
still appearing. I found a solution that is working for me based in the
2008.8 one.
In file
/usr/lib/python2.5/site-packages/framework/subsystems/ogsmd/modems/ti_calypso/unsolicited.py,
function percentCPI, line 210 aprox
Where it says:
info = {}
I have:
devchannel =
self._object.modem.communicationChannel(DeviceMediator)
devchannel.enqueue( %N0187 )
info = {}
--
View this message in context:
http://n2.nabble.com/-FSO--Stability-and-other-problems-tp1479821p1518706.html
Sent from the Openmoko Community mailing list archive at Nabble.com.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [Qt Extended] Mapping Demo (was Re: [FSO] Stability and other problems)
Am Wednesday 19 November 2008 12:18:28 schrieb superalex:
Hi, I'm using FSO since yesterday and found that the famous echo bug was
still appearing. I found a solution that is working for me based in the
2008.8 one.
In file
/usr/lib/python2.5/site-packages/framework/subsystems/ogsmd/modems/ti_calyp
so/unsolicited.py, function percentCPI, line 210 aprox
Where it says:
info = {}
I have:
devchannel =
self._object.modem.communicationChannel(DeviceMediator)
devchannel.enqueue( %N0187 )
info = {}
Guess we should make this configurable, FSO is using -6db, not -12db since
this sounds pretty harsh for many people.
--
:M:
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [Qt Extended] Mapping Demo (was Re: [FSO] Stability and other problems)
On Wed, Nov 12, 2008 at 08:23, Chris Samuel [EMAIL PROTECTED] wrote: Ahh, but if you have an Internet connection live it will fetch the tiles from Google Maps and plot you on there! To show this get your FR online and then run the Mapping Demo with the sample dataset (just an NMEA log file) and watch it follow the person on Google Maps. What it doesn't do is cache those images, which would be rather neat if you could pre-populate with them, but then it is just a demo and the source is there to be hacked with.. ;-) Though I fear Google Maps terms of use do not allow to cache their maps. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Qt Extended] Mapping Demo (was Re: [FSO] Stability and other problems)
Though I fear Google Maps terms of use do not allow to cache their maps. There's OpenStreetMap's, then :) -- Olivier ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Qt Extended] Mapping Demo (was Re: [FSO] Stability and other problems)
- Cédric Berger [EMAIL PROTECTED] wrote: Though I fear Google Maps terms of use do not allow to cache their maps. Hmm, I'd not heard about that, the legal information on the Google site is the usual unclear legalese that, if taken literally, could mean that any browser that caches the images could infringe them (depending on which countries data you are looking at). http://www.google.com/help/legalnotices_maps.html They've tried to summarise it here, but it's still not that clear to me: http://www.google.com/help/terms_maps.html So probably the safest thing to do then is not use them.. :-( -- Chris Samuel : http://www.csamuel.org/ : Melbourne, VIC ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
