CB and Ham Radio Techs Love Their Bird Wattmeters

[xrunner]

Taller side riser panels being printed - one done. My goal is to finish the enclosure by the end of the weekend.

I'm excited. I know every one else following this project is excited. 

[xrunner]

The enclosure is finally done. OK 99% done because I need some labels but I'm not counting that. Now I can get it calibrated.

It definitely needs new cal factors now after being mounted in a proper case with newer / quality cables. I had to reduce the cal factor offset for the 2 meter band to get it to read the correct power from the HT transmitter, and I notice now that the 450 MHz band is reading about twice as high (watts) as it should. So the rf path is of better quality (less loss) than it was in the testing stage. That is the way it should be in a final quality build, not more loss.

[metrologist]

MIB button coming and going 

[xrunner]

MIB button coming and going 

 

Two red buttons could confuse people - forget which is the front side. 

[metrologist]

Should be no confusion. The red button is the first thing one will push.

The lack of twisty knobs is a little disturbing though.  I know, everything is digital pots nowadays...

[xrunner]

I set up a Yaesu FTM-7250D to calibrate the power meter with higher power than the Baofeng HT could output. Last time I checked this transceiver with an hp 437B power meter it output the following power (watts) on the 2 meter HAM band -

Low: 5
Med: 23
High: 44

My power meter reads the following after I calibrated it for the 2 meter band -

Low: 4.6
Med: 23.4
High: 43.8

So that's good performance as far as I'm concerned. Eat your heart out Bird! 

A power meter like the hp 437B has filtering so the display isn't jittery, see attached page from the manual p. 3-61. I have implemented a running average function to reduce the jitter, but I haven't played with the number of averages for best performance yet. It's just a matter of selecting the number of readings to average vs. the speed of the display update. Thankfully I chose to use the Due board which is a lot faster than the old Arduino Uno, and it really shows in this implementation.

Another thing I want to do is prevent the display of useless low values when the power reading is below some minimum value such as perhaps 0.25 W.

Also I want to do some prettying-up of the screen look, and perhaps a simulated analog graph ... who knows. Maybe I don't need to display dBm, and such other choices to be considered over time.

But after all the work I'm pretty satisfied with this project, and I did pretty much finish it before the end of the year! 

[joeqsmith]

How's it perform at 400+MHz?   Or is the plan now for the 2M band only?    Do you have to manually switch bands?   Have you tired it with some mismatched loads?  Does it calculate the power correctly with them attached?  Read VSWR? 

We need more details....

***
And a video of it in action!!   

[xrunner]

How's it perform at 400+MHz?   Or is the plan now for the 2M band only?   

Oh I have four bands implemented like I decided on originally - 50 MHz, 144 MHz, 220 MHz, and 440 MHz ham bands. I'm simply showing the 2m HAM band at the moment. I will show it works with other bands later.

Do you have to manually switch bands?   

Yes that's what the RED button on the front is for. All it does is select the proper CAL factor for correction to the calculated power. However, it would be cool if it has an auto-sense from a frequency counter inside ... might be a neat add-on project for it. 

Have you tired it with some mismatched loads?  Does it calculate the power correctly with them attached?  Read VSWR? 

I will do that yes. I tried that in the prototype stage and it worked, so nothing can go wrong now.   

We need more details....

***
And a video of it in action!!   

A video? All you youngsters want are videos to watch. I'll have to locate my YT channel. Last time I used it I think I was still doing model RR videos. 

[xrunner]

I want to do a side project for a little break from the current power meter, but then return to it shortly. I made a two small power meters earlier in this long thread using Uno boards, one for ham bands only (HF, 6m, 2m, 1.25m) which requires an external attenuator and has cal factors for each of the bands.

The other one is for checking low power lab bench rf generators, and it goes from 1 MHz to 500 MHz, with a Max input of 20 mW. This one uses a quadratic equation for correction and the frequency input to the correction equation is chosen by a rotary encoder.

It works, but the only issue is it's "laggy" in response because it uses an Uno board and I pushed it to the limit. I wanted to fix that so I bought two of the new Arduino R4 Minima boards a few months ago.

The new R4 uses a Renesas RA4M1 running at 48 MHz which is 3x faster than the Uno. It has more memory also but I need the faster clock right now.

So the plan is to swap the boards, recompile my code, and test. In theory it should just run a lot faster.

Basically "nothing can go wrong"

I know stop laughing ... 

[joeqsmith]

Laggy?  Are you trying to look at something other than CW?   If so, attempting to do something fast with the micro? 

I think I had set the cuttoff filters on mine to 2kHz.  Not quite fast enough for audio and no hardware peak detection.  Still heaps faster than what that guy had shown for their PC connected meter at what, 1Hz?  That was bad.   

[xrunner]

Laggy?  Are you trying to look at something other than CW?   If so, attempting to do something fast with the micro? 

No not in that way I'm sorry for not explaining it well. I mean the response of the display and the rotary encoder. When you turn the encoder the band shown on the display doesn't keep up with you. The Uno processor can't do the graphics and calculations fast enough. This new board should fix that issue. 

[p.larner]

imho overated overpriced outdated american fodda for the equivelent of rf audiofools!,about time this thread was killed!.

[joeqsmith]

No not in that way I'm sorry for not explaining it well. I mean the response of the display and the rotary encoder. When you turn the encoder the band shown on the display doesn't keep up with you.

If it goes forward/backward,  misses steps when turning in one direction, I would say you are as good as what Siglent offers.   

[xrunner]

No not in that way I'm sorry for not explaining it well. I mean the response of the display and the rotary encoder. When you turn the encoder the band shown on the display doesn't keep up with you.

If it goes forward/backward,  misses steps when turning in one direction, I would say you are as good as what Siglent offers.

    

Oh that made my day!

[joeqsmith]

No not in that way I'm sorry for not explaining it well. I mean the response of the display and the rotary encoder. When you turn the encoder the band shown on the display doesn't keep up with you.

If it goes forward/backward,  misses steps when turning in one direction, I would say you are as good as what Siglent offers.

    

Oh that made my day!

I'll offer you the same advice that was offered to me, turn the knob slower.     

[xrunner]

The power meter was disassembled and the Elegoo UNO board was removed and replaced by an R4 Minima board. Does my original software for the UNO compile with no errors? Of course not, we have to deal with some issues now.

First, the new R4 Minima board can have up to 14 bit analog resolution as opposed to the UNO's 10 bit resolution. You can also have 12 bit resolution if you choose, so I chose that for now with the statement -

analogReadResolution(12); //change to 12-bit resolution: 4095

Next, I was using the external analog reference so I could have 3.3 V for better resolution than 5 V would have. However a minor error needed to be corrected.

old statement: analogReference(EXTERNAL);

new statement: analogReference(AR_EXTERNAL);

That fixed that problem. However more issues were causing the rotary encoder and it's button to not function. I used two libraries for these in the original program that now would not compile.

The Uno board had two easily accessible interrupt pins available, 2 & 3, being used for the rotary encoder. But to add a 3rd interrupt (easily) I used another library "PinChangeInterrupt". I needed this for the ISR for the button. This also was not working but should not now be needed.

The R4 board has more interrupts available now without the need for this helper library. I don't think the official Arduino spec pages are correct for this new board yet because they say the R4 Minima only has 2 & 3 easily available, but from other research I did it looked like pins 0, 1, 2, 3, 8, 12, 13, 15, 16, 17, 18 and 19 were easily available for interrupts.

I changed the interrupt I was using from pin 5 to pin 8, moved one wire, and presto the encoder button now works.

The Library used for the rotary encoder, "Encoder" now does not work with this board. The compiler spews error messages for it. That used interrupt pins 2 & 3.

For now, with this non-functional library and associated ISR routine commented out, my software compiles, i.e. the display works, the encoder button works, and the power reads OK from my hp 437B 0 dBm reference, although it's a little off because I can't select 50 MHz with the encoder knob. Yes the button does seem to respond a lot faster.

I will look at solutions for the encoder function next - there are other encoder libraries available that may be updated for this board.

[xrunner]

While it's taken apart I decided to re-design the front panel. The original opening for the OLED was a bit too small and constrained the viewing if looking at it from a slight angle. I widened the opening and also put a fillet on the edges to improve the viewing angle.

Still investigating the encoder issue ...

[xrunner]

I found a fix for the Encoder libray. BTW for anyone in the future who finds these posts looking for the answer the Arduino library I am using is this one -

https://github.com/PaulStoffregen/Encoder/tree/master

This rotary encoder library v 1.4.4 works OK for the Uno (and other boards) but doesn't for the new R4 Minima.

The problem has been fixed by another person so it works with the R4 Minima, but the original author has not put the fixed files in his library yet. The new files can be found here -

https://github.com/mjs513/Encoder/tree/Arduino-R4/utility

They need to go into the Encoder library's utility dir., the new modded files are not installed for the Encoder library v 1.4.4 by the normal installation from the Arduino IDE.

Also, the Encoder object must not be created like this -

Encoder my_encoder(2,3);

as it is used for other boards (where the example interrupts are pin 2 and pin 3 and "my_encoder" is the label you choose) -

Now, before the setup, do this -

Encoder my_encoder;

then in setup this -

my_encoder.begin(2,3);

So doing this fixed the issue and now the rotary knob works as it used to. And yes the encoder does respond faster and increments on each detent. Eat your heart out Siglent!

[joeqsmith]

I found a fix for the Encoder libray. ... And yes the encoder does respond faster and increments on each detent. Eat your heart out Siglent!

To be fair, that Siglent will respond but its a crap shoot if it increments or decrements when turning the knob in the same direction.  Looks like something one of the middle management's prodigy children did for an intern project and without any oversight.   Didn't they blame their strong arm business practices on the interns as well? 

[xrunner]

To be fair, that Siglent will respond but its a crap shoot if it increments or decrements when turning the knob in the same direction.  Looks like something one of the middle management's prodigy children did for an intern project and without any oversight.   Didn't they blame their strong arm business practices on the interns as well?

I had a Rigol DG1022 about eight years ago that didn't changes values on each detent, but mostly every other one. It also had some other design problems and Rigol let me send it back to exchange (plus some cash) for a new DG 1032Z.

To me it should work like a rotary switch. What if a mechanical switch didn't switch to another function or value on each position but only every other position? Most people would think that was nuts. The rotary encoder moves it's internal contacts each time you move it, so why wouldn't the circuit monitoring that change it's value or function? Say you are incrementing an input frequency to your design 1 kHz at a time and are looking at the way your circuit is responding. Well if you turn the encoder one detent and nothing happens in the circuit, you don't know if 1 kHz didn't cause an effect in the circuit, or that the frequency input didn't actually change. So you have to look at the function generator display - back and forth. No ...

Whoever designed these circuits at Rigol or Siglent was either clueless about the way people want the dials on equipment to work, or was given a set of circuit parameters that limited the reads of the encoder so it couldn't check the encoder like it should. Either way it's irritating to the user.

Anyway, I got the little power meter back together again, all upgraded with a new brain and bezel. I checked the accuracy with my Agilent 8648A @ 450 MHz, -70 dBm. Not a bad little power meter. 

[xrunner]

OK, so we're back to the previous project. I need to work on the way information is displayed and make some changes. I moved the box to my desk because I need to make a lot of tiny changes to positions and possibly fonts. This means I need to look closely at the OLED and try a lot of changes which is very time consuming, but there is no other way to get it all right.

One thing I need to do is to keep the display from showing meaningless numbers, such as when no power is actually being transmitted it will display a meaningless VSWR. I will choose to treat any display that is below 100 mW as below the lower limit of this power meter, and also not show a VSWR in that condition.

Here are some pics, before and after some display mods.

[joeqsmith]

Should read 1.198, not 1.2.  I've been told hams need three places beyond the decimal point. 

[A.Z.]

One thing I need to do is to keep the display from showing meaningless numbers, such as when no power is actually being transmitted it will display a meaningless VSWR. I will choose to treat any display that is below 100 mW as below the lower limit of this power meter, and also not show a VSWR in that condition.

Instead of putting a lower limit to the measured power, why don't you set the SWR to zero when both the displayed FWD/REF values are zero ? I mean, after rounding the values for display, you check if they're "zero" and in such a case the SWR won't be shown, it shouldn't be so difficult and will allow to take measurements even with very low power; that said, what intrigues me is the fact that with FWD and REF at zero (or some really small value) the device shows that SWR value, I wonder if there's some bug in the code calculating SWR, maybe an overflow or something like that ?

[xrunner]

Should read 1.198, not 1.2.  I've been told hams need three places beyond the decimal point. 

I'm trying to wean them away from that sort of thing. They're lucky I'm not showing the tenths as either zero or .5 - whichever is closest. 

Instead of putting a lower limit to the measured power, why don't you set the SWR to zero when both the displayed FWD/REF values are zero ?

Oh here you are. You've been very quiet but I knew you would pop up here again.

The values will not ever be "Zero" as read from the log amp - it's called the noise level.

Furthermore, this is for hams - not the likes of people who frequent this form. They have no use for measuring the power of low wattage emissions, not to mention the SWR of same. What they are interested in is the highest power they can get out of a radio without it melting.

I've never associated with any ham who talked about wanting to see the power of their 0.25 watt transmitter or anything even lower that that. ¹

Therefore, the lower power level that MY project will measure is 0.1 W as a lower limit. Anything lower than that the unit is rendered STANDBY waiting for a power to measure higher than 0.1 W, and therefore there is no VSWR to calculate.

... what intrigues me is the fact that with FWD and REF at zero (or some really small value) the device shows that SWR value, I wonder if there's some bug in the code calculating SWR, maybe an overflow or something like that ?

There is no "bug in the code calculating SWR". As I stated before, the display only shows a few decimal places. If the power calculated out of the log amp is even 100 microwatts there is a power level existing - not "Zero" power. You do realize that these log amps can respond to power levels as low as 1 e-10 W?

Here's what intrigues me: What "really small value" (whatever that means in your mind because you didn't say), for FWD and REV power (not zero power), would not show any calculated SWR?



1.Disclaimer: I do not say there are NO hams who would do this, it's just I've never met one.

[joeqsmith]

Furthermore, this is for hams - not the likes of people who frequent this form. They have no use for measuring the power of low wattage emissions, not to mention the SWR of same. What they are interested in is the highest power they can get out of a radio without it melting.

So it won't correctly read the output power of my pulsed spark gap transmitter?

My last power meter for it was a white LED...