| |
VE2HAR > MT63 12.03.05 03:42l 123 Lines 5555 Bytes #-7491 (0) @ WW
BID : 46016SENTTO
Read: GUEST
Subj: [MT63] A new idea for amateur HF digital communications
Path: DB0FHN<DB0THA<DB0ERF<DB0HGW<ON0DXC<IW2OAZ<ON0AR<VA2HAR<VE2HAR
Sent: 050312/0105z @:VE2HAR.#MTL.QC.CAN.NOAM Laval #:41489 $:46016sentto
All,
I have been listening to this list awhile, and I think it is time that I
speak up with what I have been considering. I have an idea for creating a
next-generation ham radio HF communications system. I think we can look
critically at APRS and other ad-hoc networking schemes and come up with some
improvements. If you look at this link:
http://web.usna.navy.mil/~bruninga/aprs/fix14439.html
Bob talks about how the real limiting factor to APRS is the multiple-access
aspect of the system. The reason why it is so limiting is because there can
be only one person occupying the channel at any given time. This
automatically limits the bandwidth available to all users. One way around
this might be to use an orthogonal signaling scheme using several channels
that are dynamically allocated. In reality, this is exactly what SSB and CW
ops do today in order to separate themselves from other users. Such a way
of thinking is easy for hams to understand and would be amenable to
resolving some bandwidth conflicts.
Here is my idea: We divide some acceptable bandwidth of the HF spectrum
into channels of approximately 500 Hz bandwidth. Such a channel could
contain a 300-Baud digital communications system with some slop allowed for
filter roll-off and mistuning. For example, maybe a part of the digital band
on 80 Meters and maybe parts of 10 or 40 Meters. The reason you want to
assign channels ahead of time is that it makes the job of figuring out where
to expect traffic in frequency much easier. When a user wants to chat with
another user, he simply sends a burst of data in some format. I was
thinking that a 300-Baud 8-ary PSK signal with some FEC on top would
probably be reasonable, but there might be other ideas as well.
In this case, if a user has access to a receiver that has 40 kHz of
bandwidth available out of the IF strip, and he is using a sound card to
digitize all of it, then he might be able to see 80 simultaneous channels of
"chat". Now, if a user only has a radio capable of a 2.8 kHz channel, he
would still be able to see 5 channels or so at the same time.
I am imagining the user looking at a chat-room style interface, very similar
to Tomi's gMFSK software. The user sees the spectrogram going by, and has
the ability to control where he will transmit. If he wishes to transmit
some higher-bandwidth signal, he might be able to occupy several channels
simultaneously. For example, assuming half-rate FEC, the above example of
8-ary PSK with a 2.8 kHz channel filter would allow a net peak bandwidth of
(3 bits * 300 baud) = 900 bps* (1/2)FEC rate = 450 bps * 5 carriers = 2250
bps.
This amount of bandwidth would be sufficient for digital voice, or a file
transfer with reasonable speed. The multiple channel paradigm allows other
users to listen to the file transfer or digital voice communication, and
their computers would not have to search the spectrum for all of the
simultaneous use. Of course, when the user "tunes up" to a certain
frequency, he would have to enter it into the computer in order for it to
know where the channels are relative to the digitized input. Radios with
computer interfaces could accomplish this automatically.
The ability to decide how much bandwidth one will occupy will leave it up to
the user to trade-off bandwidth with power with communications speed.
If a user merely wanted to chat with another user, he might only occupy one
of the channels, selected by the computer automatically (with some algorithm
to determine channel occupancy). Obviously, the more users that use the
higher bandwidth radios, the less interference with other modes and the
greater efficiency achieved in alleviating multiple-access collisions.
The fact that this "chat system" is not connection oriented would eliminate
a fair amount of protocol overhead (at the expense of being somewhat more
inconvenient to use for file transfers). I am imagining that each burst
would consist of a header, some amount of protocol information, and then
some fixed data block, which might contain text chat, binary data, or
whatnot. This does not preclude the use of some simple protocol for file
transfers, but it should fit with the rest of the chat system for a coherent
view of things.
This scheme could co-operate with other digital modes by ignoring channels
that have energy present. If the bursts are relatively short, i.e. a second
or two, then that should alleviate interference with other fixed-frequency
operations by allowing the system to adjust rapidly to changing conditions
on the band. I am also thinking specifically about HF operations, but this
idea is applicable elsewhere.
Anyway, these are some ideas. I would like to design and build some
open-source software that will implement them, but I would like to know what
you all thought about it.
Dave, W9OFA
------------------------ Yahoo! Groups Sponsor --------------------~-->
Music that listens to you.
LAUNCHcast. What's in your mix?
http://us.click.yahoo.com/8mKGzA/FARHAA/kkyPAA/CPMolB/TM
--------------------------------------------------------------------~->
<< Try MT63 on 80m - great fun!>>
- The MT63 Reflector -
MT63@egroups.com
(To unsubscribe. send email to
MT63-unsubscribe@onelist.com)
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/MT63/
<*> To unsubscribe from this group, send an email to:
MT63-unsubscribe@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/
Read previous mail | Read next mail
| |
