Last edited · 1 revision  


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

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