Serout problem

[skimask]

Now then....

Remove the wire between the 2 PICs. Connect the transmitter input to TXPIC-PortB.2, connect the receiver digital output to RXPIC-PortB.5. You're not ready to send data yet. You have to encode the data from the TXPIC and then decode it at the RXPIC using manchester encoding/decoding techniques.

The receiver module relies on bit transitions, not steady state levels. So therefore, with manchester encoding, 1 bit become 2 bits, either a low-high or high-low transition. So, out of one byte (256 values), we can only send 1/2 byte (16 values) of code. 2 of these values have to be reserved for 'training' the receiver, getting the data slicer in the receiver charged up (according to the datasheets for the core of this module, you have to do it for about 5ms).
If we sent all 1's, the data slicer would be charged up to a full 1, if we sent all 0's, the data slicer wouldn't get charged at all, so we send alternating 1's and 0's, hence the 2 reserved byte values, $AA (10101010) and $55 (01010101). Remember, each bit becomes 2 bits in manchester encoding, 0 becomes 01, 1 becomes 10. This gives us 16 values to play with in a byte
hex value----binary value-----manchester encoded binary (hex) value
0------------0000------------01 01 01 01 ($55)
1------------0001------------01 01 01 10 ($56)
2------------0010------------01 01 10 01 ($59)
3------------0011------------01 01 10 10 ($5A)
4------------0100------------01 10 01 01 ($65)
5------------0101------------01 10 01 10 ($66)
6------------0110------------01 10 10 01 ($69)
7------------0111------------01 10 10 10 ($6A)
8------------1000------------10 01 01 01 ($95)
9------------1001------------10 01 01 10 ($96)
A------------1010------------10 01 10 01 ($99)
B------------1011------------10 01 10 10 ($9A)
C------------1100------------10 10 01 01 ($A5)
D------------1101------------10 10 01 10 ($A6)
E------------1110------------10 10 10 01 ($A9)
F------------1111------------10 10 10 10 ($AA)

Only hex $0 and hex $F (left column) are true repeating manchester binary patterns with true alternating values (right column) , so you reserve those for training the receiver only. Everything else from hex $1 - $f (left column) are free.

So, this is what we'll do:
Modify the transmitter code to send the code for each LED 1-4 out the serial port to the transmitter in manchester format, but instead of using hex $0 for reset the LEDs, we'll use hex $5. And don't forget, we have to train the receiver (by sending data with the transmitter) each time we send a new code.


So the transmitter code changes to:


INCLUDE "modedefs.bas"
DEFINE OSC 20 'use external 20mhz crystal
CMCON = 7 : ANSEL = 0 : ADCON1 = 7
txout var portb.2 : output txout : dataout 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 'push button on portb.0
'1K-10K resistor from portb.0 to ground (pulldown)
'push button is wired between portb.0 and +5v
'initial LED check
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:

if key = 0 then 'button not pressed
goto mainloop
endif
if key = 1 then
pause 50 'wait 50ms for switch to debounce then check again
if key = 1 then 'if it's still pressed, then increment the count
ledcount = ledcount + 1
dataout = $55 ($55 = manchester encoded $0)
'train the receiver by sending 5 each of the $55's, may need more
'just copy the line below to make it send out more characters
serout txout, n2400, [ dataout, dataout, dataout, dataout, dataout ]
endif
endif

if ledcount = 0 then 'all leds off
dataout = $66 'manchester encoded $5, use because $0 is reserved
serout txout, n2400, [ dataout ]
'may have to send data more than once depending on how well the receiver
'can capture the data. Shouldn't have a problem sending it once
led1 = 0 : led2 = 0 : led3 = 0 : led4 = 0
endif

if ledcount = 1 then '1st led on
dataout = $56 'manchester encoded $1
serout txout, n2400, [ dataout ]
led1 = 1 : led2 = 0 : led3 = 0 : led4 = 0
endif

if ledcount = 2 then '2nd led on and so on and so on down the line....
dataout = $59 'manchester encoded $2
serout txout, n2400, [ dataout ]
led1 = 0 : led2 = 1 : led3 = 0 : led4 = 0
endif

if ledcount = 3 then
dataout = $5a 'manchester encoded $3
serout txout, n2400, [ dataout ]
led1 = 0 : led2 = 0 : led3 = 1 : led4 = 0
endif

if ledcount = 4 then
dataout = $65 'manchester encoded $4
serout txout, n2400, [ dataout ]
led1 = 0 : led2 = 0 : led3 = 0 : led4 = 1
endif

if ledcount = 5 then 'reset led count, roll it back to 0
ledcount = 0 'and turn leds off since count is back to 0
dataout = $66 'manchester encoded $5 (same thing as ledcount = 0 above)
serout txout, n2400, [ dataout ]
led1 = 0 : led2 = 0 : led3 = 0 : led4 = 0
endif

goto mainloop

END






This code should still change the LEDs on TXPIC, but won't do anything for RXPIC until we change that code...
Receiver code in next post....
JDG

[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

[lerameur]

By preconditioning you mean making sure the internal circuitry lets say capacitor will be ready . As in ready I mean not empty or full as to give a 1 instead of a 0 or the other way. BUt is there a start bit ? How does it know where the data start and end. I guess there is not start bit like in network communication, the training session replaces that . As en example, lets say the pic chip receives the 8bit is needs, on the next eight bit, it misses out (for a reason or another) a bit, Will it be taking its eight bit on the next sequence or simply drop the whole byte ? this is what I meant by how does it know the end and start of a byte series. In networking a packet has a lot of overhead, here there is none of that.

k

[skimask]

By preconditioning you mean making sure the internal circuitry lets say capacitor will be ready . As in ready I mean not empty or full as to give a 1 instead of a 0 or the other way. BUt is there a start bit ? How does it know where the data start and end. I guess there is not start bit like in network communication, the training session replaces that . As en example, lets say the pic chip receives the 8bit is needs, on the next eight bit, it misses out (for a reason or another) a bit, Will it be taking its eight bit on the next sequence or simply drop the whole byte ? this is what I meant by how does it know the end and start of a byte series. In networking a packet has a lot of overhead, here there is none of that.

k

When you start training/preconditioning the receiver, you won't get much of a recognizable output, maybe half a byte here and there, with or without start or stop bits,...until the receiver is conditioned. Which is why I keep saying you have to train the receiver first and ignore that data, then send some sort of sync byte to get things going.

In this project's case, we don't need much of anything so far, but with data transmission, you'll need to figure out some sort of packet method of transferring data.

The TXPIC (and therefore transmitter) still sends start and stop bits. It's just that the receiver module doesn't care about any start or stop bits. The PIC (rather the program anyways) still sees the start and stop bits and acts on them accordingly (and remember, a start bit is a low, a stop bit is a high, so that's 50% 1's and 50% 0's, they even themselves out, just like they should with manchester encoding). It's the data in between that ends up encoded.
If the PIC SerIn starts to receive a byte in the middle of it, it won't get the right stop bit, and jump out. If the PIC SerIn statement somehow never receives a full 8 bits and a stop bit, same thing, it'll timeout and jump to whatever you tell it to go to.

I don't know how to explain it to you any farther except to tell you to get online like I told you to do awhile back and do some Google'ing on manchester encoding, 433 transmitter/receiver modules, figure out how they work, why they need to use manchester encoding, etc.
The idea really isn't that hard to wrap your head around. And once you figure it out, you'll be all over it.
JDG

[Agent36]

Hi,

I am having a couple of problems with the above code. I changed it so that I could run it on two 16f628 chips, this works with out any problems.
Happy that I could tx and rx I wanted to tx using a 12f675 chip and rx on a 16f628.

Changing the tx code for a 12f675 and compiling it gave no errors. The leds flash ok and when I put an led on the serout pin I see the data. When I tx the code to the rx 16f628 via a tx the rx wont respond. I then hardwired the 12f675 to the 16f628 removing the tx/rx, it still wont work.
Can someone please check my code or suggest why it wont work.
Here is the code;

@ DEVICE PIC12F675, INTRC_OSC_NOCLKOUT
' System Clock Options (Internal)
@ DEVICE PIC12F675, WDT_ON
' Watchdog Timer
@ DEVICE PIC12F675, PWRT_ON
' Power-On Timer
@ DEVICE PIC12F675, MCLR_OFF
' Master Clear Options (Internal)
@ DEVICE PIC12F675, BOD_OFF
' Brown-Out Detect
@ DEVICE PIC12F675, CPD_OFF
' Data Memory Code Protect
@ DEVICE PIC12F675, PROTECT_ON

'PICBASIC PROGRAM

ANSEL = 0
CMCON = 7
TRISIO =%001000


INCLUDE "modedefs.bas"


txout VAR GPIO.4 : Output txout : dataout VAR BYTE
ledcount VAR BYTE
led1 VAR GPIO.0 : Output led1 : led2 VAR GPIO.1 : Output led2
led3 VAR GPIO.2 : Output led3 : led4 VAR GPIO.5 : Output led4
key VAR GPIO.3 : Input key 'push button on gpio.3
'1K-10K resistor from portb.0 to ground (pulldown)
'push button is wired between portb.0 and +5v
'initial LED check
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:

IF key = 0 Then 'button not pressed
GoTo mainloop
EndIF
IF key = 1 Then
Pause 50 'wait 50ms for switch to debounce then check again
IF key = 1 Then 'if it's still pressed, then increment the count
ledcount = ledcount + 1
dataout = $55 '($55 = manchester encoded $0)
'train the receiver by sending 5 each of the $55's, may need more
'just copy the line below to make it send out more characters
SerOut txout, n2400, [ dataout, dataout, dataout, dataout, dataout ]
EndIF
EndIF

IF ledcount = 0 Then 'all leds off
dataout = $66 'manchester encoded $5, use because $0 is reserved
SerOut txout, n2400, [ dataout ]
'may have to send data more than once depending on how well the receiver
'can capture the data. Shouldn't have a problem sending it once
led1 = 0 : led2 = 0 : led3 = 0 : led4 = 0
EndIF

IF ledcount = 1 Then '1st led on
dataout = $56 'manchester encoded $1
SerOut txout, n2400, [ dataout ]
led1 = 1 : led2 = 0 : led3 = 0 : led4 = 0
EndIF

IF ledcount = 2 Then '2nd led on and so on and so on down the line....
dataout = $59 'manchester encoded $2
SerOut txout, n2400, [ dataout ]
led1 = 0 : led2 = 1 : led3 = 0 : led4 = 0
EndIF

IF ledcount = 3 Then
dataout = $5a 'manchester encoded $3
SerOut txout, n2400, [ dataout ]
led1 = 0 : led2 = 0 : led3 = 1 : led4 = 0
EndIF

IF ledcount = 4 Then
dataout = $65 'manchester encoded $4
SerOut txout, n2400, [ dataout ]
led1 = 0 : led2 = 0 : led3 = 0 : led4 = 1
EndIF

IF ledcount = 5 Then 'reset led count, roll it back to 0
ledcount = 0 'and turn leds off since count is back to 0
dataout = $66 'manchester encoded $5 (same thing as ledcount = 0 above)
SerOut txout, n2400, [ dataout ]
led1 = 0 : led2 = 0 : led3 = 0 : led4 = 0
EndIF

GoTo mainloop

End

I am using the two 16f628's with internal clock selected with no problem

thanks Nick

[skimask]

The internal clock on the 12F675 is probably too far off (i.e. 12F675 transmitting at 2350 baud, 16F628 receiving at 2400 baud, something like that).
Try slowing down the baud rate or moving the OSCCAL value on the 12F675 around a bit and see what happens.

[mister_e]

If the calibration data is still intact, you try to add

DEFINE OSCCAL_1K 1

Before ANSEL=0

[Agent36]

Hi,
thanks for the replys, I thought it might be something to do with the internal osc. Tried the program code on a 16f819 worked fine.
So i got a brand new 12f675, checked the osc cal and band gap values, loaded the code and rechecked them. I did this because I have had other timing issues with these 12f675's. Some of which were down to me I think.
I like to stick with an 8 pin chip because I aim to fit the board into a keyfob, so space is tight.
First I will try the soloutions you have offered.

Thanks for your time.

Nick

[Agent36]

Hi,

Thanks for the info regarding the DEFINE OSCCAL_1K 1
Adding that to the program code has solved my little problem.

I have found referances about this define in the pbp manual, for some reason I thought that DEFINE OSC 4mhz was correct.

I assume that DEFINE OSCCAL_1K 1 means

org 0
movwf OSCCAL

Thanks for your time........Nick