What would be a realistic but challenging level for Bryce announced trophy money for video playback on the Neo1973? Re: h.264 format is now open?
Salve Bryce,*! Some video information given by Sean in november: http://www.openmoko.org/pipermail/community/2006-November/000340.html On Fri, 02 Feb 2007, Bryce Leo wrote: Yeah, for management. Actual Video decoding is done by a dedicated chip, Broadcom BCM2722. Good find. I guess i should have just checked wikipedia instead of googling would have gotten me much better information. I will however still bet $50 (first taker actually gets payout) that there will be a way to play video on the phone. I think your $50 has to go to somebody of the core developer team: [EMAIL PROTECTED] play robs-video.wav ; display robs-video-animated.gif ;) Which resolution and frames/s should have the video to win your prize? In some way a low resolution should run quite soon - for full or have resultion could external hardware help, or a much memory eating pre-decryption... So let us find a realistic but challenging level for your trophy money? I thought about to join with a more symbolic amount of 10 Euro (I'm just a student) but then I thought when 100 people would join and the trophy money is a big prize, maybe the competion would disturb people of charing their first success/ideas... What do you think? Would it better instead of joining the Bryce-video-prize when everybody is looking for an own (symbolic) prize? And what about a deadline to reach it? March 11th + 3 month = June 11h? Who is geeing all the unreached prizes? The Core developer team? Greetings, rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Is vim included out-of-the-box or shall i port?
[Removed the [EMAIL PROTECTED] cross-post] Richi Plana wrote: Oh, i agree that a text editor would be useful on the device given that most options probably won't have a GUI to control them through (at least at the start), but I'm sure the phone already has a text editor component and likely a text editor application. Why use VIM? The only advantages I know that vim has is its keybindings. As far as I know, a keyboard (wired or bluetooth) isn't available and the virtual keyboard won't be much help for the keybindings. ... Mind you, on other platforms where OE works, I'm sure the no keyboard, slow CPU, memory constrained or tiny viewscreen restrictions don't apply. OE is the buildsystem used for the NSLU2-Linux custom firmware, and vim is a very popular package for that platform. The NSLU2 has *no* keyboard, a 266MHz XScale CPU, only 32MB memory, and *no* viewscreen. So *all* those constraints apply. The idea is that you ssh into the embedded device, and then run vim. Or Nano. Or Emacs (which is my preferred editor) :-) (Yes, Emacs runs nicely on an NSLU2) -- Rod Whitby -- NSLU2-Linux Project Lead ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Please no crossposting! Re: Information regarding theMessaging Support in OpenMoko
On Friday 02 February 2007 13:43:52 Dave Crossland wrote: For the recipients who are on Jabber (such as Jabber conversant phones) this is a good idea. For everyone else, MMS as the least preferred but available option is quite neccessary. Tho I do wonder how much GPRS traffic it would generate to constantly be connect to a Jabber server? For people who have flatrate GPRS, this is obviously a very nice solution but for the rest of us it might turn out to be rather expensive? ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Please no crossposting! Re: Information regarding theMessaging Support in OpenMoko
On 02/02/07, Gabriel Ambuehl [EMAIL PROTECTED] wrote: On Friday 02 February 2007 13:43:52 Dave Crossland wrote: For the recipients who are on Jabber (such as Jabber conversant phones) this is a good idea. For everyone else, MMS as the least preferred but available option is quite neccessary. Tho I do wonder how much GPRS traffic it would generate to constantly be connect to a Jabber server? I imagine that low bandwidth proxies will emerge for all kinds of protocols both as the developed-world power users like OpenMoko owners want cheap omnipresence, and as the developing world wants to make best use of very limited bandwidth available. www.loband.org is a web proxy that does this, designed for the 3rd world, and I use it on my mobile often. -- Regards, Dave ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: LiarLiar
On Friday 02 February 2007 13:52:53 Sven Neuhaus wrote: Running LiarLiar (a voice stress analysis tool, http://liarliar.sourceforge.net/ ) on the Neo1973 would be a nice hack, analysing your counterpart on the other end of the line. I'm not sure the phone is fast enough to do the fast fourier transform in realtime, though... Doing the opposite could possibly come useful as well, i.e. normalizing voice in some sort? Possibly piping it through a vocoder (could sound kinda weird though)? So if you give people a weapon like liarliar, you better prepare a defense against it, don't you? ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Please no crossposting! Re: Information regarding theMessaging Support in OpenMoko
On Friday 02 February 2007 14:13:32 Dave Crossland wrote: I imagine that low bandwidth proxies will emerge for all kinds of protocols both as the developed-world power users like OpenMoko owners want cheap omnipresence, and as the developing world wants to make best use of very limited bandwidth available. Well for instant messaging, a very important part of the BW consumed could be keep alive packets for the TCP session for which low bandwith proxies can't really help much and you're at mercy of the NAT timeout of your GPRS provider... ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: LiarLiar, software access to voice data
Crane, Matthew wrote: That's definitely a cool idea. But will the kernel and/or user-space software be able to access and modify the transmitted/recived sound channel? Yes, http://lists.openmoko.org/pipermail/community/2006-December/000733.html confirms access to the microphone, I'm sure there's also access to the incoming audio stream. I think it would also be pretty neat if it was possible to lightly encrypt the voice, making the phone the open equivalent of some much more expensive devices. Why stop at light encryption? -Sven ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Voice over GPRS?
Bit rate=sampling rate x bit depth 1kb/s isn't going to get you too much audio. Try encoding an mp3 at 1kb/s to see how audible that would be. I think you'd be looking at something more along the lines of 32-64kb/s to get anything that you could understand. It might be easier to make a phone call. Conveniently enough, I think the device will have that capacity as well. On 2/2/07, Robert Michel [EMAIL PROTECTED] wrote: Salve! Does anybody has experiances/ideas about Voice over GPRS? How long is the delay? It could maybe used for asyncron voice communication Talk2Talk (instead of pushing a button) In Germany did three Prepaid Provider published new Tariffs with 0.24Euro/MB. German pages: http://teltarif.de/arch/2007/kw05/s24754.html data cost calculator: http://teltarif.de/mobilfunk/datenrechner.html I think with this tariffs using mobil data becomes interesting ;) By using 1KB/s for audio and some overhead, let us say 2 KB/s 0.24Euro/MB = 24 Cent for 500 seconds, 60 seconds makes then about 3 cents. When both using this 6 cents. Hmm that would be interesting when the user makes often make brakes/pause in their talk. Greetins, rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Voice over GPRS?
2007/2/2, Robert Michel [EMAIL PROTECTED]: Salve! Does anybody has experiances/ideas about Voice over GPRS? How long is the delay? I heard it could be pretty lond delay (like a second or more). It is hard to use programs such as skype. Walkie-talkie like solution is very interesting, though. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Voice over GPRS?
* Robert Michel [EMAIL PROTECTED] [070202 17:06]: Salve! Does anybody has experiances/ideas about Voice over GPRS? How long is the delay? It could maybe used for asyncron voice communication Talk2Talk (instead of pushing a button) The lag with E+ for GPRS/UMTS is at best in my experience 300ms, and sometimes goes up into seconds. Please consider also the fact, that GPRS is a low priority service. Hence for GPRS you get the following fascinating list of properties: a) high latency b) non uniform distribution of latency and bandwidth. c) at best analog modem speeds, albeit only download wise, upload wise you are often limited to 1 channel with 9600bps. d) no QoS support So the only sensible voice application over GPRS might be push-to-talk, which by the way is offered by some carries over GPRS :) By using 1KB/s for audio and some overhead, let In many cases you won't be able to upload 1KB/s. us say 2 KB/s 0.24Euro/MB = 24 Cent for 500 seconds, 60 seconds makes then about 3 cents. When both using this 6 cents. Hmm that would be interesting when the user makes often make brakes/pause in their talk. No way you can think of doing sensible full-duplex two way discussions. As an example, take WLAN. VoIP over WLAN works, because the involved bandwidths have a completly different ratio: Most sip providers claim 2x100kilobits/s as requirement, and even 11mbps WLAN has an useable bandwidth of 4-5mbps. Andreas ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Voice over GPRS?
* Terrence Barr - Evangelist, Java Mobile Embedded [EMAIL PROTECTED] [070202 17:56]: VoIP calls typically require approx. 120 kbit/s *each* direction, that's 240 kbit/s for a two-way conversation. UMTS gives you 384 kbit/s if you're lucky. Most of the time it's more like 150 kbit/s, so VoIP will only work with very poor quality. UMTS gives you only 64kbit/s upstream. Andreas ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Voice over GPRS?
On Fri, 2 Feb 2007, Robert Michel wrote: Does anybody has experiances/ideas about Voice over GPRS? See: http://www.cl.cam.ac.uk/~rc277/globe02.pdf They discuss tcp as well as udp performance over GPRS. How long is the delay? It could maybe used for asyncron voice communication Talk2Talk (instead of pushing a button) By using 1KB/s for audio and some overhead, let us say 2 KB/s 0.24Euro/MB = 24 Cent for 500 seconds, 60 seconds makes then about 3 cents. When both using this 6 cents. Hmm that would be interesting when the user makes often make brakes/pause in their talk. Using speex, you'd need 1.6kb upstream. So bandwidth is not the issue. Latency is. The uplink will have between 0-1 sec of latency, so it's not really an issue . Downlink however, commonly has 2 or 3 second latency, ruining voice in an interactive way. In other words, you are probably forced to use a push to talk style conversation, meaning long monologues. And that is in good conditions, with a non-mobile connection. Things will get much worse when travelling, especially in the city with many small cells, as you'll be stuck hopping from cell to cell without actually getting much communication done. Paul ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Voice over GPRS?
On Fri, 2 Feb 2007, Terrence Barr - Evangelist, Java Mobile Embedded wrote: Also, most data plans specifically prohibit VoIP usage and may even prevent it technically. AFAIK, only T-Mobile did that, and they removed that clause a few months ago. Paul ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Voice over GPRS?
* Paul Wouters [EMAIL PROTECTED] [070202 18:18]: On Fri, 2 Feb 2007, Terrence Barr - Evangelist, Java Mobile Embedded wrote: Also, most data plans specifically prohibit VoIP usage and may even prevent it technically. AFAIK, only T-Mobile did that, and they removed that clause a few months ago. Eplus does have that clause too. Plus running standard VoIP protocols like SIP and friends over a NAT firewall that is not cooperating is not possible anyway. So you would need to add a tunnel to some endpoint on the Internet, and add that latency to the bad latency of GPRS/UMTS :( Andreas ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Encrypting voice comunications..
On pe, 2007-02-02 at 09:06 -0800, Tim Newsom wrote: If we have access to the mic and speakers while a call is in process, and we have the ability to record conversations etc... Where does the processor sit in that chain? Can we consume the voice, encrypt it and feed an encrypted datastream back out to the gsm module which would transmit it and another neo1973 user could receive the stream, process through decryption and play out? No. The GSM processor does its own audio de- and encoding, and its connection to the audio i/o is analog, as reported by LaF0rge on irc a while back (any misunderstanding is probably mine if present, though). We can get at the audio via the a/d converters, but not do anything really fancy directly. Thus, I refer you to my last mail; make a GSM data call (phone-to-phone if possible, if not, both dial out and arrange the call via some server), transmit encrypted Speex stream. There would still be a bit of latency, but you would get reserved bandwidth at least. This of course costs extra. Probably one of the principal reasons why GSM chips don't like you sending your own digital data over voice calls. :] -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Voice over GPRS?
Salve Terrence,*! Terrence Barr - Evangelist, Java Mobile Embedded schrieb am Freitag, den 02. Februar 2007 um 17:52h: VoIP calls typically require approx. 120 kbit/s *each* direction, that's 240 kbit/s for a two-way conversation. http://www.asteriskguru.com/tools/bandwidth_calculator.php [*] speex [*] iax2 Incoming Bandwidth Calls: 1 RTP: 4.69 Kbps UDP: 3.13 Kbps IP: 7.81 Kibps Protocol: IAX2 REGULAR Audio Codec: 2 Kbps *IAX2 REGULAR is not using RTP or RTCP! Outgoing Bandwidth Calls: 1 RTP: 4.69 Kbps UDP: 3.13 Kbps IP: 7.81 Kibps Protocol: IAX2 REGULAR Audio Codec: 2 Kbps *IAX2 REGULAR is not using RTP or RTCP! Incoming bandwidth: 14.5 Kbps 0.01 Mbps 1.81 KBps 0 MBps Outgoing bandwidth: 14.5 Kibps 0.01 Mbps 1.81 KBps 0 MBps Total bandwidth (incoming and outgoing): 29 Kbps 0.03 Mbps 3.63 KBps 0 MBps 29Kbps = 3.625 kByte/s VoIP over cellular is just not feasible at this point. I was not speaking about VoIP, I was talking about asyncron voice services like the buzzthingy Push to talk - but I do not whant to push - Talk to talk would be more smart - no need to press a button. Without syncron communication the overhead would be lower On 2/2/07, Robert Michel [EMAIL PROTECTED] wrote: Salve! Does anybody has experiances/ideas about Voice over GPRS? How long is the delay? It could maybe used for asyncron voice communication Talk2Talk (instead of pushing a button) In Germany did three Prepaid Provider published new Tariffs with 0.24Euro/MB. German pages: http://teltarif.de/arch/2007/kw05/s24754.html data cost calculator: http://teltarif.de/mobilfunk/datenrechner.html I think with this tariffs using mobil data becomes interesting ;) By using 1KB/s for audio and some overhead, let us say 2 KB/s 0.24Euro/MB = 24 Cent for 500 seconds, 60 seconds makes then about 3 cents. When both using this 6 cents. Hmm that would be interesting when the user makes often make brakes/pause in their talk. Sorry guys, I was not asking about codecs, I was just asking about delay on GPRS. ;) Should I start again with a more simple example? I will send a voicemessage of 20 seconds to my friend. My Tarrif would cost with 60/1 second counting full 16 Cent. 20 second audio with 2.150 kbit/s will create a file of 43 kbit = 5.375 kByte. 0.24Euro/MByte GPRS traffic with 10KB block will calculate 10 kByte for the message to my frind, this makes 0.0024 Euro = 0.24 Cent for me. So my question would be how much delay will bring a GPRS connection compared with normal internet connections? Greetings, rob Greetings, rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Ok I should write _asyncrone_ Voice over GPRS in the subject from the beginning ... ; )
Salve Andreas! On Fri, 02 Feb 2007, Andreas Kostyrka wrote: * Paul Wouters [EMAIL PROTECTED] [070202 18:18]: On Fri, 2 Feb 2007, Terrence Barr - Evangelist, Java Mobile Embedded wrote: Also, most data plans specifically prohibit VoIP usage and may even prevent it technically. AFAIK, only T-Mobile did that, and they removed that clause a few months ago. Eplus does have that clause too. Who cares? When the communication is asyncron we could store the voice date in one file that even is encrypted... .. when we talking about asycrone Voice over GPRS - voice chat with a little delay... Cheers, rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Voice over GPRS?
On Fri, 2 Feb 2007, Andreas Kostyrka wrote: AFAIK, only T-Mobile did that, and they removed that clause a few months ago. Eplus does have that clause too. Ahh, not too familiar with the German markets. Plus running standard VoIP protocols like SIP and friends over a NAT firewall that is not cooperating is not possible anyway. So you would need to add a tunnel to some endpoint on the Internet, and add that latency to the bad latency of GPRS/UMTS :( that's why our firmware will include both IPsec (with NAT-Traversal) as well as OpenVPN. If that wouldn't work often enough, we'll try and do encapsulation over port 443. But yes, guaranteed in-order delivery of telco networks is really not a very nice basis to run UDP (or TCP) over. Guess the telco world still believes in the OSI model :( Paul ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Encrypting voice comunications..
On Fri, 2 Feb 2007, Mikko J Rauhala wrote: No. The GSM processor does its own audio de- and encoding, and its And echo cancellation. When using any VOIP app, you will need to put in your own echo cancelation code. I listened to the Windows Mobile 5 Skype client, and even that was pretty awfull. You'll need to use a headset. Paul ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Voice over GPRS?
* Robert Michel [EMAIL PROTECTED] [070202 18:26]: Incoming bandwidth: 14.5 Kbps 0.01 Mbps 1.81 KBps 0 MBps Outgoing bandwidth: 14.5 Kibps 0.01 Mbps 1.81 KBps 0 MBps Total bandwidth (incoming and outgoing): 29 Kbps 0.03 Mbps 3.63 KBps 0 MBps 29Kbps = 3.625 kByte/s Looks nice, BUT you don't have always a 14400 bps uplink. Beside streaming VoIP without QoS can only work with an strong oversupply of bandwidth. In the case of GPRS you often have only 9600-14400 bps uplink spped. I was not speaking about VoIP, I was talking about asyncron voice services like the buzzthingy Push to talk - but I do not whant to push - Talk to talk would be more smart - no need to press a button. That seems reasonable. So my question would be how much delay will bring a GPRS connection compared with normal internet connections? Somewhere between 300ms and 10 seconds. (I think I once that over 60seconds ping times in Munich ;) ) Andreas ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Encrypting voice comunications..
So, though possibly inefficient, we could not some how take the analog audio stream, do some predictable and reversible encoding/encrypting then convert into sounds again.. Like doing base64 encoding for binary data.. In that way we are still sending audio information and letting it get encoded by the gsm module. Having access to send audio over gsm could be useful in another way.. Say call your phone and when it answers have it read its location to you via text to speech or something. We must have the ability to do something like that, or how would asterix (sp?) work on the phone? On Fri, 2 Feb 2007 9:29, Mikko J Rauhala wrote: On pe, 2007-02-02 at 09:06 -0800, Tim Newsom wrote: If we have access to the mic and speakers while a call is in process, and we have the ability to record conversations etc... Where does the processor sit in that chain? Can we consume the voice, encrypt it and feed an encrypted datastream back out to the gsm module which would transmit it and another neo1973 user could receive the stream, process through decryption and play out? No. The GSM processor does its own audio de- and encoding, and its connection to the audio i/o is analog, as reported by LaF0rge on irc a while back (any misunderstanding is probably mine if present, though). We can get at the audio via the a/d converters, but not do anything really fancy directly. Thus, I refer you to my last mail; make a GSM data call (phone-to-phone if possible, if not, both dial out and arrange the call via some server), transmit encrypted Speex stream. There would still be a bit of latency, but you would get reserved bandwidth at least. This of course costs extra. Probably one of the principal reasons why GSM chips don't like you sending your own digital data over voice calls. :] -- Mikko J Rauhala [EMAIL PROTECTED] University of Helsinki ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community --Tim ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: What would be a realistic but challenging level for Bryce announced trophy money for video playback on the Neo1973? Re: h.264 format is now open?
Haha well then lets modify this a bit. I think your $50 has to go to somebody of the core developer team: I'm goinig to have to disagree I'll give that money to the developer who does it first and infact i'll send out an email to the dev list as a bounty. Which resolution and frames/s should have the video to win your prize? In some way a low resolution should run quite soon - for full or have resultion could external hardware help, or a much memory eating pre-decryption... So let us find a realistic but challenging level for your trophy money? I'll say 320x240 (for now) stretched to the full screen size and this MUST be at reasonable quality I'll crunch some numbers and come out with a full list of sizes and bitrates. I'll get this posted up today sometime. I thought about to join with a more symbolic amount of 10 Euro (I'm just a student) but then I thought when 100 people would join and the trophy Heh i'm a student to but i've got a decent job and this is most definately worth my 50usd for the amount of enjoyment that the community would get for it. And what about a deadline to reach it? March 11th + 3 month = June 11h? Who is geeing all the unreached prizes? The Core developer team? The only deadline i'd push would be before the second OpenMoko phone comes out from FIC. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: between 300ms and 10s - wow that is asyncron :) Re: Voice over GPRS?
* Robert Michel [EMAIL PROTECTED] [070202 18:58]: Salve Andreas! Andreas Kostyrka schrieb am Freitag, den 02. Februar 2007 um 18:44h: Looks nice, BUT you don't have always a 14400 bps uplink. But even iax2 has a huge overhead - mybe still potential to optimize the protocol? So my question would be how much delay will bring a GPRS connection compared with normal internet connections? Somewhere between 300ms and 10 seconds. (I think I once that over 60seconds ping times in Munich ;) ) wow - so for browsing a proxy could become interesting to preload the next newspages... The problem is that with GPRS you don't have that much bandwidth to do background fetches :( (EGPRS/EDGE would be a different thing) Plus people pay for these bandwidths in most places on this planet :( Plus, the 10secs was a maximum value that I've encountered multiple times. With GPRS the latency most often sticks below the 2secs bracket, but 10secs do happen from time to time. UMTS is, IMHE, worse :( Andreas ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
What more to add to http://www.linuxtogo.org/gowiki/OpenMoko/GPRS ? Re: Voice over GPRS?
Salve Paul! Paul Wouters schrieb am Freitag, den 02. Februar 2007 um 18:13h: On Fri, 2 Feb 2007, Robert Michel wrote: Does anybody has experiances/ideas about Voice over GPRS? See: http://www.cl.cam.ac.uk/~rc277/globe02.pdf Thank you, I direcly put this good source into our wiki :) Sorry for switching now to GPRS general: For the GPRS connection in general would be more interesting: - firewall on the Neo - what is with GPRS push services? - how to count the GPRS traffic (to count equal to the provider) - a limitation of data/hour data/day data/week data/month with user warning - statistic for GPRS traffic use - for prepaid cards automaticaly checking the prepaid credit/money on account -- before and after calls -- each day/hour or each 10MB GPRS traffic And just an idea in case that the Neo has only GPRS class B: Using another old GSM mobil with GPRS and Bluetooth - so using Internet connection while phonig whith the help of the second phone. BTW do you think two low quality phone connecitons would be possible via 9600 Baud? Greetings rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Let us un-stub http://en.wikipedia.org/wiki/First_International_Computer an then translate it!
On Fri, 2007-02-02 at 11:03 +0100, Robert Michel wrote: Salve Michael! On Fri, 02 Feb 2007, Michael 'Mickey' Lauer wrote: I also never realized that FIC is not just some little startup That makes it a lot more likely that they will still be around for V2 to get released, and for V1 to actually work. I'm kind of surprised that FIC means so little to a lot of people I'm talking. Just look http://de.wikipedia.org/wiki/FIC or in anny other languages then english. I wrote Sean yesterday an email and pleased to add some more intresting stuff to: http://en.wikipedia.org/wiki/First_International_Computer Official is this article count as: This computer-related article is a stub. You can help Wikipedia by expanding it. FIC was well-known to be a manufacturer of solid x86 motherboards back in the 80s. Perhaps most people weren't into computers back those days? ;) Could it be that to much production for other brands weaken the popularity of the brand FIC? End users are brand orientated, but IMHO this doesn't count... for us it is important the quality of the hardwareproduction and I have a feeling that FIC is a very good choice. So before the wave on media response about the Neo we should help with spreading some more informations about FIC - some more details, some pictures... Maby the decision of FIC to join/support/drive the OpenMoko/Neo1973 project and to develop and produce the Neo1973 could bring a popularity/image benefit for FIC? ;) Just beside of the chance of profit with selling Neo1973s? So expanding of http://en.wikipedia.org/wiki/First_International_Computer would help. Greetings, rob This is a good idea. I added my first stab...a link to OpenMoko :) I think OpenMoko will be the most notable product from FIC in the US this year (at least) :) Jon ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community -- Jon Phillips San Francisco, CA USA PH 510.499.0894 [EMAIL PROTECTED] http://www.rejon.org MSN, AIM, Yahoo Chat: kidproto Jabber Chat: [EMAIL PROTECTED] IRC: [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Any alternative ideas to fullscreen popup-messages?
Jason Weathered skrev: With regards to accidental clicks, I have a couple of ideas: * Two taps at opposite corners or opposite edges to unlock. * A quick left/right/left triple tap or left-right-left drag action in the middle of the screen. * Apple's iPhone has a slide to unlock. A continuous left to right action over a certain region unlocks the phone. Since the display isn't pressure sensitive I'm not sure of that yet... resistive display can't do multi touch, but they might be pressure sensitive... or rather can do 'area pressed size', witch can translate to pressure for a soft tip like a finger. I think any of these options would probably work. Can we have all of them? :) Might be good enough... But choosing *one* limits the risk of 'false positive'. You could integrate it with some pin code function... You strike a self defined pattern to unlock the phone. Just as an example... split the screen 9 equal parts like a keypad. A strike starting at 3 and ending at 5 equals 35, a tap at 7 is a stroke starting and ending in 7 so equals 77. Than You can get a 4 digit pin in two strokes/taps. an 8 digit pin in four strokes. Say You have to enter the right strokes within 5 sec to unlock the phone. The phone unlock when You lift Your finger after the last stroke, so Your stroke can not interfere with any app runing. Now I start to feel safe that my pocket can't crack the phone :-) But the strokes must be possible to enter with one hand without visual contact... so the details might need to be different... Think I need to have the neo in my hand to really 'feel it out'. /LaH ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Crytped calls through 9600Baud GSM-data connections?
On Fri, 2 Feb 2007, Robert Michel wrote: Did you discussed OTP, using less mobile device batterypower to add to the voicestream to build an encrypted connection between on users mobil and his homeserver? Nope. In general, devices these days have enough cpu power to just do AES. CPU isn't the limiting factor, latency and/or bandwith are. (for voice encryption at least) I thought about that maybe GSM-data connections with 9600Baud would be interesting: -would piping through such a connection possible without TCP or other overhead? If you do a gsm dat call, you can of course run your own protocol like cryptophone does. But I want to try using just a standard ppp/ipsec connection. Again, I think devices are fast enough and latency is more of a problem then bandwidth, so this approach seems much easier to implement then a custom serial/crypto protocol. This GSM data connection is used by every commercial cryptophone and avoid the delays of GPRS... Yes, that is what cryptophone is using. PS: I made advertisement on this list for your presentation in Berlin, and that this video is no online - but good that mention that it is online again - it worth for the most here on the list to see it. I moved some files and removed the ASF file in favour of the mp4 file, since the ASF file caused a lot of problems for people to get to play. Paul ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Voice over GPRS?
On Fri, 2 Feb 2007, Mikko Rauhala wrote: Of course, you can make a GSM data call (I presume) and thus reserve That's what www.cryptophone.de does to avoid latency issues. Some networks block mobile to mobile data calls though. Righto, so somebody's doing it already on free software. Good for us all :) cryptophone's phone cost 1500 euro. It's not free software. The source has been published for peer review, but you're not allowed to use it on your own phone. I was referring to simply that the carrier will likely charge extra for data calls (in comparison to voice calls). Though now that I check the figures, they _have_ come down at least here since last I checked. Which was a while ago. Well, most offer a $100/month or so flatrate. It's expensive, but if all your calls are going through a cheap SIP provider and your asterisk to your GPRS connection, your *voice* calls would go down to $0/month. Then, $100 for unlimited voice calls isnt that expensive. Paul ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Crytped calls through 9600Baud GSM-data connections?
Salve Paul! Paul Wouters schrieb am Freitag, den 02. Februar 2007 um 20:43h: On Fri, 2 Feb 2007, Robert Michel wrote: Did you discussed OTP, using less mobile device batterypower to add to the voicestream to build an encrypted connection between on users mobil and his homeserver? Nope. In general, devices these days have enough cpu power to just do AES. CPU isn't the limiting factor, latency and/or bandwith are. (for voice encryption at least) CPU isn't maybe a limiting factor, I thought about the batterypower :) And OTP would give an latency advantage as well. ;) -would piping through such a connection possible without TCP or other overhead? If you do a gsm dat call, you can of course run your own protocol like cryptophone does. My question is, would it be possibe to run 2 low quality phone calls via one GSM data connection with speex? Or when not having a second phone call, the connection could be used for data transmission. PS: I made advertisement on this list for your presentation in Berlin, and that this video is no online - but good that mention that it is online again - it worth for the most here on the list to see it. I moved some files and removed the ASF file in favour of the mp4 file, since the ASF file caused a lot of problems for people to get to play. But there are also other mirrors... see my mail and my downloadscript: http://lists.openmoko.org/pipermail/community/2007-January/001561.html Greetins, rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: http://en.wikipedia.org/wiki/Wiktionary Re: Translators needed?
I'm coming into this conversation late, as I just joined the mailing list, but I think I can offer a more general perspective on translation. My wife, and many of her colleagues, are not native English speakers. They are all highly educated (PhD) and, among the entire group, speak several languages including English, Malay, Mandarin, Kadazan, Tagalog, Japanese, Arabic, Spanish, French, German, Hindi, Tamil, and Russian. As you might have guessed, my wife is a linguist at a major university. My enthusiasm towards Open Source Software has at least piqued their curiosity and I've brought up the idea of translation. Some of them would be willing to consider doing voluntary translation for products that would benefit less-advantaged kids. The context for my discussion was OpenOffice.org, but would easily apply to other products. The point I'm getting at is that I don't think there are many professional translators, but there are many people with the same qualifications. They just didn't choose to become translators. On 2/2/07, Marnix Klooster [EMAIL PROTECTED] wrote: Op 31-01-07 15:22, Robert Michel schreef: Salve Engin! On Wed, 31 Jan 2007, Engin Erenturk wrote: In my opinion the translations must be done professionally for such a product like this. Instead of volunteers who are not professionals, volunteers who are professionals and volunteer who can provide a professional translation must localize this product. I localized RSSOwl into Turkish, and I gathered 3 of my friends and discussed every one of the phrases translated. But in the end it is not like a professional translation. It's very important to give the same meaning of the sentence in the localized language instead of pure translation. Sometimes it is very hard to do such a thing. The best example is the Microsoft products, even I don't support or like them, they did great job in localization... They got a big book of meanings of words/phrases which are used in Microsoft products, books etc. If someone wants to do a translation for the books etc. they gave this didctionary to them to use it as reference dictionary... As I said if there are volunteers who are professionsals and who can localize it with professionals must be found... I'll try to get in touch with a professional translator who is experienced in technical translations if there is a need for Turkish localization. I would like to disagre. Open translation has the big advantage that people could give feedback about the translations - many opensource projects include the wikipedia are working without the support of professional translators. Getting in touch with professional translators would help in some rar cases of doubts/dispute. IMHO more important is that the people who translate does know what the software device do at that moment. Hi Rob, First, as Engin already wrote in another response I think, open and professional are not opposites. His suggestion is, if I understood him correctly, to find volunteers who are already software translators professionally. Also, yes you are correct that many opensource projects [...] are working without the support of professional translators. And it shows. I absolutely do not intend any disrespect with that-- I'm really very grateful to the people (volunteers mostly) who make OpenOffice, GNOME, Evolution, Thunderbird, Firefox, etc. etc. available in Dutch on my home Linux box, so that also my wife can use the system comfortably. However, there definitely are many problems: inconsistencies between applications, inconsistencies with Microsoft software (yes, unfortunately this is important), different views of translators (most keep the English website, some translate it to the horrendous neologism webplek), missing translations because the translation could not keep up with new releases of the application, etc. Such problems are minor, in the sense that they usually do not block understanding of what is going on, what should I do next, etc. But they make the experience less polished and more botched. And for a device that we want in lots of non-developer hands, we need polish. Translation is a thing that Microsoft does really well, as far as I've seen. In my opinion, the officially-blessed-by-OpenMoko software feed also should aim for a high level of translation quality, consistency, and completeness. So again, professional volunteers are welcome :-) Groetjes, Marnix ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Other uses for the gsm/gprs hardware....
While the phone is not on a call, can we use the gsm audio codec or other hardware/software to do useful work? For instance, decoding of some audio file or something like that. I know we don't have access to the bare metal of the chip, but its probably at least an arm processor with some dsp or something right? I would think it could be useful in some way other than just phone calls/data transfer. --Tim ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Other uses for the gsm/gprs hardware....
Salve Tim! On Fri, 02 Feb 2007, Tim Newsom wrote: While the phone is not on a call, can we use the gsm audio codec or other hardware/software to do useful work? For instance, decoding of some audio file or something like that. Yes but not with the GSM IC - the Neo1973 itself has a quite powerfull audio IC, to be accurate, wolfson WM8753 - see Seans mail: http://lists.openmoko.org/pipermail/community/2006-December/000737.html I know we don't have access to the bare metal of the chip, but its probably at least an arm processor with some dsp or something right? I would think it could be useful in some way other than just phone calls/data transfer. Of course ;) we had already several normal or freaky ideas what to do with it. Sorry that not every idea is in our wiki yet.. but we have our mailarchive. Just see the Neo as a mobil (embedded) computer + Linux + GSM/GPRS + AGPS + Bluetooth Have you had something special in mind to do with the audio IC? Greetings, rob ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: music applications: piano, drum, bell...
You're right, the first version will not be able of it. But in the V2 (2007-09-11), on the basis of this link (http://cs.nyu.edu/~jhan/ftirtouch/), I think that it will be possible :-) Quotation: Our technique is force-sensitive, and provides unprecedented resolution and scalability... But I don't know if it will use exactly the same technology. Could anybody confirm it? Regards, Le mardi 30 janvier 2007 à 19:36 -0800, Christopher Heiny a écrit : On Tuesday 30 January 2007 18:39, kkr scribbled in crayon on the back of a kid's menu: I am not sure to well understand how works this new screen generation (multi-point touch screen)... Can he discern the force of pressure exercised with the finger over the screen (weak, normal or strong)? Can anybody confirm it? I do not believe that can be done with the resistive screen on the V1 system. ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: Idea for one of the next Neos: Projecting the display via LEDs
Le dimanche 21 janvier 2007 à 19:01 +0100, Ulrik Rasmussen a écrit : On Sunday 21 January 2007 18:46, Wil Chung wrote: Dr. H., I agree that it needs a beam scanner, on first though, but does it have to be mechanical? I know you can direct radio waves with something like a phase array, might not light be directed with a phase array? I don't know, as it's just a guess since they're both EM. I don't think it is possible to bend light, so you'll probably need some sort of mechanical device for it. However, I stumbled on this some times ago, which seems to fullfill the needs: http://news.bbc.co.uk/2/hi/technology/5359724.stm It's basically a red and blue laser diode, aimed at a very tiny vibrating mirror. The problem is, as the article says, that they can't use green diodes, because these aren't small enough. I don't know the technical details for this obstacle though. Red and blue should be enough for text though, at least you will be able to render red, purple and blue. This article (19 September 2006) seems to be already obsolete, look at this one (4 January 2007): http://phx.corporate-ir.net/phoenix.zhtml?c=114723p=irol-newsArticleID=946694highlight= or this one (unfortunately, in French): http://www.netppc.com/shownews.php3?n=1314 It would seem that problem is resolved :-) Regards, ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
Re: AT commands (Re: But wich GSM chip? Re: AT commands document (Was: Fax modem? Fax software? Neo as T.38 gateway?))
On Wed, 2007-01-31 at 12:04 +0100, Harald Welte wrote: On Tue, Jan 30, 2007 at 09:11:53AM -0800, Dimitris Kogias wrote: Sean Moss-Pultz wrote: On 1/31/07 12:32 AM, Robert Michel [EMAIL PROTECTED] wrote: So can you say us already a little more about the GSM chip? Sure. We're using a Ti Calypso chipset. Unfortunately this stuff is all under _super_ NDA :-( Isn't the AT-capable port going to be available to userland via a serial abstraction? If so, its AT command profile won't be a secret very long. there's nothing secret about that AT command profile. The chipset supports all of the mandatory ETSI GSM TS 07.07 commands (use http://pda.etsi.org/pda/queryform.asp to get it), plus some of the optional ones. This GSM standard even has a command that lists the list of available commands (AT+CLAC). See attachment. There are some vendor-specific, proprietary TI AT commands which will remain undocumented. But none of them are required for regular phone usage (including SMS, MMS, FAX, GPRS, Voice Call, Data Call (CSD), etc.) So I really don't understand all this fuzz. It's really very much standard compliant. Wild guess: some of vendor-specific, proprietary TI AT commands allow user to write/read GSM module flash. This is probably illegal in many countries. No surprise whole datasheet is under super NDA ;-) -- Aloril [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org https://lists.openmoko.org/mailman/listinfo/community
