Problem with wireless serial transmisson

Goto page 1, 2 Next

EDAboard.com Forum Index -> Hobby Circuits and Small Projects Problems -> Problem with wireless serial transmisson

Author

Message

gaurav_sharma132

Joined: 03 Feb 2009
Posts: 26

22 May 2009 9:06 ht12d decoder wikipedia

As I have bought two ask modules (tx and rx) operated at 434 MHz..
http://thinklabs.in/shop/product_info.php?cPath=44&products_id=72
http://thinklabs.in/shop/product_info.php?cPath=44&products_id=73

And I want to make remote control robot for that i am using two AT89C51 and using serial transmission. The motors are running properly when I attach TXD and RXD through wire simply. But when I introduced this module the circuit is not at all responding I felt that if there is no connection b/w two 89C51 they are operating on their own. As i am checking the circuit on breadboard first...

So please help me out......unable to achieve wireless transmission Crying or Very sad

Regards
Gaurav Sharma

Google
AdSense
Google Adsense

22 May 2009 9:06 Ads

FvM

Joined: 22 Jan 2008
Posts: 5151
Helped: 766
Location: Bochum, Germany

22 May 2009 17:26 manchester code using uart

As far as I understand, the modules are not indended to transmit an UART protocol, rather than Holtek encoder/decoder data. It should be possible to use a similar protocol through an uP, but I don't see a clear specification. A modulation scheme as manchester encoding is mostly used for wireless UART transmission.

gaurav_sharma132

Joined: 03 Feb 2009
Posts: 26

22 May 2009 18:11 18f46j11

Basic, Block Diagram is

transmitter (AT89C51) pin 11 i.e TXD --->> 434MHz ASK Transmitter Module

--->>wireless medium--->434MHz ASK Receiver Module--->> Receiver

(AT89C51) pin 10 i.e RXD--->> L293D Driver--->> control motors

we have similar working circuit at http://thinklabs.in/shop/product_info.php?products_id=99 but that using encoder/decoder.....

please explain in detail what is the problem..........

------------------
Regards
Gaurav sharma

FvM

Joined: 22 Jan 2008
Posts: 5151
Helped: 766
Location: Bochum, Germany

23 May 2009 0:22 data slicer circuit

I simply wanted to mention, that the modules are not necessarily suited for direct UART transmission. But I don't know exactly. Unfortunately I don't see a meaningful specification of the module's possible data payload. On the other hand, you didn't tell a word about the parameters of the data transmission you have tried.

As one point, the AM module seem to use a low idle level, while uP UART has a high idle level.

gaurav_sharma132

Joined: 03 Feb 2009
Posts: 26

23 May 2009 9:45 drivers de satellite a40-sp151 wireless

I am trying at 1200 baud rate........no more parameters i think.

Here is datasheet of the ASK modules......

Sorry, but you need login in to view this attachment

FvM

Joined: 22 Jan 2008
Posts: 5151
Helped: 766
Location: Bochum, Germany

23 May 2009 12:14 manchester coding 89c51 program

1200 Baud basically sounds meaningful. However, due to to the AC coupling said in the datasheet, correct transmission of UART frames isn't guaranteed, I think.

Quote:

The data slicer on the STR-433 is optimized for use with PWM encoded data, though it will work with NRZ data if certain encoding rules are followed.

I fear, at least characters with 4 or more consecutive zero or one bits are likely to fail in transmission. Also recognition of the first character after an idle period may be a problem.

As I said, typically methods as manchester encoding or 4b5b coding are used in wireless data transmission to overcome these problems. They generate a zero/one balanced datastream optimized for AC coupling.

UART can work with a recoding that avoids long zero or one bit sequences. Also an unique start sync character can be assigned. As a first step, you may want to check with an oscilloscope at the receiver, which UART characters can be transmitted reliably.

gaurav_sharma132

Joined: 03 Feb 2009
Posts: 26

23 May 2009 12:28 wireless uart manchester

yea in my hobby project there is continuous transmission of 0's and 1's.....

As I am making circuit at home on breadboard No oscilloscope only having multimeter...........

But Now how I can i Solve this problem ????

----------------------
Regards
Gaurav Sharma

darling67

Joined: 29 May 2009
Posts: 4

29 May 2009 10:54 wireless how to uart preamble

modulation, the process of varying a periodic waveform, a tone, in order to use that signal to convey a message Smile

gaurav_sharma132

Joined: 03 Feb 2009
Posts: 26

29 May 2009 10:59 block diagram of at89c51

So......... Very Happy

banjo

Joined: 24 Dec 2005
Posts: 644
Helped: 118

29 May 2009 12:52 send wireless serial data

OK, here is how I would test it. Start transmitting a string of hex 55. This is a balanced pattern of 01010101 in binary. On the receiving end, see if you receive hex 55 or in ASCII the small letter u.

If this works, then the problem is likely what FVM has stated, ac coupling.

The fix is well known. You must take your data and encode it before transmission. Then after the data is received, you must decode it before it is used. The firmware for encoding and decoding must be included within your 89C51.

If you only need a small series of commands between the robots, then the encoding scheme can be simplified.

gaurav_sharma132

Joined: 03 Feb 2009
Posts: 26

29 May 2009 14:20 holtek ht12e encoder wikipedia

OK! Thanks for reply first......

But firstly how to check it as I am only having multimeter.
Secondly, If the modules are working then what FVM say likely to occur the how to get rid of it.

Any Help is appreciated.

---------------------
Regards
Gaurav Sharma

banjo

Joined: 24 Dec 2005
Posts: 644
Helped: 118

01 Jun 2009 13:36 serial terminal emulator bray

OK, with your test equipment limitations here is what I would do.

First, read the RS232 standard so that you are familar with how it works. A serial port and RS232 are not the same thing. The RF units you bought want TTL levels. The levels coming out the back of your computer are RS232. There are several circuits and chips that will convert between RS232 and TTL.

http://en.wikipedia.org/wiki/RS-232

Next, make a loopback plug for your computer like is detailed at:

http://www.beyondlogic.org/serial/serial.htm

Now open a terminal emulator. There are lots of these. All windows computers ship with Hyperterminal which will work for your purposes. Some people prefer TerraTerm, Bray's Terminal, or other terminal software. You can use any. Open the terminal software, configure it for your baud rate and attach the loopback plug. Start typing and note what appears in the terminal window. If two copies of each character appear, then look through the setting to disable local echo. Now characters should appear only when the loopback plug is attached.

When this occurs, you now have a basic test bench for testing your serial communication. However, this is working at RS232 levels. Therefore, now get a chip like the MAX232 or some other 232 transceiver and attach it to the serial port pins 2 and 3. On the downstream side of the chip, again loopback send and receive. Run the terminal program and verify that the characters are properly echoed.

Finally, you have a TTL level test bench and can attach your RF modules. Connect the TX module to the TX line and the RX module to the RX line. Use enough wire that you can get the modules some distance apart. Now start typing in the terminal program. The characters that appear on the screen will be those sent across your RF link.

Most likely some characters will work and some will be garbled. FVM and I suspect that capital "U" will work best as it is a balanced signal. Make a list of the characters that work best and those that often fail. Open an ASCII chart and verify the sequences of the failures. It is suspected that the failed characters will have several consecutive bits of the same logic level.

If this is the case, then the solution is to encode the data before transmission to equalize the logic level transitions. Then on the on the receiving end decode the data before it is used. There are many methods to do that. Manchester encoding is one of them. If you have several characters that always transmit fine, you could also just use these characters as logic bit descriptors. For example, lets say that "U" and "F" work fine. You could assign "U" to represent logic 1 and "T" to represent logic 0. Then to transmit the hex number '0A' you would transmit, "TTTTUTUT". Of course, this crude method is 8 times slower than other encoding methods, but it works fine if the volume of data is small.

Notice, that I did not use an oscilloscope. My using the computer to construct a systematic test bench, you have all the hardware you need to troubleshoot this. Finally, as a side note, the PC parallel port can be used as a low frequency logic analyzer. Search the web for the code and the hookup.

gaurav_sharma132

Joined: 03 Feb 2009
Posts: 26

06 Jul 2009 19:42 binary encoding schemes ttl manchester

hello banjo

Really appreciate for your nice description above.

As I am busy in my examinations. So sorry for delay in post.
I'll implement it. But before that I want you to take look over my schematic. It is wired as in my simulation software(Proteus) there is no option to simulate wireless. And my wired is working OK as I already told. I am using AT89C51. And I have tried every baud rate. In schematic look over comments written there specifically hex number that are deciding the motion of my robot either forward, left, right or back. I have to send this number through wireless medium using ASK modules and certain additional task as speed control, buzzer(horn) and headlight on-off.

--------------------
With Regards
Gaurav Sharma

Sorry, but you need login in to view this attachment

banjo

Joined: 24 Dec 2005
Posts: 644
Helped: 118

07 Jul 2009 13:25 pic 18f46j11 clock synchronisation problem

Looking at the datasheet, the baud rate is limited to between 300 baud and 3000 baud by the wireless devices. They cannot transmit slower or faster than that. Therefore, you choice of common standard baud rates are 300, 1200 and 2400. I would choose 1200 baud as it is in the middle of the published spec.
Your codes for back and forward are balanced codes, but can be confused by framing errors. (A framing error occurs if you shift the code a bit or so in either direction.) Your simulation and wired versions are clear channel communications. They contain no big noise sources and thus do not really have problems with framing errors.
Your wireless transmission is a noisy channel. Atmospheric noise and other devices transmitting on close frequency will introduce random bits. This 433MHZ band is unlicensed and numerous devices use it. RF remotes like car alarms and remote door locks. Home automation equipment, and even remote thermometers broadcast in this range. Your transmission scheme must be robust enough to allow your data to be detected within the random garbage that is floating around.
Think you have no random garbage? Here is how to test it. On your receiver 8051, blink an LED everytime the receive UART triggers indicating a new data input. Now leave your transmitter idle and watch the LED. If it blinks or flickers, you are receiving random junk. To make sure your transmitter is not radiating this random junk, turn it off. Still getting random junk? Welcome to the real world!

The solution is usually a better data transmission scheme. Typically this involves sending a header package, followed by the actual command, and then finally a checksum. The header is designed to set the AGC circuits within the reciever to a good value. The checksum allows garbled transmissions with framing errors to be discarded. The receiver firmware needs to decode the packets. It also needs to discard partial packets and must set a time window for the entire packet transmission.

While this sounds like alot more work, it is what is required to communicate across a channel with noise. If you want the simplest communication, then your robot must remain wire connected.

ctownsend

Joined: 27 Nov 2004
Posts: 301
Helped: 21
Location: Canada

07 Jul 2009 13:39 wireless manchester encoding

gaurav_sharma132 wrote:

And my wired is working OK as I already told. I am using AT89C51. And I have tried every baud rate. With Regards
Gaurav Sharma

As FVM said above you must use some sort of manchester encoding in your software (Good Luck there).

For a VERY RELIABLE solution look at my post here:
http://www.edaboard.com/viewtopic.php?t=289623&highlight=

It would be better to use the Holtek decoder/encoder pair as in the schematic. I use them with the 89C51, and it works every time.

Software solutions are difficult to implement and are not as reliable.
Notice you do not find EVEN ONE example on the internet if you search google?

gaurav_sharma132

Joined: 03 Feb 2009
Posts: 26

07 Jul 2009 18:11 wireless serial data transmission schematics

Thanks for your reply first.

Take a look over my edited schematic. It is wired not wireless as my simulation software(Proteus) don't support wireless simulation as i already told.
And I am also having the encoder/decoder. Description as follow

http://thinklabs.in/shop/product_info.php?cPath=44&products_id=100

So looking over the channels in schematic and that supported by above IC....the problem can be overcome by using this IC's along with 8051 without using Manchester coding ???

--------------------
Regards
Gaurav Sharma

Sorry, but you need login in to view this attachment

banjo

Joined: 24 Dec 2005
Posts: 644
Helped: 118

07 Jul 2009 18:54 continuous letter problem in serial program

I believe that you can solve the communication issue with manchester encoding, or with dedicated encoder and decoder chips, or with a proper data scheme or data packet.

Which method you choose is a matter of economics and availability. If money or electric power or component area are tightly constrained, then the software solution is desirable. If cost is not important but you are in a hurry to complete the design, then buying encoder and decoder chips is desirable.

The statement that software solutions are not reliable should not be taken seriously. When you take a detailed look at the Holtek chips, they are simply microcontrollers running dedicated preprogrammed software algorithms.

For details from a commercial version that uses the data packet approach, look at the following URL. Notice that they are using an 8051 clone, a wireless transmitter chip and an RS-232 level converter to send serial data to a PC. Read the datasheet and technical manual for the details.

http://www.hobbyengineering.com/H2248.html

ctownsend

Joined: 27 Nov 2004
Posts: 301
Helped: 21
Location: Canada

07 Jul 2009 21:40 manchester biphase decoding open source

gaurav_sharma132 wrote:

So looking over the channels in schematic and that supported by above IC....the problem can be overcome by using this IC's along with 8051 without using Manchester coding ???
Regards
Gaurav Sharma

If you are referring to the Holtek HT12E (encoder) and the Holtek HT12D (decoder) then YES. The problem can be overcome by this extra hardware. So you need an encoder on the transmitter, and a decoder on the receiver. All your problems will be over, you will be happy, and it will be reliable as hell!

I have never used the above IC in your link, but it is probably another microcontroller.

Trying to do it with software is difficult to say the least, because you cannot detect which bits are the start/stop bits. Sure there are ways of lengthening the bit timing in these bits, however like I mentioned in the above post (GOOD LUCK ON THAT).

This is the reason why you see NO SOURCE code examples for manchester encoding with the 8051, or any microcontroller for that matter. It is way easier to do it with a very small (under $1.00) piece of hardware.

I have successfully completed a similar scheme without the hardware, but it is only about 50% reliable at best, and you still need to add an inverter which costs just about the same as the holtek device. With the holtek devices, it will be 100% reliable (provided your code is correct)

Good Luck

banjo

Joined: 24 Dec 2005
Posts: 644
Helped: 118

08 Jul 2009 13:35 wireless serial transmitter chips

These inexpensive wireless modules seem to be sensitive to interference. Take a look at :

http://www.cytron.com.my/datasheet/WirelessDevice/RF_RX_User's_Manual.pdf

They recommend limiting the clock frequency of the attached microcontroller to less the 4MHZ and being careful with component location and power supply filtering.

There are assembly language routines for various encoding and decoding schemes including Manchester. There are also C libraries for these, although several are not free open source. The encoding of data with Manchester is not difficult. The decoding can be tricky if a noisy channel has caused a bit error. This is why most implementations use preambles and check sums.

Radiotronix has a good application note that explains the difficulties transmitting data wirelessly. There are several nice scope shots that illustrate the problem areas. There proposed solution is not Manchester encoding, but a different encoding scheme. Anyone interested in their scheme can find C source code on their website by searching for the app note AN401. While the C source is written for the PIC compiler, it is easily ported to other microcontrollers.

http://www.radiotronix.com///datasheets/an401.pdf

ctownsend

Joined: 27 Nov 2004
Posts: 301
Helped: 21
Location: Canada

08 Jul 2009 16:01 18f46j11 interrupt usart2

I have yet to find one single example of TRUE MANCHESTER ENCODING (NOT USING THE UART OF THE MICROCONTROLLER)

If your sample source code uses the microcontroller's USART, then it is not TRUE manchester encoding.

Even with the best written software, it is not 100% reliable. This is why I suggest using the holtek encoder/decoder pair. I have some wireless devices working using these decoder/encoder pairs. They have been working 100% every single time for over two years now.

If you want to spend the money the Nordic NRF2401A units are extremely reliable.
http://www.sparkfun.com/commerce/product_info.php?products_id=151
You can visit the sparkfun forums where lots of guys can offer help.
http://forum.sparkfun.com/

Good Luck

betwixt

Joined: 04 Jul 2009
Posts: 383
Helped: 62
Location: Wales, UK

09 Jul 2009 9:59 single channel transmitter 434mhz scheme circuit

Sorry to contradict, although all the previous comments are very valid.

It IS possible to reliably send serial data over an FM/FSK radio link directly from a UART without using Manchester encoding. I do it here on commercial products and at a variety of speeds from 2400 bauds up to in excess of 19200 bauds. The key is to understand why if fails when 'normal' data is sent and to condition the data before transmission to prevent it happening. The PDF mentioned earlier explains what goes wrong and why a data slicer has difficulty when averaging a moving target.

The clue to getting it right, without posting my source code, is to ensure that an equal number of ones and zeroes are present in each byte leaving the UART. It can be done and quite easily. Prototype tests here were done over a 40 metre range using 1mW ERP and in a very noisy RF environment, in fact several other radio links at similar frequencies were being developed and tested in the same room as the receiver. We sent over 3 million data packets, each 32 bytes long with zero loss. The system also recovered from transmitter power down and restart in no more than two packets. Each packet contained different data to simulate a real life scenario and it coped perfectly with any combination of bits in the transmitted UART bytes, including long chains of zeroes and ones.

Brian.

gaurav_sharma132

Joined: 03 Feb 2009
Posts: 26

09 Jul 2009 12:14 send words to serial using atmega8515

How it is possible without Manchester coding until and unless one uses encoder/decoder. Can you please send me your source code so that I can get the idea how to program.

I'll be very thankful to you.

----------------
Regards
Gaurav Sharma

Last edited by gaurav_sharma132 on 09 Jul 2009 14:21; edited 2 times in total

ctownsend

Joined: 27 Nov 2004
Posts: 301
Helped: 21
Location: Canada

09 Jul 2009 13:58 manchester transmit assembly routine

betwixt wrote:

The clue to getting it right, without posting my source code, is to ensure that an equal number of ones and zeroes are present in each byte leaving the UART. It can be done and quite easily. Brian.

Brian,
How is this done with the start/stop bits? Which microcontroller are you using, AVR, 8051, PIC?

I know you don't want to post your source code, however that is the only way I can believe what you are saying (no disrespect intended of course).

I have done similar to what you have done, (8 byte packets only) however it is NOT 100% reliable as you say. The odd time it does not work. I used a start byte, and an 8 bit checksum at the end of every packet. The key to reliability I found was to lower the clock rate on the microcontroller. (anything under 4 MHz was most reliable)

betwixt

Joined: 04 Jul 2009
Posts: 383
Helped: 62
Location: Wales, UK

09 Jul 2009 23:17 433 mhz manchester coding serial uart

Well, as I stated, I'm not prepared to divulge my source code but this should give you the general idea:

Remember the intention is to keep the number of ones and zeros balanced so the data slicer can easily find the mid point between them. If they are equal, the slicer will adapt to 50% of the recovered signal which gives performance, this is what Manchester (bi-phase) encoding also aims for.

Now consider that UART start and stop bits are opposite polarity so average 50% when added together.

For the data itself, the best way to ensure an equal number of ones and zeroes is to send the compliment of the data bits immediately after the bits themselves. So a one is followed by a zero and vice versa. It takes twice as many bits as normal but for this type of application that isn't usually a problem.

For example, to send 1010 you would 10 01 10 01 the original followed by its compliment. For 1001 you would send 10 01 01 10. you may notice that not only are the bits balanced but there are only 16 different patterns in the resulting stream which may make your software easier to manage.

To transmit one byte, take the high 4 bits and send them as 8, then send the low 4 bits and send them as the next 8. Which ever bytes you send, the result will always be 50/50 1's and 0's. Do not leave long gaps between consecutive bytes.

The whole packet must consist of a preamble to allow the data slicer to adapt, this applies whether using this method or true Manchester, it is just to overcome the time constant of the slicer averaging circuit.

At the receiver, the incoming bit stream is initially ambiguous, it is not possible to find the start and stop bits as they look the same as all the other bits. However, by using the appropriate preamble bytes, there are only a limited number of possible patterns that can look like <start, 8-bits, stop> so if one NOT matching the preamble is found, clear the UART and start reading again immediately so no bits are missed. It should find the correct framing in no more than 3 attempts (3 bytes), from now on the UART should stay in sync with the received bytes. Ignore any more preamble bytes (I double check and re-sync if a dud bytes arrives) and wait for a known start marker to arrive, this could be a null or STX character, anything you want that isn't the same as the preamble data. Then just read the rest of the message, discarding every second bit. Remember these are the bits added at the transmitter to balance the data.

That is it. It is simple to implement, very reliable and because it uses the UART it doesn't need any special software timing loops and can be interrupt driven.

I use PIC processors at each end with the data transfers running as background interrupt driven routines while the real work goes on in the foreground.

Brian.

ctownsend

Joined: 27 Nov 2004
Posts: 301
Helped: 21
Location: Canada

10 Jul 2009 0:48 manchester decoder, synchronize detect

Brian, I totally agree with you, and I have done the exact same thing with an atmega8515. However it is not TRUE manchester encoding. It worked pretty good, but it was not 100%.

gaurav_sharma132

Joined: 03 Feb 2009
Posts: 26

10 Jul 2009 6:30 wireless serial transmitter

betwixt wrote:

For example, to send 1010 you would 10 01 10 01 the original followed by its compliment. For 1001 you would send 10 01 01 10. you may notice that not only are the bits balanced but there are only 16 different patterns in the resulting stream which may make your software easier to manage.

Then just read the rest of the message, discarding every second bit. Remember these are the bits added at the transmitter to balance the data.

Really nice logic !! Appreciate that...

But every second bit ?? Its first as i think data enters from bit D0 means LSB in serial.

And secondly, In my program I'm controlling the speed of motor by making a pulse train of 70% duty cycle using timer and then fed it to the L293D driver when appropriate button is pressed at transmitter unit. Let us suppose we have we want forward direction of motor. Then in this case at IN0 of L293D we have that duty cycle(70%) and at IN1 of L293D we have 0 considering only single motor.

So by combination of IN0 and IN1 the motor doesn't get 100 percent power. As in my case there is 70% duty cycle so only 7/10 percent of total power is fed to motor so its speed is slow.

Now tell me how can I send this complete pulse train via this logic ??

--------------------
Regards
Gaurav Sharma

betwixt

Joined: 04 Jul 2009
Posts: 383
Helped: 62
Location: Wales, UK

10 Jul 2009 9:55 manchester coding for serial transmission

Thanks for your comments.

Regarding it not being true Manchester encoding, that is absolutely true but there is nothing inherently 'protected' in Manchester coding either, like my example, it is only a way of ensuring a balanced frequency distribution of carrier energy. I would never say it was 100% reliable but tests have shown it to be *almost* 100% reliable in that given a poor signal path it showed over 3 million packets were transferred without a single error, these incidentally were sent as 16 data byte blocks at a high baud rate with the carrier switched off for 1.5 seconds between blocks. In other words, it had to re-adapt and re-sync every time.

Perhaps I should have said 'alternate bits' instead of every second bit but in truth, it depends on the order they were constructed at transmission. The bytes from the UART will normally be LSB first but the order of the bits in that byte is decided before sending. They are discarded by firmware after being read from the UART.

This system will never be able to cope with PWM as it is but to use it for motor control should be a very simple task. Gaurav, you state that you have a timer to generate the pulse train before sending it to the L293D. All you have to do is send a data byte (or more if necessary) and use that to program your timer duty cycle. The nice thing about my encoding method is that it does not rely on any timers except the one generating the UART bit clock, this is usually a hardware timer anyway. You can also use UART receive interrupts to alert the program that new data has arrived. This should leave almost all the processor time free to control your motor.

For example, send data byte 0x00, software sets duty cycle to 0%, send 0x80 to tell the software to generate 50% and send 0xFF to set 100%. That gives you control of the duty cycle in better than 0.5% steps and your code holds it steady until instructed to change it again so the amount of RF data sent could be quite small.

Brian.

gaurav_sharma132

Joined: 03 Feb 2009
Posts: 26

10 Jul 2009 10:28 nrf2401a basic

Thanks for reply first..

Regarding PWM, You mean to say I have to make that pulse in receiving microcontroller rather than in transmitting microcontroller. And generate that pulse in receiving microcontroller by transferring byte from transmitting microcontroller. Right ?

-------------
Regards
Gaurav Sharma

betwixt

Joined: 04 Jul 2009
Posts: 383
Helped: 62
Location: Wales, UK

10 Jul 2009 10:38 how can i send serial wireless

That is correct.

The transmitter sends INSTRUCTIONS to the receiver rather than the PWM itself.

The PWM is generated in the receiver microcontroller with the duty cycle it is told by the instruction.

You can of course expand the principle to use multi-byte instructions, either to give better PWM control or to do something completely different.

Brian.

gaurav_sharma132

Joined: 03 Feb 2009
Posts: 26

10 Jul 2009 13:28 serial to manchester encoded data circuit

That is OK!!

Now the problem I am facing is "How to separate out data and its complement in receiver microcontroller." As you gave example in your previous post.

Please tell me this trick.

----------------
Regards
Gaurav Sharma