Topics

Multiple problems getting started with RigPi


James Cizek
 

Hello all,
I just got a brand new RigPi (MFJ1234). Having a slew of problems, many of which seem common but none of the answers I've found on the forum or otherwise either apply or work.

I've attempted to attach the RigPi to 2 different radios.  Here are the results:
Yaesu FT991a - Used the "USB id" program to generate a "Radio 2". It does not work, won't connect.
  if I use /dev/ttyUSB1 it works.  I see in dmesg that a /dev/ttyUSB0 and /dev/ttyUSB1 are both added when connecting the  radio.  It does work for CAT control with the USB1 device.

Yaesu FT891 - Used "USB id" program to generate a "Radio 1".  It does not work, won't connect.
dmesg also shows a /dev/ttyUSB0 and a /dev/ttyUSB1 added when this radio is plugged in.  Neither of those work.  I've done a factory reset on the radio, then went in and verified that CAT is enabled, and is at the default 4800 baud, they both were. I cannot get RigPi to talk to this radio at all. If i move the connection over to a PC running any sort of CAT software, it works fine.

On both radios, I have audio problems.  First, in the Mumble docs, it says I should have a "CARD=audioinjectorpi",  that is not there at all.  dmesg | grep audio returns NOTHING. If I connect the FT991a up, I do get a "USBCORE" device showing in dmesg, but Mumble errors when trying to use it "incorrect parameter" error.  I wanted to "start from scratch" and just reload the image, but the downloads section of the rigpi page seems to have nothing available.  Searching online seems to show that this isn't available.  

I am wondering if I received a DOA audio board from MFJ, and secondly, if anyone has any tips on what to try next on getting CAT to work on the 891.  I'd just like to see *anything* on this thing work.  I've watched all these plug and play videos on youtube and after days of screwing with this, are no closer to making anything work. Getting frustrated with it a little! 

I am highly familiar with Linux, RaspPI, and CAT and hardware, so technical things to check are OK to pass along.  Also, I've checked the USB cables, they both work fine when attached to PC's running CAT software. Thank you very much for any assistance you can offer!

73
KI0KN
James


Howard Nurse, W6HN
 

Hi James,

Welcome to the forum.

First, please use the Help provided with RigPi, much of the online help is old.  The audio device you want is snd_rpi_proto.  (This change was discussed quite a bit here in the forum last summer when the change was made.)  The USB ID program only finds the first detected USB port from a radio, so it needs to be updated for multiple-USB port rigs.  It is best to use the correct ttyUSBn port to connect to the radio.

You can test the radio connection independently from RigPi.  Open terminal and use the command rigctl -m <nnn> -r /dev/ttyUSBn  where nnn is the radio ID which you can get from the Radio Capabilities option in Advanced Radio Settings.  When it connects you will get a radio prompt.  Enter f to get the frequency.

--Howard


James Cizek
 

Hi Howard, thanks for the tips!  Is there a log for rigctl?  It seems not able to talk to the 891
i@rigpi:~ $ rigctl -m 136 -r /dev/ttyUSB0

Rig command: f
get_freq: error = Communication timed out

Rig command: q
pi@rigpi:~ $ rigctl -m 136 -r /dev/ttyUSB1

Rig command: f
get_freq: error = Communication timed out

^C
pi@rigpi:~ $ dmesg | grep ttyUSB
[   78.021798] usb 1-1.1.2: cp210x converter now attached to ttyUSB0
[   78.029936] usb 1-1.1.2: cp210x converter now attached to ttyUSB1
pi@rigpi:~ $ 

If I load Flrig, select the Silicon labs Port 0 port, it works great right here on the rigpi. Just can't get rigctl to work. Does that lead to any clues where I might look next?
Thanks

james
KI0KN

On Fri, Jun 19, 2020 at 2:38 PM Howard Nurse, W6HN <hlnurse@...> wrote:
Hi James,

Welcome to the forum.

First, please use the Help provided with RigPi, much of the online help is old.  The audio device you want is snd_rpi_proto.  (This change was discussed quite a bit here in the forum last summer when the change was made.)  The USB ID program only finds the first detected USB port from a radio, so it needs to be updated for multiple-USB port rigs.  It is best to use the correct ttyUSBn port to connect to the radio.

You can test the radio connection independently from RigPi.  Open terminal and use the command rigctl -m <nnn> -r /dev/ttyUSBn  where nnn is the radio ID which you can get from the Radio Capabilities option in Advanced Radio Settings.  When it connects you will get a radio prompt.  Enter f to get the frequency.

--Howard


James Cizek
 

Hmm, ok.  Learned something new.

First, the serial-by-id port I see in Flrig is symlinked to /dev/ttyUSB1.  So, that's good.
I am not sure if Flrig sent something to the rig to initialize it that rigctl wasn't or what, but I've got it connecting now. 

It's insanely slow though.  I moved the baud rate from 4800 to 38400 both in the rig and the rigpi software.  It's still really slow.  3 to 4 seconds after pushing PTT until the rig PTTs.  

I also have developed a whole new fun problem.  Now that the rig is connected, the audio board driver is completely missing.  The Mumble server no longer has any selectable input or output devices. Everything is grayed out.  I've been through the "no audio" troubleshooting section and it says "you may have an audio board in need of repair".

I am not convinced yet that all this changing of things hasn't caused an errant setting somewhere.  It's a shame after purchasing the MFJ1234 that I don't have access to the image that comes on it without re-purchasing it, but that seems to be the case.   I have purchased the image from MFJ.  I am going to set this SD card aside, and now that I know all the ports, going to start fresh and see if I get further.

Thanks for the update on the audio device name change. If I can get it to recognize an audio device again, I'll pick up from there!

73
James
KI0KN

On Fri, Jun 19, 2020 at 4:07 PM James Cizek via groups.io <james.m.cizek=gmail.com@groups.io> wrote:
Hi Howard, thanks for the tips!  Is there a log for rigctl?  It seems not able to talk to the 891
i@rigpi:~ $ rigctl -m 136 -r /dev/ttyUSB0

Rig command: f
get_freq: error = Communication timed out

Rig command: q
pi@rigpi:~ $ rigctl -m 136 -r /dev/ttyUSB1

Rig command: f
get_freq: error = Communication timed out

^C
pi@rigpi:~ $ dmesg | grep ttyUSB
[   78.021798] usb 1-1.1.2: cp210x converter now attached to ttyUSB0
[   78.029936] usb 1-1.1.2: cp210x converter now attached to ttyUSB1
pi@rigpi:~ $ 

If I load Flrig, select the Silicon labs Port 0 port, it works great right here on the rigpi. Just can't get rigctl to work. Does that lead to any clues where I might look next?
Thanks

james
KI0KN

On Fri, Jun 19, 2020 at 2:38 PM Howard Nurse, W6HN <hlnurse@...> wrote:
Hi James,

Welcome to the forum.

First, please use the Help provided with RigPi, much of the online help is old.  The audio device you want is snd_rpi_proto.  (This change was discussed quite a bit here in the forum last summer when the change was made.)  The USB ID program only finds the first detected USB port from a radio, so it needs to be updated for multiple-USB port rigs.  It is best to use the correct ttyUSBn port to connect to the radio.

You can test the radio connection independently from RigPi.  Open terminal and use the command rigctl -m <nnn> -r /dev/ttyUSBn  where nnn is the radio ID which you can get from the Radio Capabilities option in Advanced Radio Settings.  When it connects you will get a radio prompt.  Enter f to get the frequency.

--Howard


Glenn VE9GJ
 

Hi James
In my experience the yaseu rigs that have 2 ttyUSB# ports you always want to use the higher number port. Do you have PTT via CAT set?
I think you mentioned a FT-991 earlier, it works FB with the USB sound. Not sure if the 891 has USB sound.
73
Glenn VE9GJ


On June 19, 2020 7:54:18 PM ADT, James Cizek <james.m.cizek@...> wrote:
Hmm, ok.  Learned something new.

First, the serial-by-id port I see in Flrig is symlinked to /dev/ttyUSB1.  So, that's good.
I am not sure if Flrig sent something to the rig to initialize it that rigctl wasn't or what, but I've got it connecting now. 

It's insanely slow though.  I moved the baud rate from 4800 to 38400 both in the rig and the rigpi software.  It's still really slow.  3 to 4 seconds after pushing PTT until the rig PTTs.  

I also have developed a whole new fun problem.  Now that the rig is connected, the audio board driver is completely missing.  The Mumble server no longer has any selectable input or output devices. Everything is grayed out.  I've been through the "no audio" troubleshooting section and it says "you may have an audio board in need of repair".

I am not convinced yet that all this changing of things hasn't caused an errant setting somewhere.  It's a shame after purchasing the MFJ1234 that I don't have access to the image that comes on it without re-purchasing it, but that seems to be the case.   I have purchased the image from MFJ.  I am going to set this SD card aside, and now that I know all the ports, going to start fresh and see if I get further.

Thanks for the update on the audio device name change. If I can get it to recognize an audio device again, I'll pick up from there!

73
James
KI0KN

On Fri, Jun 19, 2020 at 4:07 PM James Cizek via groups.io <james.m.cizek=gmail.com@groups.io> wrote:
Hi Howard, thanks for the tips!  Is there a log for rigctl?  It seems not able to talk to the 891
i@rigpi:~ $ rigctl -m 136 -r /dev/ttyUSB0

Rig command: f
get_freq: error = Communication timed out

Rig command: q
pi@rigpi:~ $ rigctl -m 136 -r /dev/ttyUSB1

Rig command: f
get_freq: error = Communication timed out

^C
pi@rigpi:~ $ dmesg | grep ttyUSB
[   78.021798] usb 1-1.1.2: cp210x converter now attached to ttyUSB0
[   78.029936] usb 1-1.1.2: cp210x converter now attached to ttyUSB1
pi@rigpi:~ $ 

If I load Flrig, select the Silicon labs Port 0 port, it works great right here on the rigpi. Just can't get rigctl to work. Does that lead to any clues where I might look next?
Thanks

james
KI0KN

On Fri, Jun 19, 2020 at 2:38 PM Howard Nurse, W6HN <hlnurse@...> wrote:
Hi James,

Welcome to the forum.

First, please use the Help provided with RigPi, much of the online help is old.  The audio device you want is snd_rpi_proto.  (This change was discussed quite a bit here in the forum last summer when the change was made.)  The USB ID program only finds the first detected USB port from a radio, so it needs to be updated for multiple-USB port rigs.  It is best to use the correct ttyUSBn port to connect to the radio.

You can test the radio connection independently from RigPi.  Open terminal and use the command rigctl -m <nnn> -r /dev/ttyUSBn  where nnn is the radio ID which you can get from the Radio Capabilities option in Advanced Radio Settings.  When it connects you will get a radio prompt.  Enter f to get the frequency.

--Howard


James Cizek
 

Hi Glenn, 

No I do not believe the 891 has the built in sound card.  It doesn't matter though, I can't get either one (the built in on the 991 nor the audio board on the rig pi for the 891) to pass any audio.  I get "parameter errors" in Mumble using either one of them.  Can't seem to find logs to help me troubleshoot what is really going on under the covers.

I have found the same as you though, typically the higher numbered port on Yaesu's is the one to use, but ironically, on the 891, it only works with the lower numbered one.  I am not sure what else I have wrong, it's so laggy it's unusable.  3 or 4 seconds from pressing ptt in the web client to the actual radio keying, and 1 to 2 seconds to show a frequency or mode change. CPU on the pi is at 10%, so it's not that.  I upped the baud rate on the CAT to 38400 on radio and software, not that either.

I figured maybe I "pushed too many buttons" so I purchased the rigpi image file from MFJ so I could start over from scratch.  That image boots fine, but it's stuck in 640x480 mode.  Using the resolution change in raspi-config says it's succeeds, but upon reboot, drops right back to 640x480.  Everything on the screen is too large to use.

I'm an IT guy by trade, with a long history in Land mobile radio, this stuff should be a piece of cake, but I find that the lack of identifying log files that have any useful data in them is making my challenge more difficult :)

Thanks for your note.
73
James
KI0KN

On Fri, Jun 19, 2020 at 6:57 PM Glenn VE9GJ <ve9gj@...> wrote:
Hi James
In my experience the yaseu rigs that have 2 ttyUSB# ports you always want to use the higher number port. Do you have PTT via CAT set?
I think you mentioned a FT-991 earlier, it works FB with the USB sound. Not sure if the 891 has USB sound.
73
Glenn VE9GJ

On June 19, 2020 7:54:18 PM ADT, James Cizek <james.m.cizek@...> wrote:
Hmm, ok.  Learned something new.

First, the serial-by-id port I see in Flrig is symlinked to /dev/ttyUSB1.  So, that's good.
I am not sure if Flrig sent something to the rig to initialize it that rigctl wasn't or what, but I've got it connecting now. 

It's insanely slow though.  I moved the baud rate from 4800 to 38400 both in the rig and the rigpi software.  It's still really slow.  3 to 4 seconds after pushing PTT until the rig PTTs.  

I also have developed a whole new fun problem.  Now that the rig is connected, the audio board driver is completely missing.  The Mumble server no longer has any selectable input or output devices. Everything is grayed out.  I've been through the "no audio" troubleshooting section and it says "you may have an audio board in need of repair".

I am not convinced yet that all this changing of things hasn't caused an errant setting somewhere.  It's a shame after purchasing the MFJ1234 that I don't have access to the image that comes on it without re-purchasing it, but that seems to be the case.   I have purchased the image from MFJ.  I am going to set this SD card aside, and now that I know all the ports, going to start fresh and see if I get further.

Thanks for the update on the audio device name change. If I can get it to recognize an audio device again, I'll pick up from there!

73
James
KI0KN

On Fri, Jun 19, 2020 at 4:07 PM James Cizek via groups.io <james.m.cizek=gmail.com@groups.io> wrote:
Hi Howard, thanks for the tips!  Is there a log for rigctl?  It seems not able to talk to the 891
i@rigpi:~ $ rigctl -m 136 -r /dev/ttyUSB0

Rig command: f
get_freq: error = Communication timed out

Rig command: q
pi@rigpi:~ $ rigctl -m 136 -r /dev/ttyUSB1

Rig command: f
get_freq: error = Communication timed out

^C
pi@rigpi:~ $ dmesg | grep ttyUSB
[   78.021798] usb 1-1.1.2: cp210x converter now attached to ttyUSB0
[   78.029936] usb 1-1.1.2: cp210x converter now attached to ttyUSB1
pi@rigpi:~ $ 

If I load Flrig, select the Silicon labs Port 0 port, it works great right here on the rigpi. Just can't get rigctl to work. Does that lead to any clues where I might look next?
Thanks

james
KI0KN

On Fri, Jun 19, 2020 at 2:38 PM Howard Nurse, W6HN <hlnurse@...> wrote:
Hi James,

Welcome to the forum.

First, please use the Help provided with RigPi, much of the online help is old.  The audio device you want is snd_rpi_proto.  (This change was discussed quite a bit here in the forum last summer when the change was made.)  The USB ID program only finds the first detected USB port from a radio, so it needs to be updated for multiple-USB port rigs.  It is best to use the correct ttyUSBn port to connect to the radio.

You can test the radio connection independently from RigPi.  Open terminal and use the command rigctl -m <nnn> -r /dev/ttyUSBn  where nnn is the radio ID which you can get from the Radio Capabilities option in Advanced Radio Settings.  When it connects you will get a radio prompt.  Enter f to get the frequency.

--Howard


jason kitchens
 

I'm using the downloaded image and having trouble with resolution as well.


Glenn VE9GJ
 

Hi James

I am sure you will get it figured out, just off to rough start.
Not sure why raspi-config won't change the screen resolution for you, are you using an hdmi monitor or VNC?

I think I misled you and the Yaseu needs to use the lower number port. It's been a long week.

On a terminal on rigpi (or ssh to the rig pi) try running hamlib directly. Radio needs to be disconnected in the Tuner page.
run
rigctl -m 136 -r /dev/ttyUSB0
(if you need to add a baud rate it is ie: -s 38400)
this should return a Rig command: prompt
type f <enter> and it will return the frequency. It should be almost instant. If it is not we need to solve this first.
BTW ? will show you a list of commands, q is quit

In a terminal what does aplay -l show?
73
Glenn VE9GJ

On 2020-06-19 10:53 p.m., James Cizek wrote:
Hi Glenn,
No I do not believe the 891 has the built in sound card. It doesn't matter
though, I can't get either one (the built in on the 991 nor the audio board
on the rig pi for the 891) to pass any audio. I get "parameter errors" in
Mumble using either one of them. Can't seem to find logs to help me
troubleshoot what is really going on under the covers.
I have found the same as you though, typically the higher numbered port on
Yaesu's is the one to use, but ironically, on the 891, it only works with
the lower numbered one. I am not sure what else I have wrong, it's so
laggy it's unusable. 3 or 4 seconds from pressing ptt in the web client to
the actual radio keying, and 1 to 2 seconds to show a frequency or mode
change. CPU on the pi is at 10%, so it's not that. I upped the baud rate
on the CAT to 38400 on radio and software, not that either.
I figured maybe I "pushed too many buttons" so I purchased the rigpi image
file from MFJ so I could start over from scratch. That image boots fine,
but it's stuck in 640x480 mode. Using the resolution change in
raspi-config says it's succeeds, but upon reboot, drops right back to
640x480. Everything on the screen is too large to use.
I'm an IT guy by trade, with a long history in Land mobile radio, this
stuff should be a piece of cake, but I find that the lack of identifying
log files that have any useful data in them is making my challenge more
difficult :)
Thanks for your note.
73
James
KI0KN


James Cizek
 

hi Glenn,
Thanks for the help!

I am now able to connect and control both the FT891 and 991, but the 891 lag is so bad it's unusable.  Anything you do in the webclient takes 3 seconds to show up on the radio (ie, press PTT and 3 seconds later the radio PTTs).

So I am throwing in the towel on the 891 for now.  The 991 is responding in a time manner that is appropriate.

However, still having the audio issues.  aplay -i shows:  aplay:main:788: audio open error: Device or resource busy
I am using [sysdefault:CARD=sndiproto] snd_rpi_proto, Default Audio Device in Mumble.

I am also a little confused on the client side.  Do I need anything running on the client to receive/transmit audio?  I keep seeing references to "plumble" for a mobile phone.  Is there a client that has to be installed on a PC?  On a mobile device?  If there is documentation about this, I haven't found it yet. 

Thank you!  
James
KI0KN

On Fri, Jun 19, 2020 at 8:27 PM Glenn VE9GJ <ve9gj@...> wrote:
Hi James

I am sure you will get it figured out, just off to rough start.
Not sure why raspi-config won't change the screen resolution for you,
are you using an hdmi monitor or VNC?

I think I misled you and the Yaseu needs to use the lower number port.
It's been a long week.

On a terminal on rigpi (or ssh to the rig pi) try running hamlib
directly. Radio needs to be disconnected in the Tuner page.
run
rigctl -m 136 -r /dev/ttyUSB0
(if you need to add a baud rate it is ie: -s 38400)
this should return a Rig command: prompt
type f  <enter> and it will return the frequency. It should be almost
instant. If it is not we need to solve this first.
BTW ? will show you a list of commands, q is quit

In a terminal what does aplay -l show?
73
Glenn VE9GJ



On 2020-06-19 10:53 p.m., James Cizek wrote:
> Hi Glenn,
>
> No I do not believe the 891 has the built in sound card.  It doesn't matter
> though, I can't get either one (the built in on the 991 nor the audio board
> on the rig pi for the 891) to pass any audio.  I get "parameter errors" in
> Mumble using either one of them.  Can't seem to find logs to help me
> troubleshoot what is really going on under the covers.
>
> I have found the same as you though, typically the higher numbered port on
> Yaesu's is the one to use, but ironically, on the 891, it only works with
> the lower numbered one.  I am not sure what else I have wrong, it's so
> laggy it's unusable.  3 or 4 seconds from pressing ptt in the web client to
> the actual radio keying, and 1 to 2 seconds to show a frequency or mode
> change. CPU on the pi is at 10%, so it's not that.  I upped the baud rate
> on the CAT to 38400 on radio and software, not that either.
>
> I figured maybe I "pushed too many buttons" so I purchased the rigpi image
> file from MFJ so I could start over from scratch.  That image boots fine,
> but it's stuck in 640x480 mode.  Using the resolution change in
> raspi-config says it's succeeds, but upon reboot, drops right back to
> 640x480.  Everything on the screen is too large to use.
>
> I'm an IT guy by trade, with a long history in Land mobile radio, this
> stuff should be a piece of cake, but I find that the lack of identifying
> log files that have any useful data in them is making my challenge more
> difficult :)
>
> Thanks for your note.
> 73
> James
> KI0KN
>




James Cizek
 

OK, I just flat missed the line in the manual that says you have to have a VOIP client installed on each device.

Got that. I downloaded, configured, installed Mumble on a PC to test.  Still no audio, so I think I still have an issue on the rigpi side.

Glenn, you mentioned 'aplay -i'   What should I see from that output?  I am not if I am getting device busy because the mumble server is attached to that sound device maybe?  

Thanks.
James
KI0KN

On Sun, Jun 21, 2020 at 7:36 PM James Cizek via groups.io <james.m.cizek=gmail.com@groups.io> wrote:
hi Glenn,
Thanks for the help!

I am now able to connect and control both the FT891 and 991, but the 891 lag is so bad it's unusable.  Anything you do in the webclient takes 3 seconds to show up on the radio (ie, press PTT and 3 seconds later the radio PTTs).

So I am throwing in the towel on the 891 for now.  The 991 is responding in a time manner that is appropriate.

However, still having the audio issues.  aplay -i shows:  aplay:main:788: audio open error: Device or resource busy
I am using [sysdefault:CARD=sndiproto] snd_rpi_proto, Default Audio Device in Mumble.

I am also a little confused on the client side.  Do I need anything running on the client to receive/transmit audio?  I keep seeing references to "plumble" for a mobile phone.  Is there a client that has to be installed on a PC?  On a mobile device?  If there is documentation about this, I haven't found it yet. 

Thank you!  
James
KI0KN

On Fri, Jun 19, 2020 at 8:27 PM Glenn VE9GJ <ve9gj@...> wrote:
Hi James

I am sure you will get it figured out, just off to rough start.
Not sure why raspi-config won't change the screen resolution for you,
are you using an hdmi monitor or VNC?

I think I misled you and the Yaseu needs to use the lower number port.
It's been a long week.

On a terminal on rigpi (or ssh to the rig pi) try running hamlib
directly. Radio needs to be disconnected in the Tuner page.
run
rigctl -m 136 -r /dev/ttyUSB0
(if you need to add a baud rate it is ie: -s 38400)
this should return a Rig command: prompt
type f  <enter> and it will return the frequency. It should be almost
instant. If it is not we need to solve this first.
BTW ? will show you a list of commands, q is quit

In a terminal what does aplay -l show?
73
Glenn VE9GJ



On 2020-06-19 10:53 p.m., James Cizek wrote:
> Hi Glenn,
>
> No I do not believe the 891 has the built in sound card.  It doesn't matter
> though, I can't get either one (the built in on the 991 nor the audio board
> on the rig pi for the 891) to pass any audio.  I get "parameter errors" in
> Mumble using either one of them.  Can't seem to find logs to help me
> troubleshoot what is really going on under the covers.
>
> I have found the same as you though, typically the higher numbered port on
> Yaesu's is the one to use, but ironically, on the 891, it only works with
> the lower numbered one.  I am not sure what else I have wrong, it's so
> laggy it's unusable.  3 or 4 seconds from pressing ptt in the web client to
> the actual radio keying, and 1 to 2 seconds to show a frequency or mode
> change. CPU on the pi is at 10%, so it's not that.  I upped the baud rate
> on the CAT to 38400 on radio and software, not that either.
>
> I figured maybe I "pushed too many buttons" so I purchased the rigpi image
> file from MFJ so I could start over from scratch.  That image boots fine,
> but it's stuck in 640x480 mode.  Using the resolution change in
> raspi-config says it's succeeds, but upon reboot, drops right back to
> 640x480.  Everything on the screen is too large to use.
>
> I'm an IT guy by trade, with a long history in Land mobile radio, this
> stuff should be a piece of cake, but I find that the lack of identifying
> log files that have any useful data in them is making my challenge more
> difficult :)
>
> Thanks for your note.
> 73
> James
> KI0KN
>




Glenn VE9GJ
 

Hi James
The command is aplay -l (lower case L)
It should list all the output sound devices that the pi thinks it has. arec -l should do the same for input audio.
You only need the USB cable for the 991 and it should appear as USB Codec I believe. On the pi desktop mumble set up what are your choices for audio in with 991 plugged in?
73
Glenn VE9GJ


On June 22, 2020 10:02:49 AM ADT, James Cizek <james.m.cizek@...> wrote:
OK, I just flat missed the line in the manual that says you have to have a VOIP client installed on each device.

Got that. I downloaded, configured, installed Mumble on a PC to test.  Still no audio, so I think I still have an issue on the rigpi side.

Glenn, you mentioned 'aplay -i'   What should I see from that output?  I am not if I am getting device busy because the mumble server is attached to that sound device maybe?  

Thanks.
James
KI0KN

On Sun, Jun 21, 2020 at 7:36 PM James Cizek via groups.io <james.m.cizek=gmail.com@groups.io> wrote:
hi Glenn,
Thanks for the help!

I am now able to connect and control both the FT891 and 991, but the 891 lag is so bad it's unusable.  Anything you do in the webclient takes 3 seconds to show up on the radio (ie, press PTT and 3 seconds later the radio PTTs).

So I am throwing in the towel on the 891 for now.  The 991 is responding in a time manner that is appropriate.

However, still having the audio issues.  aplay -i shows:  aplay:main:788: audio open error: Device or resource busy
I am using [sysdefault:CARD=sndiproto] snd_rpi_proto, Default Audio Device in Mumble.

I am also a little confused on the client side.  Do I need anything running on the client to receive/transmit audio?  I keep seeing references to "plumble" for a mobile phone.  Is there a client that has to be installed on a PC?  On a mobile device?  If there is documentation about this, I haven't found it yet. 

Thank you!  
James
KI0KN

On Fri, Jun 19, 2020 at 8:27 PM Glenn VE9GJ <ve9gj@...> wrote:
Hi James

I am sure you will get it figured out, just off to rough start.
Not sure why raspi-config won't change the screen resolution for you,
are you using an hdmi monitor or VNC?

I think I misled you and the Yaseu needs to use the lower number port.
It's been a long week.

On a terminal on rigpi (or ssh to the rig pi) try running hamlib
directly. Radio needs to be disconnected in the Tuner page.
run
rigctl -m 136 -r /dev/ttyUSB0
(if you need to add a baud rate it is ie: -s 38400)
this should return a Rig command: prompt
type f  <enter> and it will return the frequency. It should be almost
instant. If it is not we need to solve this first.
BTW ? will show you a list of commands, q is quit

In a terminal what does aplay -l show?
73
Glenn VE9GJ



On 2020-06-19 10:53 p.m., James Cizek wrote:
> Hi Glenn,
>
> No I do not believe the 891 has the built in sound card.  It doesn't matter
> though, I can't get either one (the built in on the 991 nor the audio board
> on the rig pi for the 891) to pass any audio.  I get "parameter errors" in
> Mumble using either one of them.  Can't seem to find logs to help me
> troubleshoot what is really going on under the covers.
>
> I have found the same as you though, typically the higher numbered port on
> Yaesu's is the one to use, but ironically, on the 891, it only works with
> the lower numbered one.  I am not sure what else I have wrong, it's so
> laggy it's unusable.  3 or 4 seconds from pressing ptt in the web client to
> the actual radio keying, and 1 to 2 seconds to show a frequency or mode
> change. CPU on the pi is at 10%, so it's not that.  I upped the baud rate
> on the CAT to 38400 on radio and software, not that either.
>
> I figured maybe I "pushed too many buttons" so I purchased the rigpi image
> file from MFJ so I could start over from scratch.  That image boots fine,
> but it's stuck in 640x480 mode.  Using the resolution change in
> raspi-config says it's succeeds, but upon reboot, drops right back to
> 640x480.  Everything on the screen is too large to use.
>
> I'm an IT guy by trade, with a long history in Land mobile radio, this
> stuff should be a piece of cake, but I find that the lack of identifying
> log files that have any useful data in them is making my challenge more
> difficult :)
>
> Thanks for your note.
> 73
> James
> KI0KN
>




Kelehigh@...
 

Hello RigPi group!

I haven't been active in the RigPi project game for quite awhile due to various other work commitments / projects etc. including building/installing 3 new antennas but I did at one time spend the effort to install RigPi on a ICOM IC 718 and felt the pain.

I did have many of the problems that James writes about below on my rig integrating RigPi. However when I was reading the RigPi Group memos in that time period, I had the impression that RigPi was bulletproof on Yaesu rigs. However as I read more of these recent accounts now I see that I was wrong.

I am an ex/old systems engineer and if I was the lead system engineer and/or Quality Manager on the RigPi project, I would have a detailed list of all bugs and be working them systematically by providing periodic releases (I called them dot releases such as 1.1, 1.2, 1.3 etc) when I had fixed various batches of them (maybe by platform, mode of operation, specific key client requests, etc). I also would be compiling a list of enhancement requests for the next general release that I would call release 2.0, 3.0, 4.0, etc. I would of course be doing both activities for each platform for the various Kenwoods, ICOMs and Yaesus and other platforms out there that our product supported. When I worked in CAD/CAE product development for SDRC/ Unisys this took a lot of effort and was costly. We had a beta test group of 50 or so high end clients in all industries that we gave the software to for as many days as it took (usually 30-60) to beat on it to try to break in an attempt to make our product bulletproof (we never quite made it using inside resources only). We would get daily inputs from these customers; their inputs each day would be followed by furious session of providing "fixes" and regression testing and resync activities.

It is clear from my experience and many other accounts that I read that this is not the case with this product that MFJ claims to support. IMHO, MFJ needs to spend serious time and effort to fix the many problems that our community has encountered. We can't expect Howard and others regardless of all of their great advice and effort to fix our problems, we need MFJ or some 3rd party that does software development for a living (I know this because I had to do this 3 times in my career and I was successful each time as the inside team could NOT get the JOB done).

Would someone please tell me if there have been any efforts to approach MFJ to get the shortcomings of this product addressed? With the right approach we should be able to pressure MFJ to make this engineering level RigPi into a solid bulletproof product (for which I would love to see as there is nothing that I could find at the time of my purchase of this product on the market).

BR/73: KJ7EHQ/Kevin

On 2020-06-22 07:02, James Cizek wrote:
OK, I just flat missed the line in the manual that says you have to
have a VOIP client installed on each device.
Got that. I downloaded, configured, installed Mumble on a PC to test.
Still no audio, so I think I still have an issue on the rigpi side.
Glenn, you mentioned 'aplay -i' What should I see from that output?
I am not if I am getting device busy because the mumble server is
attached to that sound device maybe?
Thanks.
James
KI0KN
On Sun, Jun 21, 2020 at 7:36 PM James Cizek via groups.io [1]
<james.m.cizek=gmail.com@groups.io> wrote:

hi Glenn,
Thanks for the help!
I am now able to connect and control both the FT891 and 991, but the
891 lag is so bad it's unusable. Anything you do in the webclient
takes 3 seconds to show up on the radio (ie, press PTT and 3 seconds
later the radio PTTs).
So I am throwing in the towel on the 891 for now. The 991 is
responding in a time manner that is appropriate.
However, still having the audio issues. aplay -i shows:
aplay:main:788: audio open error: Device or resource busy
I am using [sysdefault:CARD=sndiproto] snd_rpi_proto, Default Audio
Device in Mumble.
I am also a little confused on the client side. Do I need anything
running on the client to receive/transmit audio? I keep seeing
references to "plumble" for a mobile phone. Is there a client that
has to be installed on a PC? On a mobile device? If there is
documentation about this, I haven't found it yet.
Thank you!
James
KI0KN
On Fri, Jun 19, 2020 at 8:27 PM Glenn VE9GJ <ve9gj@...> wrote:

Hi James
I am sure you will get it figured out, just off to rough start.
Not sure why raspi-config won't change the screen resolution for
you,
are you using an hdmi monitor or VNC?
I think I misled you and the Yaseu needs to use the lower number
port.
It's been a long week.
On a terminal on rigpi (or ssh to the rig pi) try running hamlib
directly. Radio needs to be disconnected in the Tuner page.
run
rigctl -m 136 -r /dev/ttyUSB0
(if you need to add a baud rate it is ie: -s 38400)
this should return a Rig command: prompt
type f <enter> and it will return the frequency. It should be
almost
instant. If it is not we need to solve this first.
BTW ? will show you a list of commands, q is quit
In a terminal what does aplay -l show?
73
Glenn VE9GJ
On 2020-06-19 10:53 p.m., James Cizek wrote:
Hi Glenn,
No I do not believe the 891 has the built in sound card. It
doesn't matter
though, I can't get either one (the built in on the 991 nor the
audio board
on the rig pi for the 891) to pass any audio. I get "parameter
errors" in
Mumble using either one of them. Can't seem to find logs to
help me
troubleshoot what is really going on under the covers.
I have found the same as you though, typically the higher
numbered port on
Yaesu's is the one to use, but ironically, on the 891, it only
works with
the lower numbered one. I am not sure what else I have wrong,
it's so
laggy it's unusable. 3 or 4 seconds from pressing ptt in the
web client to
the actual radio keying, and 1 to 2 seconds to show a frequency
or mode
change. CPU on the pi is at 10%, so it's not that. I upped the
baud rate
on the CAT to 38400 on radio and software, not that either.
I figured maybe I "pushed too many buttons" so I purchased the
rigpi image
file from MFJ so I could start over from scratch. That image
boots fine,
but it's stuck in 640x480 mode. Using the resolution change in
raspi-config says it's succeeds, but upon reboot, drops right
back to
640x480. Everything on the screen is too large to use.
I'm an IT guy by trade, with a long history in Land mobile
radio, this
stuff should be a piece of cake, but I find that the lack of
identifying
log files that have any useful data in them is making my
challenge more
difficult :)
Thanks for your note.
73
James
KI0KN
Links:
------
[1] http://groups.io
[2] https://groups.io/g/RigPi/message/6197
[3] https://groups.io/mt/74989237/3544613
[4] https://groups.io/g/RigPi/post
[5] https://groups.io/g/RigPi/editsub/3544613
[6] https://groups.io/g/RigPi/leave/defanged


James Cizek
 

I followed the directions Howard posted here:

Specifically for the 991. I've changed all the menus in the 991 to route audio, and changed the default audio device, then updated Mumble.

I rebooted the RigPi and that seems to be a huge mistake.  I cannot connect to the radio anymore, at all.  I've rebooted the pi, rebooted radio, powered everything down completely.  Went back in to the menus on the 991 to double check I didn';t accidentally bump a CAT setting.  It won't connect.

I still get a /dev/USB0 and /dev/USB1 device added when I plug the USB in, so it's seeing the radio.  and FLRig still works fine to read and set the radio, so it's not radio or cable. 

Really frustrated.

aplay -l shows the 2 audio devices I'd expect, it shows the rpi sound board and usb codec of the FT991.  Everything returned is normal.

I assume that the mumble server would still pass audio even if rigtctl isn't working, is that right? If that is right, it's still not working.  I've changed the default audio (right click speaker) and selected the USB codec as default, and made sure default set in mumble in and out screens, apply and save. reboot.  I can successfully connect to the mumble server with a client (same lan, same switch so not a port issue)  No audio.

James
KI0KN



On Mon, Jun 22, 2020 at 10:25 AM Glenn VE9GJ <ve9gj@...> wrote:
Hi James
The command is aplay -l (lower case L)
It should list all the output sound devices that the pi thinks it has. arec -l should do the same for input audio.
You only need the USB cable for the 991 and it should appear as USB Codec I believe. On the pi desktop mumble set up what are your choices for audio in with 991 plugged in?
73
Glenn VE9GJ

On June 22, 2020 10:02:49 AM ADT, James Cizek <james.m.cizek@...> wrote:
OK, I just flat missed the line in the manual that says you have to have a VOIP client installed on each device.

Got that. I downloaded, configured, installed Mumble on a PC to test.  Still no audio, so I think I still have an issue on the rigpi side.

Glenn, you mentioned 'aplay -i'   What should I see from that output?  I am not if I am getting device busy because the mumble server is attached to that sound device maybe?  

Thanks.
James
KI0KN

On Sun, Jun 21, 2020 at 7:36 PM James Cizek via groups.io <james.m.cizek=gmail.com@groups.io> wrote:
hi Glenn,
Thanks for the help!

I am now able to connect and control both the FT891 and 991, but the 891 lag is so bad it's unusable.  Anything you do in the webclient takes 3 seconds to show up on the radio (ie, press PTT and 3 seconds later the radio PTTs).

So I am throwing in the towel on the 891 for now.  The 991 is responding in a time manner that is appropriate.

However, still having the audio issues.  aplay -i shows:  aplay:main:788: audio open error: Device or resource busy
I am using [sysdefault:CARD=sndiproto] snd_rpi_proto, Default Audio Device in Mumble.

I am also a little confused on the client side.  Do I need anything running on the client to receive/transmit audio?  I keep seeing references to "plumble" for a mobile phone.  Is there a client that has to be installed on a PC?  On a mobile device?  If there is documentation about this, I haven't found it yet. 

Thank you!  
James
KI0KN

On Fri, Jun 19, 2020 at 8:27 PM Glenn VE9GJ <ve9gj@...> wrote:
Hi James

I am sure you will get it figured out, just off to rough start.
Not sure why raspi-config won't change the screen resolution for you,
are you using an hdmi monitor or VNC?

I think I misled you and the Yaseu needs to use the lower number port.
It's been a long week.

On a terminal on rigpi (or ssh to the rig pi) try running hamlib
directly. Radio needs to be disconnected in the Tuner page.
run
rigctl -m 136 -r /dev/ttyUSB0
(if you need to add a baud rate it is ie: -s 38400)
this should return a Rig command: prompt
type f  <enter> and it will return the frequency. It should be almost
instant. If it is not we need to solve this first.
BTW ? will show you a list of commands, q is quit

In a terminal what does aplay -l show?
73
Glenn VE9GJ



On 2020-06-19 10:53 p.m., James Cizek wrote:
> Hi Glenn,
>
> No I do not believe the 891 has the built in sound card.  It doesn't matter
> though, I can't get either one (the built in on the 991 nor the audio board
> on the rig pi for the 891) to pass any audio.  I get "parameter errors" in
> Mumble using either one of them.  Can't seem to find logs to help me
> troubleshoot what is really going on under the covers.
>
> I have found the same as you though, typically the higher numbered port on
> Yaesu's is the one to use, but ironically, on the 891, it only works with
> the lower numbered one.  I am not sure what else I have wrong, it's so
> laggy it's unusable.  3 or 4 seconds from pressing ptt in the web client to
> the actual radio keying, and 1 to 2 seconds to show a frequency or mode
> change. CPU on the pi is at 10%, so it's not that.  I upped the baud rate
> on the CAT to 38400 on radio and software, not that either.
>
> I figured maybe I "pushed too many buttons" so I purchased the rigpi image
> file from MFJ so I could start over from scratch.  That image boots fine,
> but it's stuck in 640x480 mode.  Using the resolution change in
> raspi-config says it's succeeds, but upon reboot, drops right back to
> 640x480.  Everything on the screen is too large to use.
>
> I'm an IT guy by trade, with a long history in Land mobile radio, this
> stuff should be a piece of cake, but I find that the lack of identifying
> log files that have any useful data in them is making my challenge more
> difficult :)
>
> Thanks for your note.
> 73
> James
> KI0KN
>




James Cizek
 

OK, I have never seen this before on Linux, but it seems that the order in which USB device is enumerated changes from reboot to reboot.  I have rebooted several times and sometimes /dev/USB0 works, and sometimes /dev/USB1 works.  

I have re-gained control of the rig, but even though have no audio errors, still have no audio.

james

On Mon, Jun 22, 2020 at 11:09 AM James Cizek via groups.io <james.m.cizek=gmail.com@groups.io> wrote:
I followed the directions Howard posted here:

Specifically for the 991. I've changed all the menus in the 991 to route audio, and changed the default audio device, then updated Mumble.

I rebooted the RigPi and that seems to be a huge mistake.  I cannot connect to the radio anymore, at all.  I've rebooted the pi, rebooted radio, powered everything down completely.  Went back in to the menus on the 991 to double check I didn';t accidentally bump a CAT setting.  It won't connect.

I still get a /dev/USB0 and /dev/USB1 device added when I plug the USB in, so it's seeing the radio.  and FLRig still works fine to read and set the radio, so it's not radio or cable. 

Really frustrated.

aplay -l shows the 2 audio devices I'd expect, it shows the rpi sound board and usb codec of the FT991.  Everything returned is normal.

I assume that the mumble server would still pass audio even if rigtctl isn't working, is that right? If that is right, it's still not working.  I've changed the default audio (right click speaker) and selected the USB codec as default, and made sure default set in mumble in and out screens, apply and save. reboot.  I can successfully connect to the mumble server with a client (same lan, same switch so not a port issue)  No audio.

James
KI0KN



On Mon, Jun 22, 2020 at 10:25 AM Glenn VE9GJ <ve9gj@...> wrote:
Hi James
The command is aplay -l (lower case L)
It should list all the output sound devices that the pi thinks it has. arec -l should do the same for input audio.
You only need the USB cable for the 991 and it should appear as USB Codec I believe. On the pi desktop mumble set up what are your choices for audio in with 991 plugged in?
73
Glenn VE9GJ

On June 22, 2020 10:02:49 AM ADT, James Cizek <james.m.cizek@...> wrote:
OK, I just flat missed the line in the manual that says you have to have a VOIP client installed on each device.

Got that. I downloaded, configured, installed Mumble on a PC to test.  Still no audio, so I think I still have an issue on the rigpi side.

Glenn, you mentioned 'aplay -i'   What should I see from that output?  I am not if I am getting device busy because the mumble server is attached to that sound device maybe?  

Thanks.
James
KI0KN

On Sun, Jun 21, 2020 at 7:36 PM James Cizek via groups.io <james.m.cizek=gmail.com@groups.io> wrote:
hi Glenn,
Thanks for the help!

I am now able to connect and control both the FT891 and 991, but the 891 lag is so bad it's unusable.  Anything you do in the webclient takes 3 seconds to show up on the radio (ie, press PTT and 3 seconds later the radio PTTs).

So I am throwing in the towel on the 891 for now.  The 991 is responding in a time manner that is appropriate.

However, still having the audio issues.  aplay -i shows:  aplay:main:788: audio open error: Device or resource busy
I am using [sysdefault:CARD=sndiproto] snd_rpi_proto, Default Audio Device in Mumble.

I am also a little confused on the client side.  Do I need anything running on the client to receive/transmit audio?  I keep seeing references to "plumble" for a mobile phone.  Is there a client that has to be installed on a PC?  On a mobile device?  If there is documentation about this, I haven't found it yet. 

Thank you!  
James
KI0KN

On Fri, Jun 19, 2020 at 8:27 PM Glenn VE9GJ <ve9gj@...> wrote:
Hi James

I am sure you will get it figured out, just off to rough start.
Not sure why raspi-config won't change the screen resolution for you,
are you using an hdmi monitor or VNC?

I think I misled you and the Yaseu needs to use the lower number port.
It's been a long week.

On a terminal on rigpi (or ssh to the rig pi) try running hamlib
directly. Radio needs to be disconnected in the Tuner page.
run
rigctl -m 136 -r /dev/ttyUSB0
(if you need to add a baud rate it is ie: -s 38400)
this should return a Rig command: prompt
type f  <enter> and it will return the frequency. It should be almost
instant. If it is not we need to solve this first.
BTW ? will show you a list of commands, q is quit

In a terminal what does aplay -l show?
73
Glenn VE9GJ



On 2020-06-19 10:53 p.m., James Cizek wrote:
> Hi Glenn,
>
> No I do not believe the 891 has the built in sound card.  It doesn't matter
> though, I can't get either one (the built in on the 991 nor the audio board
> on the rig pi for the 891) to pass any audio.  I get "parameter errors" in
> Mumble using either one of them.  Can't seem to find logs to help me
> troubleshoot what is really going on under the covers.
>
> I have found the same as you though, typically the higher numbered port on
> Yaesu's is the one to use, but ironically, on the 891, it only works with
> the lower numbered one.  I am not sure what else I have wrong, it's so
> laggy it's unusable.  3 or 4 seconds from pressing ptt in the web client to
> the actual radio keying, and 1 to 2 seconds to show a frequency or mode
> change. CPU on the pi is at 10%, so it's not that.  I upped the baud rate
> on the CAT to 38400 on radio and software, not that either.
>
> I figured maybe I "pushed too many buttons" so I purchased the rigpi image
> file from MFJ so I could start over from scratch.  That image boots fine,
> but it's stuck in 640x480 mode.  Using the resolution change in
> raspi-config says it's succeeds, but upon reboot, drops right back to
> 640x480.  Everything on the screen is too large to use.
>
> I'm an IT guy by trade, with a long history in Land mobile radio, this
> stuff should be a piece of cake, but I find that the lack of identifying
> log files that have any useful data in them is making my challenge more
> difficult :)
>
> Thanks for your note.
> 73
> James
> KI0KN
>




James Cizek
 

I have tried using both the rigpi sound card as a source, and the USB audio directly as a source. I cannot seem to get any audio either direction still.

Once I connect my mumble client to the rigpi server, is there a way to verify (maybe a visual audio bar like the local audio generates) and see if there is anything coming across?  If I go to "information" in the mumble client, I see all the packets both "to" and "from" server are in the "good" column.  I see audio bandwidth at 72kbit/s currently and average latency is 1.07ms.   It seems like the VOIP connection is up, but audio is not passing either direction.

Sorry for the short and often posts here... trying to get this running before I leave town for field day on Wednesday.  Thank you all for your continued support.

James
KI0KN



On Mon, Jun 22, 2020 at 11:32 AM James Cizek via groups.io <james.m.cizek=gmail.com@groups.io> wrote:
OK, I have never seen this before on Linux, but it seems that the order in which USB device is enumerated changes from reboot to reboot.  I have rebooted several times and sometimes /dev/USB0 works, and sometimes /dev/USB1 works.  

I have re-gained control of the rig, but even though have no audio errors, still have no audio.

james

On Mon, Jun 22, 2020 at 11:09 AM James Cizek via groups.io <james.m.cizek=gmail.com@groups.io> wrote:
I followed the directions Howard posted here:

Specifically for the 991. I've changed all the menus in the 991 to route audio, and changed the default audio device, then updated Mumble.

I rebooted the RigPi and that seems to be a huge mistake.  I cannot connect to the radio anymore, at all.  I've rebooted the pi, rebooted radio, powered everything down completely.  Went back in to the menus on the 991 to double check I didn';t accidentally bump a CAT setting.  It won't connect.

I still get a /dev/USB0 and /dev/USB1 device added when I plug the USB in, so it's seeing the radio.  and FLRig still works fine to read and set the radio, so it's not radio or cable. 

Really frustrated.

aplay -l shows the 2 audio devices I'd expect, it shows the rpi sound board and usb codec of the FT991.  Everything returned is normal.

I assume that the mumble server would still pass audio even if rigtctl isn't working, is that right? If that is right, it's still not working.  I've changed the default audio (right click speaker) and selected the USB codec as default, and made sure default set in mumble in and out screens, apply and save. reboot.  I can successfully connect to the mumble server with a client (same lan, same switch so not a port issue)  No audio.

James
KI0KN



On Mon, Jun 22, 2020 at 10:25 AM Glenn VE9GJ <ve9gj@...> wrote:
Hi James
The command is aplay -l (lower case L)
It should list all the output sound devices that the pi thinks it has. arec -l should do the same for input audio.
You only need the USB cable for the 991 and it should appear as USB Codec I believe. On the pi desktop mumble set up what are your choices for audio in with 991 plugged in?
73
Glenn VE9GJ

On June 22, 2020 10:02:49 AM ADT, James Cizek <james.m.cizek@...> wrote:
OK, I just flat missed the line in the manual that says you have to have a VOIP client installed on each device.

Got that. I downloaded, configured, installed Mumble on a PC to test.  Still no audio, so I think I still have an issue on the rigpi side.

Glenn, you mentioned 'aplay -i'   What should I see from that output?  I am not if I am getting device busy because the mumble server is attached to that sound device maybe?  

Thanks.
James
KI0KN

On Sun, Jun 21, 2020 at 7:36 PM James Cizek via groups.io <james.m.cizek=gmail.com@groups.io> wrote:
hi Glenn,
Thanks for the help!

I am now able to connect and control both the FT891 and 991, but the 891 lag is so bad it's unusable.  Anything you do in the webclient takes 3 seconds to show up on the radio (ie, press PTT and 3 seconds later the radio PTTs).

So I am throwing in the towel on the 891 for now.  The 991 is responding in a time manner that is appropriate.

However, still having the audio issues.  aplay -i shows:  aplay:main:788: audio open error: Device or resource busy
I am using [sysdefault:CARD=sndiproto] snd_rpi_proto, Default Audio Device in Mumble.

I am also a little confused on the client side.  Do I need anything running on the client to receive/transmit audio?  I keep seeing references to "plumble" for a mobile phone.  Is there a client that has to be installed on a PC?  On a mobile device?  If there is documentation about this, I haven't found it yet. 

Thank you!  
James
KI0KN

On Fri, Jun 19, 2020 at 8:27 PM Glenn VE9GJ <ve9gj@...> wrote:
Hi James

I am sure you will get it figured out, just off to rough start.
Not sure why raspi-config won't change the screen resolution for you,
are you using an hdmi monitor or VNC?

I think I misled you and the Yaseu needs to use the lower number port.
It's been a long week.

On a terminal on rigpi (or ssh to the rig pi) try running hamlib
directly. Radio needs to be disconnected in the Tuner page.
run
rigctl -m 136 -r /dev/ttyUSB0
(if you need to add a baud rate it is ie: -s 38400)
this should return a Rig command: prompt
type f  <enter> and it will return the frequency. It should be almost
instant. If it is not we need to solve this first.
BTW ? will show you a list of commands, q is quit

In a terminal what does aplay -l show?
73
Glenn VE9GJ



On 2020-06-19 10:53 p.m., James Cizek wrote:
> Hi Glenn,
>
> No I do not believe the 891 has the built in sound card.  It doesn't matter
> though, I can't get either one (the built in on the 991 nor the audio board
> on the rig pi for the 891) to pass any audio.  I get "parameter errors" in
> Mumble using either one of them.  Can't seem to find logs to help me
> troubleshoot what is really going on under the covers.
>
> I have found the same as you though, typically the higher numbered port on
> Yaesu's is the one to use, but ironically, on the 891, it only works with
> the lower numbered one.  I am not sure what else I have wrong, it's so
> laggy it's unusable.  3 or 4 seconds from pressing ptt in the web client to
> the actual radio keying, and 1 to 2 seconds to show a frequency or mode
> change. CPU on the pi is at 10%, so it's not that.  I upped the baud rate
> on the CAT to 38400 on radio and software, not that either.
>
> I figured maybe I "pushed too many buttons" so I purchased the rigpi image
> file from MFJ so I could start over from scratch.  That image boots fine,
> but it's stuck in 640x480 mode.  Using the resolution change in
> raspi-config says it's succeeds, but upon reboot, drops right back to
> 640x480.  Everything on the screen is too large to use.
>
> I'm an IT guy by trade, with a long history in Land mobile radio, this
> stuff should be a piece of cake, but I find that the lack of identifying
> log files that have any useful data in them is making my challenge more
> difficult :)
>
> Thanks for your note.
> 73
> James
> KI0KN
>




Glenn VE9GJ
 

Hi James

I hadn't really noticed linux flipping the ttyUSB#s on reboot for the same hub device but it certainly is possible. I have custom udev rules so they always come up the same.
On the RigPi Desktop if you click the Settings Gear In Mumble then
Audio Input, set the System to Alsa, what are your choices in the Device drop down?
Do you see [HW Card =???,DEV=0]USB Audio Codec ...... ?
There should be quite a few different choices.

Glenn VE9GJ

On 2020-06-22 15:28, James Cizek wrote:
I have tried using both the rigpi sound card as a source, and the USB
audio directly as a source. I cannot seem to get any audio either
direction still.
Once I connect my mumble client to the rigpi server, is there a way to
verify (maybe a visual audio bar like the local audio generates) and
see if there is anything coming across? If I go to "information" in
the mumble client, I see all the packets both "to" and "from" server
are in the "good" column. I see audio bandwidth at 72kbit/s currently
and average latency is 1.07ms. It seems like the VOIP connection is
up, but audio is not passing either direction.
Sorry for the short and often posts here... trying to get this running
before I leave town for field day on Wednesday. Thank you all for
your continued support.
James
KI0KN


James Cizek
 

There are 17 choices in that menu.  

They are all variants of either the "USB Codec" or "snd_rpi_proto"



On Mon, Jun 22, 2020 at 1:08 PM Glenn VE9GJ <ve9gj@...> wrote:
Hi James

I hadn't really noticed linux flipping the ttyUSB#s on reboot for the
same hub device but it certainly is possible.  I have custom udev rules
so they always come up the same.
On the RigPi Desktop if you click the Settings Gear In Mumble then
Audio Input, set the System to Alsa, what are your choices in the Device
drop down?
Do you see [HW Card =???,DEV=0]USB Audio Codec ...... ?
There should be quite a few different choices.

Glenn VE9GJ

On 2020-06-22 15:28, James Cizek wrote:
> I have tried using both the rigpi sound card as a source, and the USB
> audio directly as a source. I cannot seem to get any audio either
> direction still.
>
> Once I connect my mumble client to the rigpi server, is there a way to
> verify (maybe a visual audio bar like the local audio generates) and
> see if there is anything coming across?  If I go to "information" in
> the mumble client, I see all the packets both "to" and "from" server
> are in the "good" column.  I see audio bandwidth at 72kbit/s currently
> and average latency is 1.07ms.   It seems like the VOIP connection is
> up, but audio is not passing either direction.
>
> Sorry for the short and often posts here... trying to get this running
> before I leave town for field day on Wednesday.  Thank you all for
> your continued support.
>
> James
> KI0KN
>
>




Glenn VE9GJ
 

use the one that starts with
hw:CARD=CODEC,DEV=0
for both input and output.
Then click apply, OK and then close Mumble completely and reopen.
If it does not auto connect in Mumble do Server, Connect then RigPi VOIP Server. If it asks for a user name use pi. If it asks anything about a certificate be sure to accept it. If all is good you should see user pi connected in the Rigpi Client with red lips. All of the above was on the RigPi desktop.

Now with your Windows mumble client connect to your rigpi voip server but make sure you use a different user such as Windows. Same goes for certificate ans if prompted for a password use 7388. You should see both pi and you new windows users in mumble now and both user should have red lips.

73
Glenn VE9GJ

On 2020-06-22 5:42 p.m., James Cizek wrote:
There are 17 choices in that menu.
They are all variants of either the "USB Codec" or "snd_rpi_proto"
On Mon, Jun 22, 2020 at 1:08 PM Glenn VE9GJ <ve9gj@...> wrote:

Hi James

I hadn't really noticed linux flipping the ttyUSB#s on reboot for the
same hub device but it certainly is possible. I have custom udev rules
so they always come up the same.
On the RigPi Desktop if you click the Settings Gear In Mumble then
Audio Input, set the System to Alsa, what are your choices in the Device
drop down?
Do you see [HW Card =???,DEV=0]USB Audio Codec ...... ?
There should be quite a few different choices.

Glenn VE9GJ

On 2020-06-22 15:28, James Cizek wrote:
I have tried using both the rigpi sound card as a source, and the USB
audio directly as a source. I cannot seem to get any audio either
direction still.

Once I connect my mumble client to the rigpi server, is there a way to
verify (maybe a visual audio bar like the local audio generates) and
see if there is anything coming across? If I go to "information" in
the mumble client, I see all the packets both "to" and "from" server
are in the "good" column. I see audio bandwidth at 72kbit/s currently
and average latency is 1.07ms. It seems like the VOIP connection is
up, but audio is not passing either direction.

Sorry for the short and often posts here... trying to get this running
before I leave town for field day on Wednesday. Thank you all for
your continued support.

James
KI0KN




James Cizek
 

Able to do all that successfully, but the lips do not turn red.

I see on both the pi desktop, and my remote client that both pi and ki0kn are logged in and "connected".  Lips are not red, and no audio.

I have rebooted everything and tried again. Same result.

On Mon, Jun 22, 2020 at 3:02 PM Glenn VE9GJ <ve9gj@...> wrote:
use the one that starts with
hw:CARD=CODEC,DEV=0
for both input and output.
Then click apply, OK and then close Mumble completely and reopen.
If it does not auto connect in Mumble do Server, Connect then RigPi VOIP
Server.  If it asks for a user name use pi.  If it asks anything about a
certificate be sure to accept it.  If all is good you should see user pi
connected in the Rigpi Client with red lips.  All of the above was on
the RigPi desktop.

Now with your Windows mumble client connect to your rigpi voip server
but make sure you use a different user such as Windows.  Same goes for
certificate ans if prompted for a password use 7388.  You should see
both pi and you new windows users in mumble now and both user should
have red lips.

73
Glenn VE9GJ


On 2020-06-22 5:42 p.m., James Cizek wrote:
> There are 17 choices in that menu.
>
> They are all variants of either the "USB Codec" or "snd_rpi_proto"
>
>
>
> On Mon, Jun 22, 2020 at 1:08 PM Glenn VE9GJ <ve9gj@...> wrote:
>
>> Hi James
>>
>> I hadn't really noticed linux flipping the ttyUSB#s on reboot for the
>> same hub device but it certainly is possible.  I have custom udev rules
>> so they always come up the same.
>> On the RigPi Desktop if you click the Settings Gear In Mumble then
>> Audio Input, set the System to Alsa, what are your choices in the Device
>> drop down?
>> Do you see [HW Card =???,DEV=0]USB Audio Codec ...... ?
>> There should be quite a few different choices.
>>
>> Glenn VE9GJ
>>
>> On 2020-06-22 15:28, James Cizek wrote:
>>> I have tried using both the rigpi sound card as a source, and the USB
>>> audio directly as a source. I cannot seem to get any audio either
>>> direction still.
>>>
>>> Once I connect my mumble client to the rigpi server, is there a way to
>>> verify (maybe a visual audio bar like the local audio generates) and
>>> see if there is anything coming across?  If I go to "information" in
>>> the mumble client, I see all the packets both "to" and "from" server
>>> are in the "good" column.  I see audio bandwidth at 72kbit/s currently
>>> and average latency is 1.07ms.   It seems like the VOIP connection is
>>> up, but audio is not passing either direction.
>>>
>>> Sorry for the short and often posts here... trying to get this running
>>> before I leave town for field day on Wednesday.  Thank you all for
>>> your continued support.
>>>
>>> James
>>> KI0KN
>>>
>>>
>>
>>
>>
>>
>
>
>
>





James Cizek
 

OK, I got everything to save now.  For some reason, the change didn't "stick" even though I hit apply, then ok.  

I have now rebooted, and it comes up (autostart) clean, with pi logged in and red lips.  I am logged in as ki0kn from my remote computer also and it says I am connected.
ki0kn shows up on the rigpi desktop top, but now IT doesn't have red lips!  My mumble client says it's connected and I can see that pi is also logged in, but on the rigpi desktop ki0kn still has gray lips.

On Mon, Jun 22, 2020 at 3:39 PM James Cizek via groups.io <james.m.cizek=gmail.com@groups.io> wrote:
Able to do all that successfully, but the lips do not turn red.

I see on both the pi desktop, and my remote client that both pi and ki0kn are logged in and "connected".  Lips are not red, and no audio.

I have rebooted everything and tried again. Same result.

On Mon, Jun 22, 2020 at 3:02 PM Glenn VE9GJ <ve9gj@...> wrote:
use the one that starts with
hw:CARD=CODEC,DEV=0
for both input and output.
Then click apply, OK and then close Mumble completely and reopen.
If it does not auto connect in Mumble do Server, Connect then RigPi VOIP
Server.  If it asks for a user name use pi.  If it asks anything about a
certificate be sure to accept it.  If all is good you should see user pi
connected in the Rigpi Client with red lips.  All of the above was on
the RigPi desktop.

Now with your Windows mumble client connect to your rigpi voip server
but make sure you use a different user such as Windows.  Same goes for
certificate ans if prompted for a password use 7388.  You should see
both pi and you new windows users in mumble now and both user should
have red lips.

73
Glenn VE9GJ


On 2020-06-22 5:42 p.m., James Cizek wrote:
> There are 17 choices in that menu.
>
> They are all variants of either the "USB Codec" or "snd_rpi_proto"
>
>
>
> On Mon, Jun 22, 2020 at 1:08 PM Glenn VE9GJ <ve9gj@...> wrote:
>
>> Hi James
>>
>> I hadn't really noticed linux flipping the ttyUSB#s on reboot for the
>> same hub device but it certainly is possible.  I have custom udev rules
>> so they always come up the same.
>> On the RigPi Desktop if you click the Settings Gear In Mumble then
>> Audio Input, set the System to Alsa, what are your choices in the Device
>> drop down?
>> Do you see [HW Card =???,DEV=0]USB Audio Codec ...... ?
>> There should be quite a few different choices.
>>
>> Glenn VE9GJ
>>
>> On 2020-06-22 15:28, James Cizek wrote:
>>> I have tried using both the rigpi sound card as a source, and the USB
>>> audio directly as a source. I cannot seem to get any audio either
>>> direction still.
>>>
>>> Once I connect my mumble client to the rigpi server, is there a way to
>>> verify (maybe a visual audio bar like the local audio generates) and
>>> see if there is anything coming across?  If I go to "information" in
>>> the mumble client, I see all the packets both "to" and "from" server
>>> are in the "good" column.  I see audio bandwidth at 72kbit/s currently
>>> and average latency is 1.07ms.   It seems like the VOIP connection is
>>> up, but audio is not passing either direction.
>>>
>>> Sorry for the short and often posts here... trying to get this running
>>> before I leave town for field day on Wednesday.  Thank you all for
>>> your continued support.
>>>
>>> James
>>> KI0KN
>>>
>>>
>>
>>
>>
>>
>
>
>
>