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