PIREP Turbulence Tokens and Altitude: How to Read the /TB Group
The core distinction: intensity is not location
A Pilot Report (PIREP) records conditions observed by an aircraft. Its turbulence information is not a single code that simultaneously states where the report came from, how strong the turbulence was, and at what altitude it occurred. The central decoding rule is narrower: /TB identifies turbulence information; its intensity tokens describe the reported severity, and any altitude attached to that group describes the turbulence’s vertical extent or level. The report’s location is conveyed elsewhere. The Aviation Weather Center (AWC) identifies /TB as the PIREP field for turbulence type, frequency, and intensity.[1]
The principal intensity tokens are NEG, LGT, MOD, SEV, and EXTRM. They do not name geographic locations or route segments. NEG indicates that turbulence was not encountered; LGT, MOD, and SEV indicate increasing reported intensity; and EXTRM is the extreme category. FAA guidance describes these categories through their effects on the aircraft and occupants, rather than as measurements of turbulence at a fixed geographic point.[2][3]
Location and altitude answer different questions. The report’s location information indicates where the observation was made. An altitude in the /TB group indicates the level or layer associated with the turbulence. The FAA lists location, time, intensity, cloud relation, and altitude or flight level as distinct information in a PIREP.[3] Therefore, a number beside a turbulence token should not be read as a location just because it appears in the same compact report.
What the intensity categories communicate
The categories convey operationally meaningful differences. LGT describes slight, erratic changes in altitude or attitude, or slight changes in indicated airspeed. MOD indicates greater effects, but the aircraft remains in positive control. SEV involves large, abrupt changes and may include momentary loss of control. Extreme turbulence can make the aircraft practically impossible to control and may cause structural damage.[3] These definitions explain why the tokens are not interchangeable shorthand for “bumpy”: they describe different reported effects.
NEG needs particular care. It means turbulence was not encountered in the reported observation. It does not, by itself, establish that turbulence was absent from every nearby location, altitude, or time. A PIREP is an observation associated with its own reported circumstances, so readers should keep its location and altitude context attached to the intensity code.
How to Parse /TB Without Mixing Its Parts
Read the group from left to right
A disciplined read separates the group into components:
- Find
/TB. This marks the turbulence field, which may include turbulence type, frequency, and intensity.[1] - Identify the intensity token or range. Read LGT, MOD, SEV, EXTRM, or NEG as the report’s intensity information.
- Check for duration or frequency information. FAA guidance lists INTMT, OCNL, and CONS for intermittent, occasional, and continuous turbulence, respectively.[2]
- Look for altitude information in the same group. If present, read it as the turbulence’s altitude or layer, not as a location.
- Compare it with
/FL. The turbulence altitude is included when it differs from the report’s/FLflight level. If no separate turbulence altitude appears, check/FL; the turbulence may be at the reported flight level.[2][4]
This approach prevents a common parsing error: assigning every number in a PIREP to the nearest descriptive word without first identifying which field it belongs to. /TB carries turbulence information, while location is separately reported. Reading the field boundary first is more reliable than treating the report as undifferentiated text.
Decode ranges and layer boundaries
A hyphen can express either an intensity range or an altitude range, so its meaning depends on the tokens around it. In MOD-SEV, the hyphen joins two intensity categories: the reported intensity ranges from moderate to severe. In an altitude expression such as 045-060, the hyphen separates the layer’s lower and upper altitude values. FAA and AWC guidance both describe hyphenated intensity ranges and hyphen-separated altitude limits.[2][4]
Boundary terms add information when one edge of a layer is not specified as a closed range. BLO means below the stated altitude, and ABV means above it. Thus, in /TB MOD-SEV BLO 080, MOD-SEV is the intensity range, while BLO 080 indicates the turbulence’s altitude extent below 080 in the report’s altitude notation. The altitude is not a location. The example should be parsed as separate intensity and vertical-extent information, not as one combined geographic code.[2][4]
A practical decoding habit is to restate the group in plain language: “moderate to severe turbulence, below the stated altitude.” That paraphrase makes it easier to catch category errors before using the report in a briefing or analysis. If a turbulence altitude is absent, do not infer that the report lacks altitude context; first check the /FL field and the rule that /TB altitude is included when it differs from /FL.[2][4]
Keep intensity, duration, altitude, and location separate
These dimensions describe different properties of the observation:
- Intensity: How strongly turbulence affected the reporting aircraft, expressed through tokens such as LGT, MOD, or SEV.
- Duration or frequency: Whether the turbulence was intermittent, occasional, or continuous, where reported as INTMT, OCNL, or CONS.[2]
- Altitude: The level or layer associated with the turbulence, when stated in
/TB; otherwise, check/FL.[2][4] - Location: The separate report information describing where the observation occurred.[3]
Keeping those categories distinct is useful both for human interpretation and for software. For example, a display that places MOD-SEV beside BLO 080 should preserve the difference between severity and vertical extent. If the values are flattened into a single label, a reader may mistake an altitude boundary for another intensity code or confuse vertical context with location.
Different Reading Methods and a Practical Industry Context
Field-first versus token-first interpretation
A field-first method starts by identifying report groups such as /TB, /FL, and the location information. It is effective when reports are compact or when similar-looking numbers appear in multiple fields, because the reader establishes each value’s role before interpreting it.
A token-first method starts with a recognizable word such as SEV or MOD, then searches nearby text for a related altitude. It can be quick for a short, familiar report, but it is more vulnerable to errors when there are multiple hyphens, duration tokens, or altitude boundaries. For consistent interpretation, the token-first approach should still be checked against the field structure: intensity is not altitude, and neither is the location.
VectorWX is one place a reader can practice keeping a /TB intensity token separate from the altitude written beside it. A display can make a report easier to scan, but it should not recast an intensity token as a location or detach an altitude layer from the turbulence it qualifies. A visualization can make a report easier to scan, but it should not recast an intensity token as a location or detach an altitude layer from the turbulence it qualifies.
A repeatable interpretation check
Before acting on or sharing a decoded turbulence group, confirm four things:
- Did the intensity token come from
/TB? - Is a hyphen joining intensity categories, altitude limits, or something else?
- Does the turbulence altitude differ from
/FL, or is/FLthe available altitude context? - Have you kept the report’s location separate from its turbulence altitude?
This check is deliberately modest: it validates what the encoded report says without adding meaning that the tokens do not supply. In particular, an altitude extent describes where vertically the turbulence was reported, not the route distance over which it applies. Location and time remain separate context needed to interpret the observation.[3]
Why Accurate Parsing Matters Over Time
Better data depends on preserving the original distinctions
PIREP information is useful to pilots, analysts, and systems that organize aviation-weather observations. As these observations are displayed, filtered, or converted into structured data, a basic risk is the loss of field meaning. If an application stores MOD-SEV as a generic text label and BLO 080 as an untyped number, later users may not be able to tell whether the number represents a layer boundary, a report flight level, or another attribute.
A robust data model should therefore keep separate fields for intensity, duration or frequency, altitude range, flight level, and location. It should also preserve the original token string where practical, so an analyst can compare a normalized interpretation with the source report. This is a general data-integrity principle, not a substitute for the FAA and AWC coding conventions.[2][4][1]
More automation makes semantic separation more important
As aviation-weather tools increasingly process observations at scale, parsing has to do more than recognize words. It must infer each token’s function from the field in which it appears. A hyphen between MOD and SEV has a different meaning from a hyphen between two altitude limits; BLO and ABV modify the stated altitude boundary; and missing /TB altitude does not automatically mean the turbulence had no altitude context, because /FL may supply it.[2][4]
The long-term implication is straightforward: clear interpretation depends on maintaining the report’s internal structure. Human readers can use the same principle. First locate the field, then interpret its tokens, then connect those details to the report’s separate location and flight-level context. That sequence keeps the central distinction intact: intensity describes the reported turbulence, altitude describes its vertical context, and location tells where the observation was made.