Differences

This shows you the differences between two versions of the page.

--- packet:bpq [2024/03/27 12:37] – m0lte
+++ packet:bpq [2024/04/30 15:24] (current) – g7taj
@@ Line 138: / Line 138: @@
 the  HTTPPORT=8080 found in your Port 1 telnet
-=== BPQ API ===
+===== REST API =====
-BPQ has a simple and evolving api
+BPQ has a simple and evolving HTTP REST API.
+It is used though the HTTPPORT (in this example is port 9122)
 endpoints: (note older versions were prefixed with 'get' (except request_token)
+<code>
 /api/request_token
 /api/ports
@@ Line 149: / Line 151: @@
 /api/users
 /api/info
+/api/links
 /api/mheardport/<port#>
+</code>
 Requested like so:
@@ Line 157: / Line 161: @@
 <code>{"access_token":"OSTWFHSGAPKZWMZORFEFWOFIHMOZUMJK", "expires_in":3600, "scope":"create"}</code>
-Example of MH for Port 1:
+Example of MH for Port 1: ( >ver 6.0.24.33 )
-<code>curl 127.0.0.1:9122/api/mheardport/1 -H "Authorization: Bearer OSTWFHSGAPKZWMZORFEFWOFIHMOZUMJK"</code>
+<code>curl 127.0.0.1:9122/api/mheardport?1 -H "Authorization: Bearer OSTWFHSGAPKZWMZORFEFWOFIHMOZUMJK"</code>
 Output:
@@ Line 165: / Line 169: @@
+===== Events =====
+BPQ can fire an executable on certain events.
+  * new message
+  * message read
+  * user joining chat
+In bpq32.cfg
+<code>EnableEvents=1</code>
+For mail events:
+On the web interface, MailMgmt/Configuration enable:
+<code>Enable Event Reporting</code>
+This will call the following in the bpq directory (For Windows add .exe to the filename)
+<code>MailNewMsg</code>
+It will run the following on a message being read:
+<code>MailMsgRead</code>
+The format of the output is as a string of arguments to the program:
+<code>51260 P N 0 G7TAJ G7TAJ 240408 test</code>
+Chat events:
+This needs to be configured on the chat Web interface page.
+<code>ChatNewUser</code>
+Arguments:
+''
+-G7TAJ : Steve %%*%%%%*%%%%*%% Joined Chat, Topic General
+''
+===== TX/RX cycle =====
+The table below is created from information found at https://tarpn.net/t/faq/faq_csma.html where a lot more detail and good information is available. This table just covers one transmission and the response and the values linbpq pulls from the port config file to determine how long each step should be.
+^ station ^ option   ^ description                                    ^
+| tx      | N/A      | I become ready to transmit                      |
+| tx      | slottime | I listen for other tranmitters to make sure the air is clear                                  |
+| tx      | persist  | I come up with a random number.
+   >persist:listen again
+   <=persist: transmit
+|
+| tx      | TX delay | I press the PTT so both ends of the link prepare for the transmission                          |
+| tx      | paclen      | I send this many symbols                                    |
+| RX      | resptime | I wait for the other station to switch to RX before sending the ACK                               |
+| RX      | slottime | Same as above                                   |
+| RX      | persist  | Same as above                                   |
+| RX      | TX delay | Same as above                                   |
+| RX      | N/A      | I send an ACK message                           |
+| tx      | frack    | How long will I wait for an ACK before retry?   |
+The goal here is to avoid two stations transmitting into the same space at once, thereby wrecking both transmissions. Some level of collision is unavoidable but with good settings for the local area they can be reduced to a minimum. 5% retry rates is a good outcome.
+There are two fundamental problems:
+One is that once a station has decided to transmit it takes a finite amount of time to actually get on the air between programs running, pressing the PTT and actually transmitting once the PTT has been pressed. Slottime should be about as long as that takes for the slowest radio in the network so that if a station is listening for others on the air, it waits long enough for a station to decide to transmit and actually transmit.
+The other is that frequently some nodes cannot see all the other nodes in the network so no matter how long they listen for they cannot hear particular nodes transmitting so will send data to stations that are already receiving and potentially collide.