|
|
||
Bruce Boyes's BlogJuly 2005 ArchivesDual-mode cellular and Wi-Fi phonesPosted by bboyes on July 28, 2005 at 03:55 PM | Permalink | Comments (0)Electronic News reports here that - finally - we may see a cell phone with 802.11 in it, plus the software to "operate using 802.11 technology inside the enterprise and cellular telephony elsewhere". It will operate as an "extension to the Cisco CallManager IP-based communications system" so what does that mean (this is not a rhetorical question) exactly? Apparently it means that this new device may only work as part of a Cisco hardware package... having some curiosity and Google, I found this page of information, but about here I start to lose interest. It doesn't look like a system the general public (like me) would ever use... Oh well, it made for a good headline. Handheld market drops for sixth straight quarter, says IDCPosted by bboyes on July 28, 2005 at 02:04 PM | Permalink | Comments (2)According to this article and this article, sales of handheld computing devices are declining about 30 percent year-over-year, and have been so doing for six consecutive quarters. Worldwide, 2.5 million PDAs shipped in 2005 Q1. But this doesn't mean fewer PDAs are in use, does it? It could mean the market is relatively saturated and that PDAs have a longer life than PCs. Anecdotal information bears this out. Here in our office we all carry Tungsten C PDAs, which have been in production for three years. Try to buy any given laptop PC for that long... We just had one repaired rather than upgrading to a newer model. It's one of the very few (only?) PDAs with built in WiFi -- OK, make that PalmOS PDAs with WiFi. So perhaps here we have an interesting conundrum - build something with a long life and - guess what - people won't buy as many of them, because they don't need to. Viewed from this perspective, PDAs may be somewhat a victim of their own success. Even Windows variants don't change as rapidly in the handheld sector, do they? Then too, some largish companies have banned all PDAs because they are capable of storing data, making it easy to steal things. (Hmmm, I wonder if those same progressive companies should go back to punch cards and pencil-and-paper schematics for the same reasons.) Yet those same companies probably buy desktop PCs by the truckload. So there is more demand for PCs than for PDAs. In fact, worldwide PC sales are up about 15% according to this, at over 45 million units in 2005 Q2. That's almost 20 PCs shipped for every PDA. Let's see, here in my office I have two desktops and one notebook, plus a dead notebook, but only one PDA. Not sure what I'd do with 16 more PCs... Throughout my day, people around me use a lot of PCs (the library, bank, etc) but no one I know conducts commercial business on a PDA, so maybe that's where the other 16 go. What about "the other white meat" - cell phones? Would you believe 188 million units in 2005 Q2. That's over 4 cell phones shipped for every PC shipped. But I'm guessing a lot fewer people use multiple phones than use multiple PCs. So this means that a lot more people use cell phones, period. If the phone, PDA and PC ever converge, it would make it really hard to analyze these statistics... - Bruce First Java support for a DSP core?Posted by bboyes on July 25, 2005 at 04:33 PM | Permalink | Comments (0)Every family of DSP chips is quite different from every other, memory architecture and pipelining is peculiar when compared to traditional microcontrollers. DSPs are generally RISC machines highly optimized for Digital Signal Processing (FFTs, image manipulation, telcom data streams, realtime video and digital audio codecs, etc). All of this conspires to make DSP one place where I thought Java might never go. But apparently that is all about to change. These abbreviations may not be familiar to you all. LSI Logic is a chip manufacturer. RTJ here is *not* "Real Time Java" but "RTJ Computing", of Perth, Australia, who have ported their cleanroom simpleRTJ Java virtual machine to the ZSP G1 family of DSP cores, which execute up to 960 MIPS. The G2 cores are about twice as fast, but this release doesn't mention Java support for them. Oddly, (at least on 2005 July 21) the ZSP Partners page mentions nothing about this, and RTJ Computing isn't listed as a partner. RTJ's website does list a ZSP board on their showcase page, referencing a ZSP 402ZX development board. LSI Logic responded to my email about all this by saying "RTJ has created a Java virtual machine to emulate all of our G1 (first generation) DSP embeddable cores – the ZSP Neo, ZSP200 and ZSP400. Please contact them directly for any sort of SW development kits or evaluation tools". That reply raises more questions than it answers - the JVM emulates the ZSP hardware rather than executing on it? This would be a question for RTJ... I'll ask and update this blog as appropriate. In any case, this is potentially exciting news because programming DSPs could certainly benefit from any useful progress towards making code more reliable, standardized and portable. "Useful" is the keyword here, because the nature of DSP makes much of its coding arcane, and it's not clear how useful a highly-abstracted OO language like Java will fit. Part of the dark side of embedded Java now is that the interesting bits of code - where it starts to touch the so-called "real world" often is handled by vendor- and application- specific libraries or native methods. These bits tend to be hard to reuse, are often not at all portable to other hardware, and frequently comprise a significant portion of the application code. In other words, making a modern, object-oriented, general-purpose, abstracted programming tool for DSP use is not a trivial task. I hope this new effort achieves a great deal of success. I'd love to hear from anyone with hands-on experience with this new tool, or other similar approaches. Real Soon Now: mesh network standardsPosted by bboyes on July 21, 2005 at 11:44 AM | Permalink | Comments (0)This article in Infoworld: http://www.infoworld.com/article/05/07/20/HNmeshnetworks_1.html?source=NLC-TB2005-07-20 reports that 15 competing proposals will be whittled down to create the new IEEE 802.11s specification. What's so great about a mesh network topology? A mesh network is a network in which the routing of messages is performed as a decentralized, cooperative process involving many peer devices routing on each others’ behalf. "Mesh networks reduce the need for wired connections in wireless LANs by letting multiple access points carry each others' traffic. Whereas a conventional wireless access point needs its own wired link to a backbone network, with a wireless mesh there can be just one wire for many access points. Traffic that is destined for the Internet can hop from one access point to another until it reaches the one wired connection." - Bilel Jamoussi, director of strategic standards at the Chief Research Office of Nortel Networks So you can imagine a mesh in a building, or a university campus, or formed by a group of mobile nodes - PDAs, or vehicles, or robots, which would enable reaching any connected node through a path of other mobile nodes. Personally I'm more interested in peer mesh networks which may not even have a wired internet connection, and are just used for local communications. There are apparently two competing 802.11 mesh alliances: WiMesh (including Nortel) and SEEMesh (Simple, Efficient and Extensible Mesh) which includes Intel Motorola and NTT DoCoMo. Another area of mesh network progress is in low-rate personal networks. The 802.15.4 spec and its associated ZigBee Alliance have considered mesh a key enabling feature from day one, though the mesh specification has been only recently defined, and I was not able to find a reference to the actual spec for this blog. 802.15.4 defines the physical and MAC layers of an application, and ZigBee defines the network/security layer, application framework and, in some cases, the application profile. ZigBee provides a simple, low-cost global network that supports a large number of nodes with extremely low power consumption, making it very practical for battery operation. (At the Zigbee Alliance website you can download the Zigbee specification - currently "ZigBee Document 053474r06, Version 1.0" dated both Dec 2004 and June 2005, but this document does not include any mesh specifications per se.) Where this all leads us is that very shortly there should be accepted standards for mesh networks on a variety of media layers - 802.15.4 and 802.11, for starters. This makes it possible to think about practical distributed control and communication applications utilizing standardized wireless communications. Mesh-based systems are a better fit for many applications than current star or tree topologies. Mesh networks can be more easily self-adapting and healing, especially when typical nodes are ephemeral. These are exactly some of the issues which would be faced by large robot swarms. Sandia Labs: UWB & AES demo for next generation secure wireless networksPosted by bboyes on July 08, 2005 at 10:36 PM | Permalink | Comments (0)This article describes a secure form of wireless sensor communication which "leverages UWB with the unyielding encryption protection of the 256-bit Advanced Encryption Standard (AES) to form UWB/AES". Among the key wireless features of the UWB/AES are its IP network compatibility and its “per-packet” rotating 256-bit encryption keys for even greater crypto-protection. The UWB/AES network architecture requires no computing infrastructure, provides real-time (hardware) encryption, and requires zero maintenance for complete self-recovery if interrupted or when a sensor goes down. A recent test moved streaming video over such a link, using only microwatts (compared to milliwatts for 802.11b/g) of RF power. Sounds almost too good to be true... UWB is expected to hit the market in 2005 according to this 2002 article and this 2004 article. Oops, OK, maybe 2006? Whenever, it will be big. Companies like Freescale are developing UWB chips which were/are due Real Soon Now. Top Ten Myths of Embedded Security, and what Java offersPosted by bboyes on July 08, 2005 at 01:28 PM | Permalink | Comments (1)This online article by by Mukesh Lulla, TeamF1 is a pretty good overview of the top 10 misconceptions about embedded security. It's worth mentioning here for a couple of reasons. One: embedded security is increasingly important as more embedded products are provided with a network connection to the outside world. Two: it's generally accepted that the various Java security packages are "better" than your average vendor-specific offering. A decent overview of Java security appears in this 2000 JavaWorld 5-part series By Raghavan N. Srinivas. I'm particularly interested in all this since my company is about to engage in development of a hardware/software product to make certain SCADA communications secure. We will be running all code on native-execution J2ME/CLDC hardware similar to JStamp. So I'm interested in feedback from those of you who have recent experience in securing embedded systems. Regards - Bruce | ||
|
|