code for sending binary pulses - help!

ok, first off, i'm not real familiar with how to write complicated code. i'll just lay out what i need to do....

i need to set a pin on the arduion high for 1ms for each of the 1's.
the x's are just dead space but their timing has to be counted, so
i added them for visualization. the y's are there for binary code, &
when they are "1" should go high for 1ms, & stay off (or low) for "0".

x1x1x1x1x1x1x1x1x1x1x1x1x1x1y1y1y1y1y1y1y1y1y1y1y1y1y1y1y1

so, 0 would appear
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
and 1 would appear
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 111
2 would be
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 111 1
3 would be
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 11111
etc all the way to 32,767, then start over again at 0.

i know it's a lot to ask, but could anyone help with this?

superchuckles:
the x's are just dead space but their timing has to be counted, so

I'm sure they ain't; are they zero?

superchuckles:
when they are "1" should go high for 1ms, & stay off (or low) for "0".

And how long should the '0' last?

Does this reflect what you need?

   x1x1x1x1x1x1x1x1x1x1x1x1x1x1y1y1y1y1y1y1y1y1y1y1y1y1y1y1y1

0  0101010101010101010101010101010101010101010101010101010101

1  0101010101010101010101010101010101010101010101010101010111

2  0101010101010101010101010101010101010101010101010101011101

3  0101010101010101010101010101010101010101010101010101011111

What needs to happen if you don't 'send' anything; permanently high?

You can basically implement this with something based on the 'blink' example. Change the delay to 1ms and you would have the pattern for the '0'. Next make the value (HIGH or LOW) for the LED depending on the bit that you send.

How is this data stored; how do you know that you need to send a '1' or a '0'? Stored in an integer variable?
How accurate does your timing need to be?

You could also look at tone() to see if it does approximately what you want:
https://www.arduino.cc/en/Reference/Tone

sterretje:
I'm sure they ain't; are they zero?
And how long should the '0' last?

Does this reflect what you need?

   x1x1x1x1x1x1x1x1x1x1x1x1x1x1y1y1y1y1y1y1y1y1y1y1y1y1y1y1y1

0  0101010101010101010101010101010101010101010101010101010101

1  0101010101010101010101010101010101010101010101010101010111

2  0101010101010101010101010101010101010101010101010101011101

3  0101010101010101010101010101010101010101010101010101011111




What needs to happen if you don't 'send' anything; permanently high?

You can basically implement this with something based on the 'blink' example. Change the delay to 1ms and you would have the pattern for the '0'. Next make the value (HIGH or LOW) for the LED depending on the bit that you send.

How is this data stored; how do you know that you need to send a '1' or a '0'? Stored in an integer variable?
How accurate does your timing need to be?

you have it right in your example. there shouldn't exist the possibility to "send" anything permanently high, as the longest it can be sent "high" is 1ms. the zero's would also be 1ms. & timing is kinda critical - the timing pulses (the ones that are always 1) have to occur 14 tiimes a second (14hz). so the entire sequence should happen in 2 1/14 seconds, before going to the next number. i was considering using blink, but it's been so long since i've done any kind of coding, & i wasn't entirely sure how to get it to properly sequence in binary & get the timing right. i supposed i could write a simple algebraic formula to do sequencing, but it would be so long & drawn out, i figured it would interfere with the timing.

Give us a link to the datasheet of the thing you are trying to talk to. You seem to have misunderstood something.

Mark

superchuckles:
i supposed i could write a simple algebraic formula to do sequencing, but it would be so long & drawn out, i figured it would interfere with the timing.

Computers are really good at algebraic formulae. If it has to do a thousand operations of add/subtract/shift/check/output then it can do this 16 times per millisecond before timing is a problem. Remember the default Arduino clock speed is 16MHz, so it can do 16 million instructions per second.

Does the train travel from LSb to MSb or MSb to LSb?

If I understand the request correctly something along the line -

void sendTrain(uint16_t value)
{
    uint32_t    mask    = ((1 << 29) - 1);
                value  &= ( 1 << ((sizeof(value) * CHAR_BIT) - 1)) - 1;
    
    for ( ; mask; mask >>= 1, value >>= 1 )
    {
        digitalWrite(pinTRAIN, HIGH);
        delay(1);
        
        digitalWrite(pinTRAIN, ((value & 1) ? HIGH : LOW));
        delay(1);
    }
}

... ought to work although you will want to time and average the following three statements separately to a an unused pin during setup into a couple of variables ...

digitalWrite(pinTRAIN, ((value & 1) ? HIGH : LOW));
digitalWrite(pinTRAIN, HIGH);
delayMicroseconds(0)

too determine runtime overhead and then calculate both delay values into a variable to use in the 'delayMicroseconds' of 'sendTrain' to get the timing right.

holmes4:
Give us a link to the datasheet of the thing you are trying to talk to. You seem to have misunderstood something.

Mark

I'd love to, but i don't have the datasheet - or know a way to get it. maybe i'm not explaining it right. there are 29 timing pulses - the first 14 are unimportant, since the data fits within the spaces between the last 15. what i need to do is, turn a normal number (0-32767) into a binary sequence, that fits with the last binary digit before the 29th pulse. so if the number was 1, it would look like 1,2,3.....27,28,X,29 with x being the binary pulse.... if the number was 4, it would look like 1,2,3.....X,27,28,29. it needs to count from 1 to 32,768, then start back at 1 & do it again.

You could at least tell us what it is.

aarg:
You could at least tell us what it is.

it is the datapacket for an opticom, or to be more precise, once finished, it will be the code to brute force an opticom by trying each combination in sequence.

If they catch you, this thread will be part of the prosecution's evidence.

& timing is kinda critical - the timing pulses (the ones that are always 1) have to occur 14 tiimes a second (14hz).

Uh-oh.

Thread locked.

Take it somewhere else.