Re: How to access the modem in QtMoko
robin spielr...@web.de writes: how do I communicate directly with the modem on /dev/ttySAC0? I'm not sure that question makes sense. When you're running QtMoko, there's a component somewhere inside QtMoko whose job it is to communicate with the modem, and it would be either impossible (because of locking) or unwise for some other code to try to communicate with the modem in parallel with that. If you switch QtMoko off (/etc/init.d/qtmoko stop), then you're left with a plain Debian squeeze system, and you can use any Debian squeeze tools you like to communicate with /dev/ttySAC0. For the direct acces I tried cu -l /dev/ttySAC0 as it is stated on the openmoko wiki site but I get 'cu command not found'. does anyone know which package I have to install and if it is still necessary to do chown uucp.uucp /dev/ttySAC0 to be able to access the modem? I don't know, but I typically investigate such questions by a combination of 'apt-cache search whatever' and searching. E.g. maybe searching for 'modem' or 'serial' at packages.debian.org would help. Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
QtMoko: how is long Power key press (= shutdown/restart menu) handled?
Sometimes my GTA04 gets into a state where the long Power key press is no longer recognised. I've tried to investigate this, but I can't see anything in the codebase that makes a link between a long Power key press and showing the shutdown/restart menu. Does anyone know how that happens? (This is running QtMoko git HEAD code, with Qt 4.8, so this problem might not affect any releases yet.) Thanks, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to access the modem in QtMoko
dear neil, thanks for your answer. the reason I wanted to try sending commands to the modem directly is that I have problems setting up my gprs connection with qtmoko. Now I have found one site http://www.gsmsite.de/gprs.htm where they state the AT-commands for manual modem configuration. So I wanted to try those out. Now I have found to the packages which is needed to be able to execute cu which is uucp. Now I can apparently connect to the modem with cu -l /dev/ttySAC0 as I get a connected statement printed on the screen after having set the right permissions. Then the whole terminal freezes, but not the phone. So I won't be able to send any AT commands. I guess this might be be explained by your answer: there can be only one for modem access... On the other hand I think that the openbmap logger and cellhunter allow to scan your main cell and neighbour cells and allow you to make calls as well, whilst they run (even though they might not do their scanning during the call). Generally speaking I would like to a) turn the modem off completely if I want to do GPS tracking only to save power b) scan main and neighbour cells and still be able to receive calls to bring my little progress on gsm-location also to qtmoko (works kind of in shr) c) try to send some at commands to see if I can do something to get my gprs working in qtmoko/shr so if anyone has some hints/ideas, please let me know. best regards robin ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to access the modem in QtMoko
On Saturday, December 01, 2012 07:12:41 AM robin wrote: how do I communicate directly with the modem on /dev/ttySAC0? For the direct acces I tried cu -l /dev/ttySAC0 as it is stated on the openmoko wiki site but I get 'cu command not found'. does anyone know which package I have to install and if it is still necessary to do chown uucp.uucp /dev/ttySAC0 to be able to access the modem? You can use apt-file search cu to find package where file with given name is. I am personally using minicom, it has nice gui and works very good. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko: how is long Power key press (= shutdown/restart menu) handled?
On Saturday, December 01, 2012 12:56:37 PM Neil Jerram wrote: Sometimes my GTA04 gets into a state where the long Power key press is no longer recognised. I've tried to investigate this, but I can't see anything in the codebase that makes a link between a long Power key press and showing the shutdown/restart menu. Does anyone know how that happens? Hi Neil, is this what you need? https://github.com/radekp/qtmoko/blob/master/devices/gta04/src/libraries/qtopiabase/etc/defaultbuttons.conf Radek PS: hope i will have some minutes now for your patches.. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko: how is long Power key press (= shutdown/restart menu) handled?
this would be nice to know so maybe something like short press - suspend medium press - ??? eg favourite program long press - shutdown/menu could be implemented. If I remember correctly android on freerunner has these three states for the power button. robin ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko: how is long Power key press (= shutdown/restart menu) handled?
Radek Polak pson...@seznam.cz writes: On Saturday, December 01, 2012 12:56:37 PM Neil Jerram wrote: Sometimes my GTA04 gets into a state where the long Power key press is no longer recognised. I've tried to investigate this, but I can't see anything in the codebase that makes a link between a long Power key press and showing the shutdown/restart menu. Does anyone know how that happens? Hi Neil, is this what you need? https://github.com/radekp/qtmoko/blob/master/devices/gta04/src/libraries/qtopiabase/etc/defaultbuttons.conf Yes, indeed, many thanks. My grep for shutdown didn't find this, because of how it's encoded here: HeldActionArgs=@ByteArray(\0\0\0\x1\0\0\0\n\0\0\0\0\x10\0s\0h\0u\0t\0\x64\0o\0w\0n) Radek PS: hope i will have some minutes now for your patches.. Thanks! Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to access the modem in QtMoko
Dear Radek, can you pass something like AT%EM=2,2 Serving Cell GPRS Information AT%EM=2,3 Neighbour Cell Information to minicom and get back the answer, so I could do somthing like this from my python prorgram: -- import subprocess neighbour_info_call = AT%EM=2,2 neighbour_info = subprocess.check_output(neigbourg_info_call, shell=True) print neighbour_info -- ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko: how is long Power key press (= shutdown/restart menu) handled?
robin spielr...@web.de writes: this would be nice to know so maybe something like short press - suspend We already have the lock icon for lock and suspend, so I'm not sure why we need this on the power key as well. Perhaps because you're thinking of wanting to suspend when looking at some application, and aren't on the home page? medium press - ??? eg favourite program long press - shutdown/menu Those are what we already have. Personally I'm not sure I could reliably distinguish between 3 press lengths... Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko audio state work
On Sunday, November 25, 2012 02:55:59 PM Neil Jerram wrote: After a day yesterday where the A3 audio didn't work for me in several calls, I decided to take a closer look at the QtMoko audio code. That led to a sequence of small (I think) cleanups, and a reworking of the audio state handling code, and I'd appreciate hearing what you think about that. I've pushed my work-in-progress branch to https://github.com/neiljerram/qtmoko/commits/nj, and the relevant commits are those from https://github.com/neiljerram/qtmoko/commit/0062faf815f5b1ede6624acac08bf3b 8ec7040bd to https://github.com/neiljerram/qtmoko/commit/958212671741685ae05de9e2564ea45 272f985d6 inclusive, excluding https://github.com/neiljerram/qtmoko/commit/18404194e37b85a315a64ae23b3ac97 e7dab3256. In summary, these changes: - remove code that I believe has no effect on the GTA04 - simply so as to make the audio-related code overall easier to understand - simplify and clarify the *AudioState classes and related code in neoaudioplugin.cpp - allow for different ALSA state files for A3 and A4 - rename the state files to match the QtMoko domain (Phone/Media) and profile (Headset/Speaker/Earpiece/Bluetooth) names - make the set of A3 state files more consistent with each other. Apart from the last point, all these changes should just be cleanups and have no practical effect. In particular, on A4 there should be no change at all. On A3 the last point may have a practical effect, if the previous switching of 'AVADC Clock Priority' and 'Voice route' values was sometimes causing a problem. I did a load of test calls this morning and had good audio on all of them. That might just be good luck - or it might indicate that that last point really does make a difference for A3. I guess I'll know better after a bit more experience. Anyway, I'd appreciate hearing if you think this line of work looks worthwhile, or any other thoughts you or others have about it. Yup it looks ok, will test it later but it's alreaady pulled in my git. Thanks! Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to access the modem in QtMoko
robin spielr...@web.de writes: dear neil, thanks for your answer. the reason I wanted to try sending commands to the modem directly is that I have problems setting up my gprs connection with qtmoko. Now I have found one site http://www.gsmsite.de/gprs.htm where they state the AT-commands for manual modem configuration. So I wanted to try those out. Is this with a Freerunner? Do other Freerunner users have GPRS working? If so I'd suggest logging and comparing your log with theirs. be explained by your answer: there can be only one for modem access... On the other hand I think that the openbmap logger and cellhunter allow to scan your main cell and neighbour cells and allow you to make calls as well, whilst they run (even though they might not do their scanning during the call). Are openbmap and cellhunter implemented yet for QtMoko? I thought they were implemented for FSO-based distributions only - i.e. SHR and FSO-based Debian - and in that case the access to the modem is managed by FSO. Generally speaking I would like to a) turn the modem off completely if I want to do GPS tracking only to save power Yes, that would be a useful feature. b) scan main and neighbour cells and still be able to receive calls to bring my little progress on gsm-location also to qtmoko (works kind of in shr) I think there are pieces of QtMoko that do that scanning, so the question would be how to connect those with your work. I'll try to look into that a bit more. Regards, Neil ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko audio state work
Radek Polak pson...@seznam.cz writes: Yup it looks ok, will test it later but it's alreaady pulled in my git. Thanks. Given that, I think it's worth me writing a bit more about where/how my work is going, and there's one bugfix below that you should cherry-pick: please look for While doing that I noticed a bug. Apart from that bugfix I don't want to make any assumptions about what time you have to consider this, so please feel free to leave the rest of this hanging for now. But if you do have time and thoughts I'm sure those would be useful, and in any case it's helpful for me to lay out my thoughts. Firstly, I've just pushed some more commits to https://github.com/neiljerram/qtmoko/commits/nj. These are mostly NOT suitable for your Git master, so please don't pull them, but they may help show what I'm doing. First, my previous set of commits _didn't_ make audio in calls any more reliable. My initial tests were just lucky, and in the days after that I had some calls with no audio, the same as before my cleanups. (In fact that was as expected, because the 'cleanups' didn't really fix anything.) Then I looked for a while at the gta04-gsm-voice-routing code. Empirically, - this code often works - giving clear audio - but sometimes fails catastrophically and gives no audio at all - it seems to fail more often when an incoming call causes the phone to wake up from suspend. My guess is that there is an instability in that code which is more likely to strike when other things on the phone are using CPU - such as just after waking from suspend. Perhaps it could something like this: - CPU load causes gta04-gsm-voice-routing to be slow to read the capture devices, so they report overruns - that may cause the code to loop round and try reading those devices again - which now blocks until time has passed to allow more data to be there - when the code eventually gets to the playback devices, too much time has passed, so they report underrun and don't actually play any data - etc. Then I looked at the alsaloop code and my first impression there was how much more complex it is... Putting everything together, my feeling is that this (loopback) is trickier than it looks to get right, and that gta04-gsm-voice-routing sometimes fails because it doesn't cover all the possible variations. So then I looked at pulseaudio, found Neil Brown's old suggestion, upgraded to the testing version, and eventually stumbled across the resampler method change that makes that work (per other email). I've now integrated that in my code: https://github.com/neiljerram/qtmoko/commit/9f78985e8119961cc520e4d050c88bf1e589b879 I then had to make another change to /etc/pulse/daemon.conf: -; realtime-scheduling = yes + realtime-scheduling = no to avoid pulseaudio being killed by the kernel just after starting the loopback. I guess this is the same basic problem as SHR had with alsaloop here: http://lists.goldelico.com/pipermail/gta04-owner/2012-May/002383.html and ideally the fix would be in pulseaudio to initially spin more slowly. But the realtime-scheduling change works too and doesn't impact general media playback too badly (for my taste). But after that, the integrated pulseaudio in-call audio routing seems to work. Of course I'll be more confident about it if I can have a week of it working every time... While doing that I noticed a bug in my previous Rework ALSA state / QAudioState handling commit: it will call gsmVoiceStart() and gsmVoiceStop() even for A4 devices. That's fixed by https://github.com/neiljerram/qtmoko/commit/a362c431531d6b75fcb1894c60e021588ea50d44 so that's one commit that you _should_ cherry-pick. Next what I'd like to do is to make everything louder! There are 3 things that aren't loud enough at the moment: a) the ringtone b) the in-call audio that I hear from the other person c) the in-call audio that the other person hears from me. (b) and (c) depend on good echo cancellation, and I'm hoping pulseaudio's module-echo-cancel will do that for me. I think I can test that, without needing lots of phone calls, simply by playing something (from file) through the earpiece or speaker and simultaneously recording from the microphone. If that works well, we can then just increase all the volumes in the state files. (BTW I think that the Speex echo cancellation in gta04-gsm-voice-routing was less effective because of the playback buffer being 4 times the frame size. This means that when the code sends frame X to ALSA for playback, frame X doesn't actually start playing until 3 cycles later. Therefore we can't immediately use frame X to cancel echo in the microphone sound that we're capturing _now_. I wonder if there was a time when the code had buffer size = frame size, and the buffer size was later increased?) Finally, if all of the above works, we can look at whether it all _still_ works with the squeeze version of pulseaudio. Hopefully eventually the software audio
Re: QtMoko audio state work
On Saturday, December 01, 2012 06:15:04 PM Neil Jerram wrote: Given that, I think it's worth me writing a bit more about where/how my work is going, and there's one bugfix below that you should cherry-pick: please look for While doing that I noticed a bug. Apart from that bugfix I don't want to make any assumptions about what time you have to consider this, so please feel free to leave the rest of this hanging for now. But if you do have time and thoughts I'm sure those would be useful, and in any case it's helpful for me to lay out my thoughts. Hmm i plan some relaxing now ;-) But after that, the integrated pulseaudio in-call audio routing seems to work. Of course I'll be more confident about it if I can have a week of it working every time... Very nice. While doing that I noticed a bug in my previous Rework ALSA state / QAudioState handling commit: it will call gsmVoiceStart() and gsmVoiceStop() even for A4 devices. That's fixed by https://github.com/neiljerram/qtmoko/commit/a362c431531d6b75fcb1894c60e0215 88ea50d44 so that's one commit that you _should_ cherry-pick. done Next what I'd like to do is to make everything louder! yup, that would be nice There are 3 things that aren't loud enough at the moment: a) the ringtone b) the in-call audio that I hear from the other person c) the in-call audio that the other person hears from me. (b) and (c) depend on good echo cancellation, and I'm hoping pulseaudio's module-echo-cancel will do that for me. I think I can test that, without needing lots of phone calls, simply by playing something (from file) through the earpiece or speaker and simultaneously recording from the microphone. If that works well, we can then just increase all the volumes in the state files. (BTW I think that the Speex echo cancellation in gta04-gsm-voice-routing was less effective because of the playback buffer being 4 times the frame size. This means that when the code sends frame X to ALSA for playback, frame X doesn't actually start playing until 3 cycles later. Therefore we can't immediately use frame X to cancel echo in the microphone sound that we're capturing _now_. I wonder if there was a time when the code had buffer size = frame size, and the buffer size was later increased?) Hmm it was long time ago. IIRC with small buffer size it was not working - but i cant recall the details. :( Finally, if all of the above works, we can look at whether it all _still_ works with the squeeze version of pulseaudio. Hopefully eventually the software audio routing can be good enough for A3 audio quality to be on a par with A4. Yes that would be nice. And even A4 could benefit this - e.g. for recording phone calls. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to access the modem in QtMoko
hi neil, openbmap and cellhunter use fso to access the modem, and at least in openbmaps code I have found a bit which checks if the modem is used by some other process and if not allows you to do the scanning of the main and neighbour cells. even if this becomes a bit off topic now, regarding the gsm-based location I am working on, I think that something similar could/must exist in qtmoko to get this information as already with mokofaen we have the lac and cellid of the serving cell being displayed on the home screen. this information already gives you a circular area around the serving cell where your phone is currently located in steps of 555m; so that is not too bad for a start. having neighbours or even being able to connect to other operators using roaming but to get their nearest cell would be the best and easiest way to narrow the position down even more. --- so this is the part where I am wondering how to access this information in qtmoko, also if possible via at commands and getting the return information processed by python, which is not as nicely as with fso but it should work. for my other intends on how to investigate further why gprs is not working for my freerunner it would nonetheless be nice to have a simple way to try at commands. and in the end just use at commands to eg save power by shuting the modem down if you go to bed and don't want to be disturbed but still have a phone which wakes you up, as suspend in qtmoko works only from suspend mode only but not from turned off mode (some time delay problem). best regards and many thanks to you and radek as well and the other developers who do an amazing job (qtmoko/shr/androdi) + golden del for having the guts to go for a gta04!!! robin ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko: how is long Power key press (= shutdown/restart menu) handled?
Neil Jerram neil at ossau.homelinux.net writes: robin spielraum at web.de writes: this would be nice to know so maybe something like short press - suspend We already have the lock icon for lock and suspend, so I'm not sure why we need this on the power key as well. Perhaps because you're thinking of wanting to suspend when looking at some application, and aren't on the home page? medium press - ??? eg favourite program long press - shutdown/menu Those are what we already have. Personally I'm not sure I could reliably distinguish between 3 press lengths... Neil I quite like being able to bring the phone back from suspend with a quick press on the powerbutton, checking what time it is and then sending it back to suspend with another quick press on the power button (but this is the standard way qtmoko does it if I am not being mistaken, or in which state does qtmoko turn if I just do a quick press on the power button; I thought it goes to suspend?!?). As the freerunner has only two hardware buttons and the aux button is reported to break sometimes, it might be a good idea to have three press duration specific settings for the power button. One idea could also be to have something like this as standard: a) 1s - suspend b) 1s 4s - show shutdown/reboot dialog c) 4s - show shutdown/reboot dialog and this behaviour being read from a text config file. so anyone who needs the b) slot to do something differently could just change it to fit his/her needs. best regards robin ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to access the modem in QtMoko
On Saturday, December 01, 2012 11:36:03 PM robin wrote: even if this becomes a bit off topic now, regarding the gsm-based location I am working on, I think that something similar could/must exist in qtmoko to get this information as already with mokofaen we have the lac and cellid of the serving cell being displayed on the home screen. this information already gives you a circular area around the serving cell where your phone is currently located in steps of 555m; so that is not too bad for a start. having neighbours or even being able to connect to other operators using roaming but to get their nearest cell would be the best and easiest way to narrow the position down even more. --- so this is the part where I am wondering how to access this information in qtmoko, also if possible via at commands and getting the return information processed by python, which is not as nicely as with fso but it should work. You can try /opt/qtmoko/bin/vsexplorer to browse all valuespace items - these are the ones displayed on home screen by themes. Themes are in /opt/qtmoko/etc so you can find in the xml which are the values for cell ids. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
