fix docs

docs/ble_api.rst

@@ -38,14 +38,14 @@ Restricted RF24 functionality
 The following `RF24` functionality should not be used when `FakeBLE`
 objects are instantiated with an `RF24` object:
 
-- :py:attr:`~pyrf24.rf24.RF24.dynamic_payloads`
-- :py:attr:`~pyrf24.rf24.RF24.data_rate`
-- :py:attr:`~pyrf24.rf24.RF24.address_width`
-- :py:meth:`~pyrf24.rf24.RF24.set_auto_ack()`
-- :py:attr:`~pyrf24.rf24.RF24.ack_payloads`
-- :py:attr:`~pyrf24.rf24.RF24.crc_length`
-- :py:meth:`~pyrf24.rf24.RF24.open_rx_pipe()`
-- :py:meth:`~pyrf24.rf24.RF24.open_tx_pipe()`
+- :py:attr:`~pyrf24.RF24.dynamic_payloads`
+- :py:attr:`~pyrf24.RF24.data_rate`
+- :py:attr:`~pyrf24.RF24.address_width`
+- :py:meth:`~pyrf24.RF24.set_auto_ack()`
+- :py:attr:`~pyrf24.RF24.ack_payloads`
+- :py:attr:`~pyrf24.RF24.crc_length`
+- :py:meth:`~pyrf24.RF24.open_rx_pipe()`
+- :py:meth:`~pyrf24.RF24.open_tx_pipe()`
 
 
 Service related classes

docs/conf.py

@@ -175,7 +175,7 @@
 ]
 
 python_type_aliases = {
-    "pyrf24.rf24.rf24_datarate_e": "rf24_datarate_e",
+    "pyrf24.rf24_datarate_e": "rf24_datarate_e",
 }
 
 # Set link name generated in the top bar.

docs/rf24_api.rst

@@ -3,37 +3,37 @@
 RF24 API
 ========
 
-.. automodule:: pyrf24.rf24
+.. currentmodule:: pyrf24
 
-    .. autoattribute:: pyrf24.rf24.RF24_DRIVER
+.. autoattribute:: pyrf24.RF24_DRIVER
 
-        This `str` describes the backend driver used to build the pyrf24 package.
-        If installed from pypi, then this value should be ``"SPIDEV"``.
-        
-        All other drivers imply that the pyrf24 package was built from source
-        :ref:`using-specific-driver`.
+    This `str` describes the backend driver used to build the pyrf24 package.
+    If installed from pypi, then this value should be ``"SPIDEV"``.
+
+    All other drivers imply that the pyrf24 package was built from source
+    :ref:`using-specific-driver`.
 
-        .. hint::
+    .. hint::
 
-            Use this attribute to determine programmatically which pin numbers to use.
-            Drivers like ``wiringPi`` and ``MRAA`` use their own pin numbering scheme.
+        Use this attribute to determine programmatically which pin numbers to use.
+        Drivers like ``wiringPi`` and ``MRAA`` use their own pin numbering scheme.
 
 Enum classes
 ------------
 
-.. autoclass:: pyrf24.rf24.rf24_crclength_e
+.. autoclass:: pyrf24.rf24_crclength_e
     :members: RF24_CRC_DISABLED, RF24_CRC_8, RF24_CRC_16
 
-.. autoclass:: pyrf24.rf24.rf24_datarate_e
+.. autoclass:: pyrf24.rf24_datarate_e
     :members: RF24_1MBPS, RF24_2MBPS, RF24_250KBPS
 
-.. autoclass:: pyrf24.rf24.rf24_pa_dbm_e
+.. autoclass:: pyrf24.rf24_pa_dbm_e
     :members: RF24_PA_MIN, RF24_PA_LOW, RF24_PA_HIGH, RF24_PA_MAX
 
 RF24 class
 ----------
 
-.. autoclass:: pyrf24.rf24.RF24
+.. autoclass:: pyrf24.RF24
 
     Basic RF24 API
     **************

docs/rf24_mesh_api.rst

@@ -3,12 +3,12 @@
 RF24Mesh API
 ============
 
-.. automodule:: pyrf24.rf24_mesh
+.. currentmodule:: pyrf24
 
 RF24Mesh class
 **************
 
-.. autoclass:: pyrf24.rf24_mesh.RF24Mesh
+.. autoclass:: pyrf24.RF24Mesh
 
     Basic RF24Mesh API
     ------------------
@@ -43,7 +43,7 @@ successful connection to a child node.
     The `AddrListStruct` class supports the python "magic method" :py:func:`repr()`. So, you can
     easily pass an instantiated `AddrListStruct` object to the :py:func:`print()` function.
 
-.. autoclass:: pyrf24.rf24_mesh.AddrListStruct
+.. autoclass:: pyrf24.AddrListStruct
 
     .. autoattribute:: node_id
     .. autoattribute:: address
@@ -53,30 +53,30 @@ Mesh Constants
 
 These are the pre-defined constants provided for convenience and code readability.
 
-.. autoattribute:: pyrf24.rf24_mesh.MESH_DEFAULT_ADDRESS
+.. autoattribute:: pyrf24.MESH_DEFAULT_ADDRESS
 
     A reserved valid address for use with RF24Mesh (when a mesh node requests an assigned address)
 
 Reserved System Message Types
 -----------------------------
 
-.. autoattribute:: pyrf24.rf24_mesh.MESH_ADDR_LOOKUP
+.. autoattribute:: pyrf24.MESH_ADDR_LOOKUP
 
     This message type is used to fetch (from the master node) an allocated Logical
     Address (`mesh_address`) corresponding to specified a mesh node's
     :py:attr:`~RF24Mesh.node_id`.
 
     This is exclusively used by `get_address()`.
 
-.. autoattribute:: pyrf24.rf24_mesh.MESH_ID_LOOKUP
+.. autoattribute:: pyrf24.MESH_ID_LOOKUP
 
     This message type is used to fetch (from the master node) a mesh node's
     :py:attr:`~RF24Mesh.node_id` corresponding to an specified Logical Address
     (`mesh_address`).
 
     This is exclusively used by `get_node_id()`.
 
-.. autoattribute:: pyrf24.rf24_mesh.MESH_ADDR_RELEASE
+.. autoattribute:: pyrf24.MESH_ADDR_RELEASE
 
     This message type is used when mesh nodes are consciously disconnecting from the
     network. It is used to unassign the Logical Address allocated the mesh node's

docs/rf24_network_api.rst

@@ -3,13 +3,13 @@
 RF24Network API
 ===============
 
-.. automodule:: pyrf24.rf24_network
+.. currentmodule:: pyrf24
 
 RF24Network class
 -----------------
 
 
-.. autoclass:: pyrf24.rf24_network.RF24Network
+.. autoclass:: pyrf24.RF24Network
 
     Basic RF24Network API
     *********************
@@ -36,8 +36,8 @@ RF24Network class
 External Systems or Applications
 ********************************
 
-.. autoattribute:: pyrf24.rf24_network.RF24Network.return_sys_msgs
-.. autoattribute:: pyrf24.rf24_network.RF24Network.network_flags
+.. autoattribute:: pyrf24.RF24Network.return_sys_msgs
+.. autoattribute:: pyrf24.RF24Network.network_flags
 
 RF24NetworkHeader class
 -----------------------
@@ -46,7 +46,7 @@ RF24NetworkHeader class
     The `RF24NetworkHeader` class supports the python "magic method" :py:func:`repr()`. So, you can
     easily pass an instantiated `RF24NetworkHeader` object to the :py:func:`print()` function.
 
-.. autoclass:: pyrf24.rf24_network.RF24NetworkHeader
+.. autoclass:: pyrf24.RF24NetworkHeader
 
     .. autoattribute:: to_node
     .. autoattribute:: type
@@ -66,11 +66,11 @@ Constants
 The following are predefined module-level constants that can be used for comparisons and
 code readability.
 
-.. autoattribute:: pyrf24.rf24_network.MAX_USER_DEFINED_HEADER_TYPE
+.. autoattribute:: pyrf24.MAX_USER_DEFINED_HEADER_TYPE
 
     The maximum of user defined message types.
 
-.. autoattribute:: pyrf24.rf24_network.MAX_PAYLOAD_SIZE
+.. autoattribute:: pyrf24.MAX_PAYLOAD_SIZE
 
     Maximum size of fragmented network frames and fragmentation cache.
 
@@ -87,7 +87,7 @@ The network will determine whether to automatically acknowledge payloads based o
 
 System types can also contain message data.
 
-.. autoattribute:: pyrf24.rf24_network.NETWORK_ADDR_RESPONSE
+.. autoattribute:: pyrf24.NETWORK_ADDR_RESPONSE
 
     A ``NETWORK_ADDR_RESPONSE`` type is utilized to manually route custom messages containing a
     single RF24Network address.
@@ -100,32 +100,32 @@ System types can also contain message data.
     This allows nodes to forward multicast messages to the master node, receive a response, and
     forward it back to the requester.
 
-.. autoattribute:: pyrf24.rf24_network.NETWORK_PING
+.. autoattribute:: pyrf24.NETWORK_PING
 
     Messages of type ``NETWORK_PING`` will be dropped automatically by the recipient.
     A `NETWORK_ACK` or automatic radio-ack will indicate to the sender whether the payload was
     successful. The time it takes to successfully send a ``NETWORK_PING`` is the round-trip-time.
 
-.. autoattribute:: pyrf24.rf24_network.EXTERNAL_DATA_TYPE
+.. autoattribute:: pyrf24.EXTERNAL_DATA_TYPE
 
     External data types are used to define messages that will be passed to an external data system.
     This allows RF24Network to route and pass any type of data, such as TCP/IP frames, while still
     being able to utilize standard RF24Network messages etc.
 
-.. autoattribute:: pyrf24.rf24_network.NETWORK_FIRST_FRAGMENT
+.. autoattribute:: pyrf24.NETWORK_FIRST_FRAGMENT
 
     Messages of this type designate the first of two or more message fragments, and will be re-assembled automatically.
 
-.. autoattribute:: pyrf24.rf24_network.NETWORK_MORE_FRAGMENTS
+.. autoattribute:: pyrf24.NETWORK_MORE_FRAGMENTS
 
     Messages of this type indicate a fragmented payload with two or more message fragments.
 
-.. autoattribute:: pyrf24.rf24_network.NETWORK_LAST_FRAGMENT
+.. autoattribute:: pyrf24.NETWORK_LAST_FRAGMENT
 
     Messages of this type indicate the last fragment in a sequence of message fragments.
     Messages of this type do not receive a `NETWORK_ACK`.
 
-.. autoattribute:: pyrf24.rf24_network.NETWORK_ACK
+.. autoattribute:: pyrf24.NETWORK_ACK
 
     Messages of this type signal the sender that a network-wide transmission has been completed.
 
@@ -161,15 +161,15 @@ System types can also contain message data.
         ie: When node ``0o0`` sends an instigating message to node ``0o11``, node ``0o1`` will send the
         ``NETWORK_ACK`` message to ``0o0`` upon successful delivery of instigating message to node ``0o11``.
 
-.. autoattribute:: pyrf24.rf24_network.NETWORK_POLL
+.. autoattribute:: pyrf24.NETWORK_POLL
 
     Used by RF24Mesh.
 
     Messages of this type are used with multi-casting, to find active/available nodes.
     Any node receiving a NETWORK_POLL sent to a multicast address will respond directly to the sender with a blank message, indicating the
     address of the available node via the header.
 
-.. autoattribute:: pyrf24.rf24_network.NETWORK_REQ_ADDRESS
+.. autoattribute:: pyrf24.NETWORK_REQ_ADDRESS
 
     Used by RF24Mesh
 
@@ -179,13 +179,13 @@ System types can also contain message data.
 Network flag mnemonics
 ***********************
 
-.. autoattribute:: pyrf24.rf24_network.FLAG_FAST_FRAG
+.. autoattribute:: pyrf24.FLAG_FAST_FRAG
 
     This flag (when asserted in :py:attr:`~RF24Network.network_flags`) prevents repetitively configuring the
     radio during transmission of fragmented messages.
 
-.. autoattribute:: pyrf24.rf24_network.FLAG_NO_POLL
+.. autoattribute:: pyrf24.FLAG_NO_POLL
 
     This flag (when asserted in :py:attr:`~RF24Network.network_flags`) prevents a node from responding to
-    mesh nodes looking to connect to the network. Calling :py:func:`~pyrf24.rf24_mesh.RF24Mesh.set_child()` uses this flag
+    mesh nodes looking to connect to the network. Calling :py:func:`~pyrf24.RF24Mesh.set_child()` uses this flag
     accordingly.

docs/topology.rst

@@ -113,7 +113,7 @@ For a message to travel from node ``0o124`` to node ``0o3``, it must be passed t
 network levels. So, the message flows ``0o124`` -> ``0o24`` -> ``0o4`` -> ``0o0`` -> ``0o3``.
 
 A single network can potentially have a maximum of 781 nodes (all operating on the same
-:attr:`~pyrf24.rf24.RF24.channel`), but for readability reasons, the following
+:attr:`~pyrf24.RF24.channel`), but for readability reasons, the following
 graph only demonstrates
 
 - the master node (level 0) and it's 5 children (level 1)
@@ -216,7 +216,7 @@ Physical addresses vs Logical addresses
   number ``0``
 
   .. tip::
-      Use the :py:meth:`~pyrf24.rf24_network.RF24Network.is_address_valid()`
+      Use the :py:meth:`~pyrf24.RF24Network.is_address_valid()`
       function to programmatically check a Logical Address for validity.
 
 .. note::
@@ -295,7 +295,7 @@ RF24Mesh connecting process
 As noted above, a single network *can* have up to 781 nodes. This number also includes
 up to 255 RF24Mesh nodes. The key difference from the user's perspective is that RF24Mesh
 API does not publicly use a `Logical Address <logical_address>`. Instead the RF24Mesh API
-relies on a :attr:`~pyrf24.rf24_mesh.RF24Mesh.node_id` number to identify a RF24Mesh node
+relies on a :attr:`~pyrf24.RF24Mesh.node_id` number to identify a RF24Mesh node
 that may use a different  `Logical Address <logical_address>` (which can change based on
 the node's physical location).
 
@@ -305,17 +305,17 @@ the node's physical location).
     is layered on top of the RF24Network API.
 
 To better explain the difference between a node's `mesh_address` vs a node's
-:attr:`~pyrf24.rf24_mesh.RF24Mesh.node_id`, we will examine the connecting process for a
+:attr:`~pyrf24.RF24Mesh.node_id`, we will examine the connecting process for a
 RF24Mesh node. These are the steps performed when calling `renew_address()`:
 
 1. Any RF24Mesh node not connected to a network will use the `Logical Address <logical_address>`
    ``0o4444`` (that's ``2340`` in decimal). It is up to the network administrator to ensure that
-   each RF24Mesh node has a unique :attr:`~pyrf24.rf24_mesh.RF24Mesh.node_id` (which is limited
+   each RF24Mesh node has a unique :attr:`~pyrf24.RF24Mesh.node_id` (which is limited
    to the range [0, 255]).
 
    .. hint::
        Remember that ``0`` is reserved the master node's
-       :attr:`~pyrf24.rf24_mesh.RF24Mesh.node_id`.
+       :attr:`~pyrf24.RF24Mesh.node_id`.
 2. To get assigned a `Logical Address <logical_address>`, an unconnected node must poll the
    network for a response (using a `NETWORK_POLL` message). Initially this happens on the
    network level 0, but consecutive attempts will poll higher network levels (in order of low to
@@ -329,7 +329,7 @@ RF24Mesh node. These are the steps performed when calling `renew_address()`:
    respond with an invalid `Logical Address <logical_address>`.
 5. Once the requesting node receives the address response (and the assigned address is
    valid), it assumes that as the `mesh_address` while maintaining its
-   :attr:`~pyrf24.rf24_mesh.RF24Mesh.node_id`.
+   :attr:`~pyrf24.RF24Mesh.node_id`.
 
    - The connecting node will verify its new address by calling `check_connection()`.
    - If the assigned address is invalid or `check_connection()` returns `False`, then