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