Serout problem

[lerameur]

I just started to play with wireless transmision. I used this kit that
I ordered:
http://www.rentron.com/remote_control/TWS-8-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

[skimask]

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

[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

[skimask]

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

[skimask]

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...

[lerameur]

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

[skimask]

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...

[lerameur]

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

[skimask]

$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

[lerameur]

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

[lerameur]

oups 8 bit

[skimask]

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

[lerameur]

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

[skimask]

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

[skimask]

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.

[lerameur]

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

[skimask]

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.

[lerameur]

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

[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.

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.

[skimask]

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

[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

[skimask]

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

[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

[lerameur]

I was looking at the HSERIN command..

[skimask]

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.

[lerameur]

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

[skimask]

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

[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.

[lerameur]

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/products/robot-parts/communication-control/rc-communications/on-shine-high-sensitivity-tx-rx.html
I might try them out just for fun

ken

[skimask]

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

[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

[skimask]

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

[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

[lerameur]

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

[skimask]

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

[lerameur]

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

ken

[lerameur]

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

[skimask]

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

[lerameur]

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

ken

[skimask]

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

[lerameur]

I just have a pot command as input, from memory
port portb.1,50,bo
if bo >0 and bo <150 then output1
if bo > 150 and bo <255 the output 2
output1
serout ......

something like that , just two different outputs for now,
I will use the a/d converter when I get the first working.

k

[skimask]

'posted to the wrong thread!!!! :)
didn't realize this thread has gone to 2 pages!

[skimask]

'after you've got everything else set up

led1toggle = $56 : led2toggle = $59 : led3toggle = $5a : led4toggle = $65
ledson = $66 : ledsoff = $69
ledswing = $6a

START:
gosub trainreceiver : serout portb.2, n2400, [ ledsoff ] : pause 1000
gosub trainreceiver : serout portb.2, n2400, [ ledson ] : pause 1000

goto start

trainreceiver:
serout portb.2, n2400, [ $aa, $aa, $aa, $aa, $aa ] : return

end



See that? Every time you send a command you have to train the receiver because there is more than about 5ms between commands. If you were to continuously send commands or data, you probably wouldn't need to train the receiver. But in any case, you MUST use manchester encoding! You'll get garbage at the output if you don't!
As this code is setup, all your LEDs should come on for a second, turn off for a second, come on for a second, etc.etc...
Let me know what happens...
JDG

Ok, I just saw the post about using the pot. So use the pot to turn the LEDs on and off. Then after that works, use the POT to turn the LEDs on in sequence to match the pot's rotation.

gosub trainreceiver : serout portb.2, n2400, [ ledsoff ]
if b0 < 64 then gosub trainreceiver : serout portb.2, n2400, [ led1toggle ]
if ( b0 > 63 ) and ( b0 < 128 ) then gosub trainreceiver : serout portb.2, n2400, [ led2toggle ]
if ( b0 > 127 ) and ( b0 < 192 ) then gosub trainreceiver : serout portb.2, n2400, [ led3toggle ]
if ( b0 > 191 ) then gosub trainreceiver : serout portb.2, n2400, [ led4toggle ]

[lerameur]

I had time to analyze the code:
A few questions came up:
For the ledtoggle, why would you want to bit the pin high to low and then put it high, why not put it high right away. The way you have it, if its high, you put it to low, then to high, there must be a reason why and its flying 100 feet over my head.
Also, the led will stay on until you call the ledsoff right?
as far as the manchester coding goes, I understand, but there is decoder done here, you are simply pointing the coded values to their function. right?

k

[skimask]

I had time to analyze the code:
A few questions came up:
For the ledtoggle, why would you want to bit the pin high to low and then put it high, why not put it high right away. The way you have it, if its high, you put it to low, then to high, there must be a reason why and its flying 100 feet over my head.
Also, the led will stay on until you call the ledsoff right?
as far as the manchester coding goes, I understand, but there is decoder done here, you are simply pointing the coded values to their function. right?

k


LedToggle --- It's not the way describe it.
Read the IF...ELSE....ENDIF statement... work it through in your head.
If it's on, turn it off, otherwise turn it on (implying that it was off in the first place).

Encoder/Decoder - yes, I am assuming you don't have either the encoder or the decoder in the circuit. As far as I'm concerned, you don't need it. Yes, it's a handy piece of hardware to have around. The sooner you figure out how to do things without it, the better.

JDG

[lerameur]

HI

I was not refering to the hardware encoder and decoder.
The program I have below works, but always gives me zero on the lcd.
k
By the way , the command gosub trainreceiver :... gives an eror while compiling , wrong Label..


X VAR BYTE 'VARIABLE TO incoming VALUE
pause 100
mainloop:
X =0
serin PORTB.3,n2400,[X]
Lcdout $fe, 1, "Value in: ", dec X
pause 100
Goto mainloop
End

[skimask]

HI

I was not refering to the hardware encoder and decoder.
The program I have below works, but always gives me zero on the lcd.
k
By the way , the command gosub trainreceiver :... gives an eror while compiling , wrong Label..


X VAR BYTE 'VARIABLE TO incoming VALUE
pause 100
mainloop:
X =0
serin PORTB.3,n2400,[X]
Lcdout $fe, 1, "Value in: ", dec X
pause 100
Goto mainloop
End




Now, what are you trying to do here....Make LEDs light up on command or make an LCD work.

If you can't make LEDs do what you want them to, when you want them to do it, how do you expect to make an LCD work correctly?

When you get a good hack on your priorities, let me know, I'm not going anywhere.

Until then, start with the basics and work your way up...

And as far as your program not working, you've got a 100ms pause between checking the serin. Get rid of the pause and use the timeout. If you get a timeout, no data has been received. If you don't get a timeout, you probably got some data. A 100ms is too long of a time to be missing characters. The receiver doesn't store them for you until you're ready to take them.

(On another note, the trainreceiver gosub, try putting that above the main program, but below the setup, it should work correctly then, unless I had a typo or something)

JDG

[lerameur]

I am putting an LCD to see what is coming in to be able to troubleshoot the problem , since the led dont work, I would like to see what is coming in portb.3. Sonce its giving me a value of zero, I guess my command serin is not interpretting the incoming code right.
I just tried the following code. I realized that with 'serin' command the loop would stop at the first iteration. Now with serin2 , the led blinks, so the loops keeps going. The value coming in at portb.3 is erronous when ever it flashes once in a while on the lcd screen ( at least the erronous values are between 0 and 250). AND i get the same signal in and out on the oscilloscope
if i dont get $55, $aa.. on the lcd screen , I suppsoe I wont be getting any leds turned on
k

mainloop:
X =0
serin2 PORTB.3,n2400,[X]
Lcdout $fe, 1, "Value in: ", dec X

Goto mainloop
End

[lerameur]

By the way I tried your code, led led lights at startup once, then i cannot get any leds to light. this is the reason why I thought it would be good to see what was going on with an LCD

k

[mister_e]

how about your config fuses?

Any Schematic?

[lerameur]

this is the new whole program on the receiving end. If the inpu is not good, then I guess why continue making a big program making leds flash on different Pot output when the Pic cannot identify one input in the first place.

define osc 20
Include "modedefs.bas"
Define LOADER_USED 1
DEFINE LCD_DREG PORTB ' Set LCD Data port
DEFINE LCD_DBIT 4 ' Set starting Data bit (0 or 4) if 4-bit bus
DEFINE LCD_RSREG PORTB ' Set LCD Register Select port
DEFINE LCD_RSBIT 1 ' Set LCD Register Select bit
DEFINE LCD_EREG PORTB ' Set LCD Enable port
DEFINE LCD_EBIT 0 ' Set LCD Enable bit
DEFINE LCD_BITS 4 ' Set LCD bus size (4 or 8 bits)
DEFINE LCD_LINES 2 ' Set number of lines on LCD

CMCON=7 ' Disable comparators
'ANSEL=0 ' Set port as digital I/O
ADCON1=7
TrisB = %11111111 'sets all port a as input
TrisA = %00000000 ' sets all port b as output

X VAR BYTE 'VARIABLE TO incoming VALUE

pause 100

mainloop:
X =0
serin2 PORTB.3,n2400,[X]
Lcdout $fe, 1, "Value in: ", dec X
'porta.2 = 1 ' trying to see if the loop is looping
'pause 200
'porta.3 = 1
'pause 200
Goto mainloop

End



as far as the configuration goes, It is an F88, with portB.3 as the input and porta.2 and porta.3 as led output

[mister_e]

mmm, are you using the bootlader AND the LCD? If so, for sure there's some hardware problem... as the USART share the same I/O for your LCD data bits.

Also, ANSEL should be = 0 to disable those internal ADCs, ADCON1=7 will work on some other PIC... unfortunately not this one :(

[lerameur]

I think my problem might be the sending code. I have added the output line to my lcd tosee what is sending, it says it is sending V and I's..
here is the sending code

define osc 20
Include "modedefs.bas"
Define LOADER_USED 1
DEFINE LCD_DREG PORTB ' Set LCD Data port
DEFINE LCD_DBIT 4 ' Set starting Data bit (0 or 4) if 4-bit bus
DEFINE LCD_RSREG PORTB ' Set LCD Register Select port
DEFINE LCD_RSBIT 1 ' Set LCD Register Select bit
DEFINE LCD_EREG PORTB ' Set LCD Enable port
DEFINE LCD_EBIT 0 ' Set LCD Enable bit
DEFINE LCD_BITS 4 ' Set LCD bus size (4 or 8 bits)
DEFINE LCD_LINES 2 ' Set number of lines on LCD

CMCON=7 ' Disable comparators
ANSEL=0 ' Set port as digital I/O
ADCON1=7
TrisA = %11111111 'sets all port a as input
TrisB = %00000000 ' sets all port b as output

X VAR BYTE 'VARIABLE TO PUT POT VALUE
B1 VAR BYTE
PORTB = 0 'ALL OUTPUTS LOW
'23

Start:
Pot PortA.2,49,X ' would like PortA.2,175,B0 use number to suit you
Lcdout $fe, 1 'Clear screen
Lcdout $FE,$80,"Pot: ", #X 'Display the numerical value
LCDOUT $FE,$C0,"Output: ",B1
Pause 10

IF X <= 60 THEN LED1
IF (X > 60) AND (X <= 120) THEN LED2
IF (X > 120) AND (X <= 180) THEN LED1
IF X > 180 THEN LED2
goto Start

LED1
serout portb.2,n2400, [ $AA, $AA,$AA,$AA,$AA,$AA ]
B1=$AA
goto Start


LED2
serout portb.2, n2400, [ $56,$56,$56,$56,$56 ]
B1=$56
goto Start

LED3
serout portb.2,n2400, [ $55,$55,$55,$55,$55 ]
B1=$55
goto Start

LED4
serout portb.2,n2400, [ $65,$65,$65,$65,$65,$65 ]
B1=$65
goto Start

end

[lerameur]

By the way , in the receiving code you gave me, there is a Training function called, but it does not exists.

[lerameur]

I tried ansel =o all you told me, and remove the boatloader. Dont even know why it was there. There is no change in the system .
If I am sending $aa on the tramsitter pic, shouldn'y I get that also on the LCD on the transmitter?

I have four output on my transmitter. Here is your code to with only four values, the rest I didnot change it. None of the leds are lighting besides the initial feed:

'RECEIVER CODE

DEFINE OSC 20 '20Mhz Oscillator was used

Include "modedefs.bas" ' Include serial modes

ADCON0 = 0 '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 ledson 'manchester encoded $f
if B0 = $55 then ledswing 'manchester encoded $0
if B0 = $5a then led1toggle 'manchester encoded $1
if B0 = $65 then led2toggle 'manchester encoded $2

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

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

[lerameur]

Would it be posible my pic at the receiver dont recognize the data in ?
could the USART be at cause here ?

The programs take a lot of space, I decided to post them on my web site:
http://www3.sympatico.ca/lerameur/

k

[skimask]

I think my problem might be the sending code. I have added the output line to my lcd tosee what is sending, it says it is sending V
and I's..

-----------------because a V is ASCII code $56? and the 'I' must be a special character or something-doesn't matter
---------------------

here is the sending code

define osc 20
Include "modedefs.bas"

------------------get rid of this unless you are really using a bootloader
Define LOADER_USED 1
-----------------------------------------------------------

DEFINE LCD_DREG PORTB ' Set LCD Data port
DEFINE LCD_DBIT 4 ' Set starting Data bit (0 or 4) if 4-bit bus
DEFINE LCD_RSREG PORTB ' Set LCD Register Select port
DEFINE LCD_RSBIT 1 ' Set LCD Register Select bit
DEFINE LCD_EREG PORTB ' Set LCD Enable port
DEFINE LCD_EBIT 0 ' Set LCD Enable bit
DEFINE LCD_BITS 4 ' Set LCD bus size (4 or 8 bits)
DEFINE LCD_LINES 2 ' Set number of lines on LCD

CMCON=7 ' Disable comparators
ANSEL=0 ' Set port as digital I/O
ADCON1=7
TrisA = %11111111 'sets all port a as input
TrisB = %00000000 ' sets all port b as output

X VAR BYTE 'VARIABLE TO PUT POT VALUE
B1 VAR BYTE
PORTB = 0 'ALL OUTPUTS LOW
'23

Start:
Pot PortA.2,49,X ' would like PortA.2,175,B0 use number to suit you
Lcdout $fe, 1 'Clear screen
Lcdout $FE,$80,"Pot: ", #X 'Display the numerical value

------------------------------should be 'HEX B1' at the end
LCDOUT $FE,$C0,"Output: ",B1
-------------------------------
Pause 10

IF X <= 60 THEN LED1
IF (X > 60) AND (X <= 120) THEN LED2
IF (X > 120) AND (X <= 180) THEN LED1
IF X > 180 THEN LED2
goto Start

LED1
serout portb.2,n2400, [ $AA, $AA,$AA,$AA,$AA,$AA ]
B1=$AA
goto Start

LED2
serout portb.2, n2400, [ $56,$56,$56,$56,$56 ]
B1=$56
goto Start

LED3
serout portb.2,n2400, [ $55,$55,$55,$55,$55 ]
B1=$55
goto Start

LED4
serout portb.2,n2400, [ $65,$65,$65,$65,$65,$65 ]
B1=$65
goto Start

end




Does your X value change with the POT when you rotate it?
How about this...let's break it down...again. Apparently there is too much going on here that can break the system and you're having trouble figuring out what's going on.....again...............

1. Get rid of the transmitter................

2. Get rid of the receiver...................

3. Get rid of the POT.......................

4. Put a button where the pot was....

5. Make sure the button works...in other words, you push it and an LED connected to the same PIC on a different pin lights up on software command, not because you pushed it and made an electrical connection, then you release it and the LED goes out on software command, not because you removed an electrical connection. Then change the program around to extinguish the LED when the button is pushed, and light the LED when the button is released. That will tell you that you know how to make an LED light up on command. (or something comes up on the LCD that verifies that you are pushing and releasing the button).

6. Then connect the other receiver PIC to the transmitter PIC through the serial port.

7. Set up a program in the receiver to receive control data from the transmitter PIC and act on it in some fashion, and make it repeatable. For example, each press of the button on the transmitter PIC sends a command to light up a different light in the receiver PIC (4 LEDs light up, one after the other, and so on down the line, until the end is reached, then they extinguish and the process starts again.

8. Then, after that is all working, connect the POT back into the transmitter PIC and rewrite your code to display the POT value on the LCD. When that works fine, continue...and not until it works as you want it to.

9. When steps 1-8 all work fine, each and every time, then disconnect the PIC' serial ports and reinsert the transmitter and receiver modules (not the encoder and decoder modules).

10. Add the code back into the transmitter that send out the various control codes for each LED at the receiver PIC. And don't forget about the receiver training code. It's the transmitter that does the training of the receiver, not the receiver itself.

Tune in tomorrow for more...I'm tired of explaining this...
JDG

, connect the 2 PICs at the serial ports.

[skimask]

if B0 = $aa then training 'manchester encoded $f
if B0 = $55 then training 'manchester encoded $0




that was wrong, it was supposed to be this:

if B0 = $aa then start 'manchester encoded $f
if B0 = $55 then start 'manchester encoded $0

$F and $0 are for 'training' the receiver and aren't to be used for sending data until the receiver is trained....

Also in your RX4.bas (maybe it was RX6.bas), you have
Serin PortB.3, 16780, [B0]
----shouldn't that be serin2?

JDG

[lerameur]

O k starting from scratches..
I manages to do 2 different programs which dont work.
here: http://www3.sympatico.ca/lerameur/
do I need to configure SSPCON, or the RCSTA registers ?

Also in your RX4.bas (maybe it was RX6.bas), you have
Serin PortB.3, 16780, [B0]
----shouldn't that be serin2?
I tried both , so many combinations....

k

[skimask]

O k starting from scratches..
I manages to do 2 different programs which dont work.
here: http://www3.sympatico.ca/lerameur/
do I need to configure SSPCON, or the RCSTA registers ?

Also in your RX4.bas (maybe it was RX6.bas), you have
Serin PortB.3, 16780, [B0]
----shouldn't that be serin2?
I tried both , so many combinations....

k



Did you get the LEDs to light up in sequence as described in the earlier post?
And if you didn't, then why are you worried about the SSPCON or RCSTA registers... and why are you worried about those 2 registers in the first place? You're using a software-based serial commands, not hardware.
Priorities, man, priorities....

And after further checking.....................
If you'd check your ttt program and read the PIC datasheet, you'll notice that RA.4 is an open-drain output...you'll never get a high logic level from it...
If you'd check your rrr program and read the PIC datasheet, you'll notice that the TRIS statements are wrong...

Don't assume something is broke when you just plain haven't looked hard enough... Come on,,, get on it... Get this thing working by tomorrow!!! :) or else!!!

[lerameur]

Nothing is working,
Well the testing led part in the program works. thats it.
The loop is looping, but as soon as I put the wire to the input port, then the signal disappear. AND no leds lighting

k

[skimask]

Ok, Ok, Ok,.............................
Here we go again.....................
This is getting annoying............
There is something getting messed up somewhere, something you aren't telling me, something you are doing ahead of time, something you aren't doing in a logical sequence, something somewhere...........so.......

Answer these 2 questions:

1. What hardware do you have? List the PICs, the crystals, the LEDs, the TX, the RX, the switches, the pot, etc. and so and so....

2. What is your 'master plan'? Do you intend to transfer data between 2 PICs wirelessly? Do you intend to just control a couple of LEDs wirelessly? What?

JDG

[lerameur]

1. What hardware do you have? List the PICs, the crystals, the LEDs, the TX, the RX, the switches, the pot, etc. and so and so....
Pic16F88, 20Mhz crystals, Led out on portA.0,1,2 and 3
MCRL on PORTA.5, ground pin, Vdd on 5v. NO pot, no switch, Just a wire going from PortB3 (output of serout) going to portA.4 (serin)
if serin.. well
START:
B0 =0
serout portB.3,n2400, [ $0F, $0F, $0F, $0F, $0F, $0F, $0F ]
serin portA.4,n2400, [B0 ]
if (B0 = $0F) then
porta.2 =1
pause 100
porta.2 =0
else
goto start
endif
GOTO START

2. What is your 'master plan'? Do you intend to transfer data between 2 PICs wirelessly? Do you intend to just control a couple of LEDs wirelessly? What?
I want to transfer data to about 200feet between two pics.

Go back to my web site, I posted a picture of the circuit
thanks for your time
ken

[skimask]

1. What hardware do you have? List the PICs, the crystals, the LEDs, the TX, the RX, the switches, the pot, etc. and so and so....
Pic16F88, 20Mhz crystals, Led out on portA.0,1,2 and 3

2. What is your 'master plan'? Do you intend to transfer data between 2 PICs wirelessly? Do you intend to just control a couple of LEDs wirelessly? What?
I want to transfer data to about 200feet between two pics.

ken

Ok, still a lot of information missing. Is the 16F88 your transmitter or receiver PIC? You posted what I assume is the 'transmitter' code, what about the receiver hardware and/or code...in fact, don't worry about the code for right now. We're going to make sure your hardware is hooked up right.
(P.S. I'm only going to be here for the next 1/2 hour, until 10pm CST)


And another thing, you are using a software based serial solution, also called 'bit-banging'. By the time your serout is done, all the data is transmitted. It's not buffered anywhere. It's not done in hardware. It's like trying to use 2 telephones to talk to yourself in different rooms. You talk into one phone, run to the other room and wait for your voice to come out. It isn't going to happen. Serin doesn't have anything to do but wait for nothing. Not going to work....

[lerameur]

well from what you said before:
5. Make sure the button works...in other words, you push it and an LED connected to the same PIC on a different pin lights up on software command

I went real simple as you told me.
So this pic is the only pic, emitting AND receiving, the yellow wire is from sending to receiving.

k

[skimask]

well from what you said before:
5. Make sure the button works...in other words, you push it and an LED connected to the same PIC on a different pin lights up on software command

I went real simple as you told me.
So this pic is the only pic, emitting AND receiving, the yellow wire is from sending to receiving.

k



Not going to work. See last thread I posted.
JDG

[lerameur]

just posted the unworking program ,
nothing is coming out of the sending chip

[skimask]

just posted the unworking program ,
nothing is coming out of the sending chip


I know nothing is working on your sending chip...you've got it set up wrong. Read my words a couple of posts ago. Going out of the chip back into the chip isn't going to work.

Plug this into your sending chip, with only the LEDs and a button attached to portb.0 with a pulldown resistor:

-------------------------------------------------------------------------
INCLUDE "modedefs.bas"
DEFINE OSC 20 'use external 20mhz crystal
CMCON = 7 : ANSEL = 0 : ADCON1 = 7

ledcount var byte

led1 var porta.0 : output led1 'led on porta.0
led2 var porta.1 : output led2 'and so on...
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

led1 = 1 : pause 500 : led1 = 0 'initial light up to see if program is running
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
endif
endif

if ledcount = 0 then 'all leds off
led1 = 0 : led2 = 0 : led3 = 0 : led4 = 0
endif
if ledcount = 1 then '1st led on
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....
led1 = 0 : led2 = 1 : led3 = 0 : led4 = 0
endif
if ledcount = 3 then
led1 = 0 : led2 = 0 : led3 = 1 : led4 = 0
endif
if ledcount = 4 then
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
led1 = 0 : led2 = 0 : led3 = 0 : led4 = 0
endif

goto mainloop

END




Forget about serial code, the LCD and anything else that isn't listed above. Just do what's listed, and nothing else. If you go off on a tangent somewhere else, I don't know where you're going. Just do this. Get this to work. Then do the same basic thing on the receiver PIC. Get them both to work. We'll worry about connecting the 2 after both of these work.
All this program is going to do is make the LED lights walk about 5 times a second as long as you hold the button down.
JDG

[lerameur]

Ok I am going to do this, I will read and analyze your code before asking anything
I'm off to bed now,
thanks and see ya

k

[skimask]

Ok I am going to do this, I will read and analyze your code before asking anything
I'm off to bed now,
thanks and see ya

k


There's no analyzing. You put the LEDs on PortA.0, A.1, A.2, A.3, set the pins to output. Put the switch on PortB.0, set the pin to input. Light them up in sequence for 1/2 second each.
Then we sit in a loop waiting for the key input to go high (because it's pulled low without the button pressed).
When it goes high, we wait 50ms. If it's still high after 50ms, then we increment the LED count.
After that, it goes into a bunch of IF...THEN statements and sets the LEDs accordingly. If the count is 5, we reset the count back to zero and turn off all the LEDs...
And start over again with checking the button...

What's there to analyze? There is no analyzing. It is straight forward code, nothing hidden, no tricks of programming, no code magic, nothing. Short of
10 PRINT"HELLO"
20 GOTO 10
it doesn't get much easier than this.

JDG

[lerameur]

well that works for both of them
the four leds are funvtionning good on both circuits.

k

[skimask]

well that works for both of them
the four leds are funvtionning good on both circuits.

k


You have a PIC16F88 on the transmitter and a PIC16F628A on the receiver, yes?

When you push the button on each PIC, the LEDs cycle thru on their respective PICs with each button press, yes? (remember, 2 seperate circuits running independant programs, not tied together except for the fact they happen to be mounted to the same workbench).

If they do, change the pause 50 to pause 1000. When you hold the button down, the LEDs should increment once a second. That will verify that the oscillator is running at the correct speed (or at least close to it).

I just want to make sure this is all work before we got any farther (small steps).

JDG

[lerameur]

I have two Pic16F88 ( did try a PIC16F628A once to see what would happen, how did you know, I dont think I mentioned that)

both circuits are running independently, Just the power supply is hooked up in parallel. Two circuits, two breadboards. two are doing the same thing


k

[skimask]

I have two Pic16F88 ( did try a PIC16F628A once to see what would happen, how did you know, I dont think I mentioned that)

both circuits are running independently, Just the power supply is hooked up in parallel. Two circuits, two breadboards. two are doing the same thing


k

Ok, I'm back. I don't think you did specifically mention you had a 16F628A except that it was in one of the headers of one of your files somewhere.

So, you've got 2 16F88's, one will eventually be a transmitter (TXPIC), one will eventually be a receiver (RXPIC).

Right now, both PICs right now have 4 LEDS and a push button. When you fire it up, the leds do their little power up check, then when you push the button, the leds light up in sequence about once per second.

Release the button, the sequence stops until you hit the button again right?

If that's correct, now we'll connect the 2 PICs, define one as TXPIC and and as RXPIC.
On the TXPIC side:
Select a pin for serial output. I suggest RB2.

-------------------------------------
Add:
txout var portb.2
output txout
dataout var byte

near the beginning of your TXPIC program, next to the rest of the variable declarations
--------------------------------------

-------------------------------------
And add:
dataout = ledcount
serout txout, n2400, [ dataout ]
pause 100

on the line after 'ledcount = ledcount + 1', but before the 1st endif
---------------------------------------




On the RXPIC side:
Select a pin for serial input. I suggest RB5.

-------------------------------------
Add:
rxin var portb.5
input rxin
datain var byte

near the beginning of your RXPIC program, next to the rest of the variable declarations
--------------------------------------


------------------------------------
Change your RXPIC code to this (starting at mainloop):

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

if datain = 0 then 'all leds off
led1 = 0 : led2 = 0 : led3 = 0 : led4 = 0
endif

if datain = 1 then '1st led on
led1 = 1 : led2 = 0 : led3 = 0 : led4 = 0
endif

if datain = 2 then '2nd led on and so on and so on down the line....
led1 = 0 : led2 = 1 : led3 = 0 : led4 = 0
endif

if datain = 3 then
led1 = 0 : led2 = 0 : led3 = 1 : led4 = 0
endif

if datain = 4 then
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
----------------------------------------



Connect the PortB.2 pin on the TXPIC to the PortB.5 pin on the RXPIC, and write/burn the programs.
This should make the TXPIC and RXPIC act in their respective roles. You push a button on the TXPIC, it sends a code to the RXPIC. Both sets of LEDs on both PICs should match. If you don't send a code for 5 seconds the RXPIC will flash the LEDs 3 times, then turn them all off. The next time you press the button on the TXPIC, the same leds should be on for both the TXPIC and RXPIC.

Try it out, see what happens....
JDG

[lerameur]

Ok, I tried it, everything is fine, its working, The four leds flashes if no data from sending chip after 5 seconds, everything like you said.

ken

[skimask]

Ok, I tried it, everything is fine, its working, The four leds flashes if no data from sending chip after 5 seconds, everything like you said.

ken



GREAT!!! That's great news. I'm at work at the moment. I'll post a bit more in a few hours when I get some spare time.
JDG

[lerameur]

thanks alot, I wont be home till late again today so no hurry.
I just tried putting it through the RF module just to see what would happen, but it was not going through nicely.
Waiting for your next instruction.

k

[skimask]

thanks alot, I wont be home till late again today so no hurry.
I just tried putting it through the RF module just to see what would happen, but it was not going through nicely.
Waiting for your next instruction.

k

Now go back and read thru this whole thread and see if you can tell me why that data did not go thru the RF modules correctly. The correct answer is in the thread, young grasshopper.

Same thing. I probably won't get back to this for a few hours yet. But if you're around, we should be able to get it all working within about 4-5 thread posts.
JDG

[lerameur]

Well a big rule I learn not long ago is to use encoding techniques. and perhaps keep on sending the data a little while longer with serout command.

k

[skimask]

Well a big rule I learn not long ago is to use encoding techniques. and perhaps keep on sending the data a little while longer with serout command.

k


Ok, so as it stands, you have:
TXPIC: one button, 4 leds, serial out on PortB.2
RXPIC: 4 leds, serial in on PortB.5

All works well, data appears to transfer from TXPIC to RXPIC, LEDs match on both, then go out on RXPIC after 5 seconds without button push on TXPIC....

If that's all good....Read on...I'll be typing up the next post while you read this one....
JDG

[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