Help with balancing 1's and 0's for RF

I need what we call in Texas "words of one syllable or less" help for my wireless setup.

I get ok data transfer using Wolfgang's method (Thanks Wolfgang! You rock) of sending a preamble of 0x55s and a particular pause. I've read that I will get better results out of my Sparkfun 434 mhz pair if I always send an equal number of 1's and 0's. I found a post by Hippy saying that the easiest way of doing this would be to just send the inverse and toss it at the receiver.

Great! Except what I've tried is just getting me junk data.

So, please tell me, if I want to send the following:


... what is the inverse to tact on the end? Is it ",5,4,3,2,1,"elbmaerp"?

... what would the serin statement look like for the new, correct serout?

Thanks all.
Brian

(For those wondering, I haven't been able to short out the USB power supply yet due to rainy weather. Hopefully this weekend will be clear.)

Decimal: 1 Binary: 1 Inverse binary: 0 Decimal: 0
Decimal: 2 Binary: 10 Inverse binary: 01 Decimal: 1
Decimal: 3 Binary: 11 Inverse binary: 00 Decimal: 0
Decimal: 4 Binary: 100 Inverse binary: 011 Decimal: 3
Decimal: 5 Binary: 101 Inverse binary: 010 Decimal: 2

You can serout binary if needed using the % symbol before the binary.

Have a look on Radiometrix's website - they have a vast amount of useful data and info.

A

I'm not actually sure what the question is, so I'll waffle.... (yes, as usual )

I haven't seen hippy's post or Wolfgang's code , but most recommendations for simple RF modules is the 0x55 on-off preamble. Often followed by a brief pause.
This is the usual recommended format for low-cost OOK RF - where the carrier is switched On-Off to follow the 0-1 (high-low) logic of the input signal.

A lot of people have had success just doing a Serout as you have done - but many have added a Serout... "UUU" plus a brief pause before the main Serout.
Some get really carried away with loads of "U"s but I fail to see the point.

It's to do with keeping the RF Rx electronics happy (often called the Data Slicer).

To keep the Data Slicer really happy then you would have to go to Bi-Phase (aka Manchester) but that's a lot fo hard work if you don't need it.

In FSK I'm not sure whether all that fuss is needed as Manchester slows things down a lot.

Assuming Wolfy's post was about a load of "U"s for a preamble I would stick to that and then follow it with your Serout. For the Rx, if you don't mind a blocking command, then use the Wait For syntax for your Serin.

In any event, I would practice using wires before moving to RF.

kd5crs said:

I've read that I will get better results out of my Sparkfun 434 mhz pair if I always send an equal number of 1's and 0's.

Click to expand...

Interesting piece of information. Any idea why? In the same transmission or across the life of the TX/RX pair?

EDIT: and at the 0 and 1 level, have you any idea if you are sending more 1's and zeroes without trying to fix this, what must be, n'th order 'improvement'?

As I'm sure Dippy will agree, Radiometrix application sheets tell you all you need to know about this stuff. From App sheet 28.

The data is sent in a burst, or packet, comprising of:

[preamble] [uart ‘start’ byte] [framing bytes] [data ‘payload’] [checksum]

Characters must be sent continuously, start bit to stop bit without gaps (or the mark:space ratio will become unpredictable).

Assuming 1+8+1 (one start, 8 data, 1 stop) format, a sequence of 55h (ascii U) characters provides a square wave preamble. After the transmitter is turned on, a stream of these preamble bytes must be sent, until the ‘tx-on’ time spec. of
the radio module used has been met. (This will usually be between 3 and 50mS, depending on the module).

An FFh byte must immediately follow the preamble, so the UART can frame on an identifiable start bit. To maintain DC balance, a 00h byte must follow the FFh. Both these bytes can form part of the decoded ‘framing’ sequence of the burst.

Then, to maintain mark:space balance, data can be sent by using only those characters with an equal number of ones and zeros in them. Of the 256 possible 8 bit codes, 70 contain 4 ones & 4 zeros. Omitting 0Fh, F0h, 3Ch and C3h (worst case
‘four ones in a row’ bit sequences) still leaves 66 usable codes per byte, which allows six bits of actual data to be coded into each transmitted byte.
(A full explanation of this method can be found here.

It is necessary to use a number of fixed value bytes preceding the actual data ‘payload’ as packet identification (or ‘framing’ ), to allow the decoder to tell a valid data burst from random channel noise. (In my experience, to avoid false triggering of the decoder, at lease 3-4 bytes of framing data will be necessary.)

Additionally, one or more ‘address’ bytes may be added (to allow co-located operation of multiple systems, or polled access of multiple receivers by a single transmitter), and ideally, a checksum of some kind should be added to the data
packet, as an extra precaution against spurious triggering.

I have described a very simple protocol here. There are many, far more sophisticated techniques in use throughout the industry. The method described does not even offer the best in S/N performance (as the edge triggered UART receiver is overly susceptible to data bit jitter and dropouts compared to a proper duration measuring biphase decoder) but it shows a workable technique, with a minimum of software effort and processing overheads.

(Written by Myk Dormer of Radiometrix)

Click to expand...

A

I would def agree with any RF info that is written by Uncle Myk.
He knows more about RF design than everyone on this Forum put together.

I have copies of most of Radiometrix's App Notes (as well as many other sources).
Great references and don't have to wait for Forum replies

I read, ages ago (and I don't know where on the forum), about the desirabilaty of balancing the bits, so here is what I do for a 3-byte message with a qualifier of "~~~":
With this transmission you can also re-invert on the receiving side and check for errors. It is the "pause 5" after transmitting "UUU" which is wolfgang's excellant suggestion. This is just a stab in the dark for me--no evidence to support.

I found that adding the 'pause 5' to my RF code made a huge difference - the signal was recieved all of the time, instead of just some of it.

lbenson - ~ is binary 01111110 - not the most balanced in terms of 1s and 0s, plus 6 1s in a row isn't great. I tend to use a random number (say 52) as a qualifier - 0011010100110010 is a bit more varied and balanced.

A

Re inverse, a list of ascii characters helps http://www.asciitable.com/

you need to match the characters close to each other, so for "preamble" send "p" (which is ascii 112) then send 143 (which is 255-112). Then send "r" (114) and 141 and so on.

For preambles, I like to keep them short (2 characters) and pick ascii characters with equal numbers of 1s and 0s. Windows Calculator (click the scientific option) is helpful for decimal to hex to binary.

I don't know about the bigger picaxes but the smaller ones are only 14 bytes and if you send 6 U's at the beginning I don't think it will get too out of balance with 14 bytes. I did some range testing and got maybe 5% further with balancing, and I'm not sure it is worth it because you can effectively only send half the number of bytes.

You can get much bigger improvements than 5% extra range by some very simple things, like getting the antenna 2-3 metres off the ground.

Two things to consider -

1) A longer preamble ( U's ) may better condition a receiver than shorter.

2) Transmissions with more bytes will usually benefit from balancing.

Best balancing is done using Manchester Encoding where each bit is sent twice, normally then inverted. This means two bytes sent per data byte and some complicated code to set the bits. Next best is what I call "poor man's Manchester Encoding", send each byte twice and consecutively, first time normal, second time inverted.

There's a third option which is to send additional U's which don't balance previous bits per se but again recondition the receiver. The outcome should be the same, so simply drop U's within the data sent and ignore when received. How many and how often is left as an adventure for those using RF but as an example ...

Transmit:
SerOut TX_PIN, TX_BAUD, ( "UUUUUUUUUU" )
Pause 5
SerOut TX_PIN, TX_BAUD, ( "XYZZY", "U", b0, "U", b1, "UU", b2 )

Receive:
SerIn RX_PIN, RX_BAUD, ( "XYZZY" ), b13, b0, b13, b1, b13, b13, b2
SerTxd( "Received = ", #b0, 9, #b1, 9, #b2, CR, LF )

In the receiver 'b13' is used to 'sink' / discard the U's within the data stream, the same variable can be used multiple times as above so only one 'wasted' variable - It could also be the one used which holds the last data so no extra variables required ...

SerIn RX_PIN, RX_BAUD, ( "XYZZY" ), b2, b0, b2, b1, b2, b2, b2

Use Symbol and the above doesn't look so confusing, and arguably more understandable ...

Symbol U = b2
SerIn RX_PIN, RX_BAUD, ( "XYZZY" ), U, b0, U, b1, U, U, b2

Dr_Acula makes an interesting point on length of qualifiers; longer means better rejection of noise, interference and other transmissions, but adds to the unbalancing of bits. There's no reason not to have U's within and at the end of the preamble to recondition the receiver and choosing preambles with balanced bits is a good idea. Note that although we all often specify a preamble as a text string, there's no reason not to use hex bytes and that can have advantages as 7-bit ASCII data will not clash with those -

SerOut TX_PIN, TX_BAUD, ( $33, $CC, $A5, $5A, $F0, $0F, b1 )

SerIn RX_PIN, RX_BAUD, ( $33, $CC, $A5, $5A, $F0, $0F ), b1

Idea.

(I think I’ll call it Rochdale coding, unless it’s already got a name)

Each data byte has an associated score. +1 for each 1, -1 for each zero. So the total score for %01010101 would be zero, and %11010011 would be +2, and %01000011 would be -1 etc. These scores are extracted from in a table to keep things fast.

Now you send the byte sequence, adding the scores as you go. Every (say) fifth byte is a correction byte chosen with an appropriate score to bring the average back to equality.

Much smaller overhead than Manchester coding. Not sure how easy it would be in Basic though.

I am particularly thick on Sunday mornings, so can't follow it.
Are we re-inventing a parity check or something?

I remember when I were a lad going to a talk on Sony DAT data recovery. The theory was really slick. And, now, due to lager I can't remember any of the detail other than it being very impressive.

“Are we re-inventing a parity check or something?” Don’t think so.

The point is that for reliable RX, the TX has to send an equal number of 1’s and 0’s. This keeps the average signal level in the middle. I’m guessing here, but it’s possibly something to do with an RX coupling capacitor which will become charged should the average signal level deviate too far from vcc/2.

The obvious solution is to sand a byte and its inverse. IE: %11111010 followed by the inverse correcting byte %00000101. Thus the average number of 1’s and 0’s is always equal. But this requires a 100% overhead of extra data being transmitted, effectively doubling your packet size and halving your transmission rate. The method I’m suggesting still produces an average equal number of 1’s and 0’s in the data stream but requires much less overhead. So you get smaller packets and higher overall data rates.

%11111010 has 6 ones and only 2 zeros. So it has a +4 bias (It has 4 more 1’s than it has 0’s). If the following byte has 6 zeros and 2 ones, it has a -4 bias (4 more zeros than ones). Together they have an equalising effect. The average total bias is zero.

My suggestion is that the bias of each byte be calculated (number of zeros subtracted from number of ones) and put into a lookup table, with a +1 for every excess 1 and a -1 for every excess zero. This table will only need to store one of 7 different values for each of the possible 255 bytes: 8, 4, 2, 0, -2, -4, -8.

Just before transmission, the bias for each of the data bytes is retrieved from the table and summed, so you have a total bias for the packet. Then you add one more byte at the end of the packet that carries a correcting bias, bringing the average number of 1’s and 0’s for the whole packet back to equality.

EG:
You want to send these four bytes: %11011010 + %00011111 + %10101010 + %00110001.

Byte1 has a bias of +2, Byte2 of +2, Byte3 of zero, Byte4 of -2. The sum of these biases is 2+2-2 = +2. So in order to preserve a zero bias average, you bolt on the end of the 4 byte packet an extra ‘correcting’ byte with a bias of -2 (A byte with two more zeros than ones). Say %00000111.

Sometimes this will not be possible. Say if the total bias for the four data bytes is >8 or <-8, in which case, additional correcting bytes may be needed. EG: Worst case scenario. If your data is $FF+$FF+$FF+$FF, then the minimum number of additional correcting bytes would also be four : $00+$00+$00+$00.

Still, TX programming overhead aside, this should increase data rates somewhat.

Bugger. I just noticed a flaw in this system. Ah well, back to the beer. (Prize for spotting the flaw is a signed photograph of my knee)

Too much for my 3 remaining grey cells on a Sunday morning but the point should be as on-offy as possible.

Perhaps the people (probably degree level mathematicians) that designed Manchester (coding, not the city) spent more than an hour on it ?

Having said that, there is nout wrong with building a better Mouse Trap.

The point is that for reliable RX, the TX has to send an equal number of 1&#8217;s and 0&#8217;s.

Click to expand...

That's exactly it, but as one who not had much experience in this field, I'd be interested to know just how important it is.
Does it give an extra 1mm range or does it increase by a factor of 10?
Obvioulsy we can't send DC so there is also a real 'reliability' issue at stake but with genuine 'data' how much effect does it really have?

Dunno, prob depends on construction of receiver and method of transmission (?).
But it certainly improves reliability.

Anything on the Radiometrix site?

"the TX has to send an equal number of 1’s and 0’s"
- surely it is more like sending a balanced numbr of 1s and 0s . An "equal number" could be over a longer period of time and therefore a little ambiguous.
Check out the Manchester/Bi-phase method.

I would suggest that someone spends a few hours Googling and regurgitate the expertise .

Does it give an extra 1mm range or does it increase by a factor of 10?

Click to expand...

In my limited experience I found that with very unbalanced data ( i.e. long continuous strings of 1's or 0's ) the effect was not so much a decrease in range, more a total unreliability at any distance !.

Thanks Buzby. I guess it's one of those things I'll just have to try as there are so many variables at play.

Dippy, it would be nice (I haven't actually looked yet) if the datasheets would give maximum as well as minimum pulse width values for the data pin and/or figures for duty/frequency. ie how many $FFs or $00s can be sent in a row.

If it's of any vague interest and assuimg my thingy (I didn't write it) is working properly:

Value 10101010 (170)
Manchester 1001100110011001

Value 11111111 (255)
Manchester 1010101010101010

Value 00000000 (000)
Manchester 0101010101010101

You can see how it is doing its best to balance the 0s and 1s and, by default, produce an equal number.
It also has the advantage that, during decoding, an error can be detected.

BB: Yes it would.

boriz said:

Bugger. I just noticed a flaw in this system. Ah well, back to the beer.

Click to expand...

Is it that adding correcting bytes on at the end is (1) too late if "unbalanced 1's and 0's" has already caused a fatal imbalance, (2) adding them at the end gets things into balance but for no good reason as there's no further data to receive, or (3) having tended towards an imbalance in one direction sending the balancing bytes creates an imbalance in the other direction looking at a shorter, most recent, timescale ?

If you've spotted another potential problem or weakness it would be good to hear it. The theory of Rochdale encoding seems sound if the balancing bytes are sent often enough; if sent after every byte it's almost the same as sending the inverse.

Unfortunately I only understand the issue on a macro level ( the ideal stream will be balanced ) but don't understand the details of what actually happens on a micro level.

I never thought of seizing upon a name for interspersing "U" characters in the stream. Saddleworth Encoding first comes to mind ( for no consciously good reason ), Ashby-de-la-Zeuche Encoding (ADLZ) has a ring to it, but it should really be named after somewhere up t'north near the Pennines where sheep are commonplace.

Lots of ewes, geddit

Oh my gawd ....that's terrible

I prefer RiTW coding.

The thing with Manchester Encoding is that it doesn't just give a balanced stream of 1's and 0's ( that's perhaps just a fortunate side effect ) but it makes the data stream 'self-clocking'; you can determine what bits are even if the baud rate is well out of spec or not even known or variable.

This is handy for countering Doppler effects ( transmitter and receiver moving apart or closer ) for ground to satellite or vehicle comms, when the transmitter is hung on a spring ( tyre/wheel status transmitters - also rotating ! ), or where the signal is put on something which may have variable playback speed; Burnt-In Timecode on video tape.

Ideally one would read the Manchester Encoded stream, determine the data without knowing its baud rate and deliver up the determined data. We only use SERIN on a PICAXE because we cannot do Manchester Encoded reception easily. That forces everyone to give up the real advantage of what Manchester Encoding offers but it does work and also simplifies the transmitter. The downside is that we then have to sometimes keep the receiver happy when it's lacking the Manchester Encoding.

This seems like a good time to mention the following hardware alternative to the 'adventure' of trying to balance the bits with software.

http://www.picaxeforum.co.uk/showthread.php?t=13023

I always try the easiest suggestion first, so I added the U's between each byte. That did increase the amount of transmissions making it through.

My test setup (hardware is identical on each end):

Board A:
Sends long preamble "waitforit", then 5,4,3,2,1
Board B:
Receives, sends back bytes received
Board A: Increments counter, then sertxd's counter, and the data which should be 5,4,3,2,1. Then everything starts over.

So the output looks like:
1 54321
2 54321
3 54321

etc. Bad data looks like

5 5432221

If the preamble doesn't make it, then everything stops. I'm using a very long preamble to exacerbate any transmission issues for the test.

Originally, I would often fail to get one complete cycle. If it did make it, I'd says twelve cycles was about average. Data corruption very rarely happened, seldom enough that I'm not taking any additional steps.

With the added U's, I get at least one transmission cycle every time. In fact, I don't think I've gotten less than 20. Greatest number of cycles before it stops is 74.

That's still a far cry from Wolfgang's 70,000 bytes, but it is more than enough for my purpose. I thing using Hippy's U method should be suggested practice.

(Board A and Board B are separated by 100 feet and 3 interior walls.)

Brian

@Hippy.

“adding them at the end gets things into balance but for no good reason as there's no further data to receive”

This is actually quite close, but I’m assuming the data stream consists of much more than just 4 data bytes. The flaw is that the number of correction bytes is variable, therefore the RX needs synchronising somehow so it knows where the beginning of each packet is. Otherwise, after the first 4 data bytes + n correction bytes, how does it know which of the subsequent bytes are data and which are bias correction bytes.

It would work just fine if there was only one correction byte every time: 5 byte packet, first 4 are data, ignore the fifth.

The solution is for extra processing at the RX, with its own bias lookup table. So it can work out for itself how many correction bytes are required for each packet. It would work I suppose, but the code overhead is getting a bit bloated.

What is your preamble again?

Is it "waitforit"

If so
01110111
01100001
01101001
01110100
10010110
01101111
01110010
01101001
01110100

Is that 39 1s out of 72, 54%

Pretty close to balanced. You could make it perfect by looking at the ascii table and picking letters with equal numbers of 1 and 0.

The fact that some are not getting through means it is right on the limit of the radio link, and the signal is going to be noisy and the slightest interference (eg flouro being turned on, blender, vacuum cleaner) is going to swamp the signal.

I presume the antenna is the correct length?

If you already have the Tx and Rx units, maybe look at a bit of antenna gain, eg a few yagi elements to make the radio signal more directional?

the bandwidth of the radio modems in question doesn't extend to DC ie it's AC coupled.
This means that if you send a constant '1' or '0' the rx won't be able to decode it properly as you would be trying to send DC.

Practially the conversion of the analog data received ( yes, the digital signal you transmit is converted to an analog signal by the transmitter ) is done via an AC coupled comparator.
given that the Rx & TX are not perfect in frequency or stability, there will allways be some variations in there. To reduce the effect of these variations, AC coupling ( or bandwidth filtering ) is used. However this is only going to work if the received signal is relatively free of DC offset, hence the requirement to have a similar number of 1's and 0's in the data stream.
You can work out from the actual bandwidth and filters what the maximum number of consecutive 1's or 0's that can be sent and still be decoded ok.

This is also the other reason for sending a preamble of alternating 1's and 0's ( ie ascii 'U' = 0x55 hex or 01010101 in binary ). it's to get the rx comparator ( the capacitor in the comparator cct ) into the best state to decode the data correctly.
i'll try and dig up some references/pics to demonstrate this.

hope this helps.

[edit] pretty good description of a data slicer http://www.maxim-ic.com/app-notes/index.mvp/id/3671

Bit of a dog

I can’t help coming to the conclusion that getting a basic rf link to work by trying to balance bits is like training a dog to walk on it’s hind legs. Although the result is not very elegant, it is amazing the dog can manage it at all.

Unless we want this topic to keep appearing on the forum, it may be time to come up with a more reliable alternative (e.g. code for Manchester or FSK encoding).

Not sure why you say that MFB i.e. implying it's difficult.
Manchester/Bi-phase has been working successfully for donkey's years.
If you saw how to endcode/decode Manchester you'd see it isn't difficult.

If you realy want to re-invent a better wheel then design an algorithm which does a similar thing but faster. But, if you see the code, you'll realise that it isn't worth the bother.


I can PM you some non-PICAXE-BASIC Manchester code and you can probably translate it.

Dippy, I quite agree that Manchester coding is a well-established and reliable way to transmit digital information, and in fact included this (together with FSK) as an option. What I meant was that trying to match to a specific radio link, by adding strings of 'U' and pauses etc, is difficult and offers poor noise immunity.

What I would like to see is a PICAXE feature along the lines described at www.mikroe.com/en/books/picbasicbook/09.htm#9.4. The higher speed of the X2 should provide a very useful Manchester encoded data rate.

An FSK alternative might be to use the DAC output facility of an X2 PICAXE.

I'd consider myself a pretty typical electronics newbie, and the wireless has definitely had the biggest learning curve of my picaxe experience. If there were a built in Manchester encoding function or something else to make using these transmitter/receivers easier, that would only be positive for the educational nature of picaxes.

Of course, I have no idea what is required to make that happen, so that's my 0.01.

Brian

Brian, I posted a suggestion some years ago to the effect that adding Manchester I/O commands would make low cost/power radio communications a ‘killer application’ for the PICAXE. The higher speed X2 range now makes this approach even more worthwhile.

I also submitted the following idea for PICAXE generated FSK encoding

www.picaxeforum.co.uk/showthread.php?t=13464&highlight=FSK

Again, the high speed of the X2 range and onboard DAC might make this worth a second look.

All possibilities get considered and reconsidered over time. Whether something gets implemented or not is based on a number of factors incuding difficulty, effort, degree of usefulness and balancing some factors against others as well as chip constraints. There will always be arguments in favour and against particular choices, everyone will have their own opinions.

I'm personally impressed at how well 433MHz comms works using just SERIN and SEROUT if designed and implemented properly and that seems to fulfil most people's needs though I don't have any hard evidence to base that on.

For more advanced comms, Machester Encoding and similar ,there may be other choices than including such abilities on-chip; commercial products which do that, dedicating additional PICAXE's to perform those tasks and options which bypass the need, such as XBee and other more RF modems etc. That's not to say that Manchester Encoding or anything else won't be supported, nor that it will.

I'm still a bit confused by the problem. Is the problem that the data won't quite go the distance and balancing might help another 10% on the range?

If so, and given the Manchester encoding halves the bit rate, you can get the same effect by sending the complement of each number. eg if you send 0, then send 255. If you send 1, then send 254. Choose ascii characters for the preamble that have the same number of 0s and 1s. So this is the same speed as Manchester and also gives equal balancing. And the coding already exists for picaxe.

For me, the cheap and cheerful AM RF modules for $2-3 each work fine for short range and two picaxes and tiny 14 byte packets, and for longer range and big files there are a great variety of RF transceivers for about $25 each that will go up to 3Km and they have all the error correcting on board.

I have yet to even get to the point where range is even an issue. I get the same behavior regardless of range. Either they won't work right next to each other, or they work well through 3 walls ans 100 feet. Since adding the Us makes such a positive difference, it must be a balancing bits issue. Hence, if they were balanced by default, it would be easier to use these cheap modules.

That's my thought process, anyway.

If xbees were half the price, then I'd just use those and toss these cheapies in the trash. But until that day, gotta use what I can afford 11 of.

Code is free!

Brian

What quality are these transmitters and receivers, are they matched pairs, or some $1 cheapo's from some backstreet market flogged via eBay ? Others are far more expert in RF than I am but even I agree that if you're at bottom of the bucket prices, you often get what you pay for.

It is worth pointing out that hardly any modules will work if they are less than 1 metre from each other. The Rx simply gets swamped with power. So for testing, put them at either end of the bench.

The cheapie ones do work up to a point but it depends *which* cheapie. Specifically, what you need to know is the db rating on the receiver. (Most Tx units are 10mW and that is the legal limit in most places, so it all comes down to the receiver). Decibels are a log scale where db is a doubling of power and 10db is 10 times the power. Cheap ones will be -93db. Another common figure is -109db, which is 40 times more sensitive. And the transceiver modules are -119 to -123db. -123db is 1000 times more sensitive than -93db.

In practice, higher sensitivity = more reliable data transfer.

Do you have a figure for the Rx sensitivity?

-105db. I think you guys are getting the wrong idea... The modules work fine, certainly better than the $5 bill I spent on it would!

I just know there is room for improvement. From one perspective, if you have to transmit the data 5 times to guarantee reception, who cares? From another perspective, it could matter a great deal.

Thanks for the 1 meter tip.

Edit: I can experimentally confirm that adding U's between the bytes improves reliability... for anyone reading this thread later.

Brian

-105db is pretty good, especially for $5.

Like you say, if you have to send the data a few times to guarantee reception, does that matter?

I've used a protocol where you have lots of Us to start (up to 10), then two bytes for the preamble and I choose bytes that are 'balanced'. Then 4 data bytes and then two 'checksum' bytes. Because you don't want to spend too many lines of code doing checksums, I simply add those 4 data bytes into a word (eg use w6) and send b12 and b13. Then at the other end, add the bytes up and see if they equal the checksum. If yes, then change a relay or whatever. If no, I flash a led to at least indicate something arrived but it didn't have a valid checksum. That helps with debugging.

If you have 10 Us and then 2 balanced preamble bytes, and then 6 bytes (4 data plus two checksum) then the 12 balanced bytes will more than offset against the potentially unbalanced 6 data bytes. Or to put it another way, the drift away from the 50% point is unlikely to be too bad with only 6 data bytes, even if you have 4 bytes of zero and then a checksum that would also then be zero.

And if you were only sending 'on' and 'off', you could make on = to 10101010 and off equal to 11001100 or something so they are both balanced.

Reception is still iffy, works great for a while, then has a bad stretch. So in order to help diagnose, I made a separate board with a receiver hooked up to my laptop to watch what is actually being transmitted and received. I got some very unexpected results!

The master controller sends out G,G,A,U,B,U. (After some U's to set the receiver gain, as detailed earlier in this thread.) That's a byte balanced prefix "GG", followed by the receiver identity "A", followed by the command to close the blind "B". The U's are for byte balancing and are tossed by the receiver.

Here is the code for the eavesdropper board:

So, as expected, when the command is successful, I see something like:

AUBU&#%*(#%*!% where everything after the AUBU is the junk noise that the receiver is always picking up. Nothing unexpected there. I'll leave the noise off the next example.

I thought that when the command did not go through I'd just receive junk, or it would change every time, but not so! I reliably receive:

PUèU

on those times the command does not succeed. What is that? Why am I sending A, but often receive P? Why am I sending B, but receiving è? The U's are never affected. About 1 in 20 failed tries, I receive:

ÐUBU

So the A becomes a Ð, but the B and the U's make it through.

What do you think is going on here? A is 01000001 and P is 01010000, not particularly similar. Is it not a receiver problem at all, but something wrong with my transmitter? I'm pretty flummoxed by this, I'd expect random values from noise, not the same (but wrong) data.

Brian