Transmission works with wires but not always with wireless

[jyi1]

I am using the Laipac 315 MHz RF modules and I serout only once and it works with wires 100% of the time. When I try wireless it works once in a while. On the other hand, when I serout 5 times the wireless works most of the time but does not work once in a while. I have added 4 $55s for a preamble and manchester encoded everything.

[skimask]

I am using the Laipac 315 modules and I serout only once and it works with wires 100% of the time. When I try wireless it works once in a while. On the other hand, when I serout 5 times the wireless works most of the time but does not work once in a while. I have add 4 $55 for a preamble and manchester encoded everything.

But yet we don't see any code to base an opinion on what could possibly be wrong!

[Darrel Taylor]

skimask,

Not all solutions require the persons code to solve the problem.

If you've used a "Laipac 315" before, then maybe you've noticed something that might apply.

He's made a very specific request, and shouldn't expect an answer for quite some time. Hopefully from someone that's tried that device before.

You're indignant response only 1 minute after his post, does not help.
<br>

[jyi1]

Transceiver

Include "Modedefs.bas"

ct55 var byte: encoded1 var byte: p var byte: counter var byte: e var byte: action var byte:
encoded var byte: encoded2 var byte: action2 var byte: B0 var bit: B1 var bit: B0=1: B1=0:
p=0: e=0: encoded1=0: counter = 0: action=0: action2=0: encoded=0: encoded2=0:

Main:

Clr:
p=0: e=0: encoded1=0: action=0: action2=0: encoded=0: encoded2=0

Maina:
ct55=0 'counter for $55 is zero

Wait55:
serin PORTB.0, n2400, encoded1
If encoded1 = $55 Then
ct55 = ct55 + 1
If ct55 = 4 Then goto Waitaa
Else
goto Maina
Endif
goto Wait55

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

For counter = 0 to 3 : p.0[counter] = encoded1.0[counter*2]:Next counter
write 1,p

e = p:
If ((e.3=B0) and (e.2=B1)) Then
goto L3
Else
write 2, p
goto Clr
Endif

L3:
If((p.1=0) and (p.0=0)) Then
action=%1010
write 3, p
For counter = 0 to 3
If action.0[counter]=0 Then
encoded.0[counter*2]=0 : encoded.0[counter*2+1]=1
Else
encoded.0[counter*2]=1 : encoded.0[counter*2+1]=0
Endif
Next counter:
write 8, encoded
For counter = 0 to 4
serout PORTB.7, n2400, [$55,$55,$55,$55,$aa, encoded]
Next counter
goto Clr


Endif

If ((p.1=0) and (p.0=1)) Then
action2 = %1011
write 4, p
For counter = 0 to 3
If action2.0[counter]=0 Then
encoded2.0[counter*2] = 0: encoded2.0[counter*2+1] = 1
Else
encoded2.0[counter*2] = 1: encoded2.0[counter*2+1] = 0
Endif
Next counter:
write 9, encoded2
For counter = 0 to 4
serout PORTB.7, n2400, [$55,$55, $55, $55,$aa, encoded2]
Next counter
goto Clr

Endif
End

Receiver

Include "Modedefs.bas"
cot55 var byte: encoded1 var byte: p var byte: counter var byte: e var byte:
p = 0: e = 0: encoded1 = 0: counter = 0:

Main:


Mainb:
cot55=0 'counter for $55 is zero

Wait55:
serin PORTB.0, n2400, encoded1
If encoded1 = $55 Then cot55 = cot55 + 1
If cot55 = 4 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

For counter = 0 to 3 : p.0[counter] = encoded1.0[counter*2]: Next counter
write 1,p

If (p.1=1) Then
goto B4
Else
write 2,p
High 2
Pause 1000
Low 2
goto Mainb
Endif

B4:
e = p
write 3, e
High 1
Pause 1000
Low 1
High 5
serout PORTB.3, n2400, [e.3]
serout PORTB.4, n2400, [e.2]
goto Mainb

End

[Jerson]

I am using the Laipac 315 MHz RF modules and I serout only once and it works with wires 100% of the time. When I try wireless it works once in a while. On the other hand, when I serout 5 times the wireless works most of the time but does not work once in a while. I have added 4 $55s for a preamble and manchester encoded everything.

JYI1:

Firstly, I feel a name is more suited to talking in a forum. Anyway, after seeing your code, I do feel you can look for the 55,aa alone as the marker to your data. You may not see the 4x55s followed by the aa considering that the Laipac receiver module is ASK(correct me if I am wrong).

I have used similar modules with PIC and implemented a wireless joystick which works like you say almost 100% of the time. There is an occasional hiccup due to which I would not get 100%. To achieve this, I know that RF shielding of the receiver is priority #1. I did not Manchester code my data, that could be the reason for the almost 100% accuracy. Also, the modules I have used (Summitek) specify the data rate in the region of almost 1200 baud and not 2400 baud as you use. Perhaps you need to look into this as well.

Jerson

[jyi1]

Yes Laipac uses ASK and has 2400 bps. I do not understand why the $55,$55,$55,$55,$aa is not always picked up by the receiver when I send it once. It seems like I need to send it the same thing 5 times for it to pick up reasonably well.

[Jerson]

The module needs time to get above the noise floor before it can decode the $55 stream correctly. That is why I suggested to just look for the $55,$AA in your code; you still have to transmit the $55s before you send the $AA. Those should be considered as padding and ignored in the receiver. You may increase it beyond the 4 that you have now to improve performance if you will.

Transmit $55,$55,$55,$55,$55,$AA,"data"
Receive .................."ah there it is","data" You ignore the first 4x$55


Jerson

[jyi1]

So I should basically send a couple of $55 and then just wait for $55, $aa only?
I'm thinking of coding it like: serin2 PORTB.0, 16780, [WAIT($55, $aa) ,encoded1], would this be good enough?

[Jerson]

I think you got the point. Still, tell us your name. JYI1 sounds like a name from the new StarTrek series ;)

Jerson

[skimask]

skimask, Not all solutions require the persons code to solve the problem. If you've used a "Laipac 315" before, then maybe you've noticed something that might apply. He's made a very specific request, and shouldn't expect an answer for quite some time. Hopefully from someone that's tried that device before. You're indignant response only 1 minute after his post, does not help. <br>

True...but if the guy has the code in the first place, why not hasten the process and post it straight away!

And tell me that this thread/code and this one
http://www.picbasic.co.uk/forum/showthread.php?t=6145
don't look very similar...too similar...not that there's anything wrong with that. I mean, at least the guy (whether it be the same guy as the other thread or actually a new guy) searched the forum's and found some usable code instead asking for somebody else to write it all.
And no, I don't think everything is a conspiracy...or is it?

[jyi1]

I think you got the point. Still, tell us your name. JYI1 sounds like a name from the new StarTrek series ;)

Jerson

I discover that even if I send $55 4, 6, 8, 10, 20 times but it still picks it up occasionally. On the other receiver end I am looking for $55, $aa.

[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.htmYou might also benefit from reading this page...http://davehouston.net/rf-noise.htmYou 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.htmYou can capture the output(s) from the receiver using a soundcard as I show here...http://davehouston.net/learn.htmwhich 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.

[mpardinho]

i had many bug with RF 433mhz
try pause 5 to pause 50

im my circuit pause 5 word perfect
without pause not work for me

my simple test



...
transmiter:
for i = 1 to 30
serout data_out, N2400, ["<", "A", "B", ">", i]
PAUSE 5
next i




...
receive:
serin data_in, N2400, "<ABDC>", TIME_OUT, I
if i=1 then .........

TIME_OUT:
goto receive

[oneohthree]

i had many bug with RF 433mhz
try pause 5 to pause 50

im my circuit pause 5 word perfect
without pause not work for me

my simple test



...
transmiter:
for i = 1 to 30
serout data_out, N2400, ["<", "A", "B", ">", i]
PAUSE 5
next i




...
receive:
serin data_in, N2400, "<ABDC>", TIME_OUT, I
if i=1 then .........

TIME_OUT:
goto receive


The pause helps if I need to send the data more than once. But when I only send it once it doesn't help

[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.htmYou might also benefit from reading this page...http://davehouston.net/rf-noise.htmYou 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.htmYou can capture the output(s) from the receiver using a soundcard as I show here...http://davehouston.net/learn.htmwhich 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 :D
---------------------------------------------------------
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 :D
---------------------------------------------------------
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 ???

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

[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

[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 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.The Radiotronix RCR receivers are clones of the Wenshing/Laipac receivers. The only difference is they number the pins in reverse order. I think Radiotronix gets them from Cansec in China.http://cansec.manufacturer.globalsources.com/si/6008800536479/pdtl/RF-module/1001008172/Antenna-receiver-Board.htm

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

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)?

T2400 doesn't really help.

[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

[jyi1]

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


If I were to run your code to test it would I code data0=0000001, data1=00000001, data2=00000101, data3=00001101 and then code data0=001000001, data1=00100001, data3=00100101, data3=00101101? Also in the for c=1 to Copies, what is Copies supposed to mean?Also, I discover that when I use my old code and send it through once and view the digital output of the receiver and transmitter input the on the oscilloscope the sequence appears but it does not get picked up by the microcontroller.

[skimask]

If I were to run your code to test it would I code data0=0000001, data1=00000001, data2=00000101, data3=00001101 and then code data0=001000001, data1=00100001, data3=00100101, data3=00101101? Also in the for c=1 to Copies, what is Copies supposed to mean?Also, I discover that when I use my old code and send it through once and view the digital output of the receiver and transmitter input the on the oscilloscope the sequence appears but it does not get picked up by the microcontroller.

Call me crazy...but I think between this thread and the other one, you're making the program/process entirely much harder than it needs to be...

[dhouston]

data0-data7 represents the 8 bits of the single byte being transmitted.


data.bit0 = 1
data.bit1 = 0
data.bit2 = 1
data.bit3 = 1
data.bit4 = 0
data.bit5 = 1
data.bit6 = 0
data.bit7 = 0

Copies means the number of times the transmission is repeated. You will need to experiment. If you always have a strong signal you might get by with a single copy; a weaker signal will require additional copies to set the receiver AGC and threshold. Most X-10 RF transmitters send 5 copies.

What I usually do on the receiving end is report the first valid code and then only report subsequent codes if they differ - with a time limit based on the time required to send the five (or whatever) copies.

[languer]

I am using the Laipac 315 MHz RF modules and I serout only once and it works with wires 100% of the time. When I try wireless it works once in a while. On the other hand, when I serout 5 times the wireless works most of the time but does not work once in a while. I have added 4 $55s for a preamble and manchester encoded everything.

I think skimask has a very good point. You started with the statement above and are now deeper than you could ever imagine. There is a subtle truth to the KISS principle, it works and it is simple.


What are your expectations?
Do you have something that works 4-out-of-5 times? I mean you send the message 5 times and you receive it 4.
Where you expecting the link to work 100% of the time? If so, do you know what your link budget is? Do you now how much margin you have? What distance you need to cover?
I do not know of any comm system that works 100% of the time. The best systems (very expensive) use redundancy, error correction, complex modulation schemes, etc. Normal systems (i.e. remotes, sensors, telemetry) usually just encode and send several times.
You pick what you think you need in terms of reliability and no more usually. If you have way more, you over-designed it (your wasting battery power, causing unintended radiation, or something else).

I am not trying to persuade you from making something better. But seeing how complicated it is getting, do you really need it this complex? Or can you keep your manchester coded signal (which apparently is already working) send it a few times and only use the first one that passes a CRC check or something like that?

[dhouston]

Call me crazy...but I think between this thread and the other one, you're making the program/process entirely much harder than it needs to be...OK. You're crazy!

[skimask]

I think skimask has a very good point. You started with the statement above and are now deeper than you could ever imagine. There is a subtle truth to the KISS principle, it works and it is simple.

And one other point I might make...
The 432-433Mhz modules seems to work, the 315 doesn't.
Why not use 2 432-433Mhz modules, one master, one slave. Sure you can't use them both at the same time, bidirectionally. But for instance, maybe the slave will ONLY answer after the master has spoken. Use a PICs pin to provide power to the modules, turn off the master's receiver while it's transmitting, turn off the transmitter while it's receiving, and so on with the slave, only the other way around in reverse...
I think I get what the end result is supposed to be, with changing all the bits around and sending the modified code back. But why not let the PIC handle the bit changing after receiving a certain code or something along those lines.



OK. You're crazy!
__________________
www.davehouston.net


YES!!! :D

[dhouston]

If I were to run your code to test it would I code data0=0000001, data1=00000001, data2=00000101, data3=00001101 and then code data0=001000001, data1=00100001, data3=00100101, data3=00101101?
You said you are sending 4 bits of data. My example was intended to show you how to send the 4 bits twice in two different ways. One way is "as is" in the lower 4 bits of wb; the other way is as the bitwise complement of the 4 data bits in the upper 4 bits of wb. Sending it in two forms allows us to check for errors on the receiving end.

Assuming you want to send %1101...


data=%1101
wb=data
wb=~wb
wb=wb<<4 'bitwise complement %0010 in upper 4 bits
wb=wb+data 'data "as is" in lower 4 bits

The attached GIF shows the waveform for data=%1101.

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

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

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

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.

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