What is the best display format for large frequency values?

Auto ranging?

19.999968 MHz 1.000 kHz

leading zero suppression. This looks to be the industry standard. A old 73 amateur radio Freq Counter project that I built eons ago, worked the same.

The "," is a Euro thing, so that might be acceptable too.

Cheers

The format with the commas seem to look nicer..

Are you sure that you can measure 20 MHz with 1 Hz accuracy? I would just auto-scale it and display mHz, Hz, KHz and MHz with some digits after the decimal point (or comma in Germany), so that the total number of digits is not higher than your accuracy.

The Audio Orecision software does this, too, for generators and analyzers:

E.g. in the generator you can enter "1000 Hz" and it converts it automaticly to "1.00000 kHz" (yes, it is that accurate), which is easier to read, because you'll have at most 3 digits left to the decimal point.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

What time base are you using ?

If some kind of internal (crystal) oscillator, there is no point of displaying anything with 8 digits, since the last 2-3 digits are more or less useless.

Even when comparing two frequencies within a short time, the last digit(s) might be useless due to mediocre short time stability.

Paul

On a sunny day (Sat, 5 Sep 2009 20:58:22 -0400) it happened "Martin Riddle" wrote in :

I already have that auto-ranging, but in 5 digits, with leading zero suppression of course:

19.999 MHz 0.468 kHz Wanted to get rid of it (well it still auto-ranges internally) and simply display in Hz. Probably will add a #define in the asm source after your remark... so they can select the auto ranging option.

Some in the Netherlands use the ',' comma in the same way the US uses the '.' dot, so 1,35 Euro is 1 Euro 35 cents, maybe that would confuse some.

There is an other issue, and that is parsing by some other program, for example by 'awk' and shell scripts. I will have to test some things today to see what works and what not.

This is one thing I do, for the temp_pic project to get the temperature field, and send it to some other box also via RS232: ptlrc -d /dev/ttyUSB1 -b 1200 | awk '/°C/{tempstring=sprintf("echo -en \\"Front temp=%6s\\"", $1) ; system(tempstring) ; sysstring=sprintf("echo -e -n \\"\\001Front temp=%s\\337C\\r\\" > /dev/ttyS1", substr($1, 1, 2)); system(sysstring) }' (LOL this would look cryptic to some, well awk is a bit C like).

This serial com stuff is very very powerful, as it can be so easily integrated in scripting, and be used to control anything via the PC.

What I am considering (this is getting to be a long story), is outputting 2 fields (if bash was to have problems with things like 27,123,456 Hz):

27123456 27,123,456 Hz Then awk can separate the first field, and use that for processing, the second field would be user-friendly output. But then why not use 3 fields and do: 27123456 27,123,456 Hz 27.123456 MHz

Will try some things later. Using the RS232 allows so many cool things compared to a simple LCD or 7 segment display.

On a sunny day (Sat, 05 Sep 2009 22:30:10 -0700) it happened Robert Baer wrote in :

OK, will include that option.

On a sunny day (Sun, 6 Sep 2009 08:00:06 +0200) it happened Frank Buss wrote in :

Well, there needs to be a trimmer one the crystal for calibration, so you can set it to exact frequency. I just soldered some small extra caps to tune it, but need some more testing, was rather late last night, when I got the 8 digits working I stopped.

It seems rock solid on its own crystal, I have not seen any instability when measuring my 27 MHz CB transmitter's output with 5 digits, but still need to test with 8. It does nicely display 50 Hz when I touch the input (mains hum), this is cu tand paste from the old version and the new one below it:

0.050 kHz 50 Hz

The last one is more clear to me.

Did you write that soft?

1000 Hz seems simpler to me?

On a sunny day (Sun, 06 Sep 2009 09:11:55 +0300) it happened Paul Keinanen wrote in :

crystal, adjusted by some caps.

They may give stability clues about the object under test, not always is the absolute value needed.

We shall see :-) Will run some more tests and let you know.

This doesn't sound like the next atomic clock precision reference :-)

Yes, this looks better. Maybe make it configurable: Fixed point or autoranging. For some measurements fixed point would be better. Bargraphs are nice, too, with different scales (linear, log), minimum and maximum values, depending on your application.

No, but I use it sometimes for audio development (only the software part) at a client.

For me 1 kHz is simpler. I think for most cases you don't need to know more than 3 digits anyway, so it would be 1.00 kHz. For the fixed point feature maybe another idea would be 2'999'999.9 Hz, which I've seen somewhere.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

On a sunny day (Sun, 6 Sep 2009 15:28:19 +0200) it happened Frank Buss wrote in :

Yes, well, I wrote the asm now, and the user can un-commwnt a #define to get any or all of 3 output fields to display. Screen grab and asm source is here:

I now use this output configuration:

00000000 0 Hz 00000001 1 Hz 00000016 16 Hz 00000046 46 Hz 00000158 158 Hz 19999968 19,999,968 Hz 19999968 19,999,968 Hz 19999968 19,999,968 Hz 19999968 19,999,968 Hz 05729664 5,729,664 Hz

The first field is intended for parsing in Linux (or any other OS). That way you can call system() on some frequency, and do anything. I am using awk in a script, and ptlrc to read the data, here a funny example: ptlrc -d /dev/ttyUSB1 -b 1200 | awk '{if($1 == 50) {sysstring=sprintf("echo HELLO 50 Hz hum!!"); system(sysstring) } }'

ptlrc is here:

If this is going out an RS-232 port, it is better if the data is fixed format and no commas (or any other characters) between groups of digits. If you have RS-232 data, you are likely to want to log it to disk and then open it with a spread sheet etc. It is very nice to be able to make a graph of frequency vs time over a 24 hour period etc.

HELLO 50 Hz hum!!"); system(sysstring) } }'

For the internal format for parsing I would use the scientific E notation, in Hz, e.g. 5e1 for 50 Hz. Otherwise you can't express frequencies < 1 Hz, like 0.123 Hz = 1.23e-1 and low frequencies would be in general very inexact.

--
Frank Buss, fb@frank-buss.de
http://www.frank-buss.de, http://www.it4-systems.de

On a sunny day (Sun, 6 Sep 2009 18:35:36 +0200) it happened Frank Buss wrote in :

HELLO 50 Hz hum!!"); system(sysstring) } }'

That is true, but the maximum gate time of this PIC frequency counter is 1 second. So 1 Hz *is* the minimum frequency it can display. For lower frequencies I would switch to measuring period time, how many counts of a clock between beginning and end of a period. Integers parse a lot easier in bash too.

On a sunny day (Sun, 6 Sep 2009 09:26:23 -0700 (PDT)) it happened MooseFET wrote in :

Exactly! Now I solved this by sending *both* formats, and using 'awk' in Linux to extract the first integer field. ptlrc -d /dev/ttyUSB1 -b 1200 | awk '{if($1 == 50) {sysstring=sprintf("echo HELLO 50 Hz hum!!"); system(sysstring) } }'

ptlrc is here:

On a sunny day (Sun, 06 Sep 2009 09:11:55 +0300) it happened Paul Keinanen wrote in :

Here are some test output (real) from measuring my CB transmitter on channel 39, comments added later:

00000050 50 Hz 50 Hz main hum (Europe) when I grab the counter input 00000001 1 Hz 00000000 0 Hz 00000000 0 Hz connected to dummy load via attenuator, by winding a few turns around the cable (probably about 1 pF coupling). 00272590 272,590 Hz pressed transmit button on mike, clearly when the count gate gate was already open. 27389472 27,389,472 Hz as you can see from here, very very stable, one measurement every 100 ms. 27389472 27,389,472 Hz BTW the absolute frequency is supposed to be 27,395,000, so need to trim that crystal down about 6 kHz, 27389472 27,389,472 Hz that needed 3 x 22 pF parallel (say 66 pF) on both sides of the crystal on the first PIC. 27389472 27,389,472 Hz 27389472 27,389,472 Hz 27389472 27,389,472 Hz 27389472 27,389,472 Hz 27389472 27,389,472 Hz 27389472 27,389,472 Hz 27389472 27,389,472 Hz 27389472 27,389,472 Hz 27389472 27,389,472 Hz 27389472 27,389,472 Hz 27389472 27,389,472 Hz 27389472 27,389,472 Hz 27389472 27,389,472 Hz 27389472 27,389,472 Hz 27389472 27,389,472 Hz 27389472 27,389,472 Hz 27389472 27,389,472 Hz 27389472 27,389,472 Hz 27389472 27,389,472 Hz 27389472 27,389,472 Hz 27389472 27,389,472 Hz 27389472 27,389,472 Hz

This is from the other (bigger more expansive) CB transmitter also tuned to channel 39, aha, 256 Hz difference between the transmitters, I know that THIS frequency is correct, I had it checked by somebody on the air, it also displays 273950 on the transmitter display.

00000000 0 Hz 27389728 27,389,728 Hz 27389728 27,389,728 Hz 27389728 27,389,728 Hz 27389728 27,389,728 Hz 27389728 27,389,728 Hz 27389728 27,389,728 Hz

As you can see there is NO problem measuring down to 1 Hz and using all 8 digits. The short time stability is OK. The long time stability we will have to see. The absolute accuracy can be trimmed as precise as you want. Temperature variations are not very big here in the workshop.... mmm. I want my 8 digits displayed all the time!

Hope that answers your question. To those who philosophise instability and .... NOW is the time for ..

If you want to get extravagant, period measurement and a count mode would finish it off.

Cheers

The answer to the question asked in the thread title...

2048 x 1152

Bwuahahahaha!

HELLO 50 Hz hum!!"); system(sysstring) } }'

If you're gonna use an external display, don't overlook the value of using a PDA.

I regularly buy old PalmIIIs and handspring visors at garage sales for

25-cents to a buck. The interface varies by model. Some have direct RS-232 I/O. Others put the inversion/voltage conversion in the cradle. The latter have TTL inverted RS-232 that can be connected directly to the PIC. You can even power the PIC off the PDA. There's a free limited demo basic interpreter for the Palm that knows how to make GUI buttons, text boxes etc. like visual basic.

Another possibility is serialIR to the PDA. At one point, I modified the PICBasic PRO compiler to generate serialIR that could log to the PDA via serial IR. Steal the IR transceiver out of an old PDA and hook it to the PIC serial port.

PIC Basic Pro also has a lot of useful functions for generating and parsing strings. Not sure i'd have paid the retail price for the program, but I found mine in a box of junk I bought at a swap meet. Has made PIC program development a LOT simpler. The PDA has made data manipulation and display a LOT simpler.

Using a PDA makes it feasible to do projects that just wouldn't be worth the trouble if you had to build a user interface/display/buttons for each one. Drilling holes in the box to put it in is more work than the electronic part.

T :

rintf("echo HELLO 50 Hz hum!!"); system(sysstring) } }'

If you are going to go that route, you can deal with the string with commas.

[stuff] | sed "s/,//" | [stuff]