6700 & Pactor Modem

I have a P4 Pactor modem wired through the Accessory jack on the 6700 and have been unsuccessful at making a good pactor connection PTT, Transmit & Receive audio seems fine. It my belief what the issue is that the radio is not switching from TX to RX fast enough is this a known problem or should I be looking at another issue on my end?

just a point of reference, I have successuflly used the 6500 with RMS Express ( WINMOR Protocol ) Which reports a tx>RX turn around time opf about 200 millisec. I am not sure what the Pactor protocol spec is but I might be tighter than that..

The FLEX-6000 has not been tested with PACTOR modems, so it is hard to quantify what the actual issue is, but I suspect it is an internal latency issue. It takes time for the DSP to do the signal processing.

Please try using "long path" and let me know if this resolves the problem. The PACTOR protocol can extend the latency for taking the other way around the planet and if this fixes the problem, it is likely latency. If this is what it is, what we will do is create the DIGU and DIGL modes sans any filtering which will cut the latency significantly.

I have a fundamental question regarding the comparison of an SDR to a "traditional" radio. I went back and compared latency on RX on various radios I own. All of the Flex products I own (1500, 3000, 6700) have noticeably more RX latency compared to my FT-817, IC-7000, KX1 and KX3. I know the IC-7000 has IF based DSP, and the KX3 is SDR, but I don't see a correlation in what features on the flex radios creates the latency. Do these latencies exist when not using DSP? Is it just the filtering when using SDR? If so, then why does the KX3, being an SDR, not seem to have this issue?

I'm sure I'm not getting something here.. It's always been something people have asked me about, and I can't respond with anything firm.

The signal path in the radio works like this: receiver data is passed through the FPGA where it is reduced to a bandwidth that serves our needs, in this case 24ksps at a data rate of 1.536Mbps. While we've not measured it, the latency at this point should be about about 2ms, I believe. This goes through DSP filtering, NB, NR, ANF, AGC which adds about 43ms.

For true digital work we can generally skip the filters as most digital programs will do their own filtering -- for example a PACTOR modem would tell you to skip the filtering because you add latency and if you don't know what you are doing you can add group delay. So this is why we will do a DIGU/DIGL mode without the filtering or with greatly reduced filtering.

Finally, we have to send it through OS layers to get to the audio codec. In the FLEX-6000 we are currently using PortAudio and Alsa, neither of which we have spent much time optimizing. Finally any additional filters in the codec (equalizer, for example) can add a little more latency -- generally no more than 10ms. So in the radio today, all of the additional latency is being caused by PortAudio and Alsa. PortAudio and Alsa provide an abstraction and driver layer that make dealing with the audio easier and they necessarily employ elastic buffering to achieve gapless audio. Buffers = latency.

Since I know you are a software guy, here's the detail: The codec is controllable over I2C and sends out data over I2S to the processor. We are using the linux driver from the codec manufacturer which is designed to interface with Alsa -- when we do this, we use Alsa high level controls to control the codec rather than us writing everything from scratch. This is a big labor saver (so we can send labor doing cool radio things rather than non-value-add operating system things). Together PortAudio and Alsa eliminate a lot of the work of dealing with audio. (Having said this, there is a DSP processor in the codec which we did program and we have to modify the driver for our DSP mods, but it's easier when you don't start from scratch on the driver).

Together these two layers are responsible for all of the added latency (beyond about 50ms) that we see today. Ultimately, we will go find as much of the added latency as we can and remove it. There is no fundamental reason why an SDR radio should have more latency except that the final filter in the radio will always be the dominant latency contributor. The sharper the final filter, the more latency you have. And in an SDR you can build "perfect" filters that are as steep as you want ... so we do. The latency difference in the last two versions of SmartSDR went from 10.6ms in the final filter to 42.7ms and achieved a 4x in filter skirt sharpness. Filters like this are not physically possible in an analog radio. For most folks, this 30ms additional is worth it. We will circle around and remove as much of the additional latency as we can as soon as we get a chance.

This is perfect info. And for us Unix nuts, I'm actually happy to see ALSA used in such a great product. So in a purely analog radio, there is no audio delay, but because of the imperfections of analog mixing and filtering methods, we pay for it in lack of audio quality, mixer artifacts, and ringing?

Also, this makes me want to go compare the skirts on the KX3 and IC-7000 to the Flex radios. According to what you say, they should be pretty shallow in order to be so low in latency. I didn't try tuning off frequency and compare a 500hz filter between the radios. I only compared PowerSDR to SmartSDR. I'll do that.

Since you made this recent change to the filter skirts, is this something that could be user tunable in order to allow a user to sacrifice filter sharpness for latency in specific use cases outside of DIGIU/L?

Sharp filters in analog radios are typically crystal (or mechanical) which can have issues with ringing. Of course they are not adjustable either -- if you hear a guy just inside the filter bandwidth, you can't just grab the edge of the filter and move it ;-)

Crystal Roofing Filters, which are required to protect mixers with limited dynamic range in analog radios and which also have nonlinearities, are not required in a direct sampling radio like the FLEX-6000. Provided the total input is below overload (S9+82dB with the preamp off in a FLEX-6000), the location of the strong signals in the RF spectrum is irrelevant -- you still get the same awesome dynamic range. And because the filters are "perfect" (read all non-linearities held below the noise floor where they cannot affect signal quality) there is little to no reciprocal mixing to degrade performance.

So your S9+60dB signals don't have to be artificially kept at 10kHz away to get the dynamic range out of the radio. In a traditional radio, if you get two signals like this inside your roofing filter, you are toast because of the mixer's poor dynamic range. In a FLEX-6000, they can be at 200Hz apart and you can just tighten up your filter to get rid of the one you don't want.

Yes, we can make the filters tunable in steepness also. It's a little more work and we just need to see where this falls in the priority for customers and just how much flexibility is appropriate to offer. Again, the elephant in the latency room right now is the other software layers we're using. It may be that when we fix those that adjustable filters just isn't that important. If we're talking the difference in 80ms and 50ms, it may not matter.

Thanks for the great details. This helps me know how to compare the radios. I've sold so many Flex radios already, it's good to keep the sales team properly trained. ;)

The GUI lover in me envisions the expansion of your clever filter width/shift widget with curve sculpting edges similar to the "Curves" adjustment in photoshop. This then gets translated into the sharpness of the filter, customizable on BOTH sides. I can dream, right? :)

Whatever the digital mode is, the ANF, NR, NB, Equalizer, etc. should be OUT of the signal path. On the inside or outside the filter dynamic range, the numbers are true AND the system is so linear that the IMD in the audio chain is ridiculously small even IF two signals are in band.

We should measure that so we can brag from here to Tasmania and back about how clean this audio is. It's just AWESOME. I wish my stereo system could take my 1.5KW, I would hook it up! HAHA.

If the transmit filter lower edge is "too high" or the high edge "too low" it might be considerably limiting the Pactor signal. I forget the required limits....

I'd like to work with you to get this working. Can you send me an email at steve at flexradio dot com and we can get it resolved? I'd like to talk through your setup and send you some code and see what works best. We can report back here when we get it working. I have a couple of immediate ideas and some that involve some more work on our part, but I'd like to see if we can get this fixed quickly.

So CAT works, signal is going out, spectrum looks good, signal sounds like PACTOR, RMS station on distant end hears me and goes into ARQ, but they will not connect. Tried multiple RMS stations, and none work.

There is a bug in the current release where audio from the other MIC inputs gets mixed with the ACC input so you probably shouldn't have anything else connected to the radio. Besides that I would try the following settings.

- 1 Panadapter and 1 Slice.

- DIGU or DIGL modes ( these have lower latency filters. USB/LSB will definitely not work)

-AGC Off

- PROC off (this should happen by default but to be sure, disable it while in USB and then switch to DIGU/DIGL)

- The levels sound fine since the station responds

- TX Delay of 10 ms

- CSD 10 ms ( I forget the acronym but it is a setup option on the Modem) ﻿﻿﻿﻿﻿﻿﻿﻿﻿﻿

These settings should work and have worked in previous versions. If not we may have introduced a bug with the new version. If this is the case then I believe it may work with VOX enabled.

Any current updates on this issue? I am considering adding a DR 7800 Modem to use with a 6300 and a 3000. It would be a lot of money to spend and discover I have no radio that handles the required switching rates. Andy K3UK

I do a lot of PACTOR work for EMCOMM and Winlink using an "old" IC-756pro anda FT-897D.These TRX switch fast enough and the switching relais are standing up to thestrain for a lot of years now. I haven't even had to clean them.

I built cables both for my Flex6k5 and Flex3k and I'm not getting the same lowerror rate and fast transmission as with the IC-756pro.

Steve N5AC wrote about latency above, which you can't avoid in aFlexRadio.

PACTOR is all about low latency, high speed switching and if that is not enoughfor you, just try a bit of AMTOR :-)

So why tot use a trusty good old analogue TRX? My ICOM stood up to a lot of strongsignals in the vicinity and my FT-897D stood up to years of blue water sailing andPACTOR with and without antennas connected :-( (That happens on a boat sometimes).It even got washed with a lot of seawater and I had to clean it with fresh water anddry it with my wife's hairdryer... I wouldn't dream of doíng that to my Flex...

I am using a SCS DR-7400 with my 6700. I, also, used itpreviously with my 6500. I am running the latest releasefor the Flex. On the Flex TX setup screen, all delays areset at 15 ms. Interface from modem to radio is through the ACC connector. I use Airmail to run the SCS modem. In the Airmail option screen, under the connection tabat the bottom for audio tones, here are my settings.

Center Frequency 1500USBAmplitudes FSK/PSK both 3000

Till I set the amplitudes to the highest setting,I had very, very low output.

In the Flex

My receive filter is set to 3KIt helps with the latency for AGC recovery.Your dial freq is 1.5 lower than the center freq.

Example given

40 MtrsCenter Freq 7.102.4Dial Freq 7.100.9 DIGIU

I have no problem with running Pactor III withthe Flex. Plus I use an amp when conditions warrant.

I use the pre-made cable for the Flex toSCS modem. It is well made and worth the price. I am not sure if the cable is madeby SCS or Farallon Electronics. The modemis controlled by the USB cable to thecomputer. I do not do rig control as Ihave the memory for the Flex with thenecessary parameters for mode, freq, andsuch.