Re: Staus update GTA04A5
On Tue, 12 May 2015 11:25:27 +0200 "Dr. H. Nikolaus Schaller" wrote: > Hi, > > Am 12.05.2015 um 11:18 schrieb NeilBrown : > > > On Mon, 11 May 2015 09:37:07 +0200 Dr. H. Nikolaus Schaller > > wrote: > > > >> Hi all, > >> you may wonder what is going on with this project. Did it turn into a > >> black hole? Or > >> did someone do a “rm -rf /“ :) > >> > >> No, nothing of that. Therefore, I think we owe you some short status > >> update on this project. > >> > >> There hasn’t been much to report in the last months, but now we have > >> several news > >> within some days. > >> > >> 1. I have checked again and we can still get the GTM601W, but the > >> distributor says > >>the risk is high that OPTION declares EOL any time and in that case we > >> would have > >>to make an order of at least 3000 units so that they restart production > >> just for us. > >> > >> This means we must secure these modules for us now, since there is no > >> replacement > >> that easily fits into the space constraints of the GTA04 (resp. GTA01/02 > >> board). > >> > >> Cinterion modules would be nice since they are planned for the Pyra and > >> the Neo900, > >> but they are approx. 10% too big. > >> > >> 2. we see some difficulties in getting the W2SG0084 GPS module, but that > >> is some > >>paperwork the distributor has to do with Wi2Wi. > >> > >> Nevertheless, this is also a risk candidate for EOL because only one > >> distributor shows > >> stock. > >> > >> 3. There are also good news: > >>we participate in the risk buy of Samsung 1GB RAM+512MB NAND chips (as > >>planned for the Neo900). So the GAT04A5 gets twice as much RAM :) > >> > >>This chip has already been tested by reworking a BeagleBoard XM and > >> modifying > >>the boot loader (kernel didn’t find the NAND yet, but U-Boot did. This > >> is a problem > >>that will jointly be fixed with the Neo900 software team). > >> > >> 4. Production: we still are a little away from the quorum of 100 preorders > >> (at the > >>moment of this writing we have estimated approx. half = 45 units). So > >> it is still > >>not possible to make final decisions about production dates and final > >> pricing. > >> > >>So we need to get a little more support for our project. If you have > >> ideas, please > >>let us know or start activities. Many small activities are as good as a > >> big one! > >>And we know that this is a niche product that requires an existing > >> GTA01/02 > >>device. So it is not possible to “attract the masses”. We must find and > >> convince > >>the previous GTA01/02 owners whose devices are collecting dust. There > >> had been > >>produced ca. 15k such devices so that we just need another 1/3% or in > >> other > >>words only 1 out of 300 GTA02 owners needs to decide for a GTA04A5. > >> > >> 5. Regarding the risk buy of the GTM601W, RAM chips and W2SG0084, I plan to > >>take the budget (~5100 EUR) that we already have collected. > >> > >>This will transform the vouchers into ownership of components. So it > >> has the > >>consequence that we can’t refund in money (cash, bank transfer) any > >> more, but > >>only in unused hardware components (i.e. 100 EUR ~ > >> 1*GTM601+1*RAM+1*GPS)… > >> > >>For future preorder vouchers you would also buy such a component set > >> (which we > >>would keep in safe warehouse of course) until we can really build the > >> whole devices. > >> > >> > >> So quite some news and I would be happy if we can fill up the missing > >> preorders [1] > >> sooner than later so that we can start production. Please think about > >> securing your > >> set of components for the last production batch of the most open > >> smartphone platform > >> that we already have. > >> > > > > I have been thinking about ordering a GTA04A5, but there is one barrier. > > I need to be confident that it can draw less than 10mA in standby. > > > Currently the best we have seen with GTA04A3,4 is about 20mA (and 40mA on > > Linux 4.0, but that must
Re: Staus update GTA04A5
On Mon, 11 May 2015 09:37:07 +0200 Dr. H. Nikolaus Schaller wrote: > Hi all, > you may wonder what is going on with this project. Did it turn into a black > hole? Or > did someone do a “rm -rf /“ :) > > No, nothing of that. Therefore, I think we owe you some short status update > on this project. > > There hasn’t been much to report in the last months, but now we have several > news > within some days. > > 1. I have checked again and we can still get the GTM601W, but the distributor > says > the risk is high that OPTION declares EOL any time and in that case we > would have > to make an order of at least 3000 units so that they restart production > just for us. > >This means we must secure these modules for us now, since there is no > replacement >that easily fits into the space constraints of the GTA04 (resp. GTA01/02 > board). > >Cinterion modules would be nice since they are planned for the Pyra and > the Neo900, >but they are approx. 10% too big. > > 2. we see some difficulties in getting the W2SG0084 GPS module, but that is > some > paperwork the distributor has to do with Wi2Wi. > >Nevertheless, this is also a risk candidate for EOL because only one > distributor shows >stock. > > 3. There are also good news: > we participate in the risk buy of Samsung 1GB RAM+512MB NAND chips (as > planned for the Neo900). So the GAT04A5 gets twice as much RAM :) > > This chip has already been tested by reworking a BeagleBoard XM and > modifying > the boot loader (kernel didn’t find the NAND yet, but U-Boot did. This is > a problem > that will jointly be fixed with the Neo900 software team). > > 4. Production: we still are a little away from the quorum of 100 preorders > (at the > moment of this writing we have estimated approx. half = 45 units). So it > is still > not possible to make final decisions about production dates and final > pricing. > > So we need to get a little more support for our project. If you have > ideas, please > let us know or start activities. Many small activities are as good as a > big one! > And we know that this is a niche product that requires an existing > GTA01/02 > device. So it is not possible to “attract the masses”. We must find and > convince > the previous GTA01/02 owners whose devices are collecting dust. There had > been > produced ca. 15k such devices so that we just need another 1/3% or in > other > words only 1 out of 300 GTA02 owners needs to decide for a GTA04A5. > > 5. Regarding the risk buy of the GTM601W, RAM chips and W2SG0084, I plan to > take the budget (~5100 EUR) that we already have collected. > > This will transform the vouchers into ownership of components. So it has > the > consequence that we can’t refund in money (cash, bank transfer) any more, > but > only in unused hardware components (i.e. 100 EUR ~ 1*GTM601+1*RAM+1*GPS)… > > For future preorder vouchers you would also buy such a component set > (which we > would keep in safe warehouse of course) until we can really build the > whole devices. > > > So quite some news and I would be happy if we can fill up the missing > preorders [1] > sooner than later so that we can start production. Please think about > securing your > set of components for the last production batch of the most open smartphone > platform > that we already have. > I have been thinking about ordering a GTA04A5, but there is one barrier. I need to be confident that it can draw less than 10mA in standby. Currently the best we have seen with GTA04A3,4 is about 20mA (and 40mA on Linux 4.0, but that must be a software issue). This is probably a software issue, but until it's actually been demonstrated that the hardware can sit in standby using under 10mA, I cannot be certain. It's all very frustrating... NeilBrown pgpn6StQqhjj9.pgp Description: OpenPGP digital signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Problem mounting a nfs directory
On Wed, 29 Jan 2014 18:26:11 +0100 Giacomo 'giotti' Mariani wrote: > On 01/29/2014 06:02 PM, Giacomo 'giotti' Mariani wrote: > > Hello everyone, > > in order to compile something on my freerunner I'd like to use for > > that a nfs directory+chroot. > > > > I edited fstab accordingly and tried to mount: > > > > root@neo:/mnt/nfs# mount `pwd` > > mount: wrong fs type, bad option, bad superblock on > > 192.168.0.200:/home/jack/Programmazione/Openmoko/Distros/QtMoko/CHROOT/, > >missing codepage or helper program, or other error > >(for several filesystems (e.g. nfs, cifs) you might > >need a /sbin/mount. helper program) > >In some cases useful info is found in syslog - try > >dmesg | tail or so > > > > Consequently I tried to install nfs-common, but: > > > > root@neo:/mnt/nfs# apt-get install nfs-common > > Reading package lists... Done > > Building dependency tree > > Reading state information... Done > > The following NEW packages will be installed: > > nfs-common > > 0 upgraded, 1 newly installed, 0 to remove and 2 not upgraded. > > Need to get 0 B/180 kB of archives. > > After this operation, 623 kB of additional disk space will be used. > > Selecting previously unselected package nfs-common. > > (Reading database ... 12006 files and directories currently installed.) > > Unpacking nfs-common (from .../nfs-common_1%3a1.2.6-4em1_armel.deb) ... > > Setting up nfs-common (1:1.2.6-4em1) ... > > > > Creating config file /etc/idmapd.conf with new version > > > > Creating config file /etc/default/nfs-common with new version > > [FAIL] Starting NFS common utilities: statd idmapd failed! > > invoke-rc.d: initscript nfs-common, action "start" failed. > > dpkg: error processing nfs-common (--configure): > > subprocess installed post-installation script returned error exit status 1 > > Errors were encountered while processing: > > nfs-common > > E: Sub-process /usr/bin/dpkg returned an error code (1) > > > > > > I googled and tried some stuff like "apt-get install portmap" or > > "apt-get install -f", but with no results. > > Do you have any suggestion? > > > > Thanks a lot, > > Giacomo > > > I've to correct myself, sorry. > > If I do: > > root@neo:/mnt/nfs# mount.nfs > 192.168.0.200:/home/jack/Programmazione/Openmoko/Distros/QtMoko/CHROOT/ > /mnt/nfs/ > > It mounts "well": > > root@neo:/mnt/nfs# mount > [...] > 192.168.0.200:/home/jack/Programmazione/Openmoko/Distros/QtMoko/CHROOT > on /mnt/nfs type nfs4 > (rw,relatime,vers=4,rsize=524288,wsize=524288,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=192.168.0.202,minorversion=0,local_lock=none,addr=192.168.0.200) > > But there is something that does not seem to work as I expect: even if > /home/jack/Programmazione/Openmoko/Distros/QtMoko/CHROOT it's not empty: > > root@neo:/mnt/nfs# ls > root@neo:/mnt/nfs# > > and, viceversa, if I create a file on the neo I can't see it on the laptop. > Moreover, when I umount it, the file are still there and, even if the > remote directory is mounted looking at "df" the FS space used is from > rootfs :-( > > Thanks, > Giacomo > Hi Giaomo. If you simples "cd /mnt/nfs", it should start working. Your current directory is some directory on the root filesystem. When you mount an NFS directory on top of that it doesn't change your current directory. However if you use the full name for the directory you have mounted - "/mnt/nfs" - then that will lead you to the mounted directory, not your current directory. I hope that makes sense. NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Community] GTA04A5 ready to be pre-ordered
On Thu, 7 Nov 2013 18:14:48 +0100 "Dr. H. Nikolaus Schaller" wrote: > > Am 07.11.2013 um 00:02 schrieb NeilBrown: > > > On Wed, 23 Jan 2013 12:20:01 +0100 "Dr. H. Nikolaus Schaller" > > wrote: > > > > Seeing you are considering trying again for the GTA04a5, I thought I might > > re-visit these issues: > > > > > >> > >> Am 22.01.2013 um 12:29 schrieb NeilBrown: > >> > >>> On Tue, 22 Jan 2013 10:02:38 +0100 "Dr. H. Nikolaus Schaller" > >>> wrote: > >>> > >>> > >>>> Preliminary (there may still come minor changes coming from PCB > >>>> Layout tuning and from first production feedback) schematics can be > >>>> found here: > >>>> > >>>> <http://projects.goldelico.com/p/gta04-main/downloads/48/> > >>> > >>> Thanks! > >>> > >>> One thing that has always bothered me a little bit is that the FM > >>> transceiver > >>> is wired for digital IO rather than analog. That means that the CPU > >>> needs to > >>> be active to copy sound around in order to listen to the radio. If the > >>> LOUT/ROUT pins were connected to the line-in pins on the audio chip you > >>> should be able to listen to the radio with the CPU off. > >> > >> Yes, that should be possible. > >> > >>> It would mean that you couldn't get the same fidelity if you wanted a > >>> digital > >>> copy of the broadcast, but I wonder if that really matters. > >>> > >>> What is the expected use-case of the FM radio? If it is just for > >>> listening > >>> to, the current config doesn't seem to be optimal. > >> > >> Well, the TX direction is more interesting since it can play sound (incl. > >> navigation > >> information) to a car radio. By using text2speech. And mix with sound. > >> > >> Connecting to the Audio in is a problem since we have already connected > >> them > >> to the headset jack. So that it is possible to record sound fed into the > >> headset > >> jack. I.e. portable audio recorder... > > > > Is the "portable audio recorder" use case more valuable than the "FM radio > > without excessive power usage" use case? I would be happy to sacrifice the > > stereo-aux-in if it meant I could listen to the radio for longer. > > > > For the price of another analogue switch like the one you use to isolate the > > headset outputs (U703) you could support both FM and AUX inputs. Maybe that > > price is too high?? > > I will check. It is probably less a cost issue (such chips are around 50ct) > but space > and (shielded) wiring. But since headset jack and the Si4721 are not far away > from each other it could work. > > > > >> > >> And the FM-analog out are multiplexed with the digital interface on the > >> Si4721. > >> So we would need some analog/digital switching circuits where we don't have > >> space for :( > > > > I wouldn't suggest enabling both the analogue and digital interfaces. Just > > the analogue. Digital might be nice but isn't really necessary. > > Well, it gives a better S/N since the signals are already A/D converted in > the Si4721 > and just need to be arecord >file if you want to capture signals. I'm willing to accept that the A/D converter in the Si4721 will suffer less noise than the A/D in the twl4030 as the analogue signal travels a shorter distance. But I would be surprised if it were noticeable. With the FM sound coming through the TWL4030 you would only need an extra "alsactl restore -f 'fmradio'" before "arecord > file" would work. > > > > > > >> > >>> Related: have you thought about connecting the bluetooth PCM interface > >>> directly to the TPS chip in the same way that the Modem's PCM interface is > >>> connected? > >>> > >>> That should allow the use of a bluetooth headset on a phone call without > >>> any > >>> CPU intervention. > >> > >> Yes, that could work to add these 2 wires (at least in the schematics - I > >> don't > >> know if we can squeeze them into the PCB wire hairball). And I have checked > >> that these two pins at the TPS65950 come up in GPIO (input) mode, i.e. > >> don't interfere. > >> > >
Re: [Community] GTA04A5 ready to be pre-ordered
On Wed, 23 Jan 2013 12:20:01 +0100 "Dr. H. Nikolaus Schaller" wrote: Seeing you are considering trying again for the GTA04a5, I thought I might re-visit these issues: > > Am 22.01.2013 um 12:29 schrieb NeilBrown: > > > On Tue, 22 Jan 2013 10:02:38 +0100 "Dr. H. Nikolaus Schaller" > > wrote: > > > > > >> Preliminary (there may still come minor changes coming from PCB > >> Layout tuning and from first production feedback) schematics can be found > >> here: > >> > >><http://projects.goldelico.com/p/gta04-main/downloads/48/> > > > > Thanks! > > > > One thing that has always bothered me a little bit is that the FM > > transceiver > > is wired for digital IO rather than analog. That means that the CPU needs > > to > > be active to copy sound around in order to listen to the radio. If the > > LOUT/ROUT pins were connected to the line-in pins on the audio chip you > > should be able to listen to the radio with the CPU off. > > Yes, that should be possible. > > > It would mean that you couldn't get the same fidelity if you wanted a > > digital > > copy of the broadcast, but I wonder if that really matters. > > > > What is the expected use-case of the FM radio? If it is just for listening > > to, the current config doesn't seem to be optimal. > > Well, the TX direction is more interesting since it can play sound (incl. > navigation > information) to a car radio. By using text2speech. And mix with sound. > > Connecting to the Audio in is a problem since we have already connected them > to the headset jack. So that it is possible to record sound fed into the > headset > jack. I.e. portable audio recorder... Is the "portable audio recorder" use case more valuable than the "FM radio without excessive power usage" use case? I would be happy to sacrifice the stereo-aux-in if it meant I could listen to the radio for longer. For the price of another analogue switch like the one you use to isolate the headset outputs (U703) you could support both FM and AUX inputs. Maybe that price is too high?? > > And the FM-analog out are multiplexed with the digital interface on the > Si4721. > So we would need some analog/digital switching circuits where we don't have > space for :( I wouldn't suggest enabling both the analogue and digital interfaces. Just the analogue. Digital might be nice but isn't really necessary. > > > Related: have you thought about connecting the bluetooth PCM interface > > directly to the TPS chip in the same way that the Modem's PCM interface is > > connected? > > > > That should allow the use of a bluetooth headset on a phone call without any > > CPU intervention. > > Yes, that could work to add these 2 wires (at least in the schematics - I > don't > know if we can squeeze them into the PCB wire hairball). And I have checked > that these two pins at the TPS65950 come up in GPIO (input) mode, i.e. > don't interfere. > > One issue could be that there is no BSP clock for that interface on the TPS > side. > I.e. it is shared with some other interface and I am not sure how to operate > it correctly. > So we might have to wire up something else to really make it work. The clock for the bluetooth interface and the voice interface are shared. So the clock from the GSM module drives the whole chain from bluetooth through TWL4030 to GSM. > > > Just thinking out loud - looking forward to the A5 being a reality! > > So I find both proposals really good, but I hesitate to add them... may need > a lot > of work to add, and may finally not work. The problem with hardware is that > we have to do it 100% right or risk scrapping a big set of PCBs or costly > rework > in the production line. Unfortunately there is no apt-get upgrade or git pull > for > the wires on a PCB... :-) I'm waiting for the day when a 3D printer can print a fully populated multi-layer PCB (under voice command of course). Maybe in the spirit of openness a vote might be instructive. Does anyone actually want stereo aux input through the 2.5mm jack? Does anyone actually want to listen to the FM radio without wasting power? (no and yes for me). Thanks, NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Battery graphs - was Re: Crowdfunding an Ubuntu smartphone
On Tue, 27 Aug 2013 09:46:12 +1000 NeilBrown wrote:
> On Sat, 24 Aug 2013 15:31:19 +0200 "Dr. H. Nikolaus Schaller"
> wrote:
>
> > Hm. That sounds quite different from the situation about 1 year ago when
> > you did the first releases of QtMoko and I always thought that the
> > 3.7 kernel is working well enough, so that I started to add new features.
> >
> > Has it become worse since then?
>
> I like drawing graphs. So I did - see attachment.
>
> For the last year or so my GTA04 has been logging the power usage during
> suspend for every suspend cycle longer than a few seconds. I do this by
> reading the "charge_now" value from the bq27000 in the battery, comparing the
> "before" and "after" values, and dividing by the number of seconds.
>
> I currently have my phone configured to wake from suspend every 5 minutes,
> check that the modem is still working, and go back to suspend. This has
> helped collect quite a lot of values.
>
> To get the graphs I collected all those values, discarded negative numbers
> (when the battery was charging) and a few numbers that were clearly
> ridiculous (numbers more than 1 amp), and sorted the remainder.
>
>
> So we get a cumulative frequency graph of different current levels.
>
> The red line ('/tmp/uamp') is for the last couple of days since last reboot.
> This is running 3.7 with offmode disabled.
> The green line ('tmp/uamp2') is for the last year, running a variety of
> different kernels.
>
> Obviously there is a very different number of samples in each. 342 in uamp
> 10031 in uamp2. So I normalised the X values so the graphs are comparable.
> They are much the same shape which suggests the pattern is fairly robust.
>
> The Y axis is microamps.
> The green values below 2 (20mA) are with offmode enabled I assume.
> The red values are all greater because I have offmode turned off to improve
> reliability.
>
> The steps are a bit of a surprise. They are all about 2mA. I don't think
> this is an artefact of the precision with which measurements are taken as the
> charge value read from the battery has a much higher precision.
> I think it must be an actual 2mA difference in (average) current usage.
> This could be 2mA more for the whole time, or 4mA more with a 50% duty cycle
> etc.
>
> So if we can make off-mode really usable (which possibly means find and fix
> some bug in the omap usb code) and if we can find out what is causing these
> 2mA steps and resolve that, then might might be a little closer to
> acceptable power usage.
>
> I might try running for a while with the modem turned off and see what result
> I get.
>
Here are results with modem powered off.
1/ The minimum current is higher!!! without the modem at work. - 28mA rather
than 24mA.
2/ The maximum is much lower. 36mA vs 97mA.
3/ We still see a 2mA step. Most of the values are 30mA or 32mA. A few are
2mA lower, or 2,4,6 mA higher (roughly).
This is very strange. The very rare high values when modem is working are
quite believable. The steps and the high minimum are harder to explain.
Suppose some parallel bi-directional buss ended up in suspend with both ends
driving outputs. Suppose also that if they were driving the same value it
would cause minimal current drain, but if they were driving different values
it would cause 2mA drain on each line that was unbalanced.
Then if the actual output bits on one side were random as we enter suspend,
we would see a range of different multiples of 2mA in current drain.
If this parallel bus were related to the modem, then when the modem wasn't
in use we would see much less variability. But maybe higher average as some
bits might stuck on a "bad" value.
Now there is a bi-directional bus between the OMAP and the USB PHY. But I
would be very surprised if both (or either) side were driving outputs on
suspend, and I count at least 12 steps in the green line, so it would have to
include the 8 data line and 4 control lines ... which is getting increasingly
unlikely.
I might be able to try holding the PHY in reset during suspend. That should
force all pins to tri-state. However first I think I'll try 15 minute
suspends rather than 5 minute and see if that makes a difference.
Is there another credible explanation for the 2mA steps?
NeilBrown
<>
signature.asc
Description: PGP signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Crowdfunding an Ubuntu smartphone
On Sat, 24 Aug 2013 15:31:19 +0200 "Dr. H. Nikolaus Schaller"
wrote:
> Hm. That sounds quite different from the situation about 1 year ago when
> you did the first releases of QtMoko and I always thought that the
> 3.7 kernel is working well enough, so that I started to add new features.
>
> Has it become worse since then?
I like drawing graphs. So I did - see attachment.
For the last year or so my GTA04 has been logging the power usage during
suspend for every suspend cycle longer than a few seconds. I do this by
reading the "charge_now" value from the bq27000 in the battery, comparing the
"before" and "after" values, and dividing by the number of seconds.
I currently have my phone configured to wake from suspend every 5 minutes,
check that the modem is still working, and go back to suspend. This has
helped collect quite a lot of values.
To get the graphs I collected all those values, discarded negative numbers
(when the battery was charging) and a few numbers that were clearly
ridiculous (numbers more than 1 amp), and sorted the remainder.
So we get a cumulative frequency graph of different current levels.
The red line ('/tmp/uamp') is for the last couple of days since last reboot.
This is running 3.7 with offmode disabled.
The green line ('tmp/uamp2') is for the last year, running a variety of
different kernels.
Obviously there is a very different number of samples in each. 342 in uamp
10031 in uamp2. So I normalised the X values so the graphs are comparable.
They are much the same shape which suggests the pattern is fairly robust.
The Y axis is microamps.
The green values below 2 (20mA) are with offmode enabled I assume.
The red values are all greater because I have offmode turned off to improve
reliability.
The steps are a bit of a surprise. They are all about 2mA. I don't think
this is an artefact of the precision with which measurements are taken as the
charge value read from the battery has a much higher precision.
I think it must be an actual 2mA difference in (average) current usage.
This could be 2mA more for the whole time, or 4mA more with a 50% duty cycle
etc.
So if we can make off-mode really usable (which possibly means find and fix
some bug in the omap usb code) and if we can find out what is causing these
2mA steps and resolve that, then might might be a little closer to
acceptable power usage.
I might try running for a while with the modem turned off and see what result
I get.
NeilBrown
<>
signature.asc
Description: PGP signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Modem reenummerating (was: Re: Crowdfunding an Ubuntu smartphone)
On Sat, 24 Aug 2013 23:24:29 +0200 Lukas Märdian wrote: > Am 24.08.2013 23:04, schrieb NeilBrown: > > On Sat, 24 Aug 2013 14:22:55 Radek Polak wrote: > >> And the reenumerating modem - i really dont understand why we havent > >> tried newer firmware. For me missed calls is quite serious problem. > > > > I'm starting to think the the re-enumeration could be an omap-usb > > problem. I turned off a couple of power-saving features and the rate > > at which my modem reenumerates went way down. Sometimes the the modem > > Hmm could this by any chance have something to do with the infamous > Linux-USB problem, recently pointed out by Sarah Sharp? > http://permalink.gmane.org/gmane.linux.usb.general/93288 > Certainly worth testing - thanks for the link! NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Crowdfunding an Ubuntu smartphone
On Sat, 24 Aug 2013 14:22:55 +0200 Radek Polak wrote: > > And the reenumerating modem - i really dont understand why we havent tried > newer firmware. For me missed calls is quite serious problem. I'm starting to think the the re-enumeration could be an omap-usb problem. I turned off a couple of power-saving features and the rate at which my modem reenumerates went way down. Sometimes the the modem disappears and comes back. Sometimes it disappears and doesn't come back. In those cases if I rmmod the relevant modules and modprobe them again it sometimes comes back and sometimes doesn't. When rmmod/modprobe doesn't work, a reboot does. But the reboot doesn't remove power from the modem so just resets the omap. So it seems that the problem must be in the omap-usb driver. At the very least if we could get it to reset the connection to the same level as a reboot resets it, then we should be able to improve reliability. Oh, and by the way: Don't "rfkill block wwan" :-( It doesn't actually cause the modem to stop transmitting, but it does cause it to be behave very badly in intermittent ways. My phone had been very unstable for quite a while and I eventually traced it to an "rfkill block all" that I had in my startup scripts. Removing that helped a lot. NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [QtMoko] Battery
On Mon, 05 Aug 2013 15:51:49 +0200 Giacomo 'giotti' Mariani wrote: > Hi Radeck, all, >I was reading > http://wiki.openmoko.org/wiki/Battery_Questions_and_Answers in order to > estimate the remaining power of my battery (the fraction of the maximum > energy with respect to a new one) and found about bq27k-detail[1] which > doesn't seem to work on any recent distribution (kernel >= 2.6.34) I > have on my GTA02. > > Do you have any idea why the file > /sys/devices/platform/s3c24xx_pwm.0/hdq.0/hdq/dump disappeared? Is there > another way to achieve the same result of bq27k-detail? > > Thanks a lot, > Giacomo > > [1] > http://wiki.openmoko.org/wiki/Battery_Questions_and_Answers#That_bq27000_chip_seems_to_be_pretty_cool.2C_how_can_i_read_and_understand_its_raw_registers.3F > On the GTA04 I just read /sys/class/power_supply/bq27000-battery/charge_full and /sys/class/power_supply/bq27000-battery/charge_full_design and divide one by the other. Does the GTA02 not have something similar? NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] QtMoko audio state work
On Thu, 17 Jan 2013 13:50:54 + Neil Jerram
wrote:
> >
> > What sort of stability problems do/did you experience with
> > gsm-voice-routing?
>
> On several occasions, on receipt of a real incoming call, I've just got a kind
> of distorted quiet growling noise
> instead of proper audio from the far
> end. On the other hand, whenever
> I'm just testing, the audio almost
> always works. I wonder if the rest of
> the phone is using more CPU for a real
> incoming call than when I'm testing,
> and if that affects how gsm-voice-routing
> starts up.
>
> Well, you've encouraged me to try
> more with gsm-voice-routing. I think
> I need to understand more about _how_
> it fails, when it does, and I should be
> able to discover that by adding more
> logging.
>
> Can I just check: is your gsm-voice-routing
> code the same as in QtMoko?
>
Not exactly :-)
I've just pushed out the code that I'm using to
git://neil.brown.name/gta04-gsm-voice-routing
(master branch).
I thought I'd made more changes than it seems that I have...
Just:
--- a/gsm-voice-routing.c
+++ b/gsm-voice-routing.c
@@ -596,6 +596,11 @@ int main()
open_route_stream_repeated(&p0);
open_route_stream_repeated(&r0);
+while (route_stream_read(&r1))
+ ;
+snd_pcm_start(r0.handle);
+snd_pcm_start(r1.handle);
+
/* Route sound */
while (!terminating) {
NeilBrown
signature.asc
Description: PGP signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] QtMoko audio state work
On Thu, 17 Jan 2013 14:43:19 +0100 Radek Polak wrote: > > The simplicity of > > gta04-gsm-voice-routing is appealing, but I know from previous > > experience that it sometimes fails completely. > > For me the problem was that some other program had soundcard open and gta04- > gsm-voice-routing couldnt open it. If all programs use pulseadio then it can > be solved with pasuspender, but i wish that alsa had the same functionality. > Then we could get rid of pulseaudio. Maybe something like this could be > achieved using alsa plugins. The "dmix" alsa plugin is intended for this purpose. If it is active, then multiple clients can open the device and the sounds they write get mixed together and played. A problem with this is that dmix imposes a fixed (I think) sample size, which implies a fixed latency which is probably more than the latency we want. gsm-voice-routing is quite latency sensitive, both for quality-of-call and for effectiveness of the echo cancelling. NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] [QtMoko] QX touchscreen input do not work
On Tue, 11 Sep 2012 23:33:27 +0100 Neil Jerram wrote: > Radek Polak writes: > > > On Monday, September 10, 2012 08:17:05 PM Neil Jerram wrote: > > > >> I have some theoretical patches for that (attached), but I haven't > >> offered them to Radek because I haven't really got QX working much at > >> all, and so I couldn't be sure if the QX rotation support was working. > >> > >> The first attached patch is for the main QtMoko repository; the second > >> is for the Arora submodule. > > > > Hi Neil, > > it's applied now. I tried in arora and it works good, so i expect QX to be > > working too - i will try later on Freerunner. > > Great, thanks! > > > Btw has anyone figured how to rotate X server on GTA04? > > No, I don't think so. I tried for a while before moving onto QtMoko, > but didn't manage to understand the omapfb X driver. And Neil Brown > said recently that it was on his list of things he wanted to do but > couldn't yet. I spent a while looking into this and my conclusion is that while the frame buffer does support rotation, the Xorg driver for the omap3 framebuffer doesn't hook into that. Also I couldn't find any evidence of ongoing development of the omap3 Xorg driver. So I'm guessing that to make 'xrandr' work on the GTA04 will take some fairly serious hacking in Xorg driver code. I wish I had time to do that ... though to be honest, if I did have the time I'd probably spend it on something else :-( NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [qtmoko] flight mode power consumption / turning gsm back on
On Tue, 28 Aug 2012 08:21:20 -0400 Benjamin Deering wrote: > On 08/28/2012 07:44 AM, robin wrote: > > hi ben, > > > > could you please give some more detail on how do you set it in woods mode? > > and does the gsm power on afterwards correctly or do you have to restart the > > phone? > > > > thanks > > > > robin > > > > > > ps: here is the link to the paper on powerconsumption of the freerunner: > > > > http://www.ssrg.nicta.com.au/publications/papers/Carroll_Heiser_10.pdf > > > > > > ___ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > > I use SHR most of the time, but the same thing should apply. I just > meant to change the GUI to call 'airplane mode' 'woods mode' because my > phones go in the woods and I don't fly very much at all. I suspect > something is wrong with airplane mode on both qtmoko and SHR for gta04 > if airplane mode doesn't use less power. Transmitting would be the > biggest power draw and even if the modem remained powered up power > consumption should drop unless it is transmitting. > > On gta02, I could turn 'airplane mode' off and on and it usually > worked. I never spent a lot of time watching power consumption on > gta02, but I did keep track of battery life. On gta04, we are still > figuring out power management and I had some charging issues so I was > dumping 'current_now' once a second in various configurations. A > somewhat unrelated thing I noticed and should report is that the 'idle > dim' state of fsodeviced actually uses more power. The process of > smoothly dimming the display wakes up the CPU and by the time it settles > back down, it is time to turn off the display anyway. > > I didn't mean to steer this away from qtmoko, but I think most of the > power related issues we are seeing are happening at a low level and > apply to all distros. On a GTA02 you power off the GSM chip by writing AT@POFF to the modem. This definitely reduces power usage quite a lot. You then typically write '0' to the 'power_on' and 'reset' sysfs files, but that isn't so important I think. If you are using gsm0710muxd, it will do all that for you when you tell it to. You need to use some D-Bus command that I'm not familiar with. Something like bus-send --system --print-reply --type=method_call \ --dest=org.pyneo.muxer /org/pyneo/Muxer \ org.freesmartphone.GSM.MUX.SetPower bool:false maybe. NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v46
On Fri, 3 Aug 2012 15:00:10 +0200 Radek Polak wrote: > On Thursday, August 02, 2012 04:59:55 AM NeilBrown wrote: > > > > * downgraded to 3.2 kernel > > > > What from? and for what reason? > > I'm finding 3.4 quite stable. 3.5 does seem to have some problems. > > From 3.4 - it was very slow - this is now probably fixed by your patches, but > i > already had the release done and tested with 3.2. > > For next release i plan 3.5 kernel. My experiences with 3.5 include: 1/ The battery status sometimes doesn't read correctly and it reports '0'. 2/ Sometimes my sound playing program gets stuck waiting for the soundcard. This could be just be a problem with my program. 3/ The GPS auto-on-off didn't seem to work once.. which is odd as it works perfectly in all my testing. However my antenna seems to have problems as I cannot get a fix at all most time, though once I got one in 90 seconds. Maybe I need to resolder something. Not that I want to scare you off using it, but I always encourage testing, and if you notice problem with any of these, you'll know it probably isn't your faulty, and when you report it, that will increase my motivation to find and fix the problem. > > > > > > [4] > > > > > > Jul 28 22:05:04 neo kernel: [ 117.245361] [] > > > (unwind_backtrace+0x0/0xe0) from [] > > > (omap_dma_unlink_lch+0x6c/0x8c) Jul 28 22:05:04 neo kernel: [ > > > 117.255187] [] > > > (omap_dma_unlink_lch+0x6c/0x8c) from [] > > > > There should have been some lines before that which are important. > > Possibly : omap_dma: You need to stop the DMA channels before unlinking > > or : omap_dma: trying to unlink non linked channels > > > > Also, is this the 3.2 kernel? I assume so. > > Yup. The whole dmesg is attached. Thanks. And indeed you did include all of the message that is relevant. Which is very strange as there are two places in omap_dm_unlink_lch which do a stack dump, and each has a 'printk' immediately before. Thanks, NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v46
On Sun, 29 Jul 2012 00:32:02 +0200 Radek Polak wrote: > Hi, > QtMoko v46 for GTA04 is out! You can download here[1]. For more info please > visit our homepage [2]. > > There are many changes since v45 so please consider this version a bit > experimental. List of changes is here: > .. > * downgraded to 3.2 kernel What from? and for what reason? I'm finding 3.4 quite stable. 3.5 does seem to have some problems. > > [4] > > Jul 28 22:05:04 neo kernel: [ 117.245361] [] > (unwind_backtrace+0x0/0xe0) from [] (omap_dma_unlink_lch+0x6c/0x8c) > Jul 28 22:05:04 neo kernel: [ 117.255187] [] > (omap_dma_unlink_lch+0x6c/0x8c) from [] (omap_pcm_hw_free+0x28/0x54) > Jul 28 22:05:04 neo kernel: [ 117.265045] [] > (omap_pcm_hw_free+0x28/0x54) from [] (soc_pcm_hw_free+0x88/0xd8) > Jul 28 22:05:04 neo kernel: [ 117.274536] [] > (soc_pcm_hw_free+0x88/0xd8) from [] > (snd_pcm_release_substream+0x44/0xa4) > Jul 28 22:05:04 neo kernel: [ 117.284851] [] > (snd_pcm_release_substream+0x44/0xa4) from [] > (snd_pcm_release+0x28/0x6c) > Jul 28 22:05:04 neo kernel: [ 117.295166] [] > (snd_pcm_release+0x28/0x6c) from [] (fput+0x104/0x1f8) > Jul 28 22:05:04 neo kernel: [ 117.303771] [] (fput+0x104/0x1f8) > from [] (filp_close+0x70/0x7c) > Jul 28 22:05:04 neo kernel: [ 117.311950] [] > (filp_close+0x70/0x7c) > from [] (sys_close+0xc8/0x120) > Jul 28 22:05:04 neo kernel: [ 117.320465] [] > (sys_close+0xc8/0x120) > from [] (ret_fast_syscall+0x0/0x30) There should have been some lines before that which are important. Possibly : omap_dma: You need to stop the DMA channels before unlinking or : omap_dma: trying to unlink non linked channels Also, is this the 3.2 kernel? I assume so. NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Money makes the world go round? Yes: new paid developer program for OpenPhoenux/Goldelico
On Tue, 10 Jul 2012 14:53:40 +0200 Radek Polak wrote: > On Tuesday, July 10, 2012 01:14:26 PM Dr. H. Nikolaus Schaller wrote: > > > The idea is that there is a mailing list where we (the project > > leading team) propose subtasks needing development > > (e.g. camera driver, bug fixing etc.) and interested > > developers can also make proposals what they could offer. > > I can donate money for project that makes GTA04 spend less mA in suspend. It > would be nice if we could get where Freerunner is now, it would be great to > consume even less. > > My offer is 50EUR for getting GTA04 to consume below 15 mA in suspend, 100EUR > for going below 10mA. If anyone want to look into this, the place to start is 'off_mode'. /sys/kernel/debug/enable_off_mode I think I've tried enabling that before and something didn't work - don't remember the details. Then you need to be sure that the 'off_mode' signalling between CPU and PMIC (the twl4030) is working. There is a output pin on the OMAP which indicates when it is in off_mode (sys_off_mode), and an input pin on the PMIC which handles that signal. When I last looked into this, I concluded that the default polarity of the two pins were different, or maybe one was edge-triggered and the other was level based. Or something. But I might have been wrong. Then you need to set up some power-management scripts in the twl4030 to turn regulators off when in off-mode, and back on again for resume. NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: qtmoko v45
On Mon, 2 Jul 2012 21:57:28 +0200 Marc Langlois wrote: > Hi, > > After execution of Neil Brown's howto for GPRS on the GTA04, I would > conclude as: > +> For the connection to /dev/ttyHS3, I use minicom with the default > settings but the connection does not work consistently. > +> AT+CFUN = 3D1 (set phone functions on), and AT_OWANCALL=3D1,1,1 > returns me "ERROR". > > Here is my log: > AT+COPS > OK > AT+COPS? > + COPS: 0,0, "004f00720061006e0067006500200046", 0 > > OK > AT_OWANCALL = 3D1,1,1 Try dropping the spaces and the '3D' (which a mime-encoding artefact - '=' is sometimes encoded in email messages as '=3D'). So: AT_OWANCALL=1,1,1 NeilBrown > ERROR > AT_OWANDATA? > OK > > What are the tips for the connection débuger? > Can you used the modem mode multiplexing (neocontrol) with a GTA04A4? > The UMTS signal reception is good in my house. > > Best regards, > > Marc > > >>Neil Jerram writes: > >> Marc Langlois writes: > >> > >>> Neil, > >>> > >>> My phone is GTA04A4. > >> > >> Ah, thanks. Has GPRS actually been integrated yet in QtMoko on the > >> GTA04? I'm not sure that it has. > > > >For ease of reference, here's Neil Brown's howto for GPRS on the GTA04 > >(and which it's well worth creating another copy of): > > > >> 0/ connect to /dev/ttyHS3 (others might work) > >> 1/ make sure you are registered with network. > >> e.g. > >> AT+CFUN=3D1 > >> AT+COPS > >> AT+COPS? > >> > >> 2/ establish data connection > >> AT_OWANCALL=3D1,1,1 > >> > >> 3/ collect status > >> > >>AT_OWANDATA? > >> My response was > >>_OWANDATA: 1, 49.179.102.244, 0.0.0.0, 211.29.132.12, 61.88.88.88, > >> 0.0.0= > >> .0, 0.0.0.0,144000 > >> ^IP address ^ ^DNS-1--^ ^DNS-2^ > >> > >> 4/ configure network > >> > >> ifconfig hso0 49.179.102.244 up > >> route add default dev hso0 > >> > >> echo nameserver 211.29.132.12 > /etc/resolv.conf > >> echo nameserver 61.88.88.88 >> /etc/resolv.conf > >> > >> > >> > >> > >> And you should be set to go. If you want tethering via USB then add: > >> on GTA04: > >> echo 1 > /proc/sys/net/ipv4/ip_forward=20 > >> iptables -t nat -A POSTROUTING -s 192.168.0.200 -j MASQUERADE > >> > >>(here 192.168.0.200 is the IP of my notebook on the USB interface.) > >> > >> on notebook/desktop/whatever > >> > >> route add default gw 192.168.0.202 > >> echo nameserver 211.29.132.12 > /etc/resolv.conf > >> echo nameserver 61.88.88.88 >> /etc/resolv.conf > >> > >>(192.168.0.202 is IP of GTA04 of USB link). > >> > >> To terminate data call > >> > >> AT_OWANDATA=3D1,0,1 > >> > >> > >> You don't need pppd at all. > > > >But there are no occurrences of "OWAN" in the qtmoko codebase - so I'm > >pretty sure it hasn't been integrated yet. > > > > Neil > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: TD028TTEC1 data sheet ??
On Fri, 18 May 2012 15:40:16 +0200 Harald Welte wrote: > hi Neil, > > I don't read the list at all these days, but if you still require the > data sheet, let me know. Thanks Harald. I have managed to get hold of that data-sheet. Unfortunately it doesn't contain programming details which is what I really wanted. I can live without them - as we have a working driver - but if programming information was available I would still like it. Thanks, NeilBrown > > On Sun, Nov 27, 2011 at 04:08:41PM +1100, NeilBrown wrote: > > > > Hi, > > does any one have a copy of the data sheet for the Freerunner LCD display? > > > > > > http://wiki.openmoko.org/wiki/TPO_TD028TTEC1 > > > > suggests it is at > > > > http://www.cip.physik.uni-muenchen.de/~Wolfgang.Draxinger/stuff/openmoko/TD028TTEC1.pdf > > > > but that links dead. > > > > So I wonder anyone downloaded it when it was there and still has a copy. > > > > If so - may I please get a copy? Thanks. > > > > NeilBrown > > > > > ___ > > Openmoko community mailing list > > community@lists.openmoko.org > > http://lists.openmoko.org/mailman/listinfo/community > > signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] Discussion: what are your dreams for the Openmoko Community
On Mon, 30 Apr 2012 07:38:13 +0200 "Dr. H. Nikolaus Schaller" wrote: > Wow, > this is a really impressive list with new ideas > I have not yet heard of! > > And the most interesting thing is that I think > almost all can be done and don't have major > technical hurdles to overcome. The main > challenge is to make them user friendly > and bug free. > > It appears that we more have a lack of active > developers doing it. And are missing some > coordination to get a complete solution. > > Maybe we should again think about a more > formal organization of the Openmoko.org > (software) project? > > Some Foundation or Association? What benefit would a Foundation or Association bring? I think they bring value in co-ordination when you have lots of people who are finding it difficult to work together. But I don't think that is the problem that we have. As you said: "lack of active developers". What can we do to encourage those developers that we do have, and to entice some on-lookers who aren't developers yet but might be in the future? Maybe instead of asking "what would you like to see" (which certainly does have a place) we should be asking something more down to earth, immediate, and practical. - what are you working on? - what have you recently achieved? - what one thing would you like help with? For myself: I'm mostly working on aligning the kernel we use with the upstream kernel. I recently submitted a collection of patches upstream and am hoping some will stick. I've recently discovered that my approach to power-management for wifi and bluetooth is less than perfect. Among other things it doesn't actually set the voltage properly, so we are running on 2.8V rather than 3.1V. I think I know how to fix it though. I recently tried 3.4-rc4 on my GTA04 and it was less than a brilliant success. No sound cards appear and the X server keeps crashing. I would love it if someone else had a look You can find the code in the 'gta04/mainline' branch of g...@github.com:neilbrown/linux.git NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Discussion: what are your dreams for the Openmoko Community
On Sat, 28 Apr 2012 15:39:15 +0200 Neil Jerram wrote: > Timo Juhani Lindfors writes: > > > "Dr. H. Nikolaus Schaller" writes: > >> What would you like as future hardware? What to see in software > >> distros? > > > > I'd like to have an open source calendar application, please :) > > "dates" ? I hadn't heard of dates ... goes looking ... Quite a nice clean interface, but not very finger friendly. And it pops up multiple windows for entering events which doesn't work for me on a small screen (and isn't my favourite interface even on a big screen). Still: shouldn't be hard to write something with a similar interface - I like the zooming idea - that doesn't have those problems. Just need an ical library and a widget library and a few lines of code to join them together :-) What is a good finger-friendly way to enter times? My current toy (which doesn't do ical) has 3 concentric circles of buttons for AM hours, PM hours and 5-minutes - see attached (ugly jpeg because list thought my png was too big). It's not too bad but feels a little clumsy. NeilBrown <> signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Discussion: what are your dreams for the Openmoko Community
On Sat, 28 Apr 2012 11:52:45 +0200 "Dr. H. Nikolaus Schaller" wrote: > It has become a little quiet here in the last weeks so that I > really fear about the spirit and status of this community. I notice this email was sent to gta04-de...@goldelico.com rather than gta04-own...@goldelico.com I wasn't aware of this list ... should I be? What is it for? NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Discussion: what are your dreams for the Openmoko Community
On Sat, 28 Apr 2012 11:52:45 +0200 "Dr. H. Nikolaus Schaller" wrote: > It has become a little quiet here in the last weeks so that I > really fear about the spirit and status of this community. > > So what are your dreams with respect to open mobile handhelds? A common hardware platform on which different groups can innovate differently. We almost have that thanks to Android pushing a standard which is similar to iApple. The GTA04 is close - maybe close enough. Changes would be: - multi-touch display - 2 more keys. - proximity sensor (so it knows when it is near your head) - multiple cameras - second mic to improve noise reduction - bigger battery The multi-touch is the most important I think. > What would you like as future hardware? Nicer case, bigger display. I don't need a hardware keyboard, but some do. > What to see in software > distros? Anything else? What missing piece are you waiting for? I do all my own software - that is the point for me. Though one day I expect I'll get bored of that and want a telephony stack that someone else supports... There seem to be a few options available, which is good. I'm more concerned about the IPC layer that ties it together. I don't like dbus much and I don't like Android binder for quite different reasons. Something that provided the same functionality is a "better" (that is highly subjective of course) way would be nice. NeilBrown > > If we exchange these ideas it may be possible that we all > work together (with smaller and bigger contributions - everyone > as he/she likes) to fulfill them... > > Otherwise I guess we have just to consume what Apple, Samsung, > MS-Nokia and others are confronting us with in the next years. > May it be open or closed as they like. > > Or is this where we see our future? Or am I completely wrong in my impression? > > Phew - a lot of questions and so early in the morning :) > > Nikolaus > > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] How to bring forward the community?
On Wed, 29 Feb 2012 22:38:23 + Neil Jerram wrote: > For me, the fun is in trying to put bits of software together to make a > useful and interesting phone/gadget, and in understanding (up to a > point) how it all works. "Me too". It isn't about being better than Android, or free from being spied on or free to choose, though all of that is valuable. It is about having a toy to play with and to learn from - one that I can actually use as well so there are concrete outcomes from my efforts. That last bit is important. I cannot imagine myself buying a nano-note or a Spark because I cannot imagine what I would ever really use them. Without 3G the mobility is almost irrelevant to me, so the small size becomes just an inconvenience. NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to bring forward the community?
On Wed, 29 Feb 2012 23:09:28 +0100 EdorFaus wrote: > On 02/29/2012 06:50 PM, Dr. H. Nikolaus Schaller wrote: > > Am 29.02.2012 um 18:05 schrieb Gerald A: > >> Some people like it. > > > > Yes, I know and want to better understand why. It looks as if they like > > them because they feel better than on-screen keyboards. > > I think this is precisely it, actually. Maybe you just haven't realized > how important feel actually is for this kind of thing, at least for some > people. > > When I type, either on a (closer-to-)full-size keyboard like on my > netbook, or on a smaller mobile keyboard like on my NanoNote or E51, I > do it mostly by feel - I slide my fingers across the keyboard, feeling > each key as I pass it (or maybe more accurately, the edges between > them), and then stop at the right key and apply more pressure, until I > feel it has been clicked (there's usually a threshold). > > All of that is done in my fingers, by touch/feel, which means they can > fairly easily learn how to do it more or less by themselves - leaving my > mind free for the task at hand (maybe except for the rarely used keys > that my fingers haven't learned yet). I wonder how much of this could be added to an on-screen keyboard. Certainly it would never be as good as physical keyboard could be, however... The touchscreen can measure pressure, so we could tell the difference between finger presence and finger activation (strong pressure). As you slide your thumbs we could make a short vibration was you pass the center of each key with a slightly longer vibration for the J and F keys. When you press, a short double-vibration maybe. As the touchscreen can only detect one finger you couldn't have both thumbs down at the same time, which is a definite negative - however we could probably do better than the current crop of soft-keyboards. NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] How to bring forward the community?
On Mon, 27 Feb 2012 22:36:50 + Neil Jerram wrote: > rhn writes: > > > Having an easy way to build and share programs (without the need of an > > entire distribution checkout like SHR needed if I remember right) > > would also help. Native compilation perhaps? > > FWIW, native compilation has always been possible on the GTA02, at least > under Debian. Admittedly it was sometimes painfully slow - depending on > what I was compiling - but nevertheless definitely possible. > > On the GTA04 it is quite straightforward and quick to compile things. > I'm doing it all the time. While I agree with all the above, I would very much like to be able to compile GTA04 binaries on my x86_64 multi-core notebook. I can do it easily for the kernel, but that is made much easier by the lack of external dependencies - no libraries to link with. I tried once - having a Debian/arm distro in a directory somewhere and setting up all the various paths, but I couldn't make it work. Does anyone know how to do this? (most of my user-space code is python which doesn't need compiling, but a few bits are C and I would *really* like to be able to "make install" and it would build arm version and scp them over.) NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FOSDEM 2012 - Presentation online
On Wed, 08 Feb 2012 22:29:12 + Neil Jerram wrote: > Niels Heyvaert writes: > > > The slides are also available online for download on the AoF project page. > > > > http://code.google.com/p/android-on-freerunner/ > > I couldn't straightforwardly find any slides, from that starting point. > Could you post the exact URL? http://android-on-freerunner.googlecode.com/files/FOSDEM2012%20Open%20Mobile%20Linux%20Devroom%20-%20Openmoko%20Freerunner%20Present%20and%20Future%20-%202012-02-04.pdf seems to work. NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] Flyer for FOSDEM (PDF and ODP)
On Fri, 3 Feb 2012 08:39:26 +0100 "Dr. H. Nikolaus Schaller" wrote: > Here are the files for the Flyer we will spread at > FOSDEM. So if anyone needs materials or > wants to distribute in his/her area: > > http://download.goldelico.com/gta04/Marketing/ > Nice. By the "WLAN/Bluetooth" arrows seem to be pointing at a couple of minor components (resistors?). The WLAN/Bluetooth is the black square above the OMAP, isn't it? NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] QtMoko v38 for GTA04 with suspend and GSM calls
On Tue, 31 Jan 2012 19:00:13 +0100 "Denis 'GNUtoo' Carikli" wrote: > hi, > how did you get suspend working reliabily? > personally I've that: > [ 406.115966] platform l3_main.0: LATE power domain suspend > > [ 406.121612] platform iva.0: LATE power domain suspend > > [ 406.126892] platform mpu.0: LATE power domain suspend > > [ 406.132171] omap_l3_smx omap_l3_smx.0: LATE power domain suspend > > [ 406.138458] reg-dummy reg-dummy: LATE suspend > > [ 406.143035] PM: late suspend of devices complete after 682.739 msecs > > [ 406.149688] Checking wakeup interrupts > > [ 406.876373] Successfully put all powerdomains to target state > > [ 406.882507] reg-dummy reg-dummy: EARLY resume > > [ 406.887115] omap_l3_smx omap_l3_smx.0: EARLY power domain resume > > [ 406.893402] platform mpu.0: EARLY power domain resume > > [ 406.898681] platform iva.0: EARLY power domain resume > > [ 406.903961] platform l3_main.0: EARLY power domain resume > > Should the userspace suspend/resume work in a way that is similar to > android(but in userspace): > The display would be powered off etc and the phone would try to suspend all > the time and would fully resume when he get a good reason to do so(like a > phone call or an user pressing the resume button). = There are lots of things that can wake up the phone. So are: - 3G chip signalling that something important happened - character arriving on a UART (from console, bluetooth, GPS) - power button, aux button, screen tap - USB plugged in/out Your wakeup happened 626 milliseconds after it went to sleep. Was the GPS chip on? That would do it (it reports every second I think). If so, you need to turn it off or tell it to stop reporting when you go into suspend mode (or generally when you don't care what it is saying). Of course it might be something else... Hope this helps. NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] Status GTA04 GroupTour
On Thu, 29 Dec 2011 11:50:40 +0100 "Dr. H. Nikolaus Schaller" wrote: > Curious about your ideas, If I were thinking about joining the group tour, I'd be waiting for confirmation from the early adopters that the device really worked as a phone. The freerunner was plagued with little hardware bugs which meant various bits didn't quite work perfectly. I wouldn't want to repeat that. Clearly most of the hardware does work and calls can be made but as a potential purchaser I would want to be hearing things like: - I used my gta04 to call my girl friend and she didn't complain about the sound quality. - I can browse the web over UMTS and it is quite usable - I only need to charge the battery every other day. That last one is the biggest hole in our story currently. We have no evidence that we can achieve appropriate power saving. I suspect we can but as yet we cannot demonstrate it. If I were buying I'd wait until it could be demonstrated. Others probably think very differently to me, but that I what I would be thinking. NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
TD028TTEC1 data sheet ??
Hi, does any one have a copy of the data sheet for the Freerunner LCD display? http://wiki.openmoko.org/wiki/TPO_TD028TTEC1 suggests it is at http://www.cip.physik.uni-muenchen.de/~Wolfgang.Draxinger/stuff/openmoko/TD028TTEC1.pdf but that links dead. So I wonder anyone downloaded it when it was there and still has a copy. If so - may I please get a copy? Thanks. NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: My VoIP experience in Freerunner
On Mon, 29 Aug 2011 14:13:38 -0300 Tiago Bortoletto Vaz wrote: > Hi all, > > I've just posted how I managed to get SIP working in Qtmoko - not > qtopia default app, unfortunately. > > Actually it's not only related to Qtmoko once I ended with a regular X > application for that. > > Please share your ideas to improve this setup :) > > http://tiagovaz.org/posts/VoIP_in_Neo_Freerunner_with_Qtmoko_and_Linphone/ > > Regards, > I cannot see your http://pub.tiagovaz.org/.linphonerc 403 - Forbidden anything interesting in it? Thanks, NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2.5 vs 3.5 jack
On Thu, 17 Feb 2011 00:28:29 +0100 David Lanzendörfer wrote: > Good thing is, that we also are already planning the gta05, and there I'm > organizing an amazing, cool and totally innovative new chassis in addition. > Can't tell too much as long as the specs are not CC-License, but: > It's TOTALLY cool ;-D That is SOOO cruel. Almost as Evil as Fermat and his hypothetical "last theorem" I'm going to be wondering and waiting for *months* now!!! NeilBrown signature.asc Description: PGP signature ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA04 Wiki
On Wed, 19 Jan 2011 14:28:52 +1100 Philip Rhoades wrote: > Neil, > > > On 2011-01-19 08:25, NeilBrown wrote: > > On Wed, 19 Jan 2011 07:59:10 +1100 Philip Rhoades > > wrote: > > > >> People, > >> > >> I want to know how it will compare to my GTA02 . . I want a bigger > >> screen but the video shows about the same size device? > >> > > > > The GTA04 isn't a phone (at this stage at least). It is a replacement > > motherboard for the Openmoko Freerunner. So you use the same case, the same > > display, the same touchscreen, the same battery. Only the motherboard and > > the components on it will changed. > > > > I would love a bigger screen too, and no bevel around the screen, and a > > thinner case and and and and... But the chance of getting that as a truly > > open device seems pretty slim at the moment. So I'm happy to compromise and > > get a GTA04 board to eventually put in my Freerunner case. > > > OK, well then I guess I want a comparison feature for feature between > the old and the new . . is GTA04 just to replace a dead GTA02 MB? > > Thanks, > > Phil. I suggest you read what is available at www.gta04.org and wiki.gta04.org GTA04 is an experiment. It might not work (you are warned that when trying to buy). The software certainly doesn't work completely yet. It may never unless you contribute. It has a faster processor, faster graphics, 3G phone capability and assorted other bits and pieces. It is an 'engineering component' for people who want to experiment and explore. One day it might be more than that, but today is not that day. NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA04 Wiki
On Wed, 19 Jan 2011 07:59:10 +1100 Philip Rhoades wrote: > People, > > I want to know how it will compare to my GTA02 . . I want a bigger > screen but the video shows about the same size device? > The GTA04 isn't a phone (at this stage at least). It is a replacement motherboard for the Openmoko Freerunner. So you use the same case, the same display, the same touchscreen, the same battery. Only the motherboard and the components on it will changed. I would love a bigger screen too, and no bevel around the screen, and a thinner case and and and and... But the chance of getting that as a truly open device seems pretty slim at the moment. So I'm happy to compromise and get a GTA04 board to eventually put in my Freerunner case. NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA04 Wiki
On Fri, 14 Jan 2011 14:09:45 +0100 "Dr. H. Nikolaus Schaller" wrote: > Behind the scenes a lot of things are slowly progressing. > > One part is setting up a web interface to important information. > > Therefore, we have now installed > > wiki.gta04.org > > which is completely virgin.. So virgin that it takes me to a login page... > > To start filling it with really useful information, please let us know > which pages (keyword, short description) you would expect. Surely the main thing is info about each hardware component, links to the specifications, how it is addressed/accessed in the GTA04, and where its power can be controlled independently. Thanks, NeilBrown > > Nikolaus > > PS: The early adopter offer is still open since we have not yet > got a quotation for the memory chips (Micron MT29C or MT46 > in 168-VFBGA) and those appear to be the most critical to secure > first. The more orders we have the easier it becomes to talk to the > distributors. > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko Neo FreeRunner GTA02 versions A5 & A6 Audio Buzz - Quality Enhancement Service
On Wed, July 8, 2009 2:25 pm, Denis Johnson wrote: > Also I am somewhat concerned that from Australia we will struggle to > make the cut-off date considering it is already the 8th here. I just got my freerunner back two days ago. I posted it on the 10th of June. It was processed by the 29th and arrived back in Australia by 6th July. Given that the deadline is now 7 days away, I think you have certainly left it too late. However it cannot hurt to email buzz...@sdgsystems.com and ask if you could still send it - I have found them quite responsive. (my return postage was $US31.35, $AU41.65 - more than I hoped, but less than the international express. NeilBrown PS. Sound quality is much better after the fix. > > cheers Denis > > On Fri, Jun 5, 2009 at 4:53 PM, NeilBrown wrote: >> On Fri, June 5, 2009 4:32 pm, Dr. H. Nikolaus Schaller wrote: >>> He wrote that he is in the US. >>> >>> We also run the same program for a while for EU customers: >>> >>> http://www.handheld-linux.com/wiki.php?page=Buzz-Rework >>> >>> Nikolaus >> >> Any suggestions on a best course of action for Australian >> customers? >> >> Supposing we were happy to pay shipping to-from USA, how >> would we go about paying the return postage and what might it >> cost (I think it is about $AU15 to post to the USA from here, >> for standard airmail). >> >> Thanks, >> NeilBrown >> >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to get buzz fix in Australia
On Tue, June 16, 2009 4:20 pm, Denis Johnson wrote: > On Tue, Jun 16, 2009 at 2:24 PM, NeilBrown wrote: >> You can send it to sdgsystems.com. >> You first purchase the "freerunner audio quality enhancement" on the >> website. This costs $0 plus postage. >> Their postage price is around $AU100 sent by international >> courier. If you ask, they will sent it be USPS and credit you >> the difference. I asked for "USPS first class" which according to >> >> http://ircalc.usps.gov/ >> >> is about $US11. >> It cost me $AU16 to post it from .au to .us. > > > Thanks for that. Should I also consider any other hardware fix at the > same time ? They don't offer any other hardware fix... NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to get buzz fix in Australia
On Tue, June 16, 2009 1:52 pm, Denis Johnson wrote: > I have asked this before but the thread seems to have fizzled. > > I have a GTA02 V5 one of the first group purchases into Australia and > I would like to know if anyone in Australia is planning a buzz fix > party or if there is somewhere overseas I can send my Freerunner to > get fixed. > > I do not have the equipment or expertize to do it myself. Any > recommendations welcome. You can send it to sdgsystems.com. You first purchase the "freerunner audio quality enhancement" on the website. This costs $0 plus postage. Their postage price is around $AU100 sent by international courier. If you ask, they will sent it be USPS and credit you the difference. I asked for "USPS first class" which according to http://ircalc.usps.gov/ is about $US11. It cost me $AU16 to post it from .au to .us. NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Project B guessing game was[ Re: Pat Meier (=public relation of Openmoko)]
On Wed, June 10, 2009 8:18 pm, David Reyes Samblas Martinez wrote: > Project B guessing game > - > * Hair straightener with WLAN. (1) > * Cheap wireless tablet. (1) > * Open Hardware programable Annoy-a-tron 2.0[1] like. (1) > > [1]http://www.thinkgeek.com/gadgets/electronic/b278/ In the same breath as introducing Project B, Sean mentioned his surprise at finding out how keen the "embedded community" were to get a toy to develop on. So I think it is a a touchscreen/cpu/bluetooth device that can be used as a user-interface to any blue-tooth enabled tool (phone, gps, whatever) and the target market is embedded devlopers who want a cheap and open platform to do development on. So: * Bluetooth enabled touch screen NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko Neo FreeRunner GTA02 versions A5 & A6 Audio Buzz - Quality Enhancement Service
On Fri, June 5, 2009 4:32 pm, Dr. H. Nikolaus Schaller wrote: > He wrote that he is in the US. > > We also run the same program for a while for EU customers: > > http://www.handheld-linux.com/wiki.php?page=Buzz-Rework > > Nikolaus Any suggestions on a best course of action for Australian customers? Supposing we were happy to pay shipping to-from USA, how would we go about paying the return postage and what might it cost (I think it is about $AU15 to post to the USA from here, for standard airmail). Thanks, NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Back to the Basics plan: Andy left
On Tue, March 24, 2009 2:03 pm, Mike Montour wrote: > Laszlo KREKACS wrote: > >> I can't express how sad I'm when I read Andy Green left Openmoko. >> >> I do not know why he left (and it is not my business anyway), but >> I know since Andy was at Openmoko the kernel side began >> to form shape, and got things work. (suspend? anyone?) > > You should have stopped here IMHO. It really is none of our > (community's) business, and it would be a lot more productive to just > focus on the question of "where do we go from here?" I have to say that I think the answer to that is "up stream". Code doesn't have to be completely working before it goes into the upstream kernel. Just "supported" and "useful" are often enough. I understand that there is work underway to get some of the openmoko kernel code upstream. I think that should be a major focus. Once it is all in, then work can go back to enhancing and bug fixing. It would be awesome if mainline-2.6.30 or even 2.6.31 would run on the Freerunner unchanged! When it is all in mainline, it is a lot easier for more people to contribute. NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Dialup On Demand (was: [SHR] Miscellanious minor issues)
On Sat, January 31, 2009 2:55 am, Michael 'Mickey' Lauer wrote: > Ok cool, but how does this work internally? We want the framework to be > notified, not the ppp process (which we don't want to run all the time) On demand network connection is awkward to do in a completely general way. When an application makes a TCP connection, the kernel needs to choose a local address for "this" end of the connection. It chooses that based on the IP address of whichever interface will be the first hop of the outgoing connection. If you don't have that interface established, then there is no address or route, so the kernel will give up quite quickly - there is no where for user-space to hook in and make things work. One option is to always use a VPN through some base station. I think you can get OpenVPN to establish a connection on demand. So the kernel sees the OpenVPN interface and sends a packet to that. OpenVPN then brings up whatever network can be found and forwards the packet over the VPN and on the the Internet. You could probably set up something vaguely similar that works locally without needing a remove VPN server or even a VPN. 1/ open two TUN devices and configure them with very obscure private addresses with a PTP connection between them. Maybe ifconfig tun0 127.0.0.10 pointopoint 127.0.0.11 ifconfig tun1 127.0.0.11 pointopoint 127.0.0.10 Doing this will require having a program that creates the devices and reads traffic from them. 2/ Add a default route out tun0, so all traffic will head that way. 3/ Use iptables to MASQuarade traffic arriving on tun1. 4/ Then your program gets a packet in on tun0 that it wants to send to the internet, it brings up a connection some how and fiddles the default route and writes the packet out to tun1. You then just need to copy traffic between the two interfaces. There may be some subtleties in getting the routing set up correctly. Once the Internet is available, you really want new connections to go direct, but the original connection (while it lasts) will have to go through the forwarding setup. And you don't want packets that come out of tun1 to be routed back in to tun0. If anyone tries this and gets confused by the difficulty of routing packets the right way, don't hesitate to ask - I am very confident that it is a solvable problem. NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Stage of GTA03 development?
On Fri, December 19, 2008 9:34 am, Carsten Haitzler wrote: > > 2g is charged by the kb at insane rates. ($1.65/mb is three's going rate > for 2g > data - whereas their 3g data rates are more like $0.0068/mb. now you know > why > 3g is so important? 2g data is 241 TIMES more expensive than 3g. and three > offer the best datarates in .au). We are getting a little off topic here, but I'm wondering how you get that rate for 3g. The rates I find are all around $0.015/mb dropping to about $0.010/mb if you buy in bulk (i.e. buy $100 worth). For 2g, I pay $0.40/mb (www.exetel.com.au) which is still 26x 3g, but is bearable for light usage. Another reason 3g is important: using a VOIP service, you can make cheaper phone calls by sending data over your 3g service than by using it for standard voice calls. NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: locking touchscreen
On Tue, September 2, 2008 6:25 pm, Christian Adams wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > moinmoin > > sometimes i just want to lock the screen like on my se-w810i - a > simple keypad-lock. > a way that just came to my mind could be to tell the kernel - maybe > via sysfs - to suppress data coming out of the corresponding /dev/ > input/event1. > > would that be a) possible (andy?) and b) desired (community?) Me too. The way to do this is to open /dev/input/event1 and issue the EVIOCGRAB ioctl. However there is currently a patch in the openmoko kernel which modifies EVIOCGRAB in such a way that it is no longer useful for this purpose. Before we can remove that patch, we need to fix tslib to so that it doesn't use EVIOCGRAB in a way that depends on the kernel patch. The fix for tslib is in the process of being committed to the openmoko source tree (it is in some 'devel' tree but not in 'stable' yet, though I almost certainly have those names wrong). Once that has propagated reasonably, I will be asking Andy to remove the EVIOCGRAB-modification patch from the kernel. And once that it done, we can try use EVIOCGRAB to steal all events from the touchscreen. Simple! NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: AT%N0187 openmoko echo patch?
On Mon, September 1, 2008 6:59 pm, Yorick Moko wrote: > On Mon, Sep 1, 2008 at 10:43 AM, Lorn Potter <[EMAIL PROTECTED]> > wrote: >> They certainly are not in our copy of the calypso spec's that we got >> directly from TI. If it is, I must be missing it, and haven't found it. > > Maybe TI just wants their products to suck? > What I mean: is this standard practice in this business? What possible > gain would TI have with not giving you that information? They could avoid having to pay the extra cost of getting a competent and thorough documentation writer? Never attribute to malice that which can be adequately explained by incompetence!! NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: tiny stylus in lanyard hole (warning: half-assed)
On Mon, August 18, 2008 12:04 pm, Nathan Kinkade wrote: > I questioned whether to post this here, as it's somewhat embarrassing. > I had an idea about how to store a tiny stylus in the lanyard hole at > the bottom of the Neo. The basic idea was to take some of the foam > from the Neo packaging, cut it to size and then stuff it snugly into > the hole. The idea was then to burn a hole through the middle of the > foam where possibly a tiny stylus-like device could be inserted and > would hold fast. Here is the first iteration: > http://natha.nkinka.de/stylus_lol/ Won't that muffle the microphone? I think the microphone is inside that hole! NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OM2008.8 lint-wifi and other pygtk apps fail
On Tue, August 12, 2008 7:14 pm, Florian Lohoff wrote: > > Hi, > > i tried installing lint-wifi (and mofi) and both of them return: > > [EMAIL PROTECTED]:~# export DISPLAY=:0.0 > [EMAIL PROTECTED]:~# lint-wifi.py > Traceback (most recent call last): > File "/usr/bin/lint-wifi.py", line 9, in > import gtk, os > File "/usr/lib/python2.5/site-packages/gtk-2.0/gtk/__init__.py", line > 82, in > init() > NameError: name 'init' is not defined See http://docs.openmoko.org/trac/ticket/1718 fix __init__.py, line 82, change "init" to "_init". NeilBrown > > starting from "Home" just pops up a requester saying it failed to start. > > Flo > -- > Florian Lohoff [EMAIL PROTECTED] +49-171-2280134 > Those who would give up a little freedom to get a little > security shall soon have neither - Benjamin Franklin > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FSO and GSM instability
On Sat, August 9, 2008 9:33 pm, Clare wrote:
> Yes, I have a GTA01 and GTA02 both running FSO-M2. Each one has a SIM
> card. The GTA01 has its blue bar steadily on. The GTA02 the bar is
> off more than on.Sometimes it briefly says "No Service". I have
> fiddled with it and taken some notes but it is
> quite erratic. and even if I succeed in ringing it the call drops out.
> Neither phone answers a call till it has gone through a complex
> startup. while doing 1234 frequently as it goes into withdrawal very
> quickly, it is necessary to press the phone icon, get the keyboard,
> press the X on the keyboard which gets the 4 icons back press the
> phone icon. at that point the bar goes blue and it changes from
> "zhone" to "Vodafone AU."
> Neither is doing well at initiating a call either. GTA02 I managed to
> hear hello once from the other phone then nothing.
> I can look inside via ssh if I knew what to look for.
>
> clare
"Me too".
If I run mdbus -s -l and grep for gsm I see the CID (cell ID??) changing
quite often, and the signal strength jumping around, sometimes high,
sometimes 0. Never low (during the short period that I watched).
e.g.
ogsmdINFO org.freesmartphone.GSM.Network.Status: {'cid': '590C',
'strength': 0, 'provider': 'vodafone AU', 'lac': '08A2', 'registration':
'home'}
ogsmdINFO org.freesmartphone.GSM.Network.Status: {'cid': '6E48',
'strength': 86, 'provider': 'vodafone AU', 'lac': '08A2', 'registration':
'home'}
ogsmdINFO org.freesmartphone.GSM.Network.Status: {'cid': '5909',
'strength': 86, 'provider': 'vodafone AU', 'lac': '08A2', 'registration':
'home'}
ogsmdINFO org.freesmartphone.GSM.Network.Status: {'cid': '6E48',
'strength': 86, 'provider': 'vodafone AU', 'lac': '08A2', 'registration':
'home'}
ogsmdINFO org.freesmartphone.GSM.Network.Status: {'cid': '6E48',
'strength': 0, 'provider': 'vodafone AU', 'lac': '08A2', 'registration':
'home'}
ogsmdINFO org.freesmartphone.GSM.Network.Status: {'cid': '6E48',
'strength': 0, 'provider': 'vodafone AU', 'lac': '08A2', 'registration':
'home'}
ogsmdINFO org.freesmartphone.GSM.Network.Status: {'cid': '6E48',
'strength': 0, 'provider': 'vodafone AU', 'lac': '08A2', 'registration':
'home'}
ogsmdINFO org.freesmartphone.GSM.Network.Status: {'cid': '5909',
'strength': 87, 'provider': 'vodafone AU', 'lac': '08A2', 'registration':
'home'}
ogsmdINFO org.freesmartphone.GSM.Network.Status: {'cid': '6E48',
'strength': 84, 'provider': 'vodafone AU', 'lac': '08A2', 'registration':
'home'}
ogsmdINFO org.freesmartphone.GSM.Network.Status: {'cid': '6E48',
'strength': 0, 'provider': 'vodafone AU', 'lac': '08A2', 'registration':
'home'}
ogsmdINFO org.freesmartphone.GSM.Network.Status: {'cid': '6E48',
'strength': 0, 'provider': 'vodafone AU', 'lac': '08A2', 'registration':
'home'}
ogsmdINFO org.freesmartphone.GSM.Network.Status: {'cid': '5909',
'strength': 89, 'provider': 'vodafone AU', 'lac': '08A2', 'registration':
'home'}
ogsmdINFO org.freesmartphone.GSM.Network.Status: {'cid': '6E48',
'strength': 84, 'provider': 'vodafone AU', 'lac': '08A2', 'registration':
'home'}
ogsmdINFO org.freesmartphone.GSM.Network.Status: {'cid': '590C',
'strength': 0, 'provider': 'vodafone AU', 'lac': '08A2', 'registration':
'home'}
ogsmdINFO org.freesmartphone.GSM.Network.Status: {'cid': '6E48',
'strength': 87, 'provider': 'vodafone AU', 'lac': '08A2', 'registration':
'home'}
NeilBrown
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: FSO xserver update
On Tue, August 5, 2008 5:08 pm, Charles-Henri Gros wrote: > digger vermont wrote: >> Hello, >> >> Its great to have the updates now for FSO but I've a problem with it. I >> installed the distro-feed-configs ipk > > Where did you find that? I asked earlier about feeds in FSO but got no > answer. I just edited my /etc/opkg/*-feed.conf to have e.g. src/gz remote-all http://buildhost.openmoko.org/daily-feed//all whether I'm really getting the right stuff I cannot be certain, but the increment in version numbers when I do opkg update ; opkg upgrade seems probable. NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Reason for GPS problems found! / more patches
On Wed, July 23, 2008 1:42 am, Alexey Feldgendler wrote: > On Tue, 22 Jul 2008 17:34:58 +0200, Andy Green <[EMAIL PROTECTED]> wrote: > >> I guess you're not a kernel coder... not only is the segment for these >> definitively zero at start of kernel, but it is an offence against >> ./scripts/checkpatch.pl to explicitly zero these things. > > It's strange to have a script that enforces a worse practice, even when > you really can assume that the segment is zeroed. > "worse" is subjective. int foo = 0; will put foo in the "initialised data" section with a value of 0. int foo; will put foo in the "uninitialised data" section which is guaranteed to be initialised to zero when the kernel is loaded. The former adds 4 bytes to the size of vmlinux. 4 bytes isn't much, but if there are hundreds of these, it is just a waste of space. If it really offends you, use int foo /* = 0 */; but that isn't really necessary. It wont take long before you start reading int foo; in global context as "foo is initialised to 0". NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: G3. Was: GTA03: New case? Bigger screen!
On Mon, June 16, 2008 5:14 am, Stroller wrote: > > I'm not sure what the big deal is with 3G. > > My misconception was that GSM was only "dial-up speed", but someone > recently posted here stating otherwise. Someone debated with him over > his terming GSM as having "ADSL speed", but if it's 2 or 3 times > faster than 56k then that's fine by me. I can do all my email & > websurfing quite happily at that speed, and since my current 3G > mobile is painfully slow when coverage is spotty I can't see that it > makes much difference. My understanding -- and experience -- is that GSM/GPRS does provide only "Dail-up speed". http://en.wikipedia.org/wiki/GPRS suggests a max of around 80kbit/sec which is a little faster than 56k, but not much. If you have EDGE support, then that pushes it up to 236kbit, which is almost slow-ADSL. However it is my understanding that GTA02 doesn't support EDGE. http://wiki.openmoko.org/wiki/Openmoko#GPRS_modem says GPRS modem 2.5G (no EDGE) access to the Internet. > > As I understand it GSM *does* allow you to make a digital data > connection, and that's the important thing. > I agree - that is in the important thing. I used GPRS for Internet access while traveling in the UK recently, and while it is much better than not being connected at all, it is a long way from being a comfortable browsing experience. NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA03: New case? Bigger screen!
On Sun, June 15, 2008 2:54 pm, Nigel Cunningham wrote: >I'd like > to replace them both by one thing, and I want that one thing to be Linux > based and open source. At the same time, though, I want it to be useful > for a long time. 3G seems to me ignorant mind to fit that bill better > than GSM. (They've just switched off CDMA here in Aussie; I don't know > anything for certain, but assume that it won't be too many years before > GSM goes the same way). Or maybe I am just ignorant. Can you do sending > and receiving email and so on with GSM, or is that 3G only? How many years do you expect to get out of a 'phone? Some people seem to change them every couple of years, and I'm sure GSM will last longer than that. Yes, I would like 3G too, though I've heard it said on this forum that 3G is somewhat of a catch-all term for several related technologies, and it is not possible to have a single international 3G device. I don't know how true that is. In any case, to answer your question: yes, you can send/receive Email on GSM. GSM includes GPRS which is low-speed IP. Similar sort of speed to a 56K modem. OK for sending Email, just bearable for web browsing if that pages aren't too busy. NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: resolution preferences??
On Fri, June 6, 2008 3:39 pm, Carsten Haitzler wrote: > we can just drive the vga screen at qvga. no need for scaling - just > change the > output at the lcd controller level. but it is a waste to pay for a vga > screen > when we won't use it. also it does look "blocky". it isn't about glamo or > not - > it's separate to glamo entirely. simply - how important is a vga screen... > really? how many people out there can really see the difference? be really > honest. stop thinking "my specs are bigger than your specs". scan u REALLY > see > all the pixels on a vga screen of that size. i bet to most people its all > a > blur - a qvga screen looks identical to them. only to a minority who have > very > good eyesight does it really make a difference, but this is just my "bet". > i'm > asking the question - and hoping for real honest answers. Well, it's hard to know without having an actual device to look at, but I'll try My notebook has a 15 inch 1920x1200 monitor which comes to 147dpi. The Freerunner is 285dpi, the pixels are very close to half the width/ height of my pixels. So at first I thought "wow, that's tiny. I don't think I need them *that* small" - and I have better than average eye sight. Then I resized my browser to 640x480 and found I could read it quite well, though lots of web pages don't quite fit. I took a screenshot of the window and displayed it at 50% in the GIMP. So presumably that is how the image could look on the Freerunner. If I hold this image at the same distance from my eye that I usually use a notebook (say 55cm) the text looks like it would be too small to comfortably read, though the reduction of resolution has made it blurry and I cannot be sure. If I hold it at the distance that I would typically read a book, which is closer to 35cm, the text is still a bit small, but I think I would be quite happy reading it - except that the low resolution has made it quite blurry. If it were still 640x480, but the same size I think I could read it quite happily. So my conclusion is that for reading textual content, the higher resolution probably is worth it for me. I doubt it would be of much value for photo for videos. I just tried watching a video at [EMAIL PROTECTED], and it was quite acceptable for the physical size. The question then becomes - how often will I be reading pages of text on my Freerunner. I really don't know. However maps are very similar to textual content - sharp contrast and the potential for lots of information in a small space. I tried a similar experiment comparing a google-maps image 320x240*147dpi and simulated [EMAIL PROTECTED], and the 320x240 felt very constrained - not enough information on the display. The 640x480 felt more comfortable and - I think - would have been readable if I had the real resolution. Maybe you could ask again we have all had our Freerunners for a couple of months. What was the story with 320x240x25fps video again? Is it possible with the available memory bandwidth? NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2.5mm or 3.5mm
On Fri, May 30, 2008 4:18 pm, Joerg Reisenweber wrote: > Hi community! > A short poll: on a future GTA0x (>2), would you prefer to have > A) "standard" 2.5mm headset (mic+phones) connector, where you have to buy > a > cheap adapter if you want to use your "old" headphones, (the way like it's > for GTA01/02) > or > B) classic 3.5mm headphones "Walkman(R)" connector, where you have to DIY > an > adapter for any standard cellphone headset? (or does anybody know of 3.5mm > headSET standards or adapters?) Does this "classis Walkman(R) connector" have mic-input (which the classic Walkman doesn't)? If so (or if there is a second 3.5mm for the mic) then I would say option B for me personally. But then I never use a headset on my phone, while I do use headphones on a music player. NeilBrown > > > please hurry to vote, we have to make a decision. Thanks > > cheers > jOERG > Openmoko-HW-development > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Value of headsets and pouches for 10 pack orders?
On Fri, May 16, 2008 3:59 pm, nickd wrote: > That's strange. I'm in Brisbane and it worked out cheaper to buy in > bulk. I estimated the postage as $70 for the bulk and $50 for individual > (using AusPost's Int. parcel calculator). What was your > postage/calculations? I've attached the worksheet I used to come to my > amount. > Maybe I'm missing something obvious, but where did you get the 5% figure from? Looking at the different tariff classes in http://www.customs.gov.au/site/page.cfm?u=4273 The openmoko could only possibly fall in section 16 and chapter 85. Of those the closest fit seems to be item 8517. (See http://www.customs.gov.au/webdata/resources/tariff/chapter85notes.pdf) According to http://www.customs.gov.au/webdata/resources/tariff/chapter85goods_b.pdf there are several subclasses of 8517, but the closest seems to be 8517.12.00 - Telephones for cellular networks or for other wireless networks which is "Free" of import duty. However I couldn't find "Computer" or "PDA" in Chapter 85, so maybe I'm missing something. But the above suggests that if the package is marked that it contains Cellular Telephony Devices (sounds more impressive than 'mobile phones') they should be customs-free ??? NeilBrown ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 10 or more phones order
On Mon, April 28, 2008 4:27 pm, Flyin_bbb8 wrote: > from my understanding its the first :p but don't know.. My understanding is that there will be two different things that you can buy. - a single phone. - a pack of 10 phones. You can buy multiples of each. If you like, you can be 10 lots of "a single phone". but this would be more expensive than 1 lot of "a pack of 10 phones". You cannot but "a pack of 12 phones". You would need either "a pack of 10 phones" plus 2 lots of "a single phone", or 2 lots of "a pack of 10 phones" (which would leave you with some spares). NeilBrown > > On Mon, Apr 28, 2008 at 9:13 AM, Pietro m0nt0 Montorfano > <[EMAIL PROTECTED]> > wrote: > >> Well, may be that i missed the answer but someone asked if the discount >> and the extra stuff are applied only to the 10 pack or it could also be >> a 12 >> pack? >> So to let you understand the condition is: >> >> if (phones_ordered == 10) >>do_the_10_pack_trick(); >> >> or it is something like: >> >> if (phones_ordered >= 10) >>do_the_10_pack_trick(); >> >> ? :D >> >> Cya >> >> Pietro >> >> ___ >> Openmoko community mailing list >> community@lists.openmoko.org >> http://lists.openmoko.org/mailman/listinfo/community >> > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
