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?
> > >
not to do any parade-raining... but remember to that the ipods run some kind
of dedicated OS (VXWorks?) we still have to deal with overhead for the
OS... you can crank up the process priority, but at the expense of the other
processes (what happens when a call comes in and the GSM daemon gets sta
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
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
On Fri, 2007-02-02 at 17:21 -0700, Richi Plana wrote:
> On Fri, 2007-02-02 at 23:21 +0100, Koen Kooi wrote:
> > Right, there's one snag: tinymail uses its own forked little version of
> > EDS, so if you use
> > tinymail + openmoko PIM, you will have *2* copies of the EDS libs on your
> > device :
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
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
Salve Vincente!
On Sat, 03 Feb 2007, Vincente Aggrippino wrote:
> I'm coming into this conversation late, as I just joined the mailing
> list,
Then welcome to our openmoko community :)
> but I think I can offer a more general perspective on
> translation.
:)
> My enthusiasm towards Open Source
Le mercredi 31 janvier 2007 à 17:51 +0100, Ortwin Regel a écrit :
> It's not difficult to understand but I think it's not a very intuitive
> idea. Ideally future OpenMoko devices would have multitouch which
> would get us very intuitive zoom and movement along the map. Using an
> accelerometer to c
Le jeudi 01 février 2007 à 17:31 -0700, Knight Walker a écrit :
> On Fri, Feb 02, 2007 at 12:57:22AM +0100, Richard Bennett wrote:
> > Hi,
> >
> > There's 2 apps I think would be really usefull:
> > SMS Remote Control.
> > Allow the NEO user to record a 'macro', like 'Call number in
> > spe
pe, 2007-02-02 kello 09:54 -0800, Tim Newsom kirjoitti:
> 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 w
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 languag
Now there is some most promising news, sound like with some simple
optomizations for scaling that this shouldn't be too difficult eh? I
put the full post about the bounty to the Dev maliing list. but the
link to the wiki page is
http://www.linuxtogo.org/gowiki/OpenMoko/Video_Bounty
That's the curr
On Friday 02 February 2007 12:31, Robert Michel wrote:
> Some video information given by Sean in november:
> http://lists.openmoko.org/pipermail/community/2006-November/000340.html
A few technical questions here. Is image data constantly transferred to LCD
from system memory (60 times per second)
pe, 2007-02-02 kello 20:51 +0100, Paul Wouters kirjoitti:
> On Fri, 2 Feb 2007, Mikko Rauhala wrote:
> > 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,
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?
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 so
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 th
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 conti
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
> > > re
pe, 2007-02-02 kello 19:14 +0100, Robert Michel kirjoitti:
> BTW do you think two low quality phone connecitons would be possible
> via 9600 Baud?
Pushing it, but if you don't run it over IP and rather have the same
software on both ends of the data link and therefore cut out all but the
most simp
pe, 2007-02-02 kello 18:28 +0100, Paul Wouters kirjoitti:
> On Fri, 2 Feb 2007, Mikko J 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 thou
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 :)
* 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?
>
>
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
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
encod
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
> > con
With a point to point link what would be the minimal software stack
needed? There's only so much CPU, might it be more appropriate to use a
relatively lightweight process to rx/tx+encrypt/decrypt the data?
In any case, the idea of an open encryption standard for cell phone
communications is pre
Salve Paul!
On Fri, 02 Feb 2007, Paul Wouters wrote:
> 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.
Did you discussed OTP, using less mobile device batterypower to add
* 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.6
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.
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
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 techni
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
On Fri, 2 Feb 2007, Mikko J 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.
> (Also, _this_ is how you can accomplish a proper encrypted phon
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 datast
* Paul Wouters <[EMAIL PROTECTED]> [070202 18:16]:
> 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 dela
* 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
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
__
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 (
the openmoko uses syncml for it's synchronization protocol. This is really
cool since there's several sync clients for just about anything you need,
(local and OTA sync). I ran a quick google search for google syncml and got
several plugins/clients back on the first page, so I think you should b
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
On pe, 2007-02-02 at 11:37 -0500, ROB wrote:
> 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.
mp3 isn't designed
On Fri, Feb 02, 2007 at 11:37:59AM -0500, ROB wrote:
> 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 th
* 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,
Salve ROB!
ROB schrieb am Freitag, den 02. Februar 2007 um 11:37h:
> Bit rate=sampling rate x bit depth
>
> 1kb/s isn't going to get you too much audio.
I wrote 1KB/s and I meant 1kB/s, or 8000 baud.
Already tested quality=0 speex and iax succsessful.
Maybe I did something wrong but this giv
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.
Also, most data plans specifically prohibit VoIP u
* 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 experie
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, th
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 c
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/
On Friday 02 February 2007 14:28:09 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? I think it would also be pretty neat if it was possible to
> lightly encrypt the voice,
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 the
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 band
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? 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 d
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 fouri
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 neccessa
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 genera
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...
-Sven
[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 likel
On 01/02/07, Paul Jimenez <[EMAIL PROTECTED]> wrote:
I think a good Jabber client could totally supplant MMS
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.
So
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
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 mean
63 matches
Mail list logo
