transmitting & receiving data

hello every body

i have implemented the circuit using one method
sending the clock and the data each in its independent wire , this method is very easy and simple
but i find another good idea ,
it's approximately just what super _voip said , using manchester encoding technique to embed the clock with data signal , i did this using XNOR or XOR gate , but what i am sticking in is , how can i recover it using the PLL (CD4046) .

i have read the data sheet but i didn't know exactly where is the output , there are more than one , either VCO , phase comparator output ..
so i have attached both the circuit that i have implemented (thanks to ccurtis) , and the PLL data sheet , if any find an idea , or have experienced with this stuff i will be thankful if he/she reply

Hey guys! I'm late to the party, but I want to say that I admire what you're trying to do here. I've thought about this myself, as I have wanted a simple way to send serial data without needing to connect any processor, write code, etc. Even UART's need a processor to set up baud rates, etc. A simple, propritary system using digital logic parts is ideal for alot of applications. A few people on here have tried to do this, with varying success. Despite what you might hear, simple serial communication is most often done this way.

Photon, you're trying to use manchester encoding in your scheme and you're connecting the clock signal from your transmitter to your receiver. By connecting the clock, the encoding becomes unnessary. You typically use manchester encoding when the clock is not connected to the receiver. So, you can forget about needing to code and decode it. I think your best bet is just to connect the clock.

Ccurtis: I've studied your diagram, and I'm convinced that you would get errors in a real system. The fact that your clock doesn't have a function until a start pulse is received is inconsequential to the operation of the circuit. There need to either be a synchronous clock at the receiver, or else a clock signal that is periodically synchronized. I've always been interested in the idea of using a bistable multivibrator which is synchronized with the arriving data. With careful design, I think it could be made to work. That's where manchester encoding would come in handy.

BrownOut said:

Even UART's need a processor to set up baud rates, etc.

Click to expand...

You would be completely wrong there!

You're obviously much too young - google HD6402.

Nigel Goodwin said:

You would be completely wrong there!

You're obviously much too young - google HD6402.

Click to expand...

Not completely wrong. UARTS like the 16550 have configuration registers which have to be set up before operations. I guess you can connect a bunch of switches and configure it manually each time you use it. Newer UARTS like the CDP6402/AY5-15, etc... are confugurable by strapping logic levels. That depends on the particular type of UART, but it's worth mentioning that, depending on the device, there is some programming required.

Too young? Acutally, the problem is I'm too old. My experience was with the original 8250 UARTS. But thanks for the nice sentiments.

BrownOut said:

Too young? Acutally, the problem is I'm too old. My experience was with the original 8250 UARTS. But thanks for the nice sentiments.

Click to expand...

I thought the 6402 was older than those?, the 8250 was introduced in the IBM PC, which was a fairly late arrival on the PC scene.

You could be right, as I don't have any experience with the 6402. The 8250/16XXX is the only family of UARTS I have experinece with. We actually have "soft cores" of these devices we use in our ASICS. Of course, all of our products integrate a microprocessor, so we never have to worry about how we are going to configure the device. I have never actually used a "stand alone" UART chip that doesn't need confuguration, though I am aware they do exist ( even more so since we are having this discussion ) My knowledge of commodity IC's has become dated since I've mostly worked with soft cores in recent years. That's the biggest reason I'm here, to help me get back up to speed.

PS: I see alot of embedded serial systems within the larger functions we use in out products. When you deconstruct the HDL code, it's just a bunch of shift registers, counters, etc. They are surprisingly similar to the designs some of our members come up with on their own. I think some of these designs can be made to work, once the designer understands the principles involved. Although there are simplier ways to get something up and running, putting in the effort to understand the process and learn the design and operation of these systems is a good thing, IMO.

hey guys to turn around my table !!

mr.BrownOut you have said that

"Photon, you're trying to use manchester encoding in your scheme and you're connecting the clock signal from your transmitter to your receiver. By connecting the clock, the encoding becomes unnessary. You typically use manchester encoding when the clock is not connected to the receiver. So, you can forget about needing to code and decode it. I think your best bet is just to connect the clock."

actually i am doing this to make sure that every thing is going to be alright with a clock
first , but as a development of this circuit i am going to do it by adding PLL , that's why i send the clock too .. relax i know exactly what you want to say , i am going to send only the embeded data just when i know how to use the PLL

so help to figure out the way !

i have implemented the circuit in real
the final attached circuit was working well , but with some adjustments .
any way i want to know how to use PLL?
from where can i get the output ?
i am using a clock of about 100KHZ as a test .
from the data sheet i get the following design resistance and capacitance
R1=6.25K
R2=10K
R3=2K
Rs>10K
C1=30 nf i have 33nf
C2=4 nf i have 4.72nf

the Q is , where is the output ??

Why do you want to use a PLL? It can take longer to sync up than your transfer takes. To use it properly, you need to send a constant clock signal to get the PLL to sychronize, then read the "locked" signal to know you are clear to send. If you can figure out a better way to synchronize it, then forge ahead.

Agreed, the scheme I provided is not error free. In the actual implementation, parity gen and checking was included. The main issue with errors resides on where on the data bit the clock begins to clock in the data. If crystal clocks are used, the error rate is small, however, particularly with short data words. UARTS work on the same principle of synchronizing on the start bit then relying on accurate clocks, but they also have additional circuity to ensure that clocking occurs in the middle of a data bit.

There are commodity devices made by the Holtec corp that provide single wire data transmission/reception nicely, with only a few external components. For example:

**broken link removed**

hello again

brown, thanks for you replying .
it's true that there is a sea of methods to do what i want , but using the PLL is the most simple and easy method .
guys ! ,i only asked for the output !? come on !

ccurtis , thanks a lot for your advice , but ..
i only want to send a serial data , not parallel data ,HT12A/HT12E is used to send four parallel data ,
i am already have 8 bits of serial data
also i don't want one block of IC(to encode ) and another for decoding , this
is not the idea .

i want the embedded signal (manchester signal) to enter a device (at the receiver)
like PLL to get the clock , then using D ff to decode the signal ... as simple as it !

if any idea about using the PLL ... i say welcome .
man ... nice not to attach your sound at this web site !!

photon said:

guys ! ,i only asked for the output !? come on !

Click to expand...

This site exists for the purpose of discussing ideas and solutions. If you post on here, better be ready for a discussion. Still think PLL is not the best idea.

How far the FM Transmitter can released?(Miles)

photon said:

i want the embedded signal (manchester signal) to enter a device (at the receiver)
like PLL to get the clock , then using D ff to decode the signal ... as simple as it !

Click to expand...

If you think it's that simple, then do it!.

Or you could do it the correct way, and use a PIC at each end - one to encode the data as Manchester, the other to decode it (see my tutorials for an example).

"Correct" is relative here. PIC's allow a hobbist to accomplish complex processing without much soldiering or engineering effort. However, it is exceeding rare that a processor would be used for such a simple task in industry, and for good reason. If all you want is something quick, then PIC might be a good solution. If you want to investigate different methods, and still have an aversion to soldiering, couple small CPLD's for the combinatorial design, and couple integrated shift registers is a good compromise.

BrownOut said:

PIC's allow a hobbist to accomplish complex processing without much soldiering or engineering effort. However, it is exceeding rare that a processor would be used for such a simple task in industry, and for good reason.

Click to expand...

I would disagree, they are used in all manner of devices, because they are a quick, easy, and cheap solution - you find them in an incredible range of equipment.

Receiving Manchester coding over a radio link isn't that simple an operation, and the commercially available solutions are processor based.

hello again

forget a bout the PLL , PIC , and AVR ...
can't we decode the Manchester data with just individual gates and flip flops ?!

photon said:

hello again

forget a bout the PLL , PIC , and AVR ...
can't we decode the Manchester data with just individual gates and flip flops ?!

Click to expand...

Again, feel free to do so - but how big can your PCB be, and how much can you afford to spend on it?.

Micro-controllers are used because they are small, cheap, and easy to use.

If you dont have a programmer, and can't be bothered to learn how to program, then why not buy a ready programmed one?.



Which looks like a pre-programmed 16F628 to me.

photon said:

hello again

forget a bout the PLL , PIC , and AVR ...
can't we decode the Manchester data with just individual gates and flip flops ?!

Click to expand...

Yes, simply, cheaply, small and light weight. Here's a design idea that'll run you about a buck ( nearly free if you already have the logic lying as spares ) doesn't take up much space and uses next to no power. It doesn't requre any code to be written, downloaded or debugged. It does reqire some circuit design, however, to get all the timing to be stable, manage the errors, etc. But I'm not afraid of circuit design. Logic is shmitt trigger type.

If you're working in CLDP or FPGA, then the design is even smaller, cheaper, more accurate and more efficient. You would do it a little different in those technologies, not use the delay paths.