Re: PDA + Cell Phone
Hello Martin,
Sorry for the day, but, I had to hit the road for a few days...
I do appreicate your comments, and I'm looking to discuss
these issues as to help me formulate a plan of action.
Martin Norland wrote:
While not strictly PDA - I think the subject matter is still perfectly
relevant to this list. Laptops need mobile connectivity too.
agreed. It fact it's all fuzzy with PDA, Laptops, wearables and wireless
commnications.
My experience(s) don't relate to a single device, but I would advise you
against going that route in any case - more on that later.
I've used gprs over bluetooth with my cellphone. It worked just fine,
although it was nothing like broadband speeds - which I have apparently
become quite accustomed to. Configuring bluetooth under linux is a little
tricky (or was at the time) just because getting BlueZ or Affix to work
well is a little confusing - a few levels you have to initiate manually
before bringing the (in my case) ppp up. I'll be happy to help you
diagnose anything if I can remember how :)
Much appreciated, on the offer for bluetooth help. At the end, I'll be a
little more specific about
my goals.
As far as integrated device - I would advise against this because they
traditionally aren't as powerful as their separate counterparts.
Take the nokia n-gage (which a newer model was just announced for) -
cellphone and game system... in most opinions doesn't do either
signifigantly well.
Yes, agreed, that's why I'm looking to archtect an opensouce solution
that has extra processors,
DSPS/FPGA that are asleep most of the time. I'm curious to find COTS
(Commercial
Off The Shelf) hardware, with linux drivers, but I intend to put
together an open system for
this wireless data/voice need. Others are welcome, and I am looking for
what's already been done,
as to avoid duplication of efforts.
Another device is the Danger Sidekick (Tmobile hiptop [I might have
those reversed]). This I have to admit is a very slick device - and you
get better performance since everything is proxied and their servers do a
good job of stripping out the useless bits - but you're limited with the
usability. You can't use the device as a modem like a normal cellphone -
if, for example, you had your laptop handy and wanted to get online with
it. You can't use the device without a proxy - and the SDK (I believe it
was finally released) isn't much good because you can't get the program on
the phone without a bunch of hoops.
Well if the vendor controls to RTOS, then the features you get, are what
they want you to
have. JTAG interfaces need to be discovered, if one is to customize the
RTOS software. If a vendor is not
willing/cooperative, then spinning boards is not a big deal. I'll
probable put the gerber plots up on the
net if folks have interest in the hardware. Do not forget, when it comes
to FPGA that is an enormous
amount of 'things or components' at www.opencores.org. Most of what I
want to do, exist, it's
a question, in my opinion, of defining and open archtecture, and listing
devices and services that work,
devices and services under development, and partnering with groups like
this laptop users
support forum to disseminate what's available.
irda works fine as well, but it's a pain lining things up - bluetooth is
nice because it's low power (unlike 802.11b) and works well once devices
are paired. Speaking of power - if you just want to talk to someone on
the phone you're burning your PDAs battery - and if you just want to use
your PDA you're burning your phones battery... nor can you just take one
with you somewhere...
Yes (low) power design is critical. FPGA, and most micros can be put
into sleepmode as necessary.
Power input would be via solar cells, DC (on cars, boats, wearables) and
robust batery power managment.
Linux already offers a variety of power management capabilities, some
extenable to mobile devices.
If you not driving a display and peripherals, many Arm-processors are
quite resonable on power consumption.
The caveat with most arm-processors, is they do not perform float-point
operations at, or poorly if
the arm even has Floating point. Hence a companion DSP or FPGA..... A
variety of processors
should be available.
I've got a bluetooth cf card on order from amazon (ambicom)
that I'll be trying out the pda game with. I'll let you know how well it
works if you're interested.
Yes, likewise I ran across a sharp CF bluetooth card, Model DC2C1BZ001.
I'm still gathering information
on available cards and the corresponding driver sources. Tuxmobile.org
has quite a bit of stuff listed.
Compact Flash(CF) is the interface of choice for me for general purpose
interfaces goes. USB also.
I'm really looking to add 'data logger' capabilities to the mix. For
example, if I go into a store, I might
pull out a bar_code scanner and save some pricing information into the
device. General purpose
a/d(analog-to-digital) and d/a I/O are feature that I'm going to have to
build and interface. Drop in
a CF camera, and take some pictures for saving or transmitting.
Many microshave a/d and d/a build in, as well as usb, jtag, serial, CF
etc types of interfaces. I do not intend to
scrimp on the processor's ability. I'm thinking about an arm9 with
either a DSP or FPGA companion that
can be put to sleep or awakened as needed. Also the 802.11(a,b,g,x
...etc) family is useful. If I cannot
find what I want in an existing PDA, then I'll get a dev board from one
of the the arm chip vendors....
At this stage I looking to survey a wide variety of ideas, interfaces,
protocols and existing driver code.
From there, define an open architecture on what available. Then if
somebody wanted to look for a
specific package of what they need, then they could determine when
they can purchase COTS
equipent, and figure out how to interface what else they need. This
would kind of follow the
PC as to the way we look for pci cards to stick in our desktop. CF and
usb can be the
interfaces for mobility. I see wireless communications as the glue to
allow mobile users
to access and share resources, like we do over our wired
connections.(Much of this is
already in place, in some areas).
What I do not agree with, is that we need a different radio and
billing-type access for all of this.
For things like bluetooth versus 802.11 yes a different radio is needed.
But for the same
gsm/gprs network, one radio is sufficient. Futhermore. One should be
able to have a general
purpose device, like a pda with embedded linux and CF, and be able to
plug in the appropriate radio(s).
Devices exist that do both voice and data over a gsm/gprs
infrastructure. However, currently,
cellular provides to require, registration/activation, with long term
financial commitments to
use these channels. Furthermore, their devices do not work with the ISM
and other
unlicensed frequencies. That motivates an embedded linux solution.
For example if I am traveling outside my home wireless access point I could:
1. Look for other 802.11 access points that are free ( a variety of
scenarios exist here)
2. Look for 802.11 access points that are metered.
3. Use a flat rate tcp/ip (gprs)such as t_mobile
4 use a metered ppp/celluar(pstn) again it's metered and very expensive
5. Note more techniques exist, this is an example only.
A business case for Item 1: People could build out wireless access
points with a limited 20K/s
of bandwidth that is free. If you need more wireless bandwidth, then a
pre-planned transaction
or a dynamic transaction could take place to get more bandwidth. Mapping
wireless access
areas to GPS over a map could go a long way to supporting the needs of
the rapidly growing
wireless linux market.(this is just one idea). This would allow folks to
offset their operations
and equipment costs. If we put together a "node" that sits on the DMZ of
one's home/business
network, with bandwidth limiting and security, then it could be rapidly
replicated. One
important aspect is having a plethora of devices to use on this grid,
that are merely a transaction
away. Apt-get could keep the devices functional with updated
applications and firmware.
We would need a method to dynamically determine the
cost or cost per minute for these, as well as a single selection of the
individual then go down
the sysmantic choice on how to communicate with my target. Hell, for
security reasons, I
may want 3/4 of the channels active, and round robin my packets(data)for
security reasons....
Or my goal might be to minimize costs. Some flexibility needs to be
engineered into this
scenario. The choice to give free access, limited free access, flat
rate, or metered, could
rest with the node owner/operation. If everyone used the same
control/billing sematic, then
a grid could be established.
The bottom line is choice, uniquely defined by the user/consumer and
node owner, with
and lots of options that are easy to choose between. Hopefully support
could be
organized to the various devices, via apt-get or some of the newer
graphical tools for debian.
Other OS's, like the BSD_ bretheren, could develop compatible devices
and solutions.
Maybe I'm aiming a little too high, but, if an archtecture is robustly
discussed, and many
people like the approach, then the solution and effort is worth pursuing.
I hate being at the sole_mercy of cellular providers for wireless
access. They are OK, but, we need
alternatives to supplement their fiefdoms. These alternative need to be
deployed widely, via
open standards to be effective and practical. If these alternative
become an entrepreneurial
opportunity, then, that is consistent with empowering the masses..... an
the gpl....
I suspect that much/most of this is already in place. It's just getting
organized to use mobile
devices with alternative access points, seemlessly, needs a bit of
tweaking, methinks....
James
Sincerely,
-Martin Norland
On Wed, 14 Apr 2004, James wrote:
Hello all,
Has anyone attempted to use a single device for both cellular, (pstn
switched)
phone calls and VoIP aka sip (flat-rate)? What I'm thinking of is a PDA
with GPRS capabilities. There are (OEM) GSM/GPRS modules that are
capable of both. There are also reasons to have a Cell phone and a PDA
as compatible devices. I guess the best idea it to start working form a
platform that runs embedded linux and is 100% sourcecode available.
Maybe a wearable compujter, with 2 ports, one for cellular, one for GPRS?
Any ideas? I was going to use Tmobile as the guinny_pig, as they are
GSM&GPRS. The GPRS is flat rated at 30.00/mo. here in the US.
All input is most welcome. including latency issues.
James
--
To UNSUBSCRIBE, email to debian-laptop-REQUEST@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: