Re: [Freetel-codec2] TDMA and digital voice

[Daniel Mundall]

Hi Adrian, 
Totally agree about the SDR hardware getting cheaper, a good case in point is 
the limeSDR mini which has more than enough flexibility for any ham style 
project. 
https://www.crowdsupply.com/lime-micro/limesdr-mini#products-top

Couple that with a rock64 and you could have a great low cost repeater, only 
downside to that approach is I doubt you'll get the power much below 10w of 
which is more of a pain for solar sites than something which is a bit more low 
level like the chipset below.

Another chipset that I've eyed as a cheap option for a handheld radio is the 
SX1255, maybe some of you guys on here with more RF background could offer your 
comments on that chipset. At like $7 for pretty much your entire RF transceiver 
it may be a good option for 70cm.

http://www.semtech.com/images/datasheet/sx1255_datasheet.pdf

Regards,
Daniel VA7DRM
Sent from Daniel's iPhone

> On Nov 11, 2017, at 6:41 AM, Adrian Musceac  wrote:
> 
> Hi Ross,
> 
> My initial GSM tests were done in the 70 cm band with low power (0.5
> W). I recorded them here: https://www.youtube.com/watch?v=LC3GH0vp-iQ
> 
> After that, as suggested by some local amateurs who are also part of
> the regulations comittees here, I moved it in the 1.2 GHz band with
> increased power. The frequency split in both cases being 5 Mhz. As a
> client, I use a modified version of gr-gsm which supports transmission
> (through the USRP SDR hardware). Osmo-trx will also somewhat work but
> needs some patches to make it compatible as a GSM client. You can read
> more about this subject on the OsmocomBB mailing list.
> 
> So yes, I am using a SDR frontend as a client. Some people have
> figured out how to hack some old mobile phones to allow scanning and
> camping out of band. Myself, I spent some time trying to
> reverse-engineer Qualcomm hardware but gave up as too expensive in
> man-hours.
> Other YO hams are running LTE on the 2.3 GHz band also using open
> source software and Chinese phones which have this LTE band. I'm not
> that interested in LTE though because it requires a lot of computing
> power and running a base station on a small Linux board is not
> possible.
> 
> The way I see it, SDR hardware will continue to get smaller and
> cheaper, maybe even hit a price point of $50. Might as well get
> adjusted to that.
> 
> 73,
> Adrian YO8RZZ
> 
>> On 11/11/17, Ross Whenmouth  wrote:
>> Hi Adrian,
>> 
>> I suspect that many of the people here use proprietary SDR hardware - if
>> code is linked with an appropriate HAL (hardware abstraction layer) eg
>> libosmosdr/GNUradio, then it is pretty easy to swap the USRP for a
>> BladeRF, or LimeSDR, or any other SDR with suitable capabilities which
>> is supported by the HAL...
>> 
>> Have you been using SDR for user GSM stations as well? or mobile phones
>> with custom configuration/special SIM card/hacked firmware?
>> Operating on 33cm or on a different band? (23 or 13 cm?)
>> Using the "standard" 45 MHz duplex split, or something different? (the
>> 33cm amateur allocation here in New Zealand is not wide enough to
>> accommodate a 45 MHz split)
>> 
>> 
>> 73 de ZL2WRW
>> Ross Whenmouth
>> 
>> --
>> 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
--
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

Re: [Freetel-codec2] TDMA and digital voice

[Adrian Musceac]

Hi Ross,

My initial GSM tests were done in the 70 cm band with low power (0.5
W). I recorded them here: https://www.youtube.com/watch?v=LC3GH0vp-iQ

After that, as suggested by some local amateurs who are also part of
the regulations comittees here, I moved it in the 1.2 GHz band with
increased power. The frequency split in both cases being 5 Mhz. As a
client, I use a modified version of gr-gsm which supports transmission
(through the USRP SDR hardware). Osmo-trx will also somewhat work but
needs some patches to make it compatible as a GSM client. You can read
more about this subject on the OsmocomBB mailing list.

So yes, I am using a SDR frontend as a client. Some people have
figured out how to hack some old mobile phones to allow scanning and
camping out of band. Myself, I spent some time trying to
reverse-engineer Qualcomm hardware but gave up as too expensive in
man-hours.
Other YO hams are running LTE on the 2.3 GHz band also using open
source software and Chinese phones which have this LTE band. I'm not
that interested in LTE though because it requires a lot of computing
power and running a base station on a small Linux board is not
possible.

The way I see it, SDR hardware will continue to get smaller and
cheaper, maybe even hit a price point of $50. Might as well get
adjusted to that.

73,
Adrian YO8RZZ

On 11/11/17, Ross Whenmouth  wrote:
> Hi Adrian,
>
> I suspect that many of the people here use proprietary SDR hardware - if
> code is linked with an appropriate HAL (hardware abstraction layer) eg
> libosmosdr/GNUradio, then it is pretty easy to swap the USRP for a
> BladeRF, or LimeSDR, or any other SDR with suitable capabilities which
> is supported by the HAL...
>
> Have you been using SDR for user GSM stations as well? or mobile phones
> with custom configuration/special SIM card/hacked firmware?
> Operating on 33cm or on a different band? (23 or 13 cm?)
> Using the "standard" 45 MHz duplex split, or something different? (the
> 33cm amateur allocation here in New Zealand is not wide enough to
> accommodate a 45 MHz split)
>
>
> 73 de ZL2WRW
> Ross Whenmouth
>
> --
> 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

Re: [Freetel-codec2] TDMA and digital voice

[Ross Whenmouth]

Hi Adrian,

I suspect that many of the people here use proprietary SDR hardware - if 
code is linked with an appropriate HAL (hardware abstraction layer) eg 
libosmosdr/GNUradio, then it is pretty easy to swap the USRP for a 
BladeRF, or LimeSDR, or any other SDR with suitable capabilities which 
is supported by the HAL...


Have you been using SDR for user GSM stations as well? or mobile phones 
with custom configuration/special SIM card/hacked firmware?

Operating on 33cm or on a different band? (23 or 13 cm?)
Using the "standard" 45 MHz duplex split, or something different? (the 
33cm amateur allocation here in New Zealand is not wide enough to 
accommodate a 45 MHz split)



73 de ZL2WRW
Ross Whenmouth

--
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

Re: [Freetel-codec2] TDMA and digital voice

[Adrian Musceac]

Hi,

I know talking about proprietary SDR devices is probably frowned upon
on this list, but doing TDMA with a modern SDR, let's say the Ettus
USRP, is fairly easy and there is a lot of open source code for ex.
GSM. Myself, I have been running a GSM network in amateur bands to
play with some ideas: conferences/talkgroups, voice over IP
forwarding, linking cells etc.
Some things can be learned from GSM and maybe even improved on. The
question is how easy it is to have software support for a custom radio
like SM2000 and how many people are willing to work on it.

Best regards and 73,
Adrian YO8RZZ

--
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

Re: [Freetel-codec2] TDMA and digital voice

[glen english]

only 1000 bps ish is wanted ?

what about DQPSK on OFDM (into the mic input) say 100 Hz bins, 400-3000
Hz, 64 pt FFT easy on STM32F4/F7.

use multiple modems in paralel and choice the one with least carrier
rotation (not that it matters too much, differential.


On 7/11/2017 8:49 PM, Samuel Hunt wrote:
>
> I was thinking more the two carriers just 12.5khz apart and use
> dynamic power control.
>
>  
>
> 1500symbols leans towards a high modulation order, perhaps 16fsk
> higher. On more basic radios this will become a problem due to
> linearity. There is a compromise there for sure to be discussed.
>
>  
>
> We use 12.5khz separation without DPC and get surprisingly very little
> problems unless someone is very strong (better than -70dbm)
>
>  
>
> Sam
>
>  
>
>  
>
> *From: *glen english <mailto:g...@cortexrf.com.au>
> *Sent: *07 November 2017 09:20
> *To: *freetel-codec2@lists.sourceforge.net
> <mailto:freetel-codec2@lists.sourceforge.net>
> *Subject: *Re: [Freetel-codec2] TDMA and digital voice
>
>  
>
> really good points Sam on slot timing and radios.
>
>  
>
> whatever you guys do, just remember to keep the SYMBOL rate BELOW 1500
>
> symbols per second if you want the thing to work well in hilly/ echoey
>
> terrain
>
>  
>
> if the symbol rate is low enough, you can run simulcast easily...
>
>  
>
> On the FDMA uplink- you would want the two uplinks spaced at least 50kHz
>
> apart so the sidebands dont kill the weaker signal on a near/far
>
> situation. pref 200 kHz...
>
>  
>
> if you are going to do this I think you might as well run TX diversity
>
> downlink, say 200kHz apart. They dont have to TX at the same time to
>
> avoid the need for a linear amplifier/predistortion.
>
>  
>
> IE you could have three slots- RX , TX 1, TX 2
>
>  
>
>  
>
>  
>
> g
>
>  
>
>  
>
>  
>
> On 7/11/2017 7:52 PM, Samuel Hunt wrote:
>
> > 
>
> > 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 a

Re: [Freetel-codec2] TDMA and digital voice

[glen english]

really good points Sam on slot timing and radios.

whatever you guys do, just remember to keep the SYMBOL rate BELOW 1500
symbols per second if you want the thing to work well in hilly/ echoey
terrain

if the symbol rate is low enough, you can run simulcast easily...

On the FDMA uplink- you would want the two uplinks spaced at least 50kHz
apart so the sidebands dont kill the weaker signal on a near/far
situation. pref 200 kHz...

if you are going to do this I think you might as well run TX diversity
downlink, say 200kHz apart. They dont have to TX at the same time to
avoid the need for a linear amplifier/predistortion. 

IE you could have three slots- RX , TX 1, TX 2



g



On 7/11/2017 7:52 PM, Samuel Hunt wrote:
>
> 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 > > 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 

Re: [Freetel-codec2] TDMA and digital voice

[Samuel Hunt]

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 > 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



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", 

Re: [Freetel-codec2] TDMA and digital voice

[Daniel Mundall]

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  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
>
>
> 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
> 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 

Re: [Freetel-codec2] TDMA and digital voice

[Steve]

> would it be best to spin off a new forum for this topic?

Probably not. The active members are so few, that nothing is going to
get pushed off the top very fast.

73

--
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

Re: [Freetel-codec2] TDMA and digital voice

[Ross Whenmouth]

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



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
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
https://lists.sourceforge.net/lists/listinfo/freetel-codec2

Re: [Freetel-codec2] TDMA and digital voice

[ssampson]

Brainstorming (no code, no circuit boards):
If we are talking VHF (hopefully) then probably the 3200 vocoder is a better 
choice to get a better voice quality. This is 64 bits 50 times a second (20 ms 
frames). But that's just the voice. Obviously you want data and protocol as 
well.
Say a protocol handshake to get started, separated from the stream protocol. 
That is, two ends negotiate a connection, and then the stream starts. Some 
signal to end the stream. You could negotiate half or full duplex, simplex or 
repeater.
The stream would be some number of voice and data packets while the PTT is 
enabled.
64 bit voice + 64 bit data, or 128 bits every 20 ms. That would be 64 QPSK OFDM 
carriers, or 128 BPSK carriers, then you would need some guard time so the 
transmitter can ramp up and down. You could send 4 of these OFDM signals every 
slot, centered on the 100 ms slot time. Obviously some delay buffering before 
the next slot time.
Whatever that equals as far as sending the OFDM carriers at whatever bit-rate. 
Hopefully Less than 5 kHz for SSB and 10 kHz for FM. Obviously wider than an 
analog 3-3.5 kHz modulator.
73, Steve--
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

Re: [Freetel-codec2] TDMA and digital voice

[Adrian Musceac]

Hi,

I'm also working on some TDMA code (SDR based). There are a few
issues. Codec2 frames are 40 ms which are a bit too long to fit into
the slots (with guard times involved). Because code schedules radio
bursts in the future and updates the scheduler clock every X frames,
long delays are to be avoided. Any chance we could get 10 ms frames
from Codec2? The GSM codec does 10 ms frames which is what I'm
currently using.

Cheers,
Adrian

On 11/3/17, David Rowe  wrote:
> Yes it's a good idea and quite possible.  Brady O Brien KC9TPA has
> recently been prototyping some code for a TDMA mode.
>
> - David
>
> On 03/11/17 02:13, Paul Sperbeck wrote:
>> I was watching Bruce Perens on the DDC youtube from HRN.
>>
>> see:
>>
>> https://www.youtube.com/watch?v=giZi4Y7FlwM
>>
>> He mentioned a 'fusion' (not the yaesu kind) of digital voice and TDMA
>> that could be used to create single frequency repeaters. Having built a
>> set of cans years ago this looks like quite an advancement.
>>
>> I don't know how much overhead TDMA requires,  but is this something
>> that could be melded with codec2? I would hate to see the 'big three'
>> get their chops in first... I don't think the ham community needs
>> another Dstar-Fusion-DMA street fight.
>>
>> I don't have any coding skills,  I'm mostly a gear head and hardware
>> guy, so I'm asking here if this is feasible or compatible with codec2?
>> or even if it's a good idea?
>>
>>
>> --
>> 73
>> de
>> paul
>> WB9HCO
>>
>> "You see, wireless telegraph is a kind of a very, very long
>> cat. You pull his tail in New York and his head is
>> meowing in Los Angeles. Do you understand this?
>> And radio operates exactly the same way: you send
>> signals here, they receive them there. The only
>> difference is that there is no cat." Albert Einstein
>>
>> Resistance Is Not Futile!
>> It's voltage divided by current.
>>
>> No trees were killed in the generation of this message,
>> but a tremendous number of electrons were terribly
>> inconvenienced
>>
>> "To err is human...to really mess things up requires the
>> root password."
>>
>>
>>
>> --
>> 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
>

--
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

Re: [Freetel-codec2] TDMA and digital voice

[Stuart Longland]

On 04/11/17 13:27, Alan Beard wrote:
> In the DMR camp, in particular the TYT MD-380 and clones group,
> we have a possible hand-held with downloadable firmware that
> could support another codec.

Good luck with that.  It's theoretically possible, but I doubt the CPU
in the MD-380 is brauny enough to do Codec2 real-time given it was
chosen with the intent of using a specialised DSP (the AMBE+ chip) to do
the signal processing.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
  ...it's backed up on a tape somewhere.



signature.asc
Description: OpenPGP digital signature
--
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

Re: [Freetel-codec2] TDMA and digital voice

[Albert Cahalan]

On 11/2/17, Paul Sperbeck  wrote:

> He mentioned a 'fusion' (not the yaesu kind) of digital voice and TDMA
> that could be used to create single frequency repeaters. Having built a
> set of cans years ago this looks like quite an advancement.
...
> I don't have any coding skills,  I'm mostly a gear head and hardware
> guy, so I'm asking here if this is feasible or compatible with codec2?
> or even if it's a good idea?

Hardware matters for single-frequency.

Not saying you can do the following just yet, since the first products seem
to have shipped in 2006, but be aware of what commercial stuff can do:

TDMA is not required. Consider the CDM-625 sat modem for example.
You can pay a bit extra to unlock single-frequency capability. Simultaneous
transmit and receive knocks you down about 0.3 dB, which might be perfectly
acceptable for what you get out of avoiding the need for another frequency.

Here, they call it DoubleTalk Carrier-in-Carrier:

https://www.comtechefdata.com/technologies/doubletalk
http://www.comtechefdata.com/files/brochures-pdf/DoubleTalk-Carrier-in-Carrier-Acceptance-&-Overview.pdf

Generic hardware for use with any modem:

http://www.comtechefdata.com/files/datasheets/ds-CLO-10.pdf

Modem with feature included:

https://ai-sat.com/wp-content/uploads/2017/03/Comtech-cdm625.pdf

--
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

[Freetel-codec2] TDMA and digital voice

[Paul Sperbeck]

I was watching Bruce Perens on the DDC youtube from HRN.

see:

https://www.youtube.com/watch?v=giZi4Y7FlwM

He mentioned a 'fusion' (not the yaesu kind) of digital voice and TDMA 
that could be used to create single frequency repeaters. Having built a 
set of cans years ago this looks like quite an advancement.


I don't know how much overhead TDMA requires,  but is this something 
that could be melded with codec2? I would hate to see the 'big three'  
get their chops in first... I don't think the ham community needs 
another Dstar-Fusion-DMA street fight.


I don't have any coding skills,  I'm mostly a gear head and hardware 
guy, so I'm asking here if this is feasible or compatible with codec2? 
or even if it's a good idea?



--
73
de
paul
WB9HCO

"You see, wireless telegraph is a kind of a very, very long
cat. You pull his tail in New York and his head is
meowing in Los Angeles. Do you understand this?
And radio operates exactly the same way: you send
signals here, they receive them there. The only
difference is that there is no cat." Albert Einstein

Resistance Is Not Futile!
It's voltage divided by current.

No trees were killed in the generation of this message,
but a tremendous number of electrons were terribly
inconvenienced

"To err is human...to really mess things up requires the
root password."

--
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