member-projects:m0jqq_-_bpq_for_beginners
Differences
This shows you the differences between two versions of the page.
Both sides previous revisionPrevious revisionNext revision | Previous revision | ||
member-projects:m0jqq_-_bpq_for_beginners [2024/02/09 22:27] – [Gateway to the world] mm0uhr | member-projects:m0jqq_-_bpq_for_beginners [2024/12/15 12:44] (current) – [Monitoring a Remote Battery Voltage] section added m0jqq | ||
---|---|---|---|
Line 9: | Line 9: | ||
Or "What I have learnt on my journey" | Or "What I have learnt on my journey" | ||
+ | ==== Things to check... ==== | ||
+ | - What s the relationship between NODESINTERVAL within the port config and SIMPLE in the config header? | ||
+ | - Found a new command to temporarily stop ports (needs SYSOP access) < | ||
+ | - Writeup Node Help: Create a NodeHelp.txt file in / | ||
+ | - Mine is | ||
+ | |||
+ | < | ||
+ | **************************** | ||
+ | * Ask Tom! * | ||
+ | * Always the best route :) * | ||
+ | **************************** | ||
+ | </ | ||
==== Configuring your node for mail ==== | ==== Configuring your node for mail ==== | ||
Line 34: | Line 46: | ||
=== Status === | === Status === | ||
- | {{ : | + | {{ : |
+ | |||
+ | |||
+ | |||
+ | |||
+ | The status page does not really show much. Here you can monitor live use of your node, see who is logged in to each (virtual) stream. | ||
+ | You can also see a count of messages in the system. | ||
+ | \\ | ||
+ | **NOTE:-** Message count needs verification. | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
=== Main configuration === | === Main configuration === | ||
Line 44: | Line 80: | ||
Many boxes to complete and lots of checks to get right. Let's try to take these one at a time. | Many boxes to complete and lots of checks to get right. Let's try to take these one at a time. | ||
- | * BBS Call: Your node callsign | + | |
- | * SYSOP Call: Your callsign. | + | |
- | * H Route: Your node's ' | + | |
- | * Redirect msgs to BBS Call to SYSOP Call: Self explanatory (I think) | + | |
- | * BBS APPL No: The SSID of your BBS; by convention usually 1 | + | |
- | * Streams: Maximum number of simultaneous contacts. 32 is good enough | + | |
Line 55: | Line 91: | ||
== Now the check boxes == | == Now the check boxes == | ||
- | Mostly self explnanatory | + | Mostly self explanatory |
- | + | * Send System Msgs to SYSOP Call | |
+ | * Refuse Bulls | ||
+ | * Enable FBB UI System | ||
+ | * Send Mail For Beacons every 30 Minutes | ||
+ | * Don't Hold Messages From New Users | ||
+ | * Set Don't add WINLINK.ORG flag on new users | ||
+ | * Don't Request Name | ||
+ | * Don't Request Home BBS | ||
+ | * Dont Check From Call | ||
+ | * Allow users to kill T messages | ||
+ | * Forward Messages to BBS Call | ||
+ | * Don't allow unknown users | ||
+ | * Enable Event Reporting | ||
== Ignore the rest until you get to **WP Params** == | == Ignore the rest until you get to **WP Params** == | ||
WP Destinations is where you would list stations you wish to receive any WP Updates generated by your node Housekeeping (more of which later) | WP Destinations is where you would list stations you wish to receive any WP Updates generated by your node Housekeeping (more of which later) | ||
- | + | You have the option to reject WP bulletins and to sent yours either as bulletins or personals. | |
- | + | \\ | |
+ | **NOTE:-** Further research needed here :( | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
== Message Filters == | == Message Filters == | ||
+ | Here you can define rules to filter messages accepted by your node. | ||
+ | You can filter by message **From, To or AT** fields to accept, reject or hold (for other users). | ||
TBH - not really sure of these. We need an edit... | TBH - not really sure of these. We need an edit... | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
- | |||
- | Initial description which can be fully completed at a later date | ||
=== Users === | === Users === | ||
+ | {{ : | ||
- | Example of a node and a BBS - descriptions | + | Illustrated are my node settings for GB7IOW, is it fully correct? Not sure: Does it work? Yes! |
+ | We are only concerned, at present, about packet mail routing but not email via winlink. | ||
+ | |||
+ | The meaning of the fields are: | ||
+ | * **BBS:** A BBS system. Allows the BBS to queue messages for forwarding to it, to use compressed (B/B1/B2) forwarding protocols | ||
+ | * **PMS:** Personal Message System. Allows use of software such as Winpack, to use FBB compressed forwarding, even though it isn' | ||
+ | * **Expert:** Changes the BBS prompt, normally to just >, but can be configured. | ||
+ | * **Excluded: | ||
+ | * **Hold Messages:** Prevents messages being seen by other users or forwarded until released by the sysop. This allows the sysop to review messages, as required by some licensing authorities | ||
+ | * **NTS MPS:** Message pickup station. Allows stations to retrieve NTS messages that would normally be forwarded to them on a "first come first served" | ||
+ | * **Redirect to RMS:** Messages for this user will be forwarded to [email protected]. | ||
+ | * **Send Mail For to APRS:** Whan a message arrives for this user send an APRS message to User-SSID. | ||
+ | * **Permit Email:** Allows users to use the ISP Gateway. Any user can send via RMS, so long as the RMS gateway is configured. | ||
+ | * **Poll RMS for SSID' | ||
+ | * **RMS Express User:** This allow a user (who is not also a BBS) to connect to the BBS using RMS Express. Specifically it includes B2 in the SID, which RMS needs. It isn't needed for Airmail, which doesn' | ||
+ | * **Don' | ||
+ | * **Allow Sending Bulls:** Enables the user to send B type messages. | ||
+ | * **CMS Pass:** This field holds the password | ||
+ | * RMS Express can be used as a client to the BBS, but there are some issues to watch. | ||
+ | \\ | ||
=== Messages === | === Messages === | ||
+ | {{ : | ||
+ | Here you can view messages received and their forwarding status. | ||
+ | top of the frame is the Message number which can be selected from the list of links to the left; there is also a filter if required. | ||
+ | most of the fram is given over to displaying message fields. The most useful aspect is the coloured frames which indicate the state of each message as selected. | ||
+ | * **White:** No forwarding set | ||
+ | * **Yellow:** Message queued for this user | ||
+ | * **Green:** Message sent | ||
+ | * You can click on the field to cycle through status selections. Useful if you need to resend. | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | === Forwarding === | ||
+ | {{ : | ||
+ | \\ | ||
+ | The complex bit - lots of work here | ||
+ | \\ | ||
+ | The only problem to be solved in forwarding is where you should forward a message to next. If the message goes to the next-best BBS then it is assumed that BBS will pass it on correctly. Each BBS doing it's part correctly forms the network magic. All you need to do is work out one step. | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | === Welcome Messages & Prompts === | ||
+ | {{ : | ||
+ | \\ | ||
+ | \\ | ||
+ | Mostly self explanatory | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | === Housekeeping === | ||
+ | {{ : | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\\ | ||
- | Screensnip & description | + | \\ |
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
- | === Forwarding | + | === WP menu === |
+ | {{ : | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
- | The complex bit - lots of work here | + | \\ |
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | \\ | ||
+ | ==== Hierarchical addressing ==== | ||
+ | |||
+ | A whole hierarical address (HA) would be something like MM0UHR@MM0UHR.# | ||
+ | |||
+ | The part before the @ is the TO. The part after the @ is the AT. TO@AT. | ||
+ | |||
+ | In the AT part of the HA, the parts go from the most general at the right to the most specific at the left, separated by dots. | ||
+ | |||
+ | " | ||
+ | |||
+ | " | ||
+ | |||
+ | " | ||
+ | |||
+ | "# | ||
+ | |||
+ | Different parts of the world agree on the continent codes and within that they agree their own country codes. Each country organises their own region codes. | ||
+ | |||
+ | When a message needs to be forwarded, every BBS you can forward a message to is scored to see how specifically it matches the HA of the message. | ||
+ | |||
+ | For a personal message, the message is forwareded on the **single** node that best matches the address. If more than one node is equally good, the one first alphabetically is used. | ||
+ | |||
+ | For a bulletin, the message is forwareded to **all** the nodes that best match the address. If more than one node is equally good, they all get a copy. | ||
+ | |||
+ | An HA for a message has to match all the parts that are specified in the forwarding rules. Rules that match more parts score more highly than rules that match fewer parts, but rules that specify something that isn't in the HA score nothing at all. | ||
+ | |||
+ | Here is an example for a personal message to MM0UHR@MM0UHR.# | ||
+ | |||
+ | |||
+ | ^Node^HA Personal Rule^score^ | ||
+ | |GM7RYR|# | ||
+ | |MM3NDH|ww|matches the implied WW in the HA| | ||
+ | |GM0BKS|# | ||
+ | |||
+ | In this case the message would be passed to GM7RYR because it matches the most parts of the HA address. | ||
+ | |||
+ | A message to GM0CQV@GM0CQV.# | ||
+ | |||
+ | ==== Implied parts ==== | ||
+ | |||
+ | The software has some rules baked into it. This is mostly only important for bulletins, but they count everywhere. | ||
+ | |||
+ | A message to MM0UHR@MM0UHR.# | ||
+ | |||
+ | A message to @EURO is assumed to be @EURO.WW. | ||
+ | |||
+ | A message to @GBR is assumed to be @GBR.EURO.WW. | ||
+ | |||
+ | A message to @#77 is too specific. The software only has implied rules for countries and continents and won't assume GBR on the end of a bare #77 route. | ||
+ | ==== Non-HA Addresses ==== | ||
+ | |||
+ | Most messages are sent with HA addresses because they don't need you to know everything, you just have to send the message to the next-best BBS you know about yourself and everyone doing that will get the message where it needs to go, but there are other options. | ||
+ | |||
+ | If the forwarding BBS has a value in the TO field, any message with that whole value before the @ in an address will go to that BBS. There is no special intelligence here. Any string that matches will do. Put " | ||
+ | |||
+ | In the same way, if the part after the @ matches the whole line of an AT rule the message will go that way. | ||
+ | |||
+ | In Scotland this is used to provide an @SCOT bulliten service. Every node in Scotland puts SCOT in the AT box of every neighbour within Scotland and bullitens to ALL@SCOT will be forwared to every node in Scotland. (this may be a work in progress) | ||
+ | |||
+ | SCOT is not a valid HA destination so this is entirely done with non-HA addresses and works well. | ||
+ | |||
+ | The problem of @#77 being too specific for the software to understand could be fixed by creating a #77 AT rule for your forwarding partners, but they would then have the same problem of not recognising it. Every node in your region would need to agree to make the short rule work. That's not to say it can't be done, but it requires more coordinatation than relying on the existing HA rules. | ||
+ | |||
+ | {{: | ||
==== Templates ==== | ==== Templates ==== | ||
Line 97: | Line 356: | ||
Most likely if you have just set up. You can see one BBS that's already running and doing network magic, you just want in. This is also the case if there are several BBSs but you only care about one Big BBS that can do all the collation and distribution. | Most likely if you have just set up. You can see one BBS that's already running and doing network magic, you just want in. This is also the case if there are several BBSs but you only care about one Big BBS that can do all the collation and distribution. | ||
- | Create a user for that BBS. Set them up as a BBS in their settings. In the forwarding table set " | + | In the network map, this could be MM3NDH or 2M0IIG. |
+ | |||
+ | Create a user for the other BBS. Set them up as a BBS in their settings. In the forwarding table set " | ||
They do the same for you and all mail specifically for you is delivered via an implicit AT match. | They do the same for you and all mail specifically for you is delivered via an implicit AT match. | ||
Line 103: | Line 364: | ||
==== Just your region ==== | ==== Just your region ==== | ||
Several people have set up in your region. There may be a gateway to the wider network, but that's not you. | Several people have set up in your region. There may be a gateway to the wider network, but that's not you. | ||
+ | |||
+ | In the network map this would be MM0UHR. | ||
Create a user for every BBS you can see directly. Set them up as a BBS in their settings. | Create a user for every BBS you can see directly. Set them up as a BBS in their settings. | ||
Line 111: | Line 374: | ||
If there is a gateway node, set them up with a WW rule in personals. Anything not explicitly or implicitly handled above means it goes to the wider world. If you can't see the gateway, add the WW rule to the next-best BBS you can see. | If there is a gateway node, set them up with a WW rule in personals. Anything not explicitly or implicitly handled above means it goes to the wider world. If you can't see the gateway, add the WW rule to the next-best BBS you can see. | ||
+ | |||
==== Gateway to the world ==== | ==== Gateway to the world ==== | ||
Your region is self contained except for one node that can see out of your region and that node is you. | Your region is self contained except for one node that can see out of your region and that node is you. | ||
+ | |||
+ | In the network map this is meant to me GM0BKS. | ||
The node outside your region gets WW in floods and personal. | The node outside your region gets WW in floods and personal. | ||
The nodes inside your region get set up with your region address [e.g. # | The nodes inside your region get set up with your region address [e.g. # | ||
+ | |||
+ | ==== To a hidden node ==== | ||
+ | You can only see nodes inside your region but you can see a node others can't. You //also// divide the network in two but don't have the convenience of it being on a region boundary. | ||
+ | |||
+ | In the network map this would be GM7RYR. | ||
+ | |||
+ | The same situation of making BBS users for each BBS you can see and adding explicit rules for personals in case there are nodes you can't see behind nodes you can. | ||
+ | |||
+ | Flood rules work region wide automatically because whichever side they come in on, they should go out the other. | ||
==== Your region gets through traffic ==== | ==== Your region gets through traffic ==== | ||
Line 125: | Line 400: | ||
==== Templates and scenarios ==== | ==== Templates and scenarios ==== | ||
- | | |One other BBS|Just your region | + | ^ ^One other BBS^Just your region^Gateway to the world^Through Traffic^ |
|A personal is sent to you|The Big BBS delivers it to you|One of your neighbours passes it to you|One of your neighbours passes it to you| One of your neighbours passes it to you.| | |A personal is sent to you|The Big BBS delivers it to you|One of your neighbours passes it to you|One of your neighbours passes it to you| One of your neighbours passes it to you.| | ||
|You send a personal mail within your region|It goes to the only other BBS you know about. WW matches every HA rule|If you can see the BBS, an implicit AT rule will forward it that way. If you can't see it, then explicit HA rules will forward it to the next-best BBS you can see|You pass it into your region because those implicit or explicit rules match more specifically than the WW rule for outside the region|Forwarded by implicit or explicit rules| | |You send a personal mail within your region|It goes to the only other BBS you know about. WW matches every HA rule|If you can see the BBS, an implicit AT rule will forward it that way. If you can't see it, then explicit HA rules will forward it to the next-best BBS you can see|You pass it into your region because those implicit or explicit rules match more specifically than the WW rule for outside the region|Forwarded by implicit or explicit rules| | ||
Line 134: | Line 409: | ||
- | === Welcome Messages & Prompts === | ||
- | Mostly self explanatory | ||
- | === Housekeeping | + | ==== Monitoring a Remote Battery Voltage ==== |
+ | GB7AAAX is powered via solar panels and we found there was a need to monitor the battery voltage. | ||
- | === WP menu === | + | I've elected to use the an ADC on an Arduino board to read the voltage from a divider circuit in order to reduce the input to no greater than 5 volts. The Arduino is powered and communicates via USB to the RPi. |
+ | |||
+ | === Arduino Nano === | ||
+ | |||
+ | == Wiring == | ||
+ | |||
+ | {{: | ||
+ | |||
+ | == Arduino code == | ||
+ | |||
+ | < | ||
+ | //To measure up to 15V dc | ||
+ | |||
+ | #define inputPin A0 | ||
+ | // mvpc is a measurement of actual millivolsts per count (5v ref/1064) | ||
+ | const float mvpc = 4.55; | ||
+ | //counts are the ouput of the adc | ||
+ | float counts = 0; | ||
+ | float mv = 0; | ||
+ | float multi = 3; | ||
+ | //multi depends on voltage divider setup (3 x 5k in series) | ||
+ | float output = 0; | ||
+ | |||
+ | void setup() { | ||
+ | // put your setup code here, to run once: | ||
+ | Serial.begin (115200); | ||
+ | } | ||
+ | |||
+ | void loop() { | ||
+ | // put your main code here, to run repeatedly: | ||
+ | counts = analogRead (inputPin); | ||
+ | mv = counts * mvpc; | ||
+ | output = (mv * multi) / 1000; | ||
+ | Serial.println(" | ||
+ | |||
+ | delay (5000); | ||
+ | } | ||
+ | |||
+ | </ | ||
+ | |||
+ | == Create python3 script – battMonitor.py== | ||
+ | Depending on RPI OS version, you may need to install Python and/or Python libraries | ||
+ | |||
+ | < | ||
+ | cd ~/ | ||
+ | nano battMonitor.py | ||
+ | #!/usr/bin python3 | ||
+ | import serial | ||
+ | import time | ||
+ | sdata = serial.Serial('/ | ||
+ | time.sleep(2) | ||
+ | sdata.reset_input_buffer() | ||
+ | print(" | ||
+ | try: | ||
+ | while True: | ||
+ | time.sleep(0.01) | ||
+ | if sdata.in_waiting >0: | ||
+ | file = open("/ | ||
+ | battState = sdata.readline().decode(' | ||
+ | file.write(f" | ||
+ | file.close() | ||
+ | print (battState) | ||
+ | except KeyboardInterrupt: | ||
+ | print(" | ||
+ | sdata.close() | ||
+ | file.close() | ||
+ | |||
+ | </ | ||
+ | Make it executable < | ||
+ | |||
+ | == Create bash startup script – getBattMonitor.sh == | ||
+ | < | ||
+ | nano getBattMonitor.sh | ||
+ | |||
+ | # | ||
+ | sudo python3 / | ||
+ | sleep 1 | ||
+ | </ | ||
+ | |||
+ | Make it executable < | ||
+ | |||
+ | == Create beacon file == | ||
+ | |||
+ | < | ||
+ | |||
+ | Now is the time to test your work. Connect a variable power supply set to less tha 5 volts to the batt+ and Gnd connections of your Arduino and measure the voltage between GND & A0 It should be about one third of your variable power supply voltage. | ||
+ | Start the script with < | ||
+ | |||
+ | |||
+ | |||
+ | |||
+ | a < | ||
- | === Return via Node Menu === | ||
member-projects/m0jqq_-_bpq_for_beginners.1707517629.txt.gz · Last modified: 2024/02/09 22:27 by mm0uhr