Transmission works with wires but not always with wireless

[skimask]

I would use a 5ms pulse as the preamble and a 20ms pause between data packets (it allows the AGC and threshold to reset).

I'm curious as to why you use the 20ms pause between packets? I know you said that the pause would reset the AGC & threshold, and that certainly makes sense. But I would figure if you're continuously sending bi-phase encoded data (manchester encoded) practically non-stop, wouldn't everything stay where it would need to be?

EDIT: (add)
I suppose if the TX and RX were changing positions relative to each other, the signal strength would vary, and maybe the AGC/threshold wouldn't 'keep up' with the varying conditions. The 20ms pause would compensate. If that's the case, then it really makes a lot more sense to me.

[dhouston]

I'm curious as to why you use the 20ms pause between packets? I know you said that the pause would reset the AGC & threshold, and that certainly makes sense. But I would figure if you're continuously sending bi-phase encoded data (manchester encoded) practically non-stop, wouldn't everything stay where it would need to be?

AGC reduces the gain as the signal gets stronger. Repeating the signal at close intervals can cause the gain to taper off, resulting in poorer reception. A gap between transmissions lets it reset to its baseline. You can play with the duration of the gap - in this case 5-10mS is probably adequate but its hard to say without hands-on experience to determine typical signal strength and performance. Also, I'm eliminating the manchester encoding - the NEC protocol assures a relatively balanced ratio of pulses/spaces for the dataslicer threshold.

Another reason for inserting a gap is to allow the receiver time to analyze what it has received and decide what action to take.

It is possible to get a measure of signal strength by taking ADC readings of the receiver's Linear output pin. I measure the difference between a pulse and space which, while it is not an absolute measure (due to AGC), gives a good relative indication of signal strength. IOW, if one signal registers 700 and another 500 I know which signal is stronger (and can use it for tuning) but I cannot definitively compare measurements from separate receivers since I'm not measuring an absolute magnitude.

[skimask]

AGC reduces the gain as the signal gets stronger......since I'm not measuring an absolute magnitude.

Everything you said makes perfect sense to me. And it might also explain a few issues I've always had with a couple of my RF projects and lengthy/continuous packet transmissions getting dropped after a few seconds of transmitting. I'm going to try your 'pause between packets'/'making the packets smaller' idea and see what happens.

[Ioannis]

I can understand that the issues you had might be module related. I never had any problems with FM modules and the ones I designed with the classic slicer approach (given that the proper transmission rules are followed). A good receiver should work 24/7 with no problem.

Ioannis

[skimask]

I can understand that the issues you had might be module related. I never had any problems with FM modules and the ones I designed with the classic slicer approach (given that the proper transmission rules are followed). A good receiver should work 24/7 with no problem.
Ioannis

It's not really 'problems' I have with the modules. They work fine for me, in bursts. I have a couple of project where one of my remotes acts sort of like a volume control and I have to continuously hold the transmit button down to get the receiver to change, takes about 15 seconds to run from one end to the other. About 3 or 4 seconds into holding the button, it craps out. If I release the button for less than a second and press it again, it'll work for another 3-4 seconds, then repeat. Again, no real problems, and I have a feeling that dhouston's hints earlier may solves this issue.

[dhouston]

It's not really 'problems' I have with the modules. They work fine for me, in bursts. I have a couple of project where one of my remotes acts sort of like a volume control and I have to continuously hold the transmit button down to get the receiver to change, takes about 15 seconds to run from one end to the other. About 3 or 4 seconds into holding the button, it craps out. If I release the button for less than a second and press it again, it'll work for another 3-4 seconds, then repeat. Again, no real problems, and I have a feeling that dhouston's hints earlier may solves this issue.

That's somewhat analogous to dimming a lamp using an X-10 palmpad to send RF to a module that translates it to powerline commands to control the lamp module.

X-10 uses the NEC protocol and the palmpad will send 32-bits continuously with each 32-bit burst preceded by a ~9ms/4.5ms lead-in and followed by a 40ms gap (so each code is ~105ms). It takes about 4-5 seconds to go from full on to full dim and it's very smooth.

I conduct range tests (and RF tune receivers) by clamping a button down on a palmpad. The receiver operates smoothly for the several minutes I leave the transmitter clamped.

IOW, I think you'll do better using the NEC protocol or some variation on it.

One other thing to consider (which I alluded to earlier) is that you usually have at least two timelines. One is for the RF bitstream and one is for the action to be taken by the receiver (e.g. adjust volume or brightness). Things will be smoother if the end action can finish during the gap between code bursts. That way the receiver is ready to capture the next burst(s) and act on it (them).

The NEC protocol (or variations of it) is the most popular (and oldest) protocol used for IR control of AV gear. If it has been so successful there, it makes sense to me to use it in similar low data rate RF applications.

[dhouston]

I can understand that the issues you had might be module related. I never had any problems with FM modules and the ones I designed with the classic slicer approach (given that the proper transmission rules are followed). A good receiver should work 24/7 with no problem.

Agreed - but these are $5 (retail at Mouser Electronics) superregenerative ASK receivers with a maximum data rate of 4800bps.

[dhouston]

Everything you said makes perfect sense to me. And it might also explain a few issues I've always had with a couple of my RF projects and lengthy/continuous packet transmissions getting dropped after a few seconds of transmitting. I'm going to try your 'pause between packets'/'making the packets smaller' idea and see what happens.

Almost all of my experience is with these specific superregenerative ASK receivers (at various frequencies) or with very similar superregenerative receivers. My suggestions may not apply if you're using more sophisticated receivers (e.g. superheterodyne) or FSK. Most of my applications send/receive 2-3 payload bytes. I think a wireless RS232 link and manchester encoding is overly complicated for such simple needs. If there's a need to send lengthy text or data streams, a superheterodyne or FSK receiver and a wireless RS232 link may make more sense.

I cited the following web page earlier in the thread.

• http://davehouston.net/rf-noise.htm

You can see the effects of AGC on the initial pulse in the top trace of the first 'scope screenshot. The slope is from the AGC reacting to the wide pulse. You can see the slope starting in the other direction after the pulse ends. If you look a a lot of 'scope screenshots you'll see the same (less pronounced) effect even between the data pulses and see more pronounced differences between a closely spaced series of 0-bit (narrow space) versus 1-bit (wider space). Of course, it's affected by the absolute pulse space widths as well.

The bottom picture is of a signal captured as a .WAV file with a soundcard. You can see that it's more difficult to discern a signal when it has no pronounced initial pulse to set the AGC. In this case, it's the signal sent by a Pronto touchscreen to a Philips RF extender. The three copies of the preamble contain information to address a specific RF extender and set its carrier frequency, etc. which must precede the actual IR code the extender is meant to relay. Philips doesn't use a superregenerative reveiver and they take other steps to improve reception (double modulation) but the picture illustrates the weaknesses of using no preamble or a narrow lead-in pulse with a superregenerative receiver.

[vinay kumar]

Hi,
Any idea or estimation that are available towards the usage of the ISM band (2.4Ghz to 2.48Ghz) and the WMTS (Wireless medical telemetry service) band ( 608MHZ to 614MHZ, 1395MHZ to 1400MHZ) in the next coming decade for the purpose of the wireless communication implementation.

It would be really great if any info available towards the same is linked to me, [email protected].

Thank you.