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

Hi, I am having RF modules operating a switch only when button is pressed AND as long as the button is pressed on the Tx. I am using 12F635.
Problem is that the PIC LATCHES when I go beyond lets say 5 meters. When I come near and press the second button on the Tx the latch opens and it starts behaving fine.
RF Modules have a range of greater than 100 Meters. I can't figure out WHY is this happening?
I need urgent help on this please. Thanks

Code:

---

main:
Receiver code
serin gpio.2,N2400,100,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 5 : low gpio.0 :  endif
if gpio.1=1 then
serout gpio.5,N2400,["p34",24] : pause 5 : low gpio.1 : endif

---

These are actually Data certified 2400 Baud Transmitter/Receiver Modules, or they're just plain junk Tx/Rx modules whereby you are simply keying the carrier at 2400 Baud and hoping that the receiver will attempt to replicate what's happening at the Transmitter once the signal dips into noise and the other rubbish floating about?

Hi,

Some of our R/C sets do not dare to work when too close to the transmitter ...

Saturated HF input stage of the receiver ... locked decoder.

= oversensitive devices ...

Low priced receivers with a "simply engineered AGC Stage ...

Alain

PS:

Quote:

---

Urgent help needed please

---

I do not know why, but these words always make me laugh ... like the word " problem " ...

If your transmitter switch pins are inputs, and a switch press applies Vcc to a pin, why are
you flipping these pins to outputs after a switch press and setting them at ground?

Quote:

---

Originally Posted by Melanie

These are actually Data certified 2400 Baud Transmitter/Receiver Modules, or they're just plain junk Tx/Rx modules whereby you are simply keying the carrier at 2400 Baud and hoping that the receiver will attempt to replicate what's happening at the Transmitter once the signal dips into noise and the other rubbish floating about?

---

They are just normal Rx/Tx with stated range upto 150 Meters. They actually work very well upto 100 Meters when I use it for toggling pins high or low (my other kind of switch- Tx button pressed once, receiver switches on somthing, Tx switch pressed again - receiver switches it off) at the receiver. But dont know why the receiver PIC latches up in this kind I am making where it should only stay on untill TX is pressed.

Quote:

---

Originally Posted by Bruce

If your transmitter switch pins are inputs, and a switch press applies Vcc to a pin, why are
you flipping these pins to outputs after a switch press and setting them at ground?

---

Point noted, Thanks. I will remove "low..." statements from the code.

Alain: Do you mean problem is with RF Link? as they do work fine as per my post above.

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

and other configuration is:
intcon=0
cmcon0=7
TRISIO=%001100
GPIO=0

I have checked that with my toggling switch, once you go out of range receiver PIC does not respond as soon as you walk within range it starts working fine.

BUT, with this momentary design, after the PIC latches I checked the voltage on Rx pin and it is fluctuating as other signals are in the air as well. I also found out that once PIC latches there could be one sure shot way of making it work again, which is power reset and the other not so sure shot way is press the second button on the transmitter which sends a different code. BUT again this hangs the PIC as soon as you go few meters away.

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

Quote:

---

Originally Posted by 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

---

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?

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

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

Quote:

---

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

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

Code:

---

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.

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.

Point noted.
But still wondering why PT encoder & decoders work fine. End of the day they are also transmitting / receiving the data with same receiver and transmitter pair used.

Is there any option to make changes to the code to get a reliable output?

And the PT encoders/decoders do what exactly?... they take a carrier and MODULATE it with a PWM ENCODED signal at one end, and then decode it at the other end. They DON'T try to send RAW DATA. Actually the PT encoders DON'T modulate the carrier themselves, they provide the Tx Module with an equivallent 'AUDIO' signal which is then modulated within the AM or FM Transmitter Module. At the receiver end, the receiver, after demodulation, sends this 'Audio' component to the PT Decoder which then decodes the signal.

The usual junk Tx/Rx Modules are NOT the wireless equivallents of a piece of wire linking two ends of a Serial Link (like RS232).

Any Radio Ham will tell you (and there are quite a few on this forum) that you can't send high-speed RTTY (eg your Serial Data) using CW (A1A class modulation). If it was Audio (tone) Modulated (A2A) you'd have a better chance (because you obviously have either an AM or an FM Tx/Rx pair) and at least you'd be using the integral modulator - the way the designers of the modules intended them to be used. If you want range AND reliability, then for example you would pick say an F1 or F2 Modulation type.

Some Tx/Rx Modules have integral DATA MODULATORS with integral ENCODERS/DECODERS and can guarantee DATA-IN/DATA-OUT. Most modules haven't! They rely on YOU providing a signal (usually an AUDIO Tone or Tones) which are then modulated onto a carrier by either AM or FM (with FM having superior noise rejection - which is why you pay more for those). Now the PT encoders usually provide a 1kHz signal (give or take) which then varies depending on what information it conveys... note that 1kHz signal being the equivallent of your Audio Tone which is then MODULATED onto your carrier.

If you are just keying a carrier (which is what you are doing), all you are doing at the receiver end is the equivallent of switching your squelch control (a crude anomaly but will suffice for this explaination). Great. It works. But in doing this you have just sacrificed 95% of your range.

If you're up for a test, try the two .hex files attached. One for an encoder, and one for a
decoder.

Both files have been compiled for a 12F635. Schematics for connections are in the screen
captures. If your RF modules can handle 4800bps, connect the baud pins to Vcc.

For 2400bps connect the baud pins to ground.

D0-D3 on the decoder are momentary, and should stay high for as long as a button on the
encoder is held at Vcc. Let me know what kind of range you get.

Quote:

---

Originally Posted by Bruce

If you're up for a test, try the two .hex files attached. One for an encoder, and one for a decoder.

........... Let me know what kind of range you get.

---

Sure Bruce, I will let you know as soon as possible. Thanks.

Hi, Bruce. The PICs with these hex files are not working. So I put my setup on a breadboard and by using a piece of wire between GP.5 of both. I do see a voltage pulse on GP.5(Tx) of the Transmitter but no response from the receiver. I used 2400 Baud. I await your feedback.

Can you post photos of what you have assembled & indicate which RF modules, power supply, etc you're using?

Here is the photo of my bread-board setup. The LED to right of the 1uF Cap is for power indication.
I don't have any technical details about these modules apart from that they are ASK based and are for short range RF applications. I have tested other simpler codes with them and PT enc/dec as well, everything works perfectly. They don't have any sort of marking on them as well so I can search the internet.

My power supply if from 7805. Power supply is ok as I keep testing small projects every other day.

Made a slight adjustment. These should work on pretty much any RF modules.
Let me know if this version works for you.

P.S. It's really hard to tell with that blurry yellow photo, but I would be a tad hesitant on lighting the LED on D3. It looks like the LED is wired direct to gnd on the cathode end?

Did the new code work?

Hi Bruce, sorry I am out of town right now, will be back in 4 days. Will surely update you soon. Thanks