¿ªÔÆÌåÓý

ctrl + shift + ? for shortcuts
© 2025 Groups.io

Re: ID1 to ID1 Digital Data


 

On Thu, 27 Dec 2012, viaopensource wrote:
Hi Kris, I jotted down some notes on things I tried. Here are the
protocols I tested and the results. The connection was solid but I
was only getting about 90kps even with a short range. Keep in mind
there is no error correction in the DSTAR protocol. But, in a pinch,
it would absolutely be better than nothing. It worked on 12 watts
fairly well in a 3 mile area around my house with the mobile side in
my van.
Protocol/Modes tested: Green=good; red=failed; yellow= not tested
SSH
HTTP(S)
FTP(S)
DNS
SMTP
IMAP
POP3
IM
AIM
Most of these are TCP protocols except for DNS, which is UDP for lookups
and TCP for zone transfers.


DRATS
MagicJack
Skype
DSTAR
DSTAR HOTSPOT
I don't know much about these protocols.

Multicast
Good luck on that one.

IPv6
This is a different beast altogether. It's implementation varies from
PHY to PHY; in Ethernet, it is a different flag in the frame.

Video
There are a lot of standards for that one.

SAMBA
CIFS is based on TCP as well.

Another trick that may would would be to setup a tunneling protocol like
GRE, IPIP, or L2TP and backhaul the traffic over a TCP protocol. This
helps for DNS on lossy networks. The reverse is sometimes true as well.
TCP and UDP have different behaviors depending on network loading
conditions and losses. It's been said that UDP gets priority over TCP;
this is because UDP packets are simply thrown to the wind, whatever gets
there gets there or has to be retransmitted by the application (not the
protocol stack). In a lossy network, TCP shines because packets flow.

Certainly seems like a variation or an automatic capability to switch
between 1/2, 5/6, 7/8, 8/10 FEC would be useful. Mobile stations would
be best suited using 1/2 FEC, but fixed base stations could transmit
8/10 FEC.

--
Kris Kirby, KE4AHR
Disinformation Analyst

Join [email protected] to automatically receive all group messages.