Alas,  if there was only an FM to R...  there is some useful information in the revision history/comments near the beginning of the file heather.cpp The OSC graph defaults to OFF because it tends to be a very jagged and noisy looking graph that gets rather annoyingly in the way of things.  The next rev of the program has a display filtering option that makes that plot look a lot more tame. The OSC param is shown in PPB in the status info at the top of the screen since that is the way it comes into the program.   It is shown in PPT in the plots since that gives values that are much easier read against the scale divisions on the screen.   I have considered converting to PPT in the status info,   can't remember why it stayed PPB... ----------------------------------------  RTFM comes to mind:-) _________________________________________________________________ Hotmail: Trusted email with Microsoft’s powerful SPAM protection. http://clk.atdmt.com/GBL/go/177141664/direct/01/

On Sun, 11 Oct 2009 12:10:36 +0000, Mark Sims wrote: >Alas, if there was only an FM to R... there is some useful information in the revision history/comments near the beginning of the file heather.cpp >The OSC graph defaults to OFF because it tends to be a very jagged and noisy looking graph that gets rather annoyingly in the way of things. The next rev of the program has a display filtering option that makes that plot look a lot more tame. >The OSC param is shown in PPB in the status info at the top of the screen since that is the way it comes into the program. It is shown in PPT in the plots since that gives values that are much easier read against the scale divisions on the screen. I have considered converting to PPT in the status info, can't remember why it stayed PPB... >---------------------------------------- >RTFM comes to mind:-) Mark, personally I have some promlems with the expressions as in LH ppb, ppt etc. used because there are different meanings about around the world and this is therefore misleading, error-prone. If I search in the Internet I do find lots of discussions about. Is there no way for an improvement, no standardization? I learned that in Germany (and all over continental Europe?) 1 thousend = 1.000 = E3 1 million = 1.000.000 = E6 1 milliard = 1.000.000.000 = E9 1 billion = 1.000.000.000.000 = E12 1 billiard = 1.000.000.000.000.000 = E15 1 trillion = 1.000.000.000.000.000.000 = E18 1 trilliard = 1.000.000.000.000.000.000.000 = E21 and so on with quartrillion, quartrilliard, quintillion, quintilliard, sextillion, sextilliard.... and in the US and some more countries it is million = 1,000,000 billion = 1,000,000,000 trillion = 1,000,000,000,000 and further ...? ( fantastillions acc. Donald Duck ;-)) ) wouldn't it be more scientific and less error-prone to agree at least to xE-3 instead of (m) xE-6 instead of ppm (µ) xE-9 instead of ppb (n) xE-12 instead of ppt (p) xE-15 instead of pp? etc. (f) xE-18 (a) (how do one express parts per mili...(E-3)?) or if not wanted perhaps then this way : x10^-6 x10^-9 x10^-12 etc. or could one type eg. m, µ, p, f, a for milli, mikro, nano; pico, femto, atto? When used these numbers in calculations we anyway have to convert these ppm, ppb, ppt etc. to scientific numbers using exponents There are too often discussions and misunderstandings because the ignored case sensitivity of units (b for bit, B for Byte, m for milli, M for Mega...). Btw. I remember to all these strange mmH, µµF etc. when I collected rare inductors, capacitors revovered from vintage MIL- equipment in the end fifties/ early sixties of last century ... :-) I believe that Time Nuts prefer precise and clear expressions!? ;-) What do you think about it? waiting eagerly for the new issue of LH, regards Arnold