Re: CSD calls from Neo Freerunner
On Monday 20 January 2014 07:31:55 Michael Spacefalcon wrote: For those who don't know what CSD is: http://en.wikipedia.org/wiki/Circuit_Switched_Data [snip test call logs] CSD calls may be placed from a GSM mobile either to a land line or to another mobile. (I don't know if it's possible to establish a CSD connection from a land line to a mobile.) It's possible to establish the connection from land line to mobile, with both analogue and ISDN landlines. I used to use it for remote access to condition monitoring systems. You should be able to send and receive faxes too. It does need carrier support though. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bitcoin Client
On Monday 06 May 2013 13:32:29 Allan Savolainen wrote: On Mon, 06 May 2013 11:27:53 +0300, Patryk Benderz patryk.bend...@esp.pl wrote: [cut] no, mining is not an option, but being able to use it as a wallet could be! That would be something :). I suppose you should be able to easy install one of wallets on top of QtMoko, as it is Debian based... the possible issue here is wallet's GUI not prepared for small screen. There might also be issue with the size of the blocks files, they seem to consume over 6.9GB on the disk Recent clients seem to be addressing this problem (going by release info not personal experience.) https://bitcointalk.org/index.php?topic=173182.0 How they got there: https://bitcointalk.org/index.php?topic=141543.0 https://en.bitcoin.it/wiki/BIP_0037 If I understand correctly the current version of Bitcoin-Qt should be able to work in this mode. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Invitation to indicate interest in next batch of GTA04A5 boards
On Tuesday 26 March 2013 16:13:43 joerg Reisenweber wrote: Encrypted GSM calls are basically not feasible to transfer encrypted voice you need a data link between the both ME, GSM creates GSM-codec voice path, not a data path. Means your data gets mangled by carrier's audio processing. You *can* *not* send data at a reasonable speed over a GSM voice call link. IIRC it's been done with GSM data calls but I don't know if the code was ever released. At 9600bps it's not just SIP/ZRTP over PPP though! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: bt slide keyboard
On Friday 08 February 2013 16:03:14 Alfa21-mobile wrote: do you know if there is something similar usable with gta? http://www.usbgeek.com/collections/iphone/products/iphone5-case-slideout-key board Bluetooth keyboards ought to work. I used to use a Stowaway with an old SHR image on GTA02 but I've not tried it on a recent release, or on qtmoko. That's the first one I've seen with a slide mechanism. If that's what you want your best bet may be to make an adapter for the moko to clip into the iPhone footprint. How are your solid modelling skills? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Enhancing an RPi with phone capabilities
On Thursday 24 January 2013 16:18:38 Timo Juhani Lindfors wrote: jcomm...@math.leidenuniv.nl writes: capabilities. And with that, I do not mean only SMS, but also phone calls (calling and receiving). Just plug in a USB 3G modem? Assuming it's one with voice capability and software support, yes. Some research will be needed to see if there's a combination of bits known to work with the Pi. Ofono is packaged in Raspbian and claims support for a selection of 3G dongles. Probably the easiest route. I think there's a GUI via a telepathy module and empathy. FSO is also packaged, but I don't know what dongle support it has, if any. Asterisk should work with chan_sebi or chan_dongle, but they don't appear to be packaged. Elastix may be easier than Raspbian for this. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ubuntu / Firefox OS for Openmoko
On Friday 11 January 2013 19:00:37 Radek Polak wrote: On Friday, January 11, 2013 05:04:28 PM Sebastian Krzyszkowiak wrote: Ubuntu and Firefox OS may be good opportunities to use for marketing. Yup, i think if we were the first HW that runs Firefox OS and Ubuntu this could make our phone mentioned in some bigger magazines and make some noise. That boat's already sailed I'm afraid. Firefox OS already runs on Galaxy SII, Galaxy Nexus, Nexus S and Nexus S 4G, plus pandaboard and a few others. Ubuntu are supposed to be releasing an image for the Galaxy Nexus soon. Regards Radek ___ 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: is my GTA02 getting old?
On Monday 10 December 2012 23:52:56 Ed Kapitein wrote: Are the batteries with the coulomb counter for the GTA02, still produced, or are they of the same age as the original FR's? If so, they must be near the end of their shelf life, is a compatible battery (with a coulomb counter) available? I have one battery that is very dead an two that are getting old and have to be recharged more often. I doubt they're still being made, but you can probably get a definitive answer from Pulster or GoldenDelicious. The SANYO UF653450S they contain still seems to be available, so sticking the controller board on a new cell should be possible. Of course they could be old stock too. My reading of the BQ27000 datasheet is that it'll get a power-on-reset when the new cell is attached, and should then learn the new cell capacity. I may have missed something important though. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Where is the design and electric scheme of gta04?
On Monday 12 November 2012 22:40:30 Nadav Vinik wrote: Hello Where is the design and electric scheme of gta04? http://projects.goldelico.com/p/gta04-main/page/Manual/ Also, Is there any guide how to open the case of new freerunner? I open the two screws of the case and it still not open http://wiki.openmoko.org/wiki/Disassembling_Neo1973 Thanks Nadav ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] No gta-04 available
On Thursday 08 November 2012 23:11:06 Michaël Parchet wrote: Le 30 oct. 2012 à 17:27, Al Johnson openm...@mazikeen.demon.co.uk a écrit : On Monday 29 October 2012 20:16:34 Michael Parchet wrote: Hello, The switzerland mobile phone providers will prepare the LTE (4g) network. Do you think to make a 4g matherboard gta05 ? Option now have LTE modules, but they are a little bigger than the gtm601u in the GTA04 so aren't quite a drop-in replacement. They do say the 601 will fit on the footprint of the 801 though, so they are probably electrically compatible. http://www.option.com/en/products/products/lgamodulegtm801u/ Hello, Do you test this 4g card in a freerunner ? No. It wouldn't fit in a freerunner (GTA02). I pointed it out because it is from the same supplier as the 3G module in the GTA04 and appears intended to be interchangable, but is slightly bigger. It would be a way for GoldenDelicious to offer 4G with minimal redesign of the GTA04, or perhaps put them on the GTA04 without modification _IF_ there's enough space. Whether they feel enough people will buy one to make the extra work worthwhile is another matter entirely. Is this card compatible 3g ? Yes. Follow the link and it shows you which standards and radio bands it works in. Note the limited 4G bands, meaning it won't work with 4G in some countries, a limitation that seems to apply to all 4G products at the moment. Best regarda mparchet In my opinion, with only a 3g maserboard, the future freerunner will be quickly out of date. Whath's your opinion ? Any low volume product that isn't backed by a big corporate is going to be a bit behind the times simply because the manufacturers won't release That said, the 4G issue looks like a relatively easy problem to solve. Getting the economics to work seems to be the biggest hurdle at the moment. Best regards mparchet ___ 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: [Gta04-owner] No gta-04 available
On Thursday 08 November 2012 23:11:06 Michaël Parchet wrote: Le 30 oct. 2012 à 17:27, Al Johnson openm...@mazikeen.demon.co.uk a écrit : On Monday 29 October 2012 20:16:34 Michael Parchet wrote: Hello, The switzerland mobile phone providers will prepare the LTE (4g) network. Do you think to make a 4g matherboard gta05 ? Option now have LTE modules, but they are a little bigger than the gtm601u in the GTA04 so aren't quite a drop-in replacement. They do say the 601 will fit on the footprint of the 801 though, so they are probably electrically compatible. http://www.option.com/en/products/products/lgamodulegtm801u/ Hello, Do you test this 4g card in a freerunner ? No. It wouldn't fit in a freerunner (GTA02). I pointed it out because it is from the same supplier as the 3G module in the GTA04 and appears intended to be interchangable, but is slightly bigger. It would be a way for GoldenDelicious to offer 4G with minimal redesign of the GTA04, or perhaps put them on the GTA04 without modification _IF_ there's enough space. Whether they feel enough people will buy one to make the extra work worthwhile is another matter entirely. Is this card compatible 3g ? Yes. Follow the link and it shows you which standards and radio bands it works in. Note the limited 4G bands, meaning it won't work with 4G in some countries, a limitation that seems to apply to all 4G products at the moment. Best regarda mparchet In my opinion, with only a 3g maserboard, the future freerunner will be quickly out of date. Whath's your opinion ? Any low volume product that isn't backed by a big corporate is going to be a bit behind the times simply because the manufacturers won't release That said, the 4G issue looks like a relatively easy problem to solve. Getting the economics to work seems to be the biggest hurdle at the moment. Best regards mparchet ___ 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: Help needed with GSM Geolocation without GPS
On Tuesday 06 November 2012 15:29:52 mauve wrote: On 06.11.2012 11:37, robin wrote: hi daniele, maybe you can help me with your code: what I get snip dbus.exceptions.DBusException: org.freesmartphone.GSM.DeviceFailed: OK any ideas why the call does not work? Because FSO supports getting the subsequent cell IDs, but the modem does not support reporting these, so you get a FAILED. It does, but not if you're currently registered with a network. You cannot (as I understand it) get any information of this form from the GTA01/2 modem. You can, but you need to unregister first. Just tested on a very old SHR with an expired SIM. On power up it registers sufficiently to make emergency calls. At this point GetServingCellInformation returns correct data but GetNeighbourCellInformation does not. Call org.freesmartphone.GSM.Network.Unregister and subsequent GetNeighbourCellInformation calls will return data for the cells it can see. Those bits of the API may have changed since the version I tested on, but if it can't get the data it's a bug rather than a problem with the modem. (Please note, this is fuzzy memory, it's been a while). Understandable. I had to test it to see if I remembered correctly. ___ 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: Help needed with GSM Geolocation without GPS
On Tuesday 06 November 2012 08:09:58 robin wrote: Sounds good. I wonder what the trade-off is between implementing something like this from scratch for GTA04, and trying to integrate an existing partial solution such as GeoClue? hi neil, as far as I understand geoclue comprises a communication between a provider and your phone, so that would mean data transfer via the modem. This would certainly be one solution, but it would be nice if the user could choose between: a) GSM - Provider - Location b) GSM - offline database - Location (saves money and battery(?)) I don't know if geoclue can be easily extended to use the cells.txt.gz file as an alternative input. That would be nice, because then one could actually choose between a) and b). http://www.freedesktop.org/wiki/Software/GeoClue#Learn_more As far as geoclue's concerned a Provider is anything that implements the dbus interface. There's no reason for data to go over the modem, it's just that most of the current Provider implementations use online data services for lookup. You can install whichever Providers you want. All(!) that's needed is a Provider that implements the Position interface, looking up current and/or neighbouring cells in the local file/database and returning a location extimate. IIRC that would be quite a simple dbus service to implement, at least as a proof-of-concept, but I've probably forgotten somehting important. Applications can pick whether to use the Master Provider (which uses data from the 'best' available Provider) or a specific Provider, so you can have a choice between a) and b). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] No gta-04 available
On Monday 29 October 2012 20:16:34 Michael Parchet wrote: Hello, The switzerland mobile phone providers will prepare the LTE (4g) network. Do you think to make a 4g matherboard gta05 ? Option now have LTE modules, but they are a little bigger than the gtm601u in the GTA04 so aren't quite a drop-in replacement. They do say the 601 will fit on the footprint of the 801 though, so they are probably electrically compatible. http://www.option.com/en/products/products/lgamodulegtm801u/ In my opinion, with only a 3g maserboard, the future freerunner will be quickly out of date. Whath's your opinion ? Any low volume product that isn't backed by a big corporate is going to be a bit behind the times simply because the manufacturers won't release That said, the 4G issue looks like a relatively easy problem to solve. Getting the economics to work seems to be the biggest hurdle at the moment. Best regards mparchet ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Problems using recent Rogers Wireless (Canada) SIMs in GTA02
Have you tried the new SIM in any other 2G-only phone? SIMs from 3(UK network) seem to work only in 3G-capable devices. I never looked into how or why, but it's possible Rogers are doing this with new SIMs either by accident or design. On Wednesday 26 September 2012 21:53:14 Pascal Gosselin wrote: In 2010, we were able to take circa mid-2008 Roger Wireless SIMs (Canada) borrowed from an iPhone 3G and get it to work in Android Froyo on the GTA02 850Mhz. Two years later, we decided to add some GPRS reporting capability to our Wi-Flight product which is currently using Wi-Fi only, we are unable to get a carrier registration at the AT command level using two Rogers SIMs (both from 2012, one used in an iPhone 4 and the other in a Samsung Galaxy S II Skyrocket (LTE)). The GSM baseband code was at Moko8 so we had the fix for bug 666. We tried Moko11 but it didn't make a difference. We repeated the same Android Froyo setup and indeed it doesn't work when we try the circa 2012 SIMs. Our product doesn't run on Android, the Froyo stuff was just tried to attempt to replicate something that worked before. I found a working older Rogers full-sized SIM from my GSM-enabled alarm system, which I think it at least 3-4 years old. It worked just fine in a Nexus S and I was able to send an SMS and Edge data from the phone (it's a T-mobile AWS phone so no 3G on Rogers). The conclusion so far is that something has changed in the Rogers SIMs that makes it incompatible with the GTA02. I am wondering if anyone else has encountered this problem. I'd be happy to be able to get a Fido-branded card to work (haven't tried that yet). We've repeated the same issue with a half-dozen GTA02s so we're pretty sure it's not a one-off phone problem. -Pascal +---+ Pascal Gosselin President Wi-Flight pas...@wi-flight.net cell (514) 298-3343 office (450) 676-6299 ___ 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: Tracfone? Sim Card?
On Thursday 23 August 2012 19:27:28 Travis Bachelder wrote: Is it impossible to use a Tracfone Simcard in a GTA02 FR? It sounds that way according to their wikipedia entry: TracFone service is limited to TracFone-branded handsets (all TracFone handsets are pre-programmed by the manufacturer; therefore, the handset is locked including its latest GSM models). Other GSM handsets will not accept TracFone SIM cards, even if unlocked. Additionally, on most handsets, some features like USB and Bluetooth have been modified by the manufacturer to prevent direct transfer of user files. https://en.wikipedia.org/wiki/TracFone_Wireless#TracFone This probably means they do something nonstandard talking to the SIM, which is handled by the closed GSM chipset firmware. If Osmocombb ever becomes a replacement for the closed firmware you might be able to work out what's different and add support for it. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: sandwich case idea
On Friday 27 July 2012 14:58:11 Alfa21-mobile wrote: hello, what do you think about a multi layer case like this one, but made for GTA* ? http://www.pibow.com/ I suggested that method some time ago. I started started modelling it but ran out of cad skill. Perhaps I should have started with cardboard and a knife instead. Points to consider: Acrylic gives beautiful edges but is fairly brittle. Other plastics may be mechanically better but won't cut so cleanly. Plywood might work well.. Thickness tolerance in sheet plastics is quite large, so design with it in mind. Cut tolerance is good enough to engineer press fits between cut surfaces. Buttons need some thought, and probably some experiment. It would be easier to house a board designed with this sort of housing in mind than to retrofit to boards built for an injection moulded case. look the low price! I think something like this could also be made by a reprap or any 3D printer ...or laser cut service: http://www.vectorealism.com/en/make-a-product/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ideas for a personal cluster with gta04
On Wednesday 06 June 2012 09:38:58 robin wrote: what did you have in mind for the geolocating via gsm towers and wifi? http://openbmap.org ? do you know any projects which make use of such data (triangulation). this might be very interesting to enhance navit's routing possibilities if it takes to long to get a gps-fix. Geoclue[1] is an open location system that is supposed to agregate data from multiple sources including gps. AFAIK there isn't an openbmap plugin for it yet. Gsmloc is mentioned for cell tower triangulation but a cursory look suggests it's no longer active. [1] http://www.freedesktop.org/wiki/Software/GeoClue regards robin ___ 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: Discussion: what are your dreams for the Openmoko Community
Nice list. Comments below... On Sunday 29 April 2012 18:59:34 Benjamin Deering wrote: A threaded/prepared camera hole for attaching a microscope or telescope lense would be nice. Is there any suitable standard for this? GPS program displays heading information from a digital compass, but position information from the GPS (multiple gpsd instances?) I'd go a stage further and propose a 'composite' gpsd device providing location and orientation based on all available sensor information, so the barometer augments the relatively poor vertical resolution of the GPS etc. Most of the estimating engine has probably been implemented in the various UAV projects. PGP encrypted voip (http://zfoneproject.com?) linphone should do this since 3.5.1. It would need some work to tie in better to FSO or qtmoko though (address book, audio switching on answer etc.) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA04_This is my Fantasy
On Monday 23 April 2012 10:02:17 Dr. H. Nikolaus Schaller wrote: Hi Travis, Am 23.04.2012 um 01:39 schrieb Travis Bachelder: [snip discussion of SD types and limitations] If the micro SD is limited on it's storage space, then is the GTA04 board even capable of supporting a built in external hard drive? Or is that make for a serious design change? Mechanical hard drives are generally too big. The smallest one I know of was the IBM/Hitachi Microdrive in Compact-Flash format. I think currently, the smallest ones are 1.8 inch diameter. This does not fit into the case of a smartphone... Are you sure? I just put a Tosh MK1216GSG on top of a GTA02 and it looks like a perfect fit for a new case layer, giving just enough room at the corners for wall thickness. It probably fails for needing a custom USB-microSATA adapter to fit the available space, and there may not be enough power available (3.3V 700mA), as well as making the phone rather bulky. I don't remember whether there's a USB port available internally on GTA04. Here: http://www.linuxfordevices.com/c/a/News/Toshiba-MK2x39GSL/ you can see the physical dimensions. And the interfaces of such drives (e.g. SATA) are not available on the OMAP processor. So they may need additional glue logic. What you also could do is to connect an external hard drive through the USB/OTG port. But that would no longer allow you to use the same USB port to connect to a desktop PC as you have planned. If you've got an external drive you don't need the phone as an intermediary. The 1.8 drives are available in external USB enclosures, perhaps the best bet. Or you could keep a USB stick on your keyring... If you _really_ want it as part of the phone you could embed the USB stick, or a USB SDXC reader, in a replacement back for the phone. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Keyboard for GTA04
On Thursday 15 March 2012 12:57:23 Dr. H. Nikolaus Schaller wrote: During the Openmoko Stammtisch Munich yesterday, we have once again discussed options to build a special GTA04 keyboard. And now I think we have found a way to really square the circle. The square being functionality and the circle being cost. The idea is to use: * off-the shelf pushbutons (Panasonic has some nice and very flat SMD buttons readily available at DigiKey) * a Shapeways made custom case * a not very sophisticated PCB with the buttons, a Bluetooth HCI module [1], a small LiIon battery and a microcontroller scanning the keyboard and supporting USB charging Now comes the key idea: having a shapeways printed case makes it possible to think about a keyboard built into a replacement battery cover. It makes it a little thicker than normal, but you can detach it and use it as a keyboard. I was with you up to the bluetooth + battery part. Why not use a slide out keyboard with a TCA8418 and wired i2c connection to the main board? The board should be cheaper and simpler, the plastics little different to a sliding bluetooth device, and there'd be no messing about remembering whether you'd charged the keyboard. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Keyboard for GTA04
On Thursday 15 March 2012 15:30:34 Dr. H. Nikolaus Schaller wrote: Am 15.03.2012 um 15:10 schrieb Al Johnson: On Thursday 15 March 2012 12:57:23 Dr. H. Nikolaus Schaller wrote: During the Openmoko Stammtisch Munich yesterday, we have once again discussed options to build a special GTA04 keyboard. And now I think we have found a way to really square the circle. The square being functionality and the circle being cost. The idea is to use: * off-the shelf pushbutons (Panasonic has some nice and very flat SMD buttons readily available at DigiKey) * a Shapeways made custom case * a not very sophisticated PCB with the buttons, a Bluetooth HCI module [1], a small LiIon battery and a microcontroller scanning the keyboard and supporting USB charging Now comes the key idea: having a shapeways printed case makes it possible to think about a keyboard built into a replacement battery cover. It makes it a little thicker than normal, but you can detach it and use it as a keyboard. I was with you up to the bluetooth + battery part. Why not use a slide out keyboard with a TCA8418 and wired i2c connection to the main board? The board should be cheaper and simpler, the plastics little different to a sliding bluetooth device, and there'd be no messing about remembering whether you'd charged the keyboard. Yes, there are contact points on the GTA04A4 board prepared for this. Thanks to your fine documentation I could check that before I posted ;-) The power and unused i2c3 on the test pads looked good. Did I miss a better one? It looks like there's a reasonable bit of space above them in the case too. My main concern are that cables may break too often and connecting it to the main board plus getting it out of the device is a little fiddly. I agree that's probably the trickiest bit. Any idea how sensitive the i2c is to the cable? Would a flexible headphone lead type work, or would it need flexi-pcb? But this could be a cheaper (and easier to develop) option than BT+Battery. It just needs to place the TCA (plus some ESD-protection) on the board and a set of buttons like these: http://search.digikey.com/de/de/products/EVQ-P6DB35/P14165CT-ND/1966474 With a thin cover of laser cut and etched stainless, or a plastic part to keep it all from shapeways? Either option would make changing the keymap relatively easy. Also I thought the TCA included ESD protection, although that was just from a quick glance at the datasheet. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: what to with 02 when upgrading to 04? was: Re: How to bring forward the community?
On Sunday 04 March 2012 12:51:08 arne anka wrote: (but i would be willing to donate/add a couple of euros if it will help someone to buy a GTA04 who can't afford the full or even the rebated price) myself and others in this list have made the same offer... that's very good to know. i didn't follow the development of sales too close (though close enough to finally convince me, i may want a GTA04, too ;-) - how many are there an how much additional GTA04 could we buy/fund in adavnce between us (if nobody takes up the offer)? - how well known is that to prospective buyers of limited funds? such an offer, however generous it may be, is of little use if potential users are not aware of it - i for one did not know about it, except the remark about 5% rebates still being available since several early subscribers did not claim it. There are a few places you can 'order' a donation, but I don't know how well known they are. http://www.handheld-linux.com/wiki.php?page=GTA04referer=GTA04-Early-Adopter http://www.handheld-linux.com/wiki.php?page=Openmoko%3ACommunity ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Om2008.9] screen locking application?
On Monday 05 March 2012 11:37:12 Hrabosh wrote: BTW .. would it be possible to run TrueCrypt on FreeRunner? It looks possible in theory. There are reports of it running on other arm platforms. Debian apparently don't package it for licensing reasons, but do have instructions for building and installing it. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] GTA04-Custom: EAGLE schematics and board file blueprint for developing expansion/adapter boards
On Saturday 03 March 2012 10:00:27 Lionel Broche wrote: Coming back to the original message, is it possible for an averaged-skilled person to carry out the customisation of the GTA04 board to change the connector? Also, would it be feasible to make a GTA04 module that could be connected to external screens while powered, so that you could switch from tablet to phone? I just ask out of curiosity, but it would be fun to connect your phone to a large display in your car for easier sat nav, then take it back as a phone. Why not use a DisplayLink USB display like the touchscreens at [1]? You might even find a daylight readable one for the car. Not sure if GTA04 can charge while in host mode though - the docs suggest not but don't say explicitly. [1] https://newit.co.uk/shop/products.php?cat=16 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to bring forward the community?
On Thursday 01 March 2012 13:35:34 Gerald A wrote: Hi, On Thu, Mar 1, 2012 at 5:45 AM, Al Johnson openm...@mazikeen.demon.co.ukwrote: On Wednesday 29 February 2012 11:55:46 Gerald A wrote: I've had a few bluetooth keyboards and a bluetooth mouse paired and function with my Neo. I can't remember what software rev it was, but if it works in the cranky old stuff I was using, I'm sure it should work in a later version. That's not a safe assumption. I know SHR used to work with my Stowaway keyboard, but I also remember updates that broke it. Sorry, I didn't mean to imply that it worked in some particular (later) version. The OP seemed to be wondering if it had worked at all, and indeed it did. Did the updates break it and it never got fixed? I don't remember, and I've not tested it in a recent image. At the time it wasn't something that was tested before release, and there were only a couple of us that spotted it. When it worked it worked well though, so it may be fine. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: shr-2012.01-rc1, please test
On Friday 02 March 2012 11:55:27 Martin Jansa wrote: Hi, on FSOSHRCON'11 we decided that we should do first official release. We expected to ship it in January, but everybody was quite busy so only now we have something to call at least rc1. Of course there are still some bugs, some are even already known, but please let us know what is blocking this release and what can be fixed in next one. To do that please test latest staging images+feeds. See http://www.shr-project.org/trac/wiki/Stabilizing http://www.shr-project.org/trac/wiki/StagingTests for details how to test them. I've started image rebuild for staging 032, but I'm leaving for 5 days tomorrow at 4AM and I guess they won't be finished in time to close 032 for easier testing.. that's why I'm sending this announcement now. If there is at least few test reports tonight I'll merge staging feeds up to 031 to public feed so we get more users using it. Cheers, I can't see any rootfs to test. Am I looking in the wrong place? From the docs linked above it looks like it should be in: http://build.shr-project.org/shr-core-staging/031/images/om-gta02/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: shr-2012.01-rc1, please test
On Friday 02 March 2012 18:34:20 Sebastian Krzyszkowiak wrote: On Fri, Mar 2, 2012 at 18:25, Al Johnson openm...@mazikeen.demon.co.uk wrote: I can't see any rootfs to test. Am I looking in the wrong place? From the docs linked above it looks like it should be in: http://build.shr-project.org/shr-core-staging/031/images/om-gta02/ Not every staging feed has whole image rebuilt. You need to download and install some older image and upgrade to 031 after that. Instead of manually navigating through the directories, you can use download wizard on http://build.shr-project.org/ to automatically find latest image available (requires JavaScript). Just to make sure I've got the right end of the stick, and won't be adding results for the wrong thing: rootfs from 030 kernel and qi from 031 fix the feeds at 031 using: sed -i 's#/shr-.*/ipk/#/shr-core-staging/031/ipk/#g;' /etc/opkg/*-feed.conf update/upgrade and start testing ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to bring forward the community?
On Wednesday 29 February 2012 11:55:46 Gerald A wrote: Hi, On Wed, Feb 29, 2012 at 5:45 AM, Giacomo 'giotti' Mariani giacomomari...@yahoo.it wrote: I own a similar one ( http://www.ebay.co.uk/itm/Mini-Pocket-Bluetooth-Keyboard-PC-PDA-Phone-/2 60694344470 ) but I've never been able to use it on my freerunner. I get it paired (and some traffic is visible hcidump on SHR) but it never worked as input device. Did you have any (successful) experience? I've had a few bluetooth keyboards and a bluetooth mouse paired and function with my Neo. I can't remember what software rev it was, but if it works in the cranky old stuff I was using, I'm sure it should work in a later version. That's not a safe assumption. I know SHR used to work with my Stowaway keyboard, but I also remember updates that broke it. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: How to bring forward the community?
On Tuesday 28 February 2012 21:22:40 Dr. H. Nikolaus Schaller wrote: Am 28.02.2012 um 09:47 schrieb Davide Scaini: I think that the success of spark [1] explains the failure of GTA04. My 2 cents d [1] http://aseigo.blogspot.com/2012/02/spark-pre-orders-closed.html May be, but I am not sure. A 7 inch tablet (and much worse pixel per inch) without UMTS and no GPS and other gimmicks is not really a smartphone platform like the GTA04... The price of 200 EUR/USD is indeed good and I still wonder how they can make it such cheap. Except if they produce thousands of units. It's no secret the same hardware is widely sold as an android device for ~half that. From http://aseigo.blogspot.com/2012/02/spark-answers.html Q: Is the Spark based on the Zenithink C71? A: Yes. The Internet is a clever bunch indeed. Took people all of about 5 minutes to figure that one out. :) Q: Does that mean I will be able to install Plasma Active on a C71 device I purchased elsewhere? A: Yes, that's all in the spirit of openness. However, if you break it, you get to keep both pieces. :) Keep in mind that by purchasing a Spark you will help drive development of Plasma Active, Mer and the push towards an open ARM ecosystem. Q: There are no GPL compliant sources for the C71, right? A: We are aware of this, and we've been working on it. It's been one of the hardest things to accomplish in the entire project. Does anyone know how many units have been subscribed in total? There's no exact figure given, but the link in the grandparent suggests thousands. And when it is planned to become available? Q: When will Spark start shipping? A: We expect to start shipping Sparks to you starting in May 2012. We have a lot of pieces to coordinate, and not just technical issues like the OS image and the content add-on store, but things like packaging design, manufacturing, shipping, import, retail channel coordination. So far we're on track, but I don't want to offer a more precise date than May until we pull the trigger on production. Nikolaus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New $200 tablet?
On Monday 30 January 2012 15:42:14 Patryk Benderz wrote: [cut] This look very interesting. Can’t wait to get my hands on one. It is written 200 EURO, not dollars ($). Makes a difference. No mention of tax either. It's certainly interesting, especially in light of the Lima driver project for the ARM Mali, but we need more details. It looks rather like the ZT280-C71 which is usually somewhat cheaper, but whose manufacturer doesn't seem to have released kernel source. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New $200 tablet?
On Monday 30 January 2012 18:52:19 Thomas Gstädtner wrote: On Mon, Jan 30, 2012 at 17:53, Al Johnson openm...@mazikeen.demon.co.uk wrote: On Monday 30 January 2012 15:42:14 Patryk Benderz wrote: [cut] This look very interesting. Can’t wait to get my hands on one. It is written 200 EURO, not dollars ($). Makes a difference. No mention of tax either. It's certainly interesting, especially in light of the Lima driver project for the ARM Mali, but we need more details. It looks rather like the ZT280-C71 which is usually somewhat cheaper, but whose manufacturer doesn't seem to have released kernel source. You are right. It should be noted that this is by no means any new hardware developed for KDE specifically. This hardware is already widely available for some time, in dozens (if not far more) of variants. I found similar hardware starting at about EUR 70 and the exact same hardware starting at about EUR 100. In Europe it seems to be most commonly sold as Zenithink C71 which is optically and hardware-wise fully identical to the Spark, in China I found it at least under 20 other names with the same hardware, and much more with slightly different specs. Many of them are intentionally sold as cheap i$random_apple_product clones. I haven't found out which company actually builds the device, though I'm pretty sure it's none of those found in the product names. All of those are likely based on AMLogic's reference board designs, and there is NO LINUX UPSTREAM support for either the SoC or the board. Also, there is NO SOURCE CODE available publicly (maybe with the exception of one github repository which seems to have at least some code) which means that all companies currently selling this device are violating the GPL. It may not be upstream, but AMLogic do seem to be publishing source. If everyone is using a reference design it might just work ;-) It looks like their reference bootloader is uboot too. http://openlinux.amlogic.com/wiki/index.php/Arm http://openlinux.amlogic.com/download/linux/GPL_code_release/ The lack of source from OEM and below is nothing new - it's just more obvious than with the routers and STBs where it's been happening for years unfortunately. There are also no proper spec sheets, datasheets, or code references in any way. It is to hope, that the KDE guys are interested enough to have everything properly open sourced to be GPL compliant, though I fear they - like most open source projects - don't have the pull on Chinese hardware OEMs to change a horrible situation to a good situation. I'll live in hope until there's a proper release. Anyway - in my opinion so far this is a lot of fuzz about hardly anything. It'll be one of very few tablets that run linux without needing an anti-vendor port. That's a good thing in my book, even if it's not ideal. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko Community Survey 2011 – Results
On Monday 16 January 2012 09:31:23 Dr. H. Nikolaus Schaller wrote: Let me describe my first observations from these figures (not deeply elaborated): 1. this result shows that we have a very large bandwidth what we see as an acceptable price. For some of us the current price (which is production cost driven) is ok, while for others it is far too high. 2. I find it interesting that there is no big difference between Q1 and Q2 which indicates that we either buy immediately or are just willing to add 50 EUR to make us unwilling buyers. This appears to be a strong mental level of maximum acceptable price. Or is it just available budget? If we have it we buy immediately, if we don't we can't even buy unwillingly? Or is it driven by the addition of Q2 only after 30 responses on Q1 only? For me GTA04 is a bigger chunk of a smaller toy budget than GTA02 was, plus I needed a new phone then and I don't now. I want a GTA04 but it's hard to justify right now. Making a donation to help keep the project alive would be much easier to justify, but I haven't seen any way to do that. I'd like to give something now so that there's a chance I can still buy an open phone in the future. Having a gold standard for phone openness is important, even if I can't afford one just now. 3. at the current price of the GTA04 group tour (450-500 EUR range) we can expect approx. 30% buyers. This would still mean 6000 of the originally sold GTA02 devices. Hm. We are still far away from this figure with subscriptions. What are the reasons? That's an apples/oranges comparison - eventual sales vs. early adopters. I imagine experience with problems that emerged after launch (buzz, #1024, bass etc.) might put people off buying early, as might the unknown battery life. 4. a final observation is that I have to conclude that some of us have no realistic perception of the market prices. More than 40% would not want to pay more than 200-250 EUR for a complete GTA04 (even with case etc.). This makes me really puzzled as the GTA02 was never sold cheaper than 199 EUR. Isn't getting UMTS, fast 3D graphics any value to the majority of the Openmoko community? The cheapest UMTS Android 2.2 device I can currently get in Germany is at 129 EUR (most likely from some overstock clearance). Has a 320x240 display, no sensors, no free and open software. No hardware description, no schematics. Appears to be crap and much less featured than the GTA04. But the poll result indicates this is the way we should go. Really? https://en.wikipedia.org/wiki/ZTE_Blade Consistently cheaper (99UKP/117EUR) than the model you suggest, and significantly higher specification. The bootloader isn't locked, and I think the only binary blob is for hardware accelerated graphics. It was recently superseded by a higher spec version (ZTE Crescent) at the same price, apparently with a similar level of open/closedness - the android mod community is still getting to grips with it. I don't know if anyone's tried building SHR for it, but it's MSM7k family. When GTA02 was released there was nothing like this on the market. If you wanted any degree of openness your choices were very limited and all relatively expensive. GTA04 retains the gold standard of openness, but there is now competition from devices that aren't documented, but where you can build cyanogenmod from a git checkout, for a fraction of the money. For some people that will be all the openness they want, or can afford. I wnder how the community thinks it can be done at such low prices? One answer (that I don't like at all) could be: http://www.businessinsider.com/apple-child-labor-2012-1 So please prove my last observation and conclusion to be wrong. I don't think there's any illusion in the community about how it's done - major economies of scale combined with working practices that wouldn't be allowed in Europe or the US. The recent RaspberryPi manufacturing post has probably been a timely reminder for many. It's ubiquitous and hidden though, so people tend not to think about it, and the price of virtue can come as a bit of a shock. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] SHR: no audio in headphone
On Saturday 14 January 2012 08:54:32 Matthias Apitz wrote: El día Friday, January 13, 2012 a las 09:58:20PM +0100, Matthias Apitz escribió: El dÃa Friday, January 13, 2012 a las 09:35:22PM +0100, Matthias Apitz escribió: Hello, From one day to the other I lost audio in my FR headphone running SHR: just to clarify: with 'headphone' I'm talking about the speaker of the FR above the display, not about some external headset/earphone; I have re-installed kernel and root-fs and all is fine again; with Don Google searching for the words shr no audio (without the ) one can find similar threads and hints about, for example: http://www.digipedia.pl/usenet/thread/12997/172/ opkg install --force-reinstall fsogsmd-config fsodeviced-config What could have caused this loss of configuration? Next time I will investigate this, because it does not is a hardware fault... Sounds like one of these, assuming they aren't really the same bug/design flaw. http://trac.freesmartphone.org/ticket/527 http://trac.freesmartphone.org/ticket/576 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Marketing] Ideas / Plan
On Thursday 29 December 2011 22:39:01 Alishams Hassam wrote: Things to mention: 1. The GTA04 *requires* an FR / NEO1974. This should serve as a request to get people who have these collecting dust, selling them online. Maybe this should be made more explicit? This isn't strictly true. The FR/Neo1974 is certainly the easiest way to get screen, case, antennae, speakers, vibro-motor etc. but suitable parts can be sourced separately and a case made. It may be worth supplying a list of suitable alternative parts and sources, or even a parts kit, to make it easier for people without a donor phone. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Anyone has done a Comparison GTA02 GPS Antenna vs. Nokia N95?
On Monday 05 December 2011, Dr. H. Nikolaus Schaller wrote: Hi, Am 05.12.2011 um 15:51 schrieb rakshat hooja: On Mon, Dec 5, 2011 at 2:44 PM, Dr. H. Nikolaus Schaller h...@goldelico.com wrote: We have seen that the N95 has a quite simple flexible PCB GPS antenna instead of the ceramic patch of the GTA0*. Does anyone of you own both, a N95 and GTA0*? I have a N95 and a few GTA02s. Let me know what exactly do you want me to test re GPS? Great! Do you have some software for both that shows the satellite positions and (relative) signal strength? What will be interesting is if the GTA02 sees the satellites more uniform. The background is that the ceramic patch antenna in the GTA02/04 should have a more omnidirectional sensitivity while the N95 has just one flexible PCB with a long wire. ?! Would that actually provide enough signal to get a lock without assistance? I ask partly because it may explain why a friend couldn't get a gps lock on an N95 when on deck on a yacht out of range of mobile networks. GTA02 was reliably coldstarting in ~40s as you'd expect with a clear sky view like that. You need significantly better signal to get the initial fix than to maintain it, as we found with the SD drive strength issue. And the latter should show some clear direction sensitivity. I.e. if the device is rotated some satellites should become weaker and others stronger. So far the theory we want to probe :) If the N95 antenna does not show such effects, we may have a cheaper approach for future GTA04 variants. And they may be more easily integrated into new cases than the 15x15mm ceramic block... Have you looked at an antenna like this? Smaller, cheaper and lower performance than a patch antenna, but probably significantly better than a wire. https://www.sparkfun.com/products/9131 Many thanks for any results, Nikolaus ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: what do I install now?
On Saturday 26 November 2011, Timo Juhani Lindfors wrote: dmatthews.org m...@dmatthews.org writes: I've no idea - how is that done? Try passing the following parameters to linux: glamo_mci.sd_max_clk=500 glamo_mci.sd_drive=3 Remember that sd_drive=3 can cause problems for GPS first fix. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The idea of making the MOKO tab
On Thursday 10 November 2011, SZENTE Balint wrote: On Thu, 10 Nov 2011 10:44:00 + Al Johnson openm...@mazikeen.demon.co.uk wrote: That's about all you can expect with the current state of openness on embedded GPUs. If you want acceleration you get a binary blob if you're lucky. Mostly you're just SOL. There are hints that things are moving slowly towards more openness, but that's about it. It's not much better with embedded DSPs, though Ti seem to have a reasonably open interface. Do you know of a better alternative? To be honest, I was not aware about this. I thought, the lack of specifications of Glamo chip is only a special case of the available embedded GPUs. Quite the reverse - it's a special case that Openmoko managed to get docs that can be released to community devs for an open driver at all, even if they do have to sign an NDA. As a result it's got some of the best open support out there for a mobile GPU. That it doesn't work very well with a 640x480 screen is another matter entirely ;-) However, a possible (but more complex) alternative would be to avoid completely the existing proprietary GPU/DSP chips and make an FPGA based phone instead. Then we could use various open source hardware IP cores for CPU, GPU and whatever else is needed, similar to Milkymist, Open Graphics Project or Project VGA. That would be really cool. Cool, but relatively expensive and power hungry. Any idea how many you need to be making before getting the design burned into silicon becomes cost effective? From my point of view a GPU is completely useless without drivers / specifications, thus practically it is not better at all from a basic VGA 2D accelerator IP core. At least an FPGA based open source IP core design *could be* improved in time without changing the PCB. Just think the possibilities. On the other hand, a closed unsupported GPU is dead from the start. If you want a fast and efficient cpu with a good set of interfaces for making a phone or tablet they tend to have a gpu in them too, even if we can't use the acceleration at the moment. It's like things with an iPod dock - it's a useless feature for me, but something with one may still be better than something without for entirely separate reasons. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The idea of making the MOKO tab
On Thursday 10 November 2011, SZENTE Balint wrote: Hello! On Thu, 10 Nov 2011 01:19:23 +0530 RANJAN infi...@gmail.com wrote: 25$ Linux computer at the size of a USB Flash stick http://www.raspberrypi.org/ http://www.raspberrypi.org/wp-content/uploads/2011/07/pcb1.jpg I am worried about the openness of this hardware. They say the following on their wiki[1]: * GPU core: [...] Raspberry Pi team are looking at how they can make some of the proprietary features available to application programmers * DSP core: There is a DSP, but there isn't currently a public API So it is not quite a fully open platform. Sounds similar to the Freerunner's Glamo chip features. [1] http://elinux.org/RaspberryPiBoard#Components That's about all you can expect with the current state of openness on embedded GPUs. If you want acceleration you get a binary blob if you're lucky. Mostly you're just SOL. There are hints that things are moving slowly towards more openness, but that's about it. It's not much better with embedded DSPs, though Ti seem to have a reasonably open interface. Do you know of a better alternative? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Gta04-owner] Clarification
On Tuesday 08 November 2011, Radek Polak wrote: On Tuesday 08 November 2011 13:00:41 Antonio Murdaca wrote: So, it's a dream to have a full GTA04 with case,battery,screen etc etc in a real near future? :( I mean, i have to buy a GTA01/02 and do the stuff to replace the mothherboard to have a GTA04 I bought GTA04 board + LCD display and battery and made myself wooden case [1]. I can use it now as PDA. To use it as a phone i need GPS GSM antenna and speakers IIRC. It would be nice to have possibility to buy also these missing components. If it's using widely used connectors (HFL/uFL probably) you can get gps and multi-band gsm antennae quite easily in various shapes and sizes, so you should be able to find one to fit your case. Finding a suitable speaker for your case shouldn't be much harder. When they start producing their own case I imagine it will have matching parts supplied, but they might not be as good for your case as the alternatives. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GTA04] When is the next and more powerful openmoko releasing
On Monday 24 October 2011, Xavier Cremaschi wrote: Did somebody try to use a 3D printer to see what can be done with this kind of device ? Could we use one to make a case ? It has been looked into. You should find the discussion in the list archives. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GTA04] When is the next and more powerful openmoko releasing
On Friday 21 October 2011, Dr. H. Nikolaus Schaller wrote: Hi Wolfgang, Am 18.10.2011 um 04:00 schrieb Wolfgang Spraul: Ranjit, hey, thanks for noticing :-) Happen to see the case of Milkymist one[1], it is a transparent material and would prefer GTA04 embedded in case like that, with full view of itsy bitsy circuits and chips, don't know how feasible is it. [1] http://milkymist.org/mmone.html That case was designed and manufactured by fantastic Raumfahrtagentur in Berlin http://raumfahrtagentur.org/ roh from Raumfahrtagentur used QCad for design and laser cutting, the original .dxf files are freely licensed and published https://github.com/milkymist/extras-m1/blob/master/cad/protocase_v8_laser .dxf QCad: http://en.wikipedia.org/wiki/Qcad There are many details that still need improvement, mechanical work is labor intensive :-) Screws, spacers, feet, etc. In the later versions we used dichlormethane for gluing the buttons, the entire button design can probably be improved as well. thank you for pointing to these materials. Maybe someone can pick it up to make a new GTA case... Or someone living in Berlin can visit raumfahrtagentur and discuss these ideas. What I wonder is if acrylic materials are easily handled for rounded forms and snap-fits etc. And what the wall-thickness becomes. Acrylic is too brittle for snap fits, but you can laser cut other plastics that are suitable like ABS. You need to heat acrylic to bend into curves (IIRC someone used that method to make a moko handlebar mount). You can bend thin ABS sheet and hold it in place. As a general guide you don't want to cut details thinner than the sheet you're cutting as they tend to distort. There's a reasonable guide here: http://www.pololu.com/docs/0J24/4 Maybe someone can find out... Nikolaus ___ 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: My VoIP experience in Freerunner
On Monday 29 August 2011, Paul Fertser wrote: Be warned though, afaict the FR case (especially if you have both screws properly secured, i personally use my device without those for several years without any issues) provokes echo, so you might need to find an acceptable way (yet-to-be-discovered hardware mod or software) to do echo cancellation. linphone has a simpler echo limiter that can be used if there isn't enough cpu for the proper echo canceller, or if the level of distortion is too high for it to work properly. It lowers or mutes the mic when the speaker level is high so you effectively get half-duplex calls. It's not ideal, but probably better than echo! http://www.linphone.org/eng/documentation/dev/tuning-linphone.html ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner and Wayland
On Wednesday 13 July 2011, Neil Jerram wrote: Hi Tom, Thanks for your answer... On 13 July 2011 10:01, Thomas White t...@bitwiz.org.uk wrote: acceleration pathways. A lot of the performance difficulties with the X pathway (not just on our hardware) seem to be because the server can't possibly know enough about what the client wants to accelerate it effectively. Fast and smooth graphics on the Freerunner should be perfectly possible, but would rely on exactly this kind of clairvoyance from the X server. So, getting Wayland to run on its own shouldn't be too difficult (famous last words..), but writing programs which can actually make use of it is significantly more difficult. I have read that some toolkits, like Gtk+ and Cairo, have (or are in the process of having) support for Wayland as their backend directly (i.e. not via X). Also that it's possible to write clients using a GL API directly, and that the library providing that API would use Wayland directly. Add Qt to that list. Meego may be using it, and kwin is being ported as the first stage in letting kde run on Wayland. Both of these may be a little heavy for the Glamo's GL capabilitites, but it shows writing applications for Wayland is getting much easier. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FreeRunner screen/case improvements (was: Shiftd)
On Friday 10 June 2011, Martix wrote: Speaking about screen I prefer AMOLED displays. Advantages: higher contrast on sunshine and generally less power consumption than backlit LCD, especially with GUI based on theme with white or colored text and icons on black background. AMOLED with red GUI on black background is also great for preservation of night vision, great for astronomers etc. Also price is low. I'd love a daylight readable screen, but in my experience AMOLED can't do it either. I haven't compared side by side though. I guess TFT is cheaper than AMOLED too, or ZTE wouldn't have switched screens for the later Blades. It's a pity PixelQi don't make small screens. Mirasol is getting interesting too now they've got an embedded frontlighting option. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner as a mobile gateway
On Tuesday 17 May 2011, Eric Smith wrote: Hi I am considering using the Freerunner as a mobile gateway to track GPS on a vehicle and to receive data from wireless sensors in the vehicle and send the sensor data and GPS data through GPRS. We may need to plug a customised wireless device into the freerunner usb. An external GSM and GPS antenna will be used. The device will have to run reliably and be robust for 8 to 12 weeks, so that means a customised battery. Power use efficiency means putting keeping the device in low-power consumption mode for most of the time and waking every 30 minutes (say) for polling and transmitting. Has anyone implemented such a solution or has ideas about feasibility? Nobody has talked about doing this IIRC, but it certainly sounds feasible. External power can be supplied via the usb y-cable arrangement, so shouldn't be a problem. atd-over-fso will let you wake from suspend to do what you want on an interval. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freerunner as a mobile gateway - shipping container
On Wednesday 18 May 2011, Eric Smith wrote: Thanks Al, Main application here is in a sea shipping container. Good luck getting a signal when they're stacked! I guess you can find somewhere to stick the antennae where they won't be too vulnerable and have a fair chance of getting a signal. The key issues are RF communication (when in a GSM range of course) and power management due to the long haul journey including journey overland. Power supply has to be in the form of an additional battery. Battery, efficient dc-dc converter, y-cable. Do some current measurements and size accordingly. Technical issue is to have minimal size OS and to be low in power consumption. And robust. OpenEmbedded, OpenWRT, debian would all work. Choice is probably more personal preference and familiarity than anything technical. FSO provides control via dbus for most stuff if you don't want to do the low level stuff yourself. Remember to turn the GSM and GPS off before suspending! All ideas welcome. Sounds like a bog standard monitoring job. Do you need something as powerful as the moko, or would an AVR do the job? Thanks On Tuesday 17 May 2011, Eric Smith wrote: Hi I am considering using the Freerunner as a mobile gateway to track GPS on a vehicle and to receive data from wireless sensors in the vehicle and send the sensor data and GPS data through GPRS. We may need to plug a customised wireless device into the freerunner usb. An external GSM and GPS antenna will be used. The device will have to run reliably and be robust for 8 to 12 weeks, so that means a customised battery. Power use efficiency means putting keeping the device in low-power consumption mode for most of the time and waking every 30 minutes (say) for polling and transmitting. Has anyone implemented such a solution or has ideas about feasibility? Nobody has talked about doing this IIRC, but it certainly sounds feasible. External power can be supplied via the usb y-cable arrangement, so shouldn't be a problem. atd-over-fso will let you wake from suspend to do what you want on an interval. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth keyboards
An alternative could be the one from the wiki: http://wiki.openmoko.org/wiki/Freedom_Slim_Keyboard But there is no mention of qtmoko support? The distro only has to serve the needed bt-tools, then everything will work. I recently bought the following one: http://cgi.ebay.it/ws/eBayISAPI.dll?ViewItemitem=260747301433ssPageName= STRK:MEWNX:IT which is quite cheep, small and light. It can pair with QtMoko but I can't use it for input. I tested it with the iphone of a colleague and, indeed, it works. Did you connecting to the keyboard manually after pairing? Depending on whether QtMoko is using bluez3 or bluez4 the method is slightly different, but both are in the wiki: http://wiki.openmoko.org/wiki/Manually_using_Bluetooth#HID_.28Human_Input_Device.29 If it works after manual connection then adding a GUI for it should be relatively simple. If it doesn't then some deeper investigation will be needed. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Have I fried my freerunner?
On Wednesday 09 March 2011, John O'Hagan wrote: On Fri, 4 Mar 2011, Chuck Norris wrote: 04.03.2011 06:27, John O'Hagan пишет: On Tue, 1 Mar 2011, Thomas HOCEDEZ wrote: On Tue, 1 Mar 2011 13:16:54 + John O'Hagan resea...@johnohagan.com wrote: Hi, After a couple of years of fairly trouble-free qtmoko-FR use, I used a cheap in-car charger on a recent trip. The charger died, and the FR itself began exhibiting a number of odd behaviours such as not coming back from suspend, indicating charging status when it was not charging, crashing, and after a couple of days, not booting into qtmoko at all. [snip] I needed to reflash both Qi and the rootfs to get a bootable phone, but to no avail: although the reflashing went fine, the FR will no longer charge, although the battery indicator showed charging status. Both my batteries are now dead. Looks like my poor FR took quite a beating from that cheap charger. Any advice how to diagnose/repair this? Since you're asking I assume you don't have much/any electronic diagnostic skill, and wouldn't find the schematics much use. If so, your best bet is probably to find someone with the right skills as you'll need someone skilful to do any repairs anyway. If you can recharge your batteries with a nokia or universal charger there is a functional test that can narrow down the problem a little. Schematics and component placement: http://downloads.openmoko.org/developer/schematics/GTA02/Schematics_Freerunner- GTA02_A5-A7cumulative_public_RC0.pdf http://downloads.openmoko.org/developer/schematics/GTA02/component- placement_by_lindi/ Opening the Freerunner is the same as the Neo1973: http://wiki.openmoko.org/wiki/Disassembling_Neo1973 The charge controller is under the same can as the capacitors for the bass fix: http://wiki.openmoko.org/wiki/GTA02_bass_fix The USB connector and protection is on page 7 of the schematics, and its connection to the power controller and battery is on page 4. If you're lucky one or more of the protective diode clamps has failed short circuit, and can be replaced relatively easily. If you're unlucky you have a power controller that is only partially working. Replacing that isn't an easy job even if you can get a spare part. If you have a working battery then you can try a battery swap to see if the power is getting to the power control chip. Boot the phone, plug in the charger, then remove the battery briefly as if you were changing batteries. If it keeps running than the power is reaching the power controller which is most likely partially broken. If it powers down then the problem might be in the protective bits before the power controller. Good luck! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: 2.5 vs 3.5 jack
On Wednesday 16 February 2011, David Lanzendörfer wrote: Hi list, Hello list-user :-) is anybody here from GTA04 developers? yes if it's not late, would be great to hear some case concerning 2.5 jack retention. That's only thing I found objectionable in the current tech. specification. is it possible to change it in final PCB version to 3.5 standard socket to make it compatible with most widespread headphones standard? Well, I'm plagued by the same issue. Here where I live, all connectors are Ø3.5mm while the FreeRunner has Ø2.5mm. I talked with Nikolaus about this topic already, and it's not that easy. The board wouldn't fit into the case anymore, so you would have need for a new one too... 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 best regards lev Sounds interesting! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Audio path gain, was: Re: Bluetooth module
On Sunday 23 January 2011, Hrabosh wrote: Al Johnson píše v Pá 21. 01. 2011 v 10:34 +: On Friday 21 January 2011, Hrabosh wrote: Hi guys, yesterday I opened my freerunner to check whether mine FR is affected by R3004 issue [1]. It was, I put a piece of wire there instead of those two caps and volume got better! I have also connected sine wave from generator to the WD8753 mic input and cheched it on the WD8753's output with the oscilloscope. It seemes that the audio codec chip gets into trouble (distortion, oscillations) if the overall audio path has higher gain than 1. I'm going to write more about this soon, with the scope pictures included (taken by my camera, I don't have DSO at home :-/ ) That would be interesting to see, but your summary seems wrong or perhaps oversimplified. Distortion is inevitable if you overload an amp, and oscillation isn't unusual immediately after overload. It isn't a function of the overall path gain though. The wolfson has a chain of amps and volume controls, and it only needs overload at one of them to introduce distortion. Stick the gain too high on the first stage (mic input) and the distortion won't go away no matter how far you turn down the gain on later stages. This has been a long standing problem with the default volume settings. Yes, it is oversimplified. It is obvious that you can't fix distortion by lowering the gain of next-in-chain amplifier. You are just controlling the volume of already distorted signal. If it was that obvious we wouldn't have had default settings guaranteed to cause distortion earlier than necessary in the first place. It seems it's only obvious to those of us with a grounding in analogue electronics, or those who spend time with guitar amps and similar. I put that picture from my scope with a short description to my web page, here: http://hnet.endofinternet.net/elektro/Freerunner/ALSA/sound_setting.html I was very surprised how LOW I had to set the audio controls to get rid of distortion: Mic2: 0 Sidetone: 1 Strange ... How did you pick 0.5mV as a suitable input amplitude? Measurement of peaks when talking? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: It's not a camera
On Friday 04 February 2011, Benjamin Deering wrote: http://jeepingben.homelinux.net/index.php?level=albumid=26 After attempting to use a bmp085 as a temperature sensor for my skiwax program (http://jeepingben.homelinux.net/wax/) and not getting good results (at least partially due to thermal leakage through the i2c wires), I added a mlx90614 to my freerunner. It is an infrared thermometer with a temperature range of -70C to 380C. It reacts quickly to changes in temperature and sort of fits in the freerunner case. Installation is similar to the Freerunner Navigation Board install. Christoph Mair has written a kernel module for it. The module is on gitorious, but is not yet available upstream. Nice work! There is a similar part called a mlx90615 which is much smaller, but also has a smaller temperature range. It may not work with the current kernel module, but could probably work with small changes. The temperature range is still -40C to 115C so probably good enough for many uses. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Bluetooth module
On Friday 21 January 2011, Hrabosh wrote: Hi guys, yesterday I opened my freerunner to check whether mine FR is affected by R3004 issue [1]. It was, I put a piece of wire there instead of those two caps and volume got better! I have also connected sine wave from generator to the WD8753 mic input and cheched it on the WD8753's output with the oscilloscope. It seemes that the audio codec chip gets into trouble (distortion, oscillations) if the overall audio path has higher gain than 1. I'm going to write more about this soon, with the scope pictures included (taken by my camera, I don't have DSO at home :-/ ) That would be interesting to see, but your summary seems wrong or perhaps oversimplified. Distortion is inevitable if you overload an amp, and oscillation isn't unusual immediately after overload. It isn't a function of the overall path gain though. The wolfson has a chain of amps and volume controls, and it only needs overload at one of them to introduce distortion. Stick the gain too high on the first stage (mic input) and the distortion won't go away no matter how far you turn down the gain on later stages. This has been a long standing problem with the default volume settings. But ... when I was dismounting the phone, I dammaged the bluetooth module. The module itself may be OK, but the flex cable is torn off. Don't you have any idea where can I buy some spare? I've not seen anyone list them as a spare for sale, but any of the distributors might have them available. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v31
On Monday 17 January 2011, giacomo 'giotti' mariani wrote: Hi! thank you for this new release! [...] - a message to confirm that an sms was sent; [...] greetings! Joif Hi, I think that SMS confirmation messages are a service offered by phone company (not for free). Moreover you can check in the draft folder in qtmoko messages application to see if your message has been put there as a consequence of a delivery problem. I understood this to be a request for a notification of the form message sent to GSM provider or couldn't send message so I stuck it in the pending queue/draft folder/wherever so that you don't have to check the draft folder each time to see whether the message actually made it to the network. On the other hand FSO supports a wide variety of message status returns if requested[1] so it could have been for a similar level of support. [1] http://git.freesmartphone.org/?p=specs.git;a=blob_plain;f=html/org.freesmartphone.GSM.SMS.html;hb=HEAD#SendTextMessage ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v31
On Thursday 13 January 2011, sferic wrote: Thank you for the hint!. I followed the references and boot v31 with Qi. For this I created the empty file 'noboot-GTA02' and put it to /boot in the partitions for debian and shr-u. This works just fine. But: After I use Debian on the 1st Partition and stopped it later and wanted to start again QtMoko, Qi came in kernel panic. There was the message, that mtdblocck6 can't be read (I don't remember the the exact content now). I suspect that wrong boot options had been created (in mtdblock6?) that do not match with the file system for UBIFS. I had to reflash QtMoko completly again (qi, kernel and filesystem). Currently I do not want to start my alternative distributions again because I fear the problem could occur again. Is there perhaps another way to reconstruct the right Qi boot options in this case than to reflash the freerunner? Qi boot options for NAND are compiled in, and can only be modified by flashing a modified Qi. I don't think debian would mess with your bootloader, and it shouldn't mess with the kernel in NAND if booted from iSD. It could be that debian was expecting to see something other than UBIFS on mtdblock6 and managed to mess it up. You probably wouldn't have had cause to check for errors in debian's boot messages though. If that is what's happened you should only need to reflash the rootfs, and the cure would be to tell debian about the UBIFS partition using a combination of extra boot parameters and /etc/fstab entries. I've not tried UBIFS yet, so don't ask me what they need to be, but /proc/cmdline in QtMoko should help. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The epoch is upon me.
On Tuesday 11 January 2011, Davide Scaini wrote: i'm experiencing the same problem: clock is stuck during suspend and it takes some time to update correctly when resumed. This has the side effect to make ffalarms useless ... any hint is welcome d More details please. The rtc is meant to be powered by the main battery during suspend, so the backup battery shouldn't have any effect, hence the belief that it's a software bug. ffalarms (via fso) is supposed to set the rtc to generate an interrupt to wake the phone at the specified time if necessary. It is possible the rtc isn't being set, or that ffalarms isn't being called on wake among other things. Does the phone wake but not sound the alarm? If you wake the phone and immediately run 'date' in the terminal do you see the correct time, or the time when the phone suspended? On 12/22/10, Al Johnson openm...@mazikeen.demon.co.uk wrote: On Tuesday 21 December 2010, Rui Miguel Silva Seabra wrote: Em 21-12-2010 12:55, Gay, John (GE Energy Services, Non-GE) escreveu: The last time my FreeRunner's battery died, the clock reset to epoch. Now, it no longer keeps time during suspend either. I'm guessing this means the clock battery has finally died. Someone recently commented that they replaced their battery with a pair of super caps. I just wanted to confirm my diagnosis before I take a soldering iron to my phone. Cheers, John Gay So that's why my clock...? a) goes back to 2000 without a battery Probably b) takes so long to update the clock in the toolbar and idle screen of SHR Unlikely - even in suspend the rtc is powered from the main battery, not the backup. The lack of update is most likely a software bug not a hardware problem. Damn, any instructions on how to do this properly? Just the post to the list. ___ 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: [ANN]: GTA04 (Beagleboard inspired Openmoko Upgrade) - Early Adpoter Program
On Thursday 23 December 2010, W. B. Kranendonk wrote: --- On Wed, 12/22/10, Alfa21 freerun...@my.is.it wrote: 2010-12...@14:21 W. B. Kranendonk That reminds me... The BeagleBoard can provide up to 1280*1024 or 1280*720 if I recall correctly. Do we have options to channel that power out of the box? Nikolaus why not?? If all we need is a piece of copper (w/o logic inside) cable... today we have many tv-set with hdmi, dvi, vga ports all around us! we could go in any hotel and use that tv-screen and feel like at home with our mobile computing! I am aware of the screens all around us, the point seems to me getting the wire out of the box. Could it be redirected to the USB-paths, so that the USB-connector became a DVI-disguised-as-USB? It doesn't have the amount of wires needed, so the available wires had to be multiplexed. In the USB-to-DVI/HDMI/WE(whatever)-converter the signals have to be demuxt again. USB connector won't handle the bandwidth required by raw DVI/HDMI. You could use a DisplayLink USB to HDMI adapter like the AlwaysInnovating DualScreen if USB host mode is available. Since the board is using the OTG connector instead of the mini-B there's a fair chance of a usable host mode, but wait for confirmation. Would the cameraconnector (the extra connection to the back of the phone) allow for this kind of signalling? I very much doubt it... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: The epoch is upon me.
On Tuesday 21 December 2010, Rui Miguel Silva Seabra wrote: Em 21-12-2010 12:55, Gay, John (GE Energy Services, Non-GE) escreveu: The last time my FreeRunner's battery died, the clock reset to epoch. Now, it no longer keeps time during suspend either. I'm guessing this means the clock battery has finally died. Someone recently commented that they replaced their battery with a pair of super caps. I just wanted to confirm my diagnosis before I take a soldering iron to my phone. Cheers, John Gay So that's why my clock...? a) goes back to 2000 without a battery Probably b) takes so long to update the clock in the toolbar and idle screen of SHR Unlikely - even in suspend the rtc is powered from the main battery, not the backup. The lack of update is most likely a software bug not a hardware problem. Damn, any instructions on how to do this properly? Just the post to the list. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian] 2.6.34 Openmoko kernel package available
On Friday 17 December 2010, Timo Jyrinki wrote: 2010/12/16 Neil Jerram neiljer...@gmail.com: Even after removing the /dev/input files as you suggested (in /etc/rc.local), my observation is that XOrg still eats all CPU after an initial boot-up, but that if I then do /etc/init.d/nodm stop and /etc/init.d/nodm start, it returns to using a normal (small) amount of CPU. Is that as you would expect? That doesn't happen to me, but it's probably related to starting X in parallel with rc.local, so X gets to probe those before they are removed? Anyway, if one can come up with a perfect xorg.conf that disables the extra devices there and only configures glamo + touch input + hw buttons, that'd be nice. What about USB and Bluetooth input devices? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: No plans for fennec on the FR
On Friday 03 December 2010, Thomas Gstädtner wrote: On Fri, Dec 3, 2010 at 13:17, Timo Jyrinki timo.jyri...@gmail.com wrote: 2010/12/3 Delian deli...@gmail.com: Seems there's no hope of seeing a native FR version of fennec right now. [0] Well, we already have nice browsers so, it's not a real big problem (IMHO). :P [0] https://bugzilla.mozilla.org/show_bug.cgi?id=450929#c4 Well, Mozilla is not very famous of having much interest themselves in building end-user binaries for Linux platforms. Distributions do that for them, and similarly if Fennec will get mature at some point to the point it's feasible to package it into distributions, we'll get them through distributions that support FreeRunner's ARMv4, like Debian. Please read the comments in the bug report. The issue is not the lack of builds for armv4, the issue is that the code seems to have armv4 incompatible assembly code, so you can't just build it for armv4. Anyway, I don't think mozilla would object to a 3rd party patch that implements said code (if it indeed exists, haven't looked into it yet) in a reasonable way for armv4 aditionally. Otherwise distributions could patch their sources to provide a package if someone comes up with that patch. I doubt they'd accept a patch. Support for old ARM architectures was actively dropped because it was causing a lot of problems while giving support for only a few extra devices, and even then those devices were too slow to get decent performance out of fennec. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Interesting new 'Open' Hardware how do I build shr for it?
On Wednesday 01 December 2010, Gennady Kupava wrote: В Пнд, 29/11/2010 в 01:24 -0800, c_c пишет: Hi, I was looking at arowboat.org - which is a project at getting Android working on all TI OMAP series boards and I saw a link to opensourcemid.org. Apparently, Embest (who also make the DevKit 8000 - a beagle board like board) have made a 7 MID with GPS, camera, mini PCIe (they have a WCDMA module), WiFi and bluetooth running on OMAP 3530. I ordered a device and I find that :- 1. It's built quite well 2. It's responsive and fast (running android 2.1 as of now) 3. The hardware schematics are available online 4. The source code for kernel 2.6.29, x-loader and u-boot are also available online 5. It has a lot of space between the board and the casing - I'm thinking mods like the Freerunner Navigation board 6. The company seems responsive enough I'm now looking at getting a custom kernel (something newer) running on it. Also, I was aondering how do I get SHR ported onto such a device? I have the entire openembedded based SHR build system (something I've been using to build stuff for the FreeRunner) with me - but I'm not sure how to go about changing the target system. Hi, c_c! Thank you for link. Specifications ( http://www.armkits.com/product/k7.asp ) are not really promising fast speeds: it is only 600Mhz cpu, and 'up to' 256 Mb sdram volume is not really good for long term usage. Nothing told about graphic card, so i guess CPU managing LCD, that should eat cpu resources too. So, only caches size, memory type (unspecified) are different from FR. You'll find a more complete spec at opensourcemid.org. Spec is very similar to the beagleboard and n900 - same CPU, same RAM. The CPU has PowerVR SGX530 onboard so I'd be very surprised if it wasn't available for use as it is on the beagleboard, although the accelerated driver is closed. According to same page critical parts are missing from android like power management, bluetooth, usb device support, and mic(!) and device is mostly oriented to WinCE (notice also .asp in web address), this sounds too bad for anyone who want open device, or hackable device with linux on board at all. It may not all be working out of the box, but having the schematics is better than most of the alternatives. Regards, Gennady. ___ 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: qtmoko.org?
On Thursday 25 November 2010, Radek Polak wrote: On Thursday 25 November 2010 16:47:42 Ole Carlsen wrote: It seems like someone has broken qtmoko.org pages. Anyone aware of what is going on?? The status devel page got broken, so i banned the user and it's now ok. FAQ page is also messed up, and probably more. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [e-users] Someone is trying to patent Quickwriting
On Tuesday 23 November 2010, Daniele Ricci wrote: Hello Carsten, thanks for your reply. On Tue, Nov 23, 2010 at 08:02, Carsten Haitzler ras...@rasterman.com wrote: themselves. they are forgeable. if you have an overwhelming set of such data from multiple sources and witness statements with signatures on actual paper, then you have something beginning to be believable. What kind of proof do I exactly need? I mean, all I have is prof. Perlin Quickwriting page: http://www.mrl.nyu.edu/projects/quikwriting/ We also have some implementations of that, such as the Pocket PC one and the Linux one (QWO), but i don't know what else I may need nor where to find it :-( Ideally you want something in print with a verifiable publication date. A printed copy of UIST '98 - Proceedings of the 11th annual ACM Symposium on User Interface Software and Technology [1] might be available through university libraries if you can't get it direct from ACM. I don't know whether the 'Wired' article [2] made it into the print edition, but that's another one to check. [1] http://www.acm.org/uist/archive/html/proceedings/1998.html [2] http://www.wired.com/science/discoveries/news/1999/04/19411 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Someone is trying to patent Quickwriting
On Tuesday 16 November 2010, Daniele Ricci wrote: Cross-posting for broadcasting Justus idea. [snip...] On Tue, Nov 16, 2010 at 00:00, Justus Winter Would anybody care to join me on this one? We could create a message or a message template and ask everyone send this message to the person behind the 8pen (crowdsourcing seems to be the catchy phrase for this approach...). Cheers, Justus Sure, i'm with you 110% :-) Has anyone contacted Ken Perlin or NYU about this yet? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: MeeGo 1.1 for FreeRunner?
On Tuesday 16 November 2010, Gay, John (GE Energy Services, Non-GE) wrote: Does anyone know how difficult it would be to port MeeGo to the FreeRunner? After all, we don't have enough distro's yet (-= http://wiki.meego.com/MeeGo_Porting_Guide All looks rosy until you get to the bit about requiring the Khronos graphics APIs. If you look at the draft spec you'll see they don't currently support our old ARM architecture, and I guess they're unlikely to add it. Then again they haven't defined the requirements for the handset profile yet. I could be being overly negative though, so feel free to ask over on the meego-porting list mentioned in the guide. We already have bootloader, kernel and drivers, and working X. We already use connman, and iirc someone added Calypso support to ofono for the FR already. If it wasn't for the graphics it should be a 'simple' matter of writing the required configs and setting the build system going ;-) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: WM8753 Speaker Playback ZC Switch
On Friday 12 November 2010, Ed Kapitein wrote:
Hi All,
I am happily hacking on my FR and was toying with the wolfson.
I happen to notice that in order to get any sound from the earpiece i
had to switch on the Speaker Playback ZC Switch.
That switch is mentioned in the statefile, but i can't find it in any of
the diagrams on [1] [2]
The one in the wiki is just an annotation of the Wolfson diagram, adding alsa
control numbers to the visible elements where I could identify them. I think
there were some elements I couldn't identify a control number for, and there
are a lot of controls that have no representative element in the diagram,
usually because they involve digital processing rather than an identifiable
analogue element. If you find a mistake or something to add then please make
the correction.
Is there someone with an updated version of the diagrams, that includes
the two switches below?
control.9 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Headphone Playback ZC Switch'
value.0 false
value.1 false
}
control.10 {
comment.access 'read write'
comment.type BOOLEAN
comment.count 2
iface MIXER
name 'Speaker Playback ZC Switch'
value.0 true
value.1 true
}
Kind regards,
Ed
[1] http://wiki.openmoko.org/wiki/Neo1973_Audio_Subsystem
[2] http://www.wolfsonmicro.com/products/audio_hubs/WM8753/
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: Address the WM8753 directly
On Thursday 11 November 2010, Ed Kapitein wrote: On Wed, 2010-11-10 at 12:57 -0800, W. B. Kranendonk wrote: --- On Wed, 11/10/10, Al Johnson openm...@mazikeen.demon.co.uk wrote: From: Al Johnson openm...@mazikeen.demon.co.uk The ultimate goal is to make a FR to FR modem conection, using the GSM voice band. Why? Is this just to see whether it's possible, or how bad the voice channel is as a data connection when compared to the data channel? I can imagine using such a solution on a flatfee subscribtion that does not include data traffic. Just don't tell me you want to use the resulting connection for VoIP :-P Boudewijn ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community Hi all, Yes, i would like to see if it is possible and refresh my C programming skills. As good a reason as any :-) It is indeed a flat fee voice subscription, data would cost extra. VOIP is not what i had in mind ;-) You've probably checked this, but just in case...On many subscriptions GSM data calls are treated the same as voice calls, not like GPRS or 3G data connections. It's like using an analogue or ISDN modem, circuit switched to a phone number just like a voice call, but carrying arbitrary data rather than encoded voice. But i think i can use it to send GPS data from one FR to another. Or use it for a commandline connection. That sounds plausible, going back to ancient bit rates. Good luck - you'll be an expert in the workings of voice codecs by the end of this! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Address the WM8753 directly
On Monday 08 November 2010, Ed Kapitein wrote: Hi All, I want to hack a bit on the Wolfson sound chip. The ultimate goal is to make a FR to FR modem conection, using the GSM voice band. Why? Is this just to see whether it's possible, or how bad the voice channel is as a data connection when compared to the data channel? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Where can I buy a replacement LCD screen for a Neo?
On Saturday 06 November 2010, Ori Pessach wrote: The title pretty much sums it up. My screen cracked, seemingly unprovoked. Just do a search on the part number TD028TTEC1 to find a number of suppliers at a wide range of prices. Ebay has them between $16 and $91. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Always Innovating
On Wednesday 03 November 2010, Thomas HOCEDEZ wrote: On 02/11/2010 16:44, Al Johnson wrote: On Tuesday 02 November 2010, Thomas HOCEDEZ wrote: Le 01/11/2010 12:40, Al Johnson a écrit : On Monday 01 November 2010, Chuck Norris wrote: 01.11.2010 16:41, Ed Kapitein пишет: Hi All, A while ago there was intrest in the MID of always inovating. They seem to be shipping the devices as of today. [1] So get them while they'r fresh ;-) Kind regards, Ed [1] https://www.alwaysinnovating.com/store/home.php Did they add GSM/3G ? or something other features? In that timeframe? You've got to be joking! You're not kidding so much : the founder of A.I. just asked me today if I had finished the design of the plugin I want to build for the Minibook ! I have to work hard tonight ! It's good to know they're interested. What are you putting in the module? Are you using the public info about the 40pin connector, or do you have more to go on? The main idea I had was to plug everything through the 40pin connector. All the stuff will be contained in a case in parallel of the MiniMoko one. (a kind of 'slice' if you want). They wanted us to design the schema of what should be included the connections. For my part, I started with - 1 usb hub | free miniusb connector (to connect the outside world) | 3G usb key (some of them are working out of the box, got to find which) Also check they're capable of voice calls - not all of them are. Aren't they going to be too big and power hungry though? It wasn't clear to me whether the minibook had mic and earpiece suitable for phone use either. 3G modules would be smaller - check out telit and the one identified for gta04. I don't know how they connect though. | GPS USB dongle (no idea of which one for now) The ones I've seen are probably too big. you could just connect a gps chip to the serial port, and get AI to help with getting the impedance right for the antenna trace. Sparkfun have a selection of gps chips and antennae, including a tiny chip antenna that might be good enough. Remember to stick the antenna somewhere it can see the sky! \ Internal USB Port - Powering capabilities (through USB / extra battery?) There will be a problem in what size all this stuff will be, and as the MiniBook is 0.9cm wide, I don't want to make a hufghr sandwich ! Nothing for gyro or compass? The circuit from the nav board v2 should connect directly to the 40 pin connector to provide these. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Always Innovating
On Tuesday 02 November 2010, Thomas HOCEDEZ wrote: Le 01/11/2010 12:40, Al Johnson a écrit : On Monday 01 November 2010, Chuck Norris wrote: 01.11.2010 16:41, Ed Kapitein пишет: Hi All, A while ago there was intrest in the MID of always inovating. They seem to be shipping the devices as of today. [1] So get them while they'r fresh ;-) Kind regards, Ed [1] https://www.alwaysinnovating.com/store/home.php Did they add GSM/3G ? or something other features? In that timeframe? You've got to be joking! You're not kidding so much : the founder of A.I. just asked me today if I had finished the design of the plugin I want to build for the Minibook ! I have to work hard tonight ! It's good to know they're interested. What are you putting in the module? Are you using the public info about the 40pin connector, or do you have more to go on? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Always Innovating
On Monday 01 November 2010, Chuck Norris wrote: 01.11.2010 16:41, Ed Kapitein пишет: Hi All, A while ago there was intrest in the MID of always inovating. They seem to be shipping the devices as of today. [1] So get them while they'r fresh ;-) Kind regards, Ed [1] https://www.alwaysinnovating.com/store/home.php Did they add GSM/3G ? or something other features? In that timeframe? You've got to be joking! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Anyone still have the case CAD files?
On Thursday 28 October 2010, David Lanzendörfer wrote: Try FreeCAD Its also able to open this format. The freecad ebuild in the gentoo science overlay has an unresolvable dependency at the moment. Is it significantly better than brl-cad? I'll answer this one myself. FreeCAD does a much better job on importing both STEP and IGES than brl-cad. It's possible I've missed just the right combination of switches on one of the brl-cad imports, but with freecad it just works. I may need to find some more memory though - 1G isn't really enough to handle the biggest files with either of them. The freecad gui is also significantly more modern. Whether that makes it more productive is an open question, but it's certainly quicker for looking at models. I'm using gentoo too. Seems the install paths do not fit together well, but with (temporary) hack on line 5 of following steps you can make it build. I'm using KDE4.5.2 autounmask sci-misc/freecad-0.9.2646 emerge =media-libs/coin-3.1.3-r1 emerge =media-libs/SoQt-1.5.0-r1 emerge =sci-libs/opencascade-6.3-r1 sudo ln -s /usr/include/coin/Inventor/ /usr/include/ emerge =sci-misc/freecad-0.9.2646 I'm surprised that works - freecad-0.9.2646 has a dependency on =media- libs/coin-3.1.2 unless you also modified the ebuild. I ended up using the ebuild for 0.10.3025 attached to this bug, and it's working fine now. https://bugs.gentoo.org/show_bug.cgi?id=312063 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Openmoko on Wikipedia
On Friday 29 October 2010, Denis 'GNUtoo' Carikli wrote: On Thu, 2010-10-28 at 10:27 +0200, Eric Ehlers wrote: Hello, I added a new section (2.5) to the Openmoko page on wikipedia in an attempt to reflect the latest status of the project: http://en.wikipedia.org/wiki/Openmoko I also think that the history is a bit short, but I don't know enough to complete it. For instance, I think it was the first commercial free phone. but I don't know when exactly the gta01 and gta02 were commercialized. That should be in the list archives. GTA02 was released start of July 2008, but I don't remember the exact date. I also wonder if it's the first commercial phone(or not) that permitted the installation of native applications(I wonder if the app store for the iphone came before or after the openmoko) It missed that one by a long way. WinCE/WinMo handsets had native applications from the start. They were possible with Symbian too, but less common. It would be nice to have more info, because else it would be forgetten... Denis. ___ 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: Anyone still have the case CAD files?
On Thursday 28 October 2010, David Lanzendörfer wrote: Try FreeCAD Its also able to open this format. The freecad ebuild in the gentoo science overlay has an unresolvable dependency at the moment. Is it significantly better than brl-cad? If you convert it to stl, you can print it with a RepRap. brl-cad can export to stl too. Mine will soon be done *yeeha* Good luck! best regards leviathan ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GTA04] When is the next and more powerful openmoko releasing
On Wednesday 27 October 2010, Radek Polak wrote: Another idea - i wonder if i could make the case of wood. That would be very environment friendly and wood is also good material. But that's just idea. Laser cutting works with wood, though you do get slightly charred edges. Milling works well with a lot of hardwoods. There might be some design features that depend on material properties, so you might need some modifications for a wood case, but it's certainly worth a try. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GTA04] When is the next and more powerful openmoko releasing
On Tuesday 26 October 2010, Dr. H. Nikolaus Schaller wrote: Am 26.10.2010 um 10:58 schrieb Patryk Benderz: [cut] To say more of the price, it is necessary to have the design available. This question you asked Boudewijn, is very important. Nikolaus, do you have some design available for preview? If so, I could also make a research in Poland, how much would it cost? http://wiki.openmoko.org/wiki/CAD_models This is what I use for asking for quotes (the Neo 1973 case separated into the important parts): http://download.goldelico.com/ombeagle/images/Neo1973.step.zip BTW: I just come back from another plastics manufacturing company. They can produce a case by milling and glueing plastic plates. It would come to approx. 50 EUR. But is much larger (wall thickness 10 mm, slice thickness 3mm) and needs modifications to the whole construction. Personaly I would dislike this as a Smartphone (compared to a Nokia/Palm/HTC/Apple/Samsung) and we won't get many friends... 10mm?! Friends were doing better than that when I was at school! And I discussed with them about laser cutting. Their opinion: can be used only for engraving into acrylic parts and cutting a general shape. But not for fine grained cuts. The laser burns the plastics until the color changes. That runs counter to representations I've seen from multiple manufacturers. Here's a counterexample: http://www.cut-tec.co.uk/laser%20cut%20plastic.html Discolouration is a problem with polycarbonate, but many others seem to be fine. I guess there's only one way to find out for sure, and the case of my PJB100 is starting to fall apart. I'll let you know how I get on, and whether it ends up looking acceptable. How many new cases would you and your friends buy if it costs: * 20 EUR * 50 EUR * 100 EUR * 200 EUR I need at most 2 phones, and wouldn't recommend this style of phone to most of my friends. As for cost, it really depends on the case and what's going in it. I'd probably think twice about 200 EUR unless it was something special though! ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GTA04] When is the next and more powerful openmoko releasing
On Saturday 23 October 2010, David Arnold wrote: On 23/10/2010, at 9:40 AM, Al Johnson wrote: high quality design doesn't have to be expensive to manufacture. I suspect something attractive could be made in low volume at a reasonable price using laser cut plastics. I'll try to ask the local cutters about their precision and cut thickness in different materials. This is a totally un-researched idea, but ... What about a machined aluminium case? Nice faraday cage you've got there ;-) Machined plastic would be easier for RF and almost as nice. I would guess that rental of a CNC machine would not cost too much, and perhaps we could make an arrangement with a technical college or even commercial firm to use their equipment in otherwise idle times? Unless you know someone in the firm who's willing to do something unofficial you'd have to be very lucky to get a company to do that. Either they'll be set up for big runs, in which case they won't want to change anything, or they'll be charging people for small runs exactly like ours. CNC has non-trivial setup costs for programming the tool path, and possibly for tooling to hold the workpiece. A college is much more likely to accept the idea, and might even accept case design as a student project. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GTA04] When is the next and more powerful openmoko releasing
On Saturday 23 October 2010, Dr. H. Nikolaus Schaller wrote: Am 23.10.2010 um 15:40 schrieb Al Johnson: On Friday 22 October 2010, Dr. H. Nikolaus Schaller wrote: Am 22.10.2010 um 02:17 schrieb Al Johnson: On Friday 22 October 2010, EdorFaus wrote: On 10/21/2010 07:59 PM, Alfa21 wrote: you should try 3d print like this: snip made in ABS which is a good plastic and up to 0.01 inches resolution Unfortunately, that's not quite good enough (different units). 0.01 inches = 0.254 mm, which is 2.54 times the required size: On 10/21/2010 07:32 PM, Dr. H. Nikolaus Schaller wrote: the required precision (0.1 mm, 0.5 mm wall thickness, etc.) 0.1 mm is approximately 0.0039 inches. I have a question, though - is this precision required for making *any* well-working case design (due to the electronics etc.), or is it just for making more of the current case design? If it's the latter, it would be possible to create a new case design that would be easier to get manufactured... The electronics don't need much precision in the case design. Cases that clip together firmly and securely do need precision though, and that's true of the current design. An alternative design needing less precision is possible, especially if we accept things being screwed together. Generally yes. If we sacrifice quality, ergonomics, and size, we can find simpler and less expensive case constructions. I'm sure we can find alternative case construction methods that don't sacrifice much in any of those departments. They just won't be methods used in the mass market because they don't scale up to those production volumes, just as their methods don't scale down to ours. The pcb might need some design Well, we have anlysed approx. 5 or 6 different methods and none was inexpensive for low volumes. The only one that came down below 50 EUR per case is injection moulding. But I would be happy if you can guide the GTA04 to a different approach. It would be good if you could share the results of your research so other open hardware projects can get an idea of what a custom case might cost, and see how different manufacturing methods compare. It might also stop us suggesting things you've already investigated an rejected! Also exactly how low is low volume? Given the differences in setup costs for different manufacturing methods it could make a huge difference to the unit cost. elements suited to a different method of mounting than the current 'clip it into the injection moulding' variety, but this is for future generations not the current pcb. Well, the current board is really mounted by 2 torx screws and the connectors which fit into holes on the sides. The hooks and clips are not really necessary, which allows for a lot of simplifications. This is where some of us are currently working on to get the plastics produceable by a RepRap. I'll have to open my FR again to refresh my memory. I remember the GSM antenna connection being somewhat integral with the case assembly, but it would be nice to be mistaken! One aspect to keep in mind for precision are the push-buttons (AUX and Power). The buttons [1] are specified for a Travel 0.3 mm +0.1 –0.2 mm. I.e. if we don't want that the buttons get stuck we come to this 0.1mm precision. We have experienced the same with the PCB design where the position of the buttons must be within these 0.1mm... That doesn't mean the case needs that tolerance though. It just means the end of the actuator needs to stick over the edge of the pcb by the right amount to be operable. The external button can be lightly spring to take up the tolerance, or rest slightly clear of the button actuator. Alternative switch If I understand correctly, then the button would not fit smoothly into the case. It may stand out (or in) so it either gets trapped in the gauze of your trouser pockets, or you need long fingernails to press it. If designed to rest slightly clear of the pcb button it would sit where designed. If lightly sprung it would sit slightly further in. A tapered case edge, as we have with the current power button, makes this less disruptive as well as easier to find by touch. Even with a 0.5mm recess, which I doubt we would need, a button the size of the current aux button wouldn't need fingernails to press. types are an option for future designs, including a change to capacitive sensors as provided for by the v2 nav board. Not completely. The power button must be a mechanical button to wake up the processor from deep sleep. Or we drain the battery for a always-powered sensor chip. And, I am not sure if a sensor contact is safe enough for a smartphone in a pocket. The MPR121 on the nav board is supposed to draw 29uA for a 16ms sample period, less if we can stretch it out further. That gives a nominal battery life greater than 4 years, so battery drain shouldn't
Re: [GTA04] When is the next and more powerful openmoko releasing
On Monday 25 October 2010, Dr. H. Nikolaus Schaller wrote: Well, we have anlysed approx. 5 or 6 different methods and none was inexpensive for low volumes. The only one that came down below 50 EUR per case is injection moulding. But I would be happy if you can guide the GTA04 to a different approach. It would be good if you could share the results of your research so other open hardware projects can get an idea of what a custom case might cost, and see how different manufacturing methods compare. It might also stop us suggesting things you've already investigated an rejected! Also exactly how low is low volume? Given the differences in setup costs for different manufacturing methods it could make a huge difference to the unit cost. All methods have setup cost (once) and cost per unit. Some methods have to repeat setup cost avery n units (e.g. silicon moulds made from Stereolitography). Our results so far (I can't share all of them): STL + Silicone moulds: 2000 EUR setup + 50 EUR each every 100 units Injection Moulds: 25000 EUR setup + 20 EUR per unit 3D-Printing: no setup, 400 EUR every unit (quality doubtful) Milling from ABS block: no setup, 500 EUR every unit So 1-10 units does not come below 250 EUR. 100 units may come to 70 EUR. 1000 units to 45 EUR. 10k to 22.50 EUR. You see the volume effect and clear preference of injection moulds. Which also give best quality... All these are lower estimates on industrial (not hobbyist) quality and based on 3D CAD files from Openmoko and does not include control of the process (someone must spend time to initiate and keep it running). Experience shows that real project cost is twice as high as the estimate... Thanks. I'm surprised milling comes with no setup cost. Automated tool paths must have come on somewhat since I last looked, but that was probably longer ago than it seems. Laser cutting was not yet amongst the production methods. Please try to get an estimate for setup cost (e.g. converting CAD data) and unit cost (material plus machine operation time). Laser cutting isn't suitable for making the existing case design, so converting the cad data wouldn't be an issue. This would be a new design tailored to the production method. It's a fast and accurate way to cut shapes from (usually) sheet materials. Edge quality is good with the right materials, including ABS and especially acrylic. Setup costs are low to zero, particularly if you can supply a DXF with the outlines already offset for the cut width and set out on the sheet. You can get a rough idea of the capabilities at: http://www.pololu.com/docs/0J24/4 Prices from that site for one offs are low enough to be worth further investigation, at least for small numbers of cases. It may be time to try prototyping some ideas in cardboard... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GTA04] When is the next and more powerful openmoko releasing
On Friday 22 October 2010, Dr. H. Nikolaus Schaller wrote: Am 22.10.2010 um 02:17 schrieb Al Johnson: On Friday 22 October 2010, EdorFaus wrote: On 10/21/2010 07:59 PM, Alfa21 wrote: you should try 3d print like this: snip made in ABS which is a good plastic and up to 0.01 inches resolution Unfortunately, that's not quite good enough (different units). 0.01 inches = 0.254 mm, which is 2.54 times the required size: On 10/21/2010 07:32 PM, Dr. H. Nikolaus Schaller wrote: the required precision (0.1 mm, 0.5 mm wall thickness, etc.) 0.1 mm is approximately 0.0039 inches. I have a question, though - is this precision required for making *any* well-working case design (due to the electronics etc.), or is it just for making more of the current case design? If it's the latter, it would be possible to create a new case design that would be easier to get manufactured... The electronics don't need much precision in the case design. Cases that clip together firmly and securely do need precision though, and that's true of the current design. An alternative design needing less precision is possible, especially if we accept things being screwed together. Generally yes. If we sacrifice quality, ergonomics, and size, we can find simpler and less expensive case constructions. I'm sure we can find alternative case construction methods that don't sacrifice much in any of those departments. They just won't be methods used in the mass market because they don't scale up to those production volumes, just as their methods don't scale down to ours. The pcb might need some design elements suited to a different method of mounting than the current 'clip it into the injection moulding' variety, but this is for future generations not the current pcb. One aspect to keep in mind for precision are the push-buttons (AUX and Power). The buttons [1] are specified for a Travel 0.3 mm +0.1 –0.2 mm. I.e. if we don't want that the buttons get stuck we come to this 0.1mm precision. We have experienced the same with the PCB design where the position of the buttons must be within these 0.1mm... That doesn't mean the case needs that tolerance though. It just means the end of the actuator needs to stick over the edge of the pcb by the right amount to be operable. The external button can be lightly spring to take up the tolerance, or rest slightly clear of the button actuator. Alternative switch types are an option for future designs, including a change to capacitive sensors as provided for by the v2 nav board. The same is with mounting the display. If that is not precise enough, touch operation will be deteriorated. Can you elaborate? There may be ways around this one too. So if we reduce precision of the case production process, the buttons become larger and finally, the phone is more a brick than a handheld phone :) Personally, I am in favour of high-end high-quality design (like the iPhone) even if it costs money. But it should never cost freedom and independence... high quality design doesn't have to be expensive to manufacture. I suspect something attractive could be made in low volume at a reasonable price using laser cut plastics. I'll try to ask the local cutters about their precision and cut thickness in different materials. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: I2C fm/am radio
On Saturday 23 October 2010, giacomo mariani wrote: Hello everyone, I'm willin if such a component exists and is suitable for our mobile... Does some of you have any experience, hint or idea? There doesn't seem to be a shortage of suitable chips. The problem will be integrating it into the existing design. There's a spare line input on the Wolfson chip I think, but you'll have to check whether they're accessible. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GTA04] When is the next and more powerful openmoko releasing
On Thursday 21 October 2010, Andreas Fischer wrote: Hi, One question: Do you only consider upgrades of existing Freerunners or would a complete phone also be an option? My (probably naive) impression is that you're only missing the case plastics to provide a complete GTA4 phone. Most of the parts are here: http://www.handheld- linux.com/wiki.php?page=Accessoriesreferer=Neo%20Freerunner Not sure if the button plastics are included in the middle part or not. Not sure about the vibrator either, but everything else looks to be available, at least in limited quantities. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GTA04] When is the next and more powerful openmoko releasing
On Thursday 21 October 2010, W. B. Kranendonk wrote: The LCD comes in handy at times, was my first thought... True, but they're available from many more suppliers than moko plastics! Shame there isn't a transreflective version though... ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [GTA04] When is the next and more powerful openmoko releasing
On Friday 22 October 2010, EdorFaus wrote: On 10/21/2010 07:59 PM, Alfa21 wrote: you should try 3d print like this: snip made in ABS which is a good plastic and up to 0.01 inches resolution Unfortunately, that's not quite good enough (different units). 0.01 inches = 0.254 mm, which is 2.54 times the required size: On 10/21/2010 07:32 PM, Dr. H. Nikolaus Schaller wrote: the required precision (0.1 mm, 0.5 mm wall thickness, etc.) 0.1 mm is approximately 0.0039 inches. I have a question, though - is this precision required for making *any* well-working case design (due to the electronics etc.), or is it just for making more of the current case design? If it's the latter, it would be possible to create a new case design that would be easier to get manufactured... The electronics don't need much precision in the case design. Cases that clip together firmly and securely do need precision though, and that's true of the current design. An alternative design needing less precision is possible, especially if we accept things being screwed together. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Debian] 2.6.34 Openmoko kernel package available
thanks for the package. to ssh in the device i must add 'g_ether' in /etc/modules. you should builtin this module in kernel. That's fine for you, but not for anyone who wants to use one of the other gadget modules. If you need it autoloading then autoload it as you are doing now. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: soldering tutorial, was: Re: [Shr-User] uSD hosed, on every unstable.
On Friday 15 October 2010, Alfa21 wrote: 2010-10...@15:58 jeremy jozwik yah thats what i was wondering, frying components. but it is surely a common technique, this is the first ive seen with a hot plate. most use a hot air gun. hot air is used to unsolder components for replacement. hot plate imho is fake More coverage of various techniques here, including details of the hotplate method. It's the wrong method for reattaching a USB connector and a resistor. http://www.sparkfun.com/commerce/tutorial_info.php?tutorials_id=59 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] uSD hosed, on every unstable.
On Wednesday 13 October 2010, jeremy jozwik wrote: for those who care: today, for some reason, i decided to tear down my freerunner. when i got the PCB board out i took a moment to look at the sd card reader. i noticed of the 4 little black squares just next to the sd card reader, only 3 of them seemed to be there. im thinking i must have popped one off while trying to remove the micro sd card some time along the way. Judging by your photo and the component placement doc that would be R7507 which according to the schematic is 75R, and connects the SD_DATA0 pin on the connector to the chip. That certainly explains why your SD won't work! since it seems like a simple fix, im wondering if the capacitor lister in [1] is the same as the 4 lined up between the sd reader and the battery connector. No - the 4 components are resistors not capacitors. The capacitor fix hasn't been needed since the full kernel fix that correctly implemented the Glamo's SD drive strength adjustment. i have taken images and will upload them. but i wanted to put this out first. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Shr-User] uSD hosed, on every unstable.
On Wednesday 13 October 2010, jeremy jozwik wrote: On Wed, Oct 13, 2010 at 6:22 AM, Al Johnson openm...@mazikeen.demon.co.uk wrote: Judging by your photo and the component placement doc that would be R7507 which according to the schematic is 75R, and connects the SD_DATA0 pin on the connector to the chip. That certainly explains why your SD won't work! No - the 4 components are resistors not capacitors. The capacitor fix hasn't been needed since the full kernel fix that correctly implemented the Glamo's SD drive strength adjustment. i have taken images and will upload them. but i wanted to put this out first. R75707, well this is good and bad news. the good news, our developers do indeed know what they are doing! the bad news, i need to try to solder something back on there. ok, so its a resistor, any more information? make model micro soldering tutorials? i would really really like to fix this if i can. You can find the schematic and layout documents here: http://downloads.openmoko.org/developer/schematics/GTA02/ 75 Ohm and the correct size are the critical bits. Resistor tolerance shouldn't be an issue. I think the size is 0402 but you can check this by measuring (ruler, magnifying glass) before you buy, or hope someone who actually knows replies ;-) Here's one of many smt tutorials on the net. These won't be the easiest bits to start with though! If you've got a broken old motherboard or HDD to practice on it would be well worth doing. http://www.sparkfun.com/commerce/tutorial_info.php?tutorials_id=36page=1 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Phone Project (MiniMoko) : Which functionalities ?
On Saturday 09 October 2010, Thomas HOCEDEZ wrote: On 10/09/2010 06:15 PM, Al Johnson wrote: On Saturday 09 October 2010, Timo Jyrinki wrote: 2010/10/6 Eddered...@tkwsping.nl: Will it support headphone, with a microphone? I think it's safe nowadays to just assume Bluetooth headphones, ie. not all devices need the extra plugs if something has to be sacrificed. The 40 pin connector[1] has pins for headset left, right, mic and detect, so it should support a headset connecting through this at least. There is also a minijack socket that appears to be 3.5mm[2], but the spec[3] and pin disposition suggest this may be audio out only. If so it's an odd choice as there is a de fatcto standard for 4-pole minijacks for headphone and headset. 2010/10/6 giacomo 'giotti' marianigiacomomari...@yahoo.it: Looks like it miss USB connectivity and I need SSH strongly! Well SSH over Bluetooth personal area network works just fine, but indeed I'd also like USB port for charging and connecting other devices (host mode) USB is also on the 40-pin connector. Judging by the beagleboard, the OTG pins wil give gadget or OTG support while the other port will give host mode. There doesn't appear to be a 5V out pin though, so host mode may be unpowered. Personally I would rather see a pair of usb ports than the micro-HDMI and the barrel power connector, and make sure the headset connector is 4-pole with mic support. [1] http://alwaysinnovating.com/wiki/index.php/40-pin_connector [2] http://alwaysinnovating.com/wiki/index.php/MID_board [3] http://alwaysinnovating.com/wiki/index.php/Smart_Book_specs Interesting notes ! I add them to the Do/Don't Do list. Where is this list? I just answerd about a USB adapter (pluged into the 40pins). Perhaphs a multiport adapter, plugged in the 40pins, but with a 'U' form factor, so the wires will be parallel to the phone and behind. What about that ? Add some fold out legs and you have a docking station in the same unit. It's certainly neater than an octopus cable, or multiple adapters. In another post I suggested putting the 3G module, gps, pressure and ambient light sensors, magnetometer and gyro plus connectors in a small clip on module using the 40 pin connector. That makes phone and navigation hardware an option for those that want it without requiring AI to change their existing design, or force the extra expense on those that don't want it. The moko nav board v2 already shows the sensor circuit - 3.3v supply and i2c interface as available on the 40pin connector. There's a serial port for GPS too, which just leaves 3G, and perhaps some level shifting for the interfaces. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Phone Project (MiniMoko) : Which functionalities ?
On Sunday 10 October 2010, Maksim 'max_posedon' Melnikau wrote: Looks like we have 2 different opinions here: 1. attach-all-possible-staff-to-MID add new holes new connectors and so on, e.g. people dreams about open extra-cool phone. I'm a bit confused by such unrealistic direction of developing MiniMoko, and it will require at least 1-2 years. Probably true, but a nice long term target if AI want to make such a device. I _really_ want to see a phone with a daylight readable display! 2. Use already created MiniBook, just add gsm/3g board inside. IMHO, more realistic idea and definitely require less efforts. Certainly, space permitting. There may be enough space for navigation sensors too. They are easier to add than the 3G module, and have a similarly low requirement for case mods. And one more note: attaching anything via external 40pin port, will make device impossible to attach to Smartbook. The MiniBook can be connected as normal after removing the module. We could design the module so that it can connect everything via USB, in which case the module could dock to one of the USB connections available in the SmartBook. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Phone Project (MiniMoko) : Which functionalities ?
On Sunday 10 October 2010, Alfa21 wrote: And one more note: attaching anything via external 40pin port, will make device impossible to attach to Smartbook. The MiniBook can be connected as normal after removing the module. We could design the module so that it can connect everything via USB, in which case the module could dock to one of the USB connections available in the SmartBook. so, why we don't just add the µ-usb port and use that both to connect that module, charge the phone, use it as flashdrive etc..? also you'd need one and only the usb port on the module so you'll be able to connect directly or through one of the others ports on the smartbook. Because the point of the module is that is doesn't require changes to the existing MiniBook. Much as I would like to replace the barrel and mini-HDMI with client and host usb sockets, that would require a board revision and new plastics. If that's being done then the board rev may as well include the bits that would have gone into the module. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Phone Project (MiniMoko) : Which functionalities ?
On Saturday 09 October 2010, Timo Jyrinki wrote: 2010/10/6 Edder ed...@tkwsping.nl: Will it support headphone, with a microphone? I think it's safe nowadays to just assume Bluetooth headphones, ie. not all devices need the extra plugs if something has to be sacrificed. The 40 pin connector[1] has pins for headset left, right, mic and detect, so it should support a headset connecting through this at least. There is also a minijack socket that appears to be 3.5mm[2], but the spec[3] and pin disposition suggest this may be audio out only. If so it's an odd choice as there is a de fatcto standard for 4-pole minijacks for headphone and headset. 2010/10/6 giacomo 'giotti' mariani giacomomari...@yahoo.it: Looks like it miss USB connectivity and I need SSH strongly! Well SSH over Bluetooth personal area network works just fine, but indeed I'd also like USB port for charging and connecting other devices (host mode) USB is also on the 40-pin connector. Judging by the beagleboard, the OTG pins wil give gadget or OTG support while the other port will give host mode. There doesn't appear to be a 5V out pin though, so host mode may be unpowered. Personally I would rather see a pair of usb ports than the micro-HDMI and the barrel power connector, and make sure the headset connector is 4-pole with mic support. [1] http://alwaysinnovating.com/wiki/index.php/40-pin_connector [2] http://alwaysinnovating.com/wiki/index.php/MID_board [3] http://alwaysinnovating.com/wiki/index.php/Smart_Book_specs ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: New Phone Project (MiniMoko) : Which functionalities ?
On Wednesday 06 October 2010, Thomas HOCEDEZ wrote: Hi, As you might have read, Always Innovating (A.I.), is opened to think about a collaboration between them and us (Openmoko community) to build a phone based on their MiniBook. This device is a MID, without phone capabilities (except VoIP). So the idea is to build something together on that basis. I don't want AT ALL to shortcut GTA04 project, which is vital for everyone, so the main idea would be to improve a bit the MiniBook, generating a lite version of the GTA04. By lite, I suggest not to overload the bill motherboard with extra features that GTA04 will bring. More, The MiniBook have to stay an A.I. product, this mean, it must be linkable to the others as it does today. For information, MiniBook has already impressive specs : * TI http://www.ti.com cortex-A8 with 3D and video acceleration * 512MB (RAM) + 256MB (NAND) Memory * Main storage: 8GB microSD card * 480x320 3.5 capacitive touchscreen * 30fps VGA front webcam * Wifi 802.11 b/g/n, Bluetooth class 2.1 * Video output HDMI HD * Two high-quality stereo speakers * Internal microphone * Headphone jack * 3-dimensional accelerometer * One 1500 mAh battery * Bi-color silver/black case * 64mm x 106mm x 9.3mm * Secured attachment of the MID into a Touch Book Table There's nothing much to improve, nothing to remove, just adding GSM/3G chip. Nikolaus Schaller pointed the OPTION GTM501, which is a brilliant little chip ! And if we use the same one, the porting of distros/software will be easier from one machine to another. So, the first question is : What to add for this project being interresting ? Those will be minimal functions (forget Wimax, 4G, coffe machines or color printer ...). GPS - I wouldn't buy without it. It's just too useful for navigation. 3 axis magnetometer - from recent experience it is sometimes very useful to know which way you're facing as well as where you are. 3 axis accel, gyro and a pressure sensor would be nice but less important. Daylight readable screen - again from recent experience in a sunny environment. A transreflective screen, or one from PixelQi, would be better as they would cut down on the power needed for backlighting in bright environments. An ambient light sensor would be good to automate the backlight level. Better screen resolution - at least 640x480. It really does make the screen more legible, and significantly broadens the number of apps that can be used without gui porting. USB host mode Standard connectors for USB host/otg/device and charging. These could be in place of the mini-HDMI and coax power connectors. Given what's on the 40 pin connector an option might be to have a dockable module that can go either on the end of the MiniBook or inside the SmartBook. That would enable everything but the screen changes without changing the existing MiniBook design, and seems similar to the DualScreen module in design philosophy. Second question : Debian is able to run on such a device, but does developpers of other distributions can tell if it would be possible to port their on it ? If debian can run on it there should be no problem porting to other distros. Similarities to the beagleboard and n900 may mean other distros can already work with it. Third question : On the basis we have a 'paper' version of the phone, is there anyone able to give a hand to AI for the integration of new components on the board or do we let AI do the major part of the job ? (this way, we only would be 'consultants' for them). That probably depends on what they decide to do. On the hardware side they should be more than capable of implementing anything suggested above. Pick the right components and support may already be present either in the mainstream kernel or other open drivers. See the FR Navigation Board[1] for some examples, and n900 sensor support in the mainstream kernel for others. Thanks for your interest. Thomas. [1] http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v2 ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: QtMoko v26
On Thursday 16 September 2010, Jim Morris wrote: Ori Pessach wrote: I didn't mention it, but I did just that. I stood in a field, looking at grasshoppers for 5 minutes. That's when I decided to take a walk. Â This weekend, I left my FR on a table in the back yard for 20 minutes. Still no fix. Ok, so a couple of things you can try... take out the memry card if you have one in, on older models having that in could cause enough interference to stop the gps getting a fix Not unless there's been a kernel regression. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
dbus moving into kernel?
kdbus is proof-of-concept at the moment, the idea being to reduce the number of context switches needed for each dbus message. One synthetic benchmark shows a 3x speed increase on the n900 but speedup in real world applications seems much more modest. http://alban.apinc.org/blog/2010/09/15/d-bus-in-the-kernel-faster/ ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: ANN: Freerunner Navigation Board v2 is finally available
Looks good. It'll be a month or so before I can order one. On Sunday 12 September 2010, Christoph Mair wrote: Dear list, after lots of hard work I'm happy to announce that the Freerunner Navigation Board v2 is finally available! The team from handheld-linux.com [1] kindly offered to handle orders and shipping. The second version of the Navigation Board includes some features which go well beyond of what is needed for navigational purposes. The board comes in two assembly variants standard and complete. See below for a feature description/comparison. The most recent documentation as well as possible use cases and bug descriptions can always be found on the wiki page [2]. Features supported by any board: * 3D magnetometer The magnetometer measures magnetic forces on three axes. With some math it can be used as a compass. Alternatively, use it to measure the magnetic fields generated by trains while accelerating (e.g. underground lines). * 3D gyroscope A gyroscope measures angular velocity. It can determine how fast you spin your Freerunner around its three axes. Usable to support the integrated accelerometers for inertial navigation (navigation without GPS) or to create a wireless game controller (like the wii). * Barometric pressure sensor The change in ambient air pressure is a good indicator for changing weather conditions. If the weather is relatively stable and the barometric pressure changes, it usually indicates that the height above sea level changed. If this value is known the absolute height can be calculated without using the GPS. * Four channel LED controller This LED controller can dim and make blink up to four LEDs (e.g. RGBA). It works autonomously, even if the main CPU is suspended. This may for instance be used to indicate unread messages. Large blinking intervals and duty cycles enable short flashes to save battery power. Alternatively one could connect a high brightness LED and use the Freerunner as a dimmable torch. * Seven channel touch controller The chip could actually control twelve channels, but due to space restrictions only seven are available on the FRNBv2. They can be used to add touch buttons to your Freerunner or act as proximity detector. E.g.: disable the screen lock if you pick up the phone. (*) Four channels can also drive LEDs, if you don't need them for something else. Additional features of the complete boards: * 12-Bit analog to digital converter This chip is very similar to the one used on the Freerunner Navigation Board v1 to digitize the output of the gyroscopes. The FRNBv2 does not use it for own purposes, it's completely under users' control. A possible use cases would be an ambient light sensor. Or use it to measure the current consumption of the FRNBv2 ;-) * Programmable oscillator Do you need to generate a rectangular signal with programmable frequency between 1kHz and 68MHz? Then this chip is made for you. What can you use it for? I thought about a 38kHz oscillator which can be enabled and disabled using a GPIO pin. This could be used as generic infrared remote control. If you really need these two last features, order a complete board or add the chips yourself to any standard board. They come in leaded packages and are hand solderable if you have some soldering experience. (*) This feature was not tested yet due to a missing kernel driver. I'm not sure if it will work as expected. (**) The programmable oscillator does not work due to a strange bug. See the wiki [2] for details. Have fun! Christoph [1] http://www.handheld-linux.com/wiki.php?page=Navigation%20Board [2] http://wiki.openmoko.org/wiki/Freerunner_Navigation_Board_v2 ___ 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: [Shr-User] uSD hosed, on every unstable.
On Wednesday 08 September 2010, jeremy jozwik wrote: On Wed, Sep 8, 2010 at 9:50 AM, Gennady Kupava g...@bsdmn.com wrote: SD initalisation in kernel look strange and fact that we need different rootwait/rootdelay in kernel, while u-boot can read SD card almost instantly seriously puzzles me. Also i can notice fact that I have 50% probability of successfull mmc read in u-boot wuth 2-4-2 timings, while 4-4-4 is 100% successfull, may be only in extremly rare cases. This makes me think that some delay (or proper sync) is needed in mmc sequence. are you eluding to u-boot accessing the SD card incorrectly? if so, how is it that previously locally saved u-boot version used to work. and i used to be able to read the SD card within shr. I think there are two separate issues here. I think Gennady is correct to say there is something wrong in the kernel handling of mmc on the glamo, and probably also something wrong in u-boot. If everything was correct we wouldn't need a list of compatible and incompatible cards, or parameters to fiddle with delays and clock speeds. This may be another case where some study of the glamo documentation and the existing code can help. I have a 4G Kingston card that's on the non-compatible list if someone wants to try this. I don't think that is the cause of your issue because your cards used to work, but don't any more, with software that used to work for you and still does for other people. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: FS Freerunner
On Sunday 05 September 2010, David Pottage wrote: On 05/09/10 17:13, xChris wrote: I know about it. I had no luck, the FR does not 'see' my 3G SIM (three mobile UK). But the WTF is that a 2005 mobile (Nokia 6320i) CAN use that SIM and the FR can't! Is it that the FR can't read the SIM, or can't register with the network. Three are well known for blocking all 2G phones on their network, though the details of how they do it are fairly vague. One story is that they disconnect SIMs that get used in 2G devices, another theory is that they have a whitelist of approved devices, and only allow them to register. I suggest you try another network. When I tried a friend's 3 SIM in a FR it wasn't recognised. It did the same in his Nokia Communicator, so it isn't unique to the Openmokos. Stick it back in a 3G device and it's fine. 3's TCs are quite specific about not allowing use of non-3G devices. They get their fallback 2G coverage by peering with another network (O2?) so they probably pay for that traffic. The #666 trac entry has a broken link to a test report where IIRC a variety of SIMs were tested in Openmoko, Calypso reference board, and another phone. I think the conclusion was that there were some SIMs that the calypso could support but the FR didn't at the time, and some that it just plain couldn't support because they hadn't been standardised when the calypso was designed. I could be misremembering, but I couldn't find a working link to that document to check. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: [Community Updates] 2010-09-01 is out
On Wednesday 01 September 2010, Maksim 'max_posedon' Melnikau wrote: Because of FR's NOR bootloader, better to have some hacks in kernel, imho. The NOR bootloader is only intended to allow you to fix a broken NAND bootloader. You can do this perfectly well with the slower timings the NOR bootloader uses, so why do we need hacks in the kernel? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: WikiReader sales and the future of Openmoko
On Thursday 19 August 2010, Jim Ancona wrote: On Sat, Aug 14, 2010 at 5:58 AM, Christoph Pulster openm...@pulster.de wrote: Please note Android is a Google(TM) product. TM stands for total monopol. Or terrible monster. Google is evil. Android is no free OS. By what definition of free is Android not a free OS? That depends on your definition of Android. Most people think of Android as what you get on an Android handset, and that includes non-free (binary-only non-redistributable) drivers and core applications like the Marketplace. People making modified firmware images have been prevented from including these in their images by Google, so they have to work around by backing up the original binaries before flashing, then restoring them. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
