Having had some experience with TDMA data protocols (not voice, just
data), my 2 pence on this is that I feel you are considering far too
fast a slot timing for most radios to cope with.
Yes, SDR radios could cope with 300hz slot timing or whatever, but
"older" radios with PLLs will struggle much above 10hz unless they were
specially designed for TDMA. Even at 10hz many will struggle, they just
aren't designed for such rapid RX/TX switching.
I suggest perhaps 80ms frame length, 20ms guard time would be a good
start. This will give older radios a fighting chance. The "return" slot
is similar, so it is 200ms for a complete "cycle" to complete. Yes, this
is 100ms audio delay, but in half-duplex this would be perfectly acceptable.
This is one of the big problems with TDMA as you propose, it is very
sensitive to slot timing and requires SDR type radios to work
universally, which then means many people won't want to join in because
they can't just use what they already have, or tack on a little board
inside an existing "off the shelf" £50 radio.
Ultimately a longer frame is better anyway because then the error
correction can be spread across more bits, giving more robustness. Most
error correction codes perform far better on longer (>256 bits) frames,
giving several dB advantage.
Also as another thought, if you are considering multiple slots, why not
go for TDMA "downlink" (perhaps 25khz), and 2x 12.5khz FDMA uplinks, so
the "mobiles" run lower baud/bandwidth. This gives them then a
significant (6dB?) advantage over the base, but these are the units
which are more likely to be power constrained. Then a 5W handportable is
about reciprocal with a 25W base.
Sam
M1FJB
On 07/11/2017 03:37, Daniel Mundall wrote:
Ross,
I really resonate with your desire to just jump right into the
protocol its self, I've played around with many such ideas - it really
is fun to dream about what could be possible!
But I had to realize I was getting ahead of my self though, for
something to really gain traction like you are talking about you need
to have a chunk of hardware that is cheap, looks nice and works really
well and is likely largely software defined. Once people's immigration
can be lit up with what is possible it can attract some good talent to
really flesh the whole thing out. I believe this has been one of the
large aims of the SM2000.
For my part I have a few limeSDR's that I've been playing with using
Pothos and GNU Radio to try and learn how everything works well enough
that I can actually contribute to something like this.
Have a great day!
Daniel Mundall
On Sun, Nov 5, 2017 at 10:39 PM, Ross Whenmouth <r...@topwire.co.nz
<mailto:r...@topwire.co.nz>> wrote:
Regarding TDMA (for Codec2 +), would it be best to spin off a new
forum for this topic?
I think that it would be sensible to have both half-duplex TDMA
(single RF frequency) and full-duplex TDMA (split frequency
repeater) modes. This is because whilst half-duplex TDMA has the
advantage of allowing a simple "user" radio to work as a repeater,
because only a single RF frequency is used and cavity filters are
not required (excepting shared sites where cavity filters are
required), it suffers from issues with the speed of light, range
to users and the length of guard times between slots (shorter
guard times = better channel efficiency but shorter range limit
before slot collisions occur). Unfortunately, "timing advance"
won't always work properly with a half-duplex system if some users
are very close to the repeater and others are far away from it
(slot collisions between uplink and downlink bursts - all on the
same RF frequency).
Full-duplex TDMA requires cavity filters at the repeater site and
two RF frequencies, but "timing advance" can be made to work
properly as uplink bursts sent to the repeater can never collide
with downlink bursts sent from the repeater as they are on
different frequencies. "Timing advance" is where the repeater and
the user radio measure the RF round trip time between themselves,
and the user radio then advances its slot timing (starts
transmitting earlier to compensate for the RF propagation delay)
so that its burst arrives in the correct time slot at the
repeater. GSM is a good example:
https://www.slideshare.net/singheranil/timing-advances
<https://www.slideshare.net/singheranil/timing-advances>
I think that the "default" and "supported by all stations"
modulation used for default Codec2 voice and control/beaconing in
such a TDMA system should be constant envelope (MSK, 4FSK, etc) to
allow the use of power-efficient non-linear transmit chains, but
with the option to use more complex modulations (8PSK, nQAM, etc)
for traffic, if supported by both ends of the link and channel
conditions (think high-definition digital voice, "picture
messages", data transfer, etc).
Considering that the performance of 1200bps AFSK over FM is at
least 7dB worse than what can be achieved:
http://www.rowetel.com/?p=3799
I think that it would be a good idea for a ham TDMA system to
support data as well as voice so that a TDMA machine can be used
for APRS/packet BBS/etc type use as well as for digital voice.
Buy-in from APRS & packet users, etc (better coverage & faster
data transfer) should increase support for the deployment of TDMA
repeaters?
A hypothetical full-duplex system might have say 4x slots in an
80ms long frame, with a frame rate of say 12.5 Hz (2x 40ms Codec2
frames per slot/traffic burst) and a slot time of 20 ms less
inter-slot guard time. Assuming that the interslot guard time is
negligible, and that a slot request "access burst" is only half
the length of the traffic burst which normally fills an occupied
slot (ala GSM), then the maximum range to a user before an access
burst could collide with the subsequent slot would be about 3*10^8
x (10ms /2) or ~ 1500 km, which is probably good enough for any
VHF or UHF terrestrial repeater?. Like GSM, the repeater would
respond to an access burst with a timing advance value, so that
the remote user radio can ensure its traffic bursts arrive at the
repeater in the correct time slot. 4x (or more) time slots per
frame permits staggering of uplink and downlink slots in time by
half a frame duration, so that a user radio at the say 1500 km
limit would still have ~ 10ms between the end of its RX slot and
the start of its TX slot (time for a modern PLL to QSY and settle).
Albert Cahalan mentioned "DoubleTalk Carrier in Carrier", which
appears to be patented (2025 expiry?):
https://www.google.com/patents/US6859641
<https://www.google.com/patents/US6859641>
It does NOT allow a co-located TX & RX to operate full-duplex on
the same frequency at the same time, what it does do is allow two
ground stations to simultaneously use the same channel on the
"bent-pipe" transponder of the satellite. The transponder of the
satellite still receives on one frequency and re-transmits on
another (eg uplink on 6 GHz, downlink on 4 GHz) - this technology
would not permit the elimination of cavity filters from
full-duplex machines such as ham repeaters.
73 de ZL2WRW
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
<mailto:Freetel-codec2@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
<https://lists.sourceforge.net/lists/listinfo/freetel-codec2>
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
_______________________________________________
Freetel-codec2 mailing list
Freetel-codec2@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freetel-codec2
