ESP32 Using ESP NOW and Bluetooth

@huckohio Have you looked at the swiss guys many videos on 433? I was watching one for a while before I got distracted by some other shiny object, it looked fairly easy.

Also, if you are in a hurry, just have the coop esp32 to close the contacts on the new fob. Easy code and guaranteed to work.

@zander 

Posted by: @zander

↑

Have you looked at the swiss guys many videos on 433? I was watching one for a while before I got distracted by some other shiny object, it looked fairly easy.

I've been trying to follow his garage door example and I'm having trouble understanding some of his steps and conclusions. When I finish the first pass I'll post my questions, etc.

Before that I want to look at the RF433any example. I had glanced at that before, and I think it's compatible with the HW om Billi's article.

@huckohio 

I'm trying to replicate the repository to look at the code.

Of course, now is when things on my system start going to "hell-in-a-handbasket. " Windows is updating the OS and bogging the entire system down doing it. Visual Studio seems to have forgotten how to replicate a Git repository and is taking a month of Sundays to do it.

Sheesh! Give me patience!

@tfmccarthy Takes a couple seconds on my Mac.

@zander 

Posted by: @zander

↑

Takes a couple seconds on my Mac.

Don't start, you!

Let's just say I'm fairly sure the problem lies with my hard drive and not Windows. and leave it at that, OK? Mac is great! Windows sucks! Will that do? Razzah-frazzah-@#$!-mumble-mumble!

Meanwhile, I think I've lost track of the test scenario.

@huckohio, the test data has me confused. You say you're getting consistent results for "UP" and "DOWN". I thought you were testing the coop door remote, which doesn't have "UP" and   "DOWN". Did you mean "Open" and "Close"? Or are you using some other device?

If I were doing the testing, I'd want clear delineations of the test data. The example code doesn't do a great job of this. It's not clear when one event ends and another begins. As a rough guess, if the "00 8f 44" data packet is the payload of the command then the "07 a2" may be a command prefix or suffix. Same for "47 a2". 

What I'd be seeking is a consistent response to a given command.

If you start the example and you should see no output data.

Then press the "Open Door" button once. and wait until the output data stops.

Save that response and repeat.

You should get identical output. If so, I'd repeat it 3 times to be certain. If not, then I would suspect it isn't capturing the event data.

I'd want to be certain the of the event data capture before doing the playback.

Also, I'm not clear if you have a 433Mhz transmitter setup.

As for the Hex value, I think that's trivial and will know after looking at the library.

@zander

Posted by: @zander

↑

Also, if you are in a hurry, just have the coop esp32 to close the contacts on the new fob. Easy code and guaranteed to work.

Ron,

   Yes, I did watch his video.  I have captured the signals using the universal radio hacker and my SDR.  I was looking at the Arduino radio libraries and was testing if I could read and xmit the commands.  I have been able to read the hex code with my 433 receiver so I'll play with that approach for awhile.

This is not time critical.  I just walk out once it's dark and open the door at the coop.

Thanks Ron.

Mike

@tfmccarthy 

Here's what I have so far.  I am using the RadioHead library and the ask_receiver.ino example file.

Here is the code:

// ask_receiver.pde
// -*- mode: C++ -*-
// Simple example of how to use RadioHead to receive messages
// with a simple ASK transmitter in a very simple way.
// Implements a simplex (one-way) receiver with an Rx-B1 module
// Tested on Arduino Mega, Duemilanova, Uno, Due, Teensy, ESP-12

#include <RH_ASK.h>
#ifdef RH_HAVE_HARDWARE_SPI
#include <SPI.h> // Not actually used but needed to compile
#endif

RH_ASK driver;
// RH_ASK driver(2000, 4, 5, 0); // ESP8266 or ESP32: do not use pin 11 or 2
// RH_ASK driver(2000, 3, 4, 0); // ATTiny, RX on D3 (pin 2 on attiny85) TX on D4 (pin 3 on attiny85), 
// RH_ASK driver(2000, PD14, PD13, 0); STM32F4 Discovery: see tx and rx on Orange and Red LEDS

void setup()
{
#ifdef RH_HAVE_SERIAL
    Serial.begin(9600);	  // Debugging only
#endif
    if (!driver.init())
#ifdef RH_HAVE_SERIAL
         Serial.println("init failed");
#else
	;
#endif
}

void loop()
{
    uint8_t buf[RH_ASK_MAX_MESSAGE_LEN];
    uint8_t buflen = sizeof(buf);

    if (driver.recv(buf, &buflen)) // Non-blocking
    {
	int i;

	// Message with a good checksum received, dump it.
	driver.printBuffer("Got:", buf, buflen);
    }
}

In my previous post Up = Open (door moves up to open) and down = closed.  The data I am capturing is from the remote.  The remote will continue to broadcast the command as long as the button is pressed.  There are spurious commands thrown in at a seemingly random manner. 

Here is the output for the UP/OPEN button pressed:

Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 13 bits (x1): 0d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 13 bits (x1): 0d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 13 bits (x1): 0d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 13 bits (x1): 0d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 13 bits (x1): 0d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 12 bits (x1): 0d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 12 bits (x1): 0d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 12 bits (x1): 0d 42
Received 17 bits (x4): 00 8d 42
Received 17 bits (x4): 00 8d 42
Received 13 bits (x1): 0d 42
Received 17 bits (x1): 00 8d 42
Received 16 bits (x1): 46 a1

...and here is the output for the Down/Close button pressed:

Received 16 bits (x3): 8f 44
Received 12 bits (x1): 0f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 13 bits (x1): 0f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 13 bits (x1): 0f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 13 bits (x1): 0f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 13 bits (x1): 0f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x4): 00 8f 44
Received 17 bits (x1): 00 8f 44
Received 16 bits (x1): 47 a2

Here is the transmit code I was using from ChatGPT:

// Include the RadioHead library
#include <RH_ASK.h>
#include <SPI.h> // Required for RadioHead to work with some Arduino boards

// Create an instance of the ASK (Amplitude Shift Keying) object
RH_ASK rf_driver;

void setup() {
    // Initialize the RadioHead ASK driver
    if (!rf_driver.init()) {
        // Initialization failed
        Serial.begin(9600);
        Serial.println("RF module initialization failed!");
        while (1); // Stay here forever
    }
    Serial.begin(9600);
    Serial.println("RF module initialized.");
}

void loop() {
    // Define the hexadecimal command to send
    uint8_t hexCommand[] = { 0x00, 0x8d, 0x42}; // Replace with your desired command

    // Transmit the command
    if (rf_driver.send(hexCommand, sizeof(hexCommand))) {
        rf_driver.waitPacketSent();
        Serial.println("Command sent successfully."); 
        //send second command 
        uint8_t hexCommand2[] = { 0x46, 0xa1 }; // Replace with your desired command
        if (rf_driver.send(hexCommand2, sizeof(hexCommand2))) 
          {
          rf_driver.waitPacketSent();
          Serial.println("Command2 sent successfully."); 
          }

    } else {
        Serial.println("Command failed to send.");
    }

    // Wait 1 second before sending again (adjust as necessary)
    delay(5000);

I added the //second command  transmit command to send the additional data I was receiving (not sure if it's a repeat command).  

I checked to make sure the UNO was sending the data to the transmitter, but not if the transmitter is transmitting.  

Next steps:

1. Change the code to send the hex as  text - I saw some examples did it that way.

2.  Use the SRD and Universal Radio Hacker software to make sure my transmit board is transmitting.

3.  Keep working on this....getting closer.

Thanks for all your suggestions/comments.

Mike

@huckohio You don't need to change anything, uint8_t is a synonym for char, and 0x42 is the same bit pattern as B. Sorry if I am stating the obvious but here is a snippet of a HEX/DEC/Ascii char table.

Try

Serial.println("B");

@huckohio 

Preface: This is how I would approach testing the unit. I don't claim it's the best. Testing is difficult and complex effort and there seems to be as many approaches to it as there are developers. But I've tested a lot of code in my time, so there's that.

Things are getting a bit muddled here. I have 3 different code examples: one from RF433any, one from RadioHead, and one from ChatGPT. The output data appears to match the RF433any example, so that's the example I'll focus on to start. Later we can check if the RadioHead example outputs matching data. Lastly, we can cover the ChapGPT example, but that's really extra.

Test Approach

We need to better understand the remote/door behavior. You say

The remote will continue to broadcast the command as long as the button is pressed.

OK, but a critical question we need to know is what is the door behavior? To open the door do you press the button once or do you press-and-hold the button? How long must you hold the button down? When you release the button does the door stop or complete opening?

What we're looking to find out is if we can send a single "open" command to completely open the door or must we repeatedly send the command until the door is open? (And how do we know the door is open?)

We want to capture is a single "Open Door" button press command. If needs be, we can compare it with the press-and-hold command. (I think things will get tricky if we must press-and-hold.)

When we've captured a single Open command, we can run the simple test of sending it to the door and see if it works. If we wish to completely test the system, we can transmit the command to ourselves to verify we're sending it out properly. (Obviously, if the door accepts it, we are, or at least enough to get the job done.)

RF433any example

The analysis here is on a high level, meaning just enough to understand the output of the sketch. I assume the purpose of using the sketch is

1. Verify the capture of the remote data command
2. Record of the command data for later playback

The RF433any library processes RF data read from a input pin by use of interrupts that are triggered by changes in the data on the pin. It tracks the signal and separates it into digital bits. (For this analysis, I won't try to delve further into the library details other than what is necessary to interpret the output.)

The sketch is 02_output-received-code.ino, found in the RF433any examples folder. The output of the sketch looks like the following:

Received 16 bits (x1): 8f 44
Received 17 bits (x3): 00 8f 44
Received 11 bits (x1): 07 a2
Received 16 bits (x1): 47 a2
Received 16 bits (x1): 47 a2
Received 17 bits (x4): 00 8f 44
Received 11 bits (x1): 07 a2
Received 17 bits (x4): 00 8f 44
Received 12 bits (x1): 07 a2
Received 17 bits (x4): 00 8f 44
Received 17 bits (x2): 00 8f 44
Received 16 bits (x1): 47 a2

The sketch outline is standard, and defines a single global variable, track that receives the RF signal data

#include "RF433any.h"
#include < Arduino.h >

#define PIN_RFINPUT  2

void setup() {
    //...
}

Track track(PIN_RFINPUT);

void loop() {
    //...
}

The Track object accepts a single parameter that identifies the Arduino pin that the RF data appears on.

The setup function is unremarkable.

void setup() {
    pinMode(PIN_RFINPUT, INPUT);
    Serial.begin(115200);
    Serial.print("Waiting for signal\n");
}

It set the input pin, starts the serial object, and outputs the startup message.

The loop function captures RF event packets and outputs information for the event packet. I'm not completely certain about what an event packet is but so far it appears to be the RF data that conforms to a known format, i.e., a signal with a definite start and end.

The algorithm of the loop is to reset the track object to prepare it to receive the signal and then waits for the event to be received

void loop() {
    track.treset();

    while (!track.do_events())
        delay(1);
    //...
}

Thus each iteration of the loop processes a new event. What's not clear to me is if the RF signal has stopped, i.e., we've reached the end of the command, or just a portion of it.

The rest of the function outputs the track event data which consists of a list of Decoder objects.

for (Decoder *pdec = pdec0; pdec != nullptr; pdec = pdec->get_next()) {
    //...
}

The Decoder object that contains the RF data (comments are mine)

class Decoder {
    private:
        Decoder *next;  // next object in list
        byte repeats;   // data repeat count

    protected:
        BitVector* pdata;   // RF data in bit format (reversed)
        byte convention;    // format identifier (??)
        byte nb_errors;     // error count

        TimingsExt tsext;   // signal timing markers
    //...
};

The BitVector is a dynamic array that will set bits of the first element and dynamically grow the array as more bits are set.

class BitVector {
    private:
        uint8_t* array;
        byte allocated;
        byte nb_bits;
    //...
};

The idea seems to be that you add bits at the front the array and but read the bytes in reverse order. I'm not trying to evaluate the algorithm and simply treat it as a container of bits.

When the loop iterates over the Decode object data it outs

The number of valid bits of the object

Serial.print("Received ");
Serial.print(pdec->get_nb_bits());

followed by the object repeat count

Serial.print(" bits (x");
Serial.print(pdec->get_repeats() + 1);
Serial.print("): ");

It then converts the object data into a character buffer of hexadecimal digits.

char *buf = pdec->get_pdata()->to_str();

and prints then frees the buffer

if (buf) {
    Serial.println(buf);
    free(buf);
}

n.b., the use of hexadecimal output is for display purposes only. The data is just raw 8-bit byte..

We can now match the empirical data with the code

Received 16 bits (x1): 8f 44
Received 17 bits (x3): 00 8f 44
Received 11 bits (x1): 07 a2
Received 16 bits (x1): 47 a2
Received 16 bits (x1): 47 a2
Received 17 bits (x4): 00 8f 44
Received 11 bits (x1): 07 a2
Received 17 bits (x4): 00 8f 44
Received 12 bits (x1): 07 a2
Received 17 bits (x4): 00 8f 44
Received 17 bits (x2): 00 8f 44
Received 16 bits (x1): 47 a2

The first track data consists of 16 bits contained in 2 bytes and is appears once:

8f 44

The second track has 17 bits in 3 bytes and is repeated 3 times:

00 8f 44 00 8f 44 00 8f 44

etc.

I'm not quite sure of I have the byte order correct and it may be reversed.

Given this I think it is important to try to isolate the response to a single open command to be sure we have the complete set of track data of the command.

Hopefully this helps to make sense of the output. I think it answers the first question and verifies we are receiving the data. In terms of record and playback, that would require knowledge of how the library transmits data. There is probably an example for that as well.

@tfmccarthy

Posted by: @tfmccarthy

↑

To open the door do you press the button once or do you press-and-hold the button?

You only need to press once.

Posted by: @tfmccarthy

↑

How long must you hold the button down?

You can do a quick press and the door will move. As fast and I can press and release the door will start moving.

Posted by: @tfmccarthy

↑

When you release the button does the door stop or complete opening?

Door opens fully with a single press.

Posted by: @tfmccarthy

↑

What we're looking to find out is if we can send a single "open" command to completely open the door or must we repeatedly send the command until the door is open? (And how do we know the door is open?)

Single open command.  I am guessing the door opens based on a stepper motor and # of turns.  I don't see any mechanical or e/o devices to indicate the door has reached the end of its travel.

Posted by: @tfmccarthy

↑

When we've captured a single Open command, we can run the simple test of sending it to the door and see if it works.

I can do a quick press of the remote and I'll get the commands shown in my previous response. 

Open/Up: 00 8d 42

Close/Down: 00 8f 44

There is the spurious data that pops into the serial monitor at random times.

Open/Up: 0d 42 (several times) and 46 a1 (once).  Not sure if these are coming from other devices (don't know if there is an address command).

Close/Down: 0f 44 (several times) and 47 a2 (once) and 8f 44 (once)

In my last test I tried transmitting the hex command (0x00 0x8d 0x42) to the door and the door didn't open.  I checked the output of the uno with the scope and I saw data leaving the uno (see pic)

 My next step is to verify the signal is getting out of the transmitter.  I am taking another computer that will be running the receiver and I'll check to make sure I can receive the signal being sent from the transmitter.

FYI:  Here is the output from the Universal Radio Hacker.  The down/close command is on top and the up/open command is on bottom.  There is a repeatable pattern, just not sure where the patterns start.

Mike

@tfmccarthy @zander

I have two computers set up with Arduino Unos.  The both sketches are using the Radio Head library (ask_transmitter and ask_receiver).  The transmitter is sending 0x00 0x8d 0x42 as a char string.  The receiver is capturing this:

Got:
30 78 30 30 20 30 78 38 64 20 30 78 34 32 
Got:
30 78 30 30 20 30 78 38 64 20 30 78 34 32 
Got:
30 78 30 30 20 30 78 38 64 20 30 78 34 32 
Got:
30 78 30 30 20 30 78 38 64 20 30 78 34 32 
Got:
30 78 30 30 20 30 78 38 64 20 30 78 34 32 
Got:
30 78 30 30 20 30 78 38 64 20 30 78 34 32 
Got:
30 78 30 30 20 30 78 38 64 20 30 78 34 32 
Got:
30 78 30 30 20 30 78 38 64 20 30 78 34 32 
Got:
30 78 30 30 20 30 78 38 64 20 30 78 34 32 

Ok....I am at the WTF stage 🤔 

@tfmccarthy  @zander

Here is the receiver code:

// ask_receiver.pde
// -*- mode: C++ -*-
// Simple example of how to use RadioHead to receive messages
// with a simple ASK transmitter in a very simple way.
// Implements a simplex (one-way) receiver with an Rx-B1 module
// Tested on Arduino Mega, Duemilanova, Uno, Due, Teensy, ESP-12

#include <RH_ASK.h>
#ifdef RH_HAVE_HARDWARE_SPI
#include <SPI.h> // Not actually used but needed to compile
#endif

RH_ASK driver;
// RH_ASK driver(2000, 4, 5, 0); // ESP8266 or ESP32: do not use pin 11 or 2
// RH_ASK driver(2000, 3, 4, 0); // ATTiny, RX on D3 (pin 2 on attiny85) TX on D4 (pin 3 on attiny85), 
// RH_ASK driver(2000, PD14, PD13, 0); STM32F4 Discovery: see tx and rx on Orange and Red LEDS

void setup()
{
#ifdef RH_HAVE_SERIAL
    Serial.begin(9600);   // Debugging only
#endif
    if (!driver.init())
#ifdef RH_HAVE_SERIAL
         Serial.println("init failed");
#else
  ;
#endif
}

void loop()
{
    uint8_t buf[RH_ASK_MAX_MESSAGE_LEN];
    uint8_t buflen = sizeof(buf);

    if (driver.recv(buf, &buflen)) // Non-blocking
    {
  int i;

  // Message with a good checksum received, dump it.
  driver.printBuffer("Got:", buf, buflen);
    }
}

Here is the transmit code

// ask_transmitter.pde
// -*- mode: C++ -*-
// Simple example of how to use RadioHead to transmit messages
// with a simple ASK transmitter in a very simple way.
// Implements a simplex (one-way) transmitter with an TX-C1 module
// Tested on Arduino Mega, Duemilanova, Uno, Due, Teensy, ESP-12

#include <RH_ASK.h>
#ifdef RH_HAVE_HARDWARE_SPI
#include <SPI.h> // Not actually used but needed to compile
#endif

RH_ASK driver;
// RH_ASK driver(2000, 4, 5, 0); // ESP8266 or ESP32: do not use pin 11 or 2
// RH_ASK driver(2000, 3, 4, 0); // ATTiny, RX on D3 (pin 2 on attiny85) TX on D4 (pin 3 on attiny85), 
// RH_ASK driver(2000, PD14, PD13, 0); STM32F4 Discovery: see tx and rx on Orange and Red LEDS

void setup()
{
#ifdef RH_HAVE_SERIAL
    Serial.begin(9600);   // Debugging only
#endif
    if (!driver.init())
#ifdef RH_HAVE_SERIAL
         Serial.println("init failed");
#else
  ;
#endif
}

void loop()
{
    const char *msg = "0x00 0x8d 0x42";
    //byte msg[3]={0x00, 0x8d, 0x42};
    Serial.println(msg);
    driver.send((uint8_t *)msg, strlen(msg));
    driver.waitPacketSent();
    delay(5000);
}

I picked the wrong time to stop sniffing glue!

@tfmccarthy  @zander

I added the following two lines to the receiver sketch

driver.printBuffer("Got: ", buf, buflen);  //this was existing code
const char *msg = buf;    //NEW
Serial.println(msg);         //NEW

I new see this in the serial monitor:

Got:
30 78 30 30 20 30 78 38 64 20 30 78 34 32
0x00 0x8d 0x42

When I copy the receive message into the char string I get the data I am sending.  So why are these two lines different?

@huckohio

Posted by: @huckohio

↑

In my last test I tried transmitting the hex command (0x00 0x8d 0x42) to the door and the door didn't open. 

I may be misunderstanding you here. I think the term "hex command" is the cause. I think hexadecimal notation may be confusing you.

We think the Open Door command is a 3 byte command. Each byte may hold a value between 0-255 (in decimal notation). We can represent that same value using hexadecimal notation, but it's the same value.

We think the correct sequence of the 3 byte command is:

Hex     decimal
0x00    0
0x8d    141
0x42    66

If I want a buffer that holds just the command payload it would be defined as

uint8_t buf[3] = "\x00\x84\x42";

// or set the bytes using decimal values
buf[0] = 0;
buf[1] = 141;
buf[2] = 66;

There's a tool on your system that'll help to handle this: the calculator app. You can switch it to "Programmer Mode" to get the different base values, binary, decimal, octal, and hex. You switch between the different bases.

But I think there's more to sending the command than just the raw data. I think it needs a prefix and suffix.

@huckohio 

Try this

void loop()
{
    const char *msg = "\x00\x8d\x42";
    Serial.println(msg);
    driver.send((uint8_t *)msg, 3);
    driver.waitPacketSent();
    delay(5000);
}

coreection, strlen won't work here