I have a problem that may wall into this thread: In our lab we had a demo presentation where a industrial pc connected to a lonworks net (comm api.) to configure and recieve informations from small clients connected to the lonworks net, used is Enhydra through a web browser this can be operated. But due to a out of house presentation we had to make it mobile. First I connected a gprs mobile phone but found out that one only can get dynamic ip addresses, not only do one get a new address when connecting but they may change over time. I found a site (dns2go) that could help, but the transmission rate was very poor, data send at 1 timeslot at 13 kbit/s and recieve at 3 timeslots but this is at the very best and what I have just seen it's send 380 bps and recieve 600 bps, besides talk has top prio on the net and data transmission comes there after. Recieving a page from Enhydra could take 1-2 minutes, so the next thing I tryed was to use rmi from a master Enhydra server to a client running the locale lonworks part and call methodes from server to client when changing the config and from client to server when new data was collected. The response time went from the 1-2 min. to ~ 15 sec., but looking at the data used on the connection with rmi was not that great and just to have rmi running was making 9,3 kb pr 10 min., 1MB is costing ~ 3$, and this is not something we can live with. Other problem with rmi is when the client gets a new ip the rmi ref of the client is not changed. I guess this is something that is focus by someone in this forum when talking about embedded application servers etc., and as I would very much like to make a better solution I hope that people on the list can help me in the right/better way. Oh, about the industrial pc, well if you know of a smaller device (have to use java) that can be used I would like hear about it to as I thing it's a littel overkill to use a x486 or x586 on stuff like this. Regards Martin -----Oprindelig meddelelse----- Fra: me-admin@enhydra.org [mailto:me-admin@enhydra.org]Pa vegne af Jason Anderson Sendt: 30. august 2001 18:50 Til: me@enhydra.org Emne: Re: ME: RE: I'll start a new thread then... Wind River segments the embedded market from a similar industry segmentation: 1. Industrial measurement and control. This is a pretty well-established arena that can be very resistant to major technological change -- it wasn't until the past few years that we've really seen a broader migration from in-house proprietary operating systems to commercial RTOS vendors. Usually of much greater concern to this space is the reliability of the computing environment and its resistance to odd factors like EMI/radiation interference, with some minimal amount of interaction with backoffice control systems. 2. Automotive. The auto industry is in the middle of a significant technology shift away from analog control systems to a digital bus network for controlling a variety of things in a car. You'll eventually see antilock brakes, power windows and steering, transmission/gearbox control, engine tuning, dashboard displays and other things all integrated and communicating over a common network. 3. Telecom/datacom. I believe everybody understands these pretty well; these are the makers of switches, carrier-grade equipment, wireless hubs, DSL routers, and a whole other collection of devices. This is the land of the protocols. 4. Consumer devices. This is where we see Java compatibility being of the greatest potential benefit and marketability; this includes your typical palm-held devices as well as other things you may not think of yet as requiring Internet connectivity. One plausible scenario is the initial introduction of home Internet wireless gateways using 802.11a or other newer, faster wireless technology. This would then be followed by a few core appliances such as DVD players or televisions with built-in Internet-enabled features. 5. Military/aerospace. Usually not interested in integrating or connecting with other applications, the mil/aero space has extremely high performance and determinism requirements. We've not seen much Java penetration in this space, although our other RTOS and tools products continue to do well. From my point of view, something like an embedded application server (or subset of those technologies) is best targeted at the datacom and IMC markets as a seeding strategy, to provide the infrastructure required to support distributed services (being hyped as web services right now) in the future. You'll then see consumer appliance makers needing similar technologies to enable their products to connect to those exported services. Many companies in the above industries are not big fans of the x86 CPU family. Compared to others like ARM or PowerPC, the x86 is hot, noisy, and expensive both in terms of dollars and watts. If the ME project wants to see broader success we'll need to first think deeply about which CPU architectures to support or test. Yes, JavaME and the KVM or CVM are supposed to make this straightforward but in our experience there is a huge gap between capability and reality. Porting to other CPU's requires certain capital resources and funky development environments. -Jason |