Transmission works with wires but not always with wireless

[dhouston]

I have used these extensively (although I get mine direct from WenShing in Taiwan). These are superregenerative ASK receivers. They need a pronounced preamble in order to set the AGC and receive threshold. They work quite well at low data rates using a protocol like the NEC protocol (used by X10 for their wireless remotes) which I've detailed here...

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

You might also benefit from reading this page...

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

You need a fairly good balance between pulses and spaces (which Manchester encoding guarantees) but the fact that you need to send several copies in order to receive reliably indicates you need the initial copies to set the threshold and AGC.

Which output pin are you using? Using the linear (analog) output can complicate things. It's usually best to use the digital output. A good receiving antenna is important. An eggbeater is easy to build and matches the 50-ohm input impedance of the receiver.

• http://davehouston.net/eggbeater.htm

You can capture the output(s) from the receiver using a soundcard as I show here...

• http://davehouston.net/learn.htm

which can give you an idea of the quality of the signal as received.

Bruce Reynolds sells the 433.92MHz version of this receiver. I believe he has some example projects with PBP code on his website.

BTW, the fact that your code works with a hardwired connection is another indication that your problems are related to RF signal quality.

Good luck.

[oneohthree]

I have used these extensively (although I get mine direct from WenShing in Taiwan). These are superregenerative ASK receivers. They need a pronounced preamble in order to set the AGC and receive threshold. They work quite well at low data rates using a protocol like the NEC protocol (used by X10 for their wireless remotes) which I've detailed here...

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

You might also benefit from reading this page...

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

You need a fairly good balance between pulses and spaces (which Manchester encoding guarantees) but the fact that you need to send several copies in order to receive reliably indicates you need the initial copies to set the threshold and AGC.

Which output pin are you using? Using the linear (analog) output can complicate things. It's usually best to use the digital output. A good receiving antenna is important. An eggbeater is easy to build and matches the 50-ohm input impedance of the receiver.

• http://davehouston.net/eggbeater.htm

You can capture the output(s) from the receiver using a soundcard as I show here...

• http://davehouston.net/learn.htm

which can give you an idea of the quality of the signal as received.

Bruce Reynolds sells the 433.92MHz version of this receiver. I believe he has some example projects with PBP code on his website.

BTW, the fact that your code works with a hardwired connection is another indication that your problems are related to RF signal quality.

Good luck.

I am using the digital data output pin. Also, since I need to send my data 5 times and with a pause of 5 does it mean that I should make my preamble longer?

[mister_e]

Serial communication is a female thing, so bear in mind that preamble are needed and some of them may say the size don't make any difference
---------------------------------------------------------
Usually 3-5 $AA as preamble is enough. Machester encoding have it's own advantage if you send long data packet. A checksum is also handy.

I don't think the character pacing (pause x) is really needed if you're using a slow baudrate (2400 bauds or so)

a single SEROUT/DEBUG/SEROUT2/HSEROUT line is all you need in many case.

Always make sure your crystal are accurate.

BTW which PIC are you using?

[oneohthree]

Serial communication is a female thing, so bear in mind that preamble are needed and some of them may say the size don't make any difference
---------------------------------------------------------
Usually 3-5 $AA as preamble is enough. Machester encoding have it's own advantage if you send long data packet. A checksum is also handy.

I don't think the character pacing (pause x) is really needed if you're using a slow baudrate (2400 bauds or so)

a single SEROUT/DEBUG/SEROUT2/HSEROUT line is all you need in many case.

Always make sure your crystal are accurate.

BTW which PIC are you using?

I'm using PIC16F88. I have 4 $55 and am using Manchester Encoding.

[skimask]

I'm using PIC16F88. I have 4 $55 and am using Manchester Encoding.

So...
oneofthree = jyi1 ???

[Ioannis]

So...
oneofthree = jyi1 ???

You are such a tease...!

oneofthree or jyi1 or whatever your name is (we never got any) I told you before to start one data byte at the time. A complex program is hard to debug especially if there are serial com's.

Also do not manchester encode the preambles. Only the data bytes and CRC or Checksum.

Ioannis

[languer]

I looked back at some previous projects I have done with wireless comms. I have not used the Laipac modules, but have used the RFPICs and the Radiotronix modules.

I have used 1200 baud with one preamble, two start-of-transmission identifiers (STX), and one end-of-transmission (ETX) identifier. The packet data is between these wrappers. In my experience the manchester coding did not help much with short messages.

The only thing I was able to find was the following comments in my code:

/* for wireless link, the "invert" option should not be used
as this causes the transmitter to iddle on */

My point is, have you tried your code with T2400 (as opposed to N2400)?

[dhouston]

I am using the digital data output pin. Also, since I need to send my data 5 times and with a pause of 5 does it mean that I should make my preamble longer?

I would use a 5ms pulse as the preamble and a 20ms pause between data packets (it allows the AGC and threshold to reset).
On the receiving end I would use PulsIn to wait for the 5ms pulse and then go into the normal receive routine once it's received. Using some type of error detection (e.g. checksum) is a necessity.

What range do you need? How much data do you need to send?

Looking at the digital data pin with a 'scope (or recording it with a soundcard as I suggested earlier) can eliminate a lot of guesswork by telling you whether your signal strength is adequate. I find it invaluable.

[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

[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.

[jyi1]

I would use a 5ms pulse as the preamble and a 20ms pause between data packets (it allows the AGC and threshold to reset).
On the receiving end I would use PulsIn to wait for the 5ms pulse and then go into the normal receive routine once it's received. Using some type of error detection (e.g. checksum) is a necessity.

What range do you need? How much data do you need to send?

Looking at the digital data pin with a 'scope (or recording it with a soundcard as I suggested earlier) can eliminate a lot of guesswork by telling you whether your signal strength is adequate. I find it invaluable.

Is the code that I wrote below what you are trying to tell me?
I am only trying to send 4 bits (8 bits encoded). I looked at the digital data pin of the scope and my signal has an amplitude of about 3.72 v.

Transmit:
Pulsout PORTB.7, 500
Pause 20000
serout PORTB.7, n2400, [$aa,encoded2]
Pause 20000

Receive:
Wait55:
Pulsin PORTB.0,1,ct55
If ct55 = 500 Then
goto Waitaa
Else
goto Wait55
Endif
'goto Wait55

Waitaa:
serin PORTB.0, n2400, encoded1
If encoded1 <> $aa Then goto Maina
serin PORTB.0, n2400, encoded1
write 0, encoded1

[dhouston]

Is the code that I wrote below what you are trying to tell me?
I am only trying to send 4 bits (8 bits encoded). I looked at the digital data pin of the scope and my signal has an amplitude of about 3.72 v.

Transmit:
	Pulsout PORTB.7, 500
	Pause 20000
	serout PORTB.7, n2400, [$aa,encoded2]
	Pause 20000

Receive: 
Wait55:
        Pulsin PORTB.0,1,ct55
        If ct55 = 500 Then 
           goto Waitaa
        Else
          goto Wait55
        Endif
        'goto Wait55

Yes, more or less. I would change it to...

Transmit:
	Pulsout PORTB.7, 500
	Pause 2500     'shorten space
	serout PORTB.7, n2400, [$aa,encoded2]
	Pause 20000

Receive: 
Wait55:
        Pulsin PORTB.0,1,ct55
        If ct55 < 450 Then Wait55
        goto Waitaa

The important thing with the signal is that it be clean with no noise pulses interspersed with the data.

With only 4 bits, I think I would use a variation of the NEC protocol, sending only 1 byte with each code. The NEC protocol has error detection built in so you can discard any corrupted codes. Read the NEC protocol documentation in the link I cited earlier and if you still have questions I'll try to answer them here.

[jyi1]

Yes, more or less. I would change it to...

Transmit:
	Pulsout PORTB.7, 500
	Pause 2500     'shorten space
	serout PORTB.7, n2400, [$aa,encoded2]
	Pause 20000

Receive: 
Wait55:
        Pulsin PORTB.0,1,ct55
        If ct55 < 450 Then Wait55
        goto Waitaa

The important thing with the signal is that it be clean with no noise pulses interspersed with the data.

With only 4 bits, I think I would use a variation of the NEC protocol, sending only 1 byte with each code. The NEC protocol has error detection built in so you can discard any corrupted codes. Read the NEC protocol documentation in the link I cited earlier and if you still have questions I'll try to answer them here.

I tested out the above code thats included in my code and it does not work by wireless or by wire.

[dhouston]

I'm not going to try to read your unformatted code or write the entire application but here are code snippets that show you what you need to do. It sends 4 bits both "as is" and as bitwise complement using a variation of the NEC protocol. I've hardcoded the 4 bits of data as 1101. This is adapted from code I use to send and receive 2-4 bytes so the pins are the ones I used. There are more efficient ways to do things but I've tried to show it step-by-step so you see the logic.

'-----Transmit-----
SendRF: wb.0=data0  '00000001
        wb.1=data1  '00000001 
        wb.2=data2  '00000101
        wb.3=data3  '00001101
        wb=~wb      '11110010
        wb=wb<<4    '00100000
        wb.0=data0  '00100001
        wb.1=data1  '00100001
        wb.2=data2  '00100101
        wb.3=data3  '00101101
        'bits 0-3=data, bits 4-7=~data
        Low 4
	For c=1 To Copies
	  PulsOut 4, 500
          PauseUs 2500
	  For i=0 To 7
	    PulsOut 4, 50
	    If wb.0=1 Then
	      PauseUs 1500
	    Else
	      PauseUs 500
	    EndIf 
	    wb=wb>>1
	  Next
	  PulsOut 4, 50
	  Pause 20			
	Next

'-----Receive-----	
DEFINE PULSIN_MAX = 550
	
RcvRF:  PulsIn GPIO.1, 1, STX
        wb=0
        If STX<450 Then RcvRF
        While GPIO.1=0:Wend
        For i = 0 To 7
          PulsIn GPIO.1, 0, space
          If (space<40) Or (space>175) Then RcvRF
          If (space>75) Then
            wb.0=1				
          EndIf
          wb=wb<<1
        Next i	
        comp=wb>>4
        wb=wb & 7
        If wb + comp = 15 Then
          'wb is good data
        Else
          'wb is corrupt
        EndIf