Date   

Re: hb_confbridge configuration

Steve N4IRS
 

Stephen,
Are you running hblink.py or hb_confbridge.py? hb_confbridge.py sub-class' (or calls if you wish) hblink.py

Steve

On 1/24/2018 10:36 AM, Stephen Brown - K1LNX wrote:
Hi guys, 
    I am getting my feet wet with HBlink and doing some minimal testing. I had some questions on a few things: 

For starters, one planned use of a master is for my hotspots only, as such I have defined this: 

# hotspots
[K1LNX-HOTSPOTS-MASTER]
MODE: MASTER
ENABLED: True
REPEAT: False
EXPORT_AMBE: False
IP:
PORT: 57890
PASSPHRASE: xxxxxxxxxxxxxxxxxxx
GROUP_HANGTIME: 5

If I specify explicit bridging rules in hb_confbridge_rules.py, can I leave REPEAT: set to False? My understanding is that if it's set to TRUE it routes all traffic regardless. I am trying to explicitly route certain talkgroups to and from this master with 2-3 hotspots connected. Here is what I set in hb_confbridge_rules.py (note, K1LNX-REPEATERS-MASTER is another system built identical to the HOTSPOTS master):

BRIDGES = {
    'LNXNET': [
            {'SYSTEM': 'K1LNX-HOTSPOTS-MASTER', 'TS': 2, 'TGID': 5780, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
            {'SYSTEM': 'K1LNX-REPEATERS-MASTER', 'TS': 1, 'TGID': 5780, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []}
        ],

I don't have any ability to test this yet, but I assume this will work as configured? I think this will pass traffic from "K1LNX-HOTSPOTS-MASTER" to "K1LNX-REPEATERS-MASTER" but what about passing to directly connected clients on the HOTSPOTS master? 

Next question is concerning a client connection to Brandmeister. I created a client in hblink.cfg: 

# Brandmeister 3108
[BM-3108]
MODE: CLIENT
ENABLED: True
EXPORT_AMBE: False
IP:
PORT: 62030
MASTER_PORT: 62031
PASSPHRASE: xxxxxxxxxx
CALLSIGN: K1LNX
RADIO_ID: xxxxxxxxx
RX_FREQ: 436500000
TX_FREQ: 436500000
TX_POWER: 1
COLORCODE: 1
SLOTS: 2
LATITUDE: 035.9617
LONGITUDE: -083.9234
HEIGHT: 0
LOCATION: Knoxville, TN, USA
DESCRIPTION: K1LNX MMDVM
URL:
SOFTWARE_ID: 20170620
PACKAGE_ID: MMDVM
GROUP_HANGTIME: 5
OPTIONS: 

It seems to login to the server with no issues, so I created an entry for 3100 for testing to see if I can get traffic: 

  'BM-3100': [
            {'SYSTEM': 'K1LNX-HOTSPOTS-MASTER', 'TS': 2, 'TGID': 3100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
            {'SYSTEM': 'BM-3108', 'TS': 2, 'TGID': 3100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
    ]

I connected my OpenSPOT to the HOTSPOTS master, but I do not appear to be getting traffic from 3100. 

Do my configs look correct? Should this work as-is? 

tnx and 73
Stephen
K1LNX




Re: hb_confbridge configuration

Cort N0MJS <n0mjs@...>
 

In that case you need multiple “master” instances set up and use the rules to bridge between them.


On Jan 24, 2018, at 9:36 AM, Stephen Brown - K1LNX <k1lnx@...> wrote:

Hi guys, 
    I am getting my feet wet with HBlink and doing some minimal testing. I had some questions on a few things: 

For starters, one planned use of a master is for my hotspots only, as such I have defined this: 

# hotspots
[K1LNX-HOTSPOTS-MASTER]
MODE: MASTER
ENABLED: True
REPEAT: False
EXPORT_AMBE: False
IP:
PORT: 57890
PASSPHRASE: xxxxxxxxxxxxxxxxxxx
GROUP_HANGTIME: 5

If I specify explicit bridging rules in hb_confbridge_rules.py, can I leave REPEAT: set to False? My understanding is that if it's set to TRUE it routes all traffic regardless. I am trying to explicitly route certain talkgroups to and from this master with 2-3 hotspots connected. Here is what I set in hb_confbridge_rules.py (note, K1LNX-REPEATERS-MASTER is another system built identical to the HOTSPOTS master):

BRIDGES = {
    'LNXNET': [
            {'SYSTEM': 'K1LNX-HOTSPOTS-MASTER', 'TS': 2, 'TGID': 5780, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
            {'SYSTEM': 'K1LNX-REPEATERS-MASTER', 'TS': 1, 'TGID': 5780, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []}
        ],

I don't have any ability to test this yet, but I assume this will work as configured? I think this will pass traffic from "K1LNX-HOTSPOTS-MASTER" to "K1LNX-REPEATERS-MASTER" but what about passing to directly connected clients on the HOTSPOTS master? 

Next question is concerning a client connection to Brandmeister. I created a client in hblink.cfg: 

# Brandmeister 3108
[BM-3108]
MODE: CLIENT
ENABLED: True
EXPORT_AMBE: False
IP:
PORT: 62030
MASTER_PORT: 62031
PASSPHRASE: xxxxxxxxxx
CALLSIGN: K1LNX
RADIO_ID: xxxxxxxxx
RX_FREQ: 436500000
TX_FREQ: 436500000
TX_POWER: 1
COLORCODE: 1
SLOTS: 2
LATITUDE: 035.9617
LONGITUDE: -083.9234
HEIGHT: 0
LOCATION: Knoxville, TN, USA
DESCRIPTION: K1LNX MMDVM
URL:
SOFTWARE_ID: 20170620
PACKAGE_ID: MMDVM
GROUP_HANGTIME: 5
OPTIONS: 

It seems to login to the server with no issues, so I created an entry for 3100 for testing to see if I can get traffic: 

  'BM-3100': [
            {'SYSTEM': 'K1LNX-HOTSPOTS-MASTER', 'TS': 2, 'TGID': 3100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
            {'SYSTEM': 'BM-3108', 'TS': 2, 'TGID': 3100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
    ]

I connected my OpenSPOT to the HOTSPOTS master, but I do not appear to be getting traffic from 3100. 

Do my configs look correct? Should this work as-is? 

tnx and 73
Stephen
K1LNX



Cort Buffington
785-865-7206


hb_confbridge configuration

Stephen Brown - K1LNX
 

Hi guys, 
    I am getting my feet wet with HBlink and doing some minimal testing. I had some questions on a few things: 

For starters, one planned use of a master is for my hotspots only, as such I have defined this: 

# hotspots
[K1LNX-HOTSPOTS-MASTER]
MODE: MASTER
ENABLED: True
REPEAT: False
EXPORT_AMBE: False
IP:
PORT: 57890
PASSPHRASE: xxxxxxxxxxxxxxxxxxx
GROUP_HANGTIME: 5

If I specify explicit bridging rules in hb_confbridge_rules.py, can I leave REPEAT: set to False? My understanding is that if it's set to TRUE it routes all traffic regardless. I am trying to explicitly route certain talkgroups to and from this master with 2-3 hotspots connected. Here is what I set in hb_confbridge_rules.py (note, K1LNX-REPEATERS-MASTER is another system built identical to the HOTSPOTS master):

BRIDGES = {
    'LNXNET': [
            {'SYSTEM': 'K1LNX-HOTSPOTS-MASTER', 'TS': 2, 'TGID': 5780, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
            {'SYSTEM': 'K1LNX-REPEATERS-MASTER', 'TS': 1, 'TGID': 5780, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []}
        ],

I don't have any ability to test this yet, but I assume this will work as configured? I think this will pass traffic from "K1LNX-HOTSPOTS-MASTER" to "K1LNX-REPEATERS-MASTER" but what about passing to directly connected clients on the HOTSPOTS master? 

Next question is concerning a client connection to Brandmeister. I created a client in hblink.cfg: 

# Brandmeister 3108
[BM-3108]
MODE: CLIENT
ENABLED: True
EXPORT_AMBE: False
IP:
PORT: 62030
MASTER_PORT: 62031
PASSPHRASE: xxxxxxxxxx
CALLSIGN: K1LNX
RADIO_ID: xxxxxxxxx
RX_FREQ: 436500000
TX_FREQ: 436500000
TX_POWER: 1
COLORCODE: 1
SLOTS: 2
LATITUDE: 035.9617
LONGITUDE: -083.9234
HEIGHT: 0
LOCATION: Knoxville, TN, USA
DESCRIPTION: K1LNX MMDVM
URL:
SOFTWARE_ID: 20170620
PACKAGE_ID: MMDVM
GROUP_HANGTIME: 5
OPTIONS: 

It seems to login to the server with no issues, so I created an entry for 3100 for testing to see if I can get traffic: 

  'BM-3100': [
            {'SYSTEM': 'K1LNX-HOTSPOTS-MASTER', 'TS': 2, 'TGID': 3100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
            {'SYSTEM': 'BM-3108', 'TS': 2, 'TGID': 3100, 'ACTIVE': True, 'TIMEOUT': 2, 'TO_TYPE': 'NONE', 'ON': [], 'OFF': []},
    ]

I connected my OpenSPOT to the HOTSPOTS master, but I do not appear to be getting traffic from 3100. 

Do my configs look correct? Should this work as-is? 

tnx and 73
Stephen
K1LNX



Re: Request for information

Steve N4IRS
 

On 1/22/2018 11:37 AM, Roselito de los Reyes wrote:
Hi Steve,

I am trying to build one of this.. I understand that DMRGateway is now Analog_Bridge... Where do I get a good copy of HB_Bridge and ambe_audio and conf_bridge.

Thanks

Lito WI6y

From: main@DVSwitch.groups.io <main@DVSwitch.groups.io> on behalf of Steve N4IRS <szingman@...>
Sent: Saturday, January 20, 2018 9:29 AM
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Request for information
 
Folks,
Thank you all so much for providing the information I requested. The results are helpful and somewhat telling. Keep it coming as new people run across the the post.

73, Steve N4IRS


Re: Request for information

Steve N4IRS
 

Folks,
Thank you all so much for providing the information I requested. The results are helpful and somewhat telling. Keep it coming as new people run across the the post.

73, Steve N4IRS


Re: Request for information

Ed W8VT
 

DIAL Raspberry Pi2

latency_timer = 1

Ed W8VT

On 01/17/2018 09:14 AM, Steve N4IRS wrote:
We have been working on the next revision of Analog_Bridge. Along with adding features and refining settings, we are trying to squash bugs. While testing the NWDigital DV300u (ThumbDV) we encountered a problem with data transfer . Some of the packets were not being processed in the required window. The NWD DV3000u uses a FTDI chip to communicate with the host computer. Under Linux, or at least Debian the driver is the FTDI serial. On the machine under test, a older Dell 2950 with more then enough horsepower and no history of issues with USB, we were not getting data in a timely manner. There is a value that can be adjusted to resolve this. /sys/bus/usb-serial/devices/ttyUSB0/latency_timer. The default looks to be 16. The 2950 was set at 16. So far so good. Well, I have a machine running a full time DMR <---> D-Star bridge using two of the DV3000u. When I checked the latency_timer, it was set to 1. Huh? I know I did not change it.

I am asking everybody that is using a DV3000 and a FTDI chip to test with the device plugged in. As root: cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer. Please report the result here. We have multiple ways to set this to what we want, but for now, All I want to know is what hardware / software you are running and the value.

Thanks, Steve

 



Re: Request for information

Mike, AA9VI
 

Steve, mine is also 1 with Debian 8 Jessie.


Re: Request for information

Ian Tulley
 

Hi Steve, I’m running an i3 mini ITX Board Debian 9, result=16 for me

Regards
Ian (VK2HK)

Typo's, autocorrect or spelling mistakes courtesy of both myself and my iPhone

On 18 Jan 2018, at 01:14, Steve N4IRS <szingman@...> wrote:

We have been working on the next revision of Analog_Bridge. Along with adding features and refining settings, we are trying to squash bugs. While testing the NWDigital DV300u (ThumbDV) we encountered a problem with data transfer . Some of the packets were not being processed in the required window. The NWD DV3000u uses a FTDI chip to communicate with the host computer. Under Linux, or at least Debian the driver is the FTDI serial. On the machine under test, a older Dell 2950 with more then enough horsepower and no history of issues with USB, we were not getting data in a timely manner. There is a value that can be adjusted to resolve this. /sys/bus/usb-serial/devices/ttyUSB0/latency_timer. The default looks to be 16. The 2950 was set at 16. So far so good. Well, I have a machine running a full time DMR <---> D-Star bridge using two of the DV3000u. When I checked the latency_timer, it was set to 1. Huh? I know I did not change it.

I am asking everybody that is using a DV3000 and a FTDI chip to test with the device plugged in. As root: cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer. Please report the result here. We have multiple ways to set this to what we want, but for now, All I want to know is what hardware / software you are running and the value.

Thanks, Steve

 


Re: Request for information

David KE6UPI
 

So I moved the DV3000u to the front usb port. Now its sounds much better. 

David



--
Thanks, David

"Laws that forbid the carrying of arms...disarm only those who are neither inclined nor determined to commit crimes. Such laws make things worse for the assaulted and better for the assailants; they serve rather to encourage than prevent homicides, for an unarmed man may be attacked with greater confidence than an armed one."
Thomas Jefferson

On Wed, Jan 17, 2018 at 3:15 PM, David KE6UPI <shawpbx@...> wrote:
Here is my AMBEtest4 results.

root@asl2060:/opt/Analog_Bridge/DV3000# python AMBEtest4.py -n -s /dev/ttyUSB0
Setting serial port
Serial port parameters:
Port name:      /dev/ttyUSB0
Baudrate:       460800
Byte size:      8
Parity:         N
Stop bits:      1
Xon Xoff:       False
RTS/CTS:        False
DST/DTR:        False
*********************
Silent testing mode.....
Error count =  0


David



--
Thanks, David

"Laws that forbid the carrying of arms...disarm only those who are neither inclined nor determined to commit crimes. Such laws make things worse for the assaulted and better for the assailants; they serve rather to encourage than prevent homicides, for an unarmed man may be attacked with greater confidence than an armed one."
Thomas Jefferson

On Wed, Jan 17, 2018 at 12:35 PM, Dylan KI7SBI <dylan@...> wrote:
On Wed, Jan 17, 2018 at 6:14 AM, Steve N4IRS <szingman@...> wrote:
but for now, All I want to know is what hardware / software you are running and the value.


Dell PowerEdge 400SC with DV3000usb
$ cat /etc/issue
Ubuntu 14.04.5 LTS \n \l
$ uname -a
Linux ast3 3.13.0-135-generic #184-Ubuntu SMP Wed Oct 18 11:56:31 UTC 2017 i686 i686 i686 GNU/Linux
$ cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
1

KI7SBI




Re: Request for information

David KE6UPI
 

Here is my AMBEtest4 results.

root@asl2060:/opt/Analog_Bridge/DV3000# python AMBEtest4.py -n -s /dev/ttyUSB0
Setting serial port
Serial port parameters:
Port name:      /dev/ttyUSB0
Baudrate:       460800
Byte size:      8
Parity:         N
Stop bits:      1
Xon Xoff:       False
RTS/CTS:        False
DST/DTR:        False
*********************
Silent testing mode.....
Error count =  0


David



--
Thanks, David

"Laws that forbid the carrying of arms...disarm only those who are neither inclined nor determined to commit crimes. Such laws make things worse for the assaulted and better for the assailants; they serve rather to encourage than prevent homicides, for an unarmed man may be attacked with greater confidence than an armed one."
Thomas Jefferson

On Wed, Jan 17, 2018 at 12:35 PM, Dylan KI7SBI <dylan@...> wrote:
On Wed, Jan 17, 2018 at 6:14 AM, Steve N4IRS <szingman@...> wrote:
but for now, All I want to know is what hardware / software you are running and the value.


Dell PowerEdge 400SC with DV3000usb
$ cat /etc/issue
Ubuntu 14.04.5 LTS \n \l
$ uname -a
Linux ast3 3.13.0-135-generic #184-Ubuntu SMP Wed Oct 18 11:56:31 UTC 2017 i686 i686 i686 GNU/Linux
$ cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
1

KI7SBI



Re: Request for information

Dylan KI7SBI
 

On Wed, Jan 17, 2018 at 6:14 AM, Steve N4IRS <szingman@...> wrote:
but for now, All I want to know is what hardware / software you are running and the value.


Dell PowerEdge 400SC with DV3000usb
$ cat /etc/issue
Ubuntu 14.04.5 LTS \n \l
$ uname -a
Linux ast3 3.13.0-135-generic #184-Ubuntu SMP Wed Oct 18 11:56:31 UTC 2017 i686 i686 i686 GNU/Linux
$ cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer
1

KI7SBI


Re: Request for information

Veijo Arponen OH4VA
 

Linux dmr 4.13.0-19-generic #22-Ubuntu SMP Mon Dec 4 11:57:38 UTC 2017 i686 i686 i686 GNU/Linux

Distributor ID: Ubuntu
Description: Ubuntu 17.10
Release: 17.10
Codename: artful


Currently I'm not running any DMR-application. I have plans to run
SharkRF SPK-server which serves openSPOTs for the announcements.

/sys/bus/usb-serial/devices/ttyUSB0/latency_timer
16

73 de Veijo OH3NFC


Re: Request for information

 

Hardware  is  Dell OptiPlex 380 - SFF - Core 2 Duo E7500 2.93 GHz

Running  Debian 8

 cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer     result  =   1

DV3000U running a DMR to AllStarLink gateway


Richard VE2DJE




Le 17/01/2018 à 09:24, David a écrit :
timer is 1
Pi 3 NWdigital dongle raspbian

On Wed, Jan 17, 2018 at 8:14 AM, Steve N4IRS <szingman@...> wrote:
We have been working on the next revision of Analog_Bridge. Along with adding features and refining settings, we are trying to squash bugs. While testing the NWDigital DV300u (ThumbDV) we encountered a problem with data transfer . Some of the packets were not being processed in the required window. The NWD DV3000u uses a FTDI chip to communicate with the host computer. Under Linux, or at least Debian the driver is the FTDI serial. On the machine under test, a older Dell 2950 with more then enough horsepower and no history of issues with USB, we were not getting data in a timely manner. There is a value that can be adjusted to resolve this. /sys/bus/usb-serial/devices/ttyUSB0/latency_timer. The default looks to be 16. The 2950 was set at 16. So far so good. Well, I have a machine running a full time DMR <---> D-Star bridge using two of the DV3000u. When I checked the latency_timer, it was set to 1. Huh? I know I did not change it.

I am asking everybody that is using a DV3000 and a FTDI chip to test with the device plugged in. As root: cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer. Please report the result here. We have multiple ways to set this to what we want, but for now, All I want to know is what hardware / software you are running and the value.

Thanks, Steve

 


Virus-free. www.avg.com


Re: Request for information

Steve N4IRS
 

No, I do not think so. Did you run the confidence test (AMBEtest4.py) with Analog_bridge stopped?

On 1/17/2018 10:11 AM, David KE6UPI wrote:
No it didn't. Could I (we) have received a bad batch of DV3000u? ASL to DMR sounds great. DMR to ASL is choppy. 

David



--
Thanks, David

"Laws that forbid the carrying of arms...disarm only those who are neither inclined nor determined to commit crimes. Such laws make things worse for the assaulted and better for the assailants; they serve rather to encourage than prevent homicides, for an unarmed man may be attacked with greater confidence than an armed one."
Thomas Jefferson

On Wed, Jan 17, 2018 at 7:09 AM, Steve N4IRS <szingman@...> wrote:
Both interesting bits of info.
Did changing to 1 improve the audio quality?

Thanks

On 1/17/2018 9:50 AM, David KE6UPI wrote:
After your email yesterday. I changed it to 1 from 16. It stays at 1 after reboots.

David



--
Thanks, David

"Laws that forbid the carrying of arms...disarm only those who are neither inclined nor determined to commit crimes. Such laws make things worse for the assaulted and better for the assailants; they serve rather to encourage than prevent homicides, for an unarmed man may be attacked with greater confidence than an armed one."
Thomas Jefferson

On Wed, Jan 17, 2018 at 6:33 AM, Steve N4IRS <szingman@...> wrote:
Was it set that way or did you change it after we emailed yesterday? Please check it after a fresh boot.

Thanks, Steve

On 1/17/2018 9:24 AM, David wrote:
timer is 1
Pi 3 NWdigital dongle raspbian

On Wed, Jan 17, 2018 at 8:14 AM, Steve N4IRS <szingman@...> wrote:
We have been working on the next revision of Analog_Bridge. Along with adding features and refining settings, we are trying to squash bugs. While testing the NWDigital DV300u (ThumbDV) we encountered a problem with data transfer . Some of the packets were not being processed in the required window. The NWD DV3000u uses a FTDI chip to communicate with the host computer. Under Linux, or at least Debian the driver is the FTDI serial. On the machine under test, a older Dell 2950 with more then enough horsepower and no history of issues with USB, we were not getting data in a timely manner. There is a value that can be adjusted to resolve this. /sys/bus/usb-serial/devices/ttyUSB0/latency_timer. The default looks to be 16. The 2950 was set at 16. So far so good. Well, I have a machine running a full time DMR <---> D-Star bridge using two of the DV3000u. When I checked the latency_timer, it was set to 1. Huh? I know I did not change it.

I am asking everybody that is using a DV3000 and a FTDI chip to test with the device plugged in. As root: cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer. Please report the result here. We have multiple ways to set this to what we want, but for now, All I want to know is what hardware / software you are running and the value.

Thanks, Steve

 







Re: Request for information

Steve N4IRS
 

I have 3 ThumbDVs. Two are in a semi-permanent DMR <---> D-Star bridge I put up for the local group. The other is in a machine Mike and I are testing on. That just leaves a PiDV.

On 1/17/2018 10:18 AM, Steven Blackford wrote:

Yeah…. I thought of that when I hit send.  Disregard.  I’m used to having an extra to experiment with. 😊

 

Steve

 

From: Steve N4IRS
Sent: Wednesday, January 17, 2018 10:15 AM
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Request for information

 

It's ASL to DMR. Only 1 DV3000

On 1/17/2018 10:14 AM, Steven Blackford wrote:

David,

   Have you tried swapping the ThumbDV’s around?  That’s a quck easy test to see how they work.

 

Steve

 

From: David KE6UPI
Sent: Wednesday, January 17, 2018 10:11 AM
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Request for information

 

No it didn't. Could I (we) have received a bad batch of DV3000u? ASL to DMR sounds great. DMR to ASL is choppy. 

 

David


 

 

--

Thanks, David

 

"Laws that forbid the carrying of arms...disarm only those who are neither inclined nor determined to commit crimes. Such laws make things worse for the assaulted and better for the assailants; they serve rather to encourage than prevent homicides, for an unarmed man may be attacked with greater confidence than an armed one."

Thomas Jefferson

 

On Wed, Jan 17, 2018 at 7:09 AM, Steve N4IRS <szingman@...> wrote:

Both interesting bits of info.
Did changing to 1 improve the audio quality?

Thanks

On 1/17/2018 9:50 AM, David KE6UPI wrote:

After your email yesterday. I changed it to 1 from 16. It stays at 1 after reboots.

 

David


 

 

--

Thanks, David

 

"Laws that forbid the carrying of arms...disarm only those who are neither inclined nor determined to commit crimes. Such laws make things worse for the assaulted and better for the assailants; they serve rather to encourage than prevent homicides, for an unarmed man may be attacked with greater confidence than an armed one."

Thomas Jefferson

 

On Wed, Jan 17, 2018 at 6:33 AM, Steve N4IRS <szingman@...> wrote:

Was it set that way or did you change it after we emailed yesterday? Please check it after a fresh boot.

Thanks, Steve

On 1/17/2018 9:24 AM, David wrote:

timer is 1

Pi 3 NWdigital dongle raspbian

 

On Wed, Jan 17, 2018 at 8:14 AM, Steve N4IRS <szingman@...> wrote:

We have been working on the next revision of Analog_Bridge. Along with adding features and refining settings, we are trying to squash bugs. While testing the NWDigital DV300u (ThumbDV) we encountered a problem with data transfer . Some of the packets were not being processed in the required window. The NWD DV3000u uses a FTDI chip to communicate with the host computer. Under Linux, or at least Debian the driver is the FTDI serial. On the machine under test, a older Dell 2950 with more then enough horsepower and no history of issues with USB, we were not getting data in a timely manner. There is a value that can be adjusted to resolve this. /sys/bus/usb-serial/devices/ttyUSB0/latency_timer. The default looks to be 16. The 2950 was set at 16. So far so good. Well, I have a machine running a full time DMR <---> D-Star bridge using two of the DV3000u. When I checked the latency_timer, it was set to 1. Huh? I know I did not change it.

I am asking everybody that is using a DV3000 and a FTDI chip to test with the device plugged in. As root: cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer. Please report the result here. We have multiple ways to set this to what we want, but for now, All I want to know is what hardware / software you are running and the value.

Thanks, Steve

 

 

 

 

 

 

 

 

 



Re: Request for information

Steven Blackford
 

Yeah…. I thought of that when I hit send.  Disregard.  I’m used to having an extra to experiment with. 😊

 

Steve

 

From: Steve N4IRS
Sent: Wednesday, January 17, 2018 10:15 AM
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Request for information

 

It's ASL to DMR. Only 1 DV3000

On 1/17/2018 10:14 AM, Steven Blackford wrote:

David,

   Have you tried swapping the ThumbDV’s around?  That’s a quck easy test to see how they work.

 

Steve

 

From: David KE6UPI
Sent: Wednesday, January 17, 2018 10:11 AM
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Request for information

 

No it didn't. Could I (we) have received a bad batch of DV3000u? ASL to DMR sounds great. DMR to ASL is choppy. 

 

David


 

 

--

Thanks, David

 

"Laws that forbid the carrying of arms...disarm only those who are neither inclined nor determined to commit crimes. Such laws make things worse for the assaulted and better for the assailants; they serve rather to encourage than prevent homicides, for an unarmed man may be attacked with greater confidence than an armed one."

Thomas Jefferson

 

On Wed, Jan 17, 2018 at 7:09 AM, Steve N4IRS <szingman@...> wrote:

Both interesting bits of info.
Did changing to 1 improve the audio quality?

Thanks

On 1/17/2018 9:50 AM, David KE6UPI wrote:

After your email yesterday. I changed it to 1 from 16. It stays at 1 after reboots.

 

David


 

 

--

Thanks, David

 

"Laws that forbid the carrying of arms...disarm only those who are neither inclined nor determined to commit crimes. Such laws make things worse for the assaulted and better for the assailants; they serve rather to encourage than prevent homicides, for an unarmed man may be attacked with greater confidence than an armed one."

Thomas Jefferson

 

On Wed, Jan 17, 2018 at 6:33 AM, Steve N4IRS <szingman@...> wrote:

Was it set that way or did you change it after we emailed yesterday? Please check it after a fresh boot.

Thanks, Steve

On 1/17/2018 9:24 AM, David wrote:

timer is 1

Pi 3 NWdigital dongle raspbian

 

On Wed, Jan 17, 2018 at 8:14 AM, Steve N4IRS <szingman@...> wrote:

We have been working on the next revision of Analog_Bridge. Along with adding features and refining settings, we are trying to squash bugs. While testing the NWDigital DV300u (ThumbDV) we encountered a problem with data transfer . Some of the packets were not being processed in the required window. The NWD DV3000u uses a FTDI chip to communicate with the host computer. Under Linux, or at least Debian the driver is the FTDI serial. On the machine under test, a older Dell 2950 with more then enough horsepower and no history of issues with USB, we were not getting data in a timely manner. There is a value that can be adjusted to resolve this. /sys/bus/usb-serial/devices/ttyUSB0/latency_timer. The default looks to be 16. The 2950 was set at 16. So far so good. Well, I have a machine running a full time DMR <---> D-Star bridge using two of the DV3000u. When I checked the latency_timer, it was set to 1. Huh? I know I did not change it.

I am asking everybody that is using a DV3000 and a FTDI chip to test with the device plugged in. As root: cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer. Please report the result here. We have multiple ways to set this to what we want, but for now, All I want to know is what hardware / software you are running and the value.

Thanks, Steve

 

 

 

 

 

 

 

 

 


Re: Request for information

Steve N4IRS
 

It's ASL to DMR. Only 1 DV3000

On 1/17/2018 10:14 AM, Steven Blackford wrote:

David,

   Have you tried swapping the ThumbDV’s around?  That’s a quck easy test to see how they work.

 

Steve

 

From: David KE6UPI
Sent: Wednesday, January 17, 2018 10:11 AM
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Request for information

 

No it didn't. Could I (we) have received a bad batch of DV3000u? ASL to DMR sounds great. DMR to ASL is choppy. 

 

David


 

 

--

Thanks, David

 

"Laws that forbid the carrying of arms...disarm only those who are neither inclined nor determined to commit crimes. Such laws make things worse for the assaulted and better for the assailants; they serve rather to encourage than prevent homicides, for an unarmed man may be attacked with greater confidence than an armed one."

Thomas Jefferson

 

On Wed, Jan 17, 2018 at 7:09 AM, Steve N4IRS <szingman@...> wrote:

Both interesting bits of info.
Did changing to 1 improve the audio quality?

Thanks

On 1/17/2018 9:50 AM, David KE6UPI wrote:

After your email yesterday. I changed it to 1 from 16. It stays at 1 after reboots.

 

David


 

 

--

Thanks, David

 

"Laws that forbid the carrying of arms...disarm only those who are neither inclined nor determined to commit crimes. Such laws make things worse for the assaulted and better for the assailants; they serve rather to encourage than prevent homicides, for an unarmed man may be attacked with greater confidence than an armed one."

Thomas Jefferson

 

On Wed, Jan 17, 2018 at 6:33 AM, Steve N4IRS <szingman@...> wrote:

Was it set that way or did you change it after we emailed yesterday? Please check it after a fresh boot.

Thanks, Steve

On 1/17/2018 9:24 AM, David wrote:

timer is 1

Pi 3 NWdigital dongle raspbian

 

On Wed, Jan 17, 2018 at 8:14 AM, Steve N4IRS <szingman@...> wrote:

We have been working on the next revision of Analog_Bridge. Along with adding features and refining settings, we are trying to squash bugs. While testing the NWDigital DV300u (ThumbDV) we encountered a problem with data transfer . Some of the packets were not being processed in the required window. The NWD DV3000u uses a FTDI chip to communicate with the host computer. Under Linux, or at least Debian the driver is the FTDI serial. On the machine under test, a older Dell 2950 with more then enough horsepower and no history of issues with USB, we were not getting data in a timely manner. There is a value that can be adjusted to resolve this. /sys/bus/usb-serial/devices/ttyUSB0/latency_timer. The default looks to be 16. The 2950 was set at 16. So far so good. Well, I have a machine running a full time DMR <---> D-Star bridge using two of the DV3000u. When I checked the latency_timer, it was set to 1. Huh? I know I did not change it.

I am asking everybody that is using a DV3000 and a FTDI chip to test with the device plugged in. As root: cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer. Please report the result here. We have multiple ways to set this to what we want, but for now, All I want to know is what hardware / software you are running and the value.

Thanks, Steve

 

 

 

 

 

 

 



Re: Request for information

Steven Blackford
 

David,

   Have you tried swapping the ThumbDV’s around?  That’s a quck easy test to see how they work.

 

Steve

 

From: David KE6UPI
Sent: Wednesday, January 17, 2018 10:11 AM
To: main@DVSwitch.groups.io
Subject: Re: [DVSwitch] Request for information

 

No it didn't. Could I (we) have received a bad batch of DV3000u? ASL to DMR sounds great. DMR to ASL is choppy. 

 

David


 

 

--

Thanks, David

 

"Laws that forbid the carrying of arms...disarm only those who are neither inclined nor determined to commit crimes. Such laws make things worse for the assaulted and better for the assailants; they serve rather to encourage than prevent homicides, for an unarmed man may be attacked with greater confidence than an armed one."

Thomas Jefferson

 

On Wed, Jan 17, 2018 at 7:09 AM, Steve N4IRS <szingman@...> wrote:

Both interesting bits of info.
Did changing to 1 improve the audio quality?

Thanks

On 1/17/2018 9:50 AM, David KE6UPI wrote:

After your email yesterday. I changed it to 1 from 16. It stays at 1 after reboots.

 

David


 

 

--

Thanks, David

 

"Laws that forbid the carrying of arms...disarm only those who are neither inclined nor determined to commit crimes. Such laws make things worse for the assaulted and better for the assailants; they serve rather to encourage than prevent homicides, for an unarmed man may be attacked with greater confidence than an armed one."

Thomas Jefferson

 

On Wed, Jan 17, 2018 at 6:33 AM, Steve N4IRS <szingman@...> wrote:

Was it set that way or did you change it after we emailed yesterday? Please check it after a fresh boot.

Thanks, Steve

On 1/17/2018 9:24 AM, David wrote:

timer is 1

Pi 3 NWdigital dongle raspbian

 

On Wed, Jan 17, 2018 at 8:14 AM, Steve N4IRS <szingman@...> wrote:

We have been working on the next revision of Analog_Bridge. Along with adding features and refining settings, we are trying to squash bugs. While testing the NWDigital DV300u (ThumbDV) we encountered a problem with data transfer . Some of the packets were not being processed in the required window. The NWD DV3000u uses a FTDI chip to communicate with the host computer. Under Linux, or at least Debian the driver is the FTDI serial. On the machine under test, a older Dell 2950 with more then enough horsepower and no history of issues with USB, we were not getting data in a timely manner. There is a value that can be adjusted to resolve this. /sys/bus/usb-serial/devices/ttyUSB0/latency_timer. The default looks to be 16. The 2950 was set at 16. So far so good. Well, I have a machine running a full time DMR <---> D-Star bridge using two of the DV3000u. When I checked the latency_timer, it was set to 1. Huh? I know I did not change it.

I am asking everybody that is using a DV3000 and a FTDI chip to test with the device plugged in. As root: cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer. Please report the result here. We have multiple ways to set this to what we want, but for now, All I want to know is what hardware / software you are running and the value.

Thanks, Steve

 

 

 

 

 

 

 


Re: Request for information

G7RPG - Peter Kendall
 

Steve,

My asl box running Analog_Bridge is Debain 8.9 VM on ESX 6.5 (i5 3570K) the value of latency_timer is 1


[    5.343999] usbcore: registered new interface driver ftdi_sio
[    5.344007] usbserial: USB Serial support registered for FTDI USB Serial Device
[    5.344032] ftdi_sio 1-2.2:1.0: FTDI USB Serial Device converter detected
[    5.344049] usb 1-2.2: Detected FT-X
[    5.344050] usb 1-2.2: Number of endpoints 2
[    5.344052] usb 1-2.2: Endpoint 1 MaxPacketSize 64
[    5.344053] usb 1-2.2: Endpoint 2 MaxPacketSize 64
[    5.344054] usb 1-2.2: Setting MaxPacketSize 64



Peter


On 17/01/18 14:14, Steve N4IRS wrote:
We have been working on the next revision of Analog_Bridge. Along with adding features and refining settings, we are trying to squash bugs. While testing the NWDigital DV300u (ThumbDV) we encountered a problem with data transfer . Some of the packets were not being processed in the required window. The NWD DV3000u uses a FTDI chip to communicate with the host computer. Under Linux, or at least Debian the driver is the FTDI serial. On the machine under test, a older Dell 2950 with more then enough horsepower and no history of issues with USB, we were not getting data in a timely manner. There is a value that can be adjusted to resolve this. /sys/bus/usb-serial/devices/ttyUSB0/latency_timer. The default looks to be 16. The 2950 was set at 16. So far so good. Well, I have a machine running a full time DMR <---> D-Star bridge using two of the DV3000u. When I checked the latency_timer, it was set to 1. Huh? I know I did not change it.

I am asking everybody that is using a DV3000 and a FTDI chip to test with the device plugged in. As root: cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer. Please report the result here. We have multiple ways to set this to what we want, but for now, All I want to know is what hardware / software you are running and the value.

Thanks, Steve

 


Re: Request for information

David KE6UPI
 

No it didn't. Could I (we) have received a bad batch of DV3000u? ASL to DMR sounds great. DMR to ASL is choppy. 

David



--
Thanks, David

"Laws that forbid the carrying of arms...disarm only those who are neither inclined nor determined to commit crimes. Such laws make things worse for the assaulted and better for the assailants; they serve rather to encourage than prevent homicides, for an unarmed man may be attacked with greater confidence than an armed one."
Thomas Jefferson

On Wed, Jan 17, 2018 at 7:09 AM, Steve N4IRS <szingman@...> wrote:
Both interesting bits of info.
Did changing to 1 improve the audio quality?

Thanks

On 1/17/2018 9:50 AM, David KE6UPI wrote:
After your email yesterday. I changed it to 1 from 16. It stays at 1 after reboots.

David



--
Thanks, David

"Laws that forbid the carrying of arms...disarm only those who are neither inclined nor determined to commit crimes. Such laws make things worse for the assaulted and better for the assailants; they serve rather to encourage than prevent homicides, for an unarmed man may be attacked with greater confidence than an armed one."
Thomas Jefferson

On Wed, Jan 17, 2018 at 6:33 AM, Steve N4IRS <szingman@...> wrote:
Was it set that way or did you change it after we emailed yesterday? Please check it after a fresh boot.

Thanks, Steve

On 1/17/2018 9:24 AM, David wrote:
timer is 1
Pi 3 NWdigital dongle raspbian

On Wed, Jan 17, 2018 at 8:14 AM, Steve N4IRS <szingman@...> wrote:
We have been working on the next revision of Analog_Bridge. Along with adding features and refining settings, we are trying to squash bugs. While testing the NWDigital DV300u (ThumbDV) we encountered a problem with data transfer . Some of the packets were not being processed in the required window. The NWD DV3000u uses a FTDI chip to communicate with the host computer. Under Linux, or at least Debian the driver is the FTDI serial. On the machine under test, a older Dell 2950 with more then enough horsepower and no history of issues with USB, we were not getting data in a timely manner. There is a value that can be adjusted to resolve this. /sys/bus/usb-serial/devices/ttyUSB0/latency_timer. The default looks to be 16. The 2950 was set at 16. So far so good. Well, I have a machine running a full time DMR <---> D-Star bridge using two of the DV3000u. When I checked the latency_timer, it was set to 1. Huh? I know I did not change it.

I am asking everybody that is using a DV3000 and a FTDI chip to test with the device plugged in. As root: cat /sys/bus/usb-serial/devices/ttyUSB0/latency_timer. Please report the result here. We have multiple ways to set this to what we want, but for now, All I want to know is what hardware / software you are running and the value.

Thanks, Steve

 





9061 - 9080 of 9820