Protocol-Specific Features#

IEEE 802.15.4#

RAIL provides IEEE 802.15.4-specific hardware acceleration that can be configured through RAILtest commands. To configure the IEEE 802.15.4 2.4 GHz Radio Configuration, use config2p4GHz802154. This will configure the IEEE 802.15.4 2.4 GHz modem settings as well as channel scheme, making channels 11-26 available for use. To configure IEEE 802.15.4 hardware acceleration, use the enable802154 command. The options exposed in enable802154 allow you to configure similar parameters as autoAckConfig.

Indeed, Auto-ACK is enabled when calling enable802154. Thus, do not call setRxTransitions or setTxTransitions after an enable802154 while Auto-ACK is enabled.The IEEE 802.15.4 ACK payload is already loaded into the ACK buffer; do not call setAckPayload or setAckLength. However, you will want to enable the Wait-For-ACK transmit option through configTxOptions so the hardware looks for the specific ACK corresponding to the transmitted packet. RAILtest is configured to always set frame pending bit in the ACK if it successfully receives a data command to the node. Any ACK modifications should use commands detailed in section Auto Acknowledgment.

To configure the IEEE 802.15.4 SubGHZ SUN FSK GB868 mode (802.15.4e and 802.15.4g), use 'config863MHz802154' or 'config915MHz802154'. The different options can be configured using set802154e and set802154g commands. These commands map very closely to the RAIL API that it wraps, so refer to the RAIL Library doxygen for further information.

Further IEEE 802.15.4 configuration is done through acceptFrames, setPromiscuousMode, and setPanCoordinator. To configure the node's address, use the setPanId802154, setShortAddr802154, or setLongAddr802154 commands. These commands map very closely to the RAIL API that it wraps, so refer to the RAIL Library doxygen for further information.

From this point, use the normal tx and rx commands to send packets back and forth.

Transmit side:

> rx 0
{{(rx)}{Rx:Disabled}{Idle:Enabled}{Time:1846852}}
> config2p4GHz802154
{{(config2p4GHz802154)}{802.15.4:Enabled}}
> enable802154 rx 100 192 1000
{{(enable802154)}{802.15.4:Enabled}{rxDefaultState:Rx}{txDefaultState:Rx}{idleTiming:100}{turnaroundTime:192}{ackTimeout:1000}}
// Turn on transmit wait-for-ACK option
> configTxOptions 1
{{(configTxOptions)}{waitForAck:True}{removeCrc:False}{syncWordId:0}{txAntenna:Any}{altPreambleLen:False}{ccaPeakRssi:False}}

// Load packet directed towards the receive side
// Packet has the destination address set on the receive side.
> setTxLength 26
{{(setTxLength)}{TxLength:26}}
> setTxPayload 0 0x1b 0x61 0x98 0x00 0x34 0x12 0x44 0x33 0x55 0x44
{{(setTxPayload)}{len:26}{payload: 0x1b 0x61 0x98 0x00 0x34 0x12 0x44 0x33 0x55 0x44 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00 0x00}}
> setTxPayload 10 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09
{{(setTxPayload)}{len:26}{payload: 0x1b 0x61 0x98 0x00 0x34 0x12 0x44 0x33 0x55 0x44 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x00 0x00 0x00 0x00 0x00 0x00}}
> setTxPayload 20 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f
{{(setTxPayload)}{len:26}{payload: 0x1b 0x61 0x98 0x00 0x34 0x12 0x44 0x33 0x55 0x44 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f}}

// Assumes there is another node that will receive and ACK
> tx 1
> {{(tx)}{PacketTx:Enabled}{None:Disabled}{Time:157683158}}
{{(appMode)}{None:Enabled}{PacketTx:Disabled}{Time:157689582}}
{{(txEnd)}{txStatus:Complete}{transmitted:1}{lastTxTime:157689516}{failed:0}{lastTxStatus:0x0}{isAck:False}}
{{(rxPacket)}{len:4}{timeUs:157689914}{crc:Pass}{rssi:-20}{lqi:96}{phy:0}{isAck:True}{syncWordId:0}{antenna:0}{channelHopIdx:254}{payload: 0x05 0x02 0x00 0x00}}

// Assumes a node does not ACK
> tx 1
> {{(tx)}{PacketTx:Enabled}{None:Disabled}{Time:165139148}}
{{(rxAckTimeout)}{ackTimeoutDuration:1021}}
{{(appMode)}{None:Enabled}{PacketTx:Disabled}{Time:165187375}}
{{(txEnd)}{txStatus:Complete}{transmitted:1}{lastTxTime:165145515}{failed:0}{lastTxStatus:0x0}{isAck:False}}

Receive side:

> rx 0
{{(rx)}{Rx:Disabled}{Idle:Enabled}{Time:1846852}}
> config2p4GHz802154
{{(config2p4GHz802154)}{802.15.4:Enabled}}
> enable802154 rx 100 192 1000
{{(enable802154)}{802.15.4:Enabled}{rxDefaultState:Rx}{txDefaultState:Rx}{idleTiming:100}{turnaroundTime:192}{ackTimeout:1000}}
> setPanId802154 0x1234 // PANID: 0x1234, OTA Value: 0x34 0x12
{{(setPanId802154)}{802.15.4PanId:Success}}
> setShortAddr802154 0x3344 // Short Addr: 0x3344, OTA Value: 0x44 0x33
{{(setShortAddr802154)}{802.15.4ShortAddress:Success}}
// Long Addr (OTA): 0xDD 0xCC 0xBB 0xAA 0x99 0x88 0x77 0x66
> setLongAddr802154 0xDD 0xCC 0xBB 0xAA 0x99 0x88 0x77 0x66
{{(setLongAddr802154)}{802.15.4LongAddress:Success}}
> rx 1
{{(rx)}{Rx:Enabled}{Idle:Disabled}{Time:2070858}}

// Receive a packet and ACK it
{{(rxPacket)}{len:26}{timeUs:29662246}{crc:Pass}{rssi:-15}{lqi:82}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:254}{payload: 0x1b 0x61 0x98 0x00 0x34 0x12 0x44 0x33 0x55 0x44 0x00 0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f}}

In 802.15.4, the first byte(s) written in the Tx buffer correspond to the PHR (physical header) and must follow a precise mapping, including at least the frame length. Formatting the PHR can be laborious and is error prone. Silicon Labs recommends using 'set802154PHR'.

For instance, in SUN FSK, to set this PHR:

| bit0 bit15|

| mode switch | reserved | FCS type | data whitening | frame length |

| 0 | 00 | 0 | 1 |20=000 0001 0100|

you can use:

> setTxLength 18  //must be >= frameLength+PHRsize-FCSsize
{{(setTxLength)}{TxLength:18}{TxLength Written:18}}
> setTxPayload 0 0x10 0x28
{{(setTxPayload)}{len:18}{payload: 0x10 0x28 0x11 0x22 0x33 0x44 0x55 0x0f 0x77 0x88 0x99 0xaa 0xbb 0xcc 0xdd 0xee 0x10 0x11}}

Or

> setTxLength 18  //must be >= frameLength+PHRsize-FCSsize
{{(setTxLength)}{TxLength:18}{TxLength Written:18}}
> set802154PHR 1 0 1
{{(set802154PHR)}{PhrSize:2}{PHR:0x2810}}
{{(set802154PHR)}{len:18}{payload: 0x10 0x28 0x11 0x22 0x33 0x44 0x55 0x0f 0x77 0x88 0x99 0xaa 0xbb 0xcc 0xdd 0xee 0x10 0x11}}

Note that 'set802154PHR':

  • Only formats (and writes in the Tx buffer) the PHR. It does not check that the requested PHR format is coherent with the loaded PHY.

  • Uses the TxLength value (set with 'setTxLength') to process the PHR frame length field.

  • If the FCS size is known, then it set it to TxLength-PHRsize+FCSsize.

  • If the FCS size is not known, then it set it to TxLength-PHRsize (SUN OFDM and SUN OQPSK cases).

Note that the PHR value is interpreted by the HW both in Tx and Rx to dynamically adapt the processing.

Typical SUN OFDM usage:

> setTxLength 64
{{(setTxLength)}{TxLength:64}{TxLength Written:64}}
> Set802154phr 2 6 0
{{(set802154phr)}{PhrSize:4}{PHR:0x780c00}}
{{(set802154phr)}{len:64}{payload: 0x00 0x0c 0x78 0x00 0x33 0x44 0x55 0x0f 0x77 0x88 0x99 0xaa 0xbb 0xcc 0xdd 0xee 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f 0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f}}
> tx 10
{{(tx)}{PacketTx:Enabled}{None:Disabled}{Time:3116912126}}
{{(appMode)}{None:Enabled}{PacketTx:Disabled}{Time:3117028916}}
{{(txEnd)}{txStatus:Complete}{transmitted:10}{lastTxTime:3117028845}{timePos:6}{lastTxStart:3117026790} {ccaSucess:0}{failed:0}{lastTxStatus:0x000000000}{isAck:False}}

To use 802.15.4 filtering with SUN OFDM PHYs on Rx side

> rx 0
{{(rx)}{Rx:Disabled}{Idle:Enabled}{Time:3470713331}}
> Enable802154 rx 200 1000 2000
{{(Enable802154)}{802.15.4:Enabled}{rxDefaultState:Rx}{txDefaultState:Rx}{idleTiming:200}{turnarounTime:1000} {ackTimeout:2000}{defaultFramePending:False}}
> set802154e 3
{{(set802154e)}{15.4E_GB868:True}{15.4E_EnhAck:True}{15.4E_ImplicitBroadcast:False}}
> setPanId802154 0xCDAB
{{(setPanId802154)}{802.15.4PanId:Success}}
> setLongAddr802154 0x12 0x34 0x56 0x78 0x12 0x34 0x56 0x78
{{(setLongAddr802154)}{802.15.4LongAddress:Success}}

on Tx side

> SetTxPayload 4 0x01 0x2D 0xAB 0xCD 0x12 0x34 0x56 0x78 0x12 0x34 0x56 0x78
{{(SetTxPayload)}{len:64}{payload: 0x00 0x0c 0x78 0x00 0x01 0x2d 0xab 0xcd 0x12 0x34 0x56 0x78 0x12 0x34 0x56 0x78 0x10 0x11 0x12 0x13 0x14 0x15 0x16 0x17 0x18 0x19 0x1a 0x1b 0x1c 0x1d 0x1e 0x1f 0x20 0x21 0x22 0x23 0x24 0x25 0x26 0x27 0x28 0x29 0x2a 0x2b 0x2c 0x2d 0x2e 0x2f 0x30 0x31 0x32 0x33 0x34 0x35 0x36 0x37 0x38 0x39 0x3a 0x3b 0x3c 0x3d 0x3e 0x3f}}

To use continuous Tx (setTxStream) with SUN OFDM PHYs:

  • All modes listed in RAIL_StreamMode_t from 0 to 5 are supported except the 1010 stream option.

  • the PHR is interpreted to get the rate, scrambler and frameLength parameters. Thus take care to always format it correctly and load it in the TxFIFO.

  • to get a packet of infinit length, PHR frameLength must be set to 0. For that txLength must be set to 4

    > setTxLength 4

    {{(setTxLength)}{TxLength:4}{TxLength Written:4}}

    > set802154Phr 2 4 0

    {{(set802154Phr)}{PhrSize:4}{PHR:0x400}}

    {{(set802154Phr)}{len:4}{payload: 0x00 0x04 0x00 0x00}}

    > setTxStream 1

    {{(setTxStream)}{Stream:Enabled}{None:Disabled}{StreamMode:PN9}{Time:2504841818}}

  • If PHR frameLength is set to a value different from 0, it generates an infinite number of packets of size 'frameLength' with an IFS of 1ms.

  • for a stream with data filled with a ramp started at a different offset for successive packets:

    > setTxstream 1 4

  • To send a tone at the carrier frequency:

    > setTxTone 1

    it is equivalent to

    > setTxstream 1 0

  • For an OFDM PHY the tone can also be generated roughly at channel_bandwidth/6

    > setTxstream 1 5

WiSUN Specific#

WiSUN is based on IEEE802.15.4 SUN PHYs but with a specific mode switch protocol.

Two commands support the WiSUN mode switch: trigModeSwitchTx and modeSwitchLife.

modeSwitchLife is optional and intended only for test automation or certification use.

You can also activate two specific Rx events MODE_SWITCH_START and MODE_SWITCH_END. >Note: that they need to be enabled if modeSwitchLife is set to 1.

For Rx events MODE_SWITCH_START and MODE_SWITCH_END activation:

> setEventConfig 0x0 0x0 0x6000 0x6000

{{(setEventConfig)}{Mask:0x600000000000}{Values:0x600000000000}}

Concurrent Listening Specific#

802.15.4 concurrent listening allows one radio switching quickly enough between RF channels to detect 802.15.4 preamble on either RF channel. This allows the application to use two 15.4 channels concurrently. Once preamble is detected, the radio stays on channel to receive the packet. It will also provide an ACK, if configured, and schedule any subsequent TX responses before resuming concurrent listening.

To configure concurrent listening the following RAILtest commands must be issued:

// Setup 802.15.4 on the RX side.
> rx 0
{{(rx)}{Rx:Disabled}{Idle:Enabled}{Time:1010696}}
> config2p4Ghz802154 1 0
{{(config2p4Ghz802154)}{802.15.4:Enabled}}

// Note: Channel must be set to one of the concurrent listening channels before enabling receive.
> setChannel 20
{{(setChannel)}{channel:20}}

> enable802154 rx 110 192 672 0
{{(enable802154)}{802.15.4:Enabled}{rxDefaultState:Rx}{txDefaultState:Rx}{idleTiming:110}{turnaroundTime:192}{ackTimeout:672}{defaultFramePending:False}}
> setPanId802154 4660 0
{{(setPanId802154)}{802.15.4PanId:Success}}
> setShortAddr802154 13124 0
{{(setShortAddr802154)}{802.15.4ShortAddress:Success}}
> setLongAddr802154 221 204 187 170 153 136 119 102 0
{{(setLongAddr802154)}{802.15.4LongAddress:Success}}

// Configure 802.15.4 concurrent listening on channels 15 and 20.
> configRxChannelSwitching802154 15 20
{{(configRxChannelSwitching802154)}{Success:True}}

// Configure receive options to enable concurrent listening.
> setRxOptions 1024
{{(setRxOptions)}{storeCrc:False}{ignoreCrcErrors:False}{enableDualSync:False}{trackAborted:False}{removeAppendedInfo:False}{rxAntenna:Any}{frameDet:On}{skipDCCal:False}{skipSynthCal:False}{rxChannelSwitching:True}{fastRx2Rx:False}}

// Enable the radio receive mode
> rx 1

Once configured, should the need arise to update the one or both concurrent listening channels:

> rx 0
{{(rx)}{Rx:Disabled}{Idle:Enabled}{Time:1010696}}
// Configure 802.15.4 concurrent listening on channels 11 and 17.
> configRxChannelSwitching802154 11 17
{{(configRxChannelSwitching802154)}{Success:True}}
> setChannel 17
{{(setChannel)}{channel:17}}
// Enable the radio receive mode
> rx 1

Concurrent listening can be disabled either by switching to a non-concurrent listening channel e.g.

> rx 0
{{(rx)}{Rx:Disabled}{Idle:Enabled}{Time:1010696}}
> setChannel 18
{{(setChannel)}{channel:18}}
// Enable the radio receive mode
> rx 1

Or, by disabling the rxChannelSwitching RX option, i.e., RAIL_RX_OPTION_CHANNEL_SWITCHING

> rx 0
{{(rx)}{Rx:Disabled}{Idle:Enabled}{Time:1010696}}
> setRxOptions 0
{{(setRxOptions)}{storeCrc:False}{ignoreCrcErrors:False}{enableDualSync:False}{trackAborted:False}{removeAppendedInfo:False}{rxAntenna:Any}{frameDet:On}{skipDCCal:False}{skipSynthCal:False}{rxChannelSwitching:False}{fastRx2Rx:False}}
// Enable the radio receive mode
> rx 1

Note: Loading the PHY via e.g., config2p4Ghz802154, after configuring concurrent listening, will de-initialize concurrent listening and configRxChannelSwitching802154 must be issued again to re-configure the feature.

Bluetooth Low Energy#

RAIL provides Bluetooth Low Energy (BLE)-specific hardware acceleration. RAILtest provides a few wrappers over these APIs but since BLE is so timing-critical, not much can be done through RAILtest commands. To enable BLE hardware acceleration, use the setBleMode 1 command. You can then configure channel-specific settings with setBleChannelParams. A preset configuration to enable advertising on channel 37 is available using the setBleAdvertising command.

RAILtest can output a BLE advertising packet on channel 37 with the following commands:

> rx 0
rx 0
{{(rx)}{Rx:Disabled}{Idle:Enabled}{Time:1999306}}
> setBleMode 1
setBleMode 1
{{(setBleMode)}{BLE:Enabled}}
> setBleAdvertising
setBleAdvertising 37
{{(setBleAdvertising)}{AdvertisingChannel:37}}
{{(setBleAdvertising)}{len:28}{payload: 0x02 0x1a 0xff 0xee 0xdd 0xcc 0xbb 0xaa 0x02 0x01 0x06 0x10 0x08 0x53 0x69 0x6c 0x61 0x62 0x73 0x20 0x52 0x41 0x49 0x4c 0x54 0x45 0x53 0x54}}
> tx 0
tx 0
> {{(tx)}{ContinuousTx:Enabled}{None:Disabled}{Time:16160500}}

After these commands, use your phone to search for available Bluetooth devices. You should see 'Silabs RAILTEST' as an available device. RAILtest is not a connectable device.

Z-Wave#

RAIL provides Z-Wave-specific hardware acceleration that can be configured through RAILtest commands. Users can use the setZWaveMode command to enter Z-Wave mode and then setZWaveRegion to specify one of the region-specific PHYs, which generally consist of three separate channels. More about these PHYs can be found in ITU-T G.9959 . To send packets between nodes, the following commands must be entered on both nodes, using the same region.

RX Node:

// Turn the radio off first in order to configure it
> rx 0
{{(rx)}{Rx:Disabled}{Idle:Enabled}{Time:99647646}}
// Enable Z-Wave Mode (1) – beam detection enabled (0x2), promiscuous mode off (0x1)
> setzwavemode 1 2
{{(setZWaveMode)}{ZWAVE:Enabled}{Promiscuous:Disabled}{BeamDetect:Enabled}}
// Specify the EU Region
> setzwaveregion 0
{{(setZWaveRegion)}{ZWaveRegion:EU-European Union}{ZWaveRegionIndex:0}}

On the transmit side, the user must specify the correct Home ID of the target Z-Wave node. This can be skipped, however, by enabling promiscuous mode on the receiver via setZWaveMode and/or setZWaveOptions. Additionally, the user must specify an accurate length byte, otherwise the transmitter may encounter an underflow. The CRC will be calculated on the fly by the radio hardware, so there is no need to specify it explicitly.

TX Node:

// Specify the Home ID in the packet. This is a 4-byte value, starting at byte 0
> setTxPayload 0 0xCA 0xFE 0xC0 0xDE
{{(setTxPayload)}{len:16}{payload: 0xca 0xfe 0xc0 0xde 0x33 0x44 0x55 0x66 0x77 0x88 0x99 0xaa 0xbb 0xcc 0xdd 0xee}}
// Specify the length byte (byte 7) for a packet
> setTxPayload 7 15
{{(setTxPayload)}{len:16}{payload: 0xca 0xfe 0xc0 0xde 0x33 0x44 0x55 0x0f 0x77 0x88 0x99 0xaa 0xbb 0xcc 0xdd 0xee}}

On the receiver side, for basic functionality, the node must configure its own Home ID. >Note: that this will set parameters for the node on which these commands are executed – they do not set the TX packet contents for outgoing packets. To skip Home ID configuration, promiscuous mode can also be enabled.

RX Node:

// The Home ID is CAFEC0DE, using a “don’t care” hash
setzwavehomeid 0xCAFEC0DE 0x55
{{(setZWaveHomeId)}{Status:Set}}

For more advanced receiver functionality, or to be used as a sniffer, channel hopping must be configured. As used in Z-Wave networks, the three channels in each of the Z-Wave regions can be used in rapid succession for different purposes. For a receiving node to be able to receive these packets on any arbitrary channel, the node uses hardware acceleration to hop through the three different channels at specific intervals, using preamble sense mode. The following specification configures the correct hopping scheme, with the on-channel time and preamble sense mode, as well as zero delay between channels. Note, that while this configuration is accurate for most regions, Japan and Korea regions use 270 µs for all the channels, instead of the 270, 450, and 560 specified below. After this, packets can be transmitted on channel 0, 1, or 2, and will be received on the receiver node, without having explicitly set the channel.

RX Node:

// Configure the channel hopping algorithm
> configRxChannelHopping 0 2 270 0 1 2 450 0 2 2 560 0
{{(configRxChannelHopping)}{numberOfChannels:3}{buffer:0x200048b0}{Success:True}}
// Enable channel hopping
> enableRxChannelHopping 1
{{(enableRxChannelHopping)}{Success:True}}

TX Node:

setChannel 0
{{(setchannel)}{channel:0}}
> tx 1
> {{(tx)}{PacketTx:Enabled}{None:Disabled}{Time:1518591782}}
{{(appMode)}{None:Enabled}{PacketTx:Disabled}{Time:1518601722}}
{{(txEnd)}{txStatus:Complete}{transmitted:1}{lastTxTime:1518601679}{timePos:6}{lastTxStart:1518597116}{ccaSuccess:0}{failed:0}{lastTxStatus:0x000000000}{isAck:False}}
setChannel 1
{{(setchannel)}{channel:1}}
> tx 1
> {{(tx)}{PacketTx:Enabled}{None:Disabled}{Time:1522247672}}
{{(appMode)}{None:Enabled}{PacketTx:Disabled}{Time:1522258337}}
{{(txEnd)}{txStatus:Complete}{transmitted:1}{lastTxTime:1522258277}{timePos:6}{lastTxStart:1522252961}{ccaSuccess:0}{failed:0}{lastTxStatus:0x000000000}{isAck:False}}
setChannel 2
{{(setchannel)}{channel:2}}
> tx 1
> {{(tx)}{PacketTx:Enabled}{None:Disabled}{Time:1526903409}}
{{(appMode)}{None:Enabled}{PacketTx:Disabled}{Time:1526930874}}
{{(txEnd)}{txStatus:Complete}{transmitted:1}{lastTxTime:1526930821}{timePos:6}{lastTxStart:1526908743}{ccaSuccess:0}{failed:0}{lastTxStatus:0x000000000}{isAck:False}}

RX Node:

{{(rxPacket)}{len:13}{timeUs:1508290532}{timePos:4}{crc:Pass}{rssi:-10}{lqi:114}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:0}{payload: 0xca 0xfe 0xc0 0xde 0x33 0x0a 0x55 0x0f 0x77 0x88 0x99 0xaa 0xbb}}
{{(rxPacket)}{len:14}{timeUs:1511945271}{timePos:4}{crc:Pass}{rssi:-8}{lqi:100}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:1}{payload: 0xca 0xfe 0xc0 0xde 0x33 0x0a 0x55 0x0f 0x77 0x88 0x99 0xaa 0xbb 0xcc}}
{{(rxPacket)}{len:14}{timeUs:1516608125}{timePos:4}{crc:Pass}{rssi:-10}{lqi:102}{phy:0}{isAck:False}{syncWordId:0}{antenna:0}{channelHopIdx:2}{payload: 0xca 0xfe 0xc0 0xde 0x33 0x0a 0x55 0x0f 0x77 0x88 0x99 0xaa 0xbb 0xcc}}

Cancel Specific Protocol Mode#

To cancel any of the specific BLE, 802.15.4 or Z-Wave mode, you can simply call deinitProtocol.