squelch doesn't seem the way to go


Closed Thread
Results 1 to 14 of 14

Hybrid View

  1. #1
    Join Date
    Aug 2008
    Posts
    20


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by tazntex View Post
    Thanks for both suggestion, the task I am trying to accomplish if I receive valid data while I have the switch on my output comes on, but when the switch is off, if no valid data is received turn the output off. I have the squelch circuit installed and when I adjust it up the code does what I want, but if I just break the squelch then it stays at serin2 listening for the qualifier. I did try the flag idea but with the output from the rf module toggling serin2 serpinin just stays there waiting. Here is the link to the datasheet if anyone might be interested: http://linxtechnologies.com/Document...Data_Guide.pdf

    Thanks again
    can you post your schematic iwant to know how did connect RX , pic and squelch circuit and also post your code
    because what i understand is you don't want PIC stay in SERIN2 command while you stop transmitting you do want it to process other operation right?

  2. #2
    Join Date
    Jul 2003
    Posts
    2,358


    Did you find this post helpful? Yes | No

    Default

    I'm really going to upset folks here...

    No professional would consider the use of SERIN or SERIN2 etc.

    It is designed to give you a very simple and easy way of accessing what is quite a complex activity. Because it is so easy to use, everyone uses it.

    There is a heap of down-side to all this ease of use... if you have crappy comms for example, it can't handle it. If the input toggles (for whatever reason eg noise), again it can't handle it.

    The proper way is to ditch all PBP's serial commands (including HSERIN), and access the PICs UART directly - BYTE AT A TIME and save it in a buffer. You then make a decision YOURSELF, parsing the buffer, whether the bytes that have just arrived are valid or just junk. You're not stuck in a routine WAITing for qualifiers that never come, or hanging about due to noise toggling your pin.

    Let me also remind you all, that there is a BIG difference between something like a Remote Control application, where pushing a button repeats the same byte(s) over and over again for as long as the button is depressed on the Transmitter (giving the receiver the chance to catch the transmitted packet multiple times, validate what is being sent and act on it), and a Data Communications Application where differring non-repeating data of variable length and complexity could be sent. In this instance, you must include some kind of error correction in your transmission protocol, because you WILL receive bad data and will need to know how to deal with it at the extreme range of your link.

    There is NO simple, painless way of approaching this with SERIN, HSERIN etc. There is a lot of functionality in those commands, but they limit you to using a 100% reliable link. You replace that 100% reliable wired connection with something that is WIRELESS (be it RF, or IR or whatever), then you introduce a whole heap of parameters (noise, signal degredation, signal loss etc) which those PBP commands were never designed to handle.

    You are already starting to discover this for yourself... if you eliminate the noise by turning up the squelch to increase reliability, then it is done at expense of range.

    You now have to turn to other techniques... if you insist on using those PBP commands, then you must improve the reliability in your hardware (increase power-output at the transmitter, use different modulation techniques, hardware manchester or similar encoding etc, and likewise at the receiving end have a receiver with better signal/noise characteristics, hardware manchester decoding etc).

  3. #3


    Did you find this post helpful? Yes | No

    Default

    Thanks Melanie for the advice, I've been looking at other posts like http://www.picbasic.co.uk/forum/showthread.php?t=9567 to understand how to use UART. In your reply you mentioned "something like a Remote Control application, where pushing a button repeats the same byte(s) over and over again for as long as the button is depressed on the Transmitter (giving the receiver the chance to catch the transmitted packet multiple times, validate what is being sent and act on it)" which is exactly what I am trying to do. Is there any way to get "SERIN2 serpin,16468,100,loop,[wait(254),a,b,c,d,e,f,g,h,i,j,l]" to time out and jump back to the program if the qualifier does not arrive? The only reason I continue to ask is I have already etched my pcb and from what I understand from the datasheet RB1/RX/DT and RB2/TX/CK pins are the inputs, and my portA.0 is my serial input on my pcb. I thought I was doing real good when I layed out my board and everthing was working great until I opened the squelch. It seems after all the searching for tips on remote control everyone was using SERIN2. This rf module does not have a Carrier Detect pin and I thought about checking into RadioMetrix modules although either way I would have to make a new pcb. I saw a simple idea for a diode detector using a diode with the anode coming from the data pin on the rf module, a pullup resistor from the cathode, a capacitor from the cathode to ground and the cathode being data out. Bad idea?


    Thanks again for the replies.

  4. #4
    Join Date
    Aug 2006
    Location
    Look, behind you.
    Posts
    2,818


    Did you find this post helpful? Yes | No

    Default Amem . . . Mistress, please . . .

    >I'm really going to upset folks here...
    <b> We might surprise you </b>

    >No professional would consider the use of SERIN or SERIN2 etc.

    It is designed to give you a very simple and easy way of accessing what is quite a complex activity. Because it is so easy to use, everyone uses it.

    <b> Exactly</b>

    >There is a heap of down-side to all this ease of use... if you have crappy comms for example, it can't handle it. If the input toggles (for whatever reason eg noise), again it can't handle it.

    <b>Agree !</b>

    >The proper way is to ditch all PBP's serial commands (including HSERIN), and access the PICs UART directly - BYTE AT A TIME and save it in a buffer. You then make a decision YOURSELF, parsing the buffer, whether the bytes that have just arrived are valid or just junk. You're not stuck in a routine WAITing for qualifiers that never come, or hanging about due to noise toggling your pin.

    <b>Are you feeling charitable? That's light years ahead of the average poster here. Teach me to fish, I'm all outta beer . . . </b>

    >Let me also remind you all, that there is a BIG difference between something like a Remote Control application, where pushing a button repeats the same byte(s) over and over again for as long as the button is depressed on the Transmitter (giving the receiver the chance to catch the transmitted packet multiple times, validate what is being sent and act on it), and a Data Communications Application where differing non-repeating data of variable length and complexity could be sent. In this instance, you must include some kind of error correction in your transmission protocol, because you WILL receive bad data and will need to know how to deal with it at the extreme range of your link.

    <b> Argument well founded in fact !</b>

    >There is NO simple, painless way of approaching this with SERIN, HSERIN etc. There is a lot of functionality in those commands, but they limit you to using a 100% reliable link. You replace that 100% reliable wired connection with something that is WIRELESS (be it RF, or IR or whatever), then you introduce a whole heap of parameters (noise, signal degredation, signal loss etc) which those PBP commands were never designed to handle.

    You are already starting to discover this for yourself... if you eliminate the noise by turning up the squelch to increase reliability, then it is done at expense of range.

    You now have to turn to other techniques... if you insist on using those PBP commands, then you must improve the reliability in your hardware (increase power-output at the transmitter, use different modulation techniques, hardware manchester or similar encoding etc, and likewise at the receiving end have a receiver with better signal/noise characteristics, hardware manchester decoding etc).

    <b> Thank You Melanie !
    If you do not believe in MAGIC, Consider how currency has value simply by printing it, and is then traded for real assets.
    .
    Gold is the money of kings, silver is the money of gentlemen, barter is the money of peasants - but debt is the money of slaves
    .
    There simply is no "Happy Spam" If you do it you will disappear from this forum.

Similar Threads

  1. RF Transmitter/Reciver
    By Fredrick in forum General
    Replies: 75
    Last Post: - 4th May 2008, 01:19
  2. SERIN Timeout
    By George in forum mel PIC BASIC Pro
    Replies: 15
    Last Post: - 23rd March 2007, 15:06

Members who have read this thread : 0

You do not have permission to view the list of names.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts