Date   
Re: RF access point application confirmation

Mathison Ott <mathisono@...>
 

I just wanted add that I be purchasing one !

On Feb 2, 2015 10:56 AM, "'Michael E Fox - N6MEF' n6mef@... [UniversalDigitalRadio]" <UniversalDigitalRadio@...> wrote:
 

Richard,

 

I don’t disagree with what you’re saying COULD BE the future.  Indeed, the UDR is great because of the stuff that MAY come later. 

 

But that’s betting on the come.  And the problem with that is that the radio has been “about to ship” for at least a year now, and yet still, there is evidently no one working on the high speed modem function.  (If there was, I expect we would have heard them say something by now). 

 

No, the hardware does NOT have to be built before the software can be started.  That’s the whole point of building on an open platform.   As just one example, Juniper built the entire JUNOS operating system, routing protocols, user interface, logging, diagnostics, etc., before it had a single piece of hardware built.  After that, it was a matter of the drivers for the particular serial or Ethernet or optical cards.  We did the same thing at my last startup.  The developers built the overall functionality, and then plugged in the specific API calls for each new card as it came out.  In fact, the reason I have asked more than once about what test capabilities will be available is because that data needs to be available from the hardware via an API, and that’s something the NWDR guys will need to provide to developers.  But answers there haven’t been very clear either, indicating that it’s still not defined and, at this late stage, it’s evidently not a priority.

 

So, maybe there is a large enough market of folks who want to buy this to tinker with in their garage.  But for someone who has been talking this up as a potential real-world, deployable solution for a couple of years now, it’s very concerning that work has not already begun on the one thing that will make the UDR different from what we already have now:  the high speed modem. 

 

Michael

N6MEF

 

Re: RF access point application confirmation

"Michael E Fox - N6MEF" <n6mef@...>
 

Richard,

 

I don’t disagree with what you’re saying COULD BE the future.  Indeed, the UDR is great because of the stuff that MAY come later. 

 

But that’s betting on the come.  And the problem with that is that the radio has been “about to ship” for at least a year now, and yet still, there is evidently no one working on the high speed modem function.  (If there was, I expect we would have heard them say something by now). 

 

No, the hardware does NOT have to be built before the software can be started.  That’s the whole point of building on an open platform.   As just one example, Juniper built the entire JUNOS operating system, routing protocols, user interface, logging, diagnostics, etc., before it had a single piece of hardware built.  After that, it was a matter of the drivers for the particular serial or Ethernet or optical cards.  We did the same thing at my last startup.  The developers built the overall functionality, and then plugged in the specific API calls for each new card as it came out.  In fact, the reason I have asked more than once about what test capabilities will be available is because that data needs to be available from the hardware via an API, and that’s something the NWDR guys will need to provide to developers.  But answers there haven’t been very clear either, indicating that it’s still not defined and, at this late stage, it’s evidently not a priority.

 

So, maybe there is a large enough market of folks who want to buy this to tinker with in their garage.  But for someone who has been talking this up as a potential real-world, deployable solution for a couple of years now, it’s very concerning that work has not already begun on the one thing that will make the UDR different from what we already have now:  the high speed modem. 

 

Michael

N6MEF

 

Re: RF access point application confirmation

myyahoo@...
 

56 kbps radios have existed since the mid '90s. I have one.

However, it requires infrastructure to operate - a full duplex 56 k repeater. Vancouver had two running, but I moved to San Jose in 1998, so my 56 k radio is no longer useful (I'm using some of its parts for non-digital purposes). The radio has a hardware modem that plugs into an ISA slot on a PC (soooo last millenium!) and is built in hardware so it can't be reprogrammed on a whim.

The UDRF is an open source, frequency-agile, protocol-agile SDR for 70 cm. Out-of-the-box it will talk 9600 since software already exists to do that, but it will be a community effort to get high speed data going on it - the hardware has to be built before the software can be developed.

Bryan and others are putting a lot of resources into getting a solid, agile, SDR platform on which to develop the software. Once the hardware is out-the-door, it won't be that long before you'll see higher speed software appear - maybe for several different protocols - as we discover what works, which may not be the same for all environments. Repeaters will not be needed, although still possible as part of a mesh network - look ma, no cavities! - by putting a station in a prominent location.

This radio will not be just a '9600 bps radio on steroids'. When I first heard about the project, I wasn't that enthusiastic, that's what it sounded like. However, this is a lot more - think multi-channel, dynamic bandwidth meshed networking that utilises spectrum in an intelligent fashion. This doesn't have to be a single, wide channel, but can be multiple subchannels that are continuously reallocated for multiple purposes and protocols. The first high speed data protocol will likely be a 56 k, wide band simplex effort - but that will be just the beginning, we really didn't need SDR to do that. It's not an efficient use of the channel, and throughput will suffer due to the packet size vs turnaround time - but it will be faster than 9600, and will grow to the more sophisticated protocols, and speeds not limited to 56 k, in a fairly short timeframe. I may have to make trips back to Canada for some of my experimentation or operate my station remotely - the radio regulations are much less rigid than in the US.

I was part of the beginings of Amateur Packet Radio in Vancouver in 1978, and I'm looking forward to being part of the next generation of high speed packet radio as we develop it here!

- Richard, VE7CVS

Re: RF access point application confirmation

Michael E Fox - N6MEF <n6mef@...>
 

Uhm, well, 9600 440 radios exist today (and most have higher power, too).   Small, 12V linux machines also exist ( and can be configured with more memory, dual disks, more ports, etc., if desired).  And folks have the applications that were listed running today (at 9600).  So without a higher speed radio, I honestly don't see what the UDR enables that isn't already possible today.  What we're all missing is the high speed radio.

Michael
N6MEF


Sent from my Verizon Wireless 4G LTE smartphone


-------- Original message --------
From: "ve7dhm@... [UniversalDigitalRadio]"
Date:02/01/2015 11:26 AM (GMT-08:00)
To: UniversalDigitalRadio@...
Subject: RE: [UniversalDigitalRadio] Re: RF access point application confirmation

 

Amateur Radio is about experimentation and learning, applying new technologies and applications and at the same time having some fun doing all this.  The Amateur Radio VHF / UHF packet radio technology has been stagnate far too long regarding providing higher data rates and error correcting protocols.  Although I hope the 56K capability of the UDRX is real world capable I would gladly welcome a UDRX 9600 radio / modem upgrade at this time.  If the UDRX design and testing is done then get it out on the street so that the play time can begin.  Application developers and support groups will follow along as the UDRX is deployed in the real world of users.  Since Canada is regulated by bandwidth hopefully some high speed data protocols and applications will be developed following the UDRX production release and hands-on experience.

Paul VE7DHM

Fw: 2015 MicroHams Digital Conference, Redmond, WA, Saturday, 3/21

Mark Thompson <wb9qzb_groups@...>
 


----- Forwarded Message -----
From: Philip Moscinski
To: Mark Thompson Sent: Sunday, February 1, 2015 3:08 PM
Subject: 2015 MicroHams Digital Conference

MicroHams has just opened up on-line registration for our Digital Conference (MHDC).   

Thanks for all your help in the past in getting the word out for the Digital Conference.  

Anything you can do to get this in the right hands would be appreciated!


Saturday, March 21


MicroHams Digital Conference.  Redmond, WA.  
This is an ARRL sanctioned event.  


This event draws Hams from all over the Northwest as well as other parts of the country!  
Our conference blog which is linked on our home page gives details on past and present conferences.

Best Regards & 73's
Phil Moscinski N2EU
President MicroHams ARC 




Re: RF access point application confirmation

ve7dhm@...
 

Amateur Radio is about experimentation and learning, applying new technologies and applications and at the same time having some fun doing all this.  The Amateur Radio VHF / UHF packet radio technology has been stagnate far too long regarding providing higher data rates and error correcting protocols.  Although I hope the 56K capability of the UDRX is real world capable I would gladly welcome a UDRX 9600 radio / modem upgrade at this time.  If the UDRX design and testing is done then get it out on the street so that the play time can begin.  Application developers and support groups will follow along as the UDRX is deployed in the real world of users.  Since Canada is regulated by bandwidth hopefully some high speed data protocols and applications will be developed following the UDRX production release and hands-on experience.

Paul VE7DHM

Re: RF access point application confirmation

myyahoo@...
 

This isn't a radio that's cast in stone when it leaves the factory.

It is a platform that will be used to develop the next generation of digital ham radio. It happens to include a lot of current modes in the form of already available software, but the best is yet to come - unlike a lot of manufacturer's radios, this one will be under continuous development. It won't have the occasional firmware update to patch a bug - it will be getting completely redeveloped over time. That's the wonder of SDR!

If you're not into developing SDR software - you'll still be able to take advantage of the software that the community produces. If you like to tinker with software, you can be on the forefront of this wave of technology and produce that software that everyone is using.

Another advantage of such a programmable radio is that it's possible to experiment with new modes and radio network topologies without new hardware, which has been a real millstone in the past. With SDR all of that becomes software that can be replaced on a whim.

- Richard VE7CVS

Re: RF access point application confirmation

Marshall Denny <MarshallDenny@...>
 

Sounds to me like he has a list of extra, very useful features he would like. 

Much of if not most of the long term features for the UDR is the duty of the ham community.

A useful product out of the box.
And stable reliable platform for software/protocol/mode development is what I am expecting.

I agree we need FEC early.

We need to start a feature list.  Prioritize our list. Find willing capable people. And get to work.



Respectfully,
Marshall Denny
Technical Architect, Contractor
AT&T
425 288 6443 office
206 842 9305 home
206 734 9242 cell

Politicians and diapers should be changed frequently and for the same reason.
-- unknown

Re: RF access point application confirmation

"Michael E Fox - N6MEF" <n6mef@...>
 

Thanks for the response Bryan.  Some follow-up questions/comments/suggestions and answers to your questions below.

 

From: UniversalDigitalRadio@... [mailto:UniversalDigitalRadio@...]
Sent: Friday, January 30, 2015 12:07 PM
To: UniversalDigitalRadio@...
Subject: RE: [UniversalDigitalRadio] Re: RF access point application confirmation

 

 

First, some things to understand.

 

The UDR is a network device implemented in Debian Linux. So it can do anything that a network device can do by configuring the network interfaces appropriately. It uses the Linux AX25 stack and also has support for the D-STAR DV and DD Protocols. You can install, configure and test any application software that you like. We will pre-install the most common apps.

O.K.  If I understand you correctly, the unit will NOT have its own user interface for configuring network functionality.  Users will need to be versed in how to configure the underlying linux functionality to perform bridging and/or routing functions.  And, since client units will likely need address assignment (DHCP) and all devices will need time (NTP) and possibly name service (DNS), the user will need to know how to configure all of those separate functions through the native linux commands.  Correct? 

Opinion:  For Debian linux server admins, that’s fine.  But “networking devices” have their own UI for configuring their capabilities.  For one example, Juniper routers run on BSD.  But I don’t need to issue a single ifconfig command.  I use their CLI and sometimes their web interface.  As another example, even a $70 Ubiquiti bullet gives me a simple pull-down menu to select Bridge vs. Router and other fill-in-the-blank or pull-down menus for configuring the details of each.  Without such an interface, the ability to deploy as an end-user device will be limited to those who want to (and have time and patience and knowledge to) tinker with linux.   

 

TCP/IP (IPAX) can run on AX25 and AX25 can be transported over the Internet (AXIP) it's maximally flexible, based on an understanding of network protocols and configuration under Linux.

O.K.  So, again, it sounds like if I need to do something simple like bridge two LANs over radio, I will need to know how to use native linux commands to configure Ethernet interfaces, radio interfaces, and tunnel interfaces (IP over AX25), protocols, default routes, NTP, etc., all with native linux commands.  Correct?

 

Let's start with the air interface. In the initial release the UDR has a MSK/GMSK Modem at the following rates

25kHz Channel Bandwidth:

* 4800 GMSK - D-STAR Compatible

* 9600 MSK - AX25 Packet Compatible

* 19200 MSK  - compatibility not guaranteed

100kHz Channel Bandwidth

* 56k MSK - compatibility not guaranteed

The 25/100 kHz bandwidths are the hardware filters and the DSP will narrow bandwidth for different data rates.  (e.g. 6.25 Khz in a 25 Khz 'channel' isn't very efficient)

Our modems are Open Source. We are in contact with a few modem experts about adding multi-bit per symbol and FEC. This work will be undertaken by the Amateur Community and coordinated through the ARETF.

O.K.  If I understand you correctly, there will be no FEC at first release and there is not yet a specific, committed, scheduled plan for FEC.  Correct?

As I’ve mentioned before on this list, we did a lot of testing of 9600 AX.25 (no FEC) under different signal strengths.  We found it is usable in clear paths, such as between mountain tops or between a clear site and a mountain top.  But suburban (20-50’ high antennas with 20-70’ buildings nearby) attempts to run 9600 baud AX.25 (with properly configured/calibrated radios) resulted in far too many retransmits (10-20 percent, more with more users) due to single bit errors in packets.  Certainly nothing faster is going to be truly viable in the ‘real world’ until FEC is available.  With nothing currently under test, and no specific plan, I’d speculate that we’re at least a year away from a FEC solution.  Is that your sense?

Also, I lost track of where the FCC stands on the symbol rate limitations.  What’s the latest on elimination of the symbol rate limitations in Part 97?  And, if those limitations are lifted, what’s the expected highest speed of the UDR?

 

We have tested the UDR with the following application SW and will provide a web interface for control. Anything you can do from the web interface you can also do from the command line. Set mode, frequency, power etc.

APRS Apps:

* APRX - Aprs IGate

* UDR Tracker - APRS Tracker with Messaging uses GPSd for a USB connected GPS

Winlink Apps:

* RMS GW Gateway for the Winlink Server

* You may use any POP3 or Imap Mail Client

BBS Apps:

* AX25 Call is working as a terminal BBS Client

* We have tested F6BBS as a server.

* We are investigating NNTP servers so you could use any Newsreader like Thunderbird to access the BBS.

D-STAR Apps:

* ircDDBGateway

* Dummy Repeater

O.K.  But we’re interested in a high-speed radio, not an application server.  As I mentioned we’re looking for high-speed 440 access to an existing network, with existing servers. 

 

Debugging:

 

For network configuration and troubleshooting all of the standard Linux tools and log-files are available.

OK

 

For the air interface, the modem provides a header with every received packet indicating signal quality. This is on the web interface as well as the log file.

OK.  But a per-packet signal quality is going to be hard to interpret as they are flying by.  I can’t imagine how that would be used in the real world unless it was perhaps graphed and some type of rolling average were shown. 

Suggestion:  A typical P25 or DMR analyzer provides a common set to tools to let you know very quickly what kind of signal you have and what kind of margin you have above the edge (constellation pattern, error rates, etc.).  These tools are pretty consistent across platforms. For example, I can get roughly the same information on a P25 or DMR signal from either an Anritsu LMR Master or an Aerofloex 3920.  I’m not a modulation expert, just a user of those two devices.  But presumably these tools are common because they are known to provide the info that technicians most need.  So it would make sense to provide something similar for whatever type of modulation the UDR uses.

 

If I understand your existing installation correctly, what you're referring to as an access point would be a BBS server that multiple clients would access.

No.  We already have a BBS and other servers.  We don’t need another server.  We need a high-speed radio/bridge/router.   

In my email I said “we would look to unplug an existing 440 radio with TNC from a BBS serial port and replace with the UDRX-440 connected to the same LAN as the BBSWe presume users would then telnet (and use other standard IP protocols) to the BBS, instead of their existing serial/AX.25 connection.”  Therefore, users connecting from the UDR on their LAN to the UDR on the network would be able to access the BBS and other servers on the network.  In other words, think of it as a Ubiquiti or Microtik bridge/router/radio combination, except running at 440 MHz.  In WiFi speak, that’s an access point. 

 

* The UDR can be accessed using SSH.

* The UDR can be configured as a layer 2 bridge. We will provide  a tested example.

* The UDR can be configured as a layer 3 router. We will provide  a tested example.

 

Did I miss anything?

What’s missing for us is the high-speed radio part.  I’d be very interested in a reasonable approximation of when we could see 56K (or higher) with FEC.

Michael

N6MEF

Re: RF access point application confirmation

John Ronan <jpronans@...>
 


On 30/01/15 20:07, bhhoyer@... [UniversalDigitalRadio] wrote:

First, some things to understand.


[SNIP]


Did I miss anything?

Bryan K7UDR


Shipping date ;)

HNY
John
EI7IG

Re: RF access point application confirmation

bhhoyer@...
 

First, some things to understand.


The UDR is a network device implemented in Debian Linux. So it can do anything that a network device can do by configuring the network interfaces appropriately. It uses the Linux AX25 stack and also has support for the D-STAR DV and DD Protocols. You can install, configure and test any application software that you like. We will pre-install the most common apps.


TCP/IP (IPAX) can run on AX25 and AX25 can be transported over the Internet (AXIP) it's maximally flexible, based on an understanding of network protocols and configuration under Linux.


Let's start with the air interface. In the initial release the UDR has a MSK/GMSK Modem at the following rates


25kHz Channel Bandwidth:


* 4800 GMSK - D-STAR Compatible

* 9600 MSK - AX25 Packet Compatible

* 19200 MSK  - compatibility not guaranteed


100kHz Channel Bandwidth


* 56k MSK - compatibility not guaranteed


The 25/100 kHz bandwidths are the hardware filters and the DSP will narrow bandwidth for different data rates.  (e.g. 6.25 Khz in a 25 Khz 'channel' isn't very efficient)

 

Our modems are Open Source. We are in contact with a few modem experts about adding multi-bit per symbol and FEC. This work will be undertaken by the Amateur Community and coordinated through the ARETF.


We have tested the UDR with the following application SW and will provide a web interface for control. Anything you can do from the web interface you can also do from the command line. Set mode, frequency, power etc.


APRS Apps:

* APRX - Aprs IGate

* UDR Tracker - APRS Tracker with Messaging uses GPSd for a USB connected GPS


Winlink Apps:

* RMS GW Gateway for the Winlink Server

* You may use any POP3 or Imap Mail Client


BBS Apps:

* AX25 Call is working as a terminal BBS Client

* We have tested F6BBS as a server.

* We are investigating NNTP servers so you could use any Newsreader like Thunderbird to access the BBS.


D-STAR Apps:

* ircDDBGateway

* Dummy Repeater

 

Debugging:


For network configuration and troubleshooting all of the standard Linux tools and log-files are available.


For the air interface, the modem provides a header with every received packet indicating signal quality. This is on the web interface as well as the log file.


If I understand your existing installation correctly, what you're referring to as an access point would be a BBS server that multiple clients would access. That wouldn't require a bridge or router configuration just the application software. What BBS SW are you currently running for your server and client?


* The UDR can be accessed using SSH.

* The UDR can be configured as a layer 2 bridge. We will provide  a tested example.

* The UDR can be configured as a layer 3 router. We will provide  a tested example.


Did I miss anything?

Bryan K7UDR


FUSION support

kc9gqr@...
 

Anyone working on Fusion support?   Just wondering..

Thanks

ThumbDV support coming for DUTCH*Star WinDV/DV Node

"John D. Hays" <john@...>
 

See note at http://nwdigitalradio.com/thumbdv-dutchstar-support-under-development

--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  

Re: RF access point application confirmation

bhhoyer@...
 

Sure, I'll post something tomorrow after reviewing it with the team.

Bryan K7UDR

Re: RF access point application confirmation

"Michael E Fox - N6MEF" <n6mef@...>
 

Thanks Bryan,

 

I’m doing a presentation on Saturday in which I’d like to describe this solution.  Is there something you can say in 5 minutes or less that would give folks an idea of what to expect?

 

Michael

N6MEF

 

 

From: UniversalDigitalRadio@... [mailto:UniversalDigitalRadio@...]
Sent: Thursday, January 29, 2015 8:45 AM
To: UniversalDigitalRadio@...
Subject: [UniversalDigitalRadio] Re: RF access point application confirmation

 

 

Hi Michael,

 

Thanks for your inquiry. I'll put together a detailed response in the next couple of days (after I finish Washington Taxes due tomorrow).

 

Bryan K7UDR

Re: RF access point application confirmation

bhhoyer@...
 

Hi Michael,

Thanks for your inquiry. I'll put together a detailed response in the next couple of days (after I finish Washington Taxes due tomorrow).

Bryan K7UDR

RF access point application confirmation

"Michael E Fox - N6MEF" <n6mef@...>
 

I’d like to confirm my understanding of what will be delivered with the UDRX-440.

 

The application I’m interested in is to replace multi-access 1200/9600 baud TNC environment with multi-access 56kbps (or higher) service.  Yes, I understand that the connection to the UDRX-440 would be Ethernet, rather than serial.  Specifically, we would look to unplug an existing 440 radio with TNC from a BBS serial port and replace with the UDRX-440 connected to the same LAN as the BBS.  We presume users would then telnet (and use other standard IP protocols) to the BBS, instead of their existing serial/AX.25 connection.

 

So my understanding is:

-- The UDRX-440 functions as either a layer 2 bridge or a layer 3 router.  Please say which.

-- The UDRX-440s provide 56kbps or higher bit rates, with forward error correction.  Please say which rates/modulation schemes.

-- One UDRX-440 could be set up to perform as an access point.  It is connected to the network and placed at a location with good RF reachability to surrounding users

-- Multiple users in the area each have UDRX-440s connected to the local LANs and acting as clients of the access point.

-- The UDRX-440s implement a protocol that provides some type of media access control so that the users can share the common frequency and contact the central UDRX-440 (or each other) all at the same time.  Please say which one(s).  This would be similar to (but obviously not the same as) how multiple TNC users connect to a central TNC at the same time, or multiple wifi clients connect to a single wifi AP at the same time.

-- Logging, diagnostics and other status and troubleshooting displays will be available, perhaps via a web page.  Please say what, specifically.

-- All of the above functionality will be configurable without having to write custom software, scripts, whatever.

 

Assuming the above is true, we would intend to replicate that in several locations.

 

Can one of the NW Digital Radio folks confirm that this solution will be deployable when the UDRX-440 starts shipping (currently scheduled for Q1, according to the web site)?  If not, what are the gaps and when would you expect to have that functionality?

 

Thanks in advance,

Michael

N6MEF

 

Re: Digest Number 203

Sideshowbob0374 <sideshowbob0374@...>
 

Hi John,

Thanks for your reply and I was able to get the two devices talking to one another.  I was able to link to ref012A but received choppy transmit audio reports and the receive audio is also choppy.  I went through all of my settings twice and everything is as it should be.  Decoding is working.  I can, at times, hear myself on the local repeater but the transmission is not communications quality.  Since this is happening on both transmit and receive, there may be something I'm missing in the settings.  Any suggestion would be appreciated.  Thank again,

Rob
AA6RA



On Jan 16, 2015, at 2:39 AM, UniversalDigitalRadio@... wrote:

2 Messages

Digest #203

Messages

1a

Re: DV3000U Cant find AMBE Dongle on port specified.

Thu Jan 15, 2015 4:37 pm (PST) . Posted by:

aa6ra

Hi John,

I just received my DV3000U today and I am having the same problem. I've read through the instructions for ambeserverwin and still need some help. I am using a netbook running windows 7. Now, first thing is I have downloaded the most current version of ircddbgateway and dummy repeater. I am familiar with those programs and have set them up accordingly. I am having problems with where to extract the AMBEseverWin files. You say to save them to a directory but unfortunately I do not know how to do that or where to put them on the computer so the zip file currently sits on my desktop. Also, if I extract these files to my desktop and type the command you gave above AMBEserver.exe -c22 -x (the dv3000 is on com port 22 in my case) I receive an error message. I'm guessing because I haven't extracted the files to the proper place. If you could give me step by step instruction on the entire process, I would greatly appreciate it. thanks in advanced and I look forward to getting the dv3000 up and running!


Rob Antonacci
AA6RA

1b

Re: DV3000U Cant find AMBE Dongle on port specified.

Thu Jan 15, 2015 5:05 pm (PST) . Posted by:

"John D. Hays" k7ve

Hi Bob,

If you unzipped in the Desktop, then you need to open a command window (
http://pcsupport.about.com/od/windows7/a/command-prompt-windows-7.htm)

Then change your directory to your Desktop, if your login is Bob and you
use disk C:

cd \Users\Bob\Desktop

Then issue the command

AMBEserver.exe -c 22 -x

The AMBEserver should start up.

On Thu, Jan 15, 2015 at 3:53 PM, sideshowbob0374@...
[UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:

>
>
> Hi John,
>
> I just received my DV3000U today and I am having the same problem. I've
> read through the instructions for ambeserverwin and still need some help.
> I am using a netbook running windows 7. Now, first thing is I have
> downloaded the most current version of ircddbgateway and dummy repeater. I
> am familiar with those programs and have set them up accordingly. I am
> having problems with where to extract the AMBEseverWin files. You say to
> save them to a directory but unfortunately I do not know how to do that or
> where to put them on the computer so the zip file currently sits on my
> desktop. Also, if I extract these files to my desktop and type the command
> you gave above AMBEserver.exe -c22 -x (the dv3000 is on com port 22 in my
> case) I receive an error message. I'm guessing because I haven't extracted
> the files to the proper place. If you could give me step by step
> instruction on the entire process, I would greatly appreciate it. thanks
> in advanced and I look forward to getting the dv3000 up and running!
>
> Rob Antonacci
> AA6RA
>
> __._,
>

--

------------------------------
John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223
<http://k7ve.org/blog> <http://twitter.com/#!/john_hays>
<http://www.facebook.com/john.d.hays>

Re: DV3000U Cant find AMBE Dongle on port specified.

"John D. Hays" <john@...>
 

Hi Bob,

If you unzipped in the Desktop, then you need to open a command window (http://pcsupport.about.com/od/windows7/a/command-prompt-windows-7.htm)

Then change your directory to your Desktop, if your login is Bob and you use disk C:

cd \Users\Bob\Desktop

Then issue the command

AMBEserver.exe -c 22 -x

The AMBEserver should start up.

On Thu, Jan 15, 2015 at 3:53 PM, sideshowbob0374@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

Hi John,


I just received my DV3000U today and I am having the same problem.  I've read through the instructions for ambeserverwin and still need some help.  I am using a netbook running windows 7.  Now, first thing is I have downloaded the most current version of ircddbgateway and dummy repeater.  I am familiar with those programs and have set them up accordingly.  I am having problems with where to extract the AMBEseverWin files.  You say to save them to a directory but unfortunately I do not know how to do that or where to put them on the computer so the zip file currently sits on my desktop.  Also, if I extract these files to my desktop and type the command you gave above AMBEserver.exe -c22 -x (the dv3000 is on com port 22 in my case) I receive an error message.  I'm guessing because I haven't extracted the files to the proper place. If you could give me step by step instruction on the entire process, I would greatly appreciate it.  thanks in advanced and I look forward to getting the dv3000 up and running!

Rob Antonacci
AA6RA

__._,


--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  

Re: DV3000U Cant find AMBE Dongle on port specified.

sideshowbob0374@...
 

Hi John,

I just received my DV3000U today and I am having the same problem.  I've read through the instructions for ambeserverwin and still need some help.  I am using a netbook running windows 7.  Now, first thing is I have downloaded the most current version of ircddbgateway and dummy repeater.  I am familiar with those programs and have set them up accordingly.  I am having problems with where to extract the AMBEseverWin files.  You say to save them to a directory but unfortunately I do not know how to do that or where to put them on the computer so the zip file currently sits on my desktop.  Also, if I extract these files to my desktop and type the command you gave above AMBEserver.exe -c22 -x (the dv3000 is on com port 22 in my case) I receive an error message.  I'm guessing because I haven't extracted the files to the proper place. If you could give me step by step instruction on the entire process, I would greatly appreciate it.  thanks in advanced and I look forward to getting the dv3000 up and running!

Rob Antonacci
AA6RA