User login

Weekly Report - 25/07/14




I fixed the issue I'd been stuck with and got my motes communicating this week!

I received a response from Mátyás Kiss re stm32w support in 6lbr, but this unfortunately wasn't very helpful. I was certain that I had already set my PAN IDs to be identical between my slip-radio (tunnel mote) and client mote. He mentioned the need for a "driver modification" but I am still not sure what he was referring to by this as he never got back to me again after I asked.

I had assumed that the issue was with the slip-radio application, because I could see using Wireshark that DIOs were being received from the remote mote on the tunnel interface of the raspberry pi, but there was no outbound traffic from the router. I figured the problem had to be to do with the stm32w chip somehow, since the router is already known to work on the pi!

While testing several different configurations with the 6lbr router set to debug verbosely, I noticed the slip-radio would drop packets at regular intervals. I had previously read that packet drop logs were normal to see because of corruption over the wireless medium and they could essentially be ignored, but I hadn't noticed at the time that drops were occurring every 60 seconds, likely due to testing many different configurations and not leaving them each running for long enough to obviously identify a pattern. I realised that the frequency lined up with when DIOs are sent out by the remote mote, but this left me confused for days as to how/why they were being dropped at the slip-radio because the devices' PAN IDs matched.

However I eventually realised that it was neither of the motes that were the issue - there is also a PAN ID hardcoded into the router itself; it turned out that was set in a different place and for some reason inconsistent. I had assumed the slip-radio handled everything to do with the LoWPAN, but the router must formulate the packets to begin with and pass them off to be sent.

Time to do some CoAP!