Date   

Re: DVMega AMBE3000

Steve N4IRS
 

Matthew,
I do not know of anyone that has tried it. Yes, you should be OK if you can talk to the the AMBE chip. AMBEtest4.py should work.

Steve

On 08/20/2017 03:34 PM, Matthew 2E0SIP wrote:

Hi All,

Does anyone know if the DVMEGA AMBE3000 boards will work with Analog_Bridge?

If it's untested, what does the AMBE3000 board need to expose to Analog_Bridge in order to work? The raw serial interface from the AMBE chip? 

Thanks

Matthew
2E0SIP



DVMega AMBE3000

Matthew 2E0SIP
 

Hi All,

Does anyone know if the DVMEGA AMBE3000 boards will work with Analog_Bridge?

If it's untested, what does the AMBE3000 board need to expose to Analog_Bridge in order to work? The raw serial interface from the AMBE chip? 

Thanks

Matthew
2E0SIP


DMRLink and HBlink repositories.

Steve N4IRS
 

Over the last week or so, we have noticed a few misconceptions in the structure of the repositories. GitHub allows for multiple branches in a repository. In the case of DMRlink, when you look at the https://github.com/n0mjs710/DMRlink you are looking at the master. For the most part in a perfect world, the master should be pristine. What I mean to say is changes are rare and should be vetted before they are applied to the master. When we want to do a bugfix or add a feature, we add a branch. The new branch starts out as a clone of the master. From there, we start making changes, additions etc. This way people can use the Master branch with some certainty that the code us not changing under them. Every change that is made to the new branch is tracked against the master. Once we have tested the changes and are happy with the results, the changes are merged back into the master. Two things to understand, nothing requires repository management HAS to be done this way and my explanation is rather simplistic. Since the new branch was cloned from the master, it's possible that more then one program has been changed or added. The thing to remember is that within a branch, everything is supposed to work together.

When we built HB_Bridge and IPSC_Bridge, that was the case. The new branches started as a clone of the master. Programs other then HB_Bridge and IPSC_Bridge may have been changed. With out looking at the "commits" or doing a compare of every file within the branches, you do not know what your are going to get. For that reason, you should checkout or "clone" the complete branch. Do not pick and choose from multiple branches. Yes, it MAY work, or it may not. Troubleshooting a mix and match of multiple branches can be time consuming and frustrating. If you want the bug fix or feature of a branch, clone the whole branch. For example to clone the IPSC_Bridge branch of DMRlink, at the Linux command prompt "git clone -b IPSC_Branch https://github.com/n0mjs710/DMRlink.git YourDirectoryName" This will download the IPSC_Branch into a new directory called "YourDirectoryName". You are now assured that the programs work together. IPSC_Bridge.py depends on dmrlink.py etc.

We have held off merging the HB_Bridge and IPSC_Bridge branches back into the master branch. Since these were significant changes, we wanted to wait and debug before the merge. We will start merging soon so that we can start simplifying and adding features.

73, Steve N4IRS      


Status update and welcome.

Steve N4IRS
 

Well,
It's been a few weeks and things seem to be going well. Mike and I are taking a break from DMR and D-Star for a few weeks. We feel we just want to "let it breath, like good wine" for a little while to see if any bugs shake out. We we go back we will squash those bugs and start merging back into the master repositories for DMRlink and HBlink. We also added the ability to build a analog <---> D-Star bridge or a DMR <---> D-Star bridge with modifications to DummyRepeater from G4KLX.  Please post your questions and problems. We  plan to work on the installers and hope to make things easier for people to install and update Analog_Bridge, DMRlink and HBlink.

We are up to 64 members of the forum. If you are new or have not done it yet, PLEAS add you first name and callsign to your groups.io account. It makes it so much nicer when we know who everybody is.

73, Steve N4IRS


Re: Best practice to bridge with IPSC2 or cBridge

Themis Floros SV4QXF
 

It's possible to post same example confing, i use hblink before re-starting the project again and i am confused with IPSC_Bridge and HB_Bridge.

Thanks a lot


Re: Best practice to bridge with IPSC2 or cBridge

Cort N0MJS <n0mjs@...>
 

You’re 1.37 tries ahead of me.

On Aug 2, 2017, at 12:37 PM, Steve N4IRS <szingman@...> wrote:

It only to me 2.5 tries.

On 8/2/2017 1:36 PM, Cort N0MJS wrote:
Steve’s got it right – if there are more IPSC connections, use confbridge on the DMRlink (IPSC) side… if there are more MMDVM connections, use hb_confbridge on the HBLink side. Avoid using BOTH if you can. Just a lot easier!

On Aug 2, 2017, at 6:01 AM, Steve N4IRS <szingman@...> wrote:

[Edited Message Follows]

I rethought this. The choice of DMRlink confbridge or HBlink confbridge depends on the number of "networks" involved.
If you have 4 different MMDVMHosts that need to connect to each other and 1 c-Bridge, use HBLink confbridge.
  MMDVM <---> hb_confbridge  <---> HB_Bridge <---> IPSC_Bridge <---> c-Bridge
Steve

On 08/02/2017 06:23 AM, Themis Floros SV4QXF wrote:
Steve the public TGID's is comming from cBridge .

Thanks

--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206







--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206






Re: Best practice to bridge with IPSC2 or cBridge

Steve N4IRS
 

It only to me 2.5 tries.

On 8/2/2017 1:36 PM, Cort N0MJS wrote:
Steve’s got it right – if there are more IPSC connections, use confbridge on the DMRlink (IPSC) side… if there are more MMDVM connections, use hb_confbridge on the HBLink side. Avoid using BOTH if you can. Just a lot easier!

On Aug 2, 2017, at 6:01 AM, Steve N4IRS <szingman@...> wrote:

[Edited Message Follows]

I rethought this. The choice of DMRlink confbridge or HBlink confbridge depends on the number of "networks" involved.
If you have 4 different MMDVMHosts that need to connect to each other and 1 c-Bridge, use HBLink confbridge.
  MMDVM <---> hb_confbridge  <---> HB_Bridge <---> IPSC_Bridge <---> c-Bridge
Steve

On 08/02/2017 06:23 AM, Themis Floros SV4QXF wrote:
Steve the public TGID's is comming from cBridge .

Thanks

--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206







Re: Best practice to bridge with IPSC2 or cBridge

Cort N0MJS <n0mjs@...>
 

Steve’s got it right – if there are more IPSC connections, use confbridge on the DMRlink (IPSC) side… if there are more MMDVM connections, use hb_confbridge on the HBLink side. Avoid using BOTH if you can. Just a lot easier!

On Aug 2, 2017, at 6:01 AM, Steve N4IRS <szingman@...> wrote:

[Edited Message Follows]

I rethought this. The choice of DMRlink confbridge or HBlink confbridge depends on the number of "networks" involved.
If you have 4 different MMDVMHosts that need to connect to each other and 1 c-Bridge, use HBLink confbridge.
  MMDVM <---> hb_confbridge  <---> HB_Bridge <---> IPSC_Bridge <---> c-Bridge
Steve

On 08/02/2017 06:23 AM, Themis Floros SV4QXF wrote:
Steve the public TGID's is comming from cBridge .

Thanks

--
Cort Buffington
H: +1-785-813-1501
M: +1-785-865-7206






Re: Best practice to bridge with IPSC2 or cBridge

Themis Floros SV4QXF
 

Nice! Thank you for your time...i will share results with us

73 SV4QXF


Re: Best practice to bridge with IPSC2 or cBridge

Steve N4IRS
 
Edited

I rethought this. The choice of DMRlink confbridge or HBlink confbridge depends on the number of "networks" involved.
If you have 4 different MMDVMHosts that need to connect to each other and 1 c-Bridge, use HBLink confbridge.
  MMDVM <---> hb_confbridge  <---> HB_Bridge <---> IPSC_Bridge <---> c-Bridge
Steve

On 08/02/2017 06:23 AM, Themis Floros SV4QXF wrote:
Steve the public TGID's is comming from cBridge .

Thanks


Re: Best practice to bridge with IPSC2 or cBridge

Steve N4IRS
 

The you have no choice but to use DMRlink. Setup confbridge in DMRlink to bridge the TG you want to send to the c-Bridge and use MMDVM <---> HB_Bridge <---> IPSC_Bridge <---> confbridge to add MMDVM.

Steve

On 08/02/2017 06:23 AM, Themis Floros SV4QXF wrote:
Steve the public TGID's is comming from cBridge .

Thanks


Re: Best practice to bridge with IPSC2 or cBridge

Themis Floros SV4QXF
 

Steve the public TGID's is comming from cBridge .

Thanks


Re: Best practice to bridge with IPSC2 or cBridge

Steve N4IRS
 

Hi,
I assume from your message, the public TGs are BrandMeister. If that's the case, HBlink works quite well. I would use confbridge and define those TGs you want to send to BM.

73, Steve N4IRS

On 08/02/2017 05:01 AM, Themis Floros SV4QXF wrote:
Hello Guys , i need some help with best practice to connect HBlink to IPSC2 or cBridge, is better is use CC bridge or homebrew?, for the history i try with homebrew and IPSC2 and take loops!. The resault of all this is to make a like MMDVM server with some isolted TG's and some public TG's .

Please give ideas.
SV4QXF


Best practice to bridge with IPSC2 or cBridge

Themis Floros SV4QXF
 

Hello Guys , i need some help with best practice to connect HBlink to IPSC2 or cBridge, is better is use CC bridge or homebrew?, for the history i try with homebrew and IPSC2 and take loops!. The resault of all this is to make a like MMDVM server with some isolted TG's and some public TG's .

Please give ideas.
SV4QXF


Re: AllStar to D-Star D-Star to DMR

Steve N4IRS
 

Stock DummyRepeater only knows how to talk the a sound card. The modification adds the ability for DummyRepeater to talk to Analog_Bridge or AllStarLink.

Steve

On 8/1/2017 11:52 AM, david bencini wrote:
Hi Steve, thank you !

Only 1 thing :

>You will need to modify DummyRepeater and recompile it.

Why ? i missed it ....

73

d.


2017-08-01 15:18 GMT+02:00 Steve N4IRS <szingman@...>:
David,
It looks like you are most of the way there. You are going to need to use a MMDVM or Motorola Repeater. We do not have support for Hytera. Here is a basic diagram:
MMDVM <---> HB_Bridge <---> Analog_Bridge <---> DummyRepeater <---> ircDDBGateway <-D-Star Network

Analog_Bridge and DummyRepeater each need a DV3000 (AMBEServer) you will need them on different ports. I suggest a powered Hub for 1 of the DV3000s.

HB_Bridge is at: <https://github.com/n0mjs710/HBlink/tree/HB_Bridge> Make sure you clone the HB_Bridge branch.
Analog_Bridge is at: <https://github.com/N4IRS/Analog_Bridge> Use the proper executable for your processor. For a Pi it is Analog_Bridge.ARM rename it to Analog_Bridge
You will need to modify DummyRepeater and recompile it. The changed file is at <https://github.com/N4IRS/Analog_Bridge/tree/master/DummyRepeater>

73, Steve N4IRS

On 8/1/2017 6:42 AM, david bencini wrote:
Hi Steve, your post is very interesting !

I currently have a configured system: RTX Retevis RT3 DMR connected to an URIx interface (with small circuit to have the COS signal). This interface is connected to a raspberry that runs a server ambe (a USB thumbDV is inserted) and dummyrepeater software and ircddbgateway for connection to a dstar reflector. These links between DMR and DSTAR work well, but it has a part in RF to a DMR repeater.

How can I manage everything via software only (w/out RTX)?

I have two ThumbDV 3000 usb dongle, raspberrys, hytera repeater, mmdvm repeaters, etc. So I can try any configuration.

The ideal would be: to connect the hytera dmr repeater (or mmdvm repeater ) to a server (which software must i to use?) Then process the audio datas (with the software / server (ambe server) ?) And finally send it to a dstar reflector server module. For example XLX or XRFor directly to a dstar repeater running ircddbgateway). Can you advise me a few possibilities? Do you have a software that allows you to connect dmr repeaters and send streams to a server somewhere?

Thank you

David IK5XMK




Re: AllStar to D-Star D-Star to DMR

david bencini ik5xmk
 

Hi Steve, thank you !

Only 1 thing :

>You will need to modify DummyRepeater and recompile it.

Why ? i missed it ....

73

d.


2017-08-01 15:18 GMT+02:00 Steve N4IRS <szingman@...>:

David,
It looks like you are most of the way there. You are going to need to use a MMDVM or Motorola Repeater. We do not have support for Hytera. Here is a basic diagram:
MMDVM <---> HB_Bridge <---> Analog_Bridge <---> DummyRepeater <---> ircDDBGateway <-D-Star Network

Analog_Bridge and DummyRepeater each need a DV3000 (AMBEServer) you will need them on different ports. I suggest a powered Hub for 1 of the DV3000s.

HB_Bridge is at: <https://github.com/n0mjs710/HBlink/tree/HB_Bridge> Make sure you clone the HB_Bridge branch.
Analog_Bridge is at: <https://github.com/N4IRS/Analog_Bridge> Use the proper executable for your processor. For a Pi it is Analog_Bridge.ARM rename it to Analog_Bridge
You will need to modify DummyRepeater and recompile it. The changed file is at <https://github.com/N4IRS/Analog_Bridge/tree/master/DummyRepeater>

73, Steve N4IRS

On 8/1/2017 6:42 AM, david bencini wrote:
Hi Steve, your post is very interesting !

I currently have a configured system: RTX Retevis RT3 DMR connected to an URIx interface (with small circuit to have the COS signal). This interface is connected to a raspberry that runs a server ambe (a USB thumbDV is inserted) and dummyrepeater software and ircddbgateway for connection to a dstar reflector. These links between DMR and DSTAR work well, but it has a part in RF to a DMR repeater.

How can I manage everything via software only (w/out RTX)?

I have two ThumbDV 3000 usb dongle, raspberrys, hytera repeater, mmdvm repeaters, etc. So I can try any configuration.

The ideal would be: to connect the hytera dmr repeater (or mmdvm repeater ) to a server (which software must i to use?) Then process the audio datas (with the software / server (ambe server) ?) And finally send it to a dstar reflector server module. For example XLX or XRFor directly to a dstar repeater running ircddbgateway). Can you advise me a few possibilities? Do you have a software that allows you to connect dmr repeaters and send streams to a server somewhere?

Thank you

David IK5XMK



Re: DV3000 testing results

David KE6UPI
 

Hello Steve, I ran your test for the DV3000u on my pi 2. I got to the end and get Error count = 0. I'm good right?

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, Jul 12, 2017 at 12:33 PM, Steve N4IRS <szingman@...> wrote:
We have spent the last couple of weeks working with the DV3000u and below are our results.

This what we sent to NorthWest Digital

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

  • Hardware under test
    • DV3000U set up as direct serial and AMBEServer configurations (at least 4 devices have been tested)
    • X86 based computers (Linux, OSX)
    • ARM based computers (Raspian, Comapss, Armbian)
    • Power supplies
      • Anker 60 watt multi-port supply
      • Power cube with 1.35A @ 5V output
      • X86 using internal PS
  • Test scenarios
    • Run a python test application designed to exercise and test returned results
    • Application is run on X86 machines and ARM based machines with both power supply configurations
    • Test loops are run from between 10,000 or greater passes
    • Each pass both encodes and decodes AMBE frames
    • Tests may be run with the command line
  • Test results
    • X86 
      • All tests perform as expected, both serial and AMBEServer pass
    • ARM
      • Using the Anker 60W PS all tests pass
      • Using the Anker PS with a short USB extension, tests fail
      • Using the smaller PS tests fail (expected)
    • Observations
      • The failure mode is consistent, the device will reset when under load
      • We see the PKT_READY frame returned from the DV3000 whenever the device fails
        • The frame 61 00 01 00 39 is documented in the AMBE3000 reference as PKT_READY
        • The doc states that this frame is produced when ever the device undergoes a hardware reset
      • Failure happens on either AMBE -> PCM or PCM -> AMBE
      • We see no indication of any serial data loss
        • No data corruption
        • No data loss, all data is sent and received
      • The short jumper is of good gauge wire and shows no observable damage 
  • Conclusions
    • The DV3000u will run fine on x86 and SBC machines provided that
      • USB power is sufficient to keep the dongle running
      • Under load, the power may dip causing an install that seems good to fail
      • The reset is clean, leading me to think that the TI TPS3805 is doing the reset, not the AMBE3000 itself
      • You are welcome to use the AMBETest4.py app, add to it, etc as needed.
      • You should make your customers keenly aware that all PS are not created equal and care must be exercised.
      • We have modified our Analog_Bridge application to sense this reset and output error messages in the log

 Two additional pieces of information.
I have a Pi2 that has the PiDV installed running Raspbian. All test pass on the PiDV
I added a ThumbDV to the same board and ran the test against the ThumbDV

root@pi-star(ro):DV3000# python AMBEtest4.py -v -e -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
*********************
Testing Reset DV3000
Test result: Success (6100010039)
Testing Get Product ID
Test result: Success (61000b0030414d4245333030305200)
Testing Get Version
Test result: Success (6100310031563132302e453130302e585858582e433130362e473531342e523030392e42303031303431312e433030323032303800)
Testing Set DSTAR Mode
Test result: Success (610002000a00)
Testing Reset DV3000
Test result: Success (6100010039)
Testing Set DMR Mode
Test result: Success (610002000a00)
Testing Decode AMBE
Test result: Success (6100010039)
Error, the DV3000 has unexpectly reset
root@pi-star(ro):DV3000#

I moved the DV3000u to a D-Link powered hub. I ran AMBEtest4.py for 100,000 iterations.
All tests pass.

---
"What are HB_Bridge, IPSC_Bridge and Analog_Bridge?" 



Re: AllStar to D-Star D-Star to DMR

Steve N4IRS
 

David,
It looks like you are most of the way there. You are going to need to use a MMDVM or Motorola Repeater. We do not have support for Hytera. Here is a basic diagram:
MMDVM <---> HB_Bridge <---> Analog_Bridge <---> DummyRepeater <---> ircDDBGateway <-D-Star Network

Analog_Bridge and DummyRepeater each need a DV3000 (AMBEServer) you will need them on different ports. I suggest a powered Hub for 1 of the DV3000s.

HB_Bridge is at: <https://github.com/n0mjs710/HBlink/tree/HB_Bridge> Make sure you clone the HB_Bridge branch.
Analog_Bridge is at: <https://github.com/N4IRS/Analog_Bridge> Use the proper executable for your processor. For a Pi it is Analog_Bridge.ARM rename it to Analog_Bridge
You will need to modify DummyRepeater and recompile it. The changed file is at <https://github.com/N4IRS/Analog_Bridge/tree/master/DummyRepeater>

73, Steve N4IRS

On 8/1/2017 6:42 AM, david bencini wrote:
Hi Steve, your post is very interesting !

I currently have a configured system: RTX Retevis RT3 DMR connected to an URIx interface (with small circuit to have the COS signal). This interface is connected to a raspberry that runs a server ambe (a USB thumbDV is inserted) and dummyrepeater software and ircddbgateway for connection to a dstar reflector. These links between DMR and DSTAR work well, but it has a part in RF to a DMR repeater.

How can I manage everything via software only (w/out RTX)?

I have two ThumbDV 3000 usb dongle, raspberrys, hytera repeater, mmdvm repeaters, etc. So I can try any configuration.

The ideal would be: to connect the hytera dmr repeater (or mmdvm repeater ) to a server (which software must i to use?) Then process the audio datas (with the software / server (ambe server) ?) And finally send it to a dstar reflector server module. For example XLX or XRFor directly to a dstar repeater running ircddbgateway). Can you advise me a few possibilities? Do you have a software that allows you to connect dmr repeaters and send streams to a server somewhere?

Thank you

David IK5XMK


Re: AllStar to D-Star D-Star to DMR

david bencini ik5xmk
 

Hi Steve, your post is very interesting !

I currently have a configured system: RTX Retevis RT3 DMR connected to an URIx interface (with small circuit to have the COS signal). This interface is connected to a raspberry that runs a server ambe (a USB thumbDV is inserted) and dummyrepeater software and ircddbgateway for connection to a dstar reflector. These links between DMR and DSTAR work well, but it has a part in RF to a DMR repeater.

How can I manage everything via software only (w/out RTX)?

I have two ThumbDV 3000 usb dongle, raspberrys, hytera repeater, mmdvm repeaters, etc. So I can try any configuration.

The ideal would be: to connect the hytera dmr repeater (or mmdvm repeater ) to a server (which software must i to use?) Then process the audio datas (with the software / server (ambe server) ?) And finally send it to a dstar reflector server module. For example XLX or XRFor directly to a dstar repeater running ircddbgateway). Can you advise me a few possibilities? Do you have a software that allows you to connect dmr repeaters and send streams to a server somewhere?

Thank you

David IK5XMK


AllStar to D-Star D-Star to DMR

Steve N4IRS
 

Since the introduction of a DMR to AllStarLink (ASL) bridge, we have been asked many times for a open source method to bridge ASL to D-Star. Yes, there is a channel driver included in ASL that does some of the work but it requires a closed source program. We felt that a open source solution was possible. The idea was to leverage existing open source programs to form the bridge between ASL and D-Star. ASL provides a channel driver that produces PCM from network or local audio in ASL. It also provides the signaling needed for COS and PTT. That channel driver is chan_usrp. This is the same channel driver we use for the ASL to DMR bridge(s). Why reinvent the wheel? Now we needed a open source method of sending and receiving audio to D-Star. Jonathan Naylor G4KLX as written a number for D-Star programs. One of them is DummyRepeater (DR). DR was built to take analog audio from a local mic, pass it to a Vocoder and on to the D-Star network(s) through ircDDBGateway. All we needed was a connection from ASL to DR. After looking at the code to DR, Mike N4IRR determined only one module in DR needed to be modified. That module is DummyRepeaterThread.cpp. Everything needed to communicate with ASL was in there. Audio in and out, signaling and MetaData. Modifications were made and DR was recompiled. Mike tested on a x86 machine and I tested on a Raspberry Pi.

DR did not include a daemon version. The program required that a GUI be displayed. The GUI does nothing, but it had to display somewhere. Enter xvfb, a virtual frame buffer. DR can display to xvfb. No need to see the output, just give it a place to go. DR also requires a sound device. In the case of the RPi you have 2 choices, add a simple USB sound device that will never be used or a dummy sound device. Add snd-dummy to /etc/modules and reboot or run modprobe snd-dummy. DR is now happy. One of the things we have found is on a Pi where there is no mic input so snd-dummy was used, you can hear a slight tail in the D-Star output. Adding a cheap USB sound device solve that. We are looking into a solution.

Now that DR "speaks USRP" it can connect to another DVSwitch partner. Analog_Bridge (AB) also "speaks USRP" Consider this, AB partners with either HB_Bridge (HB) ir IPSC_Bridge (IB) AB uses a DV3000 to convert AMBE from HB or IB to USRP. You can build a basic bridge from DMR to D-Star using AB and DR. Yes you need 2 Vocoders. One for AB and a second for DR. This can be a MMDVM with HB or a Motorola Repeater with IB. I'll leave other permutations to your imagination. Since both DMR and D-Star have metadata associated with each transmission we decided to pass that metadata between the 2 networks where possible. An inbound transmission from D-Star contains a callsign, that call sign is used to check for a matching call and DMR ID. If found the DMR ID is passed through AB to the DMR network. This is visible as a DMR ID on a user radio or network dashboard. From DMR to D-Star, we decided to put the call, TG and TS into the info field sent to the D-Star network. This is configurable and can be turned of if not desired. for the last 5 days I have been bridging DMR to D-Star on reflector DCS006T.

Just to be clear, this is NOT D-Star_Bridge. That will come later. The changes to DR were pretty simple and it gave us a working solution. Is it scalable? No, not really. Is it stable? Yes, seems so to us. Now is the time for others to try it out and provide feedback. That is why we are now calling it beta. No, there is not script to install it. No, there is no image to pop into your Pi. This is code pure and simple. Everything we have done with DVSwitch has been a module to do a task. Combined with DMRlink and HBlink you can do some interesting and useful things. The source to DummyRepeaterThread.cpp and my notes on building the bridge are at <https://github.com/N4IRS/Analog_Bridge> in the DummyRepeater directory.

For DVSwitch,
73, Steve N4IRS and Mike, N4IRR

--
"What are HB_Bridge, IPSC_Bridge and Analog_Bridge?"

9781 - 9800 of 10158