Date   

Re: #wl2kax25 #wl2kax25

Basil Gunn
 

Hi Ed,

-a udr1

like this:

wl2kax25 -a udr1 -c n7nix-10

You will be overriding whatever is in your /usr/local/etc/wl2k.conf
configuration file. Take a look at the 'ax25port= ' line which should be
ax25port=udr0

Make sure your ALSA settings are correct for both radios on left & right
channel.

/Basil

Ed Bloom, KD9FRQ via groups.io <ewbloom=verizon.net@groups.io> writes:

I am now ready to move forward with sending email via wl2kax25.

I just connected my second 2m rig to Port1. Port0 is currently running
XASTIR as a gateway.

I am not getting the -a PORT part of the command correct when I try to send.

What value should it be for PORT1 of the DRAWS?

Ed, KD9FRQ


#wl2kax25 #wl2kax25

Ed Bloom, KD9FRQ
 

I am now ready to move forward with sending email via wl2kax25.

I just connected my second 2m rig to Port1.  Port0 is currently running XASTIR as a gateway.

I am not getting the -a PORT part of the command correct when I try to send.

What value should it be for PORT1 of the DRAWS?

Ed, KD9FRQ


Re: refund

Charles Blackburn <wx4cb@...>
 

done. thanks

Charlie

On 5/29/2020 6:37 PM, John D Hays - K7VE wrote:
Contact sales@nwdigitalradio.com -- include your order number.

On Fri, May 29, 2020 at 3:32 PM Charles Blackburn <wx4cb@cfl.rr.com> wrote:

how do i get a refund on my draws hat order.


Charlie

--
John D. Hays
Kingston, WA
K7VE



Re: refund

Charles Blackburn <wx4cb@...>
 

I ordered at the beginning of the year, and just had this in my email

Post : Shipping Update
URL :http://nwdigitalradio.com/shipping-update/
Posted : May 29, 2020 at 7:48 am
Author : k7udr
Categories : DRAWS

ThumbDV™ shipped from the assembly house. Customer shipments Monday!

DRAWS™ Had a PCB Fab error and was re-run. We'll keep you posted.

On 5/29/2020 6:35 PM, Jonathan Weaver wrote:
Great question, Charles. I ordered two months ago...no news...no Draws.
On May 29, 2020, at 6:32 PM, Charles Blackburn <wx4cb@cfl.rr.com> wrote:


Re: refund

 

Contact sales@... -- include your order number.

On Fri, May 29, 2020 at 3:32 PM Charles Blackburn <wx4cb@...> wrote:
  how do i get a refund on my draws hat order.


Charlie

--
John D. Hays
Kingston, WA
K7VE

 


Re: refund

Jonathan Weaver
 

Great question, Charles. I ordered two months ago...no news...no Draws.

On May 29, 2020, at 6:32 PM, Charles Blackburn <wx4cb@cfl.rr.com> wrote:

 how do i get a refund on my draws hat order.


Charlie




refund

Charles Blackburn <wx4cb@...>
 

how do i get a refund on my draws hat order.


Charlie


Re: Utilizing DRAWS to encrypt handheld radios

Stuart Longland VK4MSL
 

On 22/5/20 4:38 pm, Digital Alchemy wrote:
Using encrypted radios is completely legal in the US.  the FCC rules are more based around the language of frequency and tx power.
If you're talking commercial-band stuff, then yes, encryption? Sure,
knock yourself out. Amateur bands? Well, that differs.

Here in Australia, it is permitted for emergency communications and in
EMCOMMS exercises, as well as for remote control of equipment.

I understand the FCC rules are a lot more strict on this and do not
allow EMCOMMs traffic to be encrypted.

The real question is, "what hand-held radio"? They come in all shapes
and sizes from your $2 AM set that maybe puts out 10mW and is set by a
crystal in the upper HF… right through to eye-wateringly expensive TETRA
and DMR hand-held radios which likely do their own encryption.

The former could be "encrypted"… you'd just have to interface to the PTT
(fun, because sets of that vintage often used multi-pole switches so
they could cheap out on the transistors), but would be illegal to do so
as I'm pretty sure any kind of data communications at 27.145MHz would be
a violation of the Citizen's Band Radio Service Class License (or
rather, its US equivalent). This is also the case for the more modern
UHF CB sets at 477MHz.

Amateur: again, depends on the scenario, sometimes it's legal, most of
the time it isn't, so most of us have not bothered. QSSTV does work on
the Raspberry Pi, can send files using HamDRM, and HamDRM does not care
if you're sending a photo, plain text, or a blob of data encrypted using
openssl/GnuPG/whatever crypto tool.

Anything else you can get hold of as a mere mortal… smart money would
say it's not legal to use encryption on that band.
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

Help fund COVID-19 research:
https://stuartl.longlandclan.id.au/blog/2020/04/20/who-covid19/


Re: Direwolf Update Script Errors

Troy - K4JDA
 

Basil, thanks!!  Works great!!


Re: Chromium issue...

Mike B
 

I found the directory in /n7nix/iptables/ and ran the flush and install...

It seems to have solved the problem.

So another lesson learned.

Mike


Re: Chromium issue...

Mike B
 

Thanks for pointing that out...yes I am running the NW image...but the iptables may have been overwritten...I will have to see.


Re: Chromium issue...

Basil Gunn
 

Thanks John.

If you use the NWDR image & follow the "Getting Started" Guide you will
not have this problem. iptables is already installed on the image & gets
configured when you run ./app_config.sh core.

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

Basil may have some input, but this is a Raspbian/Chromium issue. The
images are a courtesy, and not a NW Digital Radio product. However, you
could probably use iptables to build a DROP for the interfaces.

On Thu, May 28, 2020 at 2:56 PM Mike B <kf5dey@gmail.com> wrote:

So I run Pat for winlink capability...

...I started having a lot of timeout problems so I was monitoring
axlisten...

There I noticed a problem with Chromium.
...Chromium is apparently broadcasting Upnp info over the udr0:
port...triggering the radio to transmit...and or interrupting other packet
comm and completely screwing up the data transmission.

Is there something in the Draws config that can stop that...or are the IP
address ports for udr0 and udr1 enabling it

I know that Pat is not part of Draws...but Chromium comes installed...and
whenever Chromium is running it attempts to send packets over udr0:

Anywhere I can look for info?

udr0: fm KF5xxx-10 to QST ctl UI pid=CC(IP) len 195 13:13:34IP: len 195
192.168.255.2->239.255.255.250 ihl 20 ttl 1 DF prot UDPUDP: len 175
58661->1900 Data 167M-SEARCH * HTTP/1.1HOST: 239.255.255.250:1900MAN:
"ssdp:discover"MX: 1ST: urn:dial-multiscreen-org:service:dial:1USER-AGENT:
Chromium/78.0.3904.108 Linux


Re: Chromium issue...

Basil Gunn
 

So I run Pat for winlink capability...
I don't support PAT. I do support paclink-unix and mutt, claws-mail, rainloop
mail apps

...I started having a lot of timeout problems so I was monitoring axlisten...
Where did you get axlisten? The NWDR image comes with listen.

There I noticed a problem with Chromium. ...Chromium is apparently
broadcasting Upnp info over the udr0: port...triggering the radio to
transmit...and or interrupting other packet comm and completely
screwing up the data transmission.
The NWDR image comes configured with iptables to prevent that. I take it
you are not using the NWDR image? iptables gets setup when you run
./app_config.sh core if you follow the "Getting Started Guide".
https://nw-digital-radio.groups.io/g/udrc/wiki/8921

Is there something in the Draws config that can stop that...or are the
IP address ports for udr0 and udr1 enabling it
Yes I am well aware of the Chromecast problem, as well as
Bonjour/Multicast DNS, Dropbox, Samba broadcasts. All of those apps bind
to all Network interfaces. iptables fixes that.

I know that Pat is not part of Draws...but Chromium comes
installed...and whenever Chromium is running it attempts to send
packets over udr0:

Anywhere I can look for info?


udr0: fm KF5xxx-10 to QST ctl UI pid=CC(IP) len 195 13:13:34IP: len 195
192.168.255.2->239.255.255.250 ihl 20 ttl 1 DF prot UDPUDP: len 175
58661->1900 Data 167M-SEARCH * HTTP/1.1HOST: 239.255.255.250:1900MAN:
"ssdp:discover"MX: 1ST: urn:dial-multiscreen-org:service:dial:1USER-AGENT:
Chromium/78.0.3904.108 Linux


Re: Chromium issue...

 

Basil may have some input, but this is a Raspbian/Chromium issue.  The images are a courtesy, and not a NW Digital Radio product.  However, you could probably use iptables to build a DROP for the interfaces.

On Thu, May 28, 2020 at 2:56 PM Mike B <kf5dey@...> wrote:
So I run Pat for winlink capability...

...I started having a lot of timeout problems so I was monitoring axlisten...

There I noticed a problem with Chromium.
...Chromium is apparently broadcasting Upnp info over the udr0: port...triggering the radio to transmit...and or interrupting other packet comm and completely screwing up the data transmission.

Is there something in the Draws config that can stop that...or are the IP address ports for udr0 and udr1 enabling it

I know that Pat is not part of Draws...but Chromium comes installed...and whenever Chromium is running it attempts to send packets over udr0:

Anywhere I can look for info?
udr0: fm KF5xxx-10 to QST ctl UI pid=CC(IP) len 195 13:13:34IP: len 195 192.168.255.2->239.255.255.250 ihl 20 ttl 1 DF prot UDPUDP: len 175 58661->1900 Data 167M-SEARCH * HTTP/1.1HOST: 239.255.255.250:1900MAN: "ssdp:discover"MX: 1ST: urn:dial-multiscreen-org:service:dial:1USER-AGENT: Chromium/78.0.3904.108 Linux



Mike



--
John D. Hays
Kingston, WA
K7VE

 


Chromium issue...

Mike B
 

So I run Pat for winlink capability...

...I started having a lot of timeout problems so I was monitoring axlisten...

There I noticed a problem with Chromium.
...Chromium is apparently broadcasting Upnp info over the udr0: port...triggering the radio to transmit...and or interrupting other packet comm and completely screwing up the data transmission.

Is there something in the Draws config that can stop that...or are the IP address ports for udr0 and udr1 enabling it

I know that Pat is not part of Draws...but Chromium comes installed...and whenever Chromium is running it attempts to send packets over udr0:

Anywhere I can look for info?
udr0: fm KF5xxx-10 to QST ctl UI pid=CC(IP) len 195 13:13:34IP: len 195 192.168.255.2->239.255.255.250 ihl 20 ttl 1 DF prot UDPUDP: len 175 58661->1900 Data 167M-SEARCH * HTTP/1.1HOST: 239.255.255.250:1900MAN: "ssdp:discover"MX: 1ST: urn:dial-multiscreen-org:service:dial:1USER-AGENT: Chromium/78.0.3904.108 Linux



Mike


Re: Direwolf Update Script Errors

Basil Gunn
 

Troy,
Thanks for sending your console output.
After re-reading your post I found a couple of problems with the
current direwolf updater script and fixed them with this commit.

https://github.com/nwdigitalradio/n7nix/commit/8a5f1db91f7e22d9b723fbc68c344116d19cbc9b#diff-9dad93678321e85889f7ddfb8f1bafc2

This version of dw_update.sh will automatically edit dwgpsd.c so that
direwolf builds without error.
Please update your repository scripts and retry updating direwolf.

cd
cd n7nix
git pull

cd direwolf
sudo su
./dw_update.sh

/Basil n7nix

Troy - K4JDA <troy.davis@hotmail.com> writes:

Im running the direwolf update script
sudo ./dw_update.sh
and get the following errors (snip of the last several lines of output):

...
inflating: direwolf-dev/test/scripts/check-modem9600
inflating: direwolf-dev/tnc-test-cd-results.png
finishing deferred symbolic links:
direwolf-dev/debian/changelog -> ../CHANGES.md
Building direwolf in directory /usr/local/src/direwolf-dev
As of Jan 6 (May 2) build will fail with "
/usr/local/src/direwolf-dev/src/dwgpsd.c:65:2: error: #error libgps API version might be incompatible.
See direwolf github issues #241

mkdir: cannot create directory ‘build’: File exists
CMake Error: The source directory "/usr/local/src" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target 'install'. Stop.

direwolf version was: version is now: Dire Wolf DEVELOPMENT version 1.6 E (May 11 2020)


Re: Direwolf Update Script Errors

Basil Gunn
 

Read direwolf issue #241. Until John wb2osz fixes direwolf to be
compatible with gpsd version 3.20 this problem will persist.

https://github.com/wb2osz/direwolf/issues/241

If you are running direwolf DEVELOPMENT version 1.6 E that is the
current version supplied on the latest sd card image (NWDR16.img) file.

If you want your build to succeed then change the upper
API_MAJOR_VERSION number comparison from an 8 to a 9 in the following
line in dwgpsd.c and rebuild.

Change this line:
#if GPSD_API_MAJOR_VERSION < 5 || GPSD_API_MAJOR_VERSION > 8

to this:

#if GPSD_API_MAJOR_VERSION < 5 || GPSD_API_MAJOR_VERSION > 9

/Basil n7nix

Troy - K4JDA <troy.davis@hotmail.com> writes:

Im running the direwolf update script
sudo ./dw_update.sh
and get the following errors (snip of the last several lines of output):

...
inflating: direwolf-dev/test/scripts/check-modem9600
inflating: direwolf-dev/tnc-test-cd-results.png
finishing deferred symbolic links:
direwolf-dev/debian/changelog -> ../CHANGES.md
Building direwolf in directory /usr/local/src/direwolf-dev
As of Jan 6 (May 2) build will fail with "
/usr/local/src/direwolf-dev/src/dwgpsd.c:65:2: error: #error libgps API version might be incompatible.
See direwolf github issues #241

mkdir: cannot create directory ‘build’: File exists
CMake Error: The source directory "/usr/local/src" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
make: *** No targets specified and no makefile found. Stop.
make: *** No rule to make target 'install'. Stop.

direwolf version was: version is now: Dire Wolf DEVELOPMENT version 1.6 E (May 11 2020)


Direwolf Update Script Errors

Troy - K4JDA
 

Im running the direwolf update script
sudo ./dw_update.sh
and get the following errors (snip of the last several lines of output):

...
 inflating: direwolf-dev/test/scripts/check-modem9600  
  inflating: direwolf-dev/tnc-test-cd-results.png  
finishing deferred symbolic links:
  direwolf-dev/debian/changelog -> ../CHANGES.md
Building direwolf in directory /usr/local/src/direwolf-dev
As of Jan 6 (May 2) build will fail with "
   /usr/local/src/direwolf-dev/src/dwgpsd.c:65:2: error: #error libgps API version might be incompatible.
See direwolf github issues #241
 
mkdir: cannot create directory ‘build’: File exists
CMake Error: The source directory "/usr/local/src" does not appear to contain CMakeLists.txt.
Specify --help for usage, or press the help button on the CMake GUI.
make: *** No targets specified and no makefile found.  Stop.
make: *** No rule to make target 'install'.  Stop.
 
direwolf version was: version is now: Dire Wolf DEVELOPMENT version 1.6 E (May 11 2020)
 


lessons learned, problems solved using Pat and ax25

Mike B
 

Like a lot of folks I would get errors while using Pat to do winlink messaging.on packet

The symptoms were various time outs, and always when large messages were involved.

I did a lot of troubleshooting, doublechecking settings, reading multiple articles on ax25 etc...

During all this it was recommended to monitor axlisten

$ sudo axlisten -a -r -t

axlisten as listed above will show the outgoing and incoming packets.

While doing this I noticed a lot of packet repeats...ignored calls and rejected packets...and eventually it would timeout.

On a guess, I thought maybe I was overdriving the audio...same settings I had been using since I got it working initially, and that had worked for shorter messages.

So I lowered the digital gain to 0.

I continued to monitor the axlisten and pretty much all of the errors went away...sure there is an occasionally repeat, but not constant repeats, and no ignored responses.

So for those of you struggling with this...monitor axlisten and if you see lots of RRs and REJs  then you may have an audio problem...

It would be obvious if I turned the gain too far down...then the receiver never would have responded to my packets.

You don't need to actually be doing any transmitting to use axlisten...it will here any station on that freq sending and receiving messages...that was part of the clue, those messages (other stations traffic) were much cleaner than mine (no rejected packets...quick responses)

Mike


Re: What is the 8-pin connector for on the DRAWS hat?

Basil Gunn
 

I was just wondering what the 8-pin Berg socket on the DRAWS hat is
for. I can't figure out where it is on the schematic.
DRAWS 8 Pin Auxiliary Connector
https://github.com/nwdigitalradio/n7nix/blob/master/docs/DRAWS_AUX_PORT.md

On the schematic 8-pin connector is designated SHDR-8 in grid 4A
https://nw-digital-radio.groups.io/g/udrc/files/DRAWSTech.pdf

921 - 940 of 5712