Frequently Asked Questions
In the issue tracker. Please make sure to check the existing issues so that issues are not posted twice.
Yes, there is! Please see Mailing List for details.
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.
Please see Serial Port Autodetection.
Please see Logging Customization.
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!
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>
There are two answers to this question:
-
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.
-
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.xmlin 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.
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:
- 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.
- 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).
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.
On iSense nodes sometimes the MAC address gets corrupted (issue #352, typically resulting in a 0xFFFF address) by a corrupted node image. By default, the gateway process typically recognizes nodes by reading the MAC address that is stored on the core modules flash memory. It then looks up the configuration for this node in the DeviceDB (http(s)://YOUR_PORTAL_HERE/admin/devicedb). This way, when the MAC gets corrupted the gateway can not recognize a node anymore.
An alternative is to use the serial number string descriptor stored on the serial-to-USB converter FTDI chip instead. This descriptor can not be broken by a corrupted image but has to be set-up manually using e.g., "FTProg" from FTDI to overwrite the EEPROM. Using this, the gateway process can detect a broken MAC address (comparing the actual MAC address and the MAC address configured in the DeviceDB for a given serial number) and automatically "repair" the MAC address.
Therefore, in order to use this mechanism the nodes gateway module (that has the serial-to-USB converter chip on it) must be manually set up. Use FTProg to set up "Product Description" to either "isense39" (for Core Module 1 & 2 employing the JN5139R1 controller) or "isense48" (for Core Module 3 employing the JN5148 controller). Let either FTProg generate a "Serial Number" for you or set it manually (untick the "Auto Generate Serial No" box, reprogram the EEPROM:
Then go to the DeviceDB admin page (http(s)://YOUR_PORTAL_HERE/admin/devicedb) and edit the device configuration to include the serial number in the "USB Chip ID" field:
Once these things are configured the gateway will automatically check the nodes MAC address during startup and after each flash operation, repairing it when necessary. The MAC address is taken from the node URN suffix (e.g. the MAC address of node "urn:wisebed:uzl1:0x2000" is 0x2000).
Please note: As there is an additional MAC read operation after every flash operation the flashing operation takes longer to complete. DeviceDB features a set of timeout settings (including one for the flash operation) after which TR will regard the operation as failed if it has not completed yet. It might therefore be necessary to increase the timeout for the flash operation.
Please also note: This feature is available since May, 14th, 2014 from the newest build of the develop branch. All future releases (including 0.9) will support it.
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.