Prev: Energizer USB Duo battery charger hides a Trojan
Next: How to run FreeRtos on MSP430
From: Dombo on 11 Mar 2010 16:02
RalfM schreef:
> Grant Edwards wrote:
>> On 2010-03-11, RalfM<rm(a)invalid.invalid> wrote:
>>> Tim Wescott wrote:
>>>> RalfM wrote:
>>>>
>>>>> but instead of transmitting just 1 bit per cycle use instead say 8
>>>>> bits per cycle,
>>>>> ie. 8 DC voltage levels much like done with a DAC and ADC.
>>>>
>>>> That's been fiddled with. About the only place that it's really popular
>>>> is over really long stretches of wire. If the wire run is short (e.g.
>>>> USB, IEEE-1394, LVDS), or if it can be well controlled (e.g. lower
>>>> speed
>>>> Ethernet) then the signaling is usually binary with some sort of
>>>> BEC, or
>>>> FEC combined with BEC.
>>>
>>> Hmm. I don't understand why restrict yourself to use only binary
>>> signalling
>>
>> Because it's cheap, reliable, and works well.
>>
>>> when it can be done byte-wise (or even more) in the same
>>> time.
>>
>> _You_ claim it can be done. Everybody else seems to have failed and
>> chosen methods like phase/amplitude modulation and various other
>> schemes.
>>
>>> This could dramatically increase the speed, regardless of the
>>> distance.
>>
>> Again, you seem to be making a claim that contradicts what everybody
>> who has worked in the data communication industry has experienced.
>
> It is IMO so simple and easy. Let's say we use a 5.12V DC source,
> then we divide this by 256 and get 20 mV DC range for each of the 256 codes
> in a byte. Now tell me where is the problem to transmit the output of
> such a DAC over a twisted pair wire and use the reverse process on the
> other side by using an ADC?

The problem is that what comes out of the cable is quite different than
what you put into the cable, especially at high signaling rates.

> For full-duplex one of course would need 2 pairs of twisted wires.
> It all depends on the speed of the DAC and the ADC, and they are
> IMO sufficiently fast.

You are forgetting the most important part; the cable in between.
Twisted or not nasty things happen to the signal, and I'm not just
talking about noise. Consider what the frequency response, impedance,
inductance, capacity...etc of the cable would do to the signal. Of
course if the termination is less than perfect you would have to
consider reflections as well.

> For example 1 Gbps means 125 MB/s. Then a byte could
> be sent in 8 ns. Ie. the DAC and ADC would need to have a sampling rate
> of 125 MSps, and I think this is easily possible with todays chips.

Ignoring the fact that you would also need to devise a way to extract a
clock from the signal you send over the cable, it would even with a very
short cable it would be at best very unreliable.

> My preliminary calcs indicate that one even could get 1000 GBps and more
> with this method, ie. at least 10 times more than the draft 100 GBps
> Ethnernet.

Only in your fantasy, reality is quite a bit more complicated. Just take
100 meters of cable and actually try your method with signaling rate 1
MB/s. To maximize your learning experience hook up a scope.
From: David Brown on 12 Mar 2010 04:13
On 11/03/2010 22:36, RalfM wrote:
> To all the people who have dicussed this topic:
>
> Imagine Satellite TV: it is possible to get more than 1000 TV channels
> via the dish. Now this is a huge data rate and data quantity that gets
> received
> by the dish and made available in the receiver.
> Now, what do you think: is a satellite link faster than a cable link?
> I think a cable should allow more capacity and reliability than air
> transmission.
> But then why don't we see such transmission rates in computer networks?...

It's no problem to set up a communication link with a bandwidth enough
to support 1000 TV channels over a single cable (though fibre is a
better choice). Transmitting and receiving 1000 Gbps and more over one
fibre optic is perfectly possible today. There's just the small
question of cost.

What you are failing to understand about things like cable TV and
satellite TV is that the transmitters that can mix all these signals
onto one medium are /very/ expensive. At the receiving end, you have a
tuner that picks out just one of the channels - the receiver only
handles a few tens of megabits.

It is perfectly possible to make a receiver system that would be able to
get all the data on all the channels, giving you the full bandwidth.
It's just that to receive these thousand channels, it would be a
thousand times bigger and more expensive than a single channel. And
that's just for half-duplex - if you want two way communication, you
need to double everything.

From: whygee on 12 Mar 2010 08:40
David Brown wrote:
> It is perfectly possible to make a receiver system that would be able to
> get all the data on all the channels, giving you the full bandwidth.
> It's just that to receive these thousand channels, it would be a
> thousand times bigger and more expensive than a single channel. And
> that's just for half-duplex - if you want two way communication, you
> need to double everything.

don't bother : ralph needs to discover by himself
Shannon's and Nyquist work, to name few of the
obvious and basic laws of communication.

the best thing to do is : ask him to build
a proof of concept, physical prototype.
Then let him analyse the tradeoffs
of latency, distance, bandwidth and cost.

I am very fine with discrete bits,
latency = almost 0,
which is critical for fast computations.

yg
--
http://ygdes.com / http://yasep.org
From: Glenn on 13 Mar 2010 10:01
Vladimir Vassilevsky wrote:
>
>
> RalfM wrote:
>
>> Hi, here's some beginners questions:
>>
>> digital data transfer on a wired copper medium is done usually by setting
>> a DC voltage (for example 5V) for a defined duration to indicate
>> a binary 1 value, and say 0V to indicate binary 0.
>> I think the duration of such a signal is called "bit period".
>>
>> Here are some questions & thoughts:
>> What are the chips doing this switching for transmitting are called?
>> (modulator? DAC?)
>> How is it done one the receiving side? (via an ADC ?)
>> How many such binary signals can a say 2 GHz CPU generate in
>> real-world per second?
>
> Are you Radium the Troll ?
>
> VLV
>

Hi Vladimir

No he is not a troll, he is just a bright person that is starting to
think about how to improve data transmissions.

He is now testing his ideas on you - "in the real world" - actually on
people that *has* practical experience.

Theoretically he is right, but he has not yet "invented"/"discovered"
all the filthy signal degrading phenomenas in the transmitter, during
transmission and in the receiver - and from the environment; noise
signals. Some practical tests will help.

Glenn
From: Boudewijn Dijkstra on 14 Mar 2010 16:58
Op Thu, 11 Mar 2010 21:56:40 +0100 schreef RalfM <rm(a)invalid.invalid>:
> Andy wrote:
>>
>> [...]
>>
>> Compared to binary signaling, multilevel discrete signaling has less
>> noise margin for a given min-max signal swing (there is less
>> difference between discrete signal levels).
>
> Of course true, but 256 levels should IMO be within reach with todays
> chips...

The chips are not the problem. What happens between the chips (i.e.
noise) is the problem. For example a DSL connection is 'trained' at
run-time to deal with cable length, crosstalk and whatnot.


--
Gemaakt met Opera's revolutionaire e-mailprogramma:
http://www.opera.com/mail/
(remove the obvious prefix to reply by mail)
First  |  Prev  | 
Pages: 1 2 3 4
Prev: Energizer USB Duo battery charger hides a Trojan
Next: How to run FreeRtos on MSP430