Serout problem

[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