Date   

Performance measuring

ve7dhm@...
 

I came across an interesting article describing ID-1 testing using iperf in my search for finding Linux tools to use with the UDRX to quantify performance.  I tested a KPC-3+ and a KPC9600, back to back audio and over
the air, using a similar setup with the addition of ping and socat and a couple of Raspberry Pis running Raspbian.  At 1200 baud, ping was slow giving around 2.5 seconds and a bandwidth around 1 Kbits per second with a jitter figure around 0.9ms.  So I think these linux apps should work with the UDRXs to provide path testing.  Any other ideas about how to go about this?

Paul VE7DHM



Re: Android ?

Gary S <eli26e9@...>
 

Well I actually found a near usable solution:......

DV Node


Unfortunately for me (& maybe others), my currently device (which is also my most powerful) is not "rooted" and I have yet to find a solution for that. So it looks like I just have to wait till the .apk doesn't need root to be usable.

At least we are getting closer to a solution.



On Monday, 27 July 2015, 10:09, "Gary S eli26e9@... [UniversalDigitalRadio]" wrote:


 
I was actually thinking for along the lines of what someone did with a windows tablet (I cant find the link at the moment..



On Monday, 27 July 2015, 0:53, "pa3dfn@... [UniversalDigitalRadio]" wrote:


 
Hi all,

pa7lim has a working ircdddbgateway on android. The connection is via bluetooth to the DVMEGA and ambe3000.

The audio is now via a mic connected to the ambe 3000.

So far as I know is David working on audio via the android phone.

gr,

Philip






Re: Android ?

Gary S <eli26e9@...>
 

I was actually thinking for along the lines of what someone did with a windows tablet (I cant find the link at the moment..



On Monday, 27 July 2015, 0:53, "pa3dfn@... [UniversalDigitalRadio]" wrote:


 
Hi all,

pa7lim has a working ircdddbgateway on android. The connection is via bluetooth to the DVMEGA and ambe3000.

The audio is now via a mic connected to the ambe 3000.

So far as I know is David working on audio via the android phone.

gr,

Philip




Re: Android ?

pa3dfn@...
 

Hi all,

pa7lim has a working ircdddbgateway on android. The connection is via bluetooth to the DVMEGA and ambe3000.

The audio is now via a mic connected to the ambe 3000.

So far as I know is David working on audio via the android phone.

gr,

Philip


Re: Android ?

myyahoo@...
 

Nothing should stop you from plugging it in - but you have to find (or write) Android software to talk to it. :-)

- Richard, VE7CVS


Android ?

Gary S <eli26e9@...>
 

Showing the thumbdv to a fellow ham yesterday, he only ask one simple question....

So when can he plug one into his Samsung Galaxy Note 4 ?

When you consider the processing power and its Android, I wonder when as well ?

Gary
vk2zbb


does anyone know when System fusion will be supported...

kc9gqr@...
 

would be great to  be able to make a hot spot out  a non fusion radio for wires x  digital 


Re: DV3000 Pi Questions

"Dan Ozment" <dan@...>
 

John, I wondered if I could pick your brain one more time about my DV3000 configuration.   Last email exchange we had you said the following:

 

I have regularly run ircDDBGateway + dstarrepeater on a Pi as well as AMBEserverGPIO,  and accessed both from DummyRepeater whether local or remote.  Running two modules through ircDDBGateway on a Pi is not a problem, especially with a Pi 2.

 

I would love to do that, but for the life of me I can’t figure it out.   I have DummyRepeater and ircDDBGateway on a Win 8.1 machine talking to AMBEServerGPIO on a Pi2. 

 

On another Pi2 I have ircDDBGateway and PCRepeaterController (I think that’s the name) and my DVAP.

 

I would like to combine to DVAP, DV3000 and AMBEServerGPIO onto one Pi2.

 

Everything works as it is.  But, I cannot get DummyRepeater talking to ircDDBGateway on the Pi with the DVAP.    Could you possibly tell me how you did it? 

 

I think I need to be using Repeater2 on ircDDBGateway.  I set it up as a hotspot and but it on Band D.   I told Dummy Repeater (on the Windows Machine) the IP of the Pi2 and the port for Repeater 2 (20012) as shown in the following screen shot

 

 

However, I don’t see any indication that dummyrepeater is talking to ircDDB on the Pi2.

 

Stumped…. 


Re: Question? Model a vs previous model?

kd8viq@...
 

John;
 
    Thank you for the info.  While I wasn't trying to start something, sometimes change is not necessarilly good for us, and that was a concern that I had.  Yet since you show that we have nothing to worry about.  That is great. 
 
    I think I prefer having the lessor baud vs this newer rate,  Only time will truly tell. 
 
    While I have yet hooked the thumbdv into my computer.  I am looking forward to the experience. 

    Thanks again for GREAT WORK up front.
 
73
kd8viq


Re: Question? Model a vs previous model?

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

The ability to do vocoding for DMR, D-STAR, Fusion, P25 Phase 2, etc. is built into the AMBE 3000 chip.  The new Model 'A' only changes the baud rate that the serial port passes packets to and from the chip.  It does not change any other capability between the original and Model 'A'.

The 230400 baud rate is sufficient for all of these modes.  The OEM(s) we are working with are swapping out another USB AMBE-3000 device with the ThumbDV.  That other device was strapped at 460800 and they just want to swap it out.

It doesn't make sense for us to make 2 models, one strapped at 230400 and one strapped at 460800 so we are now making all units strapped at the higher baud rate. 

There is no secret, hidden, message here.  It's a simple baud rate change that we wanted customers to be aware of, nothing more.

Here is the math:

The fastest input from one voice stream is 128 Kbps (8000 samples per second at 16 bits). So 230kbps in is more than sufficient. The fastest rate out is Yaesu's full rate at 7.2kbps, DMR, Fusion half rate,  and D-STAR are at 3.6kbps. (This is for encoding, reverse for decoding.) There is only one packet stream, so you don't get any doubling of these numbers. 

There is literally nothing different than the selected baud rate, implemented in an update printed circuit board that changes what lines are strapped down.

The AMBE 3000 chip provides the vocoding, and only the vocoding.  The various protocols embed the vocoding in their respective data streams.  The 'devices' (e.g. AMBE 3000 boards, dongles, etc.) are not involved in the actual protocols, only in turning voice into AMBE and AMBE into voice.

Please view http://nwdigitalradio.com/john-speaks-on-dv-modes-at-microhams-2015 to see how digital voice systems are built up. 


On Tue, Jul 14, 2015 at 10:31 AM, gary limbert kd8viq@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

While I may be reading more into this, than what is actually happening, but if I could get some clarification to remove some of the fog or clouds in my mind.

Playing with D-star for some time now, and seeing how many of the devices are
moving to incorporate C4FM, P25 and other digital modes.  In making
this move of the baud rate on the new thumb drives will that allow this
new model to be later opened up for the other digital modes?  If it should allow them to open up for C4FM, P-25 or other digital modes, will those who have purchased the first batch before model a be stuck in D-Star Availability ONLY?

kd8viq@...



John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  


Question? Model a vs previous model?

gary limbert <kd8viq@...>
 

While I may be reading more into this, than what is actually happening, but if I could get some clarification to remove some of the fog or clouds in my mind.

Playing with D-star for some time now, and seeing how many of the devices are
moving to incorporate C4FM, P25 and other digital modes.  In making
this move of the baud rate on the new thumb drives will that allow this
new model to be later opened up for the other digital modes?  If it should allow them to open up for C4FM, P-25 or other digital modes, will those who have purchased the first batch before model a be stuck in D-Star Availability ONLY?

kd8viq@...


Re: ThumbDV -> ThumbDV Model A

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

Also doing so will void the warranty.

Thanks, Robert

On Jul 12, 2015 5:49 PM, "Robert Garcia robert@... [UniversalDigitalRadio]" <UniversalDigitalRadio@...> wrote:
 

As someone who did it, I would not recommend it, the risk of destroying the device is high.  ;-)


--
Robert Garcia, N5QM


On Sun, Jul 12, 2015 at 6:47 PM, 'John D. Hays' john@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

Changing the baud rate on the original dongle would require very delicate trace cuts and jumpers and is not recommended. 

There is really no advantage to changing the baud rate for current applications that use the ThumbDV as the throughput is more than sufficient.  


On Sun, Jul 12, 2015 at 3:52 PM, 'Don Woodward' dbwoodw@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

Can the original ThumbDV be converted to a model A?

 

Don Woodward

KD4APP


--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  



Re: ThumbDV -> ThumbDV Model A

Robert Garcia <robert@...>
 

As someone who did it, I would not recommend it, the risk of destroying the device is high.  ;-)


--
Robert Garcia, N5QM


On Sun, Jul 12, 2015 at 6:47 PM, 'John D. Hays' john@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

Changing the baud rate on the original dongle would require very delicate trace cuts and jumpers and is not recommended. 

There is really no advantage to changing the baud rate for current applications that use the ThumbDV as the throughput is more than sufficient.  


On Sun, Jul 12, 2015 at 3:52 PM, 'Don Woodward' dbwoodw@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

Can the original ThumbDV be converted to a model A?

 

Don Woodward

KD4APP


--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  



Re: ThumbDV -> ThumbDV Model A

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

Changing the baud rate on the original dongle would require very delicate trace cuts and jumpers and is not recommended. 

There is really no advantage to changing the baud rate for current applications that use the ThumbDV as the throughput is more than sufficient.  


On Sun, Jul 12, 2015 at 3:52 PM, 'Don Woodward' dbwoodw@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

Can the original ThumbDV be converted to a model A?

 

Don Woodward

KD4APP


--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  


ThumbDV update

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

http://nwdigitalradio.com/category/thumbdv

--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  


ThumbDV -> ThumbDV Model A

"Don Woodward" <dbwoodw@...>
 

Can the original ThumbDV be converted to a model A?

 

Don Woodward

KD4APP

 

 


UDRX temperature tolerance

"Michael Fox \(N6MEF\)" <n6mef@...>
 

The May 14th UDRX update on the blog page says:  “… goal of 100% duty cycle in a 20C shack without a fan.  A separate temp-controlled fan kit will be available for high ambient temperature, continuous duty applications.”

 

A couple of issues there:

 

1)  20C is 68F.  That’s pretty chilly and not something that will realistically be found … almost anywhere.   So higher than 20C is not exactly “high ambient temperature.”  For example, we know from experience that the temp at most radio sites is in the low 70s to the low 80s (22C-30C). 

 

A more common temperature spec for equipment is 40C.  My laptop is rated at 0C – 40C.  Many industrial/automotive fanless PCs are rated at 40C.  Industrial SSDs are commonly rated at 40C.  And, when an A/C failure happens, the indoor temp at a radio site can easily reach 100-105F (38-41C) or even exceed that (109F/43C was the highest I’ve ever seen).  So 40C is a much more useful number.

 

2)  100% duty cycle doesn’t tell me much about how the device will perform in real-world applications. Specifically, most applications will involve some TX, some RX, and some idle time.   

 

So, I’m thinking that a more useful set of specs would be to tell us the max sustained temp tolerance for a few different duty cycle options, both with and without the fan.  For example:

 

100% TX, no fan:  20C

100%TX, w/fan:  ??

 

50% TX, 50% RX, no fan:  ??

50% TX, 50% RX, w/fan:  ??

 

33% TX, 33% RX, 33% idle, no fan:  ??

33% TX, 33% RX, 33% idle, w/fan:  ??

 

That should be enough to help us understand whether we need the fan or not for our situation, as well as whether it will withstand typical radio site environments.

 

BTW:  I hope the fan option will include a filter.  Many mountain top sites can be dusty!   A simple 1/8” thick foam filter like is found in a window A/C unit or many industrial PC would be perfect.

 

Michael

N6MEF


WinDV/DV Node now available at Dutch-STAR.eu

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

Fred has restored and updated his site http://dutch-star.eu and you can now get updated WinDV through his downloads. (Account required.)

--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  


Re: Pi - Can't Find AMBE Dongle On The Port Specified

John Hays <john@...>
 

This config file belongs to the operating system. 

The Raspbian team would need to modify. 

Sent from my iPhone

On Jun 20, 2015, at 17:28, dsp_stap@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:

 

---In UniversalDigitalRadio@..., wrote :

> I had spaces in config.txt around the “=” as in

> init_uart_clock = 50000000

> John removed the spaces as follows, and I’m in business.

> init_uart_clock=50000000


Please change the parser to allow any amount of whitespace, except inside tokens.


73,

Ken N8KH


Re: Pi - Can't Find AMBE Dongle On The Port Specified

dsp_stap@...
 

---In UniversalDigitalRadio@..., <dan@...> wrote :
> I had spaces in config.txt around the “=” as in

> init_uart_clock = 50000000

> John removed the spaces as follows, and I’m in business.

> init_uart_clock=50000000


Please change the parser to allow any amount of whitespace, except inside tokens.


73,

Ken N8KH