Troubleshooting/FAQ

From NESTFE Wiki

Troubleshooting FAQ

This page is meant for documenting obscure error messages when working with the Trio nodes, and what they could possibly mean. See the related page Trio_Programming_Errors.

1. • Q: I am using Pytos. Initially, I get some messages back from the network for about half a minute. Then, all of a sudden, I hear nothing back from the network except for drip messages from when I send a query.
   • A: Are you using the TOSBase in tinyos-1.x/nestfe/nesc/apps/TOSBase? This tosbase (which is the one you are suppose to use for the Trio nodes in the NEST final demo, by the way) acknowledges packets for the drain tree. Pytos automatically builds a drain tree to route messages back. It assumes that the moteID of the root node of the drain tree, the TOSBase, is 65534 unless you specify otherwise upon starting up Pytos (specify the returnAddress ). Check that you actually use this moteID for your TOSBase.
2. • Q: I am running Pytos. There are multiple programs out on the network, and I am running queries using the build directory of only one of the programs. On some registry queries, I manage to crash java such that I no longer get any responses back, despite getting packets back from my queries. The crash error message is

>>> app.RegistryC.Location.get() Incorrect number of bytes for TosMsg. Byte conversion error: location_t 1 bytes to 8 java.lang.RuntimeException: Python exception thrown

       at jpype.JPypeInvocationHandler.hostInvoke(Native Method)
       at jpype.JPypeInvocationHandler.invoke(Unknown Source)
       at $Proxy0.messageReceived(Unknown Source)
       at MessageListenerObject.messageReceived(MessageListenerObject.java:39)
       at net.tinyos.drain.DrainConnector.messageReceived(DrainConnector.java:89)
       at net.tinyos.message.Receiver.packetReceived(Receiver.java:218)
       at net.tinyos.packet.PhoenixSource.dispatch(PhoenixSource.java:160)
       at net.tinyos.packet.PhoenixSource.packetDipatchLoop(PhoenixSource.java:152)
       at net.tinyos.packet.PhoenixSource.run(PhoenixSource.java:169)

1. • A: It is possible that a node with a different program from the one you're running Pytos with returned a packet (request packets are just bits, and they may happen to mean a different request for these other nodes). This packet may have the wrong length, which in turn crashes your java tool.
2. • Q: I've just written a new program that uses the PIR sensor. However, the nodes are dead when reprogrammed with this image.
   • A: Did you call PIR.PIROn() in either StdControl.init() or StdControl.start()  ? You must use a timer to give an initial wait period (for other subsystems to start up properly) before starting up the PIR sensor. A period of 500 ms has been observed to be safe.
3. • Q: I programmed TestDetectionEvent, but I don't get any events back over TOSBase.
   • A: TestDetectionEvent currently defaults to sending DummyDetection Events over the UART. See Detection Demo on how to change the behavior of the application using Pytos.
4. • Q: I am running the Matlab applications that receive messages from the mote network and processs them. However, whenever I send a pytos query, I get error messages about the message length being incorrect on my matlab console.
   • A: Ignore the error messages. The way that embedded packets, like DetectionEventMsg packets embedded in DrainMsg packets, are parsed in Matlab is a hack because the MIG tool does not yet support embedded packets. We actually have to create the embedded drain packets manually (currently, it is assumed that we have only one type of embedded packet in a drain packet). The java tools underneath do not actually filter out the embedded packets for us, and hence when we get a drain packet that is a response to a pytos query which may not be the same length as the packet we are expecting for matlab.
5. • Q: I can't program the mote. It gives me an error occoured error message.
   • A: Did you plug in the mote to USB first for a minute before trying to program it? The capacitor on the mote needs to be charged. Or, your mote may be broken.
6. • Q: I just deluged an image onto the nodes and rebooted to that image. Now, all of a sudden, I can't communicate with any of the motes!
   • A: What channel and group id was your new image compiled on? While deluge transfers node id and group id from the previous image to the new image (copies it over before running. see the deluge manual in tinyos-1.x/docs ), it does not transfer the radio channel to the new image.
7. • Q: I keep seeing a log4j error, and no messages from the Java tools.
   • A: Create a file called "log4j.properties" in one of your $CLASSPATH directories (perhaps contrib/nucleus/tools/java) with these 4 lines:

log4j.rootCategory=INFO, dest1
log4j.appender.dest1=org.apache.log4j.ConsoleAppender
log4j.appender.dest1.layout=org.apache.log4j.PatternLayout
log4j.appender.dest1.layout.ConversionPattern=%-4r %-5p [%t] %c %x - %m%n

You can change that INFO to DEBUG for detailed messages, or to WARN for practically no messages.

FAQ

1. • Q: How do I set the CC2420 Channel during compilation?
   • A: Set the environment variable (or your makelocal file) CC2420_CHANNEL = 0x11 to set to channel 0x11. For example, at the command prompt
     CC2420_CHANNEL=0x11 make telosb
2. • Q: How do I query the voltage of a node's capacitor or battery using Pytos?
   • A: >> app.PrometheusM.volCap.peek()
     >> app.PrometheusM.volBatt.peek()
3. • Q: How do I find the group id of a compiled image?
   • A: grep AM_GROUP build/telosb/app.c and looking at the result of TOS_AM_GROUP .
4. • Q: How do I find the CC2420 channel of a compiled image?
   • A:
     grep -n -A1 "gCurrentParameters\[CP_FSCTRL\] = (1 << " build/telosb/app.c .
     This should match the file tinyos-1.x/tos/lib/CC2420Radio/CC2420ControlM.nc with the lines

gCurrentParameters[CP_FSCTRL] = ((1 << CC2420_FSCTRL_LOCK) | ((357+5*(CC2420_DEF_CHANNEL-11)) << CC2420_FSCTRL_FREQ)); For instance, one such query might return

 
11639:  CC2420ControlM$gCurrentParameters[CP_FSCTRL] = (1 << 14) | ((
11640-  357 + 5 * (11 - 11)) << 0);

 

Signifying that CC2420_CHANNEL is 11.