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'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.
I hope that's not too much info.
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.
I am using a SCS DR-7400 with my 6700. I, also, used it
previously with my 6500. I am running the latest release
for the Flex. On the Flex TX setup screen, all delays are
set 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 tab
at the bottom for audio tones, here are my settings.
Center Frequency 1500
Amplitudes 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 3K
It helps with the latency for AGC recovery.
Your dial freq is 1.5 lower than the center freq.
Center Freq 7.102.4
Dial Freq 7.100.9 DIGIU
I have no problem with running Pactor III with
the Flex. Plus I use an amp when conditions warrant.
I do not un-hook any other connections to the Flex.
73, Jim N9VC
Hello N9VC de Jean on4tc..I am vy interesting about your pactor work with FLEX
I have a 6300 and SCS PTCIIUSB I would like to work pactor..could you help me...? did you have a special cable between flex and PTC..? an answer would be vy appreciated
firstname.lastname@example.org --- Best regards de jean