Printer Friendly

Mobile lab clients for testing application specific integrated circuits in education.

1. Introduction

The evidence that the field of remote engineering has matured are overwhelming, particularly as indicated by the number of remote laboratories in operation today. Furthermore, the range of disciplines being taught continue to grow and collaborations between universities all over the world are becoming increasingly common [9]. Related training courses have also been explored in chemistry, physics, and electrical engineering and other interesting setups include remote experiment and virtual labs for wind tunnels, a virtual laboratory for exploiting DSP algorithms and a learning tool for chip manufacturing [10].

The opportunity to provide students with remote access to experimental hardware and the ability to offer flexibility in time and place in which laboratories are conducted are also becoming powerful motivations for the field [7]. Additionally, the recent advances in mobile technologies have lead to an increase in the number of Internet users accessing information via mobile devices and the number of applications designed for such devices is growing and becoming increasingly popular. With the release of Visual Studio .NET 2003, it was possible to create applications to run on resource-constrained devices, in almost the same way Windows application are created. These applications are built for the .NET Compact Framework that includes a large selection of framework classes and optimized for the small screen resolutions of handheld devices. From the pedagogical viewpoint, students' expectations on how and when they learn are also creating increasingly heavier demands upon all aspects of their learning as young people are making mobile devices an extension of their personal space and fundamental to their daily lives. In response, the world is moving very rapidly to engage with the opportunities and flexibility offered by mobile technologies [8].

Mobile remote solutions may therefore be attractive tools in enhancing access to practical experiments as they offer many different possibilities for applications in industry and education because they are not subjected to limitations of location and time [9-10]. This, in combination with today's easy access to broadband Internet, is transforming the way e-learning is carried out, allowing a higher level of interactivity and providing virtual environments closer to real ones. Hence, mobile remote systems can be very useful when applied to solutions involving high costs of people and equipment transportation. Different universities and institutions could share laboratory resources, expensive equipments and experiments by means of a cooperative network of remote systems.

We have developed a system to design and test Analog ASICs (Application-Specific Integrated Circuits) remotely over the Internet. The system allows for users to create different circuits with an application software and upload them to a real device. The device under test used is an ispPAC10 from Lattice Semiconductor.

Our approach to implement a client for PDA devices is based on LabVIEW. National Instruments offers a module within its LabVIEW suit to build applications for handheld devices.

2. The Remote Lab Server in LV

Internet Protocol (IP), User Datagram Protocol (UDP), and Transmission Control Protocol (TCP) are basic standards for the network communication.

TCP describes the communication between applications. When an application wants to communicate with another application via TCP, it sends a communication request. This request must be sent to an exact address. After a "handshake" between the two applications, TCP will setup a "full-duplex" communication between the two applications [6].

IP is responsible for routing a packet to its destination and it is a "connection-less" communication protocol. LabVIEW offers an API (Application Programming Interface) for developing applications that includes TCP and UDP Vls and functions that can be used to create client or server Vls and it is possible to use TCP/IP protocols with LabVIEW on all platforms.

TCP is a connection-based protocol, which means that a connection must be established before transferring data. The data transmission occurs between a client and a server. TCP permits multiple simultaneous connections.

[FIGURE 1 OMITTED]

A connection is initiated by waiting for an incoming connection or by actively seeking a connection with a specified address. In establishing TCP connections, it is necessary to specify the address and a port at that address. Different ports at a given address identify different services at that address. TCP/IP communication provides a simple user interface that conceals the complexities of ensuring reliable network communications.

With the API for TCP/IP communication of LabVIEW it is possible to develop custom applications for TCP/IP communication. The programmer is responsible fordeveloping both the client and the server.

Our server was developed with LabVIEW versions 8.2.1 and 8.5. LabVIEW offers many proprietary high level communication protocols, like data socket and shared variables, but our approach consisted in developing our own server with the TCP/IP API of LabVIEW, so that we are free to use any platform to develop our clients, as long as they implement a

TCP/IP communication and interpret XML documents. When transferring data directly via TCP/IP, the data must be previously converted to string types. The length of the string must first be sent (also as a string) and then the data itself. Therefore, the client converts all parameters (frequency, offset, waveform, etc) to an XML string and transmits them via TCP/IP. On the server, this string is read and the parameters are extracted and converted back to their original type to be processed by the Vls controlling the data acquisition. The responses are then converted to an XML string again and sent back to the client. On the client these responses are converted back to their original types and displayed to the user. LabVIEW has its own XML Schema file that allows it to interpret the created XML file. Although we use XML as a vehicle for our data, this is not strictly necessary, but it makes the transferred data more portable and easier to be interpreted by clients developed in other platform.

The diagram shown in Fig. 1 describes the functioning of the server. We decided to use TCP port 80 for the client/server communication. The server listens to TCP port 80 and when there is a connection, it assigns to this connection the last position in the queue. Each client connected has the requests processed during its time slice. While a client is connected it is occupying a position in the queue and is consuming resources. Therefore we allow maximum connection duration of 30 min.

The server processes client requests by applying the desired signal to the circuit under test and returning the measurements back to the client. Clients were designed for PDAs as well as for Windows PCs. Requests from both should be treated seamlessly by the server. Due to resources constraints of PDA devices, not all the features designed for a client running on a PC are performed when accessing the system via PDAs, but this can be managed just by changing the client application.

The user can reconnect afterwards if needed.

As described previously, this system relies on lower level TCP/IP communication to send data through the Internet. Another way to implement this communication with LabVIEW is using Shared Variables. Shared Variables consist of a way to transmit data between multiple computers using simple coding techniques. They are faster and simpler to implement than similar communication methods.

Shared variables use the Publish-Subscribe Protocol (PSP) which is a form of User Datagram Protocol (UDP).

Sharing these variables is possible due to the Shared Variable Engine (SVE). For stand alone applications based on shared variable, it is necessary to install the SVE separately. For PDA devices it is also necessary to install the support for shared variables [8].

The SVE is where a variable resides on a computer. It manages the network communication and bindings, all of which can be configured from within LabView. Shared variables are an easy way to transfer data between targets over a network due to its high level easy configuration and set up interfaces.

Shared variable servers use UDP port 2343 and a range of UDP ports from 6000 to 6010 for incoming and outgoing packets and the clients use a range of UDP ports beginning with port 5000. The number of ports above 6000 that the network-published shared variable servers use depends on the number of servers running on the computer. The NI-PSP protocol also uses TCP ports and it begins looking for available TCP ports at port 59110 and increments upward until it finds an available port [8].

[FIGURE 2 OMITTED]

Nevertheless, we justify our approach to implement our application in the TCP/IP transport layer because portability and firewall rules are very important issues when developing such a system. We have experienced several problems when attempting to access labs via SVE from different networks, especially networks from institutions that usually are under a strict firewall policy. We cannot make any assumptions about these policies and try therefore to base our system in standard ports (80) for the communication with the server rather than on several different ports used by the shared variable tools. Figure 2 describes the main differences an considerations taken into account in order to choose the communication technology.

3. The Circuit under Test

The ispPAC10 in-system programmable analog device from Lattice Semiconductor, which is member of a family of analog circuits capable of realizing a variety of popular analog functions including precision low-pass and band-pass filters, amplifiers, oscillators summing, differencing and integration.

Its basic building block contains four integrated programmable analog modules known as PAC blocks and a programmable analog routing pool. Each PAC block emulates a collection of operational amplifiers, resistors and capacitors. The ability to program the internal capacitor values of the ispPAC10 gives the user the flexibility to vary, for example, the gain of a filter, corner frequency, and other characteristics, without the need for external components, hence allowing the designer to realize thousands of distinct analog circuits and filter characteristics from a given circuit architecture.

The ispPAC10 operates within a voltage range that goes from 1 up to 4V. Because all performed experiments were carried out in single ended mode, all the inverter analog inputs were connected to VREFOUT (2.5V).

Its basic building block contains four integrated programmable analog modules known as PACblocks and a programmable analog routing pool. Each PACblock emulates a collection of op amps, resistors and capacitors. The ispPAC10's flexibility permits the user to vary a filter's gain, corner frequency, and other characteristics without the need for external components. The ability to program the internal capacitor values of the ispPAC10 allows the designer to realize thousands of distinct analog circuits and filter characteristics from a given circuit architecture.

The assembled board shown on Figure 3 also contains all necessary circuitry, like voltage regulators and an analog multiplexes to facilitate the selection of inputs to apply signals. It is also possible to make measurements with external devices because jumpers allow the connection of inputs and outputs to coaxial connectors.

[FIGURE 3 OMITTED]

4. The LabVIEW PDA Module

The LabVIEW PDA module is a special add-on delivered by National Instruments that allows the creation of custom, user-defined PDA applications for Palm, Windows Mobile for Pocket PC and Windows CE devices. This can be done by using the LabVIEW programming environment on the same way it is done for a PC application and deploying it to a PDA. It allows also the development of data acquisition applications with Compact Flash and PCMCIA DAQ cards. With the LabVIEW PDA module it is possible to deploy an application with an emulator that can be used to test the application inside a simulated environment that mimics the behavior of the actual PDA. It gives additional flexibility in the design and testing and establishes greater confidence that the applications will behave as intended. It facilitates the development of graphical environments to create custom applications for a multitude of mobile devices and PDAs. The programmer is thus given the choice to select the appropriate operating system of the mobile device before commencing with writing the program.

The LabVIEW PDA module also includes some libraries of sub Vls developed to take advantages of some resources available on PDAs and Smartphones, like short message services (SMS) and telephony. Besides that, it is also possible to use most of the known functions and APIs (Application Programming Interfaces) available when developing applications for PCs.

It is possible to deploy applications with the LabVIEW PDA module for the most common operating systems found for these devices, like Windows Mobile, Palm OS and furthermore it is also possible to deploy it for emulated devices or real ones via the proper synchronization tool (like Microsoft Activesync for Windows Mobile). Figure 4 shows a VI running on an emulated device.

Due to the limited graphical capabilities of these devices, the controls and indicators are sized and scaled and the functions palette is reconfigured.

[FIGURE 4 OMITTED]

5. Conclusion

A new wireless remote lab system was developed to enable students to access experiments via the Internet from their mobile devices. The types of experiments under consideration were mainly electronic circuits at the junior undergraduate level for electrical engineering students.

The most important consideration when designing a remote laboratory client to be accessed by such devices like PDAs and Smartphones is the resource limitation compared to PCs. Therefore it is necessary to optimize the clients for these limitations which lead to a reduction of the features available for such labs.

Remote mobile solutions can be an attractive tool as they offer many different possibilities for applications in industries and e-learning. Wireless mobile experimenters have a great advantage because they are not subjected to limitations of locomotion, but require also a good network (wireless) infrastructure to perform experiments. For that reason, we understand that each situation must be studied within a scenario prior to the implementation.

Moreover, remote systems can be very useful when applied to solutions involving high costs of people and equipment transportation. Different institutes and schools could share experiments and therefore knowledge in an additional manner. Also by using remote solutions it would be possible for universities with less financial resources to take advantages of expensive equipments from other institutions by means of a cooperative network of remote systems.

The work presented with this paper shows one possibility for delivering remote control over one specific device (ispPAC10) to clients running on mobile devices.

Finally we would like to point out, that the solutions shown are applicable also to other labs or experiments in terms of an easy to adapt standard solution.

Received 19 July 2008; Revised 13 December 2008; Accepted 31 December 2008

References

[1] Auer, M. E., Gallent,W(2000). The Remote Electronic Lab as a Part of the Telelearning Concept at the Carinthia Tech Institute (Published work style). Villach, Austria.

[2] Perry, G (1998). Visual Basic 6.0 in 21 days (Book style). Ed. Indianapolis: Sams Publishing..

[3] Unknown (1998). LabView Basics I Course Manual, Austin, TX: National Instruments Corporation.

[4] Unknown (2001). Getting Started with Measurement Studio for Visual Basic, Austin, TX: National Instruments Corporation.

[5] Gallent,W (2000). Remote Electronic Lab (Thesis or Dissertation style), Ms. dissertation, Dept. of Electronics., Carinthia University of Applied Sciences, Villach, Carinthia.

[6] http://www.w3schools.com

[7] Mergl, C (2006). Comparison of Remote Labs in Different Technologies (Thesis or Dissertation style), Ms. Dissertation, Dept. of Electronics., Carinthia University of Applied Sciences, Villach, Carinthia.

[8] URL: http://www.ni.com

[9] Euan D. Lindsay., Malcolm C. Good (2005). Effects of Laboratory Access Modes Upon Learning Outcomes, IEEE Transaction on Education, 48(4) 619-631.

[10] Sabina Jeschke, A.Y., AI-Zoubi, Olivier Pfeiffer., Nicole Natho., Jarir Nsour (2008). Classroom-Laboratory Interaction in an Electronic Engineering Course, 5th International IEEE Conference on Innovations and Information Technology, 1618 December, AI-Ain, United Arab Emirates.

Michael E. Auer (1), Danilo G. Zutin (1)

(1) Carinthia University of Applied Sciences, Austria {auer, dgzutin}@fh-kaernten.at

Prof. Dr.-Ing., Dr.sc. Michael E. Auer, Professor of Electrical Engineering; Head of the Center of Competence Online Labs and Open Learning, Carinthia University of Applied Sciences, Villach, Austria. Prof. Auer earned his Ph.D. and M.S. degrees in electrical engineering and IT from the University of Technology Dresden, Germany. His research interests are in engineering education, real time and network programming, system- and network administration of heterogeneous networks, and remote working environments. He is author or co-author of more than 150 publications and leading member of numerous national and international organizations in the field of online technologies. Prof. Auer has has also teaching positions at the Universities of Klagenfurt (Austria), Amman (Jordan) and Brasov (Romania) and gives lectures in a variety of courses at both the undergraduate and graduate levels. Since 2006 he is President and CEO of the International Association of Online Engineering.

Dipl.- Ing. Danilo Garbi Zutin, Senior Research and team member of the Center of Competence in Online Labs and Open Learning, Carinthia University of Applied Sciences (CUAS), Villach, Austria. Danilo G. Zutin graduated in Electrical Engineering at the State University of Sao Paulo (UNESP), Bauru, Sao Paulo, Brazil and is now a Master student at CUAS where he has been engaged in projects for the development of online laboratories. His research interests are in the field of remote engineering, online labs, remote control of devices and software development for online labs.
COPYRIGHT 2009 Digital Information Research Foundation
No portion of this article can be reproduced without the express written permission from the copyright holder.
Copyright 2009 Gale, Cengage Learning. All rights reserved.

Article Details
Printer friendly Cite/link Email Feedback
Author:Auer, Michael E.; Zutin, Danilo G.
Publication:Journal of Digital Information Management
Article Type:Report
Date:Jun 1, 2009
Words:2868
Previous Article:Students' review of acceptance, usability and usefulness of WebLab-Deusto.
Next Article:Cache pre-fetching and replacement strategies for location dependent data in mobile environments.
Topics:

Terms of use | Privacy policy | Copyright © 2019 Farlex, Inc. | Feedback | For webmasters