SSB output drops off considerably - new issue

[K9RX]

I suspect this is hardware but thought I'd throw it out to see if anyone has a suggestion on what it might be.

I have an 8000DLE. Its been fine for now going on 6 years (wow - has it been that long?!). I have a Heil Pro Set headphone mic that plugs into the rear jacks. It has always worked just fine on SSB. [latest prot2 protocol and latest release Thetis]

A couple of days ago the audio in dropped way off. The output power shows - all meter readings show (MIC reading is way low). I closed and opened Thetis with the same results. I thought maybe something had happened to the DB so I went back to one a few weeks old to no avail. I checked the settings. I have always run with the added 20 db mic preamp on. But I now notice it makes no difference unchecked or checked. Nothing I did seemed to correct the issue. Listening in the MONI doesn't show anything obvious - sounds the same.

The only way I solved it was to restart the program and cycle power on the rig. Everything returned to as it was.

It occurred again just now.

Suggestions/thoughts anyone before I contact Doug?

Gary
K9RX

[w-u-2-o]

Perhaps the Heil is intermittent in some way? Do you have a way to eliminate the Heil as the source of the problem? Another mic that can be used?

What happens if you wiggle the connections?

Just thinking about mechanical problems first as being most likely.

[K1LSB]

Once in awhile when something goes south at my station the only thing that will bring back proper operation is to a full shutdown and restart of both my Windows machine and the Anan.

Mark

[w-u-2-o]

Remember that anything that is fixed by a restart of the ANAN means the something has gone sideways with the firmware.

If you are having troubles that are fixed by a reboot of the FPGA in the ANAN, consider reloading the firmware.

It's never been clear to me how the firmware might become corrupted, but anything is possible.

[K9RX]

Thanks for the responses guys....

The first time this happened I started with the obvious - the mic/headphone/connection. Nothing there. Then ultimately the only way that solved it was to cycle power on the 8000 which would eliminate an external issue like a connection problem. That has now resolved it twice. It smacks of something changing or turning off the mic preamp. I am going to get out the schematics today and trace down the path from the rear mic connector to the A/D. If there seems an obvious hardware possibility I'll get the scope out and be ready to remove the lid and test - hold on - no - if I recall the main board is on the bottom ... so that makes it much more difficult to test it on the fly. I'll need to think about this.

As an EE with my own products, I know from 40+ years of experience that intermittencies are a real pita. Since its done this twice - I KNOW it will do it again. But don't know what causes it. So sending it into Doug just means he has to go through the same "what causes it - wait and see" phase.

I don't believe in investing many $$ for a "backup" rig that just sits there ... but unfortunately, that might have to be the case.

Gary

[K9RX]

Now that stated - as easy as it is to reload the firmware - I can try that. My suspicion is that it isn't going to 'get corrupted' and then solve/resolve itself through a power cycle though. But hey - its worth a try since I've little else to do.

Gary

[w-u-2-o]

You'll see on the schematics that there is not a lot to go wrong between the mic jack and the CODEC chip. It's unlikely it's any sort of bad solder connection since a power cycle fixes the issue. Since you are not using mic bias we can't blame a failing mic bias circuit. If we assume it's not corrupted firmware, then there's not much left to consider. It could be a failing CODEC chip. Or it could be a failing FPGA that is either sending erroneous control data to the CODEC or failing to process the audio data from the CODEC properly. Replacing the CODEC is easy. A failed FPGA generally means a whole new board because it's a BGA package, and because Cyclone IV's are no longer available.

It will be easy to probe the CODEC during operation, but it's probably not going to tell you very much. Just take the bottom off and run the unit upside down. It's a bit fussy to disconnect the fan from the PA board, you either need to use a mirror or temporarily pull the top cover. Unfortunately Apache chose to tuck the Orion board under the curve of the chassis, which IMHO was not a smart move, but luckily the CODEC, U2, is easily accessible.

If you choose to only send the board to Doug instead of the entire 8000, the only difficult part is getting the cap screws out that are under the curve of the chassis. I reached under with an Allen wrench for initial/final torque, then used a too-small ball end driver poked through the vent holes to run them in or out most of the way. If you drop a fastener, well that's a good reason to have pulled the top cover off Also be aware that there is a small heatsink on the underside of the Orion board that presses on the main 8000 heatsink plate. You will need some fresh thermal grease for reassembly.

These are some photos I took the last time I opened my 8000. The labels on the cables are mine, the factory doesn't do that. U2 can be seen just off the bottom right corner of the FPGA heatsink in the photo.

PXL_20220904_150501711.jpg (1.44 MiB) Viewed 4779 times

IMG_20170519_142550263_HDR.jpg (2.69 MiB) Viewed 4779 times

[K9RX]

Super - thanks. I'm going to keep track, or try to - how I move around from band to band and mode to mode... also split on/off. I know the latter has a good bit of knock on effects. Not looking for a direct cause as its been running too long for that to just be seen now - more just additional info on what might be involved when it goes awry. I worked 3B7M in a massive pileup today on 10M for a new one on 10... called for more than an hour w/o issue.

Gary
K9RX