Note that I’ve defined both the user data bytes and
the EmbedRF’s native A-to-D inputs in the API transmit
packet array. The value of the tx_cmd byte determines
if the buffered transmit data should be transmitted
immediately by the EmbedRF, buffered for scheduled
transmission, or transmitted before receiving. The tx_end
serves the same purpose as the rx_end definition. Like
rx_end, tx_end is not part of the array data.

I found it very helpful to be able to see the device IDs,
network ID, version information, intervals, modes, and
A-to-D settings while writing and testing the EmbedRF API
code. Here’s the data structure I used to get an overall
view of the operational parameters:

The reply structure byte-filling code is typical of what
your EmbedRF control application will look like. I attached
an LED to PORTA5 on my PIC18LF2620 to act as a debug
indicator. The variable rc (short for return code) is a global