squelch doesn't seem the way to go

[eng.alamin]

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

[tazntex]

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

[eng.alamin]

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?

[Melanie]

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

[tazntex]

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.

[Archangel]

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

[eng.alamin]

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

'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

[mister_e]

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.

[tazntex]

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.

[mister_e]

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

[tazntex]

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.