Rime examples with CXMAC in Contiki 3.0

[mikirockerful]

Hello all,

I am trying to get running the example of rime 'example-unicast.c' on a simulated Zolertia Z1 mote in Cooja. I have managed to do it with ContikiMAC as the RDC protocol, but when I try to use CXMAC instead, all messages are lost. I am a bit confused about this as CXMAC is a protocol that I have managed to get working with similar configuration in previous versions of Contiki, so any help in how to correctly set it up would be appreciated.

To configure CXMAC, I have set NETSTACK_CONF_RDC as cxmac_driver in the 'contiki-conf.h' file specific to the z1 platform. I have also added the cxmac module in 'Makefile.z1', by adding: 'core/net/mac/cxmac'. Compilation is successful, but gives the following warnings:

../../dev/cc2420/cc2420.c:528:3: warning: initialization from incompatible pointer type [enabled by default] ../../dev/cc2420/cc2420.c:528:3: warning: (near initialization for ‘cc2420_aes_128_driver.set_key’) [enabled by default] ../../cpu/msp430/./cc2420-arch-sfd.c: In function ‘cc2420_timerb1_interrupt’: ../../cpu/msp430/./cc2420-arch-sfd.c:44:7: warning: variable ‘tbiv’ set but not used [-Wunused-but-set-variable] ../../dev/sht11/sht11.c: In function ‘sht11_init’: ../../dev/sht11/sht11.c:218:4: warning: #warning SHT11: DISABLING I2C BUS [-Wcpp]

The Cooja simulation consists of 2 motes within radio range. Their ID's are respectively 1 and 2, so mote 2 should send messages to mote 1. They both have the application 'example-unicast.c', and this same setting using ContikiMAC works well. With CXMAC, I can clearly see in the timeline the successive probes from 1 to 2 and the probe in response from 2 indicating that it is expecting the data, but the packet is never sent.

Thank you very much in advance.

Best regards, Miguel Gamallo

[alignan]

Those warnings I think were removed already, as Contiki now is warning free, so perhaps you should use a fresh commit from the repository. Nevertheless I don't think any of these warnings are the cause of the problem.

I don't know for sure, but I think CXMAC is not actively supported nowadays, you should ask on the Contiki mailing list instead. I'm keeping this topic open only pending to confirm the CXMAC status.

[DivadD7]

Hi,

For a school project we had to do some tests with contikimac and cxmac in cooja on contiki 3.0. And we also found out cxmac was not working properly. So our project changed to try and fix cxmac.

The problem is in the ACK. On line 772 in cxmac.c file, the hdr type gets set. Now for some reason the type is not added to the packetbuffer. So we "fixed" this by adding some code similar to how the type for the strobe gets added to the packetbuffer (see lines 460-462).

  /* This is a strobe packet for us. */

/* If the sender address is someone else, we should
   acknowledge the strobe and wait for the packet. By using
   the same address as both sender and receiver, we flag the
   message is a strobe ack. */
hdr->type = TYPE_STROBE_ACK;
packetbuf_set_addr(PACKETBUF_ADDR_RECEIVER,
           packetbuf_addr(PACKETBUF_ADDR_SENDER));
packetbuf_set_addr(PACKETBUF_ADDR_SENDER, &linkaddr_node_addr);
packetbuf_compact();
int ackylen = NETSTACK_FRAMER.create();
if( ackylen>= 0) {
  /* We turn on the radio in anticipation of the incoming
     packet. */
  someone_is_sending = 1;
  waiting_for_packet = 1;
  on();
  uint8_t acky[ackylen+2];
  memcpy(acky, packetbuf_hdrptr(), ackylen);
  acky[ackylen] = DISPATCH; /* dispatch */
  acky[ackylen + 1] = TYPE_STROBE_ACK; /* type */
  NETSTACK_RADIO.send(acky, ackylen+sizeof(struct cxmac_hdr));
  PRINTDEBUG("cxmac: send strobe ack %u\n", packetbuf_totlen());
} else {
  PRINTF("cxmac: failed to send strobe ack\n");
}

This method worked for us as fas as we can tell (we're just students who have been messing with contiki for a few weeks).

However even after this mote 2 still reports: "cxmac: data(0)" This can be fixed by setting the datalength (line 717):

` static void input_packet(void) { struct cxmac_hdr *hdr; int dataylen = packetbuf_datalen(); int temp = NETSTACK_FRAMER.parse();

if(temp >= 0) { hdr = packetbuf_dataptr(); dataylen -= temp; packetbuf_set_datalen(dataylen); if(hdr->dispatch != DISPATCH) { someone_is_sending = 0; if(linkaddr_cmp(packetbuf_addr(PACKETBUF_ADDR_RECEIVER), &linkaddr_node_addr) || linkaddr_cmp(packetbuf_addr(PACKETBUF_ADDR_RECEIVER), &linkaddr_null)) { /* This is a regular packet that is destined to us or to the broadcast address. */

 /* We have received the final packet, so we can go back to being
    asleep. */
 off();`

After doing this cxmac seemes to work fine in cooja. Our guess is that there have been some changes in the parser from 2.5 to 3.0 that cause these problems.

Hope this helps some people.

Kind regards,

Axel Rombauts & me (David De Roey)