RX / TX duo

[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/pa...15-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_SUM]
    
    ' / **** 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.