433 MHz wireless unit does not sync when using UART to send

Go To Last Post
16 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hi Guys

 

Ive been working on a project whereby i need to send an char via a 433MHz transmitter to a receiver. The idea is to receive the char and then display it on a screen. I am currently a bit puzzled as to why my receiver goes out of sync as soon as i start sending data using the UART of my avr micro controller.

 

My Setup is as follows:

 

Atmega328 running at 16MHz powered by 5v on a breadboard.

 

433MHz transmitter connected to 5v and ground with data pin connected to PIND1 (TXD) as well as my logic analyzer. The transmitter has a wire attached to it as an antenna of +-13cm (+-5inches)

 

433MHz receiver on a separate breadboard powered by the same power supply as the transmitter. The Receiver is connected to 5v and ground with the data pin connected to my logic analyzer.

 

 

Code

 

My code sets up the UART of the microcontroller and then toggles the data pin of the transmitter multiple times to get the receiver listening. then it goes low for some time and then transmits the number 85.

 

/*
 * _433_MHz_usart_test.c
 *
 * Created: 11/1/2016 7:44:32 AM
 *  Author: Atticus
 */ 


#define F_CPU 16000000UL


#include <avr/io.h>
#include <util/delay.h>
#include <avr/interrupt.h>



//*************************************************************************************************************//
//*************************************************BAUD RATE***************************************************//
//
//
//BAUD  = Fosc/(16(UBRRn + 1))
//UBRRn = (Fosc/(16*BAUD)) - 1
#define BAUD 1000
#define MYUBRR F_CPU/16/BAUD-1
//
//
//*************************************************BAUD RATE***************************************************//
//*************************************************************************************************************//

#define delay 5000
#define delay2 5000


void usart_init(unsigned int ubrr){
	
	
	//DISABLE GLOBAL INTERUPTS
	cli();
	
	//SET BAUD RATE
	UBRR0H = (unsigned char)(ubrr>>8);
	UBRR0L = (unsigned char)ubrr;
	
	//ENABLE TRANSMITTER AND RECIEVER
	UCSR0B |= (1<<TXEN0);
	UCSR0B |= (1<<RXEN0);
	
	//SET FRAME RATE
	UCSR0C |= (1<<USBS0);
	//8 BIT WORD
	UCSR0C |= (1<<UCSZ00);
	UCSR0C |= (1<<UCSZ01);
	//2 STOP BIT
	UCSR0C |= (1<<USBS0);
	
	//1 STOP BIT
	//UCSR0C &= ~(1<<USBS0);
	
	//ENABLE USART
	UCSR0B |= (1<<TXCIE0);
	
	//ENABLE GLOBAL INTERUPTS
	sei();
	
}


void usart_transmit(unsigned char data){
	
	/* Wait for empty transmit buffer */
	while (!( UCSR0A & (1<<UDRE0))){};
	/* Put data into buffer, sends the data */
	UDR0 = data;
}





int main(void)
{
	
	usart_init(MYUBRR);
	DDRD |= (1<<PIND1);
	
	
    while(1)
    {
		
		
		//synchronise
		
		//disable transmitter to toggle pin
		UCSR0B &= ~(1<<TXEN0);
		


                //toggle pin fast 20 times to synchronize receiver
		for (char count = 0;count< 21;count++){
			
			PORTD ^= (1<<PIND1);
                        //delay
			for (long counter = 0;counter < 50000;counter++);
		
		}
		


		PORTD |= (1<<PIND1);
                //delay
		for (long counter = 0;counter < 50000;counter++);


		//enable tranmitter again for TX
		UCSR0B |= (1<<TXEN0);
		

                //transmit the number 85 (0x55)
		usart_transmit(0x55);
		usart_transmit(0x55);
		usart_transmit(0x55);
		usart_transmit(0x55);
		usart_transmit(0x55);
		usart_transmit(0x55);
			
		
		
    }
}



 

 

 

 

What i expect from this setup

 

I expect to get the receiver to listen and receive the number 85. I expect to verify this using my logic analyzer. 

 

 

The problem

 

When i power up and start recording, the receiver seems to sync very nicely when i toggle the data pin manually and the receiver data pin toggles exactly the same as the transmitter pin. When i stop toggling the pin manually and start sending the data via UART the receiver receives the data but is not in sync to the transmitter. There is some lag it seems. Below is a screen shot of the logic analyzer output. 

 

 

 

This image shows the pin toggling and the transmitter and receiver are in sync

 

 

 

 

 

 

 

 

 

 

This image shows a zoomed in view when the UART function begins to transmit the number 85. As you can see the receiver does listen but lags when toggling from low to high for some reason

 

 

 

 

 

 

 

This image shows the same as above without the display of the number in decimal. i have shown the lag that i am talking about with the two green lines 1 and 2

 

 

 

 

 

 

 

What have i tried to solve my problem

 

 

I have tried looking for a data sheet for these units as maybe my timing is out or something. I can unfortunately not find a detailed data sheet on these wireless units. I have tried changing the timing to a number of combinations without luck.

 

I have added 10uf capacitors to the VCC and GND pins of both the transmitter and receiver.

 

I have varied the distance between the receiver and transmitter from 1 m to 10 m.

 

I have googles this problem but i might be googling the wrong words because not much comes up that is the same as this. 

 

I have read about these units and kind of understand that the data pin must stay active with equal amount of HIGH's as LOW's. I read as well that i might need to use manchester encoding to transmit the data.

 

I have also tried sending different chars with no luck.

 

 

 

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The wireless units i am using are these:

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

calvingloster wrote:
I have tried looking for a data sheet for these units as maybe my timing is out or something. I can unfortunately not find a detailed data sheet on these wireless units.

That is the fundamental problem with buying these cheap units!

 

They are cheap precisely because they give you no documentation and no support.

 

So, do yourself a favour - pay the extra and get something that's properly documented & supported.

 

Note that not all of these devices are intended to connect straight to a UART and "just work" - again, you pay extra for that.

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

calvingloster wrote:
I read as well that i might need to use manchester encoding to transmit the data.

Almost certainly, you do.

 

That's what I meant by, 

not ... intended to connect straight to a UART and "just work" 

 

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Thank you for the response. 

 

The reason why i am trying to use these cheap units is because i have about 10 sets.

 

By using manchester coding am i correct when i say that you basically increasing the frequency by double? i have tried increasing the timing to mimic this and it does not help. 

 

I have also chosen the number 85 strategically because it is 01010101. This in manchester coding would be 0101010101010101 in the same amount of time?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is really puzzling to me is if i toggle the pin manually or UART toggles the pin the transmitter does not know the difference so why does one work and the other not. I have changes the data rate so that the UART toggles the same time as the manual pin toggling and vice versa with the same problem.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

https://en.wikipedia.org/wiki/Manchester_code

 

Pretty sure Atmel has an App Note on doing it with AVRs ...

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Looks to me your baud rate is too high, as it follows the slower toggling, try 100 or even 10 and see what happens.

Click Link: Get Free Stock: Retire early! PM for strategy

share.robinhood.com/jamesc3274
https://www.onegold.com/join/7134f67c2b814c5ca8144a458eccfd61

 

 

 

Last Edited: Tue. Jul 18, 2017 - 09:01 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

There's a ton of stuff written about these devices - you might want to search this out and save yourself repeating the same mistakes most others make.

The core issue you need to understand is the receiver has a circuit called the 'data slicer' - this is basically a comparator and a low pass filter. For reliable reception, you need to 'train' the slicer by sending a sequence of alternating '1's and '0's. Then you send a sync header in order to make sure you align the bits correctly then you can send your data.

If you want to persist with using the uart to send data (note that no commercial system I've seen ever does this - for good reason), then you need to send a few 0x55 bytes, then your data. Due to the data slicer, using uart data gives you pattern sensitivity - certain sequences of bytes will cause the data slicer to shift. This is why manchester encoding is favoured as it keeps the data slicer happy as well as giving you clocking information.

Also note that sending data via RF is inherently unreliable - either you accept that the data may be corrupted or you build in error checking and/or correcting methods to your code.

 

There's also the library 'virtualwire' which has been renamed. Google this and there is a detailed explanation of how it works.

 

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 1

Kartman wrote:
There's a ton of stuff written about these devices - you might want to search this out and save yourself repeating the same mistakes most others make.

 

There was a thread here a while back that was rather extensive on these crappy units.  The OP had a devil of a time working with them, but I do not remember what the outcome was.

 

For myself I too bought the 10 pair Ebay special and ended up scrapping them and wrote them off as lesson learned...They suck.

 

Take a look at Linx Technologies modules:

 

https://linxtechnologies.com/wp/...

 

There are also other devices from them as well.

 

Another really easy device to use are XBEE modules:

 

https://www.digi.com/products/xb...

 

I use quite a few of the ones in the link above and the 900Mhz long range units.

 

In both cases, the Linx and XBEE use 3.3v power rails and are not happy being fed 5 volts on their inputs.

 

I can assure you that the XBEE modules out of the box will work together.

 

JIm

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

Last Edited: Wed. Jul 19, 2017 - 02:47 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Jim - i think you set your expectations too high with these modules! These are super low tech and work fine for simple low data rate transmission - just look at how many bits of consumer gear uses this technology. Door openers, doorbells etc. For the most part they work well. You're not going to get bluetooth level speed and reliability. With the cost of implementing wifi and bluetooth decreasing, we'll probably see less and less of these simple modules in consumer gear.
If anything, these modules are a good learning experience in data transmission fundamentals and radio. You can't get too much simpler than a single transistor transmitter and a two transistor receiver.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Kartman wrote:
just look at how many bits of consumer gear uses this technology. Door openers, doorbells etc.

Those are by far, higher grade than the links the OP is using. 

 

How many times have threads been started with the OP thinking they hit the 'mother lode' buying a stock of these things only to find the links cannot perform anywhere near the advertised specs.  I know I did and as I wrote learned my lesson.

 

I am sure there are other low cost links out there as not many hobbyists are willing/able to lay down the $$ for links by the two vendors I listed above.

 

 

You get what you pay for as they say.  When  I had issues with the 900Mhz long range XBEE modules,  the tech support group were phenomenal in their assistance.  But when you are paying $20.00 per module I guess the support is included in the price.

 

To each his own I guess.

 

Jim

I would rather attempt something great and fail, than attempt nothing and succeed - Fortune Cookie

 

"The critical shortage here is not stuff, but time." - Johan Ekdahl

 

"If you want a career with a known path - become an undertaker. Dead people don't sue!" - Kartman

"Why is there a "Highway to Hell" and only a "Stairway to Heaven"? A prediction of the expected traffic load?"  - Lee "theusch"

 

Speak sweetly. It makes your words easier to digest when at a later date you have to eat them ;-)  - Source Unknown

Please Read: Code-of-Conduct

Atmel Studio6.2/AS7, DipTrace, Quartus, MPLAB user

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

jgmdesign wrote:
I guess the support is included in the price.

Which was my initial point.

 

The other thing that's included in the price is a microcontroller of some sort and software to do all the clever control, error detection, and error correction.

 

As always, if you skimp on the cost of the basic unit, you have to pay the price of doing all that extra stuff yourself.

 

For a mass-market product, that works fine by amortising the extra costs over huge volumes.

 

For mid-to-low volumes, it makes no sense.

 

For a beginner, I think it makes no sense:  you will not have the skills, experience or tools to make it work properly - so you will just end up frustrated.

 

Again:

do yourself a favour - pay the extra and get something that's properly specified, documented & supported

 

https://www.avrfreaks.net/comment...

 

#CheapRF

 

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

awneil wrote:
As always, if you skimp on the cost of the basic unit, you have to pay the price of doing all that extra stuff yourself.

It's like the difference between buying a house, and just buying a bare plot of land.

 

Sure, the bare plot of land will be cheaper - but it will take a whole lot of time, effort, and specialist skills, tools, & equipment, and money to turn that into a house!

Top Tips:

  1. How to properly post source code - see: https://www.avrfreaks.net/comment... - also how to properly include images/pictures
  2. "Garbage" characters on a serial terminal are (almost?) invariably due to wrong baud rate - see: https://learn.sparkfun.com/tutorials/serial-communication
  3. Wrong baud rate is usually due to not running at the speed you thought; check by blinking a LED to see if you get the speed you expected
  4. Difference between a crystal, and a crystal oscillatorhttps://www.avrfreaks.net/comment...
  5. When your question is resolved, mark the solution: https://www.avrfreaks.net/comment...
  6. Beginner's "Getting Started" tips: https://www.avrfreaks.net/comment...
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Guys thank you so much for the information. Let me educate myself on all this before i ask any more dumb questions then I will get back to you guys if I was successful or not.