Topics

DV3000 testing results


Steve N4IRS
 
Edited

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?" 


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?"