Skip to content
This repository has been archived by the owner on Aug 25, 2020. It is now read-only.

Frequently Asked Questions

Jump to bottom
danbim edited this page Sep 18, 2012 · 39 revisions

General Questions

I Think I Found a Bug, Where Can I Post It?

In the issue tracker. Please make sure to check the existing issues so that issues are not posted twice.

Is There a Mailing List?

Yes, there is! Please see Mailing List for details.

How Can I Contribute?

Easily! The only thing you need is a github account and you're ready to go. If you want to contribute documentation please simply edit the Wiki. Please check Contributing for more information if you want to contribute code.

How Can I Use Serial Port Autodetection?

Please see Serial Port Autodetection.

How Can I Customize the Logging Behavior?

Please see Logging Customization.

Is it possible to use embedded systems like Alix as gateway hosts in my testbed infrastructure?

Sure it is! We tested the deployment of a small-scale testbed with 1 testbed server and 1 Alix acting as a gateway, with a few telosb nodes connected to it. We used the linux voyage distribution on our Alix, so if you use that one you should not have any problem. For details on installation and configuration, just follow the instructions, there is no difference in using an embedded system or a standard pc!

When running TR from my IDE the connection to the Session Management Service hangs

This behavior has been observed at least on Mac computers depending on the current connectivity status (WLAN, Ethernet, ...). Sometimes the TCP connection to the service is made but then no data is transmitted between Web service client and server and eventually the connection times out. This can be fixed by not binding to all network interfaces (i.e. not using 0.0.0.0 as binding IP address). Please pass the command line parameter -DdisableBindAllInterfacesUrl to the JVM when starting TR to disable binding to all interfaces.

Can I specify a default image that is automatically flashed to the nodes after a reservation is over?

Yes, you can (since 0.8.4)! Everything you have to do in order to do so is to specify the path to the default image file in conf/tr.iwsn-testbed.xml as in the following example:

<application name="WSNDeviceApp" factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory">
  <wsn:wsnDevice xmlns:wsn="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
    <urn>urn:local:0x1234</urn>
    <type>isense39</type>
    <defaultImage>/full/path/to/the/defaultimage.bin</defaultImage>
  </wsn:wsnDevice>
</application>

Can I listen to node outputs without a reservation?

There are two answers to this question:

  1. There will be a standardized official API in the next WISEBED API release. However, until this API is fully defined and the implementation is done some time will likely pass by.

  2. Until then: If you're the testbed provider (i.e. you run the testbed) there's an unofficial way to do this. Simply put the following configuration snippet in your tr.iwsn-testbed.xml in the <applications>-section:

<application name="SocketConnector" factoryclass="de.uniluebeck.itm.tr.runtime.socketconnector.server.SocketConnectorApplicationFactory">
<sc:socketconnector xmlns:sc="http://itm.uniluebeck.de/tr/runtime/socketconnector/server/xml">
  <port>1234</port>
</sc:socketconnector>
</application>

Introducing the SocketConnector will create a ServerSocket on the configured port to which any client application speaking the internal Testbed Runtime protocol can connect. SocketConnectorClient 0.8.4 is a sample client application that uses the overlay protocol spoken between the testbed hosts and the application-level protocol spoken between the Web Service endpoint and the gateway hosts.

My iSense device is recognized as "xbee" device and therefore not working

This is a known issue if you're using the new iSense gateway module 2. Testbed Runtime uses the wsn-device-utils to detect which devices are attached to which serial port. Sensor nodes usually have a USB<->serial converter on board that delivers some identification. Unfortunately, this identification is very similar to the xbee identification. Currently, the only solution is to download the FT_PROG application from the FTDI website. Then rewrite the EEPROM so that:

  1. The field "Serial Number" (FT EEPROM -> USB String Descriptors) must start with "IS" (e.g. ISVP08JZ). The suffix may be automatically generated by the tool or set by you manually.
  2. The field "Product Description" must be set to the string "isense-gateway-module-2".

Testbed Runtime (starting with 0.8.5) should then correctly identify the attached device by either matching the prefix (MAC OS X) or the product description (Linux).

FT_PROG Screenshot

Is there something as a simulated device so I can test my testbed setup without real hardware?

The "MockDevice" is doing exactly this. Below you find some example lines for the applications-section in the tr.iwsn-testbed.xml file that will lead to having a mocked device:

<application name="WSNDeviceApp-urn:local:0x0001" factoryclass="de.uniluebeck.itm.tr.runtime.wsnapp.WSNDeviceAppFactory">
  <wsn:wsnDevice xmlns:wsn="http://itm.uniluebeck.de/tr/runtime/wsnapp/xml">
    <urn>urn:local:0x0001</urn>
    <portalurn>urn:local:portal</portalurn>
    <type>mock</type>
    <configuration key="BOOT_MESSAGE" value="Hello, Local Testbed!" />
    <configuration key="BOOT_MESSAGE_TYPE" value="ascii" />
    <configuration key="HEARTBEAT_MESSAGE" value="I'm alive!" />
    <configuration key="HEARTBEAT_MESSAGE_TYPE" value="ascii" />
    <configuration key="HEARTBEAT_MESSAGE_RATE" value="10000" />
    <configuration key="ECHO" value="true" />
  </wsn:wsnDevice>
</application>

The following table describes the parameters and their purpose:

Parameter Name Description
BOOT_MESSAGE Defines what bootup message should be sent by the device after reset.
BOOT_MESSAGE_TYPE Defines how the value of BOOT_MESSAGE should be interpreted before conversion to the actual byte array that the mock device shall output. Valid values are either "ascii" or "binary" (the latter being the well-know string representation of byte values in space-delimited decimal, hexademical or binary, e.g., 0x0A 0x1B 0b11001001 40 40 0b11001001 0x1F).
HEARTBEAT_MESSAGE Defines what message to send periodically at HEARTBEAT_MESSAGE_RATE.
HEARTBEAT_MESSAGE_TYPE cf. BOOT_MESSAGE_TYPE
HEARTBEAT_MESSAGE_RATE The number of milliseconds after which a new heartbeat message is sent.
ECHO If set to ```true```, the mock device will simply echo all bytes received through its (mocked) serial port.

Make sure to also add an appropriate entry to the testbeds WiseML file (typically tr.iwsn-wiseml.xml) so that client applications can learn about the availability of the device.

Troubleshooting

There are no troubleshooting entries yet for Testbed Runtime. However, please also check the wsn-device-drivers FAQ and the wsn-device-utils Wiki to check if they contain something that might help you! If that doesn't help please check the issue tracker first to see if the issue is already known and/or contact the mailing list for help.

Clone this wiki locally