On 8 December 2012 04:11, Sebastian Scheibe <[email protected]
> wrote:
> 1) The last byte of the 6LowPAN frame (packet of Iris node) contains zeros
> and as per Wireshark it is an ICMPv6 RPL option (1-Byte padding). Can this
> be the reason, why the base station does not receive the solicitation
> messages of the IRIS node? Why does that byte padding happen? (How) can I
> fix it?
My bad. The fix is this:
diff --git a/tos/chips/rf212/RF212BarePacketP.nc
b/tos/chips/rf212/RF212BarePack
index 3764047..51459ac 100644
--- a/tos/chips/rf212/RF212BarePacketP.nc
+++ b/tos/chips/rf212/RF212BarePacketP.nc
@@ -12,12 +12,12 @@ implementation
command uint8_t BarePacket.payloadLength(message_t *msg)
{
- return call RadioPacket.payloadLength(msg);
+ return call RadioPacket.payloadLength(msg)+sizeof(rf212_header_t);
}
command void BarePacket.setPayloadLength(message_t *msg, uint8_t len)
{
- call RadioPacket.setPayloadLength(msg, len);
+ call RadioPacket.setPayloadLength(msg, len-sizeof(rf212_header_t));
}
> 2) Next fact, which confuses me are the different flow labels
> (IRIS:0x00002dd5e,
> Tmote: 0x0000fff3d) including different traffic classes (IRIS: ECN=0x00
> DSCP=0x01 -> traffic class=0x04, Tmote: ECN=0x03 DSCP=0x03 -> traffic
> class=0x0f ). Can this point cause discarting the packets of the IRIS node?
>
Interesting. I don't think we ever inspected the flow labels, so I have no
knowledge in this area (and I'm on a different project now, so I don't work
with TinyOS at this point).
> Did anybody test heterogeneous Blip2.0 networks yet using RF230 and
> CC24020 hardware or something similar to it?
>
Only homogenous RF212 networks here, sorry.
Regards,
/Johny
--
Johny Mattsson
Senior Software Engineer
DiUS Computing Pty. Ltd.
*where ideas are engineered
*
_______________________________________________
Tinyos-help mailing list
[email protected]
https://www.millennium.berkeley.edu/cgi-bin/mailman/listinfo/tinyos-help
