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 o DV3000U set up as direct serial and AMBEServer configurations (at least 4 devices have been tested) o X86 based computers (Linux, OSX) o ARM based computers (Raspian, Comapss, Armbian) o Power supplies + Anker 60 watt multi-port supply + Power cube with 1.35A @ 5V output + X86 using internal PS * Test scenarios o Run a python test application designed to exercise and test returned results o Application is run on X86 machines and ARM based machines with both power supply configurations o Test loops are run from between 10,000 or greater passes o Each pass both encodes and decodes AMBE frames o 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://github.com/N4IRS/Analog_Bridge/raw/master/DV3000/AMBEtest4.py * Test results o X86 + All tests perform as expected, both serial and AMBEServer pass o 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) o 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 o 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?"