You know both of you are right on this. Manchester does encode the signal such that the information resides on the transitions, and in the case of these particular receivers also serves the purpose of creating a signal which is not biased to one side or the other. In this particular case Manchester does both; and both of these serve to overcome one of the limitations of this receiver design. But you could also use PWM, or many other techniches to overcome the limitations. The beauty of Manchester is that it provides a "belt&suspenders" approach other solutions don't; the downside is that it does so at the expense of twice the bandwidth (so it reduces the possible throughput).The reason for using Manchester isn't to "balance the ones and zeros" as RB suggests, but to avoid the unreliable pulse width problem
If I read you right you are saying that the micro detects the transition in the middle of the 01 pair? How does it do that in a way that does not matter if that transition is in the wrong place? Do you have a simple diagram or something?
...
The key thing when using such modules is realy to "train" the receiver so the AGC has "settled" before the data is sent. And to understand that the data will be "modulating" the AGC; if you have too many consecutive highs , the AGC will trend one way and the duty cycle will favor one end (same thing goes with too many consecutive lows).
...
NigelGoodwin said:Essentially you avoid the 'variable width' problem by not sampling at specific times, you check for the transition within certain time constraints - so (for example) if the transmitted pulse widths are 10mS, then check from 5mS to 20mS for the transition - if it's outside those limits you know there's an error. ...
As for the duty cycle, I understand what you are saying about the hi/lo balance and how it would work with average voltage and a comparator etc, but the result I got from testing was very different.
I can't talk about your experiments or the relationship to what modules you used or not. But I can talk about "regenerative" receivers and AM receivers in general. The modules I've worked with follow that model, and you are correct in stating that the AGC does not directly track the ON/OFF balance; after all it is simply an RC with a diode (or at least you could model it that way) - that is to say it is a peak detector with some decay.
...
... For short burst, if the full strength signal is not changing, you've essentially captured the AGC and you are "free to roam about the country". Now that is usually all well and savvy for strong signals (i.e. transmitter and receiver are close to each other). But for weak signals, where the full strength carrier is say 10dBs above the noise (carrier absent condition), or where the signal is weak and varies quite a bit because signal propagation in air is a statistical measure and is affected by multitude of things (reflections, refractions, interference from nearby frequencies, etc); that AGC is going to move, and it will move a lot in some cases. And it is in these cases where things will go bad. It is in these cases where you won't be capturing the straight information. Unless you somehow make the best effort to capture that AGC. See I'm guessing from your experiments you are looking at nearly ideal situations.
...
... So all I am saying in this long-winded conversation is that what you're really doing by the pulse-period-time coding you created is increasing the reliability of your wireless link; which I'm afraid is ultimately affected by one thing, and one thing only - the AGC of the receiver. If you capture the AGC during your desired message you turn the statistical probability into an almost certainty; if you can't capture the AGC or can't keep it for the duration of the message then you're back to maybe it works and maybe it doesn't. It really boils down to that ...
For a simple system detecting a digital edge, the pulse period system should give higher reliability (and speed) than any other simple system.
Actually the implementation you suggest is quite elegant, simple, and efficient. It provides a very good compromise between reliability and bandwidth requirements (and it is easy on the hardware and software - which in embedded applications is always important).
To me the key to using these type of modules is really establishing a simple protocol. I've seen some people trying to send "Temperature: 27_C"; as opposed to one byte with 27 and letting the receiver interpret the information. In such an example, the first user has to ensure 17 bytes are sent and received flawlessly, while the second user only has one byte to worry about. That just illustrates that in the two examples the necessary information is the same, yet the complexity of one vs the other is quite different.
There are two modules, one for transmit and one for receive.Ive noticed they have just one data pin, does it mean they are only for one way communication?
NorthGuy said:Redundancy is very important too. When your device is sitting there, receiving day and night, just because it has so much time, it's quite possible that it may receive a valid message from pure noise. Happened to me even though I had 16-bit CRCs! To avoid such accidents, I had to severely restrict receiver criteria for data validity.
How did you "severely restrict receiver criteria for data validity?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?
We use cookies and similar technologies for the following purposes:
Do you accept cookies and these technologies?