Serout problem

[skimask]

Now for the receiver code....

The receiver has to be trained as noted in the last post, and almost everything applies to the receiver as far as manchester encoding/decoding goes.


INCLUDE "modedefs.bas"
DEFINE OSC 20 'use external 20mhz crystal
CMCON = 7 : ANSEL = 0 : ADCON1 = 7
rxin var portb.5 : input rxin : datain var byte

ledcount var byte
led1 var porta.0 : output led1 : led2 var porta.1 : output led2
led3 var porta.2 : output led3 : led4 var porta.3 : output led4

key var portb.0 : input btn
led1 = 1 : pause 500 : led1 = 0 : led2 = 1 : pause 500 : led2 = 0
led3 = 1 : pause 500 : led3 = 0 : led4 = 1 : pause 500 : led4 = 0

mainloop:

serin rxin, n2400, 5000, nodatarx, datain
'if no data received in 5 seconds, jump to nodatarx

'2 byte values, $55 and $aa set aside for training the receiver, ignore them
if datain = $55 then 'manchester encoded $0, training the receiver
goto mainloop
endif

if datain = $aa then 'manchester encoded $f, training the receiver
goto mainloop
endif

if datain = $66 then 'manchester encoded $5, all leds off
led1 = 0 : led2 = 0 : led3 = 0 : led4 = 0
endif

if datain = $56 then 'manchester encoded $1, led1 on
led1 = 1 : led2 = 0 : led3 = 0 : led4 = 0
endif

if datain = $59 then 'manchester encoded $2, led2 on
led1 = 0 : led2 = 1 : led3 = 0 : led4 = 0
endif

if datain = $5a then 'manchester encoded $3, led3 on
led1 = 0 : led2 = 0 : led3 = 1 : led4 = 0
endif

if datain = $65 then 'manchester encoded $4, led4 on
led1 = 0 : led2 = 0 : led3 = 0 : led4 = 1
endif

goto mainloop

nodatarx: 'flash the leds 3 times
led1 = 0 : led2 = 0 : led3 = 0 : led4 = 0
led1 = 1 : led2 = 1 : led3 = 1 : led4 = 1 : pause 400
led1 = 0 : led2 = 0 : led3 = 0 : led4 = 0 : pause 400
led1 = 1 : led2 = 1 : led3 = 1 : led4 = 1 : pause 400
led1 = 0 : led2 = 0 : led3 = 0 : led4 = 0 : pause 400
led1 = 1 : led2 = 1 : led3 = 1 : led4 = 1 : pause 400
led1 = 0 : led2 = 0 : led3 = 0 : led4 = 0
goto mainloop

END






You may have also notice I shortened up the program a bit by cramming a few of the lines together. There's no reason for it, it just takes up less space on the screen if you have more than one command on a line. I like to pack as much info on the screen as I can, other people can't stand to have more then one command on a line. Personal preference.

[lerameur]

wow, the code works great, I need to learn how to manipulate it now, I am going to work on it,
Thank you again for your time and patience

k

[skimask]

wow, the code works great, I need to learn how to manipulate it now, I am going to work on it,
Thank you again for your time and patience

k

You mean it actually works as advertised? I didn't even have my breadboard out trying the same thing that I was trying to tell you to do.
All you really have to do to get this thing to actually transmit strings of data is to remember to 'train the receiver' first. If you do that, and keep sending serial data (manchester encoded of course), without a pause of more than a few milliseconds between any 2 characters, you should be able to keep sending data.
And do not forget, if you want to send a byte, you have to encode it first, which means you end up sending two bytes, one for the high 4 bits, one for the lower four bits.
JDG

[lerameur]

yes , I actually came back now to edit my last mpost when I saw you answered. I was going to say that the reason why it did not work before is because i was not training my chip.
i have two questions:
1) How come the robot here do not use the training and apparently it works:
http://mysite.verizon.net/res8dbeh/ruf.htm
2) Why does the training code has to be different then the data code ?
I tried sending the data code directly and it do not work.

k

[skimask]

yes , I actually came back now to edit my last mpost when I saw you answered. I was going to say that the reason why it did not work before is because i was not training my chip.
i have two questions:
1) How come the robot here do not use the training and apparently it works:
http://mysite.verizon.net/res8dbeh/ruf.htm
2) Why does the training code has to be different then the data code ?
I tried sending the data code directly and it do not work.

k

1 -
I don't know why it works. I suspect it's because in the RUFBOT project, data is continuously sent (if you look at the code, it can loop around very quickly), and therefore, the number of 1's and 0's evens out eventually and keeps the receiver trained continuously. In your case, I assumed you wouldn't be transmitting data continuously, which is apparently the case.
I suppose you could rewrite your code a bit, get rid of the 'RX training code', and put everything in a loop, and have it send out data after data after data, and get rid of the manchester encoding altogether. As long as you don't wait much more than 3-4ms between data bytes, you might be alright. My big thing about using the manchester encoding is that it increases the data integrity and reliability factor immensely when compared to not using it. And if you're doing anything that needs to have a bit of integrity and reliability and don't use manchester, you need to figure out some method to make sure the data is correct (checksum, multiple data compares, etc.etc).
Manchester just seemed easier to me.

2-
Why does the training code have to be different than the data code?

I'm not exactly sure what you mean by this, but I hope this does it.
In the program that I wrote up, the training codes are $55 and $AA. As I said before, those 2 bytes have an equal number of 1's and 0's, and they alternate equally, i.e. 01010101, 10101010. Other codes, like $59, 01011001, see there's 2 1's and 2 0's back to back. So, $55 and $AA are optimal for training the receiver. Once the receiver is trained, you should be able to send whatever to the receiver. The big thing is to send an equal number of 1's and 0's over 3-5ms. That keeps the data slicer charged up halfway so it can tell the difference between a 1 and a 0. Too many 1's, and eventually, everything looks like a 0, too many 0's, and eventually, everything looks like a 1.
JDG

[lerameur]

Ok , does the training part has to do with the receiver recognizing the start it and end bit. I assume the Picbasic pro compiler adds this to the signal. If it does not how does it recognize the begining of the signal, As a matter of fact might as well be the middle or 2/3 into the signal. Is this what is meant about synchronization of transmitter and receiver?

k

[Dave]

lerameur, What skimask means by training the receiver is actually "Preconditioning" the data slicer which is actually the comparator that gives you the data output. This is done by sending some type of preamble characters that represent approx. 50 % duty cycle as far as data is concerned..

Dave Purola,
N8NTA