Problem with wireless serial transmisson

ht12d decoder wikipedia

As I have bought two ask modules (tx and rx) operated at 434 MHz..
**broken link removed**
**broken link removed**

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

Regards
Gaurav Sharma

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.

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 **broken link removed** but that using encoder/decoder.....

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

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

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.

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

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.

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.

Click to expand...

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.

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

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

block diagram of at89c51

So.........

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.

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

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.

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

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




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.

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

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.

wireless manchester encoding

gaurav_sharma132 said:

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

Click to expand...

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:


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?

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

**broken link removed**

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

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.

**broken link removed**

manchester biphase decoding open source

gaurav_sharma132 said:

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

Click to expand...

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

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.

**broken link removed**

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.
https://www.sparkfun.com/commerce/product_info.php?products_id=151
You can visit the sparkfun forums where lots of guys can offer help.
https://forum.sparkfun.com/

Good Luck