Re: GTA04 openness/freedom (was GTA04 Group Buy - Status)
Hi Michael Well I for one would like a smartphone with completely open software - if an open implementation of baseband code also led to an improvement in user experience on the freerunner, that would be a bonus. Like you, I'm not too concerned about rules imposed on us by large corporations, if the code is good, they will not know their rules are being broken. I can understand that the calypso currently is the best chance to achieve this; it is nice to imagine this will be done and then act like a trojan to open the gates wide for other projects. I've no knowledge of how to code directly to hardware, so I'm never going to be more than a bystander, at least not until the stage was reached where testing could be done. I have no clue whether what you say, about people in the free software camp witholding code/information from you is a fact. As I bystander, if it were true it is dissappointing, although I think you have gone about this in a very sub-optimal way and that you should step back and consider how to approach people who may (or indeed may not) be able to help you. Best wishes -- David Matthews m...@dmatthews.org ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA04 openness/freedom (was GTA04 Group Buy - Status)
Radek Polak wrote: > i am rather saying: > (shortage of existing GTA02 units) -> (GTA04 is the solution) It is *a* solution for some classes of users. It is not *the* solution for all use cases. > Also pool graphics performace of GTA02 make the user experience very bad - > hardly acceptable for normal users and this is fixed in GTA04 and that's one > more reason to upgrade. Fancy graphics is something I couldn't care less about. I would be quite happy with the most bare-bones UI which should be implementable just fine on the GTA02, producing responsiveness no worse than my ancient Mot V66. Instead what I want is an everyday cellphone that does voice calls, SMS and CSD, and does so using software and firmware for which I have access to inspectable and recompilable source, be it legal or illegal. I'm currently in the process of trying to acquire a TSM30: that may be the right phone for me, given that my GTA02 is currently a paperweight due to the lack of an army capable of invading Germany and prying the Closedmoko fw semi-src from its hoarders. I should be able to acquire at least one TSM30, but I'm hoping to be able to find at least two: since no TSM30 schematics are available (I don't know whether it's because they've never been released in the first place, or if they are available in some obscure location and those who know that location are selfishly refusing to point me to it), I will probably have to reconstruct them by taking an actual TSM30 PCBA and sending it to a professional PCB/PCBA reverse engineering lab where they would remove all components, separate and image the layers of the PCB or whatever they do to reconstruct the netlist and the layout of inner layers. Unfortunately that process requires destroying at least one PCBA. :-( Of course hiring a professional PCB/PCBA reverse eng lab is devilishly expensive, but it should still be less expensive than hiring the kind of people who could help me recover the semi-src I'm looking for by some brute-force means... Not to mention the cost of restructuring my life to avoid ever visiting any country that does extradition... What would I do if someone was willing to release an anonymous copy of the GTA0x (or Leonardo baseline) Calypso fw semi-src, so that instead of expending 100% of my life-force to recover that jewel I could actually do something productive? Well, in that case I would start by taking my GTA02 out of the box in which it came, and putting my own very simple distro on the Samsung application processor. I would then bring up the Calypso, using the knowledge of its code to understand the process better. Maybe even find and fix a bug or two in that Calypso fw in the process. After bringing up my own distro on the GTA02 that uses built-from-src code for both the AP and the BP, I would quite seriously consider building my own replacement PCBA just like Dr. HNS did. If he and his team could do it, why can't I? Expect that my hw design goals and target audience would be quite different. I would keep the Calypso, no UMTS, but possibly make it quad-band, copying the quad-band GSM RF front-end from the Leonardo+ schematics - if I can find a place to get that little passive component. While I have no problem with the Samsung AP on the GTA02, I realize that the component is most likely unobtainable. But since I would be targeting a user base for which the part that really matters is the BP rather than the AP, I don't really care which AP to use. Perhaps I would borrow the OMAP AP from the GTA04, or maybe find some significantly cheaper really basic AP that can do the absolutely minimal functions I expect from it. And I would most certainly omit the features/components/complexity that is of no interest to me: WiFi, BT and the accelerometer/etc sensors. The result would be a device meant to be a *phone*, not something else. But I'm not going to put any more serious thought into that project until and unless I can obtain the source or semi-src for the Calypso fw, i.e., either a GTA0x/Leonardo/other non-TSM30 version or some docs for the TSM30 which would make that already-available source version a more viable starting point. > I am not saying that everyone should upgrade. I would personally wait a bit > until i knew that the power management in GTA04 will be working - without > that the it's not much usable as phone (i.e. charging twice a day is not > comfortabe and will kill your battery soon). But it's up to anyone to > collect objective information and decide. PM issues are one of the major reasons why the absence of src/semi-src for the Calypso fw is making my GTA02 serve as a paperweight. From what I understand, the engineers at Openmoko-Inc took the Leonardo baseline code and made their own adaptations to it. One of the latter was the addition of the GPIO signal by way of which the BP wakes up the AP on certain conditions - an incoming call being the prime example, one would hope. I've heard that they were dea
Re: GTA04 openness/freedom (was GTA04 Group Buy - Status)
On Friday 02 of December 2011 17:53:15 msoko...@ivan.harhan.org wrote: > So I still disagree with your reasoning chain of > > (shortage of existing GTA02 units) -> (GTA04 is the only solution) i am rather saying: (shortage of existing GTA02 units) -> (GTA04 is the solution) Also pool graphics performace of GTA02 make the user experience very bad - hardly acceptable for normal users and this is fixed in GTA04 and that's one more reason to upgrade. I am not saying that everyone should upgrade. I would personally wait a bit until i knew that the power management in GTA04 will be working - without that the it's not much usable as phone (i.e. charging twice a day is not comfortabe and will kill your battery soon). But it's up to anyone to collect objective information and decide. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA04 openness/freedom (was GTA04 Group Buy - Status)
Radek Polak wrote: > With my wooden case i had fully working phone - only single part > that was from GTA02 was the speaker + microphone. I really dont > think this is big problem. Yes, and if I wanted to do the same thing (use a self-made wooden case), I could have done it just as well with my own APH01 PCBA (quad-band Calypso based on the liberated Leonardo+ schematics) rather than GTA04. So I still disagree with your reasoning chain of (shortage of existing GTA02 units) -> (GTA04 is the only solution) MS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: GTA04 openness/freedom (was GTA04 Group Buy - Status)
On Friday 02 December 2011 05:26:16 msoko...@ivan.harhan.org wrote:
> But seriously, swapping PCBAs between GTA02 and GTA04 is a zero-sum
> game. The number of existing {case + LCM + GSM antenna + other bits}
> sets is finite, and it stays the same whether you leave the original
> GTA02 PCBAs in those cases or replace them with GTA04s.
With my wooden case i had fully working phone - only single part that was from
GTA02 was the speaker + microphone. I really dont think this is big problem.
Regards
Radek
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: GTA04 openness/freedom (was GTA04 Group Buy - Status)
Radek Polak wrote:
> What's the point in investing time into device that is no longer manufactured
> and the number of users is decreasing to zero?
If it is so worthless in your eyes, why are you (not Radek personally,
but some others in this community) guarding that "moko" fw src/object
code so zealously? Why are you so unwilling to brighten up at least
one person's life by having some anonymous account upload a copy from
some public WiFi hotspot?
> Did you realize that very soon you will loose the freedom to buy GTA02?
Well, I've already got mine. :-)
But seriously, swapping PCBAs between GTA02 and GTA04 is a zero-sum
game. The number of existing {case + LCM + GSM antenna + other bits}
sets is finite, and it stays the same whether you leave the original
GTA02 PCBAs in those cases or replace them with GTA04s.
And if someone solves the problem of existing case shortage by making
a new case and starts selling full GTA04s with cases, perhaps I'll
make my own Calypso-based PCBA to stuff into those new cases. I've
been thinking about using Leonardo+ schematics (quad-band Calypso
reference board) as my starting point, including the quad-band GSM RF
front-end, and slapping some simple application processor in front of
it, whatever is most readily available. Maybe even the same OMAP
which Dr. HNS has used in the GTA04 - I don't really care what the AP
is as long as it can run Linux with full source, but I want the GSM
part to be Calypso, because it's the best-understood cellular baseband
chipset from the hacking standpoint.
MS
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
Re: GTA04 openness/freedom (was GTA04 Group Buy - Status)
On Thursday 01 of December 2011 20:09:02 msoko...@ivan.harhan.org wrote: > Dr. H. Nikolaus Schaller wrote: > > it is obvious why the open and free software community needs > > a device where every individual has control over the software. > > But isn't the GTM601 GSM/UMTS modem in the GTA04 just as closed as any > other? How is then GTA04 an improvement over GTA02 in terms of > openness/freedom? If anything, it's a step backward from the GTA02 in > terms of openness/freedom: at least for the GTA02's Calypso the free > world already has free physical access (legalities aside, please) to > full hw documentation for all guts of that chipset and to the fw > source for a different Calypso phone (TSM30) which may some day be > back-ported to Leonardo/GTA02. For the GTM601/GTA04 we don't have > even that. What's the point in investing time into device that is no longer manufactured and the number of users is decreasing to zero? Did you realize that very soon you will loose the freedom to buy GTA02? This freedom is much more important than some leaked docs for modem firmware. Regards Radek ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
GTA04 openness/freedom (was GTA04 Group Buy - Status)
Dr. H. Nikolaus Schaller wrote: > it is obvious why the open and free software community needs > a device where every individual has control over the software. But isn't the GTM601 GSM/UMTS modem in the GTA04 just as closed as any other? How is then GTA04 an improvement over GTA02 in terms of openness/freedom? If anything, it's a step backward from the GTA02 in terms of openness/freedom: at least for the GTA02's Calypso the free world already has free physical access (legalities aside, please) to full hw documentation for all guts of that chipset and to the fw source for a different Calypso phone (TSM30) which may some day be back-ported to Leonardo/GTA02. For the GTM601/GTA04 we don't have even that. MS ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freedom Redfined.
Hi Steve, That's great news. It sounds like you're not giving up on something you love, so good for you! I guess we'll find out once you make more announcements and get your website up, but I'm curious how this impacts the need for the community to create an organization. It sounds like a community organization might not be such an urgent need if your new company will be hosting some or all of the community projects. If that's the case count me a little relieved. A community organization might still be a good idea to complement your plans, but creating it will probably take a lot of time. I still want to help, but I can really only commit to it part time. Good luck and keep us posted! Jeremy On Mon, Jun 22, 2009 at 2:25 PM, Steve Mosher wrote: > Community, > As many of you know may 25th was my last official day at Openmoko. > Since that time I have been focused on two > things: First, putting my Openmoko business in order. There were several > tasks that got cut off midstream by the layoff > and I felt I owed it to the community to see those jobs through to some > sort of conclusion. Having relied on volunteer work > from the community for so long, it only seemed right that I contribute. > I wanted to see the buzz fix program successfully > implemented both in the EU and in North America. With help from Dr. > Schaller, SDG, and Sean I was able to get that > done. Next on my list was the GTA02 core project. When we canceled the > GTA03 Werner and others started a community > effort to do a phone design that was completely community driven. That's > no small task, but it keeps the dream alive so > I will continue to support it. On that front, we have met with some > success. Building Open Source hardware requires money > at some stage, money to buy parts and money to build prototypes. > Openmoko has graciously agreed to donate some components > to the project and I've put Werner in contact with people who can help > with the prototype runs. It's still early and there is a > lot of work to do, so pitch in if you can. I also wanted to see the > foundation work kicked off. And lastly I tried to find some of my > Openmoko friends employment which brings me to the second major thing I > have been working on: Starting a new company. > Wolfgang has alluded to this in a previous post and now is a good > time to let you > all know what we have been up to since late May. In the coming days as > we get the web page together and lists set up > I'll make some announcements and blog about the company and its > mission. The key elements are 1. Using existing hardware rather than > designing new hardware. 2. Focusing the software effort below the user > levels, 3. targeting the linux developer community. The most important > thing from our perspective is that there is no conflict with OM. > Wolfgang and I met with Sean on Saturday and explained our plan. OM will > focus on Project B so there won't be any conflict. We also agreed that > in the future the two companies will be able to find ways to work > together with OM perhaps picking up some of our products and applying > their focus-- Industrial design and user interface. > I'll be back to announce the name of the company in the coming week > or so as we build out the web page. You can write me > here or at my personal gmail account. (moshersteven@) > > Best Regards All, > > Steve. > > > ___ > 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: Freedom Redfined.
On Tue, Jun 23, 2009 at 2:32 AM, Risto H. Kurppa wrote: > Indeed, we're interested to see where this will take us. > > Please try to do it better this time with the community! > I wish you all the best luck. Its so nice to know that OM will get more strong backing because the community has matured but without a company backing, its not easy to manage things. Wish you best of luck and we will do as much as possble. Keep it up. > > > > r > > > > -- > | risto h. kurppa > | risto at kurppa dot fi > | http://risto.kurppa.fi > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > -- Shaz ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freedom Redfined.
Indeed, we're interested to see where this will take us. Please try to do it better this time with the community! I wish you all the best luck. r -- | risto h. kurppa | risto at kurppa dot fi | http://risto.kurppa.fi ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Freedom Redfined.
Wow !!! I'm very curious to listen more. I wish you a bright future for you and your new company. Giovanni On Mon, Jun 22, 2009 at 8:25 PM, Steve Mosher wrote: > Community, > As many of you know may 25th was my last official day at Openmoko. > Since that time I have been focused on two > things: First, putting my Openmoko business in order. There were several > tasks that got cut off midstream by the layoff > and I felt I owed it to the community to see those jobs through to some > sort of conclusion. Having relied on volunteer work > from the community for so long, it only seemed right that I contribute. > I wanted to see the buzz fix program successfully > implemented both in the EU and in North America. With help from Dr. > Schaller, SDG, and Sean I was able to get that > done. Next on my list was the GTA02 core project. When we canceled the > GTA03 Werner and others started a community > effort to do a phone design that was completely community driven. That's > no small task, but it keeps the dream alive so > I will continue to support it. On that front, we have met with some > success. Building Open Source hardware requires money > at some stage, money to buy parts and money to build prototypes. > Openmoko has graciously agreed to donate some components > to the project and I've put Werner in contact with people who can help > with the prototype runs. It's still early and there is a > lot of work to do, so pitch in if you can. I also wanted to see the > foundation work kicked off. And lastly I tried to find some of my > Openmoko friends employment which brings me to the second major thing I > have been working on: Starting a new company. > Wolfgang has alluded to this in a previous post and now is a good > time to let you > all know what we have been up to since late May. In the coming days as > we get the web page together and lists set up > I'll make some announcements and blog about the company and its > mission. The key elements are 1. Using existing hardware rather than > designing new hardware. 2. Focusing the software effort below the user > levels, 3. targeting the linux developer community. The most important > thing from our perspective is that there is no conflict with OM. > Wolfgang and I met with Sean on Saturday and explained our plan. OM will > focus on Project B so there won't be any conflict. We also agreed that > in the future the two companies will be able to find ways to work > together with OM perhaps picking up some of our products and applying > their focus-- Industrial design and user interface. > I'll be back to announce the name of the company in the coming week > or so as we build out the web page. You can write me > here or at my personal gmail account. (moshersteven@) > > Best Regards All, > > Steve. > > > ___ > 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
Freedom Redfined.
Community, As many of you know may 25th was my last official day at Openmoko. Since that time I have been focused on two things: First, putting my Openmoko business in order. There were several tasks that got cut off midstream by the layoff and I felt I owed it to the community to see those jobs through to some sort of conclusion. Having relied on volunteer work from the community for so long, it only seemed right that I contribute. I wanted to see the buzz fix program successfully implemented both in the EU and in North America. With help from Dr. Schaller, SDG, and Sean I was able to get that done. Next on my list was the GTA02 core project. When we canceled the GTA03 Werner and others started a community effort to do a phone design that was completely community driven. That's no small task, but it keeps the dream alive so I will continue to support it. On that front, we have met with some success. Building Open Source hardware requires money at some stage, money to buy parts and money to build prototypes. Openmoko has graciously agreed to donate some components to the project and I've put Werner in contact with people who can help with the prototype runs. It's still early and there is a lot of work to do, so pitch in if you can. I also wanted to see the foundation work kicked off. And lastly I tried to find some of my Openmoko friends employment which brings me to the second major thing I have been working on: Starting a new company. Wolfgang has alluded to this in a previous post and now is a good time to let you all know what we have been up to since late May. In the coming days as we get the web page together and lists set up I'll make some announcements and blog about the company and its mission. The key elements are 1. Using existing hardware rather than designing new hardware. 2. Focusing the software effort below the user levels, 3. targeting the linux developer community. The most important thing from our perspective is that there is no conflict with OM. Wolfgang and I met with Sean on Saturday and explained our plan. OM will focus on Project B so there won't be any conflict. We also agreed that in the future the two companies will be able to find ways to work together with OM perhaps picking up some of our products and applying their focus-- Industrial design and user interface. I'll be back to announce the name of the company in the coming week or so as we build out the web page. You can write me here or at my personal gmail account. (moshersteven@) Best Regards All, Steve. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: this is not freedom [was:Re: [OT] First rumors about first Google phone]
Again I don't know how much google will open their software, It's clear than if HTC + T-movile are involved in the phone the phone itself will not be free, that not worry me is a no go on hardware openness. I had some hope on the software stack not in hardware. El mié, 24-09-2008 a las 17:49 +0300, doron escribió: > Hi, > > I not sure , but, > > AFAIK , I can run free software for any purpose (freedom 0) , but the > Google phone is locked to one cellular provider , T-mobile , and the > device is SIM-locked [1] (paragraph 9 - first line). > This is not freedom ! > > > [1] > http://arstechnica.com/news.ars/post/20080923-t-mobile-google-finally-unveil-the-first-android-phone.html > > - doron > > > > Steven Kurylo wrote: > > Even if the code is open, will the hardware be? The hardware could > > easily check if the software has been changed and then cut power. > > > > Hopefully there will at least be some interesting bits to borrow. > > > > On 9/24/08, Cédric Berger <[EMAIL PROTECTED]> wrote: > > > >> On Tue, Sep 23, 2008 at 19:21, David Samblas > >> > >>> any news about the real openess of android? > >>> > >>> > >> first phone has just been announced to be released, and then the code > >> should be open sourced : > >> > >> http://android-developers.blogspot.com/2008/09/announcing-android-10-sdk-release-1.html > >> > >> "So what's next for us? Well, we'll keep working on the SDK, as I > >> said. But we're also working hard with our partners in the Open > >> Handset Alliance on the open-source release, with the aim of making > >> the code available in the fourth quarter > >> " > >> > >> ___ > >> 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
this is not freedom [was:Re: [OT] First rumors about first Google phone]
Hi, I not sure , but, AFAIK , I can run free software for any purpose (freedom 0) , but the Google phone is locked to one cellular provider , T-mobile , and the device is SIM-locked [1] (paragraph 9 - first line). This is not freedom ! [1] http://arstechnica.com/news.ars/post/20080923-t-mobile-google-finally-unveil-the-first-android-phone.html - doron Steven Kurylo wrote: > Even if the code is open, will the hardware be? The hardware could > easily check if the software has been changed and then cut power. > > Hopefully there will at least be some interesting bits to borrow. > > On 9/24/08, Cédric Berger <[EMAIL PROTECTED]> wrote: > >> On Tue, Sep 23, 2008 at 19:21, David Samblas >> >>> any news about the real openess of android? >>> >>> >> first phone has just been announced to be released, and then the code >> should be open sourced : >> >> http://android-developers.blogspot.com/2008/09/announcing-android-10-sdk-release-1.html >> >> "So what's next for us? Well, we'll keep working on the SDK, as I >> said. But we're also working hard with our partners in the Open >> Handset Alliance on the open-source release, with the aim of making >> the code available in the fourth quarter >> " >> >> ___ >> 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: I bought the FR for what I did not have - freedom (was: Re: funny comment from a user, in response to the question of whether FR works as a daily phone:)
On Saturday, September 20, 2008 17:55:09 yochaigal wrote: > Usable as a day phone??? I think the Fat and Dirty distro is completely > usable as a day phone... I should know (I use it every day with minimal > changes... any issues I have I just reflash). > Same for me, minus the reflashing. I've flashed the 20080913 version of it had haven't had to reflash it since that. The battery lasts about an entire day with it (I charge it every night and have not had an issue). The keyboard is rough to use though (with fingers); it takes me about 5-10 minutes to type up a proper text message. I'm pretty sure it would be faster with a multi-tap keypad (I have tried the Qtopia one though, and can type _really_ fast on it; probably faster than on my iPod touch). I have had to reboot it probably 3-4 times during this one week period, though. -- Kelvie Wong ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: I bought the FR for what I did not have - freedom
yochaigal wrote: > Usable as a day phone??? I think the Fat and Dirty distro is completely > usable as a day phone... I should know (I use it every day with minimal > changes... any issues I have I just reflash). > > > I think we need to be moving towards a situation where flashing is considered extreme. One aspect of linux, often hailed as significant (debatable) is that it needs rebooting less often then it's competitors. Flashing is akin to reinstalling the entire OS, and while it's trivial to do, I worry that it fosters a mindset of not valuing root causes. I admit though, I have not reached a point of confidence with the FR where I value any data on it, so reflashing is of little consequence. ~ Matt ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: I bought the FR for what I did not have - freedom (was: Re: funny comment from a user, in response to the question of whether FR works as a daily phone:)
Usable as a day phone??? I think the Fat and Dirty distro is completely usable as a day phone... I should know (I use it every day with minimal changes... any issues I have I just reflash). Ajay Kumar wrote: > > Somewhat similar utility to what Brian said: > > On Sun, Sep 21, 2008 at 1:00 AM, Brian Wilson <[EMAIL PROTECTED]> wrote: > >> >> They are targeted at "hospitality and healthcare" industry. They are >> just WiFi phones, no GSM no Linux. >> Both of these apps have staff that are constantly moving around and >> don't have a desk phone. > > > Similar scenario, on which I am working right now, is "Disaster > Management" > and "Relief Operations" and supplementing these activities using the FR. > > >> Build an app that caters to these folks and adds together WiFi + GPS + >> GSM >> > For Disaster management, Sahana is a FOSS web application just made for > this > purpose which has been used in real world situations. Building a solution > that caters to the similar needs of Disaster reporting and data collection > could well be very effective and useful for such critical solutions, with > such a handy and powerful device. > >> >> For a hotel -- from the phone, check status of any room. Use the phone >> as a master key for cleaning staff. >> > The central Sahana server can keep track of On Field relief workers, > broadcast them instructions or alerts based on their GPS location. Like, > need to relocate and assign a different task ? > Or say, urgently address a situation at a nearby location e.g. a victim > who > needs immediate help. > > >> >> When a phone leaves the building (loses WiFi VOIP registration) switch >> to GSM and note it in the server. >> > This is a very kool thing to have, ideally we can communicate to the > Sahana > server over Wifi, GPRS, and SMS too. I wrote the SMS server side part, > which > i am still expanding. > So you could just have a daemon running, which sends the GPS location of > the > Field Reporter, via an SMS in a timely manner. Acting like a real time GPS > tracking for Sahana's system keeping track of all volunteers. > > Moreover, there is currently a new module in development, by Dominic on > the > Sahana project, which is the Dead Body Tracking and Disaster Victim > Identification (in short: DVI) for Sahana. This would include body search > on > the scene, one thing you would preferably carry a GPS-enabled handy data > input device and a hand full of labels with you .The module should be > enabled to mark found items on a scene map, e.g. a grid, that's what the > search team usually does. > The phone, could well be used for such a purpose, if it had a camera too, > it > could take pictures. And an app to generate Bar codes for each body. Later > it can be connected to a printer to print the bar codes and fix them on > the > bodies. > > Just few more possibilities to the list :-) > I am working on this project, which aims to use the FR as an effective > Disaster reporting tool for Sahana, a FOSS Disaster management system [ > www.sahana.lk]. > > GPS, Wifi are key hardware components to start off for this, and later we > can use the other modes like SMS, GPRS to exchange data between the Sahana > server and the phone using a client application. > > Providing the field volunteers with an easy to use, touch input based > phone > to do all the data activity saves a lot of hassles and increases effiency > thus saving time. An important *thing* in such situations.. > > > Regards, > > Ajay Kumar > > ___ > Openmoko community mailing list > community@lists.openmoko.org > http://lists.openmoko.org/mailman/listinfo/community > > -- View this message in context: http://n2.nabble.com/2008.9-Basic-questions-tp1106131p1107120.html Sent from the Openmoko Community mailing list archive at Nabble.com. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: I bought the FR for what I did not have - freedom (was: Re: funny comment from a user, in response to the question of whether FR works as a daily phone:)
Somewhat similar utility to what Brian said: On Sun, Sep 21, 2008 at 1:00 AM, Brian Wilson <[EMAIL PROTECTED]> wrote: > > They are targeted at "hospitality and healthcare" industry. They are > just WiFi phones, no GSM no Linux. > Both of these apps have staff that are constantly moving around and > don't have a desk phone. Similar scenario, on which I am working right now, is "Disaster Management" and "Relief Operations" and supplementing these activities using the FR. > Build an app that caters to these folks and adds together WiFi + GPS + GSM > For Disaster management, Sahana is a FOSS web application just made for this purpose which has been used in real world situations. Building a solution that caters to the similar needs of Disaster reporting and data collection could well be very effective and useful for such critical solutions, with such a handy and powerful device. > > For a hotel -- from the phone, check status of any room. Use the phone > as a master key for cleaning staff. > The central Sahana server can keep track of On Field relief workers, broadcast them instructions or alerts based on their GPS location. Like, need to relocate and assign a different task ? Or say, urgently address a situation at a nearby location e.g. a victim who needs immediate help. > > When a phone leaves the building (loses WiFi VOIP registration) switch > to GSM and note it in the server. > This is a very kool thing to have, ideally we can communicate to the Sahana server over Wifi, GPRS, and SMS too. I wrote the SMS server side part, which i am still expanding. So you could just have a daemon running, which sends the GPS location of the Field Reporter, via an SMS in a timely manner. Acting like a real time GPS tracking for Sahana's system keeping track of all volunteers. Moreover, there is currently a new module in development, by Dominic on the Sahana project, which is the Dead Body Tracking and Disaster Victim Identification (in short: DVI) for Sahana. This would include body search on the scene, one thing you would preferably carry a GPS-enabled handy data input device and a hand full of labels with you .The module should be enabled to mark found items on a scene map, e.g. a grid, that's what the search team usually does. The phone, could well be used for such a purpose, if it had a camera too, it could take pictures. And an app to generate Bar codes for each body. Later it can be connected to a printer to print the bar codes and fix them on the bodies. Just few more possibilities to the list :-) I am working on this project, which aims to use the FR as an effective Disaster reporting tool for Sahana, a FOSS Disaster management system [ www.sahana.lk]. GPS, Wifi are key hardware components to start off for this, and later we can use the other modes like SMS, GPRS to exchange data between the Sahana server and the phone using a client application. Providing the field volunteers with an easy to use, touch input based phone to do all the data activity saves a lot of hassles and increases effiency thus saving time. An important *thing* in such situations.. Regards, Ajay Kumar ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: I bought the FR for what I did not have - freedom (was: Re: funny comment from a user, in response to the question of whether FR works as a daily phone:)
Paraphrasing Michael > In what ways can you extend the FreeRunner... I was looking at WiFi IP phones yesterday at Voipsupply.org and they have some in the $300-$600 range. They are targeted at "hospitality and healthcare" industry. They are just WiFi phones, no GSM no Linux. Both of these apps have staff that are constantly moving around and don't have a desk phone. Build an app that caters to these folks and adds together WiFi + GPS + GSM For a hotel -- from the phone, check status of any room. Use the phone as a master key for cleaning staff. For medical staff that are on call, track their locations via GPS and prioritize contacting staff that are closest to the hospital. Allow staff to locate a patient from the phone -- eg not in room? might be getting therapy. When a phone leaves the building (loses WiFi VOIP registration) switch to GSM and note it in the server. This means you can run across the street to the bagel shop on a break without being out of reach and you don't have to think about it. Just go. You might not be able to locate a smartphone accurately inside a building with GPS but at a large facility you'd know which wifi access point they were connected to so you'd know what building and possibly what floor they were on. There is lots of stuff that goes way beyond what a simple WiFi phone could do and the hardware is in the same price range. All value added most of it server based and relatively easy to protect private information... so while I might not want someone I don't know tracking my location via GPS if it's part of my job it could be very helpful to me. Brian ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
I bought the FR for what I did not have - freedom (was: Re: funny comment from a user, in response to the question of whether FR works as a daily phone:)
Michael Shiloh wrote: >> My old phone works as a daily phone. I bought the FR for what I did not >> have - misery. Sorry everyone, I found that comment amusing and was going to respond in some clever way, then changed my mind, and unfortunately sent the partially composed message. To paraphrase the original poster, we buy the FR for what we don't have - a generic Linux computer in a cellphone, on which we can develop all manner of applications in any language we chose, without the constraints of the carrier or the cellphone provider I appreciate that many of you purchased the FR to use as your daily phone. But I really believe that the magic of Openmoko comes from what we do with this platform that is different from, and way beyond, a mere phone. That is why the discussion about extending the FR with external sensors interested me so much. So what other ideas do you all have of ways to extend the utility of the FreeRunner? In what ways can you make it "more than a cellphone"? (and I don't limit this to physical extensions.) How can we all rise above the current issues with GSM, SMS, etc. and create the device of the future? My plan: I am going to take the ideas gathered in the discussion about reporting the tides (when they drifted (pun intended) into case modifications and external sensors) and build an extended FreeRunner. I plan to use a Pelican case and either an Arduino, EZ-USB, or MAKE Controller Kit to interface to external sensors and perhaps also actuators, like hobby servo motors. What is it going to be? I'm not sure yet. But I'm sure ideas will come. Michael ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Can you help the Openmoko booth at Software Freedom Day in Singapore on Sat. Sept. 20?
All right. I will be more careful next time. Thanks~ -Chelsea > I'm no list maintainer but you probably shouldn't be replying to an existing > thread. I know hitting reply is easier but it clutters the archives. > > Just so you know ... > > Sarton > > > On Tuesday 26 August 2008 16:46:28 Chelsea Wei wrote: > >> Openmoko is pleased to be invited for an open source day event on >> Software Freedom Day in Singapore. >> >> We will love to have some openmoko presence in Singapore; nevertheless, >> we are small understaffed team, so we will love if some of you could >> commit to helping us. >> >> Software Freedom Day in Singapore will be held at Singapore Management >> University Campus (School of information Systems) on Saturday September >> 20 from 10AM to 5PM. [http://www.softwarefreedomday.sg/] >> >> We will need approximately two volunteers for this event. For return, we >> will give away ONE debug board for each volunteer. >> >> If any of you is interested in helping us out, please let me know asap >> so I will be able to arrange for this event. >> >> Any help is extremely appreciated.. >> >> ___ >> 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: Can you help the Openmoko booth at Software Freedom Day in Singapore on Sat. Sept. 20?
I'm no list maintainer but you probably shouldn't be replying to an existing thread. I know hitting reply is easier but it clutters the archives. Just so you know ... Sarton On Tuesday 26 August 2008 16:46:28 Chelsea Wei wrote: > Openmoko is pleased to be invited for an open source day event on > Software Freedom Day in Singapore. > > We will love to have some openmoko presence in Singapore; nevertheless, > we are small understaffed team, so we will love if some of you could > commit to helping us. > > Software Freedom Day in Singapore will be held at Singapore Management > University Campus (School of information Systems) on Saturday September > 20 from 10AM to 5PM. [http://www.softwarefreedomday.sg/] > > We will need approximately two volunteers for this event. For return, we > will give away ONE debug board for each volunteer. > > If any of you is interested in helping us out, please let me know asap > so I will be able to arrange for this event. > > Any help is extremely appreciated.. > > ___ > 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
Can you help the Openmoko booth at Software Freedom Day in Singapore on Sat. Sept. 20?
Openmoko is pleased to be invited for an open source day event on Software Freedom Day in Singapore. We will love to have some openmoko presence in Singapore; nevertheless, we are small understaffed team, so we will love if some of you could commit to helping us. Software Freedom Day in Singapore will be held at Singapore Management University Campus (School of information Systems) on Saturday September 20 from 10AM to 5PM. [http://www.softwarefreedomday.sg/] We will need approximately two volunteers for this event. For return, we will give away ONE debug board for each volunteer. If any of you is interested in helping us out, please let me know asap so I will be able to arrange for this event. Any help is extremely appreciated.. ___ Openmoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: freedom
I don't think you can compare Peermeta with the Openmoko platform. The Openmoko platform is designed to be an Open Source platform for Open Source Handsets - and is meant to be a platform that can be built upon - not just for "Web 2.0" access. Peermeta seems to be a proprietary closed system with a completely different purpose. The website you linked to does not seem to provide any information on what exactly they do, other than the marketing speak you provided in your email. Without some technical details this is just hot air. ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: freedom
*About Peermeta* Peermeta is a pioneer in Web 2.0 enabled software platforms for intelligent end points utilizing mobile broadband infrastructure. The Peermeta solution enables mobile access to Any Content, on Any Device, on Any Network, at Any Time. Peermeta provides a method for tapping into the breadth of distributed heterogeneous content, extending control over consumable content to users for personalization and sharing among social networks and enhancing today's mobile network capabilities and end-user experiences to help drive mainstream adoption. The company was founded in January 2007 and is backed by venture capital firms Sigma Partners and Kepha Partners. For more information, please visit www.peermeta.com. Should OpenMoko be a better choice than PeerMeta ??? Can OpenMoko be the OS for WiMax CPEs ??? ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
freedom
"FREE YOUR IMAGINATION & INNOVATION" AFTER " FREE YOUR PHONE "!!! ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intercepting Audio == Freedom from Service Providers
* Tomasz Zielinski <[EMAIL PROTECTED]> [070115 15:07]: > 2007/1/14, Andreas Kostyrka <[EMAIL PROTECTED]>: > > >c) without being online all the time, you probably need to use it > >interactivly. 144B/s is way to slow for sensible feedback in the 1-2 > >seconds a user might accept to wait. > > Well, think about long wave submarine communication channel, which can > send about three bytes in ten minutes :-] Guess they don't send TCP/IP over it then. The ratio of effort and gained value doesn't work out here: Submarine case: Really huge effort I guess. Value gained: priceless, because there is no other way to get any message trough. Data-over-voice-gsm: Effort: huge. Value gained: saved about the cost for a very very slow GPRS connection. Paid instead the cost of a voice call, blocked voice channel, and so on. Potential legal problems, as some telcos might take that as misuse, fraud and press charges. Put bluntly, even with CDN$0.03 a kb, to make sense you would need the voice call to cost way below CDN$0.25 per minute to be cheaper in the bestcase. Not sure even if this is the case. Andreas ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intercepting Audio == Freedom from Service Providers
2007/1/14, Andreas Kostyrka <[EMAIL PROTECTED]>: c) without being online all the time, you probably need to use it interactivly. 144B/s is way to slow for sensible feedback in the 1-2 seconds a user might accept to wait. Well, think about long wave submarine communication channel, which can send about three bytes in ten minutes :-] -- Tomek Z. [EMAIL PROTECTED] ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intercepting Audio == Freedom from Service Providers
> If your phone can receive data over a voice channel, you have less of > a reason to pay your service provider for a separate "data package". > This would be especially nice for someone like me who only subcribes > to the "bare bones" plan, but still has minutes left over at the end > of the month and has to pay $.50 for the five text messages received. > (Sure, only useful when communicating with other OpenMoko users, but > still a possibly useful feature.) The problem is, that sending raw data is probably not possible. In theory, and especially in practice (the gsm modem being a seperate embedded hw piece), this won't work. To seperate this out: *) sending raw data is probably not exported from the gsm module, and there is the question what data can be sent. *) trying to send data via the audio channel is doomed on two counts: first you need a software modem, and these are not free software, plus you would need to take into account the fact that the GSM module does apply all kinds of lossy compression on the audio data. The question still staying, how will one access the gsm audio streams? Andreas ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
Re: Intercepting Audio == Freedom from Service Providers
* Bryan Fink <[EMAIL PROTECTED]> [070113 15:32]: > On 1/13/07, Andreas Kostyrka <[EMAIL PROTECTED]> wrote: > >> If your phone can receive data over a voice channel, you have less of > >> a reason to pay your service provider for a separate "data package". > >> This would be especially nice for someone like me who only subcribes > >> to the "bare bones" plan, but still has minutes left over at the end > >> of the month and has to pay $.50 for the five text messages received. > >> (Sure, only useful when communicating with other OpenMoko users, but > >> still a possibly useful feature.) > > > >The problem is, that sending raw data is probably not possible. > > Ha! Possible, schmossible. With that attitude you'll fail before you begin. Nope, the problem is that mobiles are highly regulated gadgets. Sure way to fool around them to get into legal troubles. > > >*) trying to send data via the audio channel is doomed on two counts: > >first you need a software modem, and these are not free software, plus > >you would need to take into account the fact that the GSM module does > >apply all kinds of lossy compression on the audio data. > > A) Software modems can be written - that's the point of an open source > phone. See B for one example. I'm sure someone much more clever than > me could come up with something much better. In theory yes. In practice, as this is even a harder problem than normal modems, I'd like to see a free softmodem codec first. Notice that the opensource community was not able to come up with something working in over a decade. (I mean this stupid Winmodems.) Additionally, you need to consider that this stuff is most certainly protected by huge list of patents :( > > B) Even with lossy compression, there are still plenty of methods of > sending data. I've mentioned one already - Morse code. I've seen so > many term-long class projects implement Morse code encoder/decoders > over crappy transmission channels, it's not even funny. Simply find a > carrier and transmission rate that the gsm module doesn't mangle "too > bad", and you're golden. > > "But Morse code only sends text!" you claim? Simple: uuencode your > raw data first (or use any other binary-to-text encoding, of course). > Throw some parity/hashes on the end to catch errors. No problem here. The problem is the bandwidth. Technically one could communicate (although regulations might make it illegal), by caller id: have n numbers to call from, and never pickup the phone. Added with with timing one might get some data over the channel. The problem is, that GSM at best offers a theoretical bandwith of 14400 bps for voice channels. GSM phones switch to lower bandwidth codecs when the situation requires it. Now if you are able to use only say 1/10th of the bandwidth because of your coding stuff. You'll get at best 1440bps. Quality wise one might notice that this is a connection where despite the propaganda, current TCP/IP stacks might need adjusting to work. (I had some bad experiences in this regard, but had never time to trace and debug it in detail back then.) 1440bps means about 144 bytes per second. Doing a ping with standard parameter over this link fills it basically completly. Let's talk, how long will it take to transfer 1MB. A quick wait of 2 hours will get you 1MB. Another check, ssh with pubkey to my router generates about 20KB traffic. Again at this speed, this means about 2.5 minutes before the prompt of your remote host shows up. > I never said it would be fast, but it *is* possible... I never said it would be impossible. I just said, that combined with my experiences in "mobile internet", anything you might arrive at is most certainly not worth the effort, just "forget it". Basically, what's the point of having email at the go, if you would have it faster by walking to some Internet cafe and starting your webmail access? Or even ssh-ing into your computer to read it via ssh (or if it's graphical via vnc-over-ssh). Additionally, all that doesn't take into account the economic side of it: a) first without a real voice flat rate, and there aren't that many, most plans advertised as "flat" do have some maximum of minutes in the small print, you cannot be online even with this slow speed online all the time. b) it blocks your voice mobile. c) without being online all the time, you probably need to use it interactivly. 144B/s is way to slow for sensible feedback in the 1-2 seconds a user might accept to wait. d) without a flat fee, it all breaks down to a simple question: csd_per_minute_cost > (voice_per_minute_cost * slowness_factor) e) all this implies a home station, which means at least one POTS line blocked while you are communicating. So basically, to put it into a broken analogy: Is it worth to invest xx man years of work (hard work, because you don't need a C.S. major, you need a signal processing engineer, these are rather more seldom) to get at the end an old and slow Lada, that m
Re: Intercepting Audio == Freedom from Service Providers
On 1/13/07, Andreas Kostyrka <[EMAIL PROTECTED]> wrote: > If your phone can receive data over a voice channel, you have less of > a reason to pay your service provider for a separate "data package". > This would be especially nice for someone like me who only subcribes > to the "bare bones" plan, but still has minutes left over at the end > of the month and has to pay $.50 for the five text messages received. > (Sure, only useful when communicating with other OpenMoko users, but > still a possibly useful feature.) The problem is, that sending raw data is probably not possible. Ha! Possible, schmossible. With that attitude you'll fail before you begin. *) trying to send data via the audio channel is doomed on two counts: first you need a software modem, and these are not free software, plus you would need to take into account the fact that the GSM module does apply all kinds of lossy compression on the audio data. A) Software modems can be written - that's the point of an open source phone. See B for one example. I'm sure someone much more clever than me could come up with something much better. B) Even with lossy compression, there are still plenty of methods of sending data. I've mentioned one already - Morse code. I've seen so many term-long class projects implement Morse code encoder/decoders over crappy transmission channels, it's not even funny. Simply find a carrier and transmission rate that the gsm module doesn't mangle "too bad", and you're golden. "But Morse code only sends text!" you claim? Simple: uuencode your raw data first (or use any other binary-to-text encoding, of course). Throw some parity/hashes on the end to catch errors. I never said it would be fast, but it *is* possible... The question still staying, how will one access the gsm audio streams? ...assuming that is possible, of course. ;) -Bryan ___ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/mailman/listinfo/community
