Topics

QSSTV on Pi3B+ and ICOM 7200


Alan
 

Has anyone been able to get QSSTV on the Pi3B+ to transmit via the USB cable to the ICOM 7200? I have all the same Hamlib and USB Codec settings as with WSJT-X, FLDIGI, JS8 on the Pi-star and they work fine, but not QSSTV. It’ll receive images OK, but not transmit. I’ve tried changing settings, but nothing works. I’ve tried it on both Stretch and Buster. Thanks, Alan, K2RHK


David Ranch
 


I've used Qsstv quite a bit on X86 systems so the Rpi shouldn't be very different.  Did you compile Qsstv yourself or are you running it via a pre-built package?  If pre-built, which version is it?   For the programs that you have working, what are you setting for PTT control?  I assume you're doing the exact same setting for Qsstv?

   http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html#28c.qsstv-config
   --
   CAT and PTT (Qsstv 9.x):

          This section is a bit confusing.  The use of Hamlib within Qsstv is ONLY
          to key up the radio (PTT) and nothing more.  There isn't any VFO control,
          filter control, etc.  In addition to that, you can only configure *either*
          CAT services to key up the rig *or* enable the "special serial port" to
          key up the rig.   If you try to enable both, and click on ok, you'll get a
          non-helpful error.
   --


--David
KI6ZHD


On 04/28/2020 03:38 PM, Alan wrote:
Has anyone been able to get QSSTV on the Pi3B+ to transmit via the USB cable to the ICOM 7200? I have all the same Hamlib and USB Codec settings as with WSJT-X, FLDIGI, JS8 on the Pi-star and they work fine, but not QSSTV. It’ll receive images OK, but not transmit. I’ve tried changing settings, but nothing works. I’ve tried it on both Stretch and Buster. Thanks, Alan, K2RHK





Alan
 

Thanks, David. I’m using QSSTV 9.2.6 loaded from the Stretch applications content. I’ve followed your suggestion and very carefully duplicated the rig control settings of my other Pi applications. With a lot of fiddling it does transmit now. At first power out was only about 5 watts, but by driving the OS to maximum audio it’s now outputting about 30 watts. I don’t think there’s a way to get more audio drive from the Pi using alsa and usb codec for interface, so I’d better be satisfied with getting this far. I got no results using pulse audio. Now it’s a matter of setting up a few templates and graphics. Meanwhile, I’d better check to see what effect the change in audio output has had on my other applications. I really appreciate your replying to my post. I was about to give it up.
Alan, K2RHK


Alan
 

My results so far on getting QSSTV to work on the Pi3B+: it receives images fine. It now controls the 7200 through USB to transmit images. But even driving the Pi (Stretch) to maximum audio I can only get QSSTV to transmit at about 25 Watts. I’ve added a few SSTV images from my MMSSTV file on Windows so I can transmit a CQ Image but at 25W even though it seems to be transmitting ok its not showing up on any of the received image sites. I wonder if anyone has worked out how to drive the program at higher levels from the Pi.
Thanks, Alan, K2RHK


David Ranch
 


Hello Alan,

Thanks, David. I’m using QSSTV 9.2.6 loaded from the Stretch applications content. 

Hmmm.. that's quite old (august 2017).  The current version is 9.4.4 and it's been out since Aug 2019. 


With a lot of fiddling it does transmit now. 

Good deal.


At first power out was only about 5 watts, but by driving the OS to maximum audio it’s now outputting about 30 watts. I don’t think there’s a way to get more audio drive from the Pi using alsa and usb codec for interface, so I’d better be satisfied with getting this far. 

Well.. audio settings are both on the sound card but ALSO on the radio.  Look for OUTPUT gain settings on your radio and be certain to monitor your radio's ALC levels when transmitting.  If they are anything more than say 10% of max, you're just sending a trash signal that won't be decodable.  If that only turns out to be 30W, then 30W it is.  Sending 50w of trash won't help you.  :-)


I got no results using pulse audio. Now it’s a matter of setting up a few templates and graphics. 

I haven't tried PulseAudio on a Pi in a while and maybe it's better now with the Rpi4 and it's new USB chipset.  It used to be a real issue a few years ago and everyone recommended to remove it and stick with say ALSA or maybe PortAudio.


Meanwhile, I’d better check to see what effect the change in audio output has had on my other applications. I really appreciate your replying to my post. I was about to give it up. 

So what was your fix?  Maybe it will help others searching the archives here.

--David
KI6ZHD


David Ranch
 


Hello Alan,

 at 25W even though it seems to be transmitting ok its not showing up on any of the received image sites. I wonder if anyone has worked out how to drive the program at higher levels from the Pi. 

Oh.. there are so many factors here!  Where is your transmitter?  What kind of antenna do you have?  What is the propagation like on your chosen frequency when you were transmitting?  Where is the receiver?  What kind of antenna do they have?  etc etc etc. (don't answer those questions as they are rhetorical)   I've also found that many SSTV image capture websites don't work.   You should ignore them and just get signal reports from fellow SSTV people on frequency.  That's the real test.

--David
KI6ZHD


Alan
 

I didn’t go into the 7200 audio output gain settings because ALC level was already about right and I didn’t want to push it further. Tomorrow I’ll see how much more gain it’ll take and still have comfortable ALC readings. Also, I’ll post my rig control settings in case anyone with this setup is having similar problems.

This QTH is a small island in the Atlantic and surrounded by salt water (we’re hiding out from New York City) so has pretty good transmission characteristics. I usually run about 40 watts on the digital modes which does fine. SSTV is the exception and there I run 100 watts with MMSSTV.

Also, I’ll get started upgrading to V. 9.4.4 and also set up some more transmitting graphics and templates.

Thanks again for all your help with this.

Alan, K2RHK


Alan
 

Well, even at 30 watts, QSSTV on my Pi3B+ is working with my 7200 via the USB interface and I had a brief QSO on 14.230 today. Using V. 9.2.6 The default settings in Hamlib For the 7200 are slightly wrong. Here are mine:

Sound, Alsa, usb codec, usb audio
Hamlib, the default serial port is wrong. It should be, /dev/ttyUSB0
PTT, CAT voice port
Parity, none
Baudrate, should be 19200
Databits, 8
Stopbits, should be 2
Handshake, none
CIV, blank

I have Processor speed set to low because I’m using a Pi3B+. With a Pi 4 that may change. Processor usage is around 55% and temp at about 73C. The app occasionally shuts down. This may also change with a Pi 4.

If anyone has questions, let me know and I’ll try to answer them. Now, to start the version upgrade...!


David Ranch
 


Hello Alan,


I didn’t go into the 7200 audio output gain settings because ALC level was already about right and I didn’t want to push it further. Tomorrow I’ll see how much more gain it’ll take and still have comfortable ALC readings. Also, I’ll post my rig control settings in case anyone with this setup is having similar problems. 

Btw, I don't know what sound card you are using but different devices have different mixer settings.  Some of them have features like a "+20db booster" which you can enable and it instantly increases lower output.  Look in the Linux mixer tool to see if that's there or not.  If your audio level is too low and this feature is there, give it a try.


This QTH is a small island in the Atlantic and surrounded by salt water (we’re hiding out from New York City) so has pretty good transmission characteristics. I usually run about 40 watts on the digital modes which does fine. SSTV is the exception and there I run 100 watts with MMSSTV.

Right.. HamDRM should be considered a full duty cycle mode so unless your radio's are rated for 100% full duty cycle at full power, cut your power by at least 50%.  For analog SSTV, those duty cycles are lower but are still higher than say SSB.  I personally would recommend to NOT run your rig at 100% output.  Instead, pull the power back and use an amplifier running no higher than 50% of max rated output unless it too is rated for 100% duty cycle.

--David
KI6ZHD


David Ranch
 


Hello Alan

Sound, Alsa, usb codec, usb audio
Hamlib, the default serial port is wrong. It should be, /dev/ttyUSB0
Consider using predictable serial port naming.  For example on my machine, I see:
--
$ ls -la /dev/serial/by-id/
total 0
drwxr-xr-x 2 root root 180 Apr 26 11:36 .
drwxr-xr-x 4 root root  80 Apr 26 04:36 ..
lrwxrwxrwx 1 root root  13 Apr 26 11:36 usb-FTDI_Navigator__CAT___2nd_PTT__00000000-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root  13 Apr 26 11:36 usb-FTDI_Navigator__CAT___2nd_PTT__00000000-if01-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root  13 Apr 26 11:36 usb-FTDI_Navigator__RS232___Config__00000002-if00-port0 -> ../../ttyUSB4
lrwxrwxrwx 1 root root  13 Apr 26 11:36 usb-FTDI_Navigator__RS232___Config__00000002-if01-port0 -> ../../ttyUSB5
lrwxrwxrwx 1 root root  13 Apr 26 11:36 usb-FTDI_Navigator__WKey___FSK__00000001-if00-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root  13 Apr 26 11:36 usb-FTDI_Navigator__WKey___FSK__00000001-if01-port0 -> ../../ttyUSB3
lrwxrwxrwx 1 root root  13 Apr 26 11:36 usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 -> ../../ttyUSB6
--

Using those long names like /dev/serial/by-id/usb-FTDI_Navigator__CAT___2nd_PTT__00000000-if01-port0 will NEVER change and always work across reboots, etc.


Parity, none
Baudrate, should be 19200
Databits, 8
Stopbits, should be 2
Handshake, none
CIV, blank

Instead of using CIV, an you use a CAT port instead?  If so, CAT control usually supports much faster serial speeds that will dramatically lower your rig control latency, etc.  A much nicer experience for sure.


I have Processor speed set to low because I’m using a Pi3B+. With a Pi 4 that may change. Processor usage is around 55% and temp at about 73C. The app occasionally shuts down. This may also change with a Pi 4. 

The application should never crash.  Run Qsstv from the command line and if it ever crashes, it should print out errors in the terminal window.  Paste those in this email thread and hopefully someone can help here.  If not, you can report them to the author of Qsstv directly.  ON4QZ has always been very helpful and responsive when there are real issues.

--David
KI6ZHD


Mark Griffith
 

Hmmm,  /dev/serial doesn't exist on Raspbian Buster.  Raspbian has been notorious for not being able to map a device consistently to the same port.  Are you using a different OS?

Mark
KD0QYN


On Thursday, April 30, 2020, 1:38:59 PM CDT, David Ranch <rpi4hamradio-groupsio@...> wrote:



Hello Alan

Sound, Alsa, usb codec, usb audio
Hamlib, the default serial port is wrong. It should be, /dev/ttyUSB0
Consider using predictable serial port naming.  For example on my machine, I see:
--
$ ls -la /dev/serial/by-id/
total 0
drwxr-xr-x 2 root root 180 Apr 26 11:36 .
drwxr-xr-x 4 root root  80 Apr 26 04:36 ..
lrwxrwxrwx 1 root root  13 Apr 26 11:36 usb-FTDI_Navigator__CAT___2nd_PTT__00000000-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root  13 Apr 26 11:36 usb-FTDI_Navigator__CAT___2nd_PTT__00000000-if01-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root  13 Apr 26 11:36 usb-FTDI_Navigator__RS232___Config__00000002-if00-port0 -> ../../ttyUSB4
lrwxrwxrwx 1 root root  13 Apr 26 11:36 usb-FTDI_Navigator__RS232___Config__00000002-if01-port0 -> ../../ttyUSB5
lrwxrwxrwx 1 root root  13 Apr 26 11:36 usb-FTDI_Navigator__WKey___FSK__00000001-if00-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root  13 Apr 26 11:36 usb-FTDI_Navigator__WKey___FSK__00000001-if01-port0 -> ../../ttyUSB3
lrwxrwxrwx 1 root root  13 Apr 26 11:36 usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 -> ../../ttyUSB6
--

Using those long names like /dev/serial/by-id/usb-FTDI_Navigator__CAT___2nd_PTT__00000000-if01-port0 will NEVER change and always work across reboots, etc.


Parity, none
Baudrate, should be 19200
Databits, 8
Stopbits, should be 2
Handshake, none
CIV, blank

Instead of using CIV, an you use a CAT port instead?  If so, CAT control usually supports much faster serial speeds that will dramatically lower your rig control latency, etc.  A much nicer experience for sure.


I have Processor speed set to low because I’m using a Pi3B+. With a Pi 4 that may change. Processor usage is around 55% and temp at about 73C. The app occasionally shuts down. This may also change with a Pi 4. 

The application should never crash.  Run Qsstv from the command line and if it ever crashes, it should print out errors in the terminal window.  Paste those in this email thread and hopefully someone can help here.  If not, you can report them to the author of Qsstv directly.  ON4QZ has always been very helpful and responsive when there are real issues.

--David
KI6ZHD


Chuck M
 

Tossing out that the "ls -la dev/serial/by-id" works on my Pi 4B running Buster.  Correctly identified serial port used with my rig.

73s,
Chuck
KD9DVB



On Thu, Apr 30, 2020 at 3:45 PM, Mark Griffith via groups.io
<mdgriffith2003@...> wrote:
Hmmm,  /dev/serial doesn't exist on Raspbian Buster.  Raspbian has been notorious for not being able to map a device consistently to the same port.  Are you using a different OS?

Mark
KD0QYN


On Thursday, April 30, 2020, 1:38:59 PM CDT, David Ranch <rpi4hamradio-groupsio@...> wrote:



Hello Alan

Sound, Alsa, usb codec, usb audio
Hamlib, the default serial port is wrong. It should be, /dev/ttyUSB0
Consider using predictable serial port naming.  For example on my machine, I see:
--
$ ls -la /dev/serial/by-id/
total 0
drwxr-xr-x 2 root root 180 Apr 26 11:36 .
drwxr-xr-x 4 root root  80 Apr 26 04:36 ..
lrwxrwxrwx 1 root root  13 Apr 26 11:36 usb-FTDI_Navigator__CAT___2nd_PTT__00000000-if00-port0 -> ../../ttyUSB0
lrwxrwxrwx 1 root root  13 Apr 26 11:36 usb-FTDI_Navigator__CAT___2nd_PTT__00000000-if01-port0 -> ../../ttyUSB1
lrwxrwxrwx 1 root root  13 Apr 26 11:36 usb-FTDI_Navigator__RS232___Config__00000002-if00-port0 -> ../../ttyUSB4
lrwxrwxrwx 1 root root  13 Apr 26 11:36 usb-FTDI_Navigator__RS232___Config__00000002-if01-port0 -> ../../ttyUSB5
lrwxrwxrwx 1 root root  13 Apr 26 11:36 usb-FTDI_Navigator__WKey___FSK__00000001-if00-port0 -> ../../ttyUSB2
lrwxrwxrwx 1 root root  13 Apr 26 11:36 usb-FTDI_Navigator__WKey___FSK__00000001-if01-port0 -> ../../ttyUSB3
lrwxrwxrwx 1 root root  13 Apr 26 11:36 usb-Prolific_Technology_Inc._USB-Serial_Controller-if00-port0 -> ../../ttyUSB6
--

Using those long names like /dev/serial/by-id/usb-FTDI_Navigator__CAT___2nd_PTT__00000000-if01-port0 will NEVER change and always work across reboots, etc.


Parity, none
Baudrate, should be 19200
Databits, 8
Stopbits, should be 2
Handshake, none
CIV, blank

Instead of using CIV, an you use a CAT port instead?  If so, CAT control usually supports much faster serial speeds that will dramatically lower your rig control latency, etc.  A much nicer experience for sure.


I have Processor speed set to low because I’m using a Pi3B+. With a Pi 4 that may change. Processor usage is around 55% and temp at about 73C. The app occasionally shuts down. This may also change with a Pi 4. 

The application should never crash.  Run Qsstv from the command line and if it ever crashes, it should print out errors in the terminal window.  Paste those in this email thread and hopefully someone can help here.  If not, you can report them to the author of Qsstv directly.  ON4QZ has always been very helpful and responsive when there are real issues.

--David
KI6ZHD


David Ranch
 


Predictable serial ports is  also there in Raspbian Stretch.  If you don't want to do it that way, you can do it via Udev tricks:

   http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html#1d.presetup-udevusbserial

--David
KI6ZHD


On 04/30/2020 01:20 PM, Chuck M via groups.io wrote:
Tossing out that the "ls -la dev/serial/by-id" works on my Pi 4B running Buster.  Correctly identified serial port used with my rig.

73s,
Chuck
KD9DVB



On Thu, Apr 30, 2020 at 3:45 PM, Mark Griffith via groups.io
Hmmm,  /dev/serial doesn't exist on Raspbian Buster.  Raspbian has been notorious for not being able to map a device consistently to the same port.  Are you using a different OS?

Mark
KD0QYN


Alan
 

Hi Mark, I’m using Stretch. I have a Buster card set up but no Pi4 yet. I’ll try it with Buster and the 3B+ tonight. Thanks, Alan


Alan
 

Hi David, Decreasing the window size helped lower the usage and temp. I had been at full 24-inches while configuring. It seems not to be crashing now but still early to tell. Alan


Mark Griffith
 

Again, hmmmmm.  I have a new distribution of Raspbian Buster and just did a dist-upgrade a few days ago, so this should be the newest available, and no /dev/serial.   You sure you have not installed an add-on package?

Perhaps it only shows up if you have more than one serial device plugged in.

Mark
KD0QYN


On Thursday, April 30, 2020, 4:01:26 PM CDT, David Ranch <rpi4hamradio-groupsio@...> wrote:



Predictable serial ports is  also there in Raspbian Stretch.  If you don't want to do it that way, you can do it via Udev tricks:

   http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html#1d.presetup-udevusbserial

--David
KI6ZHD


On 04/30/2020 01:20 PM, Chuck M via groups.io wrote:
Tossing out that the "ls -la dev/serial/by-id" works on my Pi 4B running Buster.  Correctly identified serial port used with my rig.

73s,
Chuck
KD9DVB



On Thu, Apr 30, 2020 at 3:45 PM, Mark Griffith via groups.io
Hmmm,  /dev/serial doesn't exist on Raspbian Buster.  Raspbian has been notorious for not being able to map a device consistently to the same port.  Are you using a different OS?

Mark
KD0QYN


Chuck M
 

What I've also done is to use dmesg command, then copy and paste the whole mess into text editor.  Then search for "tty" to find USB device assigned to radio.

Clunky but it works.

73s
Chuck
KD9DVB


On Thu, Apr 30, 2020 at 7:12 PM, Mark Griffith via groups.io
<mdgriffith2003@...> wrote:
Again, hmmmmm.  I have a new distribution of Raspbian Buster and just did a dist-upgrade a few days ago, so this should be the newest available, and no /dev/serial.   You sure you have not installed an add-on package?

Perhaps it only shows up if you have more than one serial device plugged in.

Mark
KD0QYN


On Thursday, April 30, 2020, 4:01:26 PM CDT, David Ranch <rpi4hamradio-groupsio@...> wrote:



Predictable serial ports is  also there in Raspbian Stretch.  If you don't want to do it that way, you can do it via Udev tricks:

   http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html#1d.presetup-udevusbserial

--David
KI6ZHD


On 04/30/2020 01:20 PM, Chuck M via groups.io wrote:
Tossing out that the "ls -la dev/serial/by-id" works on my Pi 4B running Buster.  Correctly identified serial port used with my rig.

73s,
Chuck
KD9DVB



On Thu, Apr 30, 2020 at 3:45 PM, Mark Griffith via groups.io
Hmmm,  /dev/serial doesn't exist on Raspbian Buster.  Raspbian has been notorious for not being able to map a device consistently to the same port.  Are you using a different OS?

Mark
KD0QYN


Mark Griffith
 

dmesg | grep tty

That would work much better.

Mark
KD0QYN


On Thursday, April 30, 2020, 6:43:03 PM CDT, Chuck M via groups.io <cam51mail@...> wrote:


What I've also done is to use dmesg command, then copy and paste the whole mess into text editor.  Then search for "tty" to find USB device assigned to radio.

Clunky but it works.

73s
Chuck
KD9DVB


On Thu, Apr 30, 2020 at 7:12 PM, Mark Griffith via groups.io
<mdgriffith2003@...> wrote:
Again, hmmmmm.  I have a new distribution of Raspbian Buster and just did a dist-upgrade a few days ago, so this should be the newest available, and no /dev/serial.   You sure you have not installed an add-on package?

Perhaps it only shows up if you have more than one serial device plugged in.

Mark
KD0QYN


On Thursday, April 30, 2020, 4:01:26 PM CDT, David Ranch <rpi4hamradio-groupsio@...> wrote:



Predictable serial ports is  also there in Raspbian Stretch.  If you don't want to do it that way, you can do it via Udev tricks:

   http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html#1d.presetup-udevusbserial

--David
KI6ZHD


On 04/30/2020 01:20 PM, Chuck M via groups.io wrote:
Tossing out that the "ls -la dev/serial/by-id" works on my Pi 4B running Buster.  Correctly identified serial port used with my rig.

73s,
Chuck
KD9DVB



On Thu, Apr 30, 2020 at 3:45 PM, Mark Griffith via groups.io
Hmmm,  /dev/serial doesn't exist on Raspbian Buster.  Raspbian has been notorious for not being able to map a device consistently to the same port.  Are you using a different OS?

Mark
KD0QYN


David Ranch
 


Nothing special here.  Do you have a real serial device connected via USB?

--
[Thu Apr 30 17:41:22 2020] usb 1-1.1.2: new full-speed USB device number 7 using dwc_otg
[Thu Apr 30 17:41:22 2020] usb 1-1.1.2: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 4.00
[Thu Apr 30 17:41:22 2020] usb 1-1.1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[Thu Apr 30 17:41:22 2020] usb 1-1.1.2: Product: usb serial converter
[Thu Apr 30 17:41:22 2020] usb 1-1.1.2: Manufacturer: FTDI
[Thu Apr 30 17:41:22 2020] usb 1-1.1.2: SerialNumber: FTCAWZIA
[Thu Apr 30 17:41:22 2020] usbcore: registered new interface driver usbserial_generic
[Thu Apr 30 17:41:22 2020] usbserial: USB Serial support registered for generic
[Thu Apr 30 17:41:22 2020] usbcore: registered new interface driver ftdi_sio
[Thu Apr 30 17:41:22 2020] usbserial: USB Serial support registered for FTDI USB Serial Device
[Thu Apr 30 17:41:22 2020] ftdi_sio 1-1.1.2:1.0: FTDI USB Serial Device converter detected
[Thu Apr 30 17:41:22 2020] usb 1-1.1.2: Detected FT232BM
[Thu Apr 30 17:41:22 2020] usb 1-1.1.2: FTDI USB Serial Device converter now attached to ttyUSB0
--

$ find /dev | grep serial
--
/dev/serial
/dev/serial/by-path
/dev/serial/by-path/platform-3f980000.usb-usb-0:1.1.2:1.0-port0
/dev/serial/by-path/platform-3f980000.usb-usb-0:1.2:1.2
/dev/serial/by-id
/dev/serial/by-id/usb-FTDI_usb_serial_converter_FTCAWZIA-if00-port0
/dev/serial/by-id/usb-STMicroelectronics_STM32_STLink_0675FF3035344E5043171228-if02
/dev/serial0
/dev/serial1
--


$ ls -la /dev/serial/by-id/usb-FTDI_usb_serial_converter_FTCAWZIA-if00-port0
lrwxrwxrwx 1 root root 13 Apr 30 17:41 /dev/serial/by-id/usb-FTDI_usb_serial_converter_FTCAWZIA-if00-port0 -> ../../ttyUSB0


--David
KI6ZHD



On 04/30/2020 04:12 PM, Mark Griffith via groups.io wrote:
Again, hmmmmm.  I have a new distribution of Raspbian Buster and just did a dist-upgrade a few days ago, so this should be the newest available, and no /dev/serial.   You sure you have not installed an add-on package?

Perhaps it only shows up if you have more than one serial device plugged in.

Mark
KD0QYN


On Thursday, April 30, 2020, 4:01:26 PM CDT, David Ranch <rpi4hamradio-groupsio@...> wrote:



Predictable serial ports is  also there in Raspbian Stretch.  If you don't want to do it that way, you can do it via Udev tricks:

   http://www.trinityos.com/HAM/CentosDigitalModes/hampacketizing-centos.html#1d.presetup-udevusbserial

--David
KI6ZHD


On 04/30/2020 01:20 PM, Chuck M via groups.io wrote:
Tossing out that the "ls -la dev/serial/by-id" works on my Pi 4B running Buster.  Correctly identified serial port used with my rig.

73s,
Chuck
KD9DVB



On Thu, Apr 30, 2020 at 3:45 PM, Mark Griffith via groups.io
Hmmm,  /dev/serial doesn't exist on Raspbian Buster.  Raspbian has been notorious for not being able to map a device consistently to the same port.  Are you using a different OS?

Mark
KD0QYN



Alan
 

I really appreciate everyone’s help in this.
For controlling the 7200 I use just a serial cable directly from the Pi to the rig. I have d/a converters and I guess could go that route which would allow me to get to alsa mix, but first I’ll try a bit more audio drive in the 7200 (watching ALC). I’ll also try my Buster sd card and do a dist-upgrade.
Here’s probably a dumb question. I have dozens of MMSSTV .png graphics and templates. I know the .png's are compatible with QSSTV, but is there a chance the templates are too?
Thanks, Alan