 |
 |
| View previous topic :: View next topic |
| Author |
Message |
Humberto
Joined: 08 Sep 2003
Posts: 1215
Location: Buenos Aires, La Reina del Plata
|
|
 Posted: Fri Mar 03, 2006 9:06 pm |
 |
|
| Quote: |
So is an unbalanced signal a physical problem or is it a software problem?
|
A non zero DC component signal is an electrical problem from the RF transmitter
point of view. By the opposite, the software contribute to neutralize this unwanted efect
combining '0' and '1' in such a way that for any bits combination, the final sum of them
are the same. Namely this technique is called bi-phase modulation.
| Quote: |
So your saying that sending a binary 1 will offset the rx's output signal voltage and a 0 will decrease it?
|
Not exactly as you understand. A digital '1' is electrically a high level and a logic '0' a low level.
When some of them prevails over the other, creates an unwanted "DC creep" that change
the voltage biasing of the modulator, this offset can block or saturate it, this is the real problem.
There are others indirect effects related to the transmission of a signal with 0 DC component,
one of them is the need of less power required to transmit the same signal, thanks to the
SNR improvement, but this is out of the scope of this dicussion.
Humberto |
|
 |
daveaaa
Guest
|
|
| Posted: Fri Mar 17, 2006 3:34 am |
|
|
| I don't understand the part where the tx sends chars so that the rx can lock on. locking on?? |
|
|
Ttelmah
Guest
|
|
| Posted: Fri Mar 17, 2006 3:58 am |
|
|
Imagine, that there is an electrical circuit in the receiver, which behaves a bit like a 'float', sitting on the sea. It is coupled to a second float, sitting in a tube, with a small connection to the sea, and the difference between them, feeds a pen recorder. Now if little waves arrive, the pen bobbles up and down, as the 'sea' float rapidly moves, while the 'tube' float hardly responds, and the system 'sees' the waves. However if very slow waves arrive, both tubes respond nearly together, preventing these being reproduced. The 'little waves', correspond to an incoming signal with lots of rapid 1's, and 0's. The 'slow waves', correspond to a signal where there are lots of successive 1's or 0's. Now if a 'burst' of little waves arrives, the system once again settles into correct operation. This is the effect of a 'synch' signal, sent in front of a packet of data.
Best Wishes |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1908
|
|
| Posted: Fri Mar 17, 2006 11:59 am |
|
|
| daveaaa wrote: | | I don't understand the part where the tx sends chars so that the rx can lock on. locking on?? |
Do you mean the LAM (look at me) signal?
Think of it this way. If the transmitter is silent/off, the receiver will still receive things. It's just that what it receives will be crap. Noise, in other words.
A receiver will lock onto the most powerful signal in its frequency band and happily demodulate it. It has no idea whether a signal is valid or is just noise.
This noise then is passed to the receiver's PIC - in this case into its USART. The USART isn't a particularly bright device either - it can't tell if a signal came from a valid source (the transmitter) or if it is just noise. Furthermore, it doesn't care. Your software is what makes the difference.
Imagine that the receiving PIC's USART is getting noise. Perhaps the USART thought that perhaps it saw a valid start condition and is midway through trying to figure out what is what. Now the transmitter powers on and starts sending the LAM signal.
The reason that the LAM is needed is simply to help the receiver's USART to synchronize. It may only require one character to synch the receiver, but it's unlikely. In order to ensure (100%) that the receiver synchs, you send many characters in the LAM signal.
One last thing: I read somewhere that the LAM (synch) signal shouldn't be entirely alternating 1's and 0's because most USARTs have difficulty in distinguishing the start and stop bits in such a case. I know that others have been stressing the importance of the signal being properly balanced - roughly equal numbers of 1's and 0's. I agree with their reasoning, but for all of the radio modules I've ever used, balancing the signal was unnecessary. Balancing only becomes an issue with certain types of receivers, and then only if you're sending a very long data sequence. If you're sending short bursts, balancing isn't required (or I should say that I've never required it).
Last edited by newguy on Sun Mar 19, 2006 1:25 am; edited 1 time in total |
|
|
languer
Joined: 09 Jan 2004
Posts: 144
Location: USA
|
| Some corrections required |
| Posted: Fri Mar 17, 2006 1:09 pm |
|
|
I feel I must correct some statements made. Please note that I am only doing this since I've heard some similar statements in many other circles and feel that not correcting them would be a disservice.
| Quote: | | A non zero DC component signal is an electrical problem from the RF transmitter point of view. |
A well designed transmitter should not care weather it's on or off, the drivers are usually fairly robust to handle these type of swings (although for complex modulation schemes,such as QAM, you try to avoid this since it will generate spectrum regrowth). The receiver on the other hand does care about this because the simplest data-slicers (i.e. envelope detectors) consist of some sort of RC circuit which can not change states in an instant (this is where DC balanced is required - and only for AM/ASK types modulation).
| Quote: | | There are others indirect effects related to the transmission of a signal with 0 DC component, one of them is the need of less power required to transmit the same signal, thanks to the SNR improvement, but this is out of the scope of this discussion. |
Actually a balanced signal will waste more power and more bandwidth as it requires twice as many bytes and the twice as many on-states. The peak-power is lower because it's spread out over a larger bandwidth, but the total power is twice as much. |
|
|
david90
Joined: 25 Feb 2006
Posts: 23
|
|
| Posted: Sat Mar 18, 2006 11:56 pm |
|
|
| So the receiver is programmed to look for the LAMs and when it sees it, it starts to decode the transmission after that? |
|
|
arunb
Joined: 08 Sep 2003
Posts: 492
Location: India
|
| RE: |
| Posted: Sun Mar 19, 2006 12:32 am |
|
|
Hi,
Is this problem there in wired RS 232 ??
thanks
arunb |
|
|
newguy
Joined: 24 Jun 2004
Posts: 1908
|
|
| Posted: Sun Mar 19, 2006 1:24 am |
|
|
| david90 wrote: | | So the receiver is programmed to look for the LAMs and when it sees it, it starts to decode the transmission after that? |
No. The receiver doesn't look for the LAM signal. The LAM signal's only purpose is to sync the receiver's USART. You don't look for the LAM signal. Examine the code posted earlier. The LAM is 0xBABEFACE. The receiver doesn't look for that. It looks, in this case, for "Dave ".
The only purpose of the LAM is to get the receiver's attention (sync its USART). You "unlock" the receiver with the access code (in this case, "Dave "). If the access code is good, anything after that is valid data.
| arunb wrote: | | Is this problem there in wired RS 232 ?? |
No. Although if you have more than two PICs connected, you'd use the idea of the access code to pass individualized messages amongst them.
Last edited by newguy on Sun Mar 19, 2006 11:27 am; edited 1 time in total |
|
|
camie
Guest
|
| Very good programming |
| Posted: Sun Mar 19, 2006 4:34 am |
|
|
This is very advance programming..
I try to understand it. Because I want to apply to my project..
Can anyone help me to solve my problem..
Please check the latest topic Problem in RF-PIC16f876A -camie
Please help me la.... |
|
|
soundsk
Joined: 10 May 2008
Posts: 6
|
|
| Posted: Thu May 22, 2008 3:29 pm |
|
|
Hi,
The code in this thread really helped me to understand how to use the wireless modules ER400TRS.
But since i am a bit new to CCS, i am having some troubles adapting it to my needs.
The code i am using currently sort of works. The receiver looks for the string "Temp" sent by the transmitter, and displays the defined number of characters after the detection of that string. But since i am sending a float value and receiving characters, the receiver outputs strange characters and in the middle of it the temperature, but in integer format.
The problem is that i am monitoring a temperature value in float format, with accuracy of 1/2 degree and i am a bit confused on how to pass it to the receiver.
Do i send it as characters or is there any way to send it as a float value? The receiver will display this temp on an LCD and later on store it to EEPROM or MMC or even send it over USB.
The code i am currently using is the following:
Transmitter - PIC16F877:
| Code: | #include "lm35.h"
#include <lcdts.c>
#define WireTX PIN_C6
#define WireRX PIN_C7
#use rs232(baud=19200, xmit=WireTX, rcv=WireRX, ERRORS, STREAM=Wireless)
void main()
{
int16 temp, press, press2,sinal;
float temp1, press1,sinal1;
setup_adc_ports(AN0);
setup_adc(ADC_CLOCK_DIV_64);
setup_psp(PSP_DISABLED);
setup_spi(FALSE);
setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
setup_timer_1(T1_INTERNAL|T1_DIV_BY_1);
setup_timer_2(T2_DISABLED,0,1);
setup_comparator(NC_NC_NC_NC);
setup_vref(FALSE);
lcd_init();
delay_ms(10);
lcd_putc("\fA inicializar... ");
while(1)
{
setup_adc_ports(AN0);
set_adc_channel(0);
delay_ms(20);
temp = read_adc();
temp1 = (temp*2.5)*2/10;
delay_ms(100);
setup_adc_ports(AN0_AN1_AN4_VREF_VREF);
set_adc_channel(1);
delay_ms(20);
press=read_adc();
press1=(press*2)*.977;
press2=press1;
delay_ms(20);
//setup_adc_ports(ALL_ANALOG);
//set_adc_channel(5);
//delay_ms(20);
//sinal=read_adc();
//press1=press*5.57;
//sinal1 = (sinal*2.5)/10;
lcd_gotoxy(1,1);
printf(lcd_putc, "\fTemp : %3.1f %cC ", temp1,223);
printf(lcd_putc, "\nPressao: %Lu ", press2);
//printf(lcd_putc, "\nSinal : %3.1f",sinal1);
fprintf(Wireless, "%c", 0xBA); // LAM - something for the RX's USART to "lock onto"
fprintf(Wireless, "%c", 0xBE); // LAM - something for the RX's USART to "lock onto"
fprintf(Wireless, "%c", 0xFA); // LAM - something for the RX's USART to "lock onto"
fprintf(Wireless, "%c", 0xCE); // LAM - something for the RX's USART to "lock onto"
fprintf(Wireless,"Temp %3.1f \r", temp1);
delay_ms(1000);
}
}
|
And the receiver code - PIC18F4550:
| Code: |
#include "teste1.h"
#include <lcd420ts.c>
#define WireTX PIN_C6
#define WireRX PIN_C7
#use rs232(baud=19200, xmit=WireTX, rcv=WireRX, ERRORS, STREAM=Wireless)
#define RX_BUFFER_SIZE 80
#define TX_BUFFER_SIZE 80
int8 rx_wr_index = 0, tx_rd_index = 0, tx_wr_index = 0, tx_counter = 0, received = 0;
int8 lock_state = 0, rxd, i, valid_data_count;
unsigned int8 rx_buffer[RX_BUFFER_SIZE + 1], tx_buffer[TX_BUFFER_SIZE + 1];
int1 data_avail = FALSE, got_id = FALSE;
#int_RDA
void RDA_isr(void) {
rx_buffer[rx_wr_index] = getc();
rxd = rx_buffer[rx_wr_index]; // this just makes it easier typing-wise later on
rx_wr_index++;
if (rx_wr_index > RX_BUFFER_SIZE) {
rx_wr_index = 0;
}
// now look for unique ID: "Dave "
if (rxd == 'T' && lock_state == 0) {
lock_state++;
}
else if (rxd == 'e' && lock_state == 1) {
lock_state++;
}
else if (rxd == 'm' && lock_state == 2) {
lock_state++;
}
else if (rxd == 'p' && lock_state == 3) {
lock_state++;
}
else if (rxd == ' ' && lock_state == 4) { // got the entire string "Dave ", in that order
lock_state = 0; // reset our "combination lock"
got_id = TRUE;
valid_data_count = 0xff; // get ready to count the number of data bytes - we know we have to expect 5 (Rocks)
// also going to reset the buffer write index back to 0, so that I know where my valid data will be
rx_wr_index = 0;
}
else { // we didn't receive "Dave ", so reset the lock back to the beginning
lock_state = 0;
}
if (got_id && ++valid_data_count == 5) {
data_avail = TRUE;
got_id = FALSE;
}
}
#int_TBE
void TBE_isr(void) {
if (tx_counter != 0) {
putc(tx_buffer[tx_rd_index]);
if (++tx_rd_index > TX_BUFFER_SIZE) {
tx_rd_index = 0;
}
tx_counter--;
if (tx_counter == 0) {
disable_interrupts(INT_TBE);
}
}
}
void bputc(int c) {
int restart = 0;
while (tx_counter > (TX_BUFFER_SIZE - 1));
if (tx_counter == 0) {
restart = 1;
}
tx_buffer[tx_wr_index++] = c;
if (tx_wr_index > TX_BUFFER_SIZE) {
tx_wr_index = 0;
}
tx_counter++;
if (restart == 1) {
enable_interrupts(INT_TBE);
}
}
void main() {
char cmd, teste[19];
setup_adc_ports(NO_ANALOGS);
setup_adc(ADC_OFF);
setup_psp(PSP_DISABLED);
setup_spi(FALSE);
setup_wdt(WDT_ON);
setup_timer_0(RTCC_INTERNAL|RTCC_OFF|RTCC_8_bit);
setup_timer_1(T1_DISABLED);
setup_timer_2(T2_DISABLED,0,1);
setup_timer_3(T3_DISABLED|T3_DIV_BY_1);
enable_interrupts(INT_RDA);
//enable_interrupts(INT_TBE);
enable_interrupts(global);
delay_ms(50);
//fprintf(Wireless,"ER_CMD#R1");
//delay_ms(20);
//printf("ER_CMD#P8");
//delay_ms(20);
//printf("ER_CMD#C2");
lcd_init();
delay_ms(50);
lcd_putc("\fIniciando...");
set_tris_e(0);
delay_ms(500);
lcd_putc("\fFunciona...\n");
while (TRUE) {
restart_wdt();
if (data_avail) {
data_avail = FALSE;
lcd_putc("\fDados:\n");
for (i = 0; i < 5; i++) {
printf(lcd_putc,"%c",rx_buffer[i]);
}
}
}
}
|
So can anybody help me? Do i need to change how it is sent, how it is received or both?
Thank you very much!
Best Regards! |
|
|
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
