|
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.....
|
Did you try an external XTAL oscillator for the PIC ???My config Fuses are set as follows:
WDT_ON
PWRTC_ON
MCLR_OFF
BOD_ON
IESO_OFF
INT_OSC-NOCLKOUT
....
Alain
************************************************** ***********************
Why insist on using 32 Bits when you're not even able to deal with the first 8 ones ??? ehhhhhh ...
************************************************** ***********************
IF there is the word "Problem" in your question ...
certainly the answer is " RTFM " or " RTFDataSheet " !!!
*****************************************
|
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
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.Code:serin gpio.2,N2400,250,stop,["p34"],b
|
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.
Last edited by Bruce; - 14th November 2009 at 17:46.
Members who have read this thread : 0You do not have permission to view the list of names.
Posting Permissions
Bookmarks