WAV Trigger and Hex Values

Projects Programming
1

I am getting a little closer to understanding what this device is looking for. Again, here is an example of the hex codes it needs to send to play a track.

It looks like the proper command to send all of this at once should be VAR.write(txbuf,8), where txbuf is defined as a byte array of 8.

0x0f //all commands start with this
0xaa // and this
0x08 // total length of message to be sent
0x03 // Command for Control_Track
0x01 // sub-command of Control_Track 01 is play polyphonic
0x0a // see below
0x00 // see below
0x55 //terminator, all commands end with this.

So the 6th and 7th byte are where my question comes in. These two bytes are supposed to be the track number to be manipulated (play, pause, etc). This device can store up to 999 files. In the .cpp file for a library associated with it (not used), these two bytes are defined as

txbuf[5] = (byte)trk;
txbuf[6] = (byte)(trk >> 8);

where trk is an integer for the track number. I am a little fuzzy on this bit shift concept and why it is used. Looking at the above example, 0a =10 and 00=0. So what track do you think would be executed for those values? It has to do with the fact that a single byte can only go up to ff or 255, so you need the two bytes to get in ranges of 999, right?

Just so I can wrap my head around it, what would be the two hex values for manipulating

track 8
track 16
track 27

(all random choices)

Thanks.

2

This is done a lot

txbuf[5] = (byte) trk;
txbuf[6] = (byte) (trk >> 8);

When txbuf is a byte array, and 'trk' is an unsigned integer, it's value is stored in the byte array.
Suppose 'trk' is 0x1234, the lower byte '0x34' is stored in txbuf[5]. The higher byte is shifted to the right, so it becomes '0x12' and that is stored in txbuf[6].

3

Ok. Starting to get it then. So in the above example, it essentially reads 0x0010 then? The examples online show it always to be binary (when it comes to shifting) Is that always the case, or is 0x0010 hex because it started as hex? If so, I am correct by saying that this should play track 16? Why does it shift 8 places in this case? I guess it depends if the 8 shift is binary or hex, as 8 places in hex would be ridiculously huge.

Following the examples I suggested
track 8 -
txbuf[5] = 0x08
txbuf[6] = 0x00
track 16
txbuf[5]= 0x0a
txbuf[6]= 0x00
track 23
txbuf[5]=0x17
txbuf[6]= 0x00

4

Here's another way to show that the bit shifts are working correctly:

union Data {
  byte myArray[2];
  int val;
} myUnion;

void setup() {
   int val;
  
  Serial.begin(115200);
  val = 0x1234;
  myUnion.val = val;
  Serial.print("val0 = ");
  Serial.print(myUnion.myArray[0], HEX);
  Serial.print("   val1 = ");
  Serial.println(myUnion.myArray[1], HEX);
}

void loop() {
}

Bit shifting is more efficient than using a union. Still, if the only tool you have is a hammer, all your problems start to look like a nail.

5

That's certainly true, but if you find my other thread on this Robertsonics WAV Trigger, it seems like you have to work with whatever is given to you. I haven't looked into unions at all, but I think I understand what you are displaying. Once I have a path, I am good at finding additional solutions. It's usually just figuring out the initial path to be where I struggle.

Are my examples to define those tracks using the two bytes accurate?

And again, why would he shift 8 places in his code? Because shifting is always converted to binary before the shift?

6

Every computer or microcontroller or Arduino works with binary data.
The Arduino Uno has a 8-bit microcontroller, it reads and writes 8-bits at a time.

You can show a number the way you like it, as binary bits, as a decimal or hexadecimal.
When splitting a 16-bit variable into two parts of 8-bit, it looks better to a software engineer to use hexadecimal numbers. That's all, it just looks better.

7

That makes sense, Peter. Part of it, as far as serial communication is concerned, is how the device expects it to be formatted to it though, right? That's what I want to make sure I am getting it, so are my examples correct in having the correct hex for those track number examples?

E

8

And, everyone, please understand I ask this question for two purposes. The first, just to make sure I have my head straight. You never know. :). Second, at some point I want to be able to have a variable such as track 544, and then convert it properly to the 2 hex bits that need to be sent to the device.

9

HI there did yu sort the wav trigger as I am trying to cennect to it and play a file

10

Firestorm:
Ok. Starting to get it then. So in the above example, it essentially reads 0x0010 then? The examples online show it always to be binary (when it comes to shifting) Is that always the case, or is 0x0010 hex because it started as hex?

Hex and binary are just two different ways of writing down what a number is. What the number Actually is is electric potentials in a bit of silicon.

Firestorm:
track 8 -
txbuf[5] = 0x08
txbuf[6] = 0x00
track 16
txbuf[5]= 0x0a
txbuf[6]= 0x00
track 23
txbuf[5]=0x17
txbuf[6]= 0x00

Sure, but this doesn't show you what is really going on.

Track 554, in Hex, would be 0x022A. This won't fit into a single byte, it has to be split. So:

track 554
txbuf[5]=0x2A
txbuf[6]= 0x02

A byte is 8 bits. A single hex digit is four bits. So >>8 shifts the value across by two hex digits. The cast to (byte) clips the top two digits.