FTDX101 Direct Sampling SDR?

Yaesu marketing are in full overdrive claiming the FTDX101 is a direct sampling SDR. Sure their display is driven using direct sampling SDR technology, but anything you hear out the radio (the bit that counts?) goes through a mixer to a 9MHz IF then through a roofing filter etc etc. The whole point of direct sampling is exactly what it says on the tin "direct sampling" of the RF from the antenna not of a 9MHz IF with analogue mixing spurii! Same goes for Icom 7300 and 7610. If you want real direct sampling technology "to listen to" get a Flexradio or an Annan. It is really that simple. I hope the market can come up with guidelines on how to properly describe the glut of new architectures coming onto the market. Something like:

hybrid SDR - Anything that uses a mixer as part of the receiver chain that eventually produces audio i.e. Icom/Yaesu/Kenwood/Elecraft.

SDR - Anything that directly samples (at more than double the input RF) from the antenna i.e. Flexradio/Annan.

Flexradio PTT fault in CW mode

All radios when sending cw with PTT enabled (no full or semi break-in delay) have cw sidetone alone coming out of the speaker to allow the user to hear what they are sending. Flexradio have decided that this is isn't enough and have filled the gaps between the sidetone with receiver hiss. No antenna is actually connected to the receiver during this time, but the engineers at Flexradio think it sane to decode the receiver open circuit anyway. Flexradio engineers fully engage with the full and semi break-in brigade (rag-chew, DXers, occasional contester) as this category covers 99% of the user base. These modes are useless for serious contesting, let me explain why: Flexradio Full break-in (really useless): 1) CW contesting is normally done with an amp over a 48 hour period of approx 50% duty cycle tx. This kind of usage will shorten the life of the tx/rx switching mechanism dramatically for both radio and amp. 2) When running a frequency I have no need to hear between my transmissions as those heard are mostly slow or poor operators. Flexradio Semi break-in (useless): 1) A delay is used to stop the radio unkeying between each cw element and character. This saves the tx/rx switching mechanism somewhat (if set correctly), but unfortunately this delay is also added to the end of the transmission where I want to be listening for fast return callers. 2) If I need to vary my cw speed the delay must also be adjusted. Not good for multi-op contests. Let me now explain why computer PTT or manual footswitch PTT is best: External Winkey/Footswitch PTT (brilliant): 1) When sending via my computer, it knows when the end of the stored message is coming and can remove PTT immediately allowing me to hear fast return callers. 2) When sending via my paddle (external K1EL winkey), its hang-time parameter is sufficient to save the tx/rx switching mechanism. 3) The hang-time delay parameter of my winkey changes value automatically with speed. With Flexradio implementation of what to do when PTT is applied, the operator has to listen to the following for a sent "CQ": long sidetone, false hiss, short sidetone, false hiss, long sidetone, false hiss, short sidetone, false hiss, long sidetone, false hiss, long sidetone, false hiss, short sidetone, false hiss, long sidetone, false hiss, real rx hiss. You can imagine how annoying this is going to get over a 48 hour period. Sure you can dial in some flexradio delay to get rid of the false hiss but then you get the above semi break-in disadvantages. Numerous users have reported this fault to Flexradio, but they think they know better...

ARRL DX CW 2018 GM5A (some notes)

I'm just back from doing the above contest. Using a K1EL winkey within the Microham DigikeyerII and Win-test contest logging software. I had the following problems: 1) When setting the Microham software to provide PTT with lead (20ms, to protect hot-switching amp) and constant tail (10ms, minimum allowable setting) I discovered that Win-Test drops the PTT on spaces when sending predetermined cw messages, even though it knows it hasn't sent the complete message. To counter this without lengthening the standard PTT tail, you need to replace spaces with several ^ characters (the halfspace character with 1/2 dot duration). 2) My laptop computer (Dell D630 single processor 2.4GHz processor speed) running cw skimmer, microham router software and Win-Test caused variable cw timing, pauses, burps and stalls when too many Win-Test windows were open (such as instant rate monitor, world map, statistics and other non-essential windows). This is puzzling as the K1EL is meant to be there to offload timing from the processor precisely to get rid of these timing problems. 3) CW sending speed would range every so often between the correct speed and about double that requested, normally at the "tu GM5A" end part of the exchange. 4) The winkey was set up to have independent speed control (alt-v for Win-Test messages and speed control on Microham for hand sent morse). In most cases the two speeds were the same, even when set differently!. A few taps of the escape key would return the hand sent speed to that suggested. 5) When joining a message with hand sent morse, there was always a stall, I think you have to tap the key then start sending with the key. All in all the net performance was far short of the required performance. Everyone hated whatever was causing all these faults, determining which part of the setup is responsible is difficult. The team recon that returning to a simple serial port transistor switched PTT and CW sending method would cure most problems. I am disappointed with the Microham and K1EL keyer for making such a bad job of a simple task!