From: "Ralf Reiterer" <ralfreit@...>
To: <ic7000@...>
Sent: 2005 March, 05, Saturday 17:21
Subject: [ic7000] Wishes for remote control (was Do our comments affect the
design of the IC7000 ?)
Reports back to the radio via Ethernet can and should be
unpolled. Ethernet handles collision details nicely. That
gets rid of many of the uglies of the CI-V interface;. I'd
add to your 1A memory reports request the implicit request
that they be "complete". Any memory should memorise the
entire control state of the radio at the time and restore it
on call back. That complete status should be part of the
remote control memory status report. (And a poll to request
"radio status" should exist if the "push" mode from radio to
remote controller is not desired.)
The radio should support both, the push and pull mode. By default the
push mode should be deactivated since not every client might desire (or
even be capable to handle) it.
Push is not needed for Ethernet control and arguably adds noise. It
does require a "UDP" broadcast mode of operation to be meaningful. I
had envisioned "TCP" point to point mode. To keep the push mode from
spraying where it does not belong the network setup in the transceiver
would be more complex. Either the user would need to know the proper
netmask to apply or the transceiver would have to properly implement
zero configuration DHCP as well as manual settings. (I HIGHLY vote for
the latter, too. It makes life easier.)
I'll up the ante on this and request that the changes which are
reported be user programmable via CI-V. Only tales one bit per
parameter to report.
I completely agree on that.
With Ethernet this is utterly spurious. Short messages are very
inefficient using the Ethernet bandwidth. The minimum Ethernet packet
size is some 64 bytes. That is a LOT of data compared to what the
usual ICOM transceiver gives you access to. Most control and polling
messages would be smaller than the minimum packet size and would be
padded out to length. (This minimum is part of the Ethernet
collision detection system.)
Regarding collisions, ethernet is of course a far better choice as
issues are handled at operating system level and therefore will remove
complexity from the IC-7000 device driver.
However the IC-7800 only uses ethernet for updating its firmware, as I
have read. So we can only hope that Icom sees the signs of time and
opens the ethernet port for remote control and bandscope samples too. We
will see what happens. ;-)
That is to wish for.
If the C&R, Control and Reporting, is via CI-V that may be
worthwhile. If the C&R is via Ethernet that's spurious. (CI-V
should still exist and offer the ability to send control data
to the likes of a PW-1, of course. But for remote control it
should be considered a dead issue in exchange for an Ethernet
interface that handles the IF samples and the bandscope data
as well as the C&R data. Then we can build magic with radios.
I do not completely agree on that as the CI-V system will also be
necessary if you want to connect the IC-7000 to another Icom radio, e.g.
to do CI-V transceive. Otherwise you will always need a software or
microcontroller that interfaces CI-V with ethernet. But I don't think
it's a big issue to keep the CI-V jack and add an ethernet jack too. Of
course sending bandscope samples will make most sense for ethernet only
as you don't have to take care about the low bandwidth the CI-V bus has.
However AOR managed to do that for the AR-8200. You can read the
bandscope samples in a packed format via the serial port. But I have not
tested how performant this solution is. So ethernet is definitely the
better choice for such things.
That is within the "likes of a PW-1" consideration I mentioned. It's
"legacy support", which should not be abandoned. But I think the future
lies in Ethernet cable, even if its a simple twist cable. And in that
future my comment about "PUSH" being spurious may be wrong. Although
giving a radio a name and allowing (multiple perhaps) TCP connections
to it is a good idea. Then push is not so potentially hazardous to
the network. Broadcast UDP leaking out to the Internet as a whole
is "impolite." Of course a good firewall would stop it. But why rely
on what might not be there.
{^_-} W6MKU, also a bit of a network tweaker type. 60 years is a
LONG TIME to pick up a lot of knowledge if learning is your
"thing".
