Serout problem

I just started to play with wireless transmision. I used this kit that
I ordered:
http://www.rentron.com/remote_contro...-bit-combo.htm

I do get a signal at the receiver but I do not know how to interpret
it or how to fix it. The signal is clear but not the same as the one I
sent. I posted a picture of both signal
http://www3.sympatico.ca/lerameur/

can somebody tell me why the receiving signal is not identical?
it seems the receiving signal cannot stay on more then 125ms

I tried transfering at 2400bps,4800 and 9600, putting a single data in a cycle or a few. I get the same results..
I am using this to generate my signal:
serout2 portb.3,n9600, [2,4,6]

thanks

Ken

Do a search on manchester encoding and use it.
The transmitter/receiver use a sort of zero-crossing detector (at least I think that's what it's called). You can't just put serial into the transmitter and expect to get the same signal out.
Basically, you convert all of your 0's into '01' and all of your 1's into '10', both at the transmitter end and the receiver end.
Example:
You want to send a $73 (hex 73):
$73 = % 0111 0011
manchester encoded becomes: 01 10 10 10 01 01 10 10

decoded at the other end in reverse:
receive:
01 10 10 10 = $6A
01 01 10 10 = $5a
convert:
01 = 0, 10 = 1, 10 = 1, 10 = 1; -> 0111 = $7 (upper half)
01 = 0, 01 = 0, 10 = 1, 10 = 1; -> 0011 = $3 (lower half)

put it back together to get $73.

Yes, you do 'waste' half the bandwidth (ie. transmitting at 2400 baud only gives you 1200 effective baud).
But you also have to 'train' the receiver to be able to recognize the halfway point between 0 and 1. You do this by sending about 5 ms (maybe more, maybe less) worth of $55 or $aa, whichever, it ends up the same in the end.

Then you can start sending your data.

I've got those same modules from Rentron. They work great, even in a sloppy solderless breadboard environment. I routinely can get a couple hundred feet of range from them at 9600baud (even though they aren't rated for that speed).

Also, for a software idea for you, I split the bytes in half and used a 'look up' table to encode the sending data. To receive the data, I used the same 'look up' table to decode the data and then reassembled the bytes as required.

A bit inefficient, but it's quick and simple and it works for me...
JDG

I choose a kit that came with an encode and a decoder. If I use them, will it be like utilizing a manchester coding type of technique ? I thought I would start with the basic and then add the encoder. i guess I should start puting in the encoders right a way

k

Some code I dug up from one of my earlier projects that used the modules from Rentron. They aren't complete, the meat of what the code actually does has been removed, but it might give you a decent starting point to work with...

Transmitter code....


'use TWS/RWS modules, portb.2 pwr to xmtr, portb.1 xmtr data in, slave controller PCB for data

@ DEVICE PIC16F628A , INTRC_OSC , WDT_ON , PWRT_OFF , MCLR_OFF , BOD_ON , LVP_OFF , PROTECT_OFF

'Int 4Mhz Osc, WDT off, PWR up timer off, mclr ext, brown out detect on, low volt prog off , code protect off

resetplaceholder: 'arial black, size 8, reg, 16f628A code

INCLUDE "modedefs.bas"

DEFINE OSC 4 'using internal 4mhz, switch down to 37khz when in low power mode, eventually

DISABLE

CLEAR

selectkey var portb.5 : rightkey var portb.6 : leftkey var portb.7 : upkey var portb.0 : downkey var portb.3
input selectkey : input rightkey : input leftkey : input upkey : input downkey : dataout var portb.1 : output dataout
dataout = 0 : xmtrpwr var portb.2 : output xmtrpwr : xmtrpwr = 0 : key var byte : option_reg = 8 : cmcon = 7

'option = pullups enabled, ints disabled, prescaler to WDT, all comparators off

mainloop: key = 0
if ( selectkey = 1 ) and ( upkey = 1 ) and ( downkey = 1 ) and ( leftkey = 1 ) and ( rightkey = 1 ) then
xmtrpwr = 0 : pcon.3 = 0 : nap 2
'power down for a bit, slow clock to 37khz before going into nap

else 'send manchester encoded numbers 0-4, 0=01, 1=10, therfore '1010' = '10 01 10 01'

if xmtrpwr = 0 then
pcon.3 = 1 : xmtrpwr = 1 : pause 5 : key = $55 : serout2 dataout , 84 , [ REP key \ 24 ]
endif
if upkey = 0 then key = $66 '5= 01 10 01 10
if downkey = 0 then key = $56 '1= 01 01 01 10
if leftkey = 0 then key = $6a '6= 01 10 10 01
if rightkey = 0 then key = $5a '3= 01 01 10 10
if selectkey = 0 then key = $65 '4= 01 10 01 01

serout2 dataout , 84 , [ REP key \ 2 ] 'serout2 mode 188 = 4800 baud, 84 @ 9600, 8N1 formatting

endif
goto mainloop
END










Receiver code....
@ DEVICE PIC16F628A , HS_OSC , WDT_OFF , PWRT_ON , MCLR_ON , BOD_ON , LVP_OFF , PROTECT_OFF
'HS 20mhz, watchdog off, powerup timer on, mclr external, brown out detect on, low volt program off , code protect off

resetplaceholder: 'wordpad, arial black, size 8, reg, 1600x1200 screen, 16f628A code

DEFINE OSC 20 '20mhz
DEFINE NO_CLRWDT 1 'don't clear the watchdog timer, I'm not using it anyways
DISABLE 'disable software interrupt checks
CLEAR 'clear out the ram and do a software 'reset'

upkey var portb.0 : downkey var portb.3 : rxpwr var portb.4 : selectkey var portb.5 : rightkey var portb.6
leftkey var portb.7 : redled var porta.0 : greenled var porta.1 : blueled var porta.2 : chx var porta

serdata var byte : serbuf1 var byte : serbuf2 var byte : serialselecthold var byte
gooddatacount var byte : baddatacount var byte

startupholder: goto skipsubs 'skip over all the commonly used subroutines

ON INTERRUPT GOTO INTHANDLER
DISABLE INTERRUPT
INTHANDLER: if pir1.5 = 1 then 'if serial data rx'd
pir1.5 = 0 'reset the RX flag
if ( rcsta.1 = 1 ) or ( rcsta.2 = 1 ) then 'check for err, if frame/overrun error,
rcsta.4 = 0 : rcsta.4 = 1 : serdata = rcreg : serdata = 0 'reset CREN, clear last data rx'd
gooddatacount = 0 : if baddatacount < 255 then baddatacount = baddatacount + 1
else
serdata = rcreg : serbuf2 = serbuf1 : serbuf1 = serdata
baddatacount = 0 : if gooddatacount < 255 then gooddatacount = gooddatacount + 1
endif
endif

if nokeypress <> 0 then nokeypress = nokeypress - 1 'if a key has been hit lately, this counter serves as
'a debounce/delay keeping another key hit from being
'detected later

intfinish: RESUME

clearserbuf: serialselecthold = 0 : serdata = 0 : serbuf2 = 0 : serbuf1 = 0 : return 'clear serial buffer

increasecolor: color = color + 1 : if color = 8 then color = 1 'used in a few routines for stepping the colors
return

ENABLE INTERRUPT

DISABLE INTERRUPT 'pie1=$20 enables ser-port int., spbrg= 129@2400, 255@1200baud, 64@4800baud, 33@9600baud

skipsubs: option_reg = 8 : pie1 = $20 : trisa = 0 : porta = 0 : trisb = $ef : portb = $10 : t1con = 0 : t2con = 0
cmcon = 7 : ccp1con = 0 : vrcon = 0 : txsta = 0 : rcsta = $90 : pir1.5 = 0 : spbrg = 33 : mode = 0
lastmode = 0 : intcon = $e0 : modeset = 1

mainloop: if ( selectkey = 1 ) then
if ( upkey = 1 ) then
if ( downkey = 1 ) then
if ( leftkey = 1 ) then
if ( rightkey = 1 ) then goto mainmodeloop 'if no keys pressed, don't check
endif
endif
endif
endif

if nokeypress > 1 then goto mainmodeloop 'if a certain key was pressed lately,
' don't check for any new keys

if nokeypress < 10 then
if serbuf2 = serbuf1 then
select case serbuf1 'manchester encoded numbers 1-5
case $66
gosub clearserbuf : goto serialupkey
case $56
gosub clearserbuf : goto serialdownkey
case $6a
gosub clearserbuf : goto serialleftkey
case $5a
gosub clearserbuf : goto serialrightkey
case $65
if serialselecthold > 10 then
gosub clearserbuf : goto serialselectkey
else
serialselecthold = serialselecthold + 1
endif
end select
endif
endif
ENABLE INTERRUPT
goto mainloop 'do it all over again
END

Quote:

---

Originally Posted by lerameur

I choose a kit that came with an encode and a decoder. If I use them, will it be like utilizing a manchester coding type of technique ? I thought I would start with the basic and then add the encoder. i guess I should start puting in the encoders right a way

k

---

The encoder and decoder modules do almost exactly that. The difference is generally in the outputs. Some decoder modules only turn switches on and off, others toggle, etc.etc., then again, other modules let you put serial in one end, and get serial out the other end.

You can very easily do the same thing with a bit of software.
And yes, generally the encoders would come first until you figure out that you don't need to use up that extra bit of board space with another chip! :)
Good luck...

Ok i understand what you mean by manchester encoding, My qustion is now, should I see the same signal at the output of the chip and at the output of he receiver ? That was the way My scope was hooked up before, and now it is reading a big flat black line at the receiving end with same amplitude. The transmitter is now sending spikes.

ken

The spikes at the output are the result of the incoming signal from the transmitter, going from low to high, basically because you haven't 'trained' the receiver to know where the halfway point is.

(forget about the encoder/decoder module for now)

Try sending a string of continuous $55's at 2400 baud (which ends up being binary 0101010101010101010 etc) to the receiver, then watch the input and the output; Channel A at the serial output of the PIC, Channel B at the digital output of the receiver. They should be identical.

Quite frankly, I don't know how I can easily explain to you how the receiver works without getting you (and myself) confused in the process! But I'll give it a quick try.
There's a data slicer in the receiver that relies on the fact that you don't send a continuous string of zero's or one's. You have to train the receiver by sending it one's and zero's (50% duty cycle) so it can charge up a capacitor in the data slicer to about halfway. When that's done, the receiver can know the difference between a one and a zero (since it knows where the half point is).
If you send it too many 1's in a row, that capacitor charges up too much and the halfway point gets closer and closer to the normal '1' level, eventually making everything look like a zero.
If you send it too many 0's in a row, the same capacitor discharges too much and the halfway point drops too low, making everything look like a one at some point.
Therefore, if you keep alternating one's and zero's (like manchester encoding does), you keep that capacitor in the data slicer section about halfway charged up and it doesn't lose it's mind.

How's that for confusing? Any better?
JDG
P.S. I'm about to turn off for the night, so if you've got more questions, might want to make them quick...

yes I understand the theory much better now, I just tried differnt numbers, like binary 2 in a loop or $A but I get a wider pulse,
When I put A I get 1010 on the receiving end, then 00 1111 added to the information then it starts again, I tryind logenr sequence, and that 001111 is always added at the receiving, I do not have an encoder


k

$A isn't $AA
$A = % 0000 1010 - see the leading zero's?
$AA = % 1010 1010 - no leading zero's...

When you do this, you have to remember the leading and/or trailing one's or zero's in every byte. They'll screw you up just as bad as anything...
JDG

Ok 16 bit .
Its is better but the last bit is a bit wider. I will take a picture and post it for tomorrow.. my batteries are dead. the receiver dont seem to be able to take two 1's in a row. is this normal

thank you
ken

oups 8 bit

Just try sending nothing but $AA and $55, nothing else. Forget about manchester encoding and the encoders for awhile.
At the transmitter end, using the PIC, send out an $AA, then a $55, and repeat....
At the receiver end, put the 'scope on the digital output.
If they don't match up, instead of

transmit:
serout2 portb.3,n9600, [$aa]
goto transmit

try:

transmit:
serout2 portb.3, t9600, [$aa]
goto transmit

Actually, I think that's your problem!!! You're trying to use the inverted RS232 mode instead of the non-inverted mode. Just change the n9600 to t9600 and see what happens. If you look at my code above, I use serout2 with a mode value of 84, which means true logic levels, 9600 baud, 8 bit, no parity, one stop bit.

About the only time you'll really need that inverted mode is when you're hooking up to a PC's serial port without a level translator in the middle like a MAX232.

Let me know what happens...

JDG

Actually I tried the t and the n and they have the same signal.
I posted the signal on my web site
http://www3.sympatico.ca/lerameur/
you can see the black speck at the end of the signal $AA

ken

Ok, so the signal is a bit messy. Have you tried to see if the firmware in the PIC will actually recognize it as a character? Something like turn on an LED with an $aa recevied, turn it off with a $55 received, or something simple.

I seem to remember doing some probing myself way back when (albeit with a Tek 2246A, nothing near as nice as yours!)...and it seems to me the output was a bit sloppy there too, but it worked just fine.
Also, the other issue might be the fact that you're running at 9600. Try slowing to 2400 and see if that cleans it up a bit, if not, try 19200 or higher.

Just curious...are you sure you're actually transmitting at 9600? The 'scope picture says 250ms at the bottom. Are you sure the OSC define is set right? Oscillator is running at the right speed at both ends? It sorta looks to me like your data is coming out about 8-10 times to slow. I could be reading something wrong though...

JDG

Also, are you probing pin 2 or pin 3 on the receiver? It looks like pin 2, since that's the digital output. Does pin 3 look more like a sine wave than square? It should. If pin 3 looks cleaner, use it instead.

And another thing. At 9600 baud, it'll take at least 24 characters of $55 or $aa (your preference) to 'sync up' the receiver before you can start sending data. Could be less, could be more, tolerances... 24 characters of 'preamble' has always seemed to work for me. And wait about 5-10ms after power up to start sending your data.

ok I did some changes this morning,
I changed the sending clock to 20 Mhz. I saw too that the transmission was too slow, how can I control anything with byte thats like a second. Now the bit rate is ok, I like it now, but then at the receiver I get a weired signal , a steady triangular form with lots of rise and fall time.
I added a picture of this and my circuit where i am probing
http://www3.sympatico.ca/lerameur/
My sending ciruit is just a few inches away.
ken

Are pins 6 and 7 grounded on the rx?

Where's your antenna?

And now I think you might be transmitting too fast. Check your OSC settings both in your source code and your fuse settings for the PIC.

The period of the channel 2 signal is 208.4us, which equates to 4798.4bps.

Multiply by 2 since you're using manchester encoding (or trying to), you get 9596 bps, very close to 9600 baud (within .03%).

Trying slowing down to 2400 baud and see what happens. Or if you're already there, try 1200 baud, then 9600, whatever. Try different characters. For instance, a $65 (%0110 0101) would be the manchester encoding pattern for a $4. The alternating bit patterns is the key to making the whole thing work and transmit data for you.

I will home only tonight.
BUt I did gground pin 6 and 7, there is small wire going from one to the other then ground wire from that to the ground. I removed the antennas because I did not see any difference with or without since I am transmiting very close.
I did reduce the speed down to 2400 but same output.
I am tramsitting 10101010 , why is the 4th 1 is doubled.

On another note, I tried this sending code:
http://www.rentron.com/ruf-bot.htm
with same chip in picbasic and I still did not get a good receiving, Although when I tried it, I had a 4Mhz crystal, maybe adding a 20Mhz, BUt his code do not specidy any, so I assumed default. Could my receiver be busted?

ken

The MAX reliable data-rate of the receiver you have is 2400 bps. Everything
you try should be at or below 2400 bps. Over the MAX data-rate is just not
going to produce anything reliable.

Have you tried testing your RF modules with the encoder/decoder ICs you
received with your kit yet? That's what we test them with here before kits
ship.

Before moving any farther, I would definitely recommend you validate your RF
modules by testing them with the encoder/decoder ICs you received.

Once you have verified that everything's working, it's a lot easier to move on
from that point.

Quote:

---

Originally Posted by Bruce

The MAX reliable data-rate of the receiver you have is 2400 bps. Everything
you try should be at or below 2400 bps. Over the MAX data-rate is just not
going to produce anything reliable.

I beg to differ! Those modules rock! Even though they're only rated for 2400 bps, I've been using them at 9600 bps with very good reliability (if I had to guess, over 95%), althought 19.2kbps is more like around 50% but it still works!


Have you tried testing your RF modules with the encoder/decoder ICs you
received with your kit yet? That's what we test them with here before kits
ship.
Before moving any farther, I would definitely recommend you validate your RF
modules by testing them with the encoder/decoder ICs you received.
Once you have verified that everything's working, it's a lot easier to move on
from that point.

---

True, the encoder/decoder modules are handy. I was trying to get him up to that point, but it sounded like he might've had a dead module in the first place. And since he had the 'scope out and was watching it, I figured I might've been able to induce a failure that would duplicate what he might/might not have been doing right or wrong....

Keep at it....we'll get 'er eventually...
JDG

hi,

I only had time to try one thing. I put a simple command with a decimal number and I included the encoder.
check it out:
http://www3.sympatico.ca/lerameur/

It is good, but the transmitter is right beside the receiver, I would expect a better reception, When I wil be putting this 100feet away, I am afraid I wont get a signal.
Also, I would like to get it working without the encoder. I want to understand why the way I was trying do not work.

ken

Quote:

---

Originally Posted by lerameur

hi,

I only had time to try one thing. I put a simple command with a decimal number and I included the encoder.
check it out:
http://www3.sympatico.ca/lerameur/

It is good, but the transmitter is right beside the receiver, I would expect a better reception, When I wil be putting this 100feet away, I am afraid I wont get a signal.
Also, I would like to get it working without the encoder. I want to understand why the way I was trying do not work.

ken

---

I think it should've worked. I get the same type of output with the bit of roughness on the trailing edge of the pulses like you had before. BUT, the firmware in my receiving PIC gets the bytes just fine (remember the serial module in the PIC does a bit of oversampling of the bits, so if the leading or trailing edge is a bit messy, it won't matter much).
You might be too worried about the fact that the TX and RX signals aren't exact 100% matches of each other and not worried enough if the code in the receiving PIC works in the first place.
Have you tried making the Tx-PIC talk to the Rx-PIC without the wireless modules (or the encoder/decoder) in the middle? Does that work? If not, you probably have something wrong with your code.
Also, have you actually tried putting some distance between the modules to see if the receiving signal changes much? It might not...
JDG

I want to try all of this, and will this week end, I just one interesing fact. When I use the pic, I can see that one byte is about 5ms. When I use the pic directly, the byte is 300us. I guess I need to slow it down, that is the case even at slow baud rate:
serout2 portb.3,n1200, [01010101]
I saw a command that actually slow he bit rate between every bit, They added this in the beginning of the program, I just remember reading it, cant remember where, is this possible ?
My whole program is this

Include "modedefs.bas"
DEFINE OSC 20 '20Mhz Oscillator was used
Start:
serout2 portb.3,n1200, [01010101]
GOTO START

I was looking at the HSERIN command..

Quote:

---

Originally Posted by lerameur

I want to try all of this, and will this week end, I just one interesing fact. When I use the pic, I can see that one byte is about 5ms. When I use the pic directly, the byte is 300us. I guess I need to slow it down, that is the case even at slow baud rate:
serout2 portb.3,n1200, [01010101]
I saw a command that actually slow he bit rate between every bit, They added this in the beginning of the program, I just remember reading it, cant remember where, is this possible ?
My whole program is this

Include "modedefs.bas"
DEFINE OSC 20 '20Mhz Oscillator was used
Start:
serout2 portb.3,n1200, [01010101]
GOTO START

---

Shouldn't that be [ %01010101 ] ? With a % sign in front of the binary number? The way you have it, PBP is trying to send an overflowed large number (I think, not sure), but it sure not a $55 like you had intended.

For the DEFINE that slows things down (character pacing), don't use values any higher than 1 or 2 ms if you're NOT using the encoder/decoder modules. If the pacing value is any higher, you have to 'retrain' the receiver by sending another preamble sequence (because the data slicer gets either charged or discharged in that amount of time).

And again, if you're using the encoder/decoder modules, it won't matter.

Ok sorry , it was a typo, I have $AA in my code, I just wanted to make things clearer and made a mistake while posting.

And again, if you're using the encoder/decoder modules, it won't matter.
so you mean I DO need spacing?
Like I said the pulses are much faster coming out the pic then the encoder.
what is the speed you get when sending out on a wireless ?

ken

All right....in explicit detail....write down and/or take/post pictures of what you've got so far; transmitter schematic, receiver schematic, transmitter firmware (PBP), receiver firmware (PBP) and other relavent facts.

And unless I've missed it, all I see is the fact that you are probing your receiver output while you are sending repeat bytes into the transmitter. I don't see anything saying that a PIC is connected to the receiver itself... That is what I've been wanting to know all along. What is the receiving PIC doing about all these signals...not what your 'scope is doing about them...

'cause quite frankly, that PBP software posted earlier by me and the schematics from Rentron should work just fine and like I said, and even though the modules aren't rated for it, I can get them to work at 9,600 baud reliably (19,200 intermittently). And this is all on a solderless plug-in type breadboard, nothing special about the circuit. And it works out to a few hundred feet.

Unless you messed with the tuning adjustment on the receiver (like I did on one of my modules and it took me literally days to get it back into adjustment), then all bets are off...

JDG

just my 2 cents, not on the code but... RF and breadboard are poor friends.. you really want to monitor what goes out of your receiver before using it. You may need to clean the signal before.

Once again, RF and breadboard are poor friends.

I am going to pause and start on it on friday or saturday,
I will come back with a ll the details, I also want to do some more reading before going on further.
I have been told that bread board do create a capacitive effect. But if I am getting something good with the encoders, I guess should be able to get something good also without the encoders.
I just saw a similar kit here:
http://www.robotshop.ca/home/product...ity-tx-rx.html
I might try them out just for fun

ken

Quote:

---

Originally Posted by mister_e

just my 2 cents, not on the code but... RF and breadboard are poor friends.. you really want to monitor what goes out of your receiver before using it. You may need to clean the signal before.

Once again, RF and breadboard are poor friends.

---

True, but I've made some really sloppy stuff with the Rentron RF Tx and Rx modules (sloppy as in electrically sloppy, not to mention the wiring looked like a rats nest), and it's always worked fine, albiet the range suffered because of the way it was put together. And the RF itself is constrained to the modules, it doesn't flow onto the breadboard (well, except for whatever is induced).
I'm almost positive there is something more fundamental, more basic, going on with the way he's setting things up (kinda like the familiar 'not turning off the comparators' thing).
Hopefully, we'll get it ironed out soon...
JDG

ok here the code:

Include "modedefs.bas"
DEFINE OSC 20 '20Mhz Oscillator was used

ADCON0 = 0 'AD MODULE OFF & CONSUMES NO CURRENT
ADCON1=7
CMCON = 7 'COMPARATORS OFF
TRISB = %00000000 'PORTB OUTPUTS

START:
serout portb.2,n2400,[$AA]
Pause 100
GOTO START

When I change the serout to serout2 , its worst. I am not getting a lot out the output pin, I also tried pin9 for output.

I have a outpu 20Mhz crstal on port 15 and 16
MCLR with a resistor to Vdd
Vdd on 14
ground on 5
wire from 8 to input of TX module

ken

Quote:

---

Originally Posted by lerameur

ok here the code:

Include "modedefs.bas"
DEFINE OSC 20 '20Mhz Oscillator was used

ADCON0 = 0 'AD MODULE OFF & CONSUMES NO CURRENT
ADCON1=7
CMCON = 7 'COMPARATORS OFF
TRISB = %00000000 'PORTB OUTPUTS

START:
serout portb.2,n2400,[$AA]
Pause 100
GOTO START

When I change the serout to serout2 , its worst. I am not getting a lot out the output pin, I also tried pin9 for output.

I have a outpu 20Mhz crstal on port 15 and 16
MCLR with a resistor to Vdd
Vdd on 14
ground on 5
wire from 8 to input of TX module

ken

---

I see the problem right away. Remember when I said that the receiver needs to be trained (take a bit of time and read back there somewhere)? Well, you're sending one character, waiting 100ms, then sending another, waiting another 100ms...etc.
That 100ms is WAYYYY too long. Change that pause to less than 5ms, and then look at your datastream at the receiver.

Try this-----


START:
serout portb.2, n2400, [ $aa, $aa, $aa, $aa, $aa ]
Pause 1
serout portb.2, n2400, [ $0F, $F0 ]
Pause 1
GOTO START

The 4 $AA's will take 16.6ms to transmit and probably won't match the transmitter output very well. Do not worry about that, it's ok, that's why we're training the receiver. It's completely normal.

After a few cycles, the $0F and $F0 should be clearly visible and practically match the transmitter output (because we've trained the receiver). The $0F and $F0 will take about 8.3ms to complete, then there will be a 1 ms pause, then the sequence will start over.

You should be able to see an obvious difference between the $AA's and the $0F and $F0.
This should work just fine. Let me know what happens...
JDG

yes its working, Thank You !!!
I just assumed that because I dont have a receiver chip i did not need the training session .
I tried it without just to see and it works, But I will use it.

Also , I did not see any pause in your code
serout2 dataout , 84 , [ REP key \ 2 ] 'serout2
how does yours work ?
also i wandered around on google and did see anyone using a pause that long. Like here, they use 1 sec pause:http://www.imagesco.com/articles/lcd/05.html

Ken

O my !
I just realize there button edit on this site
I was sure you put this pause
PauseUS 1660 '<----notice the change to pauseUS
and I could not see it anymore, then I saw the edit button,
I thought for a while I was in an episode of the twilight zone..
unless you did not edit it....

k

Quote:

---

Originally Posted by lerameur

yes its working, Thank You !!!
I just assumed that because I dont have a receiver chip i did not need the training session .
I tried it without just to see and it works, But I will use it.

Also , I did not see any pause in your code
serout2 dataout , 84 , [ REP key \ 2 ] 'serout2
how does yours work ?
also i wandered around on google and did see anyone using a pause that long. Like here, they use 1 sec pause:http://www.imagesco.com/articles/lcd/05.html

Ken

---

The first pause is just to let the LCD startup, you only need it once. The second one is there for no reason other than to be there and provide a bit of delay so you can see what is going on.
As far as the code goes, what you see is what you get. I don't have anything hidden in there, nothing special is going on...
JDG

I,,
I was looking at your receiving code, and I could not see any serial in command. What are you using instead ?

ken

Anyway here is the code I am using at the receiver:
I will be putting a lcd on the circuit to see how the pic is reading the input.
Beside the test led input at the begining the rest is not functioning, I suppose it has to do with the data coming is in one format and I am treating it in another.

DEFINE OSC 20 '20Mhz Oscillator was used

Include "modedefs.bas" ' Include serial modes

ADCON0 = 0 'AD MODULE OFF & CONSUMES NO CURRENT
ADCON1=7
CMCON = 7 'COMPARATORS OFF
TRISA = 0 'outpu
TRISB = 1 'input

B0 var byte

porta.0 =1 'testing leds output
pause 500
porta.1 =1
pause 500
porta.2 =1
pause 500
porta.3 =1
pause 500

start:
serin PORTB.3,n2400,[B0]
pause 1
if B0 = $aa then led1
if B0 = $aa then led2
if B0 = $5a then led3
if B0 = $5a then led4

goto loop

led1:
porta.0 =1
pause 200
goto start

led2:
porta.1 =1
pause 200
goto start

led3:
porta.2 =1
pause 200
goto start

led4:
porta.3 =1
pause 200
goto start

loop:
porta.0 =1
pause 200

goto start
end

A couple of notes:

TRISA = 0 'outpu <------ might only set porta.0 as an output(?)
use TRISA = %00000000 to make sure

TRISB = 1 'input <------ will only set portb.0 as an input
use TRISB = %11111111 to make sure all
of port B is set to input

start:
serin PORTB.3,n2400,[B0]
pause 1 <------ don't pause here, you want to read the serial
and get done what you want done and get
back to reading the serial port as quick as
possible

if B0 = $aa then led1
if B0 = $aa then led2
if B0 = $5a then led3
if B0 = $5a then led4

goto loop

led1:
porta.0 =1
pause 200 <----------- take out all these pause 200 lines
goto start

led2:
porta.1 =1
goto start

led3:
porta.2 =1
goto start

led4:
porta.3 =1
goto start

loop:
porta.0 =1

goto start
end[/QUOTE]


And you last post, 'where is the serin command?'. I'm using the hardware serial port driven by the 'on interrupt' command. Read the PBP manual a bit on it, then read the datasheets on the serial port and interrupts.
Give me a few minutes. I'll rework your code into something useful.
JDG

wow, ok some improvements to be done.
I will try this tonight when I get home, I might leave early...

ken

Ok, this should work. Ingest the code, understand the manchester encoding method.
And your other program only turned LEDs on, it never turned them off. And it never cleared B0.

'RECEIVER CODE

DEFINE OSC 20 '20Mhz Oscillator was used

Include "modedefs.bas" ' Include serial modes

ADCON0 = 0 : ADCON1 = 7 'AD MODULE OFF & CONSUMES NO CURRENT
CMCON = 7 'COMPARATORS OFF
TRISA = $00 : TRISB = $FF 'all porta is outputs, all portb is inputs

B0 var byte

'testing led outputs
porta.0 = 1 : pause 200 : porta.0 = 0
porta.1 = 1 : pause 200 : porta.1 = 0
porta.2 = 1 : pause 200 : porta.2 = 0
porta.3 = 1 : pause 200 : porta.3 = 0

start:
B0 = 0 'empty B0 because the program doesn't
serin PORTB.3,n2400,[B0] 'if n2400 doesn't work, try t2400
if B0 = $aa then training 'manchester encoded $f
if B0 = $55 then training 'manchester encoded $0
if B0 = $56 then led1toggle 'manchester encoded $1
if B0 = $59 then led2toggle 'manchester encoded $2
if B0 = $5A then led3toggle 'manchester encoded $3
if B0 = $65 then led4toggle 'manchester encoded $4
if B0 = $66 then ledson 'manchester encoded $5
if B0 = $69 then ledsoff 'manchester encoded $6
if B0 = $6A then ledswing 'manchester encoded $7
'still have $8-$e free to use
goto start

led1toggle:
if porta.0 = 1 then
porta.0 = 0
else
porta.0 = 1
endif
goto start

led2toggle:
if porta.1 = 1 then
porta.1 = 0
else
porta.1 = 1
endif
goto start

led3toggle:
if porta.2 = 1 then
porta.2 = 0
else
porta.2 = 1
endif
goto start

led4toggle:
if porta.3 = 1 then
porta.3 = 0
else
porta.3 = 1
endif
goto start

ledson:
porta.0 = 1 : porta.1 = 1 : porta.2 = 1 : porta.3 = 1
goto start

ledsoff:
porta.0 = 0 : porta.1 = 0 : porta.2 = 0 : porta.3 = 0
goto start

ledswing:
porta.0 = 1 : pause 10 : porta.0 = 0
porta.1 = 1 : pause 10 : porta.1 = 0
porta.2 = 1 : pause 10 : porta.2 = 0
porta.3 = 1 : pause 10 : porta.3 = 0
goto start

end


Redo your transmitter code to match the receiver code. Put a few buttons on it to transmit the codes above needed to turn your leds on and off, etc.

Do you have a couple of buttons on the transmitter or is it just a free running PIC without any outside input?

JDG