M0r13n__pyais-137

The user is reporting a bug in `pyais` regarding the determination of the communication status field (`is_sotdma` and `is_itdma`).
The issue is that the current implementation checks the 20th bit of the `radio` property to distinguish between SOTDMA and ITDMA. However, for some message types, the communication state is only 19 bits long, and checking the 20th bit actually checks a bit from the previous data field (e.g., the RAIM flag), leading to incorrect results.

The suggested solution is to use the message type to determine the communication status type, except for message types 9, 18, and 26, which can be either and should keep the current bit-checking logic.

Let's start by exploring the code. I need to find where `is_sotdma` and `is_itdma` are defined.
The problem statement mentions `decoded.get_communication_state()`, `decoded.is_sotdma`, and `decoded.is_itdma`.

I'll search for `is_sotdma` and `is_itdma` in the codebase.

{
  "command": "grep -rn --include=\"*.py\" \"is_sotdma\" ."
}

{
  "status": "ok",
  "stdout": "./pyais/messages.py:819:        if self.is_sotdma:\n./pyais/messages.py:827:    def is_sotdma(self) -> bool:\n./examples/communication_state.py:19:print(\"Communication state is SOTMDA:\", decoded.is_sotdma)\n./tests/test_decode.py:1393:        assert decoded.is_sotdma\n./tests/test_decode.py:1417:        assert decoded.is_sotdma\n./tests/test_decode.py:1441:        assert decoded.is_sotdma\n./tests/test_decode.py:1466:        assert not decoded.is_sotdma\n./tests/test_decode.py:1488:        assert decoded.is_sotdma\n./tests/test_decode.py:1514:        assert decoded.is_sotdma\n",
  "stderr": "",
  "exit_code": 0
}

Okay, it seems `is_sotdma` is defined in `pyais/messages.py` at line 827. Let's check that file. I also need to find `is_itdma`.

{
  "command": "grep -rn --include=\"*.py\" \"is_itdma\" ."
}

{
  "status": "ok",
  "stdout": "./pyais/messages.py:832:    def is_itdma(self) -> bool:\n./examples/communication_state.py:20:print(\"Communication state is ITDMA:\", decoded.is_itdma)\n./tests/test_decode.py:1394:        assert not decoded.is_itdma\n./tests/test_decode.py:1418:        assert not decoded.is_itdma\n./tests/test_decode.py:1442:        assert not decoded.is_itdma\n./tests/test_decode.py:1465:        assert decoded.is_itdma\n./tests/test_decode.py:1487:        assert not decoded.is_itdma\n./tests/test_decode.py:1513:        assert not decoded.is_itdma\n",
  "stderr": "",
  "exit_code": 0
}

Both are in `pyais/messages.py`. Let me read the relevant part of `pyais/messages.py`.

{
  "end_line": 840,
  "filepath": "pyais/messages.py",
  "start_line": 800
}

{
  "status": "ok",
  "filepath": "pyais/messages.py",
  "content": "    radio: int  # Type hint to make mypy happy\n\n    MAX_COMM_STATE_VALUE = 0x7ffff\n\n    def get_communication_state(self) -> Dict[str, typing.Optional[int]]:\n        \"\"\"Returns information used by the slot allocation algorithm as a dict.\"\"\"\n        result: Dict[str, typing.Optional[int]] = {\n            'received_stations': None,\n            'slot_number': None,\n            'utc_hour': None,\n            'utc_minute': None,\n            'slot_offset': None,\n            'slot_timeout': None,\n            'sync_state': None,\n            'keep_flag': None,\n            'slot_increment': None,\n            'num_slots': None,\n        }\n\n        if self.is_sotdma:\n            result.update(get_sotdma_comm_state(self.communication_state_raw))\n        else:\n            result.update(get_itdma_comm_state(self.communication_state_raw))\n\n        return result\n\n    @property\n    def is_sotdma(self) -> bool:\n        \"\"\"The radio status field has it's 20th bit (MSB) set to 0 or has less than 20 bits\"\"\"\n        return self.radio <= self.MAX_COMM_STATE_VALUE\n\n    @property\n    def is_itdma(self) -> bool:\n        \"\"\"The radio status field has it's 20th bit (MSB) set to 1\"\"\"\n        return self.radio > self.MAX_COMM_STATE_VALUE\n\n    @property\n    def communication_state_raw(self) -> int:\n        \"\"\"Get the raw radio status except 20th bit - if present\"\"\"\n        try:\n            return self.radio & self.MAX_COMM_STATE_VALUE",
  "start_line": 800,
  "end_line": 840,
  "total_lines": 1736,
  "is_truncated": false
}

Wait, these properties `is_sotdma` and `is_itdma` are defined on a class. Which class? Let me check the class definition higher up. I'll read more of `pyais/messages.py`.

{
  "end_line": 800,
  "filepath": "pyais/messages.py",
  "start_line": 750
}

{
  "status": "ok",
  "filepath": "pyais/messages.py",
  "content": "\n\ndef from_lat_lon_600(v: typing.Union[int, float]) -> float:\n    return round(float(v) * 600.0)\n\n\ndef to_lat_lon_600(v: typing.Union[int, float]) -> float:\n    return round(float(v) / 600.0, 6)\n\n\ndef from_10th(v: typing.Union[int, float]) -> float:\n    return float(v) * 10.0\n\n\ndef to_10th(v: typing.Union[int, float]) -> float:\n    return v / 10.0\n\n\ndef from_mmsi(v: typing.Union[str, int]) -> int:\n    return int(v)\n\n\ndef to_turn(turn: typing.Union[int, float]) -> typing.Union[float, TurnRate]:\n    if not turn:\n        return 0.0\n    elif abs(turn) == 127:\n        return TurnRate(turn)\n    elif abs(turn) == 128:\n        return TurnRate.NO_TI_DEFAULT\n\n    return math.copysign(round((turn / 4.733) ** 2), turn)\n\n\ndef from_turn(turn: typing.Optional[typing.Union[int, float, TurnRate]]) -> int:\n    if not turn:\n        return 0\n    elif abs(turn) == 127 or abs(turn) == 128:\n        return int(turn)\n\n    return int(math.copysign(round(4.733 * math.sqrt(abs(turn))), turn))\n\n\nclass CommunicationStateMixin:\n    \"\"\"\n    Mixin class to access Communication State values by applicable messages.\n\n    You may refer to 3.3.7.2.1 of:\n    https://www.itu.int/dms_pubrec/itu-r/rec/m/R-REC-M.1371-1-200108-S!!PDF-E.pdf\n    \"\"\"\n\n    radio: int  # Type hint to make mypy happy",
  "start_line": 750,
  "end_line": 800,
  "total_lines": 1736,
  "is_truncated": false
}

It's `CommunicationStateMixin`.

The problem description says:
"It is better to use the message type rather than the bit length to indicate the type of communication status. Table 46 of the M.1371-5 standard shows which type uses which com state. Type 9, 18 and 26 messages are edge cases, as they can include one of the two com state types. The existing implementation can be used here, as with these message types the bit before the actual com state determines its type."

So for most message types, we should use the type to decide if it's SOTDMA or ITDMA.
But wait, `CommunicationStateMixin` doesn't seem to know the message type directly unless the class it's mixed into has it.
Let's check which classes use `CommunicationStateMixin`.

{
  "command": "grep -rn \"class .*\\(CommunicationStateMixin\\)\" pyais/messages.py"
}

{
  "status": "ok",
  "stdout": "792:class CommunicationStateMixin:\n848:class MessageType1(Payload, CommunicationStateMixin):\n889:class MessageType4(Payload, CommunicationStateMixin):\n996:class MessageType9(Payload, CommunicationStateMixin):\n1141:class MessageType18(Payload, CommunicationStateMixin):\n1545:class MessageType26AddressedStructured(Payload, CommunicationStateMixin):\n1560:class MessageType26BroadcastStructured(Payload, CommunicationStateMixin):\n1574:class MessageType26AddressedUnstructured(Payload, CommunicationStateMixin):\n1589:class MessageType26BroadcastUnstructured(Payload, CommunicationStateMixin):\n",
  "stderr": "",
  "exit_code": 0
}

Okay, so MessageType1, 4, 9, 18, 26 are using `CommunicationStateMixin`.

Now I need to know which of these are always SOTDMA and which are always ITDMA, and which are the "edge cases" (9, 18, 26).

Wait, the problem says: "Table 46 of the M.1371-5 standard shows which type uses which com state."
It doesn't provide the table, but it says: "Type 9, 18 and 26 messages are edge cases... The existing implementation can be used here".

So for types 1 and 4, we should probably use a fixed value?
Wait, if I only have 1 and 4 left (besides 9, 18, 26), maybe type 1 is always SOTDMA and type 4 is always ITDMA? Or something like that?

Wait, "The current method of detecting and distinguishing communication status fields is not entirely reliable. For example, the following example incorrectly indicates that it is a SOTDMA communication status, although it is an ITDMA."

Example provided:
`pyais.decode('!AIVDM,1,1,,A,333ga6PP0jPPDUNM3I7DTOwDR59C,0*51')`

Let's see what message type this is.

{
  "command": "python3 - <<'PY'\nimport pyais\ndecoded = pyais.decode('!AIVDM,1,1,,A,333ga6PP0jPPDUNM3I7DTOwDR59C,0*51')\nprint(f\"Type: {decoded.msg_type}\")\nprint(f\"SOTDMA: {decoded.is_sotdma}, ITDMA: {decoded.is_itdma}\")\nprint(f\"Radio: {decoded.radio}\")\nPY\n"
}

{
  "status": "ok",
  "stdout": "Type: 3\nSOTDMA: True, ITDMA: False\nRadio: 21075\n",
  "stderr": "",
  "exit_code": 0
}

The example decodes to Type 3.
Wait, my previous search for `CommunicationStateMixin` showed:
`848:class MessageType1(Payload, CommunicationStateMixin):`
`889:class MessageType4(Payload, CommunicationStateMixin):`
`996:class MessageType9(Payload, CommunicationStateMixin):`
`1141:class MessageType18(Payload, CommunicationStateMixin):`
`1545:class MessageType26AddressedStructured(Payload, CommunicationStateMixin):`
...

I didn't see `MessageType3` in the grep output. Let me check `pyais/messages.py` for `MessageType3`.

{
  "command": "grep -rn \"class MessageType3\" pyais/messages.py"
}

{
  "status": "ok",
  "stdout": "880:class MessageType3(MessageType1):\n",
  "stderr": "",
  "exit_code": 0
}

Ah, `MessageType3` inherits from `MessageType1`. And `MessageType1` inherits from `CommunicationStateMixin`.

So for `MessageType3` (which inherits from `MessageType1`), it should be SOTDMA or ITDMA based on the type?
Wait, if Type 3 is an ITDMA message, then the current logic (which says it's SOTDMA) is wrong.

The problem says: "In the case of a type 1, 2 or 3 message, it would be checked whether the RAIM flag is set. Since 1 is the default value, pyais returns in almost all cases that it is a SOTDMA com state."
Wait, "Since 1 is the default value, pyais returns... SOTDMA".
`is_sotdma` is `self.radio <= self.MAX_COMM_STATE_VALUE`.
`MAX_COMM_STATE_VALUE` is `0x7ffff` (which is 2^19 - 1).
So if the 20th bit is 0, it's SOTDMA. If the 20th bit is 1, it's ITDMA.
If `radio` is 21075, it's definitely <= `0x7ffff` (131071).
So `is_sotdma` returns True.

But for Type 1, 2, 3, the radio status is only 19 bits. The 20th bit actually belongs to the previous field (RAIM flag).
So for Type 1, 2, 3, it should probably always be SOTDMA? No, the problem says: "the following example incorrectly indicates that it is a SOTDMA communication status, although it is an ITDMA." and the example is Type 3.
Wait. If Type 3 is ITDMA, then the logic for Type 1, 2, 3 should be different.

Wait, let me re-read: "Table 46 of the M.1371-5 standard shows which type uses which com state. Type 9, 18 and 26 messages are edge cases, as they can include one of the two com state types. The existing implementation can be used here, as with these message types the bit before the actual com state determines its type."

So for Types 1, 2, 3, 4, etc., we should use the message type.
But what is the mapping?
If the example is Type 3 and it should be ITDMA, then maybe Type 3 is ITDMA?
Wait, usually Type 1, 2, 3 are SOTDMA and Type 4 is ITDMA?
Let me check typical AIS specs.
Actually, the problem says "the following example incorrectly indicates that it is a SOTDMA communication status, although it is an ITDMA."
The example is Type 3.

Let me re-read carefully: "In the case of a type 1, 2 or 3 message, it would be checked whether the RAIM flag is set. Since 1 is the default value, pyais returns in almost all cases that it is a SOTDMA com state."
This means for Type 1, 2, 3, the `radio` field contains the RAIM flag as the MSB (the 20th bit).
Wait, if the RAIM flag is 1, then `radio > self.MAX_COMM_STATE_VALUE` would be true, which means `is_itdma` would be true.
But it says "Since 1 is the default value, pyais returns in almost all cases that it is a SOTDMA com state."
This is contradictory. If RAIM flag is 1, `radio` would be `1 << 19 | something`, which is `> 0x7ffff`. So it should be ITDMA.

Wait. Let me check `MAX_COMM_STATE_VALUE` again.
`MAX_COMM_STATE_VALUE = 0x7ffff` (19 bits of 1s).
If `radio` is `0x80000` (20th bit is 1), then `radio > self.MAX_COMM_STATE_VALUE` is True, so `is_itdma` is True.
If `radio` is `0x00000` (20th bit is 0), then `radio <= self.MAX_COMM_STATE_VALUE` is True, so `is_sotdma` is True.

The problem says: "In the case of a type 1, 2 or 3 message, it would be checked whether the RAIM flag is set. Since 1 is the default value, pyais returns in almost all cases that it is a SOTDMA com state."
This part of the problem description seems to have a mistake in its logic or I'm misinterpreting "RAIM flag is set".
If RAIM flag is 1, then `radio` should have the 20th bit set.

Wait, let me look at the example again.
`decoded = pyais.decode('!AIVDM,1,1,,A,333ga6PP0jPPDUNM3I7DTOwDR59C,0*51')`
`radio` was 21075.
`bin(21075)` is `'0b1010010//0110011'` (approx).
`21075` is `0x5253`.
`0x5253` is way less than `0x80000`.
So `is_sotdma` is True.
But the problem says it should be ITDMA.

If Type 3 should be ITDMA, then the rule is: if it's Type 1, 2, 3, we should just say it's SOTDMA? No, the example is Type 3 and it SHOULD be ITDMA.
Wait, if Type 1, 2, 3 should be ITDMA, then why does it say they are normally SOTDMA?

Let me re-read the problem again.
"For example, the following example incorrectly indicates that it is a SOTDMA communication status, although it is an ITDMA."
`decoded = pyais.decode('!AIVDM,1,1,,A,333ga6PP0jPPDUNM3I7DTOwDR59C,0*51')` -> Type 3.
"In the case of a type 1, 2 or 3 message, it would be checked whether the RAIM flag is set. Since 1 is the default value, pyais returns in almost all cases that it is a SOTDMA com state."
This means for Type 1, 2, 3, it's actually supposed to be SOTDMA or ITDMA regardless of that 20th bit? No.
If the RAIM flag is the 20th bit, and it's 1, `is_itdma` would be true.
But it says "since 1 is the default value, pyais returns ... SOTDMA".
This suggests that the RAIM flag is NOT the 20th bit of `radio`, or `radio` calculation is wrong.

Let's look at how `radio` is calculated.
I'll check `pyais/decode.py` or `pyais/messages.py` where the payload is decoded.

I'll search for how `radio` is set in `pyais/messages.py`.

{
  "command": "grep -rn \"self.radio =\" pyais/messages.py"
}

{
  "status": "error",
  "error_type": "CommandError",
  "error_message": "",
  "details": {
    "stdout": "",
    "stderr": "",
    "exit_code": 1
  }
}

Maybe it's in `pyais/decode.py`.

{
  "command": "grep -rn \"radio\" pyais/decode.py | head -n 20"
}

{
  "status": "ok",
  "stdout": "",
  "stderr": "",
  "exit_code": 0
}

That's weird. Let's search for "radio" in `pyais/messages.py` again, but using `grep -r`.

{
  "command": "grep -rn \"radio\" pyais/messages.py | head -n 20"
}

{
  "status": "ok",
  "stdout": "800:    radio: int  # Type hint to make mypy happy\n828:        \"\"\"The radio status field has it's 20th bit (MSB) set to 0 or has less than 20 bits\"\"\"\n829:        return self.radio <= self.MAX_COMM_STATE_VALUE\n833:        \"\"\"The radio status field has it's 20th bit (MSB) set to 1\"\"\"\n834:        return self.radio > self.MAX_COMM_STATE_VALUE\n838:        \"\"\"Get the raw radio status except 20th bit - if present\"\"\"\n840:            return self.radio & self.MAX_COMM_STATE_VALUE\n843:                'Communication State is only available for messages with radio field'\n869:    radio = bit_field(19, int, default=0, signed=False)\n910:    radio = bit_field(19, int, default=0, signed=False)\n1019:    radio = bit_field(20, int, default=0, signed=False)\n1166:    radio = bit_field(20, int, default=0)\n1556:    radio = bit_field(20, int, default=0, signed=False)\n1570:    radio = bit_field(20, int, default=0, signed=False)\n1585:    radio = bit_field(20, int, default=0, signed=False)\n1598:    radio = bit_field(20, int, default=0, signed=False)\n",
  "stderr": "",
  "exit_code": 0
}

Okay, look at those `bit_field` definitions:
`869:    radio = bit_field(19, int, default=0, signed=False)` (inside `MessageType1` likely)
`910:    radio = bit_field(19, int, default=0, signed=False)` (inside `MessageType4` likely)
`1019:    radio = bit_field(20, int, default=0, signed=False)` (inside `MessageType9` likely)
`1166:    radio = bit_field(20, int, default=0)` (inside `MessageType18` likely)
... and the others are also 20 bits.

So for `MessageType1` and `MessageType4`, `radio` is defined as 19 bits.
Wait, if `radio` is 19 bits, it will ALWAYS be `<= 0x7ffff`.
So `is_sotdma` will ALWAYS be True, and `is_itdma` will ALWAYS be False.
This explains why it always returns SOTDMA for Type 1, 2, 3 (since 2 and 3 inherit from 1).

But if it's Type 1, 2, 3, it should be... what? The problem says for the example (Type 3), it should be ITDMA.
Wait, if it's Type 1, 2, 3, it's ALWAYS one of them?
No, "Table 46 of the M.1371-5 standard shows which type uses which com state."

Let me search for information on AIS message types and communication status.
SOTDMA: Spontaneously organized Time Division Multiple Access.
ITDMA: Invitational Time Division Multiple Access.

According to some AIS specs:
Types 1, 2, 3: SOTDMA.
Type 4: ITDMA.
Wait, if Type 1, 2, 3 are SOTDMA, then the example (Type 3) should be SOTDMA.
But the problem says "the following example incorrectly indicates that it is a SOTDMA communication status, although it is an ITDMA."
This is very confusing. Let me re-read again.

"For example, the following example incorrectly indicates that it is a SOTDMA communication status, although it is an ITDMA.
```python
decoded = pyais.decode('!AIVDM,1,1,,A,333ga6PP0jPPDUNM3I7DTOwDR59C,0*51')
com = decoded.get_communication_state()
print(f"SOTDMA: {decoded.is_sotdma}, ITDMA: {decoded.is_itdma}")
```"
And the output of my reproduction was: `SOTDMA: True, ITDMA: False`.
So the problem says this is WRONG, and it should be `SOTDMA: False, ITDMA: True`.

But then it says: "In the case of a type 1, 2 or 3 message, it would be checked whether the RAIM flag is set. Since 1 is the default value, pyais returns in almost all cases that it is a SOTDMA com state."
This means the RAIM flag is being mistaken for the 20th bit of the communication status.

If the RAIM flag is 1, then `radio`'s 20th bit would be 1.
Wait, if `radio` is defined as `bit_field(19, ...)` for `MessageType1`, then the 20th bit is NOT part of `radio`. It's part of the field BEFORE `radio`.
Let's check `MessageType1` in `pyais/messages.py`.

{
  "end_line": 870,
  "filepath": "pyais/messages.py",
  "start_line": 840
}

{
  "status": "ok",
  "filepath": "pyais/messages.py",
  "content": "            return self.radio & self.MAX_COMM_STATE_VALUE\n        except AttributeError as err:\n            raise ValueError(\n                'Communication State is only available for messages with radio field'\n            ) from err\n\n\n@attr.s(slots=True)\nclass MessageType1(Payload, CommunicationStateMixin):\n    \"\"\"\n    AIS Vessel position report using SOTDMA (Self-Organizing Time Division Multiple Access)\n    Src: https://gpsd.gitlab.io/gpsd/AIVDM.html#_types_1_2_and_3_position_report_class_a\n    \"\"\"\n    msg_type = bit_field(6, int, default=1, signed=False)\n    repeat = bit_field(2, int, default=0, signed=False)\n    mmsi = bit_field(30, int, from_converter=from_mmsi)\n    status = bit_field(4, int, default=0, converter=NavigationStatus.from_value, signed=False)\n    turn = bit_field(8, float, default=TurnRate.NO_TI_DEFAULT, signed=True, to_converter=to_turn, from_converter=from_turn)\n    speed = bit_field(10, float, from_converter=from_speed, to_converter=to_speed, default=0, signed=False)\n    accuracy = bit_field(1, bool, default=0, signed=False)\n    lon = bit_field(28, float, from_converter=from_lat_lon, to_converter=to_lat_lon, default=0, signed=True)\n    lat = bit_field(27, float, from_converter=from_lat_lon, to_converter=to_lat_lon, default=0, signed=True)\n    course = bit_field(12, float, from_converter=from_10th, to_converter=to_10th, default=0, signed=False)\n    heading = bit_field(9, int, default=0, signed=False)\n    second = bit_field(6, int, default=0, signed=False)\n    maneuver = bit_field(2, int, default=0, from_converter=ManeuverIndicator.from_value,\n                         to_converter=ManeuverIndicator.from_value, signed=False)\n    spare_1 = bit_field(3, bytes, default=b'')\n    raim = bit_field(1, bool, default=0)\n    radio = bit_field(19, int, default=0, signed=False)\n",
  "start_line": 840,
  "end_line": 870,
  "total_lines": 1736,
  "is_truncated": false
}

Yes! `raim` is a 1-bit field, and it is immediately followed by `radio` (19 bits).
So if we consider the combination of `raim` and `radio` as a 20-bit value, then the `raim` bit is the MSB.

If `raim` is 1, then the combined value is `(1 << 19) | radio`.
This combined value is `> 0x7ffff`.
So the current implementation of `is_itdma` (which’s `self.radio > self.MAX_COMM_STATE_value`) is almost correct IF `radio` included the RAIM bit.
But `radio` is only 19 bits. So `self.radio > 0x7ffff` is ALWAYS False.

Wait, the problem says "since 1 is the default value, pyais returns in almost all cases that it is a SOTDMA com state."
This is still confusing. If `radio` is only 19 bits, it's ALWAYS SOTDMA.
If the current code is:
```python
    @property
    def is_sotdma(self) -> bool:
        return self.radio <= self.MAX_COMM_STATE_VALUE
```
Then for `MessageType1`, `self.radio` is always 0-131071, and `MAX_COMM_STATE_VALUE` is 131071.
So `is_sotdma` is always True.

If the problem says "the following example incorrectly indicates that it is a SOTDMA communication status, although it is an ITDMA," it means for Type 3, it should be ITDMA.

But wait, the "Solution" says: "It is better to use the message type rather than the bit length to indicate the type of communication status. Table 46 of the M.1371-5 standard shows which type uses which com state."

So I need to know which message types are SOTDMA and which are ITDMA.
Commonly:
Type 1, 2, 3: SOTDMA
Type 4: ITDMA
Type 9: either
Type 18: either
Type 26: either

Wait, if Type 1, 2, 3 are SOTDMA, then why is the example (Type 3) supposed to be ITDMA?
Let me re-read: "For example, the following example incorrectly indicates that it is a SOTDMA communication status, although it is an ITDMA."
Example: `!AIVDM,1,1,,A,333ga6PP0jPPDUNM3I7DTOwDR59C,0*51` -> Type 3.

Wait, maybe I'm wrong about Type 1, 2, 3 always being SOTDMA?
Let's look at the example message again.
SOTDMA is "Self-Organized", ITDMA is "Invitational".
Usually, Type 1, 2, 3 are SOTDMA. But can they be ITDMA?

Let me look at the `CommunicationStateMixin` again.
The current implementation uses the 20th bit of `radio` to decide.
But `MessageType1` defines `radio` as 19 bits.
`MessageType4` defines `radio` as 19 bits.
`MessageType9` defines `radio` as 20 bits.
`MessageType18` defines `radio` as 20 bits.
`MessageType26` defines `radio` as 20 bits.

Wait, if `MessageType1` and `MessageType4` have `radio` as 19 bits, they will ALWAYS be SOTDMA with the current code.
But Type 4 should probably be ITDMA?
Let's check `MessageType4` in `pyais/messages.py`.

{
  "command": "grep -n \"class MessageType4\" pyais/messages.py"
}

{
  "status": "ok",
  "stdout": "889:class MessageType4(Payload, CommunicationStateMixin):\n",
  "stderr": "",
  "exit_code": 0
}

Let's read `MessageType4`.

{
  "end_line": 920,
  "filepath": "pyais/messages.py",
  "start_line": 880
}

{
  "status": "ok",
  "filepath": "pyais/messages.py",
  "content": "class MessageType3(MessageType1):\n    \"\"\"\n    AIS Vessel position report using ITDMA (Incremental Time Division Multiple Access)\n    Src: https://gpsd.gitlab.io/gpsd/AIVDM.html#_types_1_2_and_3_position_report_class_a\n    \"\"\"\n    msg_type = bit_field(6, int, default=3)\n\n\n@attr.s(slots=True)\nclass MessageType4(Payload, CommunicationStateMixin):\n    \"\"\"\n    AIS Vessel position report using SOTDMA (Self-Organizing Time Division Multiple Access)\n    Src: https://gpsd.gitlab.io/gpsd/AIVDM.html#_type_4_base_station_report\n    \"\"\"\n    msg_type = bit_field(6, int, default=4, signed=False)\n    repeat = bit_field(2, int, default=0, signed=False)\n    mmsi = bit_field(30, int, from_converter=from_mmsi)\n    year = bit_field(14, int, default=1970, signed=False)\n    month = bit_field(4, int, default=1, signed=False)\n    day = bit_field(5, int, default=1, signed=False)\n    hour = bit_field(5, int, default=0, signed=False)\n    minute = bit_field(6, int, default=0, signed=False)\n    second = bit_field(6, int, default=0, signed=False)\n    accuracy = bit_field(1, bool, default=0, signed=False)\n    lon = bit_field(28, float, from_converter=from_lat_lon, to_converter=to_lat_lon, signed=True, default=0)\n    lat = bit_field(27, float, from_converter=from_lat_lon, to_converter=to_lat_lon, signed=True, default=0)\n    epfd = bit_field(4, int, default=0, from_converter=EpfdType.from_value, to_converter=EpfdType.from_value,\n                     signed=False)\n    spare_1 = bit_field(10, bytes, default=b'')\n    raim = bit_field(1, bool, default=0)\n    radio = bit_field(19, int, default=0, signed=False)\n\n\n@attr.s(slots=True)\nclass MessageType5(Payload):\n    \"\"\"\n    Static and Voyage Related Data\n    Src: https://gpsd.gitlab.io/gpsd/AIVDM.html#_type_5_static_and_voyage_related_data\n    \"\"\"\n    msg_type = bit_field(6, int, default=5, signed=False)\n    repeat = bit_field(2, int, default=0, signed=False)",
  "start_line": 880,
  "end_line": 920,
  "total_lines": 1736,
  "is_truncated": false
}

Wait! Look at the docstrings!
`MessageType3`: "AIS Vessel position report using ITDMA"
`MessageType1`: "AIS Vessel position report using SOTDMA"
`MessageType4`: "AIS Vessel position report using SOTDMA" (Wait, the docstring for MessageType4 says SOTDMA? That's weird. Usually Type 4 is a base station report, so it should be ITDMA).

Let me re-read the docstrings carefully.
Line 881: `class MessageType3(MessageType1):`
Line 882: `    """AIS Vessel position report using ITDMA (Incremental Time Division Multiple Access)`

Wait, `MessageType1` docstring (line 848): `AIS Vessel position report using SOTDMA`
And `MessageType3` docstring (line 882): `AIS Vessel position report using ITDMA`
And `MessageType4` docstring (line 895): `AIS Vessel position report using SOTDMA`

This is confusing as hell. Usually, Type 1, 2, 3 are SOTDMA and Type 4 is ITDMA.
But here the docstrings say:
Type 1: SOTDMA
Type 3: ITDMA
Type 4: SOTDMA

Let's trust the problem description: "In the case of a type 1, 2 or 3 message, it would be checked whether the RAIM flag is set."
Actually, let's re-read: "It is better to use the message type rather than the bit length to indicate the type of communication status."

If I use the message type, I need to know the mapping.
The problem says: "Type 9, 18 and 26 messages are edge cases, as they can include one of the two com state types. The existing implementation can be used here".

What about the others?
If the example is Type 3 and it's ITDMA, then Type 1, 2, 3 might be... no, that can't be right.
Actually, let's look at the example again.
Type 3 was ITDMA.
If Type 3 is ITDMA, maybe Type 1, 2, 3 are all ITDMA?
No, Type 1 is listed as SOTDMA in the docstring.

Let's look at the `CommunicationStateMixin` again.
```python
    @property
    def is_sotdma(self) -> bool:
        """The radio status field has it's 20th bit (MSB) set to 0 or has less than 20 bits"""
        return self.radio <= self.MAX_COMM_STATE_VALUE

    @property
    def is_itdma(self) -> bool:
        """The radio status field has it's 20th bit (MSB) set to 1"""
        return self.radio > self.MAX_COMM_STATE_VALUE
```
And `MessageType1` and `MessageType4` have `radio = bit_field(19, ...)`.
So they are ALWAYS `is_sotdma == True`.

But if Type 1, 2, 3 are SOTDMA and Type 4 is ITDMA, then:
Type 1, 2, 3: `is_sotdma = True`
Type 4: `is_itdma = True`

But the example is Type 3 and it should be ITDMA!
This means my assumption about Type 1, 2, 3 being SOTDMA is wrong for this library's context or for general AIS.

Wait, I have the docstrings!
Type 1: SOTDMA
Type 3: ITDMA
Type 4: SOTDMA (Wait, Type 4 docstring says SOTDMA too)

Let me check `MessageType2`.

{
  "command": "grep -n \"class MessageType2\" pyais/messages.py"
}

{
  "status": "ok",
  "stdout": "872:class MessageType2(MessageType1):\n1203:class MessageType20(Payload):\n1235:class MessageType21(Payload):\n1268:class MessageType22Addressed(Payload):\n1299:class MessageType22Broadcast(Payload):\n1330:class MessageType22(Payload):\n1357:class MessageType23(Payload):\n1386:class MessageType24PartA(Payload):\n1397:class MessageType24PartB(Payload):\n1417:class MessageType24(Payload):\n1450:class MessageType25AddressedStructured(Payload):\n1464:class MessageType25BroadcastStructured(Payload):\n1477:class MessageType25AddressedUnstructured(Payload):\n1490:class MessageType25BroadcastUnstructured(Payload):\n1501:class MessageType25(Payload):\n1545:class MessageType26AddressedStructured(Payload, CommunicationStateMixin):\n1560:class MessageType26BroadcastStructured(Payload, CommunicationStateMixin):\n1574:class MessageType26AddressedUnstructured(Payload, CommunicationStateMixin):\n1589:class MessageType26BroadcastUnstructured(Payload, CommunicationStateMixin):\n1601:class MessageType26(Payload):\n1645:class MessageType27(Payload):\n",
  "stderr": "",
  "exit_code": 0
}

`MessageType2` inherits from `MessageType1`.

If I follow the docstrings:
Type 1: SOTDMA
Type 2: SOTDMA (inherits from Type 1)
Type 3: ITDMA
Type 4: SOTDMA (docstring says so)
Wait, this is very strange.

Let's re-read the problem one more time.
"In the case of a type 1, 2 or 3 message, it would be checked whether the RAIM flag is set."
Wait, it says "In the case of a type 1, 2 or 3 message".
And "Since 1 is the default value, pyais returns in almost all cases that it is a SOTDMA com state."
If RAIM flag is 1, it returns SOTDMA?
But we saw that if `radio` is only 19 bits (which it is for Type 1, 2, 3), `is_sotdma` is ALWAYS True.
So regardless of the RAIM flag, it always returns SOTDMA.
This matches "pyais returns in almost all cases that it is a SOTDMA com state."

And for the example (Type 3), it should be ITDMA.
Does this mean if it's Type 1, 2, 3, we should check the RAIM flag?
No, the "Solution" says: "It is better to use the message type rather than the bit length to indicate the type of communication status."

So for Type 1, 2, 3 we should use something else.
Wait, if it's Type 1, 2, 3, is it ALWAYS SOTDMA? No, the example says Type 3 can be ITDMA.

Let me think. If it's Type 1, 2, 3, the `radio` field is 19 bits.
What if we include the RAIM flag?
In `MessageType1`:
`raim = bit_field(1, bool, default=0)`
`radio = bit_field(19, int, default=0, signed=False)`
If we combine them: `(int(self.raim) << 19) | self.radio`.
Then we check if this 20-bit value has the 20th bit set.
But the 20th bit IS the RAIM flag!
So if `raim` is 1, then `(int(self.raim) << 19) | self.radio` is `> 0x7ffff`, so it's ITDMA.
If `raim` is 0, it's SOTDMA.

Wait, does this match "In the case of a type 1, 2 or 3 message, it would be checked whether the RAIM flag is set. Since 1 is the default value, pyais returns in almost all cases that it is a SOTDMA com state."?
No, because if RAIM is 1, and we check the RAIM flag, it should be ITDMA.
But the problem says "Since 1 is the default value, pyais returns ... SOTDMA".
This means currents as-is it's SOTDMA even when RAIM is 1.
And we want it to be ITDMA when RAIM is 1?
No, "the following example incorrectly indicates that it is a SOTDMA communication status, although it is an ITDMA."
Example: `!AIVDM,1,1,,A,333ga6PP0jPPDUNM3I7DTOwDR59C,0*51` -> Type 3.
In this example, let's see if `raim` is 1.

{
  "command": "python3 - <<'PY'\nimport pyais\ndecoded = pyais.decode('!AIVDM,1,1,,A,333ga6PP0jPPDUNM3I7DTOwDR59C,0*51')\nprint(f\"RAIM: {decoded.raim}\")\nPY\n"
}

{
  "status": "ok",
  "stdout": "RAIM: True\n",
  "stderr": "",
  "exit_code": 0
}