Requesting new Decibels (dB) Unit in Udunits Database

[jplpodaac]

Various data producers in the NASA earth remote sensing community are requesting a standard unit to represent Decibels (dB) for Radar data, such as for scatterometers, altimeters, and synthetic aperture radars. Having these units available in the standardized Udunits database would provide a significant contribution toward data provenance and would likewise help meet CF compliance standards, which many NASA data producers are making significant efforts to achieve.

More details in defining this unit can be provided as needed.

This request corresponds to Unidata ticket #VZX-973749.

[semmerson]

Are you OK with such units only being useful for changes in a physical quantity.

[jplpodaac]

First, it should be understood that dB is not a geophysical quantity, but rather an indirectly measured quantity derived from either Watts or Volts representing the return power (or energy) from a surface or reflectance or scatter. A radar equation is used to convert the return power to a normalized derived quantity known as sigma naught (i.e., the normalized radar cross section), which is represented in units of dB.

What we're looking for here is a standardized unit to express sigma naught.

Ultimately, there are changes in sigma naught just like any other remotely sensed quantity.

However, the major advantage I see here is having a standardized unit that allows scientists to determine relationships (including differences in sensor calibrations) between various active microwave sensors that are retrieving sigma naught in a common standardized unit of measurement.

[semmerson]

Are you aware that the UDUNITS-2 units database contains the unit "Bz", which is a logarithmic unit for radar reflectivity from rain? It's reference level is one cubic micron and its definition is lg(re (1e-6 m)^3). The UDUNITS-2 package can, consequently, already convert values in "dBz" to compatible units.

Such units can be easily added to the units database. The major difficulty is creating a unique but meaningful suffix for the "B".

Is this what you're interested in?

[jplpodaac]

That's quite interesting, but unfortunately I don't think this relationship applies to Sigma-0. Bz is related to dBz, as my understanding that the "z" is relative to the size of the droplet being measured. This is useful for data derived from ground-based doppler radar systems for weather applications with the goal of assessing cloud and precipitation droplet sizes.

What I'm describing is an entirely different application: space-based observation platforms in which the surface of the Earth is being observed through surface reflectance through backscattering in which droplets and droplet sizes within the atmosphere are not observed.

The primary difference between dBz and dB as expressed by Sigma-0 is that dB is normalized to the spatial area representing the footprint of the radar pulse on the ground.

Furthermore, dB doesn't have a common reference level because there are different altitudes, and scanning geometries, and sizes of the aperture that all determine various footprint sizes. Hence, dB is normalized according to each radar pulse, which allows for relatively consistent calibration and comparison with other space borne radar (i.e., altimeter, scatterometer, SAR) systems.

In summary, dB cannot be derived from dBz because these space borne radar systems are measuring a fundamentally different quantity.

[semmerson]

I don't think we're understanding each other.

My point wasn't that the "Bz" unit might already satisfy your needs; rather, that logarithmic units (but for different physical quantities and with different reference levels) can be easily added by the user to the UDUNITS-2 unit database. The definition of the "Bz" unit is lg(re (1e-6 m)^3) (you'll find it in the file udunits2-common.xml). One could easily have another file (for example udunits2-local.xml) that contained definitions of your choosing for other logarithmic units. The reason the UDUNITS-2 package comes with the "Bz" unit defined is because we support meteorology (among other disciplines).

[jplpodaac]

I see your point. I should note that the dB I am referring to is actually a dimensionless quantity that is merely meant for logarithmic scaling.

So I think in principal what you are suggesting is supportive of our goal in correctly representing the unit of dB. I'm working with a group of individuals within NASA to construct a definition for dB based upon your example of Bz. I should have a draft to send your way by the end of this week.

[mhidas]

@semmerson @jplpodaac Has there been any progress on this? I work with ocean data, and we also have some decibels.

[jplpodaac]

@mhidas There was some progress a few months back with offline email discussions I had had with experts in the radar/scatterometer science community, but I haven't had the time to push that forward to a consensus on the formalized definition of dB as it applies to space-borne radar scatterometry.

I will need some time to revisit this and get some final closure to it.

Thank you for the followup.

[mhidas]

Would it be possible to have a "generic" decibel, just defined as "lg(re reference_value)", with the reference value to be defined separately?

[jplpodaac]

Perhaps. Can you give me an example of how this might be cited in the variable attributes?

[semmerson]

The UDUNITS package currently only supports logarithmic units that have a reference level. Unreferenced logarithmic units would not be appropriate for absolute physical quantities but would be appropriate for changes in a physical quantity (e.g., increases in power).

Adding such units should be straightforward though non-trivial and has been on my to-do list for this package for several years. Unfortunately, there are higher-priority items on that list.

[mhidas]

@jplpodaac To me it's somewhat analogous to the way we specify vertical location in marine data. We might measure depth in metres, but to specify the location, we also need a reference point, so our depth variable has two attributes: units = "metres" and reference_datum = "sea surface".

So perhaps for the "Bz" example above, instead of defining a specific unit that includes the reference value, we could have units = "dB" (defined as "lg(re reference_value)") and reference_value = "(1e-6 m)^3".

Another alternative would be to have the reference value in the actual unit name (not just the definition), e.g. units = "dB re (1e-6 m)^3". This is analogous to the way time units can be specified (e.g. days since 1950-01-01T00:00:00Z).

[jplpodaac]

@semmerson This has been simmering for almost 2 years now, so I was wondering if I could get a status update as whether we can now start adding dB unto UDUNITS. What more do you need from me to get started?

[lesserwhirls]

@semmerson - this is being discussed again on the CF Metadata list. By any chance has there been work done in UDUNITS on this?

[semmerson]

I'm aware of the issue. The problem is finding the time.

[lesserwhirls]

Thanks for the update @semmerson

[martinjuckes]

Hello @semmerson, I'm just joining the discussion here from the CF Metadata list that @lesserwhirls refers to above. Have you decided on an approach you want to follow when (or if) you find time? I've been doing some background reading and discovered that the IEC 60027 recognise a syntax of the form 6 dB (1 W) (the space between dB and (1 W) is important to them because the reference level is not considered as part of the unit). There is a slight complication in that the interpretation is different depending on whether the parameter is a "field" or a "power". If you want to follow this approach I suppose you would need to decide whether it is a "field" or "power" from the units of the reference level.

[semmerson]

Yes, I have thought about this a little. The goal would be to create an unreferenced logarithmic unit, "UnrefLogUnit", that would only be convertible with other unreferenced logarithmic units.

Hmm... Units like "6 dB (1 W)" might be tricky as it could easily be interpreted by the parser as a sequence of terms to be multiplied together. Probably need to enhance the parser's grammar.

[martinjuckes]

OK, "UnrefLogUnit" (with symbol "B"?) on its own would probably be enough for the current CF use cases. The IEC standard stresses that reference levels are not part of the definition of the unit, so leaving them out of UDUNITS and leaving it to the upstream applications would be a consistent approach.

[semmerson]

"UnrefLogUnit" would be a programmatic type of unit (Like BaseUnit or DerivedUnit). The symbol "B" would cause the parser to create such a unit if there was no subsequent reference value.

[jplpodaac]

It's nice to see some life brought back to this discussion. I would like to point out, that there still remains a lot of interest in the space-based remote sensing community on having dB as an officially recognized unit by UDUNITS for CF metadata representation. Even though dB is not yet officially recognized by UDUNITS, there's been a number of examples of its use. Here are some examples (as expressed via OPeNDAP links):

1. See "sigma0" and "sigma0_attn_map"; https://opendap.jpl.nasa.gov/opendap/allData/rapidscat/L2A/12km/v1.3/2016/042/RS_S2A07873.20162571504.CP12.gz.html
2. See "ddm_snr", "direct_signal_snr", "lna_noise_figure" variables: https://opendap.jpl.nasa.gov/opendap/allData/cygnss/L1/v2.1/2018/001/cyg01.ddmi.s20180101-000000-e20180101-235959.l1.power-brcs.a21.d21.nc.html
3. See "sig0_ku", "sig0_c", "net_instr_corr_sig0_ku", "net_instr_corr_sig0_c", "atmos_corr_sig0_ku", variables: https://opendap.jpl.nasa.gov/opendap/hyrax/allData/jason1/L2/gdr_netcdf_e/c001/JA1_GPN_2PeP001_002_20020115_060706_20020115_070316.nc.html

For the first example above (QuikSCAT scatterometer data), the sigma0 data variable was the primary motivation behind the initial request for dB units. For details, see the earlier posts above.

In the second example above (Cyclone Global Navigation Satellite System), there are other variations of dB that are in use, such as dBi (receive antenna gain) and dBW (transmit power). The variable metadata for CYGNSS does a pretty good job explaining the data variables in use for this example, but please let me know if you have more questions on those variables.

The 3rd example comes from the altimetry method of remote sensing, using both a C-band and Ku-band radar pointing at nadir, from the Jason-1 mission. Sigma-0 retrievals are very similar to the scatterometry example provided by QuikSCAT.

There are many more dataset examples than this, but I just thought I would provide this for more of a real-world illustration of dB that is currently in use by the operational and research science communities.

[jplpodaac]

For the previous post, I meant to say RapidScat, not QuikSCAT. Nonetheless, RapidScat and QuikSCAT share an identical instrument, just different mounting platforms. The data formatting is identical for both.

[mhidas]

Likewise, there is still interest in unreferenced logarithmic units (ideally referred to as "dB" or "decibel") in the marine observations domain. It is mainly used in reporting some ancillary data from acoustic Doppler current profilers (ADCP). These are ratios (e.g. "signal_noise_ratio_from_acoustic_beam_1" or "backscatter_intensity_from_acoustic_beam_1") so the reference value is "1". For an example, see variables like SNR1 and ABS1 in the file here (e.g. this file).

[jplpodaac]

@semmerson , Thank you for revisiting this, and I am more than happy to work with you toward a resolution that satisfies these many data types, which as you can see, are already in public distribution. Please let me know if there's any more information I can provide to help in the formal adoption and definition of dB/Decibels.

[semmerson]

Information and adoption aren't the problem. Time is.

[lesserwhirls]

I can understand that time is a precious resource. Would you have an estimate of when you think you might be able to get to it?

[semmerson]

I'm currently behind on my LDM7 NSF grant. It expires next April.

[martinjuckes]

It looks as though the changes needed are covered in pull request https://github.com/Unidata/UDUNITS-2/pull/42 : could that be accepted? Apologies for the naive question, it looks like a few simple edits to the udunits2-common.xml file, but I appreciate that it could involve much more than that.

[semmerson]

Not even close. The pull-request merely adds a new, referenced, logarithmic unit: it doesn't address the need for unreferenced logarithmic units at all.

[mhidas]

Maybe I'm missing something, but this (part of #42) looks to me like an "unreferenced" logarithmic unit:

        <unit>
             <def>lg(re 1)</def>
             <aliases> <symbol>B</symbol> </aliases>
             <definition>logarithmic unit used to express dimensionless ratios; a value of 0 B (0 dB) corresponds to a ratio of 1</definition>
        </unit>

From my perspective, the only addition we need is the name "bel" for this unit.

[semmerson]

Hmm... You might be right. I'll have to think about it.