You most likely need to append a carriage return. Check the datasheet if it needs both an \r and \n

So example would be...

SendSerial(d0, 19200, ">play 0", 13, 10)

Thanks DJ. The documentation is quite sparse. In fact its the reason I'm poking in the dark. Here is the all the info from their manual, but i will try and add the returns to see what happens:

>>The serial port operates at 19.2kbps, 8 data bits, one stop bit, and no parity. The port implements a standard RS232 interface and conversion circuitry may be required to interface to a TTL serial port (e.g., Basic Stamp or other microcontroller).

And the commands;

pm [mode] If the optional [mode] parameter is supplied, this comm and sets the current playback mode. If the mode parameter is not supplied, this command retrieves the current playback mode (0:play once, 1:repeat single, 2: loop all, 3:random play).

play <track number> This commands starts playback and requires an argument that indicate s the number of the track to play (e.g., the fi rst track is track zero).

ooops, I mean..

SendSerial(d0, 19200, ">play 0", 13, 10)

or in hex it would be

SendSerial(d0, 19200, ">play 0", 0x0d, 0x0a)

Here is a reference chart for ASCII characters and their respective Decimal or Hex values:

DJ beat me to the code. Send it through a EZ Script just like that and see what happens. When I was struggeling with getting my Kangraroo X2 working I had to place that Return code at the end. I found I didnt need the New Line code but your device may be different.

One other thing Will. If you only have one wire connected between EZB and the RX of your device you may need to run a ground wire between the two also. So run it from theground pin of the same Digital port your sending from (use D0) to the control side ground of your serial device. Maybe that will help.

@Dave is absolutely correct. You must have a shared ground for serial communications.

Interestingly, as I connect the ground from D0 to the ground on the ttl converter, all the LEDs go out on the board (ttl converter board). Still having trouble sending commands. I've shot off an email to support waiting to hear back from them.

Thanks guys, still waiting to hear from them. Here is another question. More for DJ I think. Is there a way to control another program running on the same PC that EZB is running on. In this instance, lets say you want to have EZB control the triggering of events, using say visual basic, or powerpoint etc. ( the software uses Active x). The device software i'm using allows control of the software (not hardware) using a console software solution. This is not an ideal solution as it must be tethered to the computer. But also asking out of curiosity.

Edit:

Another option is the hardware has a built in IR controller. So you can send commands with a stardard handheld tv remote control. Sooooo, possible to connect an Ir transmitter of some kind to the EZB? Is there an i2c or other hardware IR device the EZB can control?

Edit 2: Ok i see there is an IR reciever, in i2C folder, can a trasmitter used as well?

There are a few ways to have ARC control other software, or at least "talk" to it. Telnet, http, UDP broadcasting and even running of software (which could include macros etc.)

I'm sure DJ has way more experience and advice on these methods than I have as I've only really briefly touched on them myself (it's always been on the list of things I need to look at but always been bumped down the list by something else so I'm not 100% clear on ARC's capabilities).

As for the original question, I think everyone else has covered everything I would have said anyway. The only additional thing I would say is, and I don't think it makes a scrap of difference but it's what I did with the TellyMate when I had a few issues, is to break down the data. I suspect doing so must have fixed a syntax error in the data that I hadn't spotted but it may have more to it.

Basically, split the data up a bit more in the SendSerial() command; SendSerial(d0, 19200, 0x3E, "play", 0, 0x0D, 0x0A)

The data sent should be exactly the same as DJ's example however, like I said, when I had a few issues with the TellyMate doing this seemed to fix them but I am pretty certain it was just really a case of redoing it fixed an error I overlooked. For the sake of a copy and paste it's worth a shot though.

Great additional info Rich, I will give it a try!

One other silly thought.. I have a USB to TTL adapter that has the tx and rx lines mis-labeled. Maybe this device is from the same manufacturer and they mis-label consistently? Try connecting to the tx instead and see if it hears your signal.

Good point Alan... Used to need to use a "null" modem adapter when communication to two serial devices (swapping the Rx and Tx so that the devices weren't receiving and transmitting on the same pins))

Ok I heard back from them. They were making sure I had it connected correctly. And added that I need to be sure to send the line end (in C++ this would be "/r/n"). Also that I need to drop the ">" which is simply the prompt if you open up in a serial terminal with tx and rx active. I I will try a couple of new lines today with the changes and try the tx/rx switch around, ground etc. If I knew I had the code right then I could work on making sure the the hardware was connected correctly. Too many variables to change at once!

Ok,

I'm going to need some help here. To recap, the manufacturer of the device have no docs beyond the serial terminal usage. Ther are no libraries on using serial commands (via ttl). So I scoured the internet for anyone using this device. I found one guy who owns a prop house who actually wrote some code to use a controller with it (PIC). You can read below his email to me. If anyone has programmed the pic controller and knows how to transfer this code to match what you need to do in the EZB serial commands, please help me to get this to work. He randomized playing of his routines. I want to play "x" by send the code. But it seems everything is in his code adn directions. Any help figuring this out I would be grateful.

His email and code:

Hi Will,

I was using a PIC microcontroller to monitor n IR sensor and then tell the Rapu unit to randomly choose one of 7 routines to run. Looks like I send a cr character first (ascii 13) but not exactly sure why I do this. (I wrote this years ago) Here is the routine I used:

void TransmitCommand(int8 intRandomValue) { int8 BufferVal;

putc(13);
delay_ms(100);
while (kbhit()) //this clears the buffer
  BufferVal=getc();

putc(112); //"p"
delay_ms(10);

putc(108); //"l"
delay_ms(10);

putc(97); //"a"
delay_ms(10);

putc(121); //"y"
delay_ms(10);

putc(32); // space
delay_ms(10);


//put numeric value of routine here (0-7)

putc(48+intRandomValue); //send ascii equiv of the number 0 - 7; the

number zero is ascii 48 delay_ms(10);

putc(13);

}

I'm no expert on PIC programming (in fact I'm on the other end of that spectrum) but looking at his code I guess he is using the equivalent of

$track = GetRandom(1,7)
SendSerial(port, baud, 0x13, "play ", $track, 0x13)

Obviously replace port & baud as required.

To explain a little (so you can try to follow what I did to work it out). His code is sending a carriage return (13 in his code, 0x0D in mine) then the word play (done with dec. for the ascii characters one by one in his code, then a space in dec., then the track number (again in dec.) and followed by another carriage return in dec.

If you wanted you could use just the hex i.e. for track 1

SendSerial(port, baud, 0x0D, 0x70, 0x6c, 0x61, 0x79, 0x20, 0x31, 0x0D)

track 2 would be

SendSerial(port, baud, 0x0D, 0x70, 0x6c, 0x61, 0x79, 0x20, 0x32, 0x0D)

track 3

SendSerial(port, baud, 0x0D, 0x70, 0x6c, 0x61, 0x79, 0x20, 0x33, 0x0D)

You should be able to see which part is changing to change track number. 0x31 is hex for a 1, 0x32 is a 2 and so on up to 0x39. 0x30 is a 0.

Like I said, I'm no expert and outside of my actual knowledge so it's guess work... Let me know, I'm interested in knowing if I assumed correctly.

Edit: I used the wrong hex for the CR, updated above.

If I were to drop the $track in the serial line, just to play a single track, track "0", would the code include the track number with in the "" with play, or outside the "" where you have $track after the comma?

Just edited my reply with a bit more info.

Drop the $track and just have it "play 0" or "play 1" where the "play " is...

SendSerial(port, baud, 0x0D, "play 0", 0x0D)

or maybe even

SendSerial(port, baud, 0x0D, "play ", 0, 0x0D)

or use hex

SendSerial(port, baud, 0x0D, "play ", 0x30, 0x0D)

Any is fine. ARC knows a 0 is the decimal so can be outside the quotes or inside the quotes.

Edit: I used the wrong hex for the CR, updated the above.

Well those all look like they would work, but I still got nothing. I'm going to make sure all the hardware is connected correctly. With the ttl converter. I also want to see if i can get the new serial wi fi terminal to work to make sure the hardware is connected right. When I run the RS-232 to USB to the computer is works just fine. So I know everything is right upto the ttl converter.

I'll look again in a bit, I have to admit I was feeling like death warmed up last night and know I made a few errors (which I think I corrected last night). I'll sit down with a coffee and have a proper read of everything and see what I can figure out.

Thanks Rich, no rush. Hope you are felling better.

Nothing keeps me down for long. I expect it's just a mild case of exhaustion, nothing too serious

OK, taking the other guys code apart piece by piece and converting over to EZ-Script commands we get this;

SendSerial(D0, 19200, 0x0D) # Send a CR
Sleep(100) # Pause for 100ms
SendSerial(D0, 19200, 0x70) # Send the letter p
Sleep(10) # Pause for 10ms
SendSerial(D0, 19200, 0x6c) # Send the letter l
Sleep(10) # Pause for 10ms
SendSerial(D0, 19200, 0x61) # Send the letter a
Sleep(10) # Pause for 10ms
SendSerial(D0, 19200, 0x79) # Send the letter y
Sleep(10) # Pause for 10ms
SendSerial(D0, 19200, 0x20) # Send a space
Sleep(10) # Pause for 10ms
SendSerial(D0, 19200, 0x30) # Send a 0 (his code used a random track this uses track 0)
SendSerial(D0, 19200, 0x0d) # Send a CR

That's a lot of lines for not very much. It may be that those 10ms delays between each character being sent are important so I'd try that one first.

To be honest, if the above doesn't work I would concentrate on checking the wiring is OK since, at least in theory, the above is pretty much the same as his code.

If that works we can look at condensing the code to something a little less overwhelming and easier to work with. i.e. SendSerial(D0,19200, 0x0d, "play 0", 0x0d) which it seems is what I come up with yesterday...

Going back over older posts, the above is pretty much what DJ suggested to start with (but with the exclusion of the > before the play command and a carriage return before the command).

Try the long code with the sleeps. If that doesn't work then it's a case of triple checking the wiring.

Thanks Rich! I'll give it a try tonight! Get some rest