-
Notifications
You must be signed in to change notification settings - Fork 3
Baloo debugging
This page is currently under construction. At this stage, the information included here has no guarantee of being complete nor correct.
This page contains common problems you may encounter while using Baloo. And how to solve them.
When the host starts, nothing seems to happen, with no failure message.
The problem might be that you are misconstructing the control packet. Typically, the schedule overwrites the config section. As a result, the middleware does not find any valid configuration to start and stops.
What do to? Verify that you are setting the correct size for your control schedule section, using
#define GMW_CONF_MAX_SLOTS
This define is used in the declaration of the gmw_control_t type.
Schedule and config information seem fine, but no packet is actually transmitted by the radio. In Glossy mode, glossy is started, but the initiator does not TX.
Likely, the problem is with your radio configuration. The packet you are trying to send might be bigger than the maximal packet size your radio is configured to send.
This configuration is controlled by the following defines, which refer to the payload size in Bytes of the control and data packets respectively.
#define GMW_CONF_MAX_CONTROL_PKT_LEN
#define GMW_CONF_MAX_DATA_PKT_LEN
Make sure to set those to the correct values for your application. The middleware will take care to correctly set the radio based on those parameters.
If the source and host node are in close proximity of each other, the source node might fail to bootstrap. Reduce the TX power or increase the distance between the nodes.
There is currently an issue in the case glossy_stop() is called during the first TX phase of a receiving node. It may happen that the received payload will not be copied into the packet buffer, while the packet was received correctly in the preceding RX phase.
As a consequence, Baloo will return an GMW_EVT_PKT_OK, since the receive counter is not zero, but the payload is garbage (either the previous packet, or 0 if GMW_CONF_USE_AUTOCLEAN is set).
As a workaround, check whether the received payload is valid in your protocol implementation! That is usually a good thing to do anyway...
Note: This should have been solved. To double-check.
There is a bug with the dc-stat.h for the sky mote. DCSTAT_CPU_ON does not work properly and break sensitive timing (currently unknown reason).
What do to? Use energest instead.
At times, the time returns by energest are buggy. The cause is likely because of some missing/misplaced ENERGEST_ON and ENERGEST_OFF calls in the radio driver (rf1a.c).
What do to? Use DCSTAT instead.
This concludes the overview of how to program with Baloo.
Advanced functionalities are described in the Advanced features pages.