Re: Om2008.8 comments and questions
On Tue, 2008-08-12 at 17:13 -0400, Helmut Tessarek wrote: Alright then. What format has the addressbook? A .vcf importer cannot be that hard to develop. It does not even have to be a GUI app. I'm not sure if it would be worth the effort to work on this just for 2008.8. One of the phase 2 subsystems for FSO is a PIM manager that should handle this, although I don't think much work has been done on it yet. Maybe working on this for FSO and rolling it into 2008.8 would make more sense. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: Openmoko Om 2008.8 Release
On Sun, 2008-08-10 at 19:53 -0700, steve wrote: Good question. Here are the options. 1. Ship with 2007.2. Basicaly a dialer that works. bare bones phone. 2. Ship with Qtopia. A solid full featured smart phone. 3. Ship with OM2008.8 An alpha release of our future phone. What are the plans for FSO? Are there any issues with moving some of its features into OM2008.8 - maybe integrate the OM2008.8 dialer with the FSO phone server. I think OM2008.8 may be a good choice because it allows use of both gtk and qt apps and gives insight to where things are moving. I would suggest changing the gtk theme to something that doesn't mess up visibility of rendering like it has and matches the rest of the theme better (I have a theme if anyone wants it). Plain qtopia doesn't use x windows and you miss out on a bunch of good apps like tango. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Flash ASU
On Wed, 2008-07-30 at 22:49 -0700, Charles-Henri Gros wrote: Evgeny Ginzburg wrote: Scott wrote: Why do the latest ASU folders not have the kernel or root file system files? AFAIK if they are no changed, they don't appear again. Couldn't we get symlinks to the old ones or something? Having to click on all the days until you find a directory with the right files is annoying. I have to agree with this. It was a hassle last night when I was searching for the latest versions of everything to flash. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ears and FR - Display Locker
Sounds good thanks. I myself will want these instructions tomorrow. Just out of curiosity, what did you change the theme to? On Fri, 2008-07-18 at 11:09 +0200, Bastian Feder wrote: HI, regarding the installation of the display locker themes. I added the 'hint' / instruction to the Display Locker (http://wiki.openmoko.org/Display_Locker) Wiki page. Hope this was desiered ;) Bastian On Thu, Jul 17, 2008 at 6:02 PM, Bastian Feder [EMAIL PROTECTED] wrote: Hey, in my /etc/matchbox/session there is nothing obvious pointing to the display locker. I searched the matchbox docu,but wasn't successful at all. Then I rememdered reading a the display locker Wiki page whis says the Display Locker is noe part of the neod. That lead me to '/usr/share/neod/' which fortunately contained the images for the display locker. I replaced them by the ones I wanted and restarted my FR ... tada! just to led you know ;o) Bastian On Thu, Jul 17, 2008 at 1:44 PM, arne anka [EMAIL PROTECTED] wrote: I really like the alternative themes, but did not find how to change the default to an alternative theme. Ideas? the theme of the fr gui as whole is controlled by a parameter in /etc/matchbox/session ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community -- -- spread the word ... see www.browsehappy.com ;o) Calvin: Weekends don't count unless you spend them doing something completely pointless. Join the Greater IBM Connection (http://www.xing.com/premiumgroup-6291.d26b7d) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Ears and FR - Display Locker
I would suggest re-using the Display Locker program created for 2007.2 that's referenced at http://wiki.openmoko.org/wiki/Current_Applications#List_.2F_Description_2 on the wiki. It was, to my understanding, added as a standard application quite some time ago. Also thanks to the core Openmoko team. I should be getting my FreeRunner Saturday. Actually having the hardware will make me far more interested in developing for it again. The passion placed into creating a quality device warms my heart. Thank you for the work towards getting it out the door squashing bugs. On Wed, 2008-07-16 at 21:02 -0400, Yaroslav Halchenko wrote: why not to place analogous to qtopia 'unlock' action. e.g. phone which you need to drag down (ie drop it) to drop the call? On Wed, 16 Jul 2008, Joerg Reisenweber wrote: Am Mi 16. Juli 2008 schrieb Joseph Reeves: I do it all the time ;-) I'd like a keypad lock during calls. I know that there's some options available during a call, but I'd much rather have to unlock them first. Of course, it doesn't have to be a lock that's particularly difficult to un-lock - pressing the aux button before the screen does anything would be great. Use the g-meters / gestures! FR on ear - locked. FR in front of face - unlocked. Also simply placing buttons on bottom of screen instead on top might help a lot. /jOERG ___ 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: not being able to use Skype is a big problem
Carsten Haitzler (The Rasterman) wrote: On Wed, 2 Jul 2008 20:56:43 -0500 Forrest Sheng Bao [EMAIL PROTECTED] babbled: they both use ARM. freerunner is armv4, n8xx is armv5. (think of it like a pentium vs pentium-mmx - it has extra instructions in v5 compared to v4, but the vast majority of the core is the same). it can be run.. if you are lucky that the compiled binary doesn't use them. you can always write binary shims to interface binaries to existing libraries and system. you can manually hex-edit the binary and replace the armv4 instructions with v4 ones (insert etc). hacking a binary is not something that hasn't been done before. it's been done so many times there are many people who think of it as an art form... it just may be a LOT of work. On Thu, 2008-07-03 at 12:27 +1000, nickd wrote: Could this hackery mean that Android is a possibility? -Nick hacking android to run was tried, without too much luck, as mentioned at http://benno.id.au/blog/2007/11/21/android-neo1973 getting back to skype, i don't see why anyone would really want or need it. there are plenty of other voip clients such as ekiga. gizmo may also be an option on the freerunner. someone else was working on a voip client specifically for the FreeRunner, but I can't remember who at the moment. -jeremiah ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Convert Freerunner CAD Files - IGES or STEP?
On Fri, 2008-06-20 at 22:33 +0100, Andy Selby wrote: I have access to Pro/E and am willing to convert the Wildfire 3 files into something else. What do you prefer? IGES (Wireframe or Solid?), or STEP (Wireframe or Solid?)? .DXF would be nice If you have the files as IGES or STEP you should be able to convert them to DXF yourself. I'd like to see both IGES and STEP conversions. Solids would likely be better than wireframe, but I think people would have to try and open them in their respective CAD apps to see what works well. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Convert Freerunner CAD Files - IGES or STEP?
On Fri, 2008-06-20 at 16:49 -0700, Mike Montour wrote: I don't have any need for the CAD files myself, but yesterday someone on IRC was looking for an open-source program that could view them. Blender apparently has the ability to import .slp files from Pro/E, so it might be nice to have that in addition to IGES or STEP. Blender is more of an artistic program than a CAD program. I would suggest looking at Salome (OpenCascade), gCAD3D, MEDUSA, or possibly BRL-CAD. All of those are free (although some require registration) and should be able to perform conversions to files Blender can read as well. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA03: New case? Bigger screen! Plug in modules
On Tue, 2008-06-10 at 18:02 +0200, Ortwin Regel wrote: If the GTA03 get's a new case design, please consider making the screen twice as big! I would like a screen maybe 10mm to 20mm or so larger, but any bigger than that makes it too wide for a phone. Also, I suggest concentrating more on the horizontal (landscape or vertical portrait) usage. For example, bring the stereo speakers back. I would rather see the height used for a widescreen display and/or increased to add space for drop in modules (camera, ir remote, card reader, etc). ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
USB connectors on FreeRunner Hostmode
It's my understanding that the SC32442B in the FreeRunner has a host controller that can support 2 peripherals (I found a link to the manual today updated in the wiki). Is there just the 1 external connector or are there additional pins or connectors internal to the FreeRunner that can be easily used to connect a second peripheral device? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
RE: IGES STEP CAD file issues
Well, I haven't had any luck getting Pro/Engineer Wildfire 4.0 to install on Linux with Wine. It fails at a different point every time with one of a dozen documented errors. They suggesting ordering installing off a CD to fix most of those issues. Guillermo, I actually started an email to you previously, but wanted to try my hand at getting Pro/E to run first. As it stands I can't find anything to load the Pro/E geometry. Would you be willing to translate the new Openmoko Neo FreeRunner Pro/E file http://downloads.openmoko.org/CAD/NeoFreerunner_ProE.zip to some alternate formats (IGES, STEP, etc)? Also good job on your Neo skin. It looks great most of those files load perfectly for me. If you could translate the new Pro/E file into STEP IGES, then I have good faith I could load them into a 3D modeler program. Thanks, Jeremiah On Sat, 2008-05-24 at 11:16 -0700, steve wrote: Guillermo may be bale to help. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of christooss Sent: Thursday, May 22, 2008 2:50 PM To: [EMAIL PROTECTED]; List for Openmoko community discussion Subject: Re: IGES STEP CAD file issues Jeremiah Flerchinger wrote: I was curious how many people have been playing with the Neo CAD files? After I found the FreeRunner would be different in case design from the 1973, I held off on using the files. Since no-one has posted conversions of the new Pro/E files I decided to go back look at the old IGES STEP files and plan modifications I'd like to make. Do the 1973 IGES and/or STEP files work well for anyone? VariCAD either crashes (STEP) or returns a failure to convert dialog (IGES). Salome loads the STEP model but has all kind of geometries that go in the wrong directions (inverted buttons going out of case instead of in, etc). gCAD does about the same as Salome. I'm trying to install a 30 day trial version of Pro/E Wildfire 4.0 right now. If I'm lucky I can run it in Wine and I can see if it can export models that work any better for me. Please wirte if it works. ___ 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
IGES STEP CAD file issues
I was curious how many people have been playing with the Neo CAD files? After I found the FreeRunner would be different in case design from the 1973, I held off on using the files. Since no-one has posted conversions of the new Pro/E files I decided to go back look at the old IGES STEP files and plan modifications I'd like to make. Do the 1973 IGES and/or STEP files work well for anyone? VariCAD either crashes (STEP) or returns a failure to convert dialog (IGES). Salome loads the STEP model but has all kind of geometries that go in the wrong directions (inverted buttons going out of case instead of in, etc). gCAD does about the same as Salome. I'm trying to install a 30 day trial version of Pro/E Wildfire 4.0 right now. If I'm lucky I can run it in Wine and I can see if it can export models that work any better for me. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Wiki distorted in Firefox 3?
I concur that the left menu is now at the top, except for the search and toolbox items. On Tue, 2008-05-06 at 07:05 +0200, Joachim Steiger wrote: please retest, ive added a small patch, courtesy of abraxa. thanks for testing (most of us is till on FF2 here) ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Stylus Recommendation
I'd like a Nintendo DS style stylus and holder because they're small, cheap, I like how they fit into the casing of the DS. I would try to use the FreeRunner CAD data ( http://wiki.openmoko.org/wiki/Neo_FreeRunner_GTA02_Hardware#Case ) to make my own case mod design if I could find something to convert Pro-E files. As it stands I refuse to buy Pro-E for a single hobby project. On Sat, 2008-05-03 at 09:12 +0200, Nicanor Babula wrote: Shawn Rutledge wrote: On Fri, May 2, 2008 at 7:56 AM, Hans L [EMAIL PROTECTED] wrote: I am not an electrical engineer, but I think that the voltage/current produced from such a magnet would be negligible. But, even assuming that it would not be harmful, isn't the case made of plastic? Is Well you could take apart the phone and try to find a place to stash a small, really strong neodymium magnet. Then use a thin steel stylus (with a soft plastic tip), shaped to fit against whatever surface has the magnet. It could even fit against the side of the phone, if it had a slightly concave shape. Or mod the case to have a shallow groove for the stylus to fit into, then the stylus could just be a thin steel bar, or rounded on one side as suggested. Since the magnet doesn't move, it shouldn't cause any inductive pulses (although it might cause electrons that are trying to move in a straight line to go off in a curve instead. Not sure if that would affect anything...) Now I am using a motorola A1200E Motoming (linux based ;) ) and it has a stylus too. I like very much the way the stylus is attached to my motorola and I would like to see it on the neo if it doesn't create large additional costs. Check it out: http://direct.motorola.com/hellomoto/motomingedge/ ___ 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: Steve on V5 versus v6
On Sat, Apr 19, 2008 at 12:21 PM, steve [EMAIL PROTECTED] wrote: As far as the goodies in the box go. Whether it's an A5 or a A6, the box will the following at least. I'm still sorting through some issues. 1. phone. 2. Battery 3. Custom Charger 4. Sdcard. 5. Stylus. 6. USB cable. Sometime down the road I will pull out the Sdcard and try to put in a branded Neo stylus. No promises. Headset, I am working on. No promises. Steve Is the usb cable really needed by most people? There is bluetooth wifi for synching and people could always just go buy one if needed. It's my understanding it will be a standard mini-usb to usb. Somehow I have at least 5 of those sitting in my office. Maybe just tell people in the quickstart guide what kind of cable they'll need to attach usb peripherals or charge from a computer. I think that a usb cable would be easier for people to find buy than headphones with a specific impedance. If the quickstart doesn't have a recommended headphone impedance range one should probably be added - especially since I heard some people were having issues with low headphone volume because of the impedance. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Unofficial poll: Do you want 3G in the proposed successor, GTA03?
On Wed, Apr 9, 2008 at 4:26 AM, Hugo Mills [EMAIL PROTECTED] wrote: On Tue, Apr 08, 2008 at 09:28:02PM -0500, Mark Arvidson wrote: I use my phone's EDGE capabilities while riding across Texas to the next family event... As it is, I don't use Wifi much (of course, I don't have it on my phone yet). There are very few free places to use it around here, and their ranges are rather limited. Traveling at 75 mph down a highway means hotspots come and go in a few seconds, so that's not even a potential problem solver for me. I'm almost precisely the opposite use case. I'm almost always somewhere with stable wireless access. I don't really care too much about fast data access over the phone network, but having 802.11(whatever) in the device is a must for me. Hugo. I myself am also much closer to Hugo. If I want access to data, I'm usually near someplace with wireless access and would rather use Wifi because it is free or cheaper. I also don't think it's wise to drive down a highway and using a browser, email, or typing in the terminal (hopefully you're the passenger) - but WiMAX could provide that capability. We are starting to see a push to integrate WiMAX WiFi into the same chipsets and this will only become more common. I think WiFi is popular enough the integration of WiMAX would make it questionable to not include these technologies together warrant a seperate module for WiFi/WiMax. Wouldn't the areas that currently support 3G also be more likely to quickly adopt a 4G technology like WiMax? Why not skip 3G and go straight to 4G? ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Post GTA02 plans
Michael, I'm not sure if the other guys read this mailing list too, but I wanted to that all of you for opening up this topic and share my opinion. From: Andy Green [EMAIL PROTECTED] To: [EMAIL PROTECTED] [EMAIL PROTECTED] We had some internal talk about how to go post GTA02 and Wolfgang wants us to make it external. We have a choice about basing on S3C2443 or S3C6400. I like the 6400 better but information is a bit scarce right now and it can go either way. I myself like the overall look of the 6400. It has a bunch of decoding I/O features. The USB 2 could be useful to some people. It's also a nice step from an ARMv4 to a ARMv6 instruction set. I didn't look too hard, but what are the big reasons against the 6400? Some other concepts kicked around: - Merge the debug board function on to the phone, perhaps with internal micro USB used for debricking and hacking. No write-once memory. This would be great. Any chance to have downloadable firmware updates? - Focus on SD Card rootfs rather than internal memory Can we get a 2nd SD card slot, so 1 is for rootfs and 1 is for files in general? If so, the rootfs card should be place in a separate location under a cover so it isn't accidentally pulled out. To be clear though -- GTA02 is soon going to actually exist, and this is just future talk right now. But because of that, if you have any ideas about future arch, now is the time to throw them in and they will at least get the time of day. WiMax might be fairly interesting if it begins to permeate the market. I know Intel is releasing chips that combine WiMax with Wifi and adding it to laptops. A slightly bigger screen might also be nice. I can't say much about the future until I actually get my hands on some hardware that's been created to date. -Jeremiah ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Metal case [was: Application idea: Bicycle computer]
By the way, when will the CAD files for the Freerunner case be released? Also, is anyone seriously working on alternative cases for the FIC Openmoko phones? I've heard the GTA01 and GTA02 have similar cases, but it hasn't been confirmed if they are identical. I'm going to wait for word on this before I make anything (or just wait until I get a GTA02). I'd like to make initial prototypes with molds casts made from a GTA02 to try out shapes before doing anything in CAD that could be machined. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Similarity of GTA01 and GTA02 cases
Sorry, to respond to myself, but I just remembered something. I've heard the GTA01 and GTA02 have similar cases, but it hasn't been confirmed if they are identical. Actually Michael did confirm they're not identical, but the nature of the differences are currently unknown. I'll wait until these are known, because I will only have a GTA02 (or 2). ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA02 schematics
Thanks, I wasn't aware the Freerunner files had also been posted. Now we just need some people with Pro/E to do some conversions. Daniel Willmann wrote: On Fri, 07 Mar 2008 10:56:56 -0700 Jeremiah Flerchinger [EMAIL PROTECTED] wrote: Sorry, to respond to myself, but I just remembered something. I've heard the GTA01 and GTA02 have similar cases, but it hasn't been confirmed if they are identical. Actually Michael did confirm they're not identical, but the nature of the differences are currently unknown. I'll wait until these are known, because I will only have a GTA02 (or 2). Well, anyone with access to Pro/E can now check: http://downloads.openmoko.org/CAD/ Regards, Daniel Willmann ___ 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: questions about Neo FreeRunner
Is there a list of standard software features that will be installed on the phone? Everything I saw seemed to outline just the hardware. Go here http://wiki.openmoko.org/wiki/Applications The freerunner should have everything (0,1st 2nd phase apps) I think looking here http://wiki.openmoko.org/wiki/OpenMoko_Core_Applications might be better for showing the standard software. It has some screenshots and it should reflect the current core applications more accurately. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Wiki dialer warning
The warning on the wiki says: *WARNING:* *The OpenMoko GUI applications are not suitable for end users yet.* They are still in beta. Do not expect to always and reliably make and receive calls from the OpenMoko GUI. Thanks to the openness of the FIC Neo1973 hardware, there is also an alternative to the OpenMoko GUI: Qtopia 4.3.x is released under GPL and is at the edge of being usable for phone use. How reliable is the dialer currently? Can we remove Do not expect to always and reliably make and receive calls from the OpenMoko GUI from the warning yet? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: A bit of fun - freerunner and the wisdom of crowds
I believe I read the initial GTA01 batch of 1000 was announced for sale in early July 2007 and was sold out early August 2007. Hans L wrote: Does anyone know how many GTA01 devices were produced? As far as I know all the ones they produced were sold. I wonder how long it took before they had enough orders to sell all the devices(I understand there were some production/distribution delays even after orders were taken). If anyone knows this info, I think it might help get a ballpark idea of the amount of interest. -Hans Loeblich On Sun, Feb 10, 2008 at 11:52 PM, Jeremiah Flerchinger [EMAIL PROTECTED] wrote: A scatter plot would be cool with some more sales to a given month period that could be guessed. At least additional guesses for sales in first 6 and 12 months would be interesting. Tim Kersten wrote: The site is up. It's mostly untested. See it here: http://openmoko.hobby-site.com/ It has the features that were mentioned in the original opening email of this thread. It's not possible to edit entries at the moment, but I can add this if it's needed. I figured it doesn't need any authentication. Do you think a captcha is necessary? Feedback is of course appreciated. I can't make any promises about finding time to make improvements to it though, as I'm fairly busy with college. If I find/have time I'll gladly do it :-) Cheers, --tim On Sat, Feb 9, 2008 at 5:13 PM, JW [EMAIL PROTECTED] wrote: Tim Kersten [EMAIL PROTECTED] writes: As there doesn't seem to be any takers, I'll offer to give it a shot.--tim nice one tim! JW ___ 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 ___ 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: VoIP+IAX Program Theory for OM
I think there would be more compatibility across devices networks with a SIP based client than an IAX. Asterisk supports both, although I not sure of the benefits of using one versus the other. I previously suggested looking into LinPhone since it is a GTK solution that is the basis for PhoneGaim several other solutions. I'm not sure I like the idea of Mozilla's Zap if it requires all the overhead of running Mozilla. Right now I use the Gizmo Project server (without the Gizmo client) for handling of all my SIP calls. I use GrandCentral to get a local POTS number (and a number local to my parents), voicemail I can check from the internet or any phone, and forward calls to both my cellphone my SIP phone for free. If someone has a better setup that doesn't require a land-line still allows POTS calls, I'm happy to hear it. I don't see running my own Asterisk server being that much more beneficial to my needs. My dream is to have a freerunner that would default to SIP when attached to a wifi network and switch to the GSM network when wifi is not available. Meadhbh S. Hamrick wrote: Hey Kyle... Yes.. this is a basic convergence function. I worked at Divitas Networks last year trying to make this happen on WinMoblie and Symbian phones. Sadly, I was unsuccessful in getting them to work on a Linux Solution, so I had to do all my Linux based VoIP experimentation on my own time, though I've been working exclusively in the SIP/SRTP solution space. There's a lot of flexibility in this kind of solution. For one, you don't really need a POTS phone number connected to your VoIP system, you can use it as a complete net-bearer system using IAX or SIP. You could then add an IPCSP (IP Communications Service Provider) to link the POTS phone number to your asterisk box. This is sort of what Skype does with Skype-In / Skype-Out, but their network is closed and you have to wait for them to port their client to various platforms :-(. And if you wanted to have a lot of fun, you could even roam between VoIP and cell. This is essentially what the carriers do with UMA, and it's what Divitas did, though uptake on their product has been pretty slow. Several folks are in this game I've been looking at Mozilla's ZAP project recently, and under the hood on the client I can't imagine rewriting a media framework given that gStreamer seems to work quite nicely. -cheers! -M. On Feb 21, 2008, at 9:33 AM, Kyle Bassett wrote: Hey guys, I've been contemplating writing an IAX client for OM which would be capable of the following: Prerequisites: -user has dedicated VoIP phone number routed to an Asterisk server[1] ---OR a compatible VoIP provider that supports fallback[2] calling -user has smartphone+OM with some form of internet access (wifi/bt internet/ethernet) ---in addition to regular GSM/CDMA service on the smartphone -[optional] user has regular GSM/CDMA cell phone+service Usage situation: The user exchanges the VoIP number with all contacts. When someone attempts to contact the user, via dialing the VoIP number, the asterisk server answers the call and checks to see if the user is available over VoIP. If the user's smartphone is on and connected to the internet, the OM IAX client should connect to the asterisk server automatically (depending on the user's settings, etc.) If the phone is available over VoIP, asterisk attempts to ring the user over VoIP for a specified time. If the user does not answer or a connection problem persisted, then the asterisk server can forward the call to the user's regular (OM or third party) cell line. Asterisk is very flexible and many permutations of this example can be accomplished, ie. calling all the numbers at once, and forwarding the call to the first to pickup. There are many benefits to this system: --User has complete control over the call routing and voicemail system --User can prevent the usage of regular cell airtime by using VoIP as much as possible --User can give one phone number to all contacts and have asterisk decide how to handle the call (routing not just to the cell phones, but to home lines, etc.) --During the debugging process with OM+GTA0x, users can carry both phones and still use just one number throughout the day Call comes in-asterisk tries OM[VoIP]- tries OM[GSM] - tries regular third party cell phone (can also ring all numbers at once) [1] asterisk.org [2] fallback calling is a service that allows VoIP users to enter a number (regular landline/cell) as a fallback in case the VoIP call cannot be established I have tried to remain as general as possible, that way this post won't become outdated with specifics to any specific hardware. In reality, we want OM on as many phones as possible. ;-) Please provide any feedback or ideas! -Kyle ___ OpenMoko community mailing list community@lists.openmoko.org
Re: A bit of fun - freerunner and the wisdom of crowds
A scatter plot would be cool with some more sales to a given month period that could be guessed. At least additional guesses for sales in first 6 and 12 months would be interesting. Tim Kersten wrote: The site is up. It's mostly untested. See it here: http://openmoko.hobby-site.com/ It has the features that were mentioned in the original opening email of this thread. It's not possible to edit entries at the moment, but I can add this if it's needed. I figured it doesn't need any authentication. Do you think a captcha is necessary? Feedback is of course appreciated. I can't make any promises about finding time to make improvements to it though, as I'm fairly busy with college. If I find/have time I'll gladly do it :-) Cheers, --tim On Sat, Feb 9, 2008 at 5:13 PM, JW [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Tim Kersten [EMAIL PROTECTED] writes: As there doesn't seem to be any takers, I'll offer to give it a shot.--tim nice one tim! JW ___ OpenMoko community mailing list community@lists.openmoko.org mailto: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: A bit of fun - freerunner and the wisdom of crowds
can you change my guess (Flerchjj) to 3000? Tim Kersten wrote: The site is up. It's mostly untested. See it here: http://openmoko.hobby-site.com/ It has the features that were mentioned in the original opening email of this thread. It's not possible to edit entries at the moment, but I can add this if it's needed. I figured it doesn't need any authentication. Do you think a captcha is necessary? Feedback is of course appreciated. I can't make any promises about finding time to make improvements to it though, as I'm fairly busy with college. If I find/have time I'll gladly do it :-) Cheers, --tim On Sat, Feb 9, 2008 at 5:13 PM, JW [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Tim Kersten [EMAIL PROTECTED] writes: As there doesn't seem to be any takers, I'll offer to give it a shot.--tim nice one tim! JW ___ OpenMoko community mailing list community@lists.openmoko.org mailto: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: proprietary firmware
I see the concern of using up all the CPU time and wasting power. It would be great if we could have binary patches as downloads with software an architecture that could update all the firmware. It would be even better if we had enough information about the chips in concern that we could upload our own software into the flash memory or RAM of different chips to run our own firmware. Software drivers on the main processor could be used in either case to test apply temporary patches or provide specialty extensions. More information about hardware an API to access the hardware would be needed either way. My opinion is a (binary/encrypted) software mechanism should be provided to update firmware with binary/encrypted data from the vendor, but try to get APIs with the firmware to get access to lower level functionality and provide the option of doing as much or as little on chip as desired. Individuals could flesh out modules in software they could eventually create fully open functional drivers firmware. Users could be given a default configuration and allowed to choose an alternate configuration or additional software modules/patches. Maybe, in the future, hardware manufacturers would agree to set aside or disclose some address locations/registers on the hardware that point to certain functions allow values to be written there that point to custom routines. Maybe they could even allocate some address space in the hardware for custom routines to be loaded in addition to a method of interacting with the CPU main memory (possibly with these chips executing code on main RAM as instructed by CPU). On another note, access to low level GPS functions could be fairly interesting. Imagine gathering data from a local weather station and using it to better calculate atmospheric effects and improve accuracy. 'a little cpu-speed' is an assumption. The more the more software's running on the CPU, the more CPU speed they'll take. 400MHz is really, *really* easy to use up. Considering how much stuff the other ICs do by themselves, we can heavily load the CPU pretty easily. Also, we can lose phone reliability, as the scheduling of periodic tasks could be delayed by other things (do we even have a hard real-time scheduler here?). IMHO it's a giant waste of CPU battery power -- the other chips will still be running, but now we're using the CPU more. For what? I don't think the GSM chip does anything terribly interesting. Wifi's not much better, and the GPS is probably the simplest. I'm sure others want to find that out themselves through their own hacking. But I don't want to fill up my CPU with garbage the other dedicated chips should be doing. If openmoko decides to go through with this firmware opening, please give us a way to use the regular firmware, too. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Input Method Development
this uim has an embedded scheme interpreter... I don't like that too much for an embedded device... hmm, I have no idea: is it big, slow? It's apparently used on Linux Zaurus. We could adapt the openmoko soft keyboard to interface with uim, and if the API is well designed, the IM module could be changed... I'm not sure adapting to a soft keyboard would be required. It may seize key presses emit appropriate utf-8 key values. Try installing it on your desktop trying it with a few soft keyboards. could someone update me on the differences between these kr input methods described in the doc? * Byeoru * Hangul (2-beol) * Hangul (3-beol) * Hangul (Romaja) I have no clue. Were you intending this for the mailing list? I'm assuming so, but only saw this addressed to myself. Yeah, I know the patents problem with T9. But what about this one? What one? uim is open-source, so there aren't patent issues (if that's your question). ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Any users in Hong Kong?
Hong Kong appears to have decent DOP, as reported on the US Air Force GPS map http://gps.afspc.af.mil/gpsoc/performance_reports.aspx Are you trying indoors or while surrounded by many tall buildings? That would seriously degrade the GPS signal. dda wrote: Hi, The reason I ask is that my Neo1973's GPS can't get a fix, at all, and I was wondering whether the problem was location-related -- or just plain bad karma... Thanks. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: I dont know why I was supprised
It's been listed on http://wiki.openmoko.org/wiki/Neo1973_case_schematics#Official_case_schematics for a couple weeks. They could use any help they can get converting to additional file formats (see the note on wiki link). Christopher Earl wrote: www.openmoko.com Today I noticed a change that OM has released their CAD files for the case of the GTA01, This opens a major door to Case modding. I guess im used to closed hardware and tight-liped companies, but i was supprised. I will never again own a closed phone. ___ 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: Input Method Development
I've done a little work on a soft querty keyboard written with GTK. It is reconfigurable, by use of an xml config file, and I was playing with support for UTF-8. I haven't had time in the last couple weeks to work on it because of my work school schedule. A slightly out of date version is available in a tar.gz http://projects.openmoko.org/projects/gtkeypad/ Feel free to look at it, create a Korean xml config file, and add to the source. I have slightly newer code on my computer that I need to post. I also have to get everything into the CVS after Alessandro lurlano told me how to correct an authentication issue. Jeremiah Flerchinger dda wrote: I just received my Neo1973, and since I require Korean input, I'd like to do it myself... I'd like to do something similar to the soft qwerty keyboard -- except that I'd use Korean letters instead of Latin ones. I've poked around the wiki, but I haven't found any good pointers on creating and adding input methods. Any pointers would be greatly appreciated. Thanks ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: support for using yyyy-mm-dd (2008-01-31) date format in Wiki and elsewhere
I myself am used to using dates like 04 Feb 2008. How about just
inverting this order so it matches what you want, but the abbreviation
of the month is used? Then nobody would get confused on what is the day
what is the month.
Joachim Steiger wrote:
Ian Darwin wrote:
No, they cannot. That is always, always year-month-day. It is an ISO
standard, is used in many countries (see the Wikipedia link in the OP),
and has been standard that way (maybe not de jure, but widely used) for
at least thirty years. The other is very commonly used both ways, split
between the US and other parts of the world.
i fully agree.
lets use -mm-dd
its totally clear to use it since it gives the slowest changing number
first and the fastest changing last (especially when adding a time (in
UTC of course ;) ) AND it also gets sorted correctly by machines.
ps:
please do not get me started about how chinese do count years (its '97
now, you know?) or how germans do it ('/' instead of '-' and starting
from the other end) ;)
kind regards
___
OpenMoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Gizmo for Skype-like functionality in Neo?
Has anyone who actually has hardware right now tried/had luck running a full featured VOIP application in OpenMoko? I'd much rather see Gizmo than Skype, especially since it looks like it's integrated into GrandCentral (http://www.grandcentral.com/) and is based on open standards (and closed source). It also looks like Gizmo directly supports the Maemo on the Nokia N800 (http://gizmoproject.com/learnmore-nokia800.html). ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Gizmo for Skype-like functionality in Neo?
the serverless instant messenger http://retroshare.sf.net (Qt gui) will have soon as well VOIP and VIDEO Chat, and this is quite good for openmoko, as this is an encrypted one, so you are safe, that no third party is hearing your Voips. (http://gizmoproject.com/learnmore-nokia800.html). Other options are http://ekiga.org/ and http://www.openwengo.org/. They both do SIP. I know about Ekiga because it ships with Ubuntu, and it's completely open source. I don't know that much about OpenWengo. -c. Ekiga is just a client package and doesn't contain a server component, like asterisk. There is also linPhone (http://www.linphone.org/), which is built with GTK and has core/gui seperation. That might be nice for direct integration into the OpenMoko GUI and for people who don't want to run an entire asterisk server on their phone. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Gizmo for Skype-like functionality in Neo?
joerg wrote: Am Mi 30. Januar 2008 schrieb Jeremiah Flerchinger: Ekiga is just a client package and doesn't contain a server component, What for do you want to have a server on GTA? BTW linphone is no way different in this aspect AFAIK. I personally wouldn't want a server on the phone. I would rather log into a separate SIP/IAX server that could give access to land lines as well as SIP VOIP lines. I was trying to extend the post I replied to gather more suggestions for SIP client software because I didn't understand why an entire server was needed. like asterisk. There is also linPhone (http://www.linphone.org/), That might be nice for ... people who don't want to run an entire asterisk server on their phone. That's true for every SIP-Usaer-Agent, i think. Just no need for a server. Register with any SIP-provider, or simply do direct IP2IP without any registrar at all. I don't know _any_ SIP-softphone that needs asterisk on the local machine. j Agreed, as I said above. Still, I do prefer the idea of using a SIP-provider instead of IP2IP purely for the purpose of calling land lines. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: What soft phone to port?
I personally don't care much which sip client would be ported. I would like to a sip client that could be eventually integrated with the address book, dialer, webkit (for clicking on sip links) or other apps, to some extent, in the future. I don't know how well all of the different apps would lend themselves to this. I think a GTK based client that looked similar to the current dialer would be great. Also the current build environment doesn't support C++ to my knowledge. This would exclude Ekiga because it's written in C++. LinPhone is C based I'm not sure about minisip. I think most of the other apps mentioned were Qt based. Brandon Kruse wrote: I am going to fully port a sip client (besides the iax client I am already working on) This is a flame-free thread :) I want your input on what sip client you like, why, and in your opinion, how easy would it be to adapt to the OM platform? Take into account portability and libraries. Btw asterisk on the moko was my idea, it was for proof of concept and fun, really not a soft client. Not what it is meant to do. (even though chan_alsa does work :) ) Brandon Kruse (bkruse) ___ 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: Any OS X developers out there working with OpenMoko?
I currently don't have a Neo, nor do I have an iPhone. I currently won't get the latter, due to the current lack of an SDK and being forced into a wireless contract that doesn't meet my needs. I do occasionally work in OS X, but am usually on a Ubuntu desktop. At the time being my plate is (over) full. After I get a FreeRunner wrap up a couple other things I'm working on, I'll look into using it with the Mac. Still, I plan on doing most/all my development in Linux. In regards to the shape or form factor that some people mentioned, if you don't like it then change it. Design a new case and have some made. Maybe others will like it and it will gain popularity. The same goes for software. If you don't like something spend a few minutes a week trying to fix it or providing /constructive/ feedback and test results. Dr. H. Nikolaus Schaller wrote: Hi, I recently looked into the change history of the dedicated MacOS X page in the wiki and I have got the impression that I am the only one still doing something and improving the interworking between the Mac and OpenMoko: http://wiki.openmoko.org/index.php?title=MacOS_Xaction=history Is my impression wrong or have you all already bought an iPodTouch or iPhone and waits for the SDK? Please raise your hands... Nikolaus (hns) ___ 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: Digital Compass JavaFX - Additional hardware through custom mods
I agree that additional hardware should not be added to the default phone. If people want additional hardware they should get a custom case with extra room to support hobby projects and build/test these expansion modules themselves. If some of the modules became mainstream I could /eventually/ see these features added to the default configuration. Carsten Haitzler (The Rasterman) wrote: On Wed, 23 Jan 2008 08:45:43 -0800 (PST) Wallace Jackson [EMAIL PROTECTED] babbled: A digital compass would be a nice feature for VIA (OpenMoko) to have in the phone as a hardware default. Is it inexpensive enough in quantity to include in the shipping release!? Also, I saw a NEO1973 on Sun's not going to happen. we are at gta02a5 (5th version) and are making zero changes - we want to make this work and release. we are only in the business of making sure what we actually have works. adding more will add cost and a lot more time to market. so basically- no. :) JavaFX announcement release on-line, behind the presenter (bigger than life!)... Does this mean that JavaFX is ready to rock for NEO application? no idea at this stage. Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ ___ 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: CAD files for the case of the Neo will be made available
Thanks to Mario for the link. I'll have to try MEDUSA in the next few days. From the documentation, it looks like it may be like BRLCAD and require a copy of ProE for the coversion (hopefully not), but we'll have to wait see unless someone already knows for sure. I'm glad to see a decision has been made regardless. Wolfgang the OpenMoko team will give us files in the same format they use, insuring no degradation of dimensional information between them us, and I'm sure we can find some programs people that can convert the files from there. We can at least try. Getting the files like this should at least speed up the process for the OpenMoko team. Wolgang, someone made a wiki entry at http://wiki.openmoko.org/wiki/Neo1973_case_schematics, so this would likely be a good place to place the Pro-E schematics for the Neo1973. Jeremiah Wolfgang Spraul wrote: Mario - thanks, that is good to see. After long discussions, we have settled on releasing the files in Pro/E .asm/.prt format, the same as used by our mechanical engineers. Zero loss of fidelity. Highest quality. Expect to see more from Michael soon. Thanks again for the link. Wolfgang On Jan 17, 2008, at 10:33 PM, Rogen, Mario wrote: I did not follow the whole discussion but today i've read about a CAD Software which is free for personal use and i think it is able to read/import? Pro-E files: http://www.medusa4.com/index.php?screen=1.3ziel=Products-MEDUSAland=co m maybe someone knows more details? Best regards Mario -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wolfgang Spraul Sent: Thursday, January 17, 2008 1:29 PM To: [EMAIL PROTECTED] Cc: List for OpenMoko community discussion Subject: Re: CAD files for the case of the Neo will be made available Jeremiah - thanks for the detailed information, it is indeed very helpful. The file format is the last open question. We have been looking into it the whole day. We are concerned that we release a file that will not be really useful for the purpose we are trying to achieve - allow for custom cases, case addons, mods. Our internal engineers use Pro/E Wildfire 3.0. They believe an export to DXF would severely limit the ability to use the file in an actual custom case project. Of course it may be that they are just most familiar with Pro/E. So at the moment I am leaning towards releasing the GTA01 case design in the original Pro/E format (.asm/.prt), with zero loss in fidelity. That would also make it easier for us in the future to release more such data, because our engineers could make sure the files we are releasing are really high quality and useful data, rather than as a last step exporting to a format they never use, and hope the exported file is still useful. It would probably be posted as an attachment in our wiki (about 70 MB). If someone can do a conversion to a more open format as part of a real project, and thus keep the quality/usability of the file intact, that would be great! What do you think? Regards, Wolfgang On Jan 17, 2008, at 1:57 PM, Jeremiah Flerchinger wrote: Wolfgang Spraul wrote: Jeremiah - thanks for the information, that is indeed very helpful. Your list includes DXF, that was the preference before. I am concerned that the export process will corrupt the file and we release a file that will be painful to actually use. From the formats you listed (Wavefront, DXF, STL), which is your preference? Which one do you believe is a format where Pro/E can export all information into, without loosing much? I'm not very familiar with internal structure/format of DXF files, but have written software that uses STL and Wavefront files. I'll answer to the best of my knowledge. The most information would be lost with STL files. DXF files would likely loose the least information and Wavefront would be somewhere between. This is dependent on how good the converters in ProE are. Often only the most basic features of the Wavefront format are implemented in applications and a surface description equal to or only slightly better than a STL file is achieved. This could also apply to DXF files, depending on the quality of the converter and the app that reads them in, but I bet the converter in ProE is pretty good. One issue is there are many versions of the DXF file format. A quick search shows Blender supports a subset of objects up to DXF version 2007. Art of Illusion only loads from ASCII DXF files and is limited to vertex information. Of course as long as the conversion is good loads well for a couple apps, we could do additional conversions on our own. I believe an ASCII DXF format would be more accurate for most people and lose the least amount of information in the conversion. There may be fewer version compatibility issues with Wavefront files, but DXF readers can also often read newer files than they were designed
Re: CAD files for the case of the Neo will be made available
I don't think ProE by itself is suitable, especially since you need a copy of ProE even to import it to BRLCAD. I myself would suggest Wavefront (.obj), ASCII DXF (.dxf), or STL (.stl) file. All are standard formats should be in ProE and any other 3D editor. Instructions for converting from ProE to STL are as follows: ProE * File Export Model * STL * Set chord height to 0. The field will be replaced by minimum acceptable value. * Set Angle Control to 1 * OK ProE Wildfire * File Save a Copy Model * Change type to STL (*.stl) * Set Chord Height to 0. The field will be replaced by minimum acceptable value. * Set Angle Control to 1 * OK* * I'm sure the process would be similar to convert to either of the other 2 formats. Jeremiah Flerchinger* * Wolfgang Spraul wrote: Esben - Interesting. I checked on BRLCAD's website Converting Geometry Between BRL-CAD and other Formats, Page 17 http://ftp.brlcad.org/VolumeIV-Converting_Geometry.pdf and it seems Pro/E import is actually quite solid. However you need a seat of Pro/E to do the conversion. Is releasing in Pro/E format (.prt and .asm files) an acceptable way? Wolfgang On Jan 17, 2008, at 2:36 AM, Esben Stien wrote: Wolfgang Spraul [EMAIL PROTECTED] writes: Regarding the format, the original is in Pro/Engineer Assembly (.asm) and Part (.prt) files. That's probably hard to digest for any FOSS CAD software. BRLCAD[0] has preliminary support for this format. [0]http://brlcad.org/ -- Esben Stien is [EMAIL PROTECTED] s a http://www. s tn m irc://irc. b - i . e/%23contact sip:b0ef@ e e jid:b0ef@n n ___ 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: CAD files for the case of the Neo will be made available
There are converters from .stl and .dxf files to G-code. A web search will bring up a few. I couldn't recommend any because I haven't tried them. Shawn Rutledge wrote: On Jan 14, 2008 8:32 PM, Jeremiah Flerchinger [EMAIL PROTECTED] wrote: Can you generate CAM paths with Blender? What type of CAM files/input do you have in mind? I know both Blender AOI support .stl files and a few others. Plugins are available for both. Are you asking about CNC G-code or something else? Yeah, G-code. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: OpenMoko will be at SVHMPC meeting TONIGHT in Menlo Park
I see OpenMoko as lower level than Android. Users can give feedback into the very core of the hardware software. I expect to someday see Android applications integrated into OpenMoko. Android appears to be just a virtual machine sandbox that sits on top of a Linux core. I don't see most Android based phones makers willingly giving access outside of the Android API and runtime or taking user feedback seriously. My question is why doesn't Google release the Android runtime API in a form that can be easily integrated and run on OpenMoko or any other Linux? It's just built on top of a linux kernel a bunch of standard libs. Someone please ask that for me. Michael Shiloh wrote: Good question, Jeffrey, and you suggest a question that I'd like to ask you, the community: Why do you chose to develop on OpenMoko, rather than on Android? Or do you do both? (Beside the lack of Android hardware) Michael Jeffrey Thomas wrote: I am unable to attend this meeting due to geography, but if anyone is in attendance I would be interested to hear the Google people's response to why they felt the need to start a competitive project rather than join the OpenMoko team. Michael, as an official in the OpenMoko community, I wouldn't expect you to ask this, but if someone else is in attendance, raise the question and report back to us! Jeffrey Minnesota USA ___ 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: CAD files for the case of the Neo will be made available
Wolfgang Spraul wrote: Jeremiah - thanks for the information, that is indeed very helpful. Your list includes DXF, that was the preference before. I am concerned that the export process will corrupt the file and we release a file that will be painful to actually use. From the formats you listed (Wavefront, DXF, STL), which is your preference? Which one do you believe is a format where Pro/E can export all information into, without loosing much? I'm not very familiar with internal structure/format of DXF files, but have written software that uses STL and Wavefront files. I'll answer to the best of my knowledge. The most information would be lost with STL files. DXF files would likely loose the least information and Wavefront would be somewhere between. This is dependent on how good the converters in ProE are. Often only the most basic features of the Wavefront format are implemented in applications and a surface description equal to or only slightly better than a STL file is achieved. This could also apply to DXF files, depending on the quality of the converter and the app that reads them in, but I bet the converter in ProE is pretty good. One issue is there are many versions of the DXF file format. A quick search shows Blender supports a subset of objects up to DXF version 2007. Art of Illusion only loads from ASCII DXF files and is limited to vertex information. Of course as long as the conversion is good loads well for a couple apps, we could do additional conversions on our own. I believe an ASCII DXF format would be more accurate for most people and lose the least amount of information in the conversion. There may be fewer version compatibility issues with Wavefront files, but DXF readers can also often read newer files than they were designed for at a lower level of detail. Jeremiah Thanks, Wolfgang On Jan 17, 2008, at 10:37 AM, Jeremiah Flerchinger wrote: I don't think ProE by itself is suitable, especially since you need a copy of ProE even to import it to BRLCAD. I myself would suggest Wavefront (.obj), ASCII DXF (.dxf), or STL (.stl) file. All are standard formats should be in ProE and any other 3D editor. Instructions for converting from ProE to STL are as follows: ProE * File Export Model * STL * Set chord height to 0. The field will be replaced by minimum acceptable value. * Set Angle Control to 1 * OK ProE Wildfire * File Save a Copy Model * Change type to STL (*.stl) * Set Chord Height to 0. The field will be replaced by minimum acceptable value. * Set Angle Control to 1 * OK* * I'm sure the process would be similar to convert to either of the other 2 formats. Jeremiah Flerchinger* * Wolfgang Spraul wrote: Esben - Interesting. I checked on BRLCAD's website Converting Geometry Between BRL-CAD and other Formats, Page 17 http://ftp.brlcad.org/VolumeIV-Converting_Geometry.pdf and it seems Pro/E import is actually quite solid. However you need a seat of Pro/E to do the conversion. Is releasing in Pro/E format (.prt and .asm files) an acceptable way? Wolfgang On Jan 17, 2008, at 2:36 AM, Esben Stien wrote: Wolfgang Spraul [EMAIL PROTECTED] writes: Regarding the format, the original is in Pro/Engineer Assembly (.asm) and Part (.prt) files. That's probably hard to digest for any FOSS CAD software. BRLCAD[0] has preliminary support for this format. [0]http://brlcad.org/ -- Esben Stien is [EMAIL PROTECTED] s a http://www. s tn m irc://irc. b - i . e/%23contact sip:b0ef@ e e jid:b0ef@n n ___ 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: CAD files for the case of the Neo will be made available
Yes, you did say they were going to try and make CAD files available. I'm happy to hear further confirmation back so soon. Hopefully it won't take too much longer to get the files. DXF files should also be fine. I know of several free editors that can import these natively or with a plugin (although not all of them export dxf files). Do you know if this model has objects providing dimensions for the pcb, screen, battery, other elements? It isn't a problem to wait see, if the release will be occurring soon. I was just curious. Jeremiah Michael Shiloh wrote: Hi Community, Can't remember if I told you this or not, but OpenMoko has decided to make available the CAD files detailing the NEO case. I'm pretty sure the format will be .dxf files. To my limited understanding of CAD, this seems pretty universal and easy to convert to the other formats. We're in the process of getting all the pieces in order. I'll let you know as soon as it is available. Michael ___ 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: CAD files for the case of the Neo will be made available
Shawn Rutledge wrote: What is your favorite Linux CAD tool for actual 3D work? I have to agree with the people that say Blender is a high quality program. For a simple 3D editor I would suggest something like Art of Illusion (http://en.wikipedia.org/wiki/Art_of_Illusion). In my opinion that would would be a simpler application to use before moving to something more powerful like Blender. Can you generate CAM paths with Blender? What type of CAM files/input do you have in mind? I know both Blender AOI support .stl files and a few others. Plugins are available for both. Are you asking about CNC G-code or something else? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Southern California Linux Expo, Feb 8-10 2008
Where did you see that? It wasn't in Current Events-Upcoming events in the Wiki. Too bad I just finished several months in California, won't be going back any time soon (I think) and will miss out on the show in Feb. Anyone know of any other shows coming up in the US that OpenMoko will be at? Jeremiah ian douglas wrote: Hey all, Just saw that OpenMoko is going to be at the SCALE show this year -- can't wait to drop by and meet some of you guys. Got any good giveaways planned? ;o) Ian ___ 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: Videos and pictures of Neo FreeRunner at CES:
The boot graphic could look like the old suggested power off image (http://wiki.openmoko.org/wiki/Look_%26_Feel) or the black plain logo (http://wiki.openmoko.org/wiki/Artwork#Logo_Plain) overlaid with a progress bar and a single line of text that tells the current step of the boot process. Then there would be feedback on the progress of the boot and people that wanted could always switch to the boot scroll. kenneth marken wrote: On Saturday 12 January 2008 07:26:18 Ted Lemon wrote: On Jan 11, 2008, at 3:20 PM, Lon Lentz wrote: I read the not so happy comments following the Gizmodo article. A lot of those comments have been made here on this list. Like the repeated ones about the boot scroll being visible. I thought that was weird. The boot scroll is one of my favorite parts! imo its a much better feature then looking at a boot graphic that never stops looping and wonder why it does not... ___ 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: Community update, January 2, 2008
I would assume the difference to be fiscal vs calendar year. My workplace uses Oct 1st to the start of their fiscal year, with project funding and reseting of vacation time being based around this. For other things we refer to particular quarters of the calendar year. I think expressing things as quarters is acceptable and obvious as long as it was stated as 2nd quarter - calendar year or something similar. I don't care whether months or quarters are used, but think either would be valid to use as the core team sees fit. -J Heilpern, Mark wrote: The difference between fiscal year and calendar year, I suppose? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steven ** Sent: Thursday, January 10, 2008 1:09 PM To: List for OpenMoko community discussion Subject: Re: Community update, January 2, 2008 At my employer, 1st quarter starts October 1st. See what I mean about no standard? -Steven On Jan 10, 2008 10:48 AM, Sébastien Lorquet [EMAIL PROTECTED] wrote: For me, one year is 12 months so one quarter is 3 months, and then: 1st day of 1st quarter = january 1 1st day of 2nd quarter = april 1 and so on... Don't tell us you will release gta02 for the second quarter of 2008 :) Sebastien ___ 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 NOTE: The information in this message is intended for the personal and confidential use of the designated recipient(s) named above. To the extent the recipient(s) is/are bound by a non-disclosure agreement, or other agreement that contains an obligation of confidentiality, with AuthenTec, then this message and/or any attachments shall be considered confidential information and subject to the confidentiality terms of that agreement. If the reader of this message is not the intended recipient named above, you are notified that you have received this document in error, and any review, dissemination, distribution or copying of this message is strictly prohibited. If you have received this document in error, please delete the original message and notify the sender immediately. Thank you. AuthenTec, Inc. http://www.authentec.com ___ 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: Case Schematics
I have no clue why dimensional drawings or 3D models of the Neo haven't been released either. People have been requesting them for quite some time to explore alternate case designs (http://wiki.openmoko.org/wiki/Hardware:Neo1973:Alternate_Cases). I myself would be happy with something as simple as a Wavefront object file, since almost any CAD tool can import these. Joe Pfeiffer wrote: Gabriel Ambuehl writes: On Wednesday 26 December 2007 21:11:18 Michael Shiloh wrote: The main reason IIRC is that some of the chips came with NDAs that prevent us from doing so. You have chips in the case? oOOOo Well, the original request was phrased strangely -- the case wouldn't *have* schematics! Presumably what was meant was dimensional drawings (which also haven't been released, for reasons that escape me). ___ 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: Community Update
Standard Precision Service (SPS) for GPS is open to the general public and all information related to it should be unclassified, although some is For Official Use Only (FOUO). Pres Bill Clinton made a Presidential Decree, when he was in office, that gave undiluted precision of SPS to the public. SPS is presented in C/A code, which is a pseudo-random code, on the L1 band and is separate from military Precise Position Service (PPS). As long as only SPS and C/A code is used there /*should*/ be no problem. The only possible hang-up I can think of is there /*may*/ be a rule that imposes an altitude that consumer gps devices must fail to output positioning data above... but I can't remember. Also a copy of the C/A code or the design of the Feedback Registers that generate the C/A code would have to be obtained. That should be public information though. Any GPS radio used should probably be able to also receive on the L2 band, in case we decide to try and implement our own tropospheric compensation algorithms to improve precision. That isn't too big a deal though, because nav almanac data would be good enough for most cases. -Jeremiah Kyle Bassett wrote: Curiosity prevails: I do see a few benefits to a device which is just a GPS radio, like what Ian has stated. Would their be any legal ramifications to a reverse-engineered open source binary interpreter for the GPS radio? I saw a few people mention government concerns with having access to a very accurate GPS device, but what about Global Locate's license agreement (if any) by using their hardware? I think a GPS radio would make an excellent open source project; allowing access to the specifics of GPS (theory) not available with closed firmware. I wouldn't mind working on this project. -Kyle On Nov 29, 2007 9:46 PM, Ian Stirling [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Doug Sutherland wrote: Mikko wrote: 2) Yes, it can make sense not to have a bazillion CPUs on board from various perspectives. I evaluated no less than 25 different GPS modules some years ago and compared them in all important aspects. Every single one had a microcontroller onboard. I do not agree that it makes any sense at all not to choose one of these types. They are down to the size of a thumbnail almost. Is the microcontroller a CPU, technically yes, but it's part of the receiver, and you want to do all this fancy GUI and not suck the life of the battery from ARM9 usage. It is a good thing they ditched that GPS. It is now standard that any GPS module does have a microcontroller inside, most commonly some variant of ARM7, super low power, you never deal with any firmware. (sorry for the late response) To clarify why it might be nice - yes there are simplicity benefits from just using a GPS with a NMEA output (or at least with that as an option) If the existing hardware had an open-source driver (there was some progress towards such, but this has stalled since it was announced it would not be used in GTA02) then many of these objections go away. The following is based on preliminary work that has not been completed, and due to the lack of work on the current GPS may never be. The device is basically only a software radio, that does the absolute minimum to enable the host to avoid having to do hard-real time stuff, 115200 baud serial is just fine. As I understand it, the following things are possible, which are difficult to do with 'normal' chipsets. Wakeup once every 3 minutes for 1s, to maintain lock on satellites, keeping a reasonable (say 50m) position accuracy, with the GPS totally off in the interim. This (with the mobile phone part off) uses a very small amount of power, enough to track for around 8 months. Logging all parameters of the signal that the chip measures in hardware, so that the track can be post-processed for better accuracy. The option of delaying the output of the signal by 10s+, and being able to smooth the output based on the 'future' movement, not just the past. (this can dramatically improve tracks round sharp corners) Being able to feed in information from the accelerometers to go into the position solution. (this is mainly useful in cars - the accels give you good turn rate info) Using even 'failed' GPS satellites as position sources, with the aid of AGPS (however, this is unlikely to be of use unless the GPS system stops being maintained) Easy tradeoffs between output noise and update frequency - few devices support updates faster than 1Hz. User-provided AGPS correction information. ___ OpenMoko community mailing list community@lists.openmoko.org mailto:community@lists.openmoko.org
Neo1973 drawings - 3D model
I also made a simple 3D model of the Neo1973. It's intended more for drawings illustrations, since I didn't have all the dimensions and the model is a bit rough. If anyone has detailed measurements it would be great if they posted them on the wiki. Links to the model some renderings are on the wiki as follows: http://wiki.openmoko.org/wiki/Hardware:Neo1973:Alternate_Cases#Alternate_Case_Suggestion_Format http://wiki.openmoko.org/wiki/Neo1973_case_schematics -Jeremiah Ryan Lerch wrote: Yeah, if the wiki took SVG, I would have uploaded them there instead of the openclipart library. -Original Message- From: [EMAIL PROTECTED] [mailto:community- [EMAIL PROTECTED] On Behalf Of Shawn Rutledge Sent: Friday, 5 October 2007 10:06 AM To: List for OpenMoko community discussion Cc: [EMAIL PROTECTED] Subject: Re: Neo1973 drawings On 10/4/07, Ryan Lerch [EMAIL PROTECTED] wrote: If anyone is interested, I have uploaded a few simple drawings of the neo1973 to the openclipart library. Cool. I made links on the wiki. ___ 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
