Sending a serial command to device

I'm trying to write a Arduino code that will repetitively transmit a pre defined string of binary commands to a externally connected device. Not sure where to start.

Arduino Uno
Baud: 115.2 Kbps
Command Repeat rate: Every 25 ms
Data bits per packet:8
Total # of bits:128

Here is the info I want to send in binary.

Packet Data
1 00000000
2 10100010
3 00001011
4 11111110
5 00101001
6 01010100
7 00010011
8 11111110
9 00100110
10 10100110
11 00011011
12 11111110
13 00110000
14 00000000
15 00000011
16 11100010

I need the high to be 3.3 volts, what pin should I use for the transmit?

Any help would be great. Thank you

I need the high to be 3.3 volts, what pin should I use for the transmit?

Whichever pin you like, as long as it is attached to a 3.3V Arduino. Most Arduinos are 5V. (There are exceptions).

Nesbittcj:
I'm trying to write a Arduino code that will repetitively transmit a pre defined string of binary commands to a externally connected device. Not sure where to start.

"Serial" normally means sending with the Serial.print() or Serial.write() commands but it sounds as if that is not what you mean. Can you confirm that ?

Post a link to the datasheet for the device you want to communicate with.

...R

PaulS:
Whichever pin you like, as long as it is attached to a 3.3V Arduino. Most Arduinos are 5V. (There are exceptions).

That's a great idea. Then I wouldn't need to change the voltage Thank you. I will use a Pro mini 328 3.3V

Robin2:
"Serial" normally means sending with the Serial.print() or Serial.write() commands but it sounds as if that is not what you mean. Can you confirm that ?

Post a link to the datasheet for the device you want to communicate with.

...R

SO the device I'm trying to connect to is a Blade 350 Qx3 quad copter. I'm trying to control the quad by sending it commands thru the line that the RC receiver normally sends commands to the quad. My thought is if I know the commands that the RC receiver sends to the quad to perform a action, why cant an Arduino send those same commands. The ultimate goal is to make the quad autonomous by having the Arduino send a series of known commands at certain time intervals. I know what the commands are because I hooked the RC receiver up to a Pico scope and captured the 128 bit commands for each action (Throttle Up, RTH, ect.) Now I just need to know how to send those 128 bit messages back out to the quad.

RC receiver normally sends commands to the quad.

So, just what would these commands be?

zoomkat:
So, just what would these commands be?

They were a string of binary ones and zeros in a specific order. 128 in total

For Example, The Throttle neutral command is
"00000000101000100000101111111110001010010101010000010011111111100010011010100110000110111111111000110000000000000000001111100010"

Then that's not going to work with the Serial command. Serial is byte-based. There's a start bit and a stop bit added to every byte. A continuous stream of ones and zeros is not Serial.

SPI can do this. I2C is also a little similar.

How did you determine that sequence? Sampling from the actual device or does it show up in a manual somewhere?

Nesbittcj:
They were a string of binary ones and zeros in a specific order. 128 in total

For Example, The Throttle neutral command is

How did you get that data?

You will also need to know the timing system. How will the device receiving the data know how many 0s there are in a continuous series of 0s?

How will it know which bit is the first bit in the 128 bit sequence?

You really need to get the datasheet that describes the data system you want to emulate. Otherwise there is a grave risk of a catastrophic crash of your quad copter. It is quite likely that it is using a standard system - why would the quad-copter people have reinvented the wheel?

Are you sure the receiver is not just outputting standard servo signals?

Another thought - that sequence of bits is far more complex than what would be needed to mean "throttle neutral" so it must mean a lot more than that.

...R

MorganS:
How did you determine that sequence? Sampling from the actual device or does it show up in a manual somewhere?

The sequence was recorded by a Pico Scope sampling from the actual device.

Here is a screen capture or the rate

Here is a screen capture of each command

The Pico software can then convert this info to binary or Hex commands.

Robin2:
How did you get that data?

You will also need to know the timing system. How will the device receiving the data know how many 0s there are in a continuous series of 0s?

How will it know which bit is the first bit in the 128 bit sequence?

...R

The data was recorded with a Pico scope.

Here is a screen capture of each command

I checked all the timings until I found the one that revealed usable data.

This info has also been confirmed by this webpage where someone did the same thing.
http://www.desertrc.com/spektrum_protocol.htm

Robin2:
You really need to get the datasheet that describes the data system you want to emulate. Otherwise there is a grave risk of a catastrophic crash of your quad copter. It is quite likely that it is using a standard system - why would the quad-copter people have reinvented the wheel?

Are you sure the receiver is not just outputting standard servo signals?

Another thought - that sequence of bits is far more complex than what would be needed to mean "throttle neutral" so it must mean a lot more than that.

...R

No datasheet is available. The quad was not intended for this use, I don't care if it crashes. This is a experiment.

Its absolutely not outputting standard servo signals.

The binary string is also reporting the status of all the channels at one.

Please see Image Guide and modify your Posts so we can see the images without having to download them.

Do you know the exact duration that is required for each bit?
Are you sure there is not also a clock signal on a separate pin to synchronize with the data bits?

The binary string is also reporting the status of all the channels at one.

Do you know which part of the data represents the throttle?

You have not commented on the issue of how to identify the start and end of the 128 bit data stream?

...R