Hi Steve,

Here’s a link to a Ham that direct connected to his TM-281:

https://groups.io/g/TM281KenwoodMods/topic/tm_281_mod/18112488?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,0,18112488

Bryan K7UDR

The PTT line is 4.94v when the radio is on and the DRAWS/Pi is not

When the Pi comes on, the PTT line goes negative.

I have PTT line on draws connected to PTT line on Radio... but I'm thinking they both produce 5v and they should be connected in a crossover fashion?

On Mon, Jun 3, 2019 at 8:23 AM Bryan Hoyer <bhhoyer@...> wrote:

The PTT Output on DRAWS is an open collector NPN Transistor. It expects the Radio to have a pullup to Positive voltage, typically 5-12V.

If the PTT LED goes off then the SW has done its job.

Measure the voltage on PTT when yo power up, then again when you PTT and release.

Bryan K7UDR

The PTT Output on DRAWS is an open collector NPN Transistor. It expects the Radio to have a pullup to Positive voltage, typically 5-12V.

If the PTT LED goes off then the SW has done its job.

Measure the voltage on PTT when yo power up, then again when you PTT and release.

Bryan K7UDR

Cross posting this from the udrc forum.
Not sure why you are asking your questions in main.

> The tlv320aic3204 driver in the 4.19.42 kernel will NOT work
> reliably. You need to stick with the  4.14.98 kernel until all of Anna's
> patches work their way into the main stream kernel.
>
> From  Anna:
>
>> ALSA changed the API to some of their calls, and the old TLV320 driver
>> doesn’t have the calls.  The new TLV320 driver is in the Raspbian
>> kernel, but it won’t work reliably until I get the final patch pushed
>> in the kernel.
>
> Do NOT do an apt-get upgrade for a while until this gets fixed.
> I have taken apt-get upgrade out of prog_refresh.sh script.

> Where are the sources for udrc-dkms package?

/var/lib/dkms/udrc/1.0.5/source

The udrc/draws tlv320aic32x4 driver is transitioning to a main line
linux kernel driver and will not be built using dkms in future kernels.

/Basil

Christopher AI6KG <ch@...> writes:

> I just reverted back to the latest image.  I will avoid upgrading the
> kernel for now.
>
> Where are the sources for udrc-dkms package?
>
> On Sun, Jun 2, 2019 at 12:23 PM Christopher AI6KG via Groups.Io <ch=
> murgatroid.com@groups.io> wrote:
>
>> #udrc-dkms #dkms #rpi
>>
>> udrc-dkms fails to install after updating system/kernel as seen below.
>>
>> 73 de AI6KG
>>
>>
>> pi@draws:~ $ sudo apt update
>> Hit:1 http://archive.compasslinux.org cedar InRelease
>> Hit:2 http://archive.raspberrypi.org/debian stretch InRelease
>>
>> Get:3 http://raspbian.raspberrypi.org/raspbian stretch InRelease [15.0
>> kB]
>> Fetched 15.0 kB in 2s (5,695 B/s)
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> All packages are up to date.
>> pi@draws:~ $ sudo apt upgrade
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> Calculating upgrade... Done
>> The following package was automatically installed and is no longer
>> required:
>>   dkms
>> Use 'sudo apt autoremove' to remove it.
>> 0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
>> pi@draws:~ $ sudo apt install udrc-dkms
>> Reading package lists... Done
>> Building dependency tree
>> Reading state information... Done
>> The following NEW packages will be installed:
>>   udrc-dkms
>> 0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.
>> Need to get 0 B/27.7 kB of archives.
>> After this operation, 233 kB of additional disk space will be used.
>> (Reading database ... 139013 files and directories currently installed.)
>> Preparing to unpack .../udrc-dkms_1.0.5_armhf.deb ...
>> Leaving 'diversion of /boot/overlays/udrc.dtbo to
>> /usr/share/udrcdkmshack/udrc.dtbo by udrcdkmshack'
>> Leaving 'diversion of /boot/overlays/draws.dtbo to
>> /usr/share/udrcdkmshack/draws.dtbo by udrcdkmshack'
>> Unpacking udrc-dkms (1.0.5) ...
>> dpkg: error processing archive
>> /var/cache/apt/archives/udrc-dkms_1.0.5_armhf.deb (--unpack):
>>  trying to overwrite '/boot/overlays/draws.dtbo', which is also in package
>> raspberrypi-kernel 1.20190517-1
>> Errors were encountered while processing:
>>  /var/cache/apt/archives/udrc-dkms_1.0.5_armhf.deb
>> E: Sub-process /usr/bin/dpkg returned an error code (1)
>> pi@draws:~ $ dpkg -l |grep raspberrypi-kernel
>> ii  raspberrypi-kernel                    1.20190517-1
>>  armhf        Raspberry Pi bootloader
>> ii  raspberrypi-kernel-headers            1.20190517-1
>>  armhf        Header files for the Raspberry Pi Linux kernel

#udrc-dkms #dkms #rpi

udrc-dkms fails to install after updating system/kernel as seen below.

73 de AI6KG

pi@draws:~ $ sudo apt update

Hit:1 http://archive.compasslinux.org cedar InRelease

Hit:2 http://archive.raspberrypi.org/debian stretch InRelease                  

Get:3 http://raspbian.raspberrypi.org/raspbian stretch InRelease [15.0 kB]     

Fetched 15.0 kB in 2s (5,695 B/s)                         

Reading package lists... Done

Building dependency tree       

Reading state information... Done

All packages are up to date.

pi@draws:~ $ sudo apt upgrade

Reading package lists... Done

Building dependency tree       

Reading state information... Done

Calculating upgrade... Done

The following package was automatically installed and is no longer required:

  dkms

Use 'sudo apt autoremove' to remove it.

0 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.

pi@draws:~ $ sudo apt install udrc-dkms 

Reading package lists... Done

Building dependency tree       

Reading state information... Done

The following NEW packages will be installed:

  udrc-dkms

0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.

Need to get 0 B/27.7 kB of archives.

After this operation, 233 kB of additional disk space will be used.

(Reading database ... 139013 files and directories currently installed.)

Preparing to unpack .../udrc-dkms_1.0.5_armhf.deb ...

Leaving 'diversion of /boot/overlays/udrc.dtbo to /usr/share/udrcdkmshack/udrc.dtbo by udrcdkmshack'

Leaving 'diversion of /boot/overlays/draws.dtbo to /usr/share/udrcdkmshack/draws.dtbo by udrcdkmshack'

Unpacking udrc-dkms (1.0.5) ...

dpkg: error processing archive /var/cache/apt/archives/udrc-dkms_1.0.5_armhf.deb (--unpack):

 trying to overwrite '/boot/overlays/draws.dtbo', which is also in package raspberrypi-kernel 1.20190517-1

Errors were encountered while processing:

 /var/cache/apt/archives/udrc-dkms_1.0.5_armhf.deb

E: Sub-process /usr/bin/dpkg returned an error code (1)

pi@draws:~ $ dpkg -l |grep raspberrypi-kernel

ii  raspberrypi-kernel                    1.20190517-1                   armhf        Raspberry Pi bootloader

ii  raspberrypi-kernel-headers            1.20190517-1                   armhf        Header files for the Raspberry Pi Linux kernel

pi@draws:~ $ 

What kind of radio are you trying to setup? What are circuit are you to use?

On Sun, Jun 2, 2019, 11:39 AM Steve McGrane <temporarilyoffline@...> wrote:

I'm chasing this PTT issue on my 2m unit and I'm not sure where to go from here.  I'm out of parts or ideas or both.

The DRAWS hat will signal PTT and the radio will open transmit and send as it is supposed to.  When DRAWS is done, DRAWS PTT will shut off, but the radio still transmits.

What can I put "in-line" in the PTT wire to get the signal closer to "zero"?

Am I asking the right question?

- Steve

I'm chasing this PTT issue on my 2m unit and I'm not sure where to go from here.  I'm out of parts or ideas or both.

The DRAWS hat will signal PTT and the radio will open transmit and send as it is supposed to.  When DRAWS is done, DRAWS PTT will shut off, but the radio still transmits.

What can I put "in-line" in the PTT wire to get the signal closer to "zero"?

Am I asking the right question?

- Steve

Thanks, Basil.

I had a couple of issues. I had tried to configure Fldigi to use Hamlib for rig control. That seemed to have hung the PC interface in the radio until I power cycled it. Additionally, I saw a few undervoltage warnings in dmesg so I switched to a beefier supply.

After changing out the Pi power supply and power cycling the radio, rigctl is working fine at 57600.

So now I need to figure out how to use Hamlib in Fldigi. Here is how I have it configured (although I currently have "Use Hamlib" unchecked). I figure I want to continue to use GPIO 23 for PTT (via the GPIO tab) so I have PTT via Hamlib command unchecked. 

What should be used for flow control? Anything on this panel pop out to you as an issue?

Thanks,

Keith

KF7DRV

On Sat, Jun 1, 2019 at 6:59 AM Basil Gunn <basil@...> wrote:

Try setting the PC baud rate on the radio to 57600.
Also try connecting a serial program like screen and typing in the radio ID string. It should respond with 'OK'.
screen /dev/ttyUSB0 57600

TMV71 or D700
When I'm in front of my radio again I'll find out which works.
/Basil n7nix

On May 31, 2019 10:45:22 PM PDT, Basil Gunn <basil@...> wrote:

Check out a recent script (wlgw-check.sh) I wrote for rig control of the tm-v71.
https://github.com/n7nix/auto-rmsgw-find
This script iterates through a list of RMS gateways using a TM-V71a and Hamlib rigctl
/Basil

On May 31, 2019 5:43:34 PM PDT, Keith Williamson <hkwilliamson@...> wrote:

I now have a TM-V71a connected to my UDRC and am trying to get rigctl to work with it. I have an equivalent of a PG-5H connected to a serial/USB converter enumerated as /dev/ttyUSB0. My first test of the cable was with chirp and it seems to work fine. 

When I try ""rigctl -m 234 -r /dev/ttyUSB0 -vvvv", I see multiple read_string timeouts and then rigctl enters command mode. When I try "f" to get the current vfo frequency, I get multiple read_string timeouts and finally "get_freq: error = Communication timed out". 

Are there specific serial params needed to talk to the V71a? (e.g. RTS/CTS flow control, specific baud rate)?

Thanks for any help!

Keith

KF7DRV

On Sat, May 25, 2019 at 4:13 PM Doug Henry <doug.henry1@...> wrote:

Bill, 6 pin mini din 1200 and 9600  although I've only used on 1200.

Doug VE1ZG

On Sat, 25 May 2019 at 19:59, Bill Vodall <wa7nwp@...> wrote:

> The Icom IC-7000 has a data port that works well for packet.

6 pin mini-din or other?

1200 baud and/or 9600 baud?

Try setting the PC baud rate on the radio to 57600.
Also try connecting a serial program like screen and typing in the radio ID string. It should respond with 'OK'.
screen /dev/ttyUSB0 57600

TMV71 or D700
When I'm in front of my radio again I'll find out which works.
/Basil n7nix

On May 31, 2019 10:45:22 PM PDT, Basil Gunn <basil@...> wrote:

Check out a recent script (wlgw-check.sh) I wrote for rig control of the tm-v71.
https://github.com/n7nix/auto-rmsgw-find
This script iterates through a list of RMS gateways using a TM-V71a and Hamlib rigctl
/Basil

On May 31, 2019 5:43:34 PM PDT, Keith Williamson <hkwilliamson@...> wrote:

I now have a TM-V71a connected to my UDRC and am trying to get rigctl to work with it. I have an equivalent of a PG-5H connected to a serial/USB converter enumerated as /dev/ttyUSB0. My first test of the cable was with chirp and it seems to work fine. 

When I try ""rigctl -m 234 -r /dev/ttyUSB0 -vvvv", I see multiple read_string timeouts and then rigctl enters command mode. When I try "f" to get the current vfo frequency, I get multiple read_string timeouts and finally "get_freq: error = Communication timed out". 

Are there specific serial params needed to talk to the V71a? (e.g. RTS/CTS flow control, specific baud rate)?

Thanks for any help!

Keith

KF7DRV

On Sat, May 25, 2019 at 4:13 PM Doug Henry <doug.henry1@...> wrote:

Bill, 6 pin mini din 1200 and 9600  although I've only used on 1200.

Doug VE1ZG

On Sat, 25 May 2019 at 19:59, Bill Vodall <wa7nwp@...> wrote:

> The Icom IC-7000 has a data port that works well for packet.

6 pin mini-din or other?

1200 baud and/or 9600 baud?