Closed master131 closed 1 year ago
Currently I only have access to the 2003 version where these bits are marked RFU (reserved for future use). I guess that future is now :)
Currently I only have access to the 2003 version where these bits are marked RFU (reserved for future use). I guess that future is now :)
Just sent you a message via Twitter.
These fields are now decoded and printed as-is. It takes a bit of post-processing to combine these with the location table number, if needed. One option would be to always print these values alongside the LTN, if available.
Just wondering if it were possible to include the LTCC (Location Table Country Code) and LTECC (Location Table Extended Country Code) as per the ISO 14819-1 standard in the redsea JSON output?
The document says for ODA CD46 & CD47, when the variant is equal to 1 (TMCService::receiveSystemGroup), and M [mode of transmission] = 0 (basic) (bit 4, referred to as enhanced_mode in code), LTCC is provided in bits 0-3 (4-bit value). In almost all cases, LTCC will equal PICC (last 4 bits of PI) but ISO 14819-1 notes that this can deviate so long as a service agreement has been signed with TISA (due to backward compatibility issues for tuners built against the ≤2003 standard).
LTECC is located in bits 0-7 (8-bit value) when the variant is equal to 2 and M = 0. From what I've seen, variant 2 is not used in most countries but there is this RDS Spy capture from the USA which has this variant in use: https://github.com/walczakp/rds-spy-logs/blob/master/USA/4569%20-%202020-08-19%2020-45-06.spy
In the above example, PICC is 0x5, however the LTCC is 0x1 and LTECC is 0xA0 (United States) which affects how RDS-TMC tuners will lookup the country code against their access profiles.
Additionally, with both values the country can also be identified just what is already being done in type 1A groups.
There might be some noise or some providers that omit this information, probably have to check that LTCC and LTECC are non-zero.