Anyone know what architecture Flex uses when sending CW? I bet the key input gets sent up the Firewire port to the PC to be processed before being sent back down the link to the radio hardware as an RF waveform
Midi messages
They would have been better off putting a $0.50 Pic MCU in the box and using that to directly key the transmitter, even if the radio's internal firmware has to generate the RF waveform directly. A simple on-off keyed CW signal can't be that hard to generate to require a fast PC's processing power.
That's not how it generates CW (nor how any SDR would generate it): you're thinking in terms of traditional analog radios where you do something like turn the final amplifier on and off (or perhaps one of the stages, and then feed it to a linear amp).
In an SDR, you just generate the sine wave (envelope shaped to reduce key clicks) that you want transmitted. Think in terms of something like hooking the output of a code practice oscillator to the input of a SSB rig.
The challenge with the PowerSDR software architecture is that the latency through the chain can vary somewhat. The transmitted signal is ok, but has a variable delay from the input to the chain, so if you listen to your own transmitted signal, you'll be confused. The recipient on the other end of the path doesn't care.. he or she hears normal CW. Another term for this is "pipeline delay" and such a delay exists in ALL radios (even analog ones). The delay through a filter with a given bandwidth is roughly 1/Bandwidth * number of sections. So if you have a 50 Hz wide filter, you're going to have a 20 ms delay (at least). In the Power SDR, the delay is more about the block size in the DSP. SHort blocks mean shorter absolute delay, but the filter performance isn't as good. You want a 1 Hz transition in a brick wall filter? that's a 1 second delay.
The other challenge faced by the PowerSDR architecture is T/R switching. In the early versions (fixed at least 4-5 years ago, I think), you had to wait for the audio buffer to finish before it could be "turned around" to the other direction. That's probably the "missing dit" thing. When they fixed the buffering so that it ran full duplex (at a cost of doubling the CPU burden), that particular problem went away..
The other tricky aspect to the PowerSDR architecture is that it potentially has multiple blocks of data stacked up through the chain in both directions. You really, really don't want to have the Transmit DACs "run dry" (because you'll be emitting a big CW carrier at the DDS center frequency with fixed values of I and Q until the next set of samples arrives), so you want to have a few blocks queued up, in case the PC decides to go do something else for a short time. If you're watching a DVD and you hesitate a frame or two, you might not notice. But if the last set of samples happened to be full scale I & Q on a Flex, then you're transmitting full power carrier until the next samples arrive. A good design (which they may have done in the firmware between 1394/Firewire and DACs) would have some default "zero" value (chosen to minimize feedthrough of the DDS) to clock out if samples don't arrive over the firewire in time.
In any case, the need to have extra blocks in the pipeline so the FIFO doesn't run dry also leads to longer delays.
