Single pulse analogWrite

I'm looking at sending a single byte over a 433Mhz link as a single pulse. Can I send a single pulse using analogWrite by following an analogWrite(p,n) command with a digitalWrite(0) like this?

...
analogWrite(pulsePin,n) // Send pulse 0 to 255 long
digitalWtite(pulsePin,0)  // Set output to 0
...

Will This send just a single pulse, or terminate late or early?

Pogo.

To put single a pulse of a specific duration on an Arduino pin, you'd do something like:

digitalWrite(pulsePin,1)  // Set output to 1
delayMicroseconds( pulseLength ) ;  // set this yourself
digitalWrite(pulsePin,0)  // Set output to 0

6v6gt:
To put single a pulse of a specific duration on an Arduino pin, you'd do something like:

digitalWrite(pulsePin,1)  // Set output to 1

delayMicroseconds( pulseLength ) ;  // set this yourself
digitalWrite(pulsePin,0)  // Set output to 0

Thanks @6v6gt, I got that.

But as an interesting hack, where the data is already a byte (so doesn't need to be massaged into microseconds), and the range of pulse lengths is suited to the problem (low rate ASK transmission over a short but potentially noisy range), and without an Arduino in front of me to try it on, would it work as required?

To ask it as a deeper question, does the Arduino complete sending a pulse in analogWrite before executing the next instruction, or would the following digitalWrite terminate the analogWrite early, or on the other end would it take so long to terminate that a pulse and a bit or maybe two or more whole pulses were sent?

Yes, I could (and have looked at) use an FSK serial link, but where's the fun in following everyone else?

Pogo

The output of analogWrite is from a separate, asynchronous piece of hardware called a counter/timer.

This continually outputs pulses all the time, the call to analogWrite merely changes the width of future pulses.
It doesn't wait, it doesn't take immediate effect, and so outputing a single pulse is not feasible using analogWrite.

Trying to encode 8 bits as an RF pulse length is fraught with issues, such as the bandwidth of TX and RX, noise,
interference, AGC pumping, and probably others. Old fashioned used such schemes for analog data, and you
had to put up with some jitter and noise, but that's not a shop stopper for RC models.

Trust the people who've worked with wireless all their lives and use a packet transceiver to communicate digital/binary data. The RF12 module is cheap and there are libraries to support it. Transceivers have
checksums, packet start recognition, and other support to make data communication reasonably robust even
in such cheap ISM modules.

Anyway what is this byte?

MarkT:
The output of analogWrite is from a separate, asynchronous piece of hardware called a counter/timer.

This continually outputs pulses all the time, the call to analogWrite merely changes the width of future pulses.
It doesn't wait, it doesn't take immediate effect, and so outputing a single pulse is not feasible using analogWrite.

Trying to encode 8 bits as an RF pulse length is fraught with issues, such as the bandwidth of TX and RX, noise,
interference, AGC pumping, and probably others. Old fashioned used such schemes for analog data, and you
had to put up with some jitter and noise, but that's not a shop stopper for RC models.

Trust the people who've worked with wireless all their lives and use a packet transceiver to communicate digital/binary data. The RF12 module is cheap and there are libraries to support it. Transceivers have
checksums, packet start recognition, and other support to make data communication reasonably robust even
in such cheap ISM modules.

Anyway what is this byte?

Thanks @MarkT I needed to know. Sitting here with a pad and a pen isn't quite as good as being able to fail with real hardware.

I'm very happy to take expert advice with an explanation. That's why I asked, and part of the fun of learning is getting a good answer. (Otherwise I'd have tried it, failed and then asked "Why doesn't this work?", and still appreciated the answer).

It just looked like a neat fit to the problem. The byte is half a dozen flags (trailer light signals) that I want to move by wireless (because it is fun) rather than by the current dodgy cable (with too many unprotected connectors in it).

I didn't want to 'waste' resources continually resending the same data, even at a low rate. And using an HC-12 seems like delivering newspapers with a Rolls Royce.

There are many solutions to the problem. Many are cheaper or easier or more efficient, but this looked like fun. And "if it ain't fun, I don't do it".

Pogo

RF12, not HC12. Actually I mean RFM12 which is the module using the RF12 chip. Its available for several
VHF/UHF ISM bands, extremely cheap.

. . . And using an HC-12 seems like delivering newspapers with a Rolls Royce. . . .

I wouldn’t use the term “Rolls Royce Solution” for something that costs less than the price a small beer !
Of course, that ignores your coding time.

MarkT:
RF12, not HC12. Actually I mean RFM12 which is the module using the RF12 chip. Its available for several
VHF/UHF ISM bands, extremely cheap.

Thanks for the tip, Mark. I'll look it up and see how much fun I can have.

Pogo.

6v6gt:
I wouldn't use the term "Rolls Royce Solution" for something that costs less than the price a small beer !
Of course, that ignores your coding time.

Perhaps, but 100 channels half duplex with selectable baud rate and transmission power and a range of a kilometre (free field) seems much more tech than required to move one byte over a couple of metres ten times a second.

As an aside, while I went looking for a lower tech solution, I am amazed at how much technology is packed into so few dollars.

Thanks for helping me get to an understanding.

Pogo.