[Date Prev][Date Next][Thread Prev][Thread Next] - [Date Index][Thread Index][Author Index]

RE: AO40 modes

> > Similarly, highly compressed video
> > streams are of interest too
> You and me both, but bidirectional is what I'm after...

Indeed, it would have to be bidirectional.  Live video links, all that sort
of stuff.

> I've been looking at this - mostly off than on recently unfortunately.
> I have enough here to do 38kbps bidirectional, and I've 
> successfully run
> Netmeeting over a radio link at this speed - and it's not at 
> all bad I might
> add.

On a reliable 38.4k link, it probably would work well. :)

> What's gonna really screw things up is that you need a 
> protocol which will
> stand the test of a noisy channel... goes back to that thing 
> about digital:
> either it works or it doesn't, and there's not much in between.

True, any protocol has to handle a noisy, high latency environment (long
haul satellite links).

> I'd like to use Standards if possible, so here's what I've 
> come up with so
> far...
> We're not really interested in point-to-point - without 
> broadcasting this
> whole idea lacks appeal. H.323 (_the_ standard currently for 

Basically, it has to have similar facilities to analog modes.  Non
participants need to be able to "tune in", just like they can with analog,
by selecting the right frequency and mode.  These bystandars also must not
impact the network by merely "listening" (current Internet "webcasts" don't
meet this criterium, as they use separate unicast streams per connection).

> IP Telephony,
> or Voice over IP) supports multicasting but relies on 
> gateways and security
> technology not really compatible with what we're trying to 
> achieve in a
> simple manner.

No, the multicasting is ideal (a mechanism for digitally "tuning" into a
particular QSO on a shared channel), but the security stuff is simply not
needed, should be simple at that level.

> It's exactly the same reasons why we use PB/PG on the digital 
> sats - the
> PB/PG protocol has both broadcasting _and_ error correction 
> built in... the
> receiving stations generally say nothing unless they fail to receive
> something - ie a negative acknowledgement strategy.

This sounds ideal, and meets the basic criteria.

> There's also an open source cross platform H.323 platform, 
> but I found this
> to be lacking in some of the things NM already supported - like quick
> connection. Of course I could write it in there...

I am aware of this, but it seems to be in the early stages of its
development cycle.

> I really really want to use the Voice over IP standards - 
> H.323 and all that
> that encompasses, but I'm afraid that I really can't see it 
> working reliably
> enough over a radio channel. Not only that but at 38k4 
> there's still quite a
> bit of overhead. For H.323, even if you're only 'listening' 
> you still need
> to be a part of the underlying digital conversation. We'd 
> need to have a
> means of 'sniffing' out the conversation, but H.323 
> deliberately tries to
> stop this in an attempt to aid to security.

Hmm, we really don't want any overhead.  If we use IP as the underlying
network protocol, multicast would seem to be an important part of any
audio/video system we build.  IP Multicast is standard (though most Internet
users never see it, due to lack of implamentation in routers), and can also
enable easy linking to terrestrial gateways (via ground based IGMP routers -
hey, I built my first IGMP router the other day! :) ).  Now there's a whole
new area of ham experimentation both on the ground and in the sky! :)

> With a real-time two-way digital conversation over a noisy 
> channel you've
> got two mutual incompatiblities: (a) you want minimal delay two way
> conversations and (b) in order to make up for the noisy 
> channel you've got
> FEC which is probably going to be built around quite a long 
> delay for the
> kind of channel we're discussing here.
> So there's my thoughts - basically I've done quite a bit of 
> investigation,
> both cerebrally and physically, but there's still a way to go.

It's a good start though.  We will get there, put it down as another ham
challenge to tackle. :-)  
Via the amsat-bb mailing list at AMSAT.ORG courtesy of AMSAT-NA.
To unsubscribe, send "unsubscribe amsat-bb" to Majordomo@amsat.org