At the moment, riftd requires a somewhat specific configuration for new radios. Currently, it requires the following attributes to be set on a standard XBee radio:
PAN IDs must be the same for any peer connectivity; for ease of use, this is assumed to be 0xFFFF, which effectively transmits on all PANs
DH and DL must be set to 0x0 to force 64-bit addressing mode
MY must be set to 0xFFFF to disable receiving non-64-bit transmissions
RR must be set to 0x0 to use default 802.15.4 MAC retries
CE must be set to 0x0 to configure this device as an "end device"
AP must be set to 0x1 to enabled "API mode"
Additionally, these attributes are not currently used, but may be used in the future:
SH and SL may be read in the future in order to easily obtain the current device's local IPv6 address
MM may be modified for strict 802.15.4 adherence
EE and KY may be modified to enable AES encryption
PL and SM may be modified to switch between varying power and sleep modes for transmission
BD may be modified to support higher baud rates
As such, it would be ideal to build out a simple subcommand to riftd for auto-configuring the correct attributes for a new radio device (as hardware vendor configuration utilities are a bit obnoxious to use at times).
jerluc
commented
7 years ago
At the moment, riftd requires a somewhat specific configuration for new radios. Currently, it requires the following attributes to be set on a standard XBee radio:
0xFFFF, which effectively transmits on all PANs0x0to force 64-bit addressing mode0xFFFFto disable receiving non-64-bit transmissions0x0to use default 802.15.4 MAC retries0x0to configure this device as an "end device"0x1to enabled "API mode"Additionally, these attributes are not currently used, but may be used in the future:
As such, it would be ideal to build out a simple subcommand to riftd for auto-configuring the correct attributes for a new radio device (as hardware vendor configuration utilities are a bit obnoxious to use at times).