[G0HZU_JMR]

When you do your tests, are you following the flow chart fig 4.3 in the manual?

Also look at fig 4.2 for the block diagram for range 2.

At the start of the routine it surely must bias the mixer MX1 to bypass mode (using Q12 to deliver about 11V) It actually states it sets the multiplier to DC bias but I'm not sure if this is as relevant (or as correct) as the importance of setting the MX1 mixer to DC bias mode. I think MX1 must be DC biased during the early routine to allow the signals to bypass across the mixer with low loss. This is because it starts off looking to see if the RF signal is in the IF range (<200MHz)

Then it looks at your input RF signal level and compares it with the IF level with the comparator U1.

Because there is a 200MHz LPF and an amplifier before the IF level detector then the counter assumes the signal is <200MHz if the IF level is bigger than your input RF signal (because anything much above 200MHz will not get through the 200MHz LPF at a large level)

If the IF level is declared BIGGER than the input level (determined by comparator U1) then the counter has a go at measuring the frequency of the signal at the IF port. To do this it has to 'signal select' or 'route' the signal to the J5 connector using U4 and U5.

If it counts it as BELOW about 190MHz then it concludes the signal is a genuine signal in the range 2A (10-185MHz)

It will then declare that the input RF frequency is effectively the IF frequency (because it didn't need to do any downmixing) so it declares lock and displays the frequency of the IF frequency as a valid RF frequency.



It looks like your counter can't even respond correctly to a 10MHz signal in this first bit of the flowchart in fig 4.3.

So either the level arriving at the IF detector is too small wrt the RF signal or there's something wrong about the U4,U5 switching when it tries to measure the frequency.

There's lots of ways these faults could happen and the best way to faultfind the counter is to see what it does when it tries to follow the routine above.

I have no idea how quickly it is able to whizz through the flowchart in fig 4.3 but is it possible you are missing some fast action at TP4 and only reporting what happens when it gets stuck? Are you sure you are injecting at least -20dBm into it?

It probably only spends a tiny fraction of a second in any one part of that flow chart...