You can look at my trouble tickets and correspondence with Dudley over the last 6 full months now on this problem.
The problem with loosing MIC audio was NOT fixed in version 1.14 SmartSDR!
I just can't figure out how to make it happen over and over so you could see it happen, It just happens randomly.
I have tried keying the Radio from the back PTT jack and the front 8 pin MIC jack and has nothing to do with keying the radio, it keys fine there is just no output or PanAdapter signal showing and acts just like it does if you have the wrong "AF input source" until you un-key and re-key the radio.
You might with to check the contacts in your foot switch. I had a similar problem with my foot-switch and another radio some time ago that I traced to a bad contact in the foot-switch.
Looking at all the replies thus far shows there are quite a few that have this problem as there was the first time I put this issue on the Flex Email Community and the Flex Yahoo reflector back last November.
This Email Community service is NOT a trouble ticket or Official way to let FLEX know of these kind of hard to recreate problems and if you don't do a Official trouble ticket then these hard to find issues may never get found.
It's easy to do a Help ticket, in SmartSDR click on "HELP" then click on "HelpDesk" then follow the instructions on the page that come up.
With all do respect for the wonderful FLEX crew, if the Flex folks monitoring this reflector can't readily recreate the problem on there radios they won't make a trouble ticket for you!
If this were a data network situation, I'd liken it to an ARP cache timeout, and the network node is re-ARP'ing the network. Since it's DAX, I'm sure it's something else, but again, it smacks of some sort of "caching" thing. It's not annoying enough for me to hassle with it. I just click once and go on my way. :-)
I suspect this PTT thing still has something to do with DAX and the network media streams it uses. The thing I notice, and doesn't seem to be quite right, is that as soon as the radio boots, it starts streaming IP packets to the last unicast address of the computer. I've not bothered to watch the radio boot on Wireshark to see if there's some sort of connection negotiation happening that I can't see. To be honest, I've never bothered to look because there's nothing I could do about it if something looked weird anyway. Perhaps there's a negotiation happening that I just didn't catch in the analyzer. At any rate, I think the problem resides in the network/packet subsystem with DAX. Who knows, though, since Windows is Windows. Back in the day, Windows NT allows Ring0 access to the video drivers to get around performance issues. I wouldn't want to be a developer who's trying to work around the embrace-and-extend mentality of Microsoft!
It appears to grab an IP address from DHCP. It then broadcasts a UDP discover message to port 4992, apparently to elicit response from any SmartSDR/DAX clients on the network. My DAX client hears this broadcast, ARPs the network to get the MAC of the Flex, receives the ARP reply, then proceeds to open a TCP connection with the radio. There's some media stream negotiation, then we see the VITA 49 (Virtual Radio Transport protocol) start streaming to the DAX client. Seemingly a pretty straightforward process.
So no, watching the streams start up as soon as the radio boots appears to be kosher. There's negotiation of the streams and then they do their thing till I shut down the radio. Probably should have performed this packet capture before, as now I'm back to not having a suspect in terms of the PTT issue. I was ready to blame DAX, and perhaps it is the problem. I just don't see anything that suggests a network transport problem that would munge the media streams, and in turn, proper DAX interaction between the radio and the workstation(s).
I've seen this too on my 6300, with both 1.3.8 and 1.4. I key my radio with a footswitch. I know the keying signal is reaching the radio as I see the light change from green to red just below the power switch. Releasing the footswitch and immediately rekeying has always remedied the problem. I don't recall any instance of the problem in which I had to rekey more than once.
It's clear when the problem occurs as I immediately notice that all the transmit indicators have appeared on the SSDR display, but none of the level indicators move from the bottom stops as I speak, including the very obvious power indicators on my amp.
Posting issues like this on this forum is an effective way to get the problem into the software problem database. When the problem is entered, there is a lot of detailed information available in these threads to support it.
This is a nasty problem to resolve as it doesn't correlate to any particular setting or usage pattern, at least not for me. It appears now and again and disappears for relatively long stretches.
I run (not exclusively) a weekly 2M ssb/cw net using a foot operated switch into the front of a F6300 driving an elecraft XVTR into a KW amp. The radio is cabled to the PC with no other accessories.
I noticed the problem about midway through v 1.38 version and guessed it was the
footswitch, but since it happened for only a brief period, maybe on-off through 1 week, I no longer
gave it much thought. I installed v1.4 as soon as it was released and haven't noticed an issue with it along these lines.
On the HF bands I mostly operate cw, at times using an elecraft amp w/o footswitch, and don't ever recall the issue there.
Personally, I have found the response times for help from the forum to be much better than the helpdesk, so the latter is always a poor second when it comes to problems. The forum help is also better quality-wise.
I do not like phone contests but this is not the way to abandon them forever.
For me, this is a SERIOUS problem since I do not know if I can trust 1.4 during contests or chasing DX.
AND, I also installed WSJT-X this weekend and had several incidents when the radio would not produce RF to a command from the software to transmit. Using DXLabs Commander CAT interface.
I am likely to put in a report to the help desk later today.
This is the first time in all the months I have had a 6000 with SmartSDR that I am truly disappointed.
It doesn't seem to be a frequent.
I have not had opportunity to try any DIGI modes since the upgrade, because I have been working on other projects (MIDI Controllers), so I don't know if is still doing it when keyed via FLDIGI, which it had been doing with 1.38 on occasion.
Tech Specs here:
6500 keyed with a solid industrial footswitch via the RCA PTT port.
no other amps in line.
Running 100 Watts with no RF problems in the shack.
With a key plugged in there is no delay whatsoever In CW mode.
In SSB mode the transceiver goes in to transmit immediately the PTT is operated, but the audio and therefore RF output is delayed for around 1 to 1.5 seconds. No audio is missed-out, just delayed.
Smart SDR reports latency as less than 1 millisecond.