You can send the reset command to the ThumbDV with the
extra two parity bytes even when the chip has parity
disabled. It will still execute the reset. But as you've
noticed, it doesn't work the other way round.
The VCH 72 and VeCH 32 bits are the 104 bits (72 + 32)
after adding the triple fec on the first 27 voice bits (81
bits) + 22 straight bits, then adding a padding '0' bit
before whitening and bit interleaving for the frame ..
this is for encoding.
I added support for the AMBE3000 in dsd, but have not
posted source online. Saturday, I cleaned up my
repository, reorganized the branches, and updated the
source code to the current dsd code. By Sunday Night I
was able to add in a cleaned up version of DVSI USB3000
support to dsd on my local laptop. No code is posted yet
as I am still working on it.
I finally got to try the NWdigital DVthumb, but it did
not work first time. The DVthumb uses a different
baudrate (230400) and has parity (message checksum)
turned off. The baudrate is no problem as it just needs
a command line parameter. Since the AMBE3000 chip does
not respond if the parity is wrong, I had to resend the
reset command with parity off and turn on parity when
the inital reset command does not return a response. I
got both the USB3000 and DVthumb to work in dsd.
The developer of mbelib did not realize that the bit
interleaving is usually done by the codec, so it is done
in dsd and not mbelib. I had to add another set of
interleaving data for the AMBE3000, mostly no
interleave. DStar is exception since they transmit byte
The USB3000 I have supports IMBE P25, and the DVthumb
does not. The code prints out if IMBE P25 is supported,
but does not do anything with the information currently.
This means the DVthumb will not decode IMBE P25 and
After I get the AMBE3000 support committed, the next
step is to add my Yaesu System Fusion code to the new
codebase. The code currently only does Mode 1. I want to
attempt to decode Mode 2 and High Speed.
Mode 2 uses a similar method as EDACS control channels,
where bits are sent three times. Only 27 bits are sent 3
times, and 22 bits are unprotected. On recieve the
majority of the three bits are used to determine the bit
value. I do not know how they get the VCH 72 and VeCH 32
numbers on page 34 as that does not reflect the result
of the processes on the page. It should be more like 49
VCH and 54 VeCH.