Feature Request: Bit Regenerator/Packet Repeater

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!

Dear radar27,

I don't know if I understood correctly your issue but such a digi feature is already built into this software. When a packet is digi'd the software will re-encode it (and adding, for example, the digi callsing) and then send it on-air. Direwolf by default will try to fix up to 1 bit in order to retrieve some information from packet badly received, in the settings you could increase the level of "fix bits" but you WILL occasionally get some corrupted packets! I don't think there's a way to fix the "hidden transmitter syndrome" because everyone is using a different packet engine, hardware, software, etc so no "standard" can be easily implemented. AGWPE and KISS over TCP interface are already well supported. Using com0com you can run software (on windows) that require a "real" RS232 port by emulating one!

Hope this helps Cheers

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. It reduces latency and can help a lot in a situation where a single packet must go over many hops. 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.

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.

wb2osz / direwolf

Feature Request: Bit Regenerator/Packet Repeater #144