| |
MM0UHR > ALL 08.02.24 20:50l 168 Lines 7349 Bytes #999 (0) @ GBR
BID : 2872_MM0UHR
Read: GUEST
Subj: Brandmeister TG 235419 Packet Net - 2024-02-06
Path: ON0AR<IW0QNL<VE2PKT<PD0LPM<MM0RJJ<MM3NDH<GM0BKS<GM7RYR<MM0UHR
Sent: 240206/2215Z 2872@MM0UHR.#77.GBR.EURO LinBPQ6.0.24
The net ran from 20:00-21:05UTC
-- Attendees
GM0CQV - Brendan - Net Control
MM0UHR - Chris
GM0BKS - Graeme
GM4UPX - Ian
MM3XIA - Iain
GM0NRT - Bill
-- Feedback from readers
Some of the topics for discussion tonight were suggested by feedback
from the readers of this summary. We are delighted to get questions to
put into the mix. Interesting questions either get interesting answers
or are a prompt for all of us to learn something new.
-- Signals into #79 from #71 and #77
Ongoing efforts to link north and south from the Glasburgh line are
showing more education than results.
#79 is to the North and hills are in the way, but GM7RYR, GM0BKS and
GB7AUG are audible in the #79 area. Linking back is possible but not
reliable even with high power.
A 4m node was stood up temporarily in Edinburgh to try and link to the
4m nodes in the Scottish Borders. Nothing was heard but that might be
to do with the very slapdash build or the Moorfoot Hills. Tests from
better locations are in progress.
More exploration is ongoing to maybe bring in new nodes and expand the
network.
-- Instant connections followed by a long wait
One attendee is reporting that when they try to connect to a BBS via RF
they get a "Connected to" response almost immediately, but then there
is a several second delay before the BBS information appears.
Nobody on the net had any ideas what would cause this but hopefully we
can unearth suggestions for next week.
-- White Pages
A short discussion of the white pages feature showed one attendee
having trouble making query messages work. This isn't a terrible
problem as all the desired functionality works, but it would be good to
know how to work this too.
Part of that discussion returned that wildcards can go into a query
email, so a query for "MM*?" would return every MM callsign the
recipient node knows about.
Beware email sizes if you get carried away with wildcard queries. Some
white pages are very large.
-- RF vs Internet links on the M0LTE map
If a pair of stations has an RF and an Internet link, the M0LTE map
will just pick one to show. Work is planned to make it favour the RF
link, but at the moment the only way to force it would be to disable
the Internet link.
-- Packet Node Wall
Some discussion was had that the chat program wasn't quite what people
were looking for. The real time nature of the chat can certainly be
interesting but something more asynchronous was sought.
The NodeWall project might be the very thing being looked for. Details
can be found here: https://github.com/juniberry/NodeWall and we hope
someone will set it up and report back for next week
-- Decoding the protocol
Mention was made of the messages you can see if you monitor the link
and what they all mean. Discussion on the net was brief as this summary
was thought to be the place to kick of the discussion rather than
reading out message types and explanations. Perhaps more specific
questions will come back next week.
The protocol is AX.25 and is a seriously thought out piece of work. A
full explanation is documented at
https://www.ax25.net/AX25.2.2-Jul%2098-2.pdf
Common messages are:
C or SABM Layer 2 Connect Request
D or DISC Layer 2 Disconnect Request
I Information Frame
RR Receive Ready. System Ready To Receive
RNR or NR Receive Not Ready. TNC Buffer Full
RJ or REJ Reject Frame. Out of Sequence or Duplicate
FRMR Frame Reject. Fatal Error
UI Unnumbered Information Frame. "Unproto"
DM Disconnect Mode. System Busy or Disconnected.
(Copied from: https://www.qsl.net/oe8djk/pr4ax25.html)
"Layer 2" is a reference to the OSI network model. Layer 1 is physical
stuff. In our case the air, frequencies, modulation and bandwidth.
Layer 2 is concerned with how the point-to-point links between
neighbouring nodes actually pass data.
-- Efforts to reduce retries and RTT
After reading the CSMA description shared last week
(https://tarpn.net/t/faq/faq_csma.html) a summary of how some of the
config options affect each stage of the packet workflow has been made
and included below
|---------+----------+-------------------------------------------------|
| 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: transmit |
| | | >persist:listen again |
|---------+----------+-------------------------------------------------|
| tx | TX delay | I press the PTT so both ends of the link prepare|
| | | for the transmission |
|---------+----------+-------------------------------------------------|
| tx | N/A | I send data |
|---------+----------+-------------------------------------------------|
| RX | resptime | I wait for my radio 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? |
|---------+----------+-------------------------------------------------|
There reality is that there is a delay between deciding you are going
to claim the channel and actually transmitting. Slot time is how long
other stations will wait for you to claim the channel since the
previous slottime expired.
One fundamental issue is slottime is no use if your station can't hear
the current transmitter. This can be caused by hidden nodes!
Network designs should seek to minimise hidden nodes and build fully
connected meshes.
-- GBR routing
Extending delivery of this summary to all@gbr has revealed some routing
issues which we hope have been fixed. This means people in the all@scot
catchment area might get this message to two bulletin addresses.
Please reply to MM0UHR if you got this once or twice and roughly where
you are.
--
People are welcome to join the net next week. If you don't have DMR but
want to put in a topic for discussion, you can reply to this bulletin
or to me directly and we'll add it to next week.
If you happen to know someone who is interested in packet but isn't
set up far enough to get this message, please pass it along and let them
know about the net.
73
Chris MM0UHR@MM0UHR.#77.GBR.EU
Read previous mail | Read next mail
| |
