squelch doesn't seem the way to go


Closed Thread
Results 1 to 14 of 14
  1. #1

    Default squelch doesn't seem the way to go

    Thanks Melanie, for answering my last post this morning. Last night I read a post about using rf module and carrier detect back in 2004, I am playing with the Linx rxm-418lr-s and it has an rssi pin. The data output pin is always toggling. I have added the suggested squelch circuit and as you mentioned it cuts the range, but using the timeout with the squelch I can jump of serin2 onto my loop that would state basically no data received so "do this". I already take multiple samples to confirm what is being sent is what I want. For example, SERIN2 serialpinin,16468,100,loop1,[wait(254),a,b,c,d,e,f,g,h,i,j,k,l] ok, so if everything matches m=1 , moving on if a particular bit in A is 1 and m=1 then through a IF THEN ELSE statement a certain function get turned on but lets go back to serin2 now reading serinpinin if everything matched but that particular bit in A is a 0, then it gets turn off but what if your not sending any data? how would I be able to turn it off? I want this to be momentary, If I "SERIN2 serialpinin,16468,100,loop1,[wait(254),a,b,c,d,e,f,g,h,i,j,k,l] " it never jumps out because the data pin is constantly toggling, and if I take the timeout away it also just sits there waiting until the qualifier is satisfied or doomsday comes.

    Any Ideas?

    BTW I am using PBP 2.50a that I have purchase from BRUCE at Rentron
    Thank you

  2. #2
    Join Date
    May 2008
    Location
    Italy
    Posts
    825


    Did you find this post helpful? Yes | No

    Default

    If I understood correcly, this should help you:

    Code:
    Flag=0
    loop1:
    Flag=Flag+1
    If flag=>100 then goto Jumpout
    SERIN2 serialpinin,16468,100,loop1,[wait(254),a,b,c,d,e,f,g,h,i,j,k,l] 
    Jumpout:
    When flag count reach 100 * 100 ms = 10 secs. You can vary the total delay changing the 100 to the best value that fit your project.

    Al.
    Last edited by aratti; - 31st October 2008 at 17:06.

  3. #3


    Did you find this post helpful? Yes | No

    Default

    Thanks, I will give it a try and will post how it turned out.

  4. #4
    Join Date
    Aug 2008
    Posts
    20


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by tazntex View Post
    Thanks Melanie, for answering my last post this morning. Last night I read a post about using rf module and carrier detect back in 2004, I am playing with the Linx rxm-418lr-s and it has an rssi pin. The data output pin is always toggling. I have added the suggested squelch circuit and as you mentioned it cuts the range, but using the timeout with the squelch I can jump of serin2 onto my loop that would state basically no data received so "do this". I already take multiple samples to confirm what is being sent is what I want. For example, SERIN2 serialpinin,16468,100,loop1,[wait(254),a,b,c,d,e,f,g,h,i,j,k,l] ok, so if everything matches m=1 , moving on if a particular bit in A is 1 and m=1 then through a IF THEN ELSE statement a certain function get turned on but lets go back to serin2 now reading serinpinin if everything matched but that particular bit in A is a 0, then it gets turn off but what if your not sending any data? how would I be able to turn it off? I want this to be momentary, If I "SERIN2 serialpinin,16468,100,loop1,[wait(254),a,b,c,d,e,f,g,h,i,j,k,l] " it never jumps out because the data pin is constantly toggling, and if I take the timeout away it also just sits there waiting until the qualifier is satisfied or doomsday comes.

    Any Ideas?

    BTW I am using PBP 2.50a that I have purchase from BRUCE at Rentron
    Thank you
    you know if you use hardware UART your code will be much better in this case

    or you can use interrupt pin in case there is no hardware uart in your pic
    also it works
    i hope that will help

    regards

  5. #5


    Did you find this post helpful? Yes | No

    Default

    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

  6. #6
    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?

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

  8. #8


    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.

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

  10. #10
    Join Date
    Aug 2008
    Posts
    20


    Did you find this post helpful? Yes | No

    Default

    Quote Originally Posted by eng.alamin View Post
    you know if you use hardware UART your code will be much better in this case
    i already advised you to use pic's hardware UART in my first replay

    anyway any thing hard for first time don't be frustrated

    i don't know which pic that you use , so i assumed that you use pic16f877a

    here is small code will guide to use HARDWARE UART with pic basic pro

    Code:
    'small code for my friend 
    'eng.alamin
    '------------------------
    
    buffer var byte [10]  ' your stream buffers  
     x  var byte  ' for counter
    SPBRG = 12 ' 4800 clock must be 4MHz (sorry my friend but it's not inverted )
    
    RCSTA = %10010000  ' Enable RX
    TXSTA = %00100000  '    //    TX
    
    main
    
    low porta.0   '  disable your sqaulch circuit ;)
    gosub  lunix 
    gosub  pc
    
    lunix:
    if pir1.5 = 1 then     ' this is the wicked :)
    
    high porta.0    'Enable sqaulch circuit
    
    buffer[0]  = RCREG
    
    endif
    return
    
    
    pc :
    
    if PIR1.4 = 0 then pc   ' wait for loading 
    
    TXREG = buffer[0]     ' send data to your pc
    
    low porta.0   '  disable your sqaulch circuit ;)
    return

    this program will allow you to receive only one byte and transmit it
    edit and modify it according to your circuit to you have to work in loading all in coming data in buffer[x] by increasing x and adding some code line
    also you can invert logic by using NPN transistor
    ididn't compile this program i just worte it here so you may find dumb mistakes

    ---------

    regards
    Last edited by eng.alamin; - 2nd November 2008 at 10:24.

  11. #11
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898


    Did you find this post helpful? Yes | No

    Default

    Two other Kick-Start codes

    http://www.picbasic.co.uk/forum/show...1&postcount=11

    http://www.picbasic.co.uk/forum/show...42&postcount=2

    Having a on-board USART allow to deal with interrupts as well... really handy... sort of background process.

    Make friend with USART section of your PIC datasheet. Usually, there's a load of information. Have a look to the related registers... see what you can use in.

    Obviously, if you plan to use interrupts, Instant Interrupts or ASM are welcome... see... mandatory.
    Last edited by mister_e; - 2nd November 2008 at 11:06.
    Steve

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

  12. #12


    Did you find this post helpful? Yes | No

    Default

    Thanks again for all of the suggestions, I will go back to the datasheet and and read about uart, Thanks Eng.Alamin for the sample, well I am off to see what I can accomplish with this information.

    Thanks again to all.

    By the way I am using the 16F628A processor.

  13. #13
    Join Date
    Sep 2004
    Location
    montreal, canada
    Posts
    6,898


    Did you find this post helpful? Yes | No

    Default

    Nice, it also have the built-in voltage comparator, reducing the external hardware to a minimum.
    Steve

    It's not a bug, it's a random feature.
    There's no problem, only learning opportunities.

  14. #14


    Did you find this post helpful? Yes | No

    Default

    Although now I will focus on Uart, I been playing around this evening with my experiment after all I spent a lot of time on this and without etching a new pcb this would be sent to the scrapbox. I wanted to mention to Aratti that his sugggestion :
    Flag=0
    loop1:
    Flag=Flag+1
    If flag=>100 then goto Jumpout
    SERIN2 serialpinin,16468,100,loop1,[wait(254),a,b,c,d,e,f,g,h,i,j,k,l]
    Jumpout:
    At first it would not work for me and after all the questions I have asked on this forum one piece of advice stuck, that was when Skimask pointed out that "start thinking of PICs not as a teenager that can be told what to do ('cause that's what I see), but as a 6 year old that has to be told EXACTLY WHAT to do, WHEN to do it, HOW to do it, and to know yourself WHY he/she is doing what he/she is doing and HOW he/she is going to accomplish it". then Then light bulb lit in my head,I began to think how I could use Aratti's suggestion.
    Here is what I did:

    while flag < 1
    SERIN2 serpin,16468,[wait(254),a,b,c,d,e,]
    flag = flag + 1
    wend

    Now with the squelch wide open and the data pin toggling, Guess what??? It worked!!!!!!!!!!! keep in mind variable a-d are byte size and are all the same data and e is my check sum, the total sum of a-d, then I compare a-d if they match I multiply e * 4 and if it matches I count by 1 up to ten. If they don't match I set my counting variable1 to 0. If they match I set my counting variable2 to 1. If they match TEN times IN A ROW then my data is assumed good so I go to my next loop and turn on/off my functions, I seemed to have had some mutipath here in my metal barn so I just adjusted my counting variables to allow for errors. That kept my output on or off long enough to take some more samples. Now it works fast and seems very reliable. I've been doing flips etc. to make it act up and so far it hasn't missed anything that I know of, the outputs is on or off depending on if I was pressing the switch. Anyhow, I am waiting for the bubble to pop, LOL. As ya'll can see I don't like to give up. now that this is working, for now that is, I am off to UART. I'll be back with many more questions on that, I'm sure.

    Thanks everyone.
    Last edited by tazntex; - 3rd November 2008 at 03:00.

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