creating signal bar for RF links Tx/Rx

I had the customchar ready but not sure how to implement it in software.

heard i've to constantly send data to the Rx and depends on the amount of data i received, It would be output as the signal strength.

I am not sure what your question is, or what you are trying to do exactly. It sounds like you want to use a custom character on the lcd to show a bar graph of signal strength.

Have you got any code that you are having trouble with ?

Have you tried searching the forum ? I found this http://forum.arduino.cc/index.php?topic=180678.msg1339198#msg1339198 which may help you, but I have not looked at it in detail.

UKHeliBob:
I am not sure what your question is, or what you are trying to do exactly. It sounds like you want to use a custom character on the lcd to show a bar graph of signal strength.

Have you got any code that you are having trouble with ?

Have you tried searching the forum ? I found this http://forum.arduino.cc/index.php?topic=180678.msg1339198#msg1339198 which may help you, but I have not looked at it in detail.

Thanks. Sorry for begin unclear.
I had written the software for the signal bar on lcd. However I do not have the signal strength of the Tx/Rx (315Mhz) hence I would need a code which provide such algorithm to determine the signal strength.

I would need a code which provide such algorithm to determine the signal strength

No. You need hardware capable of providing that data. Signal strength is something that the hardware reports, if you ask it nicely, and it knows it. Your cheap hardware doesn't know it.

PaulS:

I would need a code which provide such algorithm to determine the signal strength

No. You need hardware capable of providing that data. Signal strength is something that the hardware reports, if you ask it nicely, and it knows it. Your cheap hardware doesn't know it.

however i saw a demo set with such feature using this setup.

I asked the guy, he told me it has to do with constantly sending bytes and received bytes indicate the strength.

I asked the guy, he told me it has to do with constantly sending bytes and received bytes indicate the strength.

So, you need to do the same thing. What part of that is proving difficult?

beside this "signal strength" byte. I have to wait for user input (at transmitter) to send the command over.

I am thinking of using a header byte "^^^^^" + "user command". Usually it would send ^^^^^[BLANK] at a periodic time however upon receive command, it would combine the char arrays.

Reading would use the buf and hard code the first 5 to be sync bytes n the rest to be command. Is this workable?

pokkax: Is this workable?

Yes. Don't forget to send and verify a checksum on your packets so you can detect corrupted commands.

The technique you are describing is generally workable. WiFi does something similar. WiFi chipsets typically can measure signal strength (RSSI) directly, but they lack the hardware required to measure non-coherent interference, so they cannot measure signal-to-noise ratio (SNR), also known as "signal quality" in some circles. The WiFi chipset measures symbol reception errors and provides a synthetic measure of SNR based on the ratio of corrupted symbols to non-corrupted symbols. The thinking is that there is a known relationship (based on mathematics and lab testing) between the average SNR and the average corruption rate, so one can back-out the SNR if one knows the corruption rate.

This brings up a complication in your plan. You can measure "signal quality" by transmitting characters and detecting corruption. This would be as simple as transmitting a known bit-sequence, followed by its own XOR perhaps, as a rough checksum, and then mapping percent of received vs. corrupted packets to a "quality" metric. This is not true SNR, because true SNR is measured in decibels, and you don't have the hardware to do that, but you could easily map "quality" on a scale of 1-5 based on some subjective threshold.

The complication in your plan is that you cannot measure signal strength using this method. Consider: signal strength is at level 10; background noise is at level 2; SNR is therefore at 8 (10 - 2). Now the interfering device gets stronger and/or moves closer to the receiver. Now signal strength is still 10, but background noise is 7. SNR is, therefore, 3 (10 - 7). You will get a LOT more corrupted packets even though signal strength has not changed.

The question is whether you should care about this? If you are trying to align antennas, for example, then signal strength is what you care about. But if you are trying to report a more subjective, overall measure of channel "goodness", then SNR is actually what you want, and the "send characters and count corruption" method is entirely appropriate.

I've tried sending the message of {'^','^','^','^','^'} without vw_wait_tx(); //wait for tx to send

However transmission still drop upon going out of range, no data corruption sighted. was polling at 1000ms.

pokkax: I've tried sending the message of {'^','^','^','^','^'} without vw_wait_tx(); //wait for tx to send However transmission still drop upon going out of range, no data corruption sighted. was polling at 1000ms.

Without seeing your actual code, it's impossible to really give any more advice. We need to see your code so that we can analyze how you are detecting whether there are corrupted packets. It is unlikely that the radio link went straight from "perfectly good, no corruption," to, "no link at all," without passing through a period of lower SNR during which there was corruption. Something else must be going on, but without seeing your code, we can't know for sure.

Receiever

#include <VirtualWire.h>

char recMsg[9]={0,0,0,0,0,0,0,0,0};
char chkMsg[6]={0,0,0,0,0,0};
char cmdMsg[4]={0,0,0,0};

void setup(){
  Serial.begin(9600);
  vw_set_tx_pin(A5);
  vw_set_rx_pin(A4);
  vw_setup(2000); // Bits per sec   
  vw_rx_start();       // Start the receiver PLL running
}

void loop()
{
    uint8_t buf[VW_MAX_MESSAGE_LEN];
    uint8_t buflen = VW_MAX_MESSAGE_LEN;
    if (vw_get_message(buf, &buflen)) // Non-blocking
    {

      	// Message with a good checksum received, dump it.
	Serial.print("Got: ");
	
	for (i = 0; i < buflen; i++)
	{
            recMsg[i]=(char)buf[i];
	}
	Serial.println(recMsg);
         
        if ((recMsg[0]!=0)&&(recMsg[1]!=0)&&(recMsg[2]!=0)&&(recMsg[3]!=0)&&(recMsg[4]!=0)) // Header bits
       {
        chkMsg[0]=recMsg[0];
        chkMsg[1]=recMsg[1];
        chkMsg[2]=recMsg[2];
        chkMsg[3]=recMsg[3];
        chkMsg[4]=recMsg[4];
       } 
        if ((recMsg[5]!=0)&&(recMsg[6]!=0)&&(recMsg[7]!=0)){ // Check if command Msg is not empty
        k=1;
        cmdMsg[0]=recMsg[5];
        cmdMsg[1]=recMsg[6];
        cmdMsg[2]=recMsg[7];
        }
        for (j=0;j<9;j++){
           recMsg[j]=0;
        }
        if(k==1){ // Print when Command Msg is receieved. 
           if ((cmdMsg[0]!=0)&&(cmdMsg[1]!=0)&&(cmdMsg[2]!=0)){
           digitalWrite(6, HIGH);
           Serial.print("Cmd: ");
           Serial.println(cmdMsg);
           k=0;
           }
        }
     }  
        
}

Transmitter

#include <VirtualWire.h>

char keyIn[4]={0,0,0,0};// used for current input key
char oldkeyIn[4]={0,0,0,0};// remember previous key
char sendmsg[9]={'^','^','^','^','^',0,0,0,0};//final send msg
int z=0; 

void sendsigStr(){  
    
   if ((sendmsg[5]!=0)&&(sendmsg[6]!=0)&&(sendmsg[7]!=0)){
    vw_send((uint8_t *)sendmsg, strlen(sendmsg)); //send data over
    vw_wait_tx(); //wait for tx to send
    Serial.print("1");
    }
   else{
     vw_send((uint8_t *)sendmsg, strlen(sendmsg)); //send data over
    Serial.print("2");
   }
     Serial.print("Send Sig Code: ");
     Serial.println(sendmsg);
     sendmsg[5]=0;
     sendmsg[6]=0;
     sendmsg[7]=0;
}


void setup(){
  Serial.begin(9600);
   pinMode(A5, OUTPUT);
   pinMode(A4, INPUT);
   vw_set_tx_pin(A5);
   vw_set_rx_pin(A4);
   vw_setup(2000); // Bits per sec   
  
  timer.setInterval(1000, sendsigStr); // Send Signal @ 1s interval
}
void loop(){
  timer.run(); //run the timer
}

I monitor the sendMSG via serial monitor.

Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^1
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^3
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^
Got: ^^^^^

I sent 1, 2 ,3 as i go further away from the rx. [sent 1 to 9, only receive up to 3]

So, with "real" hardware RSSI, you have a comparatively long period where signal strength falls before you start getting symbol errors.

Without RSSI, you have no idea how strong the signal is until you start getting symbol errors. Then, the threshold between "a few" symbol errors and "total signal loss" is very small.

In order to get more synthesized signal strength resolution, you're going to need to find a way to detect more errors before you lose the signal integrity entirely. One strategy would be using FEC (Forward Error Correction), for example http://en.wikipedia.org/wiki/Hamming_code (there are many others). That means some percentage of your data could get corrupted, and you can detect that fact, yet still reconstruct your data without loss. This will give you a wider "margin" to detect a weak signal before it disappears entirely.

tylernt: Without RSSI, you have no idea how strong the signal is until you start getting symbol errors. Then, the threshold between "a few" symbol errors and "total signal loss" is very small.

I think tylernt is on to something here. If I am reading your code correctly, you don't detect individual symbol errors within a packet--only entire packets that are lost. So your sampling resolution on your signal strength measurement algorithm is 1 Hz. Quite low. Consider, for example, if you transmitted a 100-byte sequence, and its own XOR, every second. Then you could compare the two sequences and determine if an individual bit had changed. That's 800 samples per second. In an extreme case, you could simply transmit "sounding" data constantly, to maximize your sampling, and have a flag that differentiates between "real" data and "sounding" bytes.

But the problem is still going to be that the encoding/modulation method used by the radio may have a relatively narrow range of SNR at which it experiences corruption, before it drops out entirely. So you go from no corruption at all to no link at all in a relatively narrow distance. In the 802.11 (WiFi) standard, this is addressed by having many different encoding/modulation methods, or data rates, so if you are transmitting at, say, 54 Mbps, and the SNR drops to the point where that is not sustainable, you can drop down to, say, 36 Mbps, and operate at the lower SNR. This is known as Dynamic Rate Shifting. I am guessing that your 300 MHz radios don't support Dynamic Rate Shifting, though.

joshuabardwell: I am guessing that your 300 MHz radios don't support Dynamic Rate Shifting, though.

The cheap RF modules are pretty "dumb" and will key as often as you tell them to.

Looks like VirtualWire works up to 7kHz with an approximate range of 90m (I assume that's free space, i.e., not through walls and trees and with ideal antennas). Lower bit rates do increase range, so you could write sketch code that sets the bit rate based on the symbol error rate and you can derive a synthetic signal strength from that information.

tylernt:

joshuabardwell:
I am guessing that your 300 MHz radios don’t support Dynamic Rate Shifting, though.

The cheap RF modules are pretty “dumb” and will key as often as you tell them to.

I’m not sure we’re talking about the same thing. I’m talking about, e.g. switching from BPSK to QPSK or 64-QAM modulation, so as to require a higher or lower SNR to receive the signal without corruption.

joshuabardwell: I'm not sure we're talking about the same thing. I'm talking about, e.g. switching from BPSK to QPSK or 64-QAM modulation, so as to require a higher or lower SNR to receive the signal without corruption.

Oh I see. No, the cheap modules are either FSK (Frequency Shift keying) or OOK (On-Off Keying) and that's permanent in the hardware. But VirtualWire will let you change the 'speed' in vw_setup from about 7,000 down to some low value like maybe 300, with lower values improving the S/N ratio just by virtue of the fact that that the transmitter is keyed longer per bit to give the receiver more sample time to converge on weak signals.