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
• python AMBETest4.py -v -e -n -s /dev/ttyUSB0
• Where
• -v = verbose operation
• -e = stop on errors
• -n = use 460800 baud serial
• -s port = use device “port”
• -I address = use AMBEServer “address” (default port)
• https://dvswitch.groups.io/g/allstarlink/files/AMBEtest4.py
• 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.