Wire worked by not wireless

[mankan]

Dear Gurus,

Below is the code I am using to build a wireless data transfer, I started by building a wired connection and it worked very fine but once I go wireless nothing works.

Any idea, hint, help is greatly appreciated.

Thanks,
Mankan

'************************************************* ***************
'* Name : Receiver.BAS *
'* Author : [select VIEW...EDITOR OPTIONS] *
'* Notice : Copyright (c) 2006 [select VIEW...EDITOR OPTIONS] *
'* : All Rights Reserved *
'* Date : 5/10/2006 *
'* Version : 1.0 *
'* Notes : *
'* : *
'************************************************* ***************

INCLUDE "modedefs.bas"

'@DEVICE PIC16F628, WDT_ON
'@DEVICE PIC16F628, BOD_ON
'@DEVICE PIC16F628, PROTECT_OFF
'@DEVICE PIC16F628, MCLR_ON

DEFINE OSC 4
DEFINE NO_CLRWDT

'* Variable declarations
Header var BYTE
Counter VAR BYTE
Packet VAR BYTE
End_Of_Data VAR BYTE

counterA VAR BYTE
ErrorFlag var bit
MyData var byte
ManchesterWord Var WORD

Temp_Byte var byte[5]
Temp_Word var WORD[5]
x VAR BYTE
send_word VAR WORD

SYNCH VAR byte
SYNCH=$C6


CMCON = 7
VRCON = 0
TRISB.1 = 1

INPUT PORTB.1
PORTB.1 = 1

pause 10
Loop:
Header = 0
HIGH PORTB.6
'SERIN PORTB.1,N300,[SYNCH],Header,Counter,Packet,End_Of_Data
'SERIN PORTB.1,N300,[SYNCH],ManchesterWord.lowbyte,ManchesterWord.highbyte
SERIN PORTB.1,N300,[SYNCH],send_word.lowbyte,send_word.highbyte
Temp_Word[0] = send_word
For x=1 to 4
SERIN PORTB.1,N300,300,Loop,send_word.lowbyte,send_word. highbyte
Temp_Word[x] = send_word
next x

for x=0 to 4
ManchesterWord = Temp_Word[x]
GOSUB DecodeManchester
Temp_Byte[x] = MyData
next x

Low PORTB.6
Header = Temp_Byte[0]
PAUSE 100
if Header = 96 THEN
gosub GLOW_PIN7
if Counter = 2 Then
gosub glow_pass
ENDIF
endif
goto loop

TimeOut:
call GLOW_TIMEOUT
goto loop

GLOW_PASS:
HIGH PORTB.5
PAUSE 50

LOW PORTB.5
PAUSE 50
RETURN

GLOW_PIN7:
HIGH PORTB.7
PAUSE 50

LOW PORTB.7
PAUSE 50
RETURN

GLOW_TIMEOUT:
HIGH PORTB.6
PAUSE 500

LOW PORTB.6
PAUSE 500
RETURN

DecodeManchester:
ErrorFlag=0
For counterA=0 to 7
if ManchesterWord.1=0 then
MyData.7=0
If ManchesterWord.0=0 then ErrorFlag=1
else
MyData.7=1
If ManchesterWord.0=1 then ErrorFlag=1
endif
ManchesterWord=ManchesterWord>>2
if counterA<7 then MyData=MyData>>1
next counterA
return

/**********END OF Receiver*********************/

/**********Start of Transmitter*********************/
'************************************************* ***************
'* Name : Transmitter.BAS *
'* Author : [select VIEW...EDITOR OPTIONS] *
'* Notice : Copyright (c) 2006 [select VIEW...EDITOR OPTIONS] *
'* : All Rights Reserved *
'* Date : 5/2/2006 *
'* Version : 1.0 *
'* Notes : *
'* : *
'************************************************* ***************

INCLUDE "modedefs.bas"

DEFINE OSC 4
DEFINE NO_CLRWDT


CMCON = 7
VRCON = 0
TRISB.2 = 0

Header VAR BYTE
End_Of_Data con 24
SYNCH VAR byte
SYNCH=$C6

'* Variable declarations
Counter VAR BYTE
Packet VAR BYTE

counterA VAR BYTE
MyData var byte
Temp_Byte var byte[5]
Temp_Word var WORD[5]

ManchesterWord Var WORD
x VAR BYTE
send_word VAR WORD

Header = 96


pause 10
OUTPUT PORTB.2
PORTB.2 = 0
OUTPUT PORTB.4
PORTB.4 = 0
OUTPUT PORTB.5
PORTB.5 = 0

Counter = 2
Packet = 78


Temp_Byte[0] = 96
Temp_Byte[1] = 16
Temp_Byte[2] = 26
Temp_Byte[3] = 36
Temp_Byte[4] = 46

start:
pause 1000
MyData = Header
for x=0 to 4
MyData = Temp_Byte[x]
gosub EncodeManchester
Temp_Word[x] = ManchesterWord
nEXT X
'SEROUT PORTB.2,N300,[126, SYNCH,Header, Counter, Packet, End_Of_Data]
'SEROUT PORTB.2,N300,[126, SYNCH,ManchesterWord.lowbyte, ManchesterWord.highbyte]
SEROUT PORTB.2,N300,[1263, SYNCH]
for x=0 to 4
send_word = Temp_Word[x]
PAUSE 1
SEROUT PORTB.2,N300,[send_word.lowbyte, send_word.highbyte]
next x
CALL GLOW_LED
goto Start

GLOW_LED:
HIGH PORTB.5
PAUSE 50

LOW PORTB.5
PAUSE 50
RETURN

EncodeManchester:
ManchesterWord = 0
for counterA=0 to 7
if MyData.0 = 0 then
ManchesterWord.14=1
else
ManchesterWord.15=1
endif

if CounterA<7 then ManchesterWord = ManchesterWord>>2
MyData=MyData>>1
Next CounterA
return

/************END OF TX****************/

[Christopher4187]

I'm not one of the most experienced people on this forum but I have made successful links with PIC's without wires. Can you tell us what you are using in the way of hardware? If your code works with wires, your code should work without wires. Have you ever done a wireless link with PIC's before?

Chris

[Christopher4187]

I forgot to mention, it is possible that your software may have an issue with timing. When I use a wireless link, I typically give a little more time for the transmit and receive signals....maybe an extra 10 to 20ms.

[mankan]

Chris,

Thank you very much for the reply. This is my first project with the PIC. Is there any other issue apart from time-to-transmit?

Do you see anything wrong with my code? It worked fine with the wires.I have even grounded the Rx DataIn pin to overcome the noise.

I am using laipac 434 series of Tx/Rx.

Thanks,
Mankan

[Christopher4187]

I have never used those but I have used Linx Technologies LR series modules. I found that without a 10K pullup resistor (to +5V) on the RX side, they would not work at all. The TX side did not need anything. Are you making only a transmitter and receiver or are you making two transceivers. Don't forget that you cannot have to transmitters transmitting at the same time. With the Linx modules, if you don't pull down the PDN line, the transmit port will always be open making it impossible to send data. Of course, if only using one TX and one RX, this is not a problem. The other thing you may look at is interference in the surrounding area. Let me know if you still have problems.

[dhouston]

The Laipac modules (also widely available under other names) use ASK and the suprerregenerative receiver has AGC/ATC so the output line will have continuous noise in the absence of a signal. I would not try to use serial in and out but would use some type of preamble that will serve to tell the receiver that a message is coming and also allow it to set its AGC/ATC. I use the NEC IR protocol and have never had much of a problem sending/receiving. However, it may or may not be the best choice depending on the type of data you need to transmit. The length of messages casn be a determining factor.

I don't recall what Bruce Reynolds uses in his examples but he does have some examples using these modules on his web site.

[mankan]

I am doing RF Tx/Rx not an IR. Is there anything special to be taken care of something?

Thanks,
Mankan

[dhouston]

It doesn't matter whether it's IR or RF. A protocol is a protocol and the priciples are the same. The only difference is that on the receiving end most IR receivers are active low while RF receivers are active high. X-10 has used the NEC IR protocol for their RF remotes for about 20 years, now.

But, even if you want to use manchester coding, you will still need a preamble to alert the receiver.

There is one other key difference with IR. IR receivers do not output continuous noise in the absence of a signal, so a preamble is not always necessary. Nevertheless, most protocols still use one.

[mankan]

Hello Chris,

I followed your suggestion and I added a pull-up resistor but nothing improved. Any other suggestions.

I am planning to look at the txmitted code pattern.

-Mankan

[Christopher4187]

If you can't find someone who has used these modules or get tech support, there is an easier option. Linx Technologies has a transmitter and receiver pair that can cost as low as about $16 (depending upon quantites and where you get them) in the SMT version. Bruce at Rentron.com sells the pinned versions and while I have never used them before, I'm sure they work fine. I have made many different designs with these modules and Linx claims 3000+ feet but I have never seen that but it's probably due to my inefficient layout of the PCB. If your power supply is clean and the correct voltage, you don't need any external components except for the 10K pullup on the receive line. The data in is the data out. If you need a short range, something like 500 feet, you can use the HETH antenna for your frequency which sells for .67 cents. They are easy to use and relatively cheap. One thing I need to mention, if you don't purchase an evaluation kit, they won't give you tech support. However, if you do want one, I have one here that I will sell for a cheap price. No worries though, if you don't want to purchase one, I will still help you if you need it.

[mankan]

Hello,

Is the other way to test a RF link? Like using PulsIn and wait for the RF pulse on a particular pin.

Just to make sure that link works.

Thanks,
Mankan

[Squibcakes]

Gidday mate,

You can make this work! Say it out loud 10 times OK!

When the TX is not sending data the RX will be picking up noise, the PIC will see this noise as data, so you need to do a few things.

1. Encode the data (which you have already done) and decode at RX.
2. Add a preamble before you send your data strings,

eg send about 10 bytes of data (eg "RFDATAREADY") and on your receiver have it waiting for the text "READY"

Then start sending your data.

I found that it was useful to use an oscilliscope so you could see the data at TX and RX chips, and see the noise when your not transmitting.

Good luck
J

[dhouston]

I've used the TWSxxx and RWSxxx (where xxx=MHz) extensively over the past 7-8 years. I have attached a couple of GIFs (captured at the receiver output) that illustrate the problem you have to deal with.

One GIF is of a marginally weak signal. The upper trace is the LINEAR output pin while the lower trace is the DIGITAL output pin. This happens to be an X-10 RF signal (which uses the NEC IR protocol). You would need to wait in a loop until you receive a valid preamble (e.g. using PulsIn) and then capture the next 32 bits.

The other GIF shows another approach with a preamble that is repeated a few times prior to the actual code. It takes 2-3 copies of the preamble to set the receiver AGC to a point where the preamble emerges from the noise. You would need to wait in a loop for the preamble and then capture the code which follows.

As I recall, Holtek merely repeats the entire code several times with the first copies used to set the AGC so you would have to listen all the time for a valid code.

One more tip: If you do not have access to a 'scope you can record these signals using LineIn of a soundcard. You just need a couple of resistors to form a voltage divider so that the voltage input to the card is in the 0-1V range. This has the added advantage that you can hear the codes, as well. The GIF with the single trace was recorded this way.

[mankan]

Hello,

I am making a Tx port pin High/Low for some duration of time and then on the receiver side, I am just using PULSIN to check the pulse.

I found that transmission and reception is very fine and this brings to the opinion that SERIN command has some problem.

Am I correct? Is there any other way of implementing SERIN for sending RF data?

Thanks for you support.
Mankan

[dhouston]

mankan,

Here is a tutorial that shows how to do manchester RS232 RF with a PIC using ASM. Note that he uses what he calls a header (equivalent to what I've been calling a preamble) to alert the receiver, set the AGC, etc.
http://www.winpicprog.co.uk/pic_tutorial12.htmThe problem you will have on the receiving end is the same - you'll have to monitor full-time for the preamble/header to detect the beginning of a message.

How much data do you need to transmit?

[mankan]

Hello,

I have to transmit only following command pattern:

Header - 1 byte
Command - 2 byte + 2 byte
End of Packet - 1 byte

Hope this should not be a problem for RF transmission.

Thanks,
Mankan

[dhouston]

Panasonic uses a 48-bit protocol that is very similar to the NEC IR protocol. You could adapt the NEC protocol to your needs.

If your header and end-of-packet bytes serve no other purpose you can drop them, using those that are built-in to the NEC protocol. Here's a URL to documentation for the NEC protocol.http://www.cpcares.com/pdf/UPD6121G-001.PDFIt uses a 9.5mS pulse followed by a 4.5mS space as the preamble or Start-of-Packet and a 0.5mS pulse followed by a 40mS space as End-of-Packet. I use a 0.5mS pulse followed by 1.5mS space as digital 1 and 0.5mS pulse followed by a 0.5mS space as digital 0. I would send your 4 data bytes plus one checksum byte for error detection.

Experiment to find whether you can send just one copy or need to send multiple copies to guarantee clear reception.