I always used Direwolf for APRS. Now I was trying to use Direwolf + EasyTerm to connect another station using a hardware TNC. It seems that the packets from Direwolf aren't recognized?
by the other station, so that station does not reply to the connect request.?My question is if I should set some parameters in the .conf file special for connected mode.
Notice that Soundmodem from UZ7HO works instead.?
I am using Direwolf on Windows.?
Thanks?
73 Giovanni IZ5PQT?

First question would be about path settings.
?? Does UZ7HO have path settings that are extending the reach of your packets (and Direwolf does not)?

Otherwise, I see 2 sides to consider:?
The lack of a reply from your connect request can either be:
?? 1) The other station is not decoding your packet, and therefore does not reply
?? 2) The other station is decoding your packet and replies to it, but your station is not able to decode the reply.
Assuming the other station is configured properly and others are able to communicate with it (as you were with UZ7HO),
?? then (in IMO), the issue is most likely sound card settings.? Even though the settings work with UZ7HO, they may need to be adjusted for Direwolf.

Checks:
Can you contact the other station and see if they can help you troubleshoot this.
?? Can the other station connect to you with Direwolf setup?? If yes, then I am at a loss!
If not ...
1)?? First ask if they are decoding your packets? If yes, proceed to 2).
????? Adjust the sound card output and send them packets to determine their best decode.
2)?? Have the other station send some packets to your (not connected) - does your station decode them?
????? Adjust the sound card input and see if you can find a setting to best decode them.
??
-------
Rob KB8RCO

Thanks Rob,

first, the two stations are in my shack, hi!

Then as you suggested, the problem were the audio settings. The Direwolf radio here is a FT-991A where I use the USB Audio Codec. Despite the Output audio device?
was correctly selected in the 991.conf, it was inactive until I set it as default device in Windows. Soundmodem did not care about Windows settings.

I have another question: I set up all this drudgery as I would like? to test file transfers using packet radio. The results so far are quite
disappointing. EasyTerm has the Yapp option but is seems not to work at all with Direwolf, and works erratically with Soundmodem. Any idea?

Thanks and 73
Giovanni IZ5PQT

开云体育

Hello Giovanni,

Then as you suggested, the problem were the audio settings. The Direwolf radio here is a FT-991A where I use the USB Audio Codec. Despite the Output audio device?
was correctly selected in the 991.conf, it was inactive until I set it as default device in Windows. Soundmodem did not care about Windows settings.

This still sounds like you have a Direwolf configuration issue as you shouldn't have to set your FT991A as the default Windows sound card to get things to work with Direwolf.

I have another question: I set up all this drudgery as I would like? to test file transfers using packet radio. The results so far are quite
disappointing. EasyTerm has the Yapp option but is seems not to work at all with Direwolf, and works erratically with Soundmodem. Any idea?

You haven't shared much information here but assuming you're still using 1200bps AFSK packet with say 200ms PTT keyup delay, you won't get much more than say about 900bps worth of usable throughput (best case) for application uses such as file transfers.? That said, if EasyTerm with UZ7HO soundmodem via a AGW connection works, then it should work under Direwolf with a AGW connection as well.? Can you tell us what you're seeing in terms of failures, errors, etc?? It's possible there might be a bug so some Direwolf logs and packet captures, etc. will help.


Btw, Rob's last email was spot on and there is at least one other terminal program that supports YAPP that you can try:

?? - QtTermTCP for Windows supports AGW and Yapp :


Though older, you might consider looking for programs that support the "AutoBin" protocol as well.?

--David
KI6ZHD

Thank you David,

my experience with sound cards? tells me that Windows 10 behaves often in unpredictable ways, not limited to Direwolf. Maybe it's more an issue of how it deals with USB Codecs, but many times I solved the situation by declaring a given audio card the default one.

About file transfer yes, I am using 1200 bps. It's just a matter of curiosity. I got recently an used PK-96 TNC and I wanted to check what really the speed was and perhaps move to 9600. However I am frustrated by disappointing results: sometimes the transfer works, sometimes not. The error messages so far are not very explicative ("unexpected packet", "cancel request") and it will take time to understand. So I think I will put this stuff aside for a while. At the moment the highest speed I got was around 80 bytes/sec.?

73 Giovanni IZ5PQT??

Hi Giovanni,

I know I'm late to the party and you already got Direwolf in Connected Mode working for you. However it seems that you didn't get a proper answer to this question:

My question is if I should set some parameters in the .conf file special for connected mode.

There is no simple yes/no answer for this.

Yes, there are plenty of settings in the direwolf.conf file that are specific to Connected Mode only. However one of the nice things about DIrewolf is that it has reasonable default values for all those settings and therefore you can get Connected Mode working without tweaking any of those values. Generally, when two stations are capable of sending and receiving connection-less packets between each other they are also capable of using Connected Mode.

The AX.25 protocol is designed to allow multiple stations to share a channel/frequency and to have multiple communications at the same time. It does so by keeping transmissions short and having sufficient pauses to allow others to transmit (especially important for confirmations from your destination). In addition some timing parameters are defaulting to safe/conservative values to allow proper operation with slow radios and high latency in the computers audio subsystem. All of this makes it less efficient if there is only a single transmitter and receiver pair and you are trying to transfer a file as fast as possible.

It is possible to tune AX.25 in Direwolf (or a hardware TNC) to optimize for that specific use case (one sender, one receiver, fast file transfer) but care should be taken to revert back to normal protocol settings when accessing a shared resource such as a BBS.

You should also be aware that optimizing for speed can effect reliability. AX.25 uses the same 16-bit checksum mechanism to detect incorrectly received packets regardless of the packet size. Making packets larger improves file transfer speed but increases the probability that in a noisy RF environment a corrupted packet nevertheless matches the checksum (and therefore will be accepted as correct). FX.25 addresses that issue by adding forward error correction to the protocol.
Increasing the window size (number of packets sent in a single before waiting for acknowledgement) also helps with the efficient transfer of files. This works fine with AX.25 version 2 level 2 if supported by both sender and receiver since only failed packets need to be retransmitted (selective reject). Direwolf supports this but if either station doesn't, any successfully transferred packets following a bad packet have to be transmitted again (wasting precious air time). If selective reject isn't supported and the RF conditions aren't perfect then increasing the window size may be counterproductive due to number of packets that have to be transmitted multiple times.

73,
Thomas
KK6FPP

Thank you Thomas.
This is why I am subscribed.
Answers like this are very educational.

Thank you
--
Paul AC1DW

That was a very good summary of the tunable parameters and tradeoffs.

A more detailed discussion can be found here:


73,
John WB2OSZ

Hi Thomas,

thanks for the clear explanation. You confirm the information that Direwolf "as? is" should be able to support connected communication. Unfortunately I did several tests with two stations in my shack and?the results have been disappointing. I used an FT-991A with Direwolf + EasyTerm on one side (station X) and a TM-V71 attached to an old PK-96 TNC using the Winpack software (station Y).?Since the?Winpack only runs on old Windows versions I setup a Virtual Machine running XP on my Windows 10 PC. Very broadly speaking I was somewhat successful in transferring binary?files (20 kB size) from Y to X using YAPP but not from X to Y. On the other hand, by converting the binary files to ASCII, the transfer from X to Y was possible. This asymmetry? puzzles me. The reasons for the aborted transfers are not very clear. In particular the message "unexpected packet received" puzzles me: is not connected packed supposed to resend bad data? So why give up for one unexpected packet? All this was for the moment done at 1200 bps.?
I think, to make things more clear, that I should set up both stations using Direwolf? and then repeat the tests. This would separate the problems I have, which could also be in the Winpack software. However this will take some time.?
Unfortunately the packet radio bug hit me too late, hi! Not many aficionados still around!?

73 Giovanni IZ5PQT