Inductance and capacitance will effect the propagation down the cable, but not in the magnatudes that we're talking about. It might change that 200 ns propagation delay by maybe +/- 100 ns but not make it go to 1 us or even 1 ms. This delay is miniscule compared to the delay that you'd get from moving 100 feet away from the speaker (and the rest of the band).
1ms delay in a 100 ft cable? Not likely. Signals travel in a cable at about 1/2 the speed of light or about 6 inches per nanosecond. So a 100 ft cable will have a propagation delay of about 200 nanoseconds. That's a far cry from 1 ms (a.k.a. 1,000,000 nanoseconds).
On the other hand, sound travels through air at about 1 foot per millisecond (roughly). So that 100 ft cable would put Jimi 100 ms away from the monitor speakers. At 4/4 time and 120 beats per minute that is almost a quarternote of latency. Clearly no riff-master would ever want to be off by that much.
Likewise, you can think of latency as "adding distance between you and the speaker". For example, 1 ms of added latency is like adding another foot between you and the speaker. For most applications 5 ms isn't going to be noticeable, but the signal chain for a concert or studio can be long. And all those 5 ms delays really add up.
Gibson Magic is really just a CobraNet wannabe (www.peakaudio.com). CobraNet has been around longer, is more of an established standard, and has more sophisticated network management and routing than Magic. In contrast to CobraNet, Magic is a latecommer that was developed by people who should stick with guitars rather than 100Base-T. More to the point, CobraNet is supported by more than 30 different companies while Magic has maybe one supporter if you don't count Gibson itself.
And isn't this just a repeat post? It seems that Gibson Magic pops up here every so often but that they don't have any real new news...
Hardware flow control won't help. You still won't get the accuracy required in the baud clock for reliable communications-- at any baud rate. Sure, flow control would give you time to process the received bytes but none of that matters if 75% of the bytes you get are corrupted.
They claim to have a PIC 12C509 microcontroller running at 4 MHz, and a serial link running at 115.2 kbps. Let's look at that closely.
The first thing that I notice is that there isn't any RS-232/422/485 line drivers on their PCB, so that brings up some credibility problems. But, I'll give them the benefit of a doubt on this one.
That particular PIC doesn't have a UART on it. So, they must "bit-bang" the UART function in software. This CPU executes an instruction every 4 clock cycles, or at 1 MIPS at the specified 4 MHz. That works out to be 8.68 instructions per bit. Anyone who has bit-banged a UART knows that it's damn near impossible to do a UART in that many instructions, and even if they managed to pull it off they have NO time for anything else, like serving up a web page.
Next is the claim of using the internal RC oscilator for this CPU. Now, RC oscilators are not particularly accurate things. In fact, at a supply voltage of 2.5 volts that CPU has an oscilator frequency range of 3.5 to 4.26 MHz. Since this clock is also used as the alleged baud rate generator, any inaccuracy in this clock translates to an inaccuracy in the baud clock. Thus, there is 12% error in their baud rate. Now, in many situations an error of more than 5% is a bad thing and would cause severe communication errors.
So their claim of a serial connection at 115 kbps is doubtful at best. Never mind the difficulty of putting a TCP/IP stack and web server into that thing.
Slashdot Mirror
Inductance and capacitance will effect the propagation down the cable, but not in the magnatudes that we're talking about. It might change that 200 ns propagation delay by maybe +/- 100 ns but not make it go to 1 us or even 1 ms. This delay is miniscule compared to the delay that you'd get from moving 100 feet away from the speaker (and the rest of the band).
1ms delay in a 100 ft cable? Not likely. Signals travel in a cable at about 1/2 the speed of light or about 6 inches per nanosecond. So a 100 ft cable will have a propagation delay of about 200 nanoseconds. That's a far cry from 1 ms (a.k.a. 1,000,000 nanoseconds).
On the other hand, sound travels through air at about 1 foot per millisecond (roughly). So that 100 ft cable would put Jimi 100 ms away from the monitor speakers. At 4/4 time and 120 beats per minute that is almost a quarternote of latency. Clearly no riff-master would ever want to be off by that much.
Likewise, you can think of latency as "adding distance between you and the speaker". For example, 1 ms of added latency is like adding another foot between you and the speaker. For most applications 5 ms isn't going to be noticeable, but the signal chain for a concert or studio can be long. And all those 5 ms delays really add up.
Gibson Magic is really just a CobraNet wannabe (www.peakaudio.com). CobraNet has been around longer, is more of an established standard, and has more sophisticated network management and routing than Magic. In contrast to CobraNet, Magic is a latecommer that was developed by people who should stick with guitars rather than 100Base-T. More to the point, CobraNet is supported by more than 30 different companies while Magic has maybe one supporter if you don't count Gibson itself.
And isn't this just a repeat post? It seems that Gibson Magic pops up here every so often but that they don't have any real new news...
Hardware flow control won't help. You still won't get the accuracy required in the baud clock for reliable communications-- at any baud rate. Sure, flow control would give you time to process the received bytes but none of that matters if 75% of the bytes you get are corrupted.
This thing can't be for real. Here's why:
They claim to have a PIC 12C509 microcontroller
running at 4 MHz, and a serial link running
at 115.2 kbps. Let's look at that closely.
The first thing that I notice is that there
isn't any RS-232/422/485 line drivers on
their PCB, so that brings up some credibility
problems. But, I'll give them the benefit
of a doubt on this one.
That particular PIC doesn't have a UART on
it. So, they must "bit-bang" the UART function
in software. This CPU executes an instruction
every 4 clock cycles, or at 1 MIPS at the
specified 4 MHz. That works out to be 8.68
instructions per bit. Anyone who has bit-banged
a UART knows that it's damn near impossible to
do a UART in that many instructions, and even
if they managed to pull it off they have NO
time for anything else, like serving up a web
page.
Next is the claim of using the internal
RC oscilator for this CPU. Now, RC oscilators
are not particularly accurate things. In
fact, at a supply voltage of 2.5 volts that
CPU has an oscilator frequency range of 3.5
to 4.26 MHz. Since this clock is also
used as the alleged baud rate generator,
any inaccuracy in this clock translates
to an inaccuracy in the baud clock. Thus,
there is 12% error in their baud rate.
Now, in many situations an error of more
than 5% is a bad thing and would cause
severe communication errors.
So their claim of a serial connection
at 115 kbps is doubtful at best. Never
mind the difficulty of putting a TCP/IP
stack and web server into that thing.
-David Kessner, davidk@free-ip.com