Feature Request: Bit Regenerator/Packet Repeater #144
Comments
|
Dear radar27, I don't know if I understood correctly your issue but such a digi feature is already built into this software. Hope this helps |
|
Hi Skinoku, The feature I am referring to is geared towards an actual duplex repeater that simultaneously transmits on one frequency and receives on another. In a classic repeater environment, the signal that arrives on the receiver essentially has it's audio patched through to the transmitter. While this is largely the only option for voice communication, we do have a better option for digital. Rather than simply passing the audio, we can use Direwolf's excellent decoding (with or without FIX_BITS) and then reencode the audio in near realtime. Obviously the receiver would need a chance to start decoding prior to the transmitter being able to start encoding, but this delay could be relatively small. There is a hardware version from TAPR that does this, it has an 8 bit buffer: https://www.tapr.org/kits_9600.html See the "9600bps Modem Bit Regenerator Option" section. The advantage in this approach is that we give Direwolf the chance to decode the packet as it is coming in and reencode it before going back out. This eliminates the hidden transmitter syndrome if all stations can reach the Packet Repeater itself (again very similar to a classic voice repeater extending the coverage over simplex). This also can clean up any marginal signals that Direwolf is able to successfully decode. Simply passing the marginal signal on the output may or may not result in a successful decode from the other packet repeater users (particularly if they are using an older hardware TNC for example). There is a REGEN option today which allows one modem to send to another. From the documentation I can find it appears this was intended to change between baudrates. An example of this would be to run a 300 baud modem and 1200 baud modem with REGEN linking the two together. From there a user could have a 1200 baud only TNC linked to the 1200 baud side and let Direwolf act as a gateway down to 300 baud for HF packet. I have tested this option out and it does work well, the only difference I can tell between this and what I have requested here is that the regeneration occurs after the complete packet has been decoded as opposed to using a small buffer to perform a decode and encode with only a small delay (8 bit buffer in the TAPR design). The primary reason I seek the buffer is to try and eliminate collisions. If you were to operate a packet repeater with REGEN alone, the transmitter would not come up until the receiver has completed a decode. If there were another station on frequency, their carrier detect would not detect anything being transmit (listening to the transmit frequency) and could potentially key up on top of the other system, creating a "double" and likely causing neither packet to be successfully decoded. This request is probably only applies to a small number of installations, but I think it can greatly enhance packet operation in a given area, particularly when there is a high profile site that could be used as a packet repeater. 73! |
|
Not needing the entire packet to be received before being retransmitted is a very useful feature that (I think) is also used in some specialized wired packet network routers to minimize latency. This feature is essential for low-latency full-duplex networks at low baud rates. Unfortunately such a use-case is currently rare so I doubt this will be seen as a high priority. |
|
In computer networking this is known as a cut-through switch. |
|
The internal architecture of direwolf is based on the store-and-forward concept.
Adding this capability would be difficult and I don't see the value for this application.
Legacy packet does a fairly good job of sharing a channel - specially
if all stations can hear each other and hold off transmitting when the
channel is in use. As soon as there is a station that doesn't
hear/heard-by others - then HTS - Hidden Transmitter Syndrome - leads
to many collisions and drastically reduces the effective performance.
One solution to HTS is to use a full duplex digital repeater (definitely NOT a
digipeater) that can hear and is heard by everyone.
Off the cuff I'd suggest a packet repeater running 1200 baud is equal
or better in performance to a simplex system with HTS running 9600.
Hardware solutions for a packet repeater controller have varied thru
the years - see the old TAPR kits and early DCC articles. Even today
there is no OTS solution and we've been hoping that one of the
software packet applications may be the answer.
The need for this has diminished. In the old days it was a N to N
free for all of packets where JNOS ruled and email and other
operations would be from any Server to any other server. Today we
have a one to N operation where many stations may take turns accessing
a single Email access point. Hidden transmitters are less of a
factor.
Bottem line - full duplex regeneration and retransmission technology
could potentially be a big thing... Please keep it in the list of
future features.
73,
Bill, W7NWP
PS. In the early 90's, I've personally used 1200 baud regens in
Denver, Calgary and Seattle. In addition, the WETNET group in seattle
had four 9600 baud regens covering the entire Puget Sound region.. It
was a thing of beauty to watch the packets flow.
|
|
The critical issue solved by bit regenerators is channel access contention,
or what we would call "doubling" in voice comms.
Bit regenerators are popular in mountain countries because wide area bit
repeaters would be on mountain tops, and were implemented in a TNC-2 with
the Xanthus Digital Bit Regenerator EPROM or equivalent.
The BBS's were at somebody's home, usually down in the valley, and the
ability for a Ham 50 miles away, on the other side of the mountain to
access the BBS was pretty amazing.
Even with HSMM and mesh systems this basic concept remains an issue today.
The AREDN MESH software operates on CSMA. Carrier Sense Multiple Access.
The throughput of the mesh will be limited if there are a lot of hidden
transmitters in the mesh.
You may know that HamWAN uses exclusively Mikrotik Radios for HamWAN cells
and clients.
They use the Mikrotik NV2 proprietary protocol which is based on TDMA -
Time Division Multiple Access.
TDMA solves the Hidden Transmitter Syndrome, and improves throughput of the
channel.
The access point (typically on a mountain) acts as the master in the radio
network. It divides time into several slots, and then tells each registered
client radio when it's time to transmit and how long they can transmit.
This fair-shares the channel and provides an orderly channel access
mechanism, all on a simplex frequency used for both up and down to the
mountain.
Summary:
We continue to need High Speed Data Protocols that work on VHF/UHF radio -
25 KHz or even 100 KHz data channels. We have lots of spectrum in the 70cm
, and 23cm bands.
Full duplex regenerators are pretty nice for mountain tops.
Idea/Concept:
Our friends in the Amateur TV space are still largely Analog. There are not
many ATV repeaters around, but they typically operate split band. 434 Mhz
from user to the repeater, and 1253 Mhz repeater to user, with 6 MHZ wide
RF channels.
It could be interesting to explore a merging of Amateur TV and Digital
Radio activities.
The repeater would transmit IP packets on 1253 MHz, with a high speed
protocol 5 or 6 MHz wide.
Included in the protocol would be either a busy/idle bit status for the
inbound channel, or some kind of TDMA slotting protocol for access to the
inbound channel.
Amateur TV would stream over IP using one of the many digital
video protocols, allowing both ATV and data transmission to share the
spectrum.
The goal would be use of radio spectrum that doesn't require perfect line
of sight.
The 2.4GHz and 5.9 GHz systems are truly wonderful, but with so many darn
tall trees in Washington, access to perfect line of sight is problematic.
Randy, W3RWN
Burien, WA
…On Sat, Nov 6, 2021 at 5:07 PM Bill Vodall ***@***.***> wrote:
> The internal architecture of direwolf is based on the store-and-forward
concept.
> Adding this capability would be difficult and I don't see the value for
this application.
Legacy packet does a fairly good job of sharing a channel - specially
if all stations can hear each other and hold off transmitting when the
channel is in use. As soon as there is a station that doesn't
hear/heard-by others - then HTS - Hidden Transmitter Syndrome - leads
to many collisions and drastically reduces the effective performance.
One solution to HTS is to use a full duplex digital repeater (definitely
NOT a
digipeater) that can hear and is heard by everyone.
Off the cuff I'd suggest a packet repeater running 1200 baud is equal
or better in performance to a simplex system with HTS running 9600.
Hardware solutions for a packet repeater controller have varied thru
the years - see the old TAPR kits and early DCC articles. Even today
there is no OTS solution and we've been hoping that one of the
software packet applications may be the answer.
The need for this has diminished. In the old days it was a N to N
free for all of packets where JNOS ruled and email and other
operations would be from any Server to any other server. Today we
have a one to N operation where many stations may take turns accessing
a single Email access point. Hidden transmitters are less of a
factor.
Bottem line - full duplex regeneration and retransmission technology
could potentially be a big thing... Please keep it in the list of
future features.
73,
Bill, W7NWP
PS. In the early 90's, I've personally used 1200 baud regens in
Denver, Calgary and Seattle. In addition, the WETNET group in seattle
had four 9600 baud regens covering the entire Puget Sound region.. It
was a thing of beauty to watch the packets flow.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#1221): https://wetnet.groups.io/g/main/message/1221
Mute This Topic: https://groups.io/mt/86874559/404057
Group Owner: ***@***.***
Unsubscribe:
https://wetnet.groups.io/g/main/leave/10734726/404057/1696885841/xyzzy [
***@***.***
-=-=-=-=-=-=-=-=-=-=-=-
|
|
More info on packet regeneration. Check out Lyle's article in PSR046
- it starts on page 7
https://files.tapr.org/psr/psr046.pdf
There is one more article with some tweaks to modify the TNC-2 - I
haven't found it yet.
73,
Bill W7NWP
…On Sat, Nov 6, 2021 at 5:07 PM Bill Vodall ***@***.***> wrote:
> The internal architecture of direwolf is based on the store-and-forward concept.
> Adding this capability would be difficult and I don't see the value for this application.
Legacy packet does a fairly good job of sharing a channel - specially
if all stations can hear each other and hold off transmitting when the
channel is in use. As soon as there is a station that doesn't
hear/heard-by others - then HTS - Hidden Transmitter Syndrome - leads
to many collisions and drastically reduces the effective performance.
One solution to HTS is to use a full duplex digital repeater (definitely NOT a
digipeater) that can hear and is heard by everyone.
Off the cuff I'd suggest a packet repeater running 1200 baud is equal
or better in performance to a simplex system with HTS running 9600.
Hardware solutions for a packet repeater controller have varied thru
the years - see the old TAPR kits and early DCC articles. Even today
there is no OTS solution and we've been hoping that one of the
software packet applications may be the answer.
The need for this has diminished. In the old days it was a N to N
free for all of packets where JNOS ruled and email and other
operations would be from any Server to any other server. Today we
have a one to N operation where many stations may take turns accessing
a single Email access point. Hidden transmitters are less of a
factor.
Bottem line - full duplex regeneration and retransmission technology
could potentially be a big thing... Please keep it in the list of
future features.
73,
Bill, W7NWP
PS. In the early 90's, I've personally used 1200 baud regens in
Denver, Calgary and Seattle. In addition, the WETNET group in seattle
had four 9600 baud regens covering the entire Puget Sound region.. It
was a thing of beauty to watch the packets flow.
|
|
The REGEN feature was originally added for speed conversion but it can also regenerate the packet at the same speed. |
Greetings,
Would it be possible to add a bit regenerator/packet repeater function? Many years ago, TAPR introduced a hardware version which went into a standard TNC2, which when attached to appropriate hardware permitted a packet repeater that actually decoded+reencoded the (A)FSK signal versus just repeating the audio like a classic voice repeater would do:
https://www.tapr.org/kits_9600.html#bitregen
One of the big challenges with packet is the "hidden transmitter syndrome", which a packet repeater in a suitable location can largely address. I have had some success in using a crossover cable from one KISS TNC to another, but I was hoping we could do this in software in a more real-time fashion. that could ultimately then support other applications via the AGWPE and/or KISS over TCP interface.
Thanks for this great software.
73!
The text was updated successfully, but these errors were encountered: