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 perfectlyagreed. It fact it's all fuzzy with PDA, Laptops, wearables and wireless commnications.
relevant to this list. Laptops need mobile connectivity too.
Much appreciated, on the offer for bluetooth help. At the end, I'll be a little more specific aboutMy 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 :)
my goals.
Yes, agreed, that's why I'm looking to archtect an opensouce solution that has extra processors,
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.
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.
Well if the vendor controls to RTOS, then the features you get, are what they want you toAnother 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.
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.
Yes (low) power design is critical. FPGA, and most micros can be put into sleepmode as necessary.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...
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.
Yes, likewise I ran across a sharp CF bluetooth card, Model DC2C1BZ001. I'm still gathering informationI'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.
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 [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
-- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
