| |
NL1VKL > PACKET 03.08.21 12:00l 102 Lines 3726 Bytes #999 (0) @ WW
BID : 32926NL1VKL
Read: GAST DQB562
Subj: Re: Direwolf FixBit DE/ENG
Path: DBO595<DBX320<BLM274<CB0ESN<FU0BOX<KS1BBS<HEJ717<VB1BOX<NL3VKL
Sent: 210803/0714Z @:NL3VKL.NBO.NLD.EU #:1860 [Uden] $:32926NL1VKL
From: NL1VKL@NL3VKL.NBO.NLD.EU
To : PACKET@WW
Message from: NL1VKL@NL3VKL
Quoting from a previous message...
>
> From: MD2SAW@MD2BBS.#SAW.SAA.DEU.EU
> To : PACKET@WW
>
>
> English:
>
> hi and thanks for the information.
>
> You are of course right that FIX_BITS can not restore the packages to
> 100%, but these "broken" packages are still forwarded to the respective
> software, which can lead to problems in some cases.
>
> But you can let Direwolf check the packages after FIX_BITS, but this is
> no guarantee for correct data.
>
> With
> FIX_BITS 1 AX25
> DW checks the AX25 address range for plausibility and with
> FIX_BITS 1 APRS
> DW checks if it is a plausible APRS packet.
>
> Concerning FX.25 and FIX_BITS, it looks like FIX_BITS is not used for
> FX.25 packets.
>
> Normal packet without FX.25:
> DNX527 audio level = 41(14/9) [NONE] _|||||___
> the [NONE] indicates that FIX_BITS is enabled.
> [NONE] - Don't try to repair.
> [SINGLE] - Attempt to fix single bit error. (default)
> [DOUBLE] - Also attempt to fix two adjacent bits.
> [TRIPLE] - Also attempt to fix three adjacent bits.
> [TWO_SEP] - Also attempt to fix two non-adjacent (separated) bits.
>
> FX25 package:
> DX0SAW audio level = 54(15/10) 000007___
>
> Here are no FIX_BITS "labels" ( [....] ) given which leads me to believe
> that no FIX_BITS is applied here.
>
> It depends of course on the area of application.
> If I run a BBS that does forward via HF or if I use a NET/ROM link
> FIX_BITS could be rather counterproductive.
>
> But I have no bad experiences with it so far although I also forward via
> HF and also have a NET/ROM link via HF set up.
>
> I can only see that FIX_BITS "saves" packages from time to time.
> In how far they were corrupted I can't say.
>
> Greetings,
>
> Translated with www.DeepL.com/Translator (free version)
>
> --
> 73 Manuel.
>
Without forwarding / only simple user usage it isn't a big issue but can be
very annoying. You're most likely seeing/noticing callsigns where a single
character is something else than it should be. For example NL1VKL ->
NL1VLL...
The AX25 address range plausibility check is most likely to be optimized for
HAM callsigns. Also with the given example it doesn't do anything good, the
callsign is still wrong and will probably also fail with callsigns not
following the plausibility check pattern, for example callsigns without a
number in it. But that's an assumption with the experience of how several
packet software packages do callsign validation/checks.
My experience with FIX_BITS isn't that good, especially when forwarding.
Yes... It saves packages, but corruption is likely and does occur. The
higher FIX_BITS is set, the more occurances. Corrupted packets should be
discarded, not trying to recover without FEC.
Therefore I've disabled it again. I personally prefer a retry, it are only
max. a couple of bits, or real/good correction (FEC) instead of corrupted
frames.
73! Dave de NL1VKL
====================================================================
_____ __ ___ _____ _____ __
| | | | |_ | | | | | | | Sysop: Dave
| | | | |__ _| |_| | | -| |__ QTH: Uden - JO21TP
|_|___|_____|_____|\___/|__|__|_____| BBS: NL3VKL.NBO.NLD.EU
QRV: 27.235 MHz (FM 1k2)
27.365 MHz (LSB 1k2)
NL3VKL BBS
NL5VKL Net/Rom node / internet gateway https://nl5vkl.mijndingen.nl
====================================================================
** This message is generated with Sally 7.2.044
-----------------------------------------------------------------
Lese vorherige Mail | Lese naechste Mail
| |