A very very very strange problem-Urgent help needed please!

[Macgman2000]

Be careful that the module you select has a data in = data out feature. Some low cost modules need to have a "balanced" data stream in order to work well.

One of the symptoms is reduced range, the closer you are the more likely the data makes it through the demod stage. The further out you go the more you get DC offsets that creep up and cause the demod to hold states longer causing bit distortion. You should be able to see this on a scope.....latch the tx in continuous transmit at 30m and look at the output of the RX.

Nick

[FromTheCockpit]

Be careful that the module you select has a data in = data out feature. Some low cost modules need to have a "balanced" data stream in order to work well.

One of the symptoms is reduced range, the closer you are the more likely the data makes it through the demod stage. The further out you go the more you get DC offsets that creep up and cause the demod to hold states longer causing bit distortion. You should be able to see this on a scope.....latch the tx in continuous transmit at 30m and look at the output of the RX.

Nick

Thanks, Reading your post I am assuming that if I make the following changes to the code, it will help to balance the data stream and allow sufficient time to the receiver to process previous data before new one is thrown in:

receiver code:
main:
serin gpio.2,N2400,250,stop,["p34"],b
if b=24 then gpio.1=1
if b=54 then gpio.0=1
goto main

stop:
gpio.1=0
gpio.0=0
goto main

Transmitter code
main:
if gpio.0=1 then
serout gpio.5,N2400,["p34",54] : pause 50 : endif
if gpio.1=1 then
serout gpio.5,N2400,["p34",24] : pause 50 : endif

Have I understood the point right?

[Macgman2000]

Actually if instead of sending raw data you send manchester encoded data. Another trick is to send a 10101010 preamble then data then pause for 10ms before sending again. I have a few chinese made ON/OFF keying RX/TX modules and they work if you talk to them correctly, what that usually means is not necessarily how Serin/serout sends data.

If this is a one off project, invest in FSK TX/RX like Linx technologies. If mass production, then it is worth the time to find out what mods in the data format will give you what you want.

Nick

[FromTheCockpit]

So, my findings say that it's not the receiver and transmitter pair at fault. I have tested the same circuit with PT encoder and decoder and IT WORKS LIKE A CHARM.

Problem is with my PIC.
But I am going bonkers figuring it out. Can one of the gurus here please have a deeper look what might be the cause of the problem. I also tried manchester encoding on the data. Same results. PIC hangs!

Please help.....

[Acetronics2]

My config Fuses are set as follows:
WDT_ON
PWRTC_ON
MCLR_OFF
BOD_ON
IESO_OFF
INT_OSC-NOCLKOUT

Did you try an external XTAL oscillator for the PIC ???

....

Alain

[FromTheCockpit]

I have not tried it yet. But I will soon now and will let you know if this is causing the problem.

By the way the interesting thing is that the PIC HANGS which seems to have less relation with the oscillator as in the statement I am using

serin gpio.2,N2400,250,stop,["p34"],b

It should put the relay pin down after 250 ms. And also I think that if oscillator is the problem it should just malfunction and not start behaving properly as soon as you enter in a defined area close to the Receiver.

[Melanie]

You forgot one thing with the SERIN statement...

It will time-out ONLY when the pin stops seeing Data (by Data I mean ANY High/Low transition - valid or not) and remains in the CORRECT IDLE state for 250mS... if the signal is from a Radio Receiver the pin could be fluctuating through random noise... and it may also be idling in the WRONG state... all things covered in other threads earlier on the forum. Stick a scope on the PIC pin and see what you've got - it may not be such a clean signal which you expect.

As you get closer with your Transmitter, the signal-to-noise ratio improves to the point where you are actually getting a good clean signal out of your Receiver. Your Tx/Rx pair may well be specified for 100 metres... that means the Receiver will hear the Transmitter at 100 metres - it DOESN'T mean you'll get HIGH SPEED RELIABLE SERIAL COMMUNICATIONS at 100 metres without additional filtering and conditioning circuitry.

I refer you to my post at the start of the thread...

If life was so simple just keying a carrier 2400 times (or more) a second, manufacturers wouldn't have bothered spending millions developing FSK (and other) endoders/decoders, etc.