Date   

Re: direwolf frame size #ax25 #direwolf

jgindc1@...
 

Basil,

Thanks for taking the time to investigate. Any information is worth having.

John KM7LJ


On Tue, Feb 26, 2019 at 5:02 PM Basil Gunn <basil@...> wrote:

John,
Thanks for the files.

You are having a problem with Pat timeouts. I support paclink-unix as a
Linux Winlink client/transport and not Pat.

It looks like you have a pending message coming in and you successfully
sent your 144.8k picture of a Pactor modem and then the AX.25 socket
opened by Pat times out.

What I would do is simplify your problem by receiving your pending
message. You can do that by using your Winlink Web account.

Try transmitting your file again. If it still times out try transmitting
some smaller attached file. Also you might want to post this problem on
the Pat support forums.

I see you successfully connected to RMS Gateway K7GJT-10 which is not
configured to beacon to Winlink services, ie. I could not find it in the
Winlink packet RMS list. This gateway will eventually stop responding if
that isn't fixed.

Sorry I couldn't be of more help.

/Basil


jgindc1@... writes:

> Attachment and console output sent to your personal address.
>
> John KM7LJ




Re: direwolf frame size #ax25 #direwolf

Basil Gunn
 

John,
Thanks for the files.

You are having a problem with Pat timeouts. I support paclink-unix as a
Linux Winlink client/transport and not Pat.

It looks like you have a pending message coming in and you successfully
sent your 144.8k picture of a Pactor modem and then the AX.25 socket
opened by Pat times out.

What I would do is simplify your problem by receiving your pending
message. You can do that by using your Winlink Web account.

Try transmitting your file again. If it still times out try transmitting
some smaller attached file. Also you might want to post this problem on
the Pat support forums.

I see you successfully connected to RMS Gateway K7GJT-10 which is not
configured to beacon to Winlink services, ie. I could not find it in the
Winlink packet RMS list. This gateway will eventually stop responding if
that isn't fixed.

Sorry I couldn't be of more help.

/Basil


jgindc1@gmail.com writes:

Attachment and console output sent to your personal address.

John KM7LJ


Re: direwolf frame size #ax25 #direwolf

jgindc1@...
 

Attachment and console output sent to your personal address.

John KM7LJ


On Mon, Feb 25, 2019 at 5:26 PM Basil Gunn <basil@...> wrote:

I know of a timing problem in paclink-unix but the file sizes are in the
10k to 20k byte range. Could you please send the file you are trying to
send as an attachment to my personal email address, not the udrc
group. Also copy/paste the entire console session output so that I can
replicate your problem.

The AX.25 frame size is set in /etc/ax25/axports configuration file and
should be 255 bytes.

I only use direwolf as a sound modem. You should NOT be setting any
AX.25 parameters there.

Regarding Winlink message file sizes:

From a google groups thread (Adam KF7LJH)

ARES typically recommends no more than 5KB winlink messages. More than
than can risk your radio (and the gateway's radio) since the output
finals can get so hot because of the long transmission time.

Attachments are generally a bad idea with winlink. Keep it plain text
only.

From the Winlink site:
Message size maximum, including Attachments: 120000 bytes (compressed)

/Basil

jgindc1@... writes:

> I am sending/receiving Winlink messages using a Raspberry pi with the
> DRAWS hat. All is well as long as the messages/attachments are short,
> less than a couple of kBytes.
>
> When attempting to send longer messages/attachments, each transmission
> increases in time starting at about 4 seconds then climbing up to
> about 14-15 seconds at which time I get a fail message - "Exchanged
> failed: read udr0: connection timed out". I would like to set a limit
> to the maximum transmission period.
>
> I am unsure at which software level the maximum packet/frame length is
> determined. I have looked at direwolf.conf but did not see any
> reference to frame or packet length.
>
> Any suggestions would be gratefully received.
>
> John KM7LJ




Re: IMPORTANT: Do not upgrade #kernel on #kernel #beta8

Basil Gunn
 

Thank you Anna! /basil


Re: IMPORTANT: Do not upgrade #kernel on #kernel #beta8

Basil Gunn
 

This is the fix for the 4.14.98-v7+ kernel breakage.
There is a conflict with the udrc driver and the AudioSense-Pi drivers.
If you have done an apt-get upgrade & the udrc sound card has
disappeared then do the following:

# Go to the script repo
cd
cd n7nix

# Get the latest scripts
git pull

# Put the latest scripts in the local bin directory
cd config
./bin_refresh.sh

# run the script that fixes the conflict
chk_conflict.sh

# Reboot your RPi

The BETA9 image will have the driver conflict fixed.
/Basil n7nix

John D Hays - K7VE <john@hays.org> writes:

We have determined that upgrading to kernel 4.14.98-v7+ is breaking access
to the DRAWS™ HAT (UDRC) driver.

Please *do not* do a general
apt-get update
apt-get upgrade
until we resolve this issue.

At the current time we can only recommend backing up your application
configurations and reverting to a fresh copy of beta8, if you have already
performed an upgrade.


Re: direwolf frame size #ax25 #direwolf

 

There are two different ways that applications can use direwolf as a TNC.

(1) As a stupid KISS TNC.  In this case the application is totally in control.  The stupid TNC just does what it is told.  Decisions about PACLEN, MAXFRAME, etc. are made entirely by the application layer.  (Or AX.25 for Linux if that is in the middle.)

(2) The AGW network interface allows direwolf to perform the link layer (connected mode) function.  In this case the direwolf configuration has the usual PACLEN, MAXFRAME, etc.

This block diagram illustrates how the AGW network interface can access more functionality inside the TNC.   https://github.com/wb2osz/direwolf/blob/master/direwolf-block-diagram.png   It is advantageous to use that interface if your application supports it. 

This application note  https://github.com/wb2osz/direwolf/raw/dev/doc/Why-is-9600-only-twice-as-fast-as-1200.pdf  explains the differences between using the AX.25 link layer built in to direwolf or having the application treat it as a stupid KISS TNC.

Back to your question.  We need to run a test to see what is going on.  Run direwolf with these options:

direwolf -d nao -T %T  2>&1 | tee w.log

This will capture information about the conversation between your application and direwolf.  It will also print information about Carrier Detect and PTT so we can see how many frames are in each transmission.  The -T option will add timestamps.   Finally it is all captured in a file so we can examine it later.


Re: direwolf frame size #ax25 #direwolf

Basil Gunn
 

I know of a timing problem in paclink-unix but the file sizes are in the
10k to 20k byte range. Could you please send the file you are trying to
send as an attachment to my personal email address, not the udrc
group. Also copy/paste the entire console session output so that I can
replicate your problem.

The AX.25 frame size is set in /etc/ax25/axports configuration file and
should be 255 bytes.

I only use direwolf as a sound modem. You should NOT be setting any
AX.25 parameters there.

Regarding Winlink message file sizes:

From a google groups thread (Adam KF7LJH)

ARES typically recommends no more than 5KB winlink messages. More than
than can risk your radio (and the gateway's radio) since the output
finals can get so hot because of the long transmission time.

Attachments are generally a bad idea with winlink. Keep it plain text
only.

From the Winlink site:
Message size maximum, including Attachments: 120000 bytes (compressed)

/Basil

jgindc1@gmail.com writes:

I am sending/receiving Winlink messages using a Raspberry pi with the
DRAWS hat. All is well as long as the messages/attachments are short,
less than a couple of kBytes.

When attempting to send longer messages/attachments, each transmission
increases in time starting at about 4 seconds then climbing up to
about 14-15 seconds at which time I get a fail message - "Exchanged
failed: read udr0: connection timed out". I would like to set a limit
to the maximum transmission period.

I am unsure at which software level the maximum packet/frame length is
determined. I have looked at direwolf.conf but did not see any
reference to frame or packet length.

Any suggestions would be gratefully received.

John KM7LJ


[New post] DRAWS Production Update

 
Edited

 


k7udr posted: "As we come to the end of February all parts are in house or in transit. Once the last few parts arrive we will secure a 5 day assembly turn. At that time we'll provide a ship date. We have ramped up our capability to meet demand, and should be able to "
 

New post on NW Digital Radio

 

DRAWS Production Update

by k7udr

As we come to the end of February all parts are in house or in transit. Once the last few parts arrive we will secure a 5 day assembly turn. At that time we'll provide a ship date.

We have ramped up our capability to meet demand, and should be able to maintain stock going forward.

Thanks for your patience.

 
k7udr | February 25, 2019 at 2:07 pm | Categories: DRAWS | URL: https://wp.me/p2mAAP-1zD
 

 

 


Re: direwolf frame size #ax25 #direwolf

 



--


John D. Hays
Edmonds, WA
K7VE

   


direwolf frame size #ax25 #direwolf

jgindc1@...
 

I am sending/receiving Winlink messages using a Raspberry pi with the DRAWS hat. All is well as long as the messages/attachments are short, less than a couple of kBytes.

When attempting to send longer messages/attachments, each transmission increases in time starting at about 4 seconds then climbing up to about 14-15 seconds at which time I get a fail message - "Exchanged failed: read udr0: connection timed out". I would like to set a limit to the maximum transmission period.

I am unsure at which software level the maximum packet/frame length is determined. I have looked at direwolf.conf but did not see any reference to frame or packet length.

Any suggestions would be gratefully received.

John KM7LJ


Re: DRAWS™ Manager Demo #drawsmanager

Steve Stroh
 

Nice work John!

Looks reasonably intuitive.

I suggest that you add:
* On screen PTT indicator
* Button to toggle PTT on / off
* Button and slider for various test tones, including varying tones so you can adjust for twist
* Ability to define your own radio on the drop down menu.

The telemetry is great, but why crowd it into a couple of lines at the very bottom? Break it out and make it more prominent.

Also, display the version of DRAWS driver(s) and the version of Rasperian. 

Overall, this is a great tool for DRAWS!

On Sun, Feb 24, 2019 at 15:03 John D Hays - K7VE <john@...> wrote:

See - 

https://www.youtube.com/watch?v=v5C3cWVVz_A

--
Steve Stroh (personal / general): stevestroh@...


DRAWS™ Manager Demo #drawsmanager

 

See - 

https://www.youtube.com/watch?v=v5C3cWVVz_A


Re: IMPORTANT: Do not upgrade #kernel on #kernel #beta8

Art - KC7SDA
 

oh crud =(


Re: FT891, FT817, Audio Levels, I/O Fail , and Documentation #draws #ft817 #hfmodes

jgindc1@...
 

Basil,

Thanks for replying so quickly. Cutting the pin 6 squelch line did indeed solve the problem.

For some unknown reason I had associated the squelch issue with HF and did not check at VHF/UHF FM. 

Also thanks to John and Brian for additional info and references.

73, John KM7LJ


On Sat, Feb 23, 2019 at 7:22 PM Brian Badger <brian@...> wrote:
The advantage of cutting the black wire is that you can in-line a switch to restore squelch operation for non-HF modes.

Brian N0KZ


On Feb 23, 2019, at 8:13 PM, John D Hays - K7VE <john@...> wrote:

Or pull the pin in one end of the cable.

On Sat, Feb 23, 2019, 18:46 Brian Badger <brian@...> wrote:
This is correct.  In order to work with the 817, 857, and 897 in HF modes, the squelch line must be cut.   

I had asked if this could be done in software or by jumper and the answer at the time was that cutting the line was the only solution.

See msg 2079 — the SQL line is the black wire.

Brian
> On Feb 23, 2019, at 5:56 PM, Basil Gunn <basil@...> wrote:
>
>
> I had to disconnect the the squelch pin in my mDin6 cable to get the
> FT-817 to work. There are some notes for the FT-817 HF SSB based AFSK
> and 1200/9600 bps FM operation here:
>
> https://github.com/nwdigitalradio/n7nix/blob/master/docs/RADIO_APP_NOTES.md
>
> /Basil n7nix
>
>
> jgindc1@... writes:
>
>> Using the DRAWS hat, I have had good success with AX25 packet using a
>> Kenwood V71, for example, running XASTIR, or sending and receiving winlink
>> messages using PAT.
>>
>> However, when I substitute my FT-817 for the V71, using the same cables for
>> data and rig control, the DRAWS DIN-6 connection appears to "short" the
>> audio from the FT-817 to ground.
>
>
>




IMPORTANT: Do not upgrade #kernel on #kernel #beta8

 

We have determined that upgrading to kernel 4.14.98-v7+  is breaking access to the DRAWS™ HAT (UDRC) driver.

Please do not do a general 
apt-get update
apt-get upgrade
until we resolve this issue.

At the current time we can only recommend backing up your application configurations and reverting to a fresh copy of beta8, if you have already performed an upgrade.


John D. Hays
Director

  


Re: FT891, FT817, Audio Levels, I/O Fail , and Documentation #draws #ft817 #hfmodes

Brian Badger
 

The advantage of cutting the black wire is that you can in-line a switch to restore squelch operation for non-HF modes.

Brian N0KZ


On Feb 23, 2019, at 8:13 PM, John D Hays - K7VE <john@...> wrote:

Or pull the pin in one end of the cable.

On Sat, Feb 23, 2019, 18:46 Brian Badger <brian@...> wrote:
This is correct.  In order to work with the 817, 857, and 897 in HF modes, the squelch line must be cut.   

I had asked if this could be done in software or by jumper and the answer at the time was that cutting the line was the only solution.

See msg 2079 — the SQL line is the black wire.

Brian
> On Feb 23, 2019, at 5:56 PM, Basil Gunn <basil@...> wrote:
>
>
> I had to disconnect the the squelch pin in my mDin6 cable to get the
> FT-817 to work. There are some notes for the FT-817 HF SSB based AFSK
> and 1200/9600 bps FM operation here:
>
> https://github.com/nwdigitalradio/n7nix/blob/master/docs/RADIO_APP_NOTES.md
>
> /Basil n7nix
>
>
> jgindc1@... writes:
>
>> Using the DRAWS hat, I have had good success with AX25 packet using a
>> Kenwood V71, for example, running XASTIR, or sending and receiving winlink
>> messages using PAT.
>>
>> However, when I substitute my FT-817 for the V71, using the same cables for
>> data and rig control, the DRAWS DIN-6 connection appears to "short" the
>> audio from the FT-817 to ground.
>
>
>




Re: FT891, FT817, Audio Levels, I/O Fail , and Documentation #draws #ft817 #hfmodes

 

Or pull the pin in one end of the cable.


On Sat, Feb 23, 2019, 18:46 Brian Badger <brian@...> wrote:
This is correct.  In order to work with the 817, 857, and 897 in HF modes, the squelch line must be cut.   

I had asked if this could be done in software or by jumper and the answer at the time was that cutting the line was the only solution.

See msg 2079 — the SQL line is the black wire.

Brian
> On Feb 23, 2019, at 5:56 PM, Basil Gunn <basil@...> wrote:
>
>
> I had to disconnect the the squelch pin in my mDin6 cable to get the
> FT-817 to work. There are some notes for the FT-817 HF SSB based AFSK
> and 1200/9600 bps FM operation here:
>
> https://github.com/nwdigitalradio/n7nix/blob/master/docs/RADIO_APP_NOTES.md
>
> /Basil n7nix
>
>
> jgindc1@... writes:
>
>> Using the DRAWS hat, I have had good success with AX25 packet using a
>> Kenwood V71, for example, running XASTIR, or sending and receiving winlink
>> messages using PAT.
>>
>> However, when I substitute my FT-817 for the V71, using the same cables for
>> data and rig control, the DRAWS DIN-6 connection appears to "short" the
>> audio from the FT-817 to ground.
>
>
>




Re: no sound card.... again..... #beta #draws

Art - KC7SDA
 

my guess its something to do with the update/upgrade I did... I normally don't pay attention when I do it as, for the most part, I want everything upgraded....


Re: FT891, FT817, Audio Levels, I/O Fail , and Documentation #draws #ft817 #hfmodes

Brian Badger
 

This is correct. In order to work with the 817, 857, and 897 in HF modes, the squelch line must be cut.

I had asked if this could be done in software or by jumper and the answer at the time was that cutting the line was the only solution.

See msg 2079 — the SQL line is the black wire.

Brian

On Feb 23, 2019, at 5:56 PM, Basil Gunn <basil@pacabunga.com> wrote:


I had to disconnect the the squelch pin in my mDin6 cable to get the
FT-817 to work. There are some notes for the FT-817 HF SSB based AFSK
and 1200/9600 bps FM operation here:

https://github.com/nwdigitalradio/n7nix/blob/master/docs/RADIO_APP_NOTES.md

/Basil n7nix


jgindc1@gmail.com writes:

Using the DRAWS hat, I have had good success with AX25 packet using a
Kenwood V71, for example, running XASTIR, or sending and receiving winlink
messages using PAT.

However, when I substitute my FT-817 for the V71, using the same cables for
data and rig control, the DRAWS DIN-6 connection appears to "short" the
audio from the FT-817 to ground.


Re: FT891, FT817, Audio Levels, I/O Fail , and Documentation #draws #ft817 #hfmodes

Basil Gunn
 

I had to disconnect the the squelch pin in my mDin6 cable to get the
FT-817 to work. There are some notes for the FT-817 HF SSB based AFSK
and 1200/9600 bps FM operation here:

https://github.com/nwdigitalradio/n7nix/blob/master/docs/RADIO_APP_NOTES.md

/Basil n7nix


jgindc1@gmail.com writes:

Using the DRAWS hat, I have had good success with AX25 packet using a
Kenwood V71, for example, running XASTIR, or sending and receiving winlink
messages using PAT.

However, when I substitute my FT-817 for the V71, using the same cables for
data and rig control, the DRAWS DIN-6 connection appears to "short" the
audio from the FT-817 to ground.

3181 - 3200 of 6023