[Flexradio] [SPAM] Frequency change by "slidingacrosspanadapter"

[Brian Lloyd]

On Sun, May 24, 2009 at 5:08 AM, Ray Andrews, K9DUR <k9dur at rnacs.com> wrote:
> Unless we were a party to all of the design discussions & experiments which
> led to the choosing of firewire over the other available technologies, we
> cannot fully understand the reasons why firewire was chosen.  Gerald has
> stated that all of the technologies discussed in this thread were
> investigated and firewire was found to be the only one that fully supported
> the data transfer rates required by the FLEX-5000 (and now the FLEX-3000).
> To state otherwise is to consider him to be less than truthful, or to be a
> poor engineer.  Personally, I have implicit faith in his engineering
> judgement.  Gerald has provided us with an outstanding communications
> system, a true advancement of the radio art.  Obviously he is an engineering
> genius, and not a bad businessman either.

The whole flex group has done a good job. Unfortunately, the
engineering skills developed from doing RF do not necessarily cross
over to doing data links. It is a whole different set of skills
involved.

For example, for many years I suggested that Ethernet be used as a
data bus for advanced avionics. I was informed of all the tests that
"proved" that Ethernet was not suitable for mission-critical avionics
communications. You see, standard Ethernet uses CSMA-CD with backoff
and you couldn't guarantee packet delivery times. I pointed out that,
at low network utilization, it didn't matter, even less so if one used
a store-and-forward hub. (Store-and-forward hubs are what everyone
uses now.)

Funny thing -- the Airbus aircraft now use Ethernet as their avionics
bus. Seems that none of the bad things I was told would happen,
happen.

The real problem that appears with Ethernet is that in order to move
"audio", e.g. channels sending frames consisting of 24-bit sample at
up to 192KHz, you need a lot of overhead software. When one looks at
it that way FireWire looks a lot better. But once you pay the piper to
make the UDP/IP/Ethernet system work, things get simpler because we
have long had interfaces for programs to open sockets on a UDP port.

So it is a trade-off with greater one-time NRE cost with greater
CPU/memory requirements on one (Ethernet), and lower NRE but higher
application development costs on the other (FireWire). The only really
good way to determine which is better is to build both and gain
experience with them. Until then one is just guessing.

OTOH, If one had to pick one and only one to start with I would agree
that the FireWire approach is simpler and more likely to bring success
(and lower cost) in the short term. From that point of view Flex's
decision makes perfect sense (to me).

OTOH, if you are a wacko like me, you would go for the more general
solution of UDP/IP/Ethernet. That would allow you to pipe your streams
over the Internet immediately. It also works with the Ethernet
hardware that is already installed on every computer in the world. But
that is a crap shoot that only someone with long time extensive
experience sending latency-critical data would pick.

Eventually you WILL see all your low-IF streams end up running over
UDP/IP. In the case of the existing Flex 5000/3000 that use Firewire,
you will have a PC connected to the FireWire port of the F3K/F5K
dedicated to doing some preprocessing before shipping the data out
using standardized protocols over UDP/IP/Ethernet.

So we really don't need to have this argument. As the new approach
comes along, your F5K or F3K will go along with it. OK, so you will
have this PC "dongle" in the middle. Who cares. Besides, every shack
needs another box with blinking lights. It is ever so much more
impressive if you have more boxes, more knobs, more meters, more
lights, etc. Who can take seriously a shack that consists of just a
plain box with nothing on the front? Oh, wait, let me rephrase that
...

;-)

73 de Brian, WB6RQN/J79BPL