Date   
Re: Adding a second radio

 

Jack, Jim, et al --

The two approaches meet different needs.

I use both, depending on what applications I am trying to support.

If the applications you are trying to support require the Linux AX.25 stack, then Basil's scripts and setup are the better solution.  This tends to be a lot of historical applications for Keyboard to Keyboard, BBS, IP over AX.25, AX.25 over IP, ... and can also support newer applications in the Winlink and APRS world.

However, direwolf, in addition to being the modem can support many functions without the need for the Linux AX.25 stack.  It can directly support digipeating, APRS®, Igating, beaconing (including GPS parsing), KISS, Network KISS/AGW, APRS® TouchTone™, and more.  All via configuration in direwolf.conf with fewer 'moving parts'. I consider it a simpler approach, if it meets your needs.

The choice is driven by application requirements and user preference.


On Fri, Oct 11, 2019 at 9:51 AM Jack Spitznagel <kd4iz@...> wrote:
Jim, Basil and John, All,

I would like to hear that explained as well. I started with John's approach early after DRAWS became available, then switched over to Basil's install script with the AX25 internals in Raspbian. They both work for me, but I was doing "quick and dirty" evals of the beta images when I set things up. I found that the Direwolf alone approach was easier for switching from AX.25 to HF modem function. I have to work at 'script-kiddie" level in Linux. I am busy with real work and I need to reconfigure it so very little that I have to go back and reference my notes (which are not great) each time I fire up. I would love to see an install choice be offered in the configuration scripts.

John, Basil, is that easily do-able without creating internal dissension or is it a philosophic divide you would rather not bridge?

No doubt there are good reasons for both approaches... however, I am a realist and know I will not get time to go "larval stage" with the OS until I retire, so as smooth and efficient as Basil's approach may be, it seems less flexible than having GUI access to Direwolf, being able to check its status and shut it down without bringing up a terminal or creating a bunch of icons linked to scripts that switch things for me. Typical lazy ham, I guess.

In the meantime I have a DRAWS in my "go-box" for portable digital work and one on the desk here running Xastir as a fill-in digi and inet gateway for local 144.39 users.

Thanks for all of your hard work supporting this little beast!
--
Jack - KD4IZ



--
John D. Hays
Kingston, WA
K7VE

 

Re: Adding a second radio

 

The two approaches meet different needs.

I use both, depending on what applications I am trying to support.

If the applications you are trying to support require the Linux AX.25 stack, then Basil's scripts and setup are the better solution. This tends to be a lot of historical applications for Keyboard to Keyboard, BBS, IP over AX.25, AX.25 over IP, ... and can also support newer applications in the Winlink and APRS world.

However, direwolf, in addition to being the modem can support many functions without the
And you can install either LinBPQ or JNOS to do packet without the
complexity of dealing with the Linux AX.25 stack. (Not saying that
LinBPQ or JNOS are less complex....)

Bill

Re: Adding a second radio

Basil Gunn
 

And you can install either LinBPQ or JNOS to do packet without the
complexity of dealing with the Linux AX.25 stack. (Not saying that
LinBPQ or JNOS are less complex....)
The Linux AX.25 stack comes with the kernel and is installed on our
image and configured with my scripts taking the complexity out of
dealing with Linux AX.25 stack. Bill you should try it some time.

You can use LinBPQ or JNOS, I think they are good pieces of software but
I don't support them.

/Basil

Re: Eureka!!!! She works perfectly!!

Anthony Sutera
 

I have the 817 and have tried for weeks to get solid audio out to the radio.  Does anyone have a configuration that is really working ? If so please post it.  Thank you! Tony

Re: Eureka!!!! She works perfectly!!

 

The FT-817 is a heavily tested radio with the UDRC and DRAWS boards.  There are built-in configurations on the image.

What application(s) are you trying to setup?

The proper way to set audio levels is using Draws™ Manager  -- the FT-817 settings assume the FT-817 internal menu settings are at default, so you may want to do a factory reset on the radio.  Also note that removing the squelch pin (PIN 6) in the cable is generally required on Yaesu radios.

Have you followed the recall notes?  If you have a newer board with the SMA coming out the same end as the power jack, you should review the thread and specifically https://nw-digital-radio.groups.io/g/udrc/message/3977



On Sun, Oct 13, 2019 at 3:10 PM <tsutera@...> wrote:
I have the 817 and have tried for weeks to get solid audio out to the radio.  Does anyone have a configuration that is really working ? If so please post it.  Thank you! Tony


--
John D. Hays
Kingston, WA
K7VE

 

Re: Eureka!!!! She works perfectly!!

K4KDR
 

Appreciate all the info shared about this product!

I don't know about the FT-817, but my FT-857d works great with the latest DRAWS board using an un-modified 6-pin data cable (NO pins removed).  Just wanted to mention in case anyone with an FT-857d sees this post and wonders if they have to make any cable modifications.

-Scott,  K4KDR

====================


On Sun, Oct 13, 2019 at 6:35 PM John D Hays - K7VE <john@...> wrote:
The FT-817 is a heavily tested radio with the UDRC and DRAWS boards.  There are built-in configurations on the image.

What application(s) are you trying to setup?

The proper way to set audio levels is using Draws™ Manager  -- the FT-817 settings assume the FT-817 internal menu settings are at default, so you may want to do a factory reset on the radio.  Also note that removing the squelch pin (PIN 6) in the cable is generally required on Yaesu radios.

Have you followed the recall notes?  If you have a newer board with the SMA coming out the same end as the power jack, you should review the thread and specifically https://nw-digital-radio.groups.io/g/udrc/message/3977



On Sun, Oct 13, 2019 at 3:10 PM <tsutera@...> wrote:
I have the 817 and have tried for weeks to get solid audio out to the radio.  Does anyone have a configuration that is really working ? If so please post it.  Thank you! Tony


--
John D. Hays
Kingston, WA
K7VE

 


Re: Eureka!!!! She works perfectly!!

Anthony Sutera
 

Hello John,

I am running WSJT-X.  I have one of the boards that had the issue.  I removed both caps.  The RX audio works pretty well (but not quite as sensitive as my signal link).  I have tried multiple sets of cables with and without Pin6.  I ran the alsa command for the 817, played with multiple setting in the draws manager including changing to the right hand port.  The best I can get out the of the TX audio are occasional TX reports WSPR.

Thank you,
Tony 

On Oct 13, 2019, at 4:34 PM, John D Hays - K7VE <john@...> wrote:

The FT-817 is a heavily tested radio with the UDRC and DRAWS boards.  There are built-in configurations on the image.

What application(s) are you trying to setup?

The proper way to set audio levels is using Draws™ Manager  -- the FT-817 settings assume the FT-817 internal menu settings are at default, so you may want to do a factory reset on the radio.  Also note that removing the squelch pin (PIN 6) in the cable is generally required on Yaesu radios.

Have you followed the recall notes?  If you have a newer board with the SMA coming out the same end as the power jack, you should review the thread and specifically https://nw-digital-radio.groups.io/g/udrc/message/3977



On Sun, Oct 13, 2019 at 3:10 PM <tsutera@...> wrote:
I have the 817 and have tried for weeks to get solid audio out to the radio.  Does anyone have a configuration that is really working ? If so please post it.  Thank you! Tony


--
John D. Hays
Kingston, WA
K7VE

 


KC9KKORE: Second interface

J P Watters
 

John,

I saw that you referenced that you were able to run 9600 and or 1200 on a single radio interface. 

Can you refer us to the code, configuration that allows for on the fly switchng between Direwolf 9600/1200 baud packet speeds.

..jpw J P Watters
KC9KKO

Re: Eureka!!!! She works perfectly!!

Mitch Winkle
 

I found after my board was fixed by NWDR that DRAWS manger values were not even close to appropriate for using FLDIGI, particularly on receive.  I also had to recompile FLDIGI using configure defaults (using no parameters) before the audio settled down properly.  I find the receive audio to be quite good with an apparent low noise floor from the sound card.  Transmit audio seems fine as well. 

FLDIGI has a process for setting audio that always works well, so I suggest using that rather than arbitrary values computed by DRAWS Manager.

On Oct 13, 2019, at 20:36, Anthony Sutera <tsutera@...> wrote:
Hello John,

I am running WSJT-X.  I have one of the boards that had the issue.  I removed both caps.  The RX audio works pretty well (but not quite as sensitive as my signal link).  I have tried multiple sets of cables with and without Pin6.  I ran the alsa command for the 817, played with multiple setting in the draws manager including changing to the right hand port.  The best I can get out the of the TX audio are occasional TX reports WSPR.

Thank you,
Tony 
On Oct 13, 2019, at 4:34 PM, John D Hays - K7VE < john@...> wrote:

The FT-817 is a heavily tested radio with the UDRC and DRAWS boards.  There are built-in configurations on the image.

What application(s) are you trying to setup?

The proper way to set audio levels is using Draws™ Manager  -- the FT-817 settings assume the FT-817 internal menu settings are at default, so you may want to do a factory reset on the radio.  Also note that removing the squelch pin (PIN 6) in the cable is generally required on Yaesu radios.

Have you followed the recall notes?  If you have a newer board with the SMA coming out the same end as the power jack, you should review the thread and specifically  https://nw-digital-radio.groups.io/g/udrc/message/3977



On Sun, Oct 13, 2019 at 3:10 PM < tsutera@...> wrote:
I have the 817 and have tried for weeks to get solid audio out to the radio.  Does anyone have a configuration that is really working ? If so please post it.  Thank you! Tony


--
John D. Hays
Kingston, WA
K7VE

 


Re: KC9KKORE: Second interface

Basil Gunn
 

J P,
I'm currently traveling with limited Internet access. Look for a script in
n7nix/debug/speed_switch.com. Will be more helpful when I return in about a week. /basil


On October 14, 2019 12:19:57 AM PDT, "J P Watters via Groups.Io" <kc9kko@...> wrote:
John,

I saw that you referenced that you were able to run 9600 and or 1200 on a single radio interface. 

Can you refer us to the code, configuration that allows for on the fly switchng between Direwolf 9600/1200 baud packet speeds.

..jpw J P Watters
KC9KKO

Re: KC9KKORE: Second interface

 

JP,

If you are asking about running 1200/9600 in parallel on the same radio port.  This only partially works at the current time.  It receives just fine and can transmit on one rate or the other.  The gating factor is activating PTT from direwolf.  The current version of direwolf allow only one channel to access a given GPIO PTT in configuration.  The configuration runs two virtual sound device on a single audio channel.   

If you simply want to switch between the two, look at Basil's script.

On Mon, Oct 14, 2019 at 12:19 AM J P Watters via Groups.Io <kc9kko=mac.com@groups.io> wrote:
John,

I saw that you referenced that you were able to run 9600 and or 1200 on a single radio interface. 

Can you refer us to the code, configuration that allows for on the fly switchng between Direwolf 9600/1200 baud packet speeds.

..jpw J P Watters
KC9KKO



--
John D. Hays
Kingston, WA
K7VE

 

Re: KC9KKORE: Second interface

 

On Mon, Oct 14, 2019 at 11:21 AM John D Hays - K7VE <@john_hays> wrote:

JP,

If you are asking about running 1200/9600 in parallel on the same radio port. This only partially works at the current time. It receives just fine and can transmit on one rate or the other. The gating factor is activating PTT from direwolf. The current version of direwolf allow only one channel to access a given GPIO PTT in configuration. The configuration runs two virtual sound device on a single audio channel.
How about running two instances of Direwolf?

Re: KC9KKORE: Second interface

Stuart Longland VK4MSL
 

On 15/10/19 8:56 am, Bill Vodall wrote:
On Mon, Oct 14, 2019 at 11:21 AM John D Hays - K7VE <@john_hays> wrote:

JP,

If you are asking about running 1200/9600 in parallel on the same radio port. This only partially works at the current time. It receives just fine and can transmit on one rate or the other. The gating factor is activating PTT from direwolf. The current version of direwolf allow only one channel to access a given GPIO PTT in configuration. The configuration runs two virtual sound device on a single audio channel.
How about running two instances of Direwolf?
You might run afoul of one instance of Direwolf opening the ALSA device for the sound card and locking out the second instance unless you do some trickery in the ALSA configuration files to present the UDRC/DRAWS as two separate audio interfaces.

This is doable of course, just may require a bit of research.
--
Stuart Longland (aka Redhatter, VK4MSL)

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

Re: KC9KKORE: Second interface

 

Multiple instances of the audio on a physical device is accomplished using PulseAudio. See the wiki. 


On Mon, Oct 14, 2019, 20:11 Stuart Longland VK4MSL <stuartl@...> wrote:
On 15/10/19 8:56 am, Bill Vodall wrote:
> On Mon, Oct 14, 2019 at 11:21 AM John D Hays - K7VE <john@...> wrote:
>>
>> JP,
>>
>> If you are asking about running 1200/9600 in parallel on the same radio port.  This only partially works at the current time.  It receives just fine and can transmit on one rate or the other.  The gating factor is activating PTT from direwolf.  The current version of direwolf allow only one channel to access a given GPIO PTT in configuration.  The configuration runs two virtual sound device on a single audio channel.
>
> How about running two instances of Direwolf?

You might run afoul of one instance of Direwolf opening the ALSA device
for the sound card and locking out the second instance unless you do
some trickery in the ALSA configuration files to present the UDRC/DRAWS
as two separate audio interfaces.

This is doable of course, just may require a bit of research.
--
Stuart Longland (aka Redhatter, VK4MSL)

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



GPS Monitoring for DRAWS

Edouard Lafargue
 

Hi everyone,

  Since the DRAWS is equipped with a GPS receiver, I figured I would write a quick web interface for it. I mostly use my Raspberry Pi station remotely from my Mac, and having a web interface to monitor the radio and GPS is fairly useful.

   I used the open source Wizkers.io framework to implement this, so that it works nicely with the remote rig control and monitoring that already exist for it (full disclosure, I am the developer). The code is not pushed to Github yet, but if there is interest, I'll be happy to oblige.

What other GPS information would you want to see on a status dashboard? The screenshots below are all web pages:

GPS Monitor screen:
Screen Shot 2019-10-16 at 09.36.07.png

Kenwood V71A remote control screen:

Screen Shot 2019-10-16 at 13.24.14.png

Re: GPS Monitoring for DRAWS

 

Very nice. A git repository would be very welcome.

On Wed, Oct 16, 2019 at 1:29 PM Edouard Lafargue <edouard@...> wrote:
Hi everyone,

  Since the DRAWS is equipped with a GPS receiver, I figured I would write a quick web interface for it. I mostly use my Raspberry Pi station remotely from my Mac, and having a web interface to monitor the radio and GPS is fairly useful.

   I used the open source Wizkers.io framework to implement this, so that it works nicely with the remote rig control and monitoring that already exist for it (full disclosure, I am the developer). The code is not pushed to Github yet, but if there is interest, I'll be happy to oblige.

What other GPS information would you want to see on a status dashboard? The screenshots below are all web pages:

GPS Monitor screen:
Screen Shot 2019-10-16 at 09.36.07.png

Kenwood V71A remote control screen:

Screen Shot 2019-10-16 at 13.24.14.png



--
John D. Hays
Kingston, WA
K7VE

 

Temporary mobile RMS Gateway for EMCOM #winlink #rms

Matthew Kozma
 

I am thinking of creating a mobile RMS gateway for temporary use on ARES & Search and Rescue missions. I have a rPi with a UDRC II in my vehicle. It is configured to run APRS using a radio on the DB15 port.  I also have a second radio connected the din port.  This radio is used by my laptop running Winlink and connecting via KISS port 2.  I have a hot spot in the vehicle too and was considering installing the RMS gateway on the rPi so that I can operate as a temporary RMS using that second radio.  My question is how can I start and stop the RMS gateway service.  I want to be able to control when that function is running.     

Re: Temporary mobile RMS Gateway for EMCOM #winlink #rms

 

Basil has limited email access for a few days, maybe ping this when he is back.

Re: GPS Monitoring for DRAWS

Ruben .
 

Hello Edouard,

Just wondering if your program uses or can use hamlib, this would greatly expand the number of radios your program can use.

Thank you and 73,
Ruben
WA2NBL

On 10/16/2019 1:28 PM, Edouard Lafargue wrote:,

Hi everyone,

  Since the DRAWS is equipped with a GPS receiver, I figured I would write a quick web interface for it. I mostly use my Raspberry Pi station remotely from my Mac, and having a web interface to monitor the radio and GPS is fairly useful.

   I used the open source Wizkers.io framework to implement this, so that it works nicely with the remote rig control and monitoring that already exist for it (full disclosure, I am the developer). The code is not pushed to Github yet, but if there is interest, I'll be happy to oblige.

What other GPS information would you want to see on a status dashboard? The screenshots below are all web pages:

GPS Monitor screen:
Screen Shot 2019-10-16 at 09.36.07.png

Kenwood V71A remote control screen:

Screen Shot 2019-10-16 at 13.24.14.png

Re: GPS Monitoring for DRAWS

Edouard Lafargue
 

It doesn't use hamlib so far - it does far more than hamlib can do for Elecraft or Kenwoodradios, but at the expense of wider rig support.

Source is at https://GitHub.com/wizkers/wizkers.git . I need to replublish the manual too...

On Wed, Oct 16, 2019, 17:08 Ruben . <rubenkaf@...> wrote:
Hello Edouard,

Just wondering if your program uses or can use hamlib, this would greatly expand the number of radios your program can use.

Thank you and 73,
Ruben
WA2NBL

On 10/16/2019 1:28 PM, Edouard Lafargue wrote:,
Hi everyone,

  Since the DRAWS is equipped with a GPS receiver, I figured I would write a quick web interface for it. I mostly use my Raspberry Pi station remotely from my Mac, and having a web interface to monitor the radio and GPS is fairly useful.

   I used the open source Wizkers.io framework to implement this, so that it works nicely with the remote rig control and monitoring that already exist for it (full disclosure, I am the developer). The code is not pushed to Github yet, but if there is interest, I'll be happy to oblige.

What other GPS information would you want to see on a status dashboard? The screenshots below are all web pages:

GPS Monitor screen:

Kenwood V71A remote control screen: