RX / TX duo

[mbw123]

I am fairly new to PIC's so I would love if I got some help to see if this code would work. I am making a remote control car and I have a receiver and transmitter that both use the 16f84. The four pushbuttons on the transmitter control two motors that are connected to an H-Bridge (on the receiving end) which in turn control both directions for the motors. Can someone tell me if this code is valid for the schematics? Thanks a million...

Both schematics are attached and the code is below...

Transmitter Code

------------------------------------------

INCLUDE "modedefs.bas"

output PORTB.4

start:
'Check if buttons are pressed
if (PORTB.0 = 1) then one
if (PORTB.1 = 1) then two
if (PORTB.2 = 1) then three
if (PORTB.3 = 1) then four

goto start

one:
serout PORTB.4,N2400,["1"]
goto start

two:
serout PORTB.4,N2400,["2"]
goto start

three:
Serout PORTB.4,N2400,["3"]
goto start

four:
serout PORTB.4,N2400,["4"]
goto start

Receiver Code

----------------------

INCLUDE "modedefs.bas"

output PORTA.0
output PORTA.1
output PORTA.2
output PORTA.3

start:

in VAR BYTE

serin PORTB.1,N2400,in
'PORTA.0 receives signal at 2400 baud rate and places
'input at variable in

'Testing serial input
if in == "1" then one

if in == "2" then two

if in == "3" then three

if in == "4" then four

goto start

'Turn on PORTA.x for 100 milliseconds and then turn off (motors)
one:
high PORTA.2
PAUSE 100
low PORTA.2
goto start

two:
high PORTA.3
PAUSE 100
low PORTA.3
goto start

three:
high PORTA.1
PAUSE 100
low PORTA.1
goto start

four:
high PORTA.0
PAUSE 100
low PORTA.0
goto start

--------------------------------
Thanks again!!!

-Mike

[skimask]

First off, your serial input/output code won't work as it's set up. I use that particular pair of transmitter/receivers a lot, I know a bit about them. All you'll get at the output is a bunch of noise.

Do a search on "manchester encoding" for use with this type of Tx/Rx pair.

Basically what has to happen is this:

You have to 'train' the receiver to 'know' what the difference between a '1' and a '0' is.
You do this by sending a 'preamble' of 0's and 1's, a few milliseconds of each. This charges up a capacitor to 1/2 the voltage needed to detect if the input is actually a '1' or a '0'. This is actually what's called a 'data slicer'.

After the preamble is sent, you can start sending data.

The problem is, if the data you send has too many '1's or '0's, the capacitor in the 'data slicer' will either charge up all the way to the '1' trip-point or the '0' trip-point and pretty soon all your data is either '1's or '0's.

The trick is to try and send an equal number of '1's and '0's. The closer you are to an equal number of each, the better the quality of the data sent.

So, what you do is, you break apart your input byte into individual '1's and '0's, a binary '0' becomes a '01' and a binary '1' becomes a '10'. This has a side effect of doubling the amount of data you have to send, no biggie. If you only need 4 codes (actually this single byte method works up to 16 individual codes), you can just use a look up table.

For instance:
To send a binary 0000, send 01010101, ($55)
To send a binary 1010, send 10011001, ($99)

Relatively easily done. You can do it in a loop, parsing every bit out at both the Tx and Rx end, or just use bytes that have an equal number of '1's and '0's, but no more than 2 '1's or '0's in a row.
0 = 0000 = 0101 0101
1 = 0001 = 0101 0110
2 = 0010 = 0101 1001
3 = 0011 = 0101 1010
4 = 0100 = 0110 0101
5 = 0101 = 0110 0110
6 = 0110 = 0110 1001
7 = 0111 = 0110 1010
...and so on...

BTW = a good preamble sequence is a bunch of $55 and $AA back to back for about 5ms with the TWS-434/RWS-434 pair.

Have fun...break something...or make it work...
JDG

[Christopher4187]

I don't have any experience with these modules but I do have two questions about them regarding something I read a while ago:

1. Is it true that you don't need an FCC certification to use these?

2. What is the typical range for the pair?

Thanks,

Chris

[skimask]

You don't need an FCC certification in the U.S. as far as I know. If it's a commercial device to be sold in bulk, then you probably will, I'm not sure. I've got 10 different 'things' I've built running around the house/yard/garage, I don't have any certifications, then again, I live out in the sticks.

Range...
Well, it varies wildly. The best I've gotten is about 1/4 mile on 12v on the Tx at about 9600 baud (4800 if you use manchester encoding), big tuned antenna at both ends, etc. Generally, I can easily get about 100-200 feet on 5v on the Tx, 12-15 wire antennas at both ends at 2400 baud.

JDG

[Christopher4187]

FCC certification doesn't matter whether you live in the "sticks" or in a big city. I have many RF devices around my house also but they are not certified because I am not selling them. However, I have made one device that needed FCC certification because I am selling it.

I use the Linx LR series chips and they work very well. No need for Manchester encoding and they are pretty cheap. I'm not sure how much the TWS is but you can get a pair of Linx chips for about $15 depending on where you get them. They have pretty good range (100-3000 feet) depending upon the antenna and board design, and have very little noise. Furthermore, if you want to send a decimal 1, then you send a decimal 1....no need for 10101010.

My reason for asking the questions was money. There are many devices (quantites of 1 or 2) that I want to make for customers but I can't legally sell them because they need FCC certification. It's simply not worth it to go for a certification on a product that costs $100 to build but $5000 to certify and never sell it again. If the FCC certification is in fact not required, it would be very advantageous for me to use them.

I was told they work on AM frequency and this is why it does not need FCC certification. If anyone knows if this is true, please let me know.

Thanks,

Chris

[skimask]

Certification - I know it doesn't matter where I live, but it doesn't hurt when what somebody doesn't know doesn't hurt them....:)

The TWS/RWS-434 pair work in the 432Mhz band, On/Off keying (A.S.K.???). Still I don't think it matters. If you sell them as a commercial product, I think they have to be certified.

Now if you sell them as a hobby/experimental type deal, that's a different story.

Range on the TWS, I suppose I could get longer if I put more effort into the antenna efficiency at both ends. But like I said, the ranges stated above were with simple wire whip antennas, not even the stuff kind, just a chunk of wire hanging out in the wind.

JDG

[mbw123]

My idea was based on this link here: http://www.rentron.com/ruf-bot.htm

His code and schematics are all on his site. He didn't use manchester encoding but it still worked. Will my slight modifications still work with his design?

Thanks a lot!!

-MW

[mbw123]

My idea was based on this link here: http://www.rentron.com/ruf-bot.htm

His code and schematics are all on his site. He didn't use manchester encoding but it still worked. Will my slight modifications still work with his design?

Thanks a lot!!

-Mike

[skimask]

True he doesn't use manchester encoding and it does work without manchester encoding. But what the project is doing is so very simple and error tolerant, it doesn't need error correction and just ignores errors.
I'm only saying that you'd be doing yourself a big favor by learning what manchester encoding is and why it works the way it does, and then apply those principles to your project, even if it is something as simple as turning a light on and off...or whatever.
I can guarantee you that it will come in handy in the future if/when you actually try to send data packets back and forth and need reliability. You know how it is, projects get more and more complicated!
JDG

[Bruce]

If you design a product that includes a non certified RF transmitter, and
sell it, then it needs certification prior to the sale. If you sell an RF
receiver with it, the receiver will need a declaration of conformity.

If your product is Part 15 compliant, that just means the end-user won't
need a license to operate it. Assuming they don't make any modifications
prior to use.

Download this: http://www.fcc.gov/oet/info/rules/part15/part15-2-16-06.pdf

Section 15.1 explains what Part 15 is about.

For hobby projects read section 15.23 on Home-built devices

It doesn't matter which RF modules you use. The TWS/RWS, Linx modules
or any others that are not pre-certified. It will require certification first if you
sell the finished product using them. It doesn't matter if you sell just 1 or
ten million. Your transmitter still needs to be certified, and you'll need a
declaration of conformity on the receiver.

You can build the end product with "pre certified" modules, and antennas so
you don't need to have it certified again. But you need to have proper labels
fixed on the finished product.

For example, if your using a Maxstream 9XSTREAM pre-certified module in your
product;

(quote from 9XSTREAM documentation)


The 9XSTREAM module has been certified by the FCC for integration into OEM
products without any further certification (as per FCC section 2.1091.)

Changes or modifications not expressly approved by MaxStream could void
the user’s authority to operate the equipment.

In order to fulfill the certification requirements, however, the OEM must
comply with FCC regulations:

1. The system integrator must ensure that the external label provided with
this device is placed on the outside of the final product.

2. The 9XStream may be used only with Approved Antennas that have been
tested with this module.
Note that you may still need a 2nd certification if you use a microcontroller
in the design. When in doubt, send it to a pre-screening lab like Linx. It's
worth every penny you spend on making sure whatever you crank out there
is going to have the okee-doke from the FCC.

As for range with the TWS-434A/RWS-434 combination, you can normally
expect between 300-500' depending on your finished circuit design or board
layout.

Linx LC series, 300' max normally. Linx LR series, up to 3000' line of sight.

Range with most any RF modules is going to be determined by your finished
design, antenna choice, operating environment, and a ton of other factors.

For simple stuff like remote control on/off type applications, you normally
don't need to mess with manchester encoding/decoding, but you do need to
work out some method of synchronizing the transmitter/receiver, and
validating all data when it's received.

I can't share code we make money with, but I'll share a small part of what I
use on simple encoding/decoding type apps with PIC's & inexpensive RF
modules like the TWS/RWS, and Linx modules.

Transmitter:


PreAmble CON $A5 ' 10100101 preamble
Synch CON "~" ' 01111110 synch byte

SEROUT2 E_OUT,BAUD,[PreAmble,Synch,Address,DAT_OUT,Address,DAT_OUT,CHK _SUM]

The PreAmble helps DC balance the data slicer (fancy word for a comparator).
The synch byte is locked onto by the serin routine indicating the start of the
address/data payload.

I mixup my address and data bytes, and send them both twice in the same
data stream. Address,DAT_OUT,Address,DAT_OUT which makes it very hard
for noise on the receiver end to duplicate my actual payload like this.

CHK_SUM is just a single byte. It contains Address + DAT_OUT where all 4
bytes are simply added together prior to sending a packet.

It doesn't matter that CHK_SUM overflows when adding them together. It's
just another simple data validation byte to make sure I get a match when
duplicate bytes of address & data are added together again on the receiving
end.

Partial receiver code:


' Wait for Synch byte, then get new inbound address and data
SERIN2 D_IN,BAUD,[WAIT(Synch),ADD_IN1,DAT_IN1,ADD_IN2,DAT_IN2,CHK_SU M]

' / **** Begin data validation **** /

' Calculate checksum by adding all 4 address and data bytes together
CheckSum = (ADD_IN1 + ADD_IN2)
CheckSum = CheckSum + (DAT_IN1 + DAT_IN2)

' Test new checksum against one received in CHK_SUM
IF CheckSum != CHK_SUM THEN MAIN

' Test address & data bytes for match
IF (DAT_IN1) != (DAT_IN2) THEN MAIN
IF (ADD_IN1) != (ADD_IN2) THEN MAIN

' Test received address against hardware address
IF ADD_IN1 != ADDRESS THEN MAIN

' Do something with the data received here
This is really simple stuff, but still very effective. It's easy to synch up both
ends of the link. Even with really noisy receivers like the Linx LR series or
RWS-434.

The Ruff-Bot project works because it continuously sends the same data. It
will definitely miss a great deal of packets, but with this particular project, it
really is a moot point. It's also sending data at 9600 bps which is well above
the TWS/RWS max data rate is, but it still gets enough packets through to
do the job it was intended to do.

[mbw123]

Thanks for the responses guys. I think I will redo the code with the manchester encoding so I can make my projects much more complicated. I was wondering if I could still stick with the same schematic, though. And also, do you have any sample code to accomplish the manchester? Thanks!

-Mike

[mbw123]

Sorry Bruce, my browser freaked out for a second and I didn't scroll down to see the rest of your post. Thanks for the help!!

-Mike

[skimask]

Nothing wrong with your schematic. Same basic design I use. As far as manchester code...roll your own. You wouldn't like what I'm using, kludged up, works for me, but it's ugly.
JDG

[Bruce]

I rarely use manchester, but here's a simple version you can run with a
terminal program to see how it works. You can easily change it to work
with serial comms between two PIC via RF.

You still want to include a preamble & synch byte before each packet.

The assembler routine is a slightly modified version of one done by Les
Johnson a long time ago, and it's very fast.

This version is for an 18F. Just make the rotate instruction change as shown
to use it on a 12F or 16F part. You'll want to change banka to bank0 also.


; Compile with MPASMWIN
X VAR BYTE
Y VAR BYTE
BitCount VAR BYTE banka system ' Bank0 system so we don't need an underscore
ByteIn VAR BYTE banka system ' to access BASIC variables from assembler
ByteOut VAR BYTE banka system
Manch VAR WORD banka system ' Holds manchester encoded word
Temp VAR WORD banka system ' Temp var
CRC VAR BYTE system
Enc_Dat VAR WORD[6] ' Holds 6 manchester encoded words

GOTO Main ' Jump over encode/decode routines

ASM ; Note: For 14-bit core just change Rlcf to Rlf
; Manchester encode routine
_Encode
Movlw 8
Movwf BitCount
E_Repeat
Rlcf ByteIn,F
Btfss STATUS,C
Goto BitClr
BitSet
Rlcf Manch,F
Rlcf Manch+1,F
bcf STATUS,C
Rlcf Manch,F
Rlcf Manch+1,F
Goto E_Loop
BitClr
Rlcf Manch,F
Rlcf Manch+1,F
bsf STATUS,C
Rlcf Manch,F
Rlcf Manch+1,F
E_Loop
Decfsz BitCount,F
Goto E_Repeat
Return
ENDASM

ASM
; Manchester decode routine.
_Decode
Movf Manch+1,W
Movwf Temp+1
Movf Manch,W
Movwf Temp
Movlw 8
Movwf BitCount
Repeat
Rlcf Temp,F
Rlcf Temp+1,F
Rlcf ByteOut,F
Rlcf Temp,F
Rlcf Temp+1,F
Decfsz BitCount,F
Goto Repeat
Return
ENDASM

Main:
' Manchester encode ASCII characters "A" to "F"
Y = 0 ' Start array index pointer at 0
FOR X = "A" to "F"
ByteIn = X
CALL Encode
Enc_Dat[Y] = Manch
HSEROUT ["Encoded ",X," = ",IBIN8 X," = ",IBIN16 Enc_Dat[Y],13,10]
Y = Y + 1 ' Increment array index pointer
NEXT X

' Decode & print results
FOR Y = 0 to 5
Manch = Enc_Dat[Y]
CALL Decode
HSEROUT ["Decoded ",IBIN16 Manch," = ",ByteOut,13,10]
NEXT Y
PAUSE 10000
GOTO Main

END
Here's the output;

Encoded A = %01000001 = %0110010101010110
Encoded B = %01000010 = %0110010101011001
Encoded C = %01000011 = %0110010101011010
Encoded D = %01000100 = %0110010101100101
Encoded E = %01000101 = %0110010101100110
Encoded F = %01000110 = %0110010101101001
Decoded %0110010101010110 = A
Decoded %0110010101011001 = B
Decoded %0110010101011010 = C
Decoded %0110010101100101 = D
Decoded %0110010101100110 = E
Decoded %0110010101101001 = F

Manchester does have its advantages, but I rarely use it. A big factor is
getting the receiver/transmitter in synch.

Like in my previous post, I would definitely use a preamble followed by a
synch character. That really makes a big difference.

[skimask]

I was doing some reading awhile back on these various modules using On/Off keying, FSK/ASK, whatever. I can see the modules working fine when only sending small data packets that only end up lasting a few milliseconds (with a good preamble of course). But, from what I've read, it seems that the data slicer will lose it's mind after that especially if the data has a lot of repeating 0's or 1's.
Correct or wrong?
JDG

[Bruce]

Long periods of 0's will cause problems.

Short bursts of information like preamble,synch,address,data,checksum etc
work just fine. The payload is delivered just after everything is stable and in
synch. Even a few bytes of data with large numbers of 0's works, but you
wouldn't want to stuff 50 words in there made up of all 0's.

If you're transmitting long streams of serial data that can vary from all 0's
to all 1's, then you might want to look into using manchester.

Here's one example of how a simple remote control encoder works.
http://www.linxtechnologies.com/documents/encdecdatastruct.pdf

[mbw123]

Bruce,
I didn't read your first post carefully enough. In your receiver code you had the SERIN line say:

SERIN2 D_IN,BAUD,[WAIT(Synch),ADD_IN1,DAT_IN1,ADD_IN2...]

What does the WAIT(Synch) line do?

I appreciate your answering, as this is probably a stupid question.

Thanks!!

-Mike

[Bruce]

It WAITs for the Synch byte. Look in your PBP manual under SERIN2 for the
WAIT modifier. This forces the SERIN2 line to wait until this specific byte
arrives before receiving the rest of the serial packet.

[mbw123]

Sorry about the late post, and thanks for the help guys! Now I am thinking about the possibility of using the PIC16F628A instead of the 16f84. Will I be able to use the same code and schematics (I think that the PIC16F628A has an internal oscillator; will that mean I can eliminate the external oscillator?)? Thanks for the help!!

-Mike

[mister_e]

you can use the same schematic and probably the same code. But look at the the 16F628 Specs... it have an internal USART. More reliable than a software solution and produce a tighter code. HSERIN, HSEROUT that's it.

About skipping the external OSC... it could work good or not. Usually for serial comm i prefer to use a crystal for a better stability upon the temperature variation. The internal OSC is still a RC circuit... But try it before at slow baudrate and it could work great.