900HP-S3B Mesh API Frame Documents?


No problem.

Honestly I would probably recommend a ZigMo or equivalent for a setup like this. The ZigMo is basically a USB to Wireless adapter. It would allow you to see exact byte values being sent by your devices. It will also allow you to configure your modules for encryption, transparent mode, etc.



Sorry, can’t use this suggestion.

I will integrate your board into a DigiMesh network of sensing. Sensors have Digi radios on them.

Your board will mount in customer’s electrical cabinet and be used to signal customer’s contactors which will then start and stop heavy equipment. Sensing will send instructions via DigiMesh to your boards thereby giving sensors the ability to control customer’s heavy equipment.

The application is similar to ventilation: Not enough air sensed - turn fans on until enough air is sensed.



Ok, just to be sure I see the forest from the trees…

My goal is to turn Relay 1 on in Bank 1. This is command

254, 108, 1

Which I get from * ProXR Quick Start Guide

I wrap this in NI API format according to definition in * API Codec Quick Start Guide to become

170, 3, 254, 108, 1, 24 (this is hex AA, 03, FE, 64, 00, 0F)

I take this package and further wrap it in Digi API format for their Transmit Request, according to Digi API Frame Document (below) and Digi Transmit Request Frame Document (below), specifying that address of the Digi radio on your board. NI board address for this example: 00 00 00 00 00 00 00 00

The final byte group is, according to Digi API Full Frame Example (XCTU output below) here is:

7E 00 14 10 01 00 00 00 00 00 00 00 00 FF FE 00 00 AA 03 FE 64 00 15 CD

Deconstructing this group makes it clearer:

7E - Digi packet identifier
00 14 - overall packet length
10 - TX Request Frame identifier
01 - TX Frame ID
00 00 00 00 00 00 00 00 - Address of remote NI relay board radio
FF FE - Digi reserved
00 - Digi broadcast radius
00 - Digi transmit options

AA - NI API packet identifier
03 - NI packet length
FE 64 00 - NI relay closure command
15 - NI checksum

CD - Digi Checksum

I send the above to my radio, it flows through the 900 MHz DigiMesh to your radio, and the relay closes?


Digi%20API%20Frame%20Document !

Digi%20Transmit%20Request%20Frame%20Document !




That looks accurate, but I’m not an expert on Digi’s API. I’ve only ever used their libraries which hid most of that.

Is that not working?

The command you’re sending in the frame generator is the 254 100 0 command which will deactivate the relay.



I made this google sheet that outlines relay activation and de-activation in both hex and decimal formats: https://docs.google.com/spreadsheets/d/1I9AlbTaKfBiFkpAhvdIdc1Jm3KWqBjNV1XE7tQImP4Y/edit?usp=sharing

It may help in initial testing.



I also just learned of a packet calculator we’re building for a new series called endNode. It will build you a correct packet for ProXR though: https://ncd.io/api-calculator/



OOPS, my mistake. Correct your documents show FE 64 00 turns relay 1 OFF, not ON as I wrote above.

Excellent references. I tried FE 64 00 with radio address 00 00 00 00 00 00 00 00 in the calculator and see the result

You: 7E 00 14 10 00 00 00 00 00 00 00 00 00 FF FE 00 40 AA 03 FE 64 00 0F 94
Me: 7E 00 14 10 01 00 00 00 00 00 00 00 00 FF FE 00 00 AA 03 FE 64 00 15 CD
Dif: xx xx xx xx aa xx xx xx xx xx xx xx xx xx xx xx xx bb xx xx xx xx xx xx cc

Difference aa is the Digi Frame ID. These are just frame tags so software can sort out returned frames if multiple frames are used.

Difference bb is are the Digi frame transmission options. You chose point-multipoint, I chose an invalid option.

Difference cc is just the different checksum owing to the different choices you and I made.

Simple! Thanks for making the communication via DigiMesh clear.



Hi Jacob,

I have follow-on question which is appropriate in this thread.

Our previous discussion involves sending your relay board a command to turn Relay 1 OFF. I learned where the basic command is, how to encode it into your API and then how to encode this into the Digi XBee radio API as a TX Request.

Now my goal is to get something back from your relay board. I would like to read an 8 bit result from ADC Input 1. Your documents give your API. I’ll repeat your document here:

I see I must send 254 150 after appropriate wrapping in your API and the Digi TX API. I’ve shown this wrapping method in example in the the previous communications.

Your document shows I can expect the board to respond with a single byte, (255 in your document but I guess any value 0 to 255 depending on ADC input), wrapped in your API format:

170 1 255 170

I expect this to arrive at my radio in a Digi API, which I can unwrap.

My concern now is how your relay board routes the return to me. I expect that your board will use DigiMesh and that it will use the Digi Transmit Request method of sending. In this case your relay board must know my radio’s address. How does the relay board obtain this address? How does it know where to send?




Unfortunately the on-board processor doesn’t take this into account and will send the data to whatever the lower serial address is configured on the attached S3B module.

By default it will broadcast (0000ffff) so everything on the wireless network will get the response.

If you only ever need to access that board’s responses with just one “master” device then you can set the S3B module on the relay controller to use the master’s lower serial.

Also you’ll get the data in the serial buffer of the “master” device if that’s also part of the question.



In fact each relay control command will send a response that should be read to make sure it went through successfully. We also recommend reading the response to make sure the device is actually ready for another command and not still processing the last command.



Hi Jacob,

The Digi Radio is a complex bit of hardware. In this reply I’ll attempt to translate your “whatever lower serial address is configured” into a definite feature in the Digi radio (S3B module).

Your relay board software could operate in transparent mode or in Digi API. I assume that it uses API from the discussion above concerning wrapping relay commands.

In API your relay board software has these choices for sending information out the Digi radio:

Which of these methods do you use?

Once I know the method I’ll dig deeper and ask questions on how you obtain the destination address in the context of the method.



The relay board will operate in Transparent mode actually. The on-board processor sends a raw serial transmission without any S3B consideration out over serial to the S3B and the S3B wraps it up and transmits it.

The destination address lives on the S3B module itself and can be configured using X-CTU.



Hi Jacob,

I’ve done a little hunting with Digi Tech support. I’ll put what I’ve learned here for posterity.

Hi Tech Support,

I’m building a system of buoys to make measurements and relays to control equipment. These will communicate via DigiMesh using XBP9B-DMST-002 radios.

I’m evaluating a 3rd party as a hardware provider for a part of my buoy system. Have a look at

scroll mostly down to the bottom and you’ll see your radio. This board is a good fit in my system. I’ll use it to switch customer equipment on/off based on buoy sensing.

My plan is that the buoy will send commands by buoy Digi radio to relay board Digi radio. Relay will open/close.

But my buoy uses API mode. The relay uses Transparent mode. Bummer!


The relay board generates a response for every command it receives.

The buoy will know the MAC address of the relay board radio.

I’m not sure how the relay board will know the MAC address of the buoy


Will the relay board, DigiMesh, in transparent mode receive a TX Request (0x10) from the buoy?

If NOT, what can be done?

If SO:

Will the relay board response arrive back at the buoy?

What frame will this response arrive in?

Hello Mike,

AT / Transparent mode and API mode only refer to the way in which the module interacts with the device connected to the module’s UART.

There are many networks in use that have an API master and AT/Transparent slave nodes. This is probably the most common setup we see.

In your case, having a mixed AT/API network should be fine.

A 0x10 frame send from an API transmitter will be received by the intended AT or API receiver. Once in the air, the packets are basically encoded in the same way.

I hope that answers your question.


Q: Will the relay board, DigiMesh, in transparent mode receive a TX Request (0x10) from the buoy?

A: Yes. Correct.

Q: Will the relay board transparent mode response arrive back at the buoy?

A: As long as the DH/DL of the transmitter in transparent mode matches the SH/SL of the receiver, then yes.

Q: What frame will this response arrive in?

A:The response will arrive as a Receive Packet frame 0x90.



So my translation of your “whatever lower serial address is configured” is that your relay board Digi radio will send replies using Transparent mode to the address in the DH/DL parameters of the relay board Digi radio. If these DH/DL are set to my radio address (my SH/SL) then I’ll receive a Receive Packet frame (0x90) containing your relay board response.

I note that since your relay board uses the Digi radio in transparent mode, the discussion above on Digi API formatting doesn’t apply at your end. However since I use Digi API I’ll have to communicate with you by formatting your commands into the Digi API.




Awesome! Thanks for posting the above info.

The guys at Digi are much better at explaining their protocol interactions.



The relay board arrived today. Powered it and used a different radio to review relay board radio settings via XCTD. Here they are:

(These are the settings of the NCD relay board radio as shipped from NCD)

3 6



And here is testing using XCTU and a different radio to toggle relay board on/off. Relay board clicks once each second.

Relay ON:

Relay OFF

And the XCTU screen that toggles relay every second:



That’s great! Everything working as expected?



Yes. XCTU shown above is connected to a Digi development board and Digi radio. XCTU sends the Transmit Request frames I show to this board and radio. These are then sent over the air to your relay board/radio.

Relay closes and opens.

Here is a picture of the hook up. Digi development board at bottom is connected to XCTU.



This may be the fastest S3B integration I’ve ever seen. Thanks for posting your application follow ups and notes. Our wireless options are becoming more popular and I’m sure this will come in handy!