Date   

Re: Yaesu AMBE chip

beaupeppybrandypip@...
 

Hello Eric

I guess DVSI has slightly improved their AMBE chips packet handling routine since the firmware revision in your chip.

I've found that if you send a packet with parity to the AMBE-3000 chip when the chip has parity enabled, the chip not only ignores the command (no problem with that), but also ignores any other following commands/packets from that point onwards .. They still need to work on their internal packet handling.

DTR to hardware reset pin would be useful ;)

Cath


Re: Yaesu AMBE chip

"Eric A. Cottrell" <wb1hbu@...>
 

Hello,

The early revision of the ThumbDV I have does not respond to reset with the parity on. I just retry the reset with parity off and it works solidly. I then turn parity on.

I just fixed a problem with the AMBE3000 code. I found the AMBE3000 chip does bit interleaving for AMBE, even without FEC. I had a problem playing back AMBE output files in dsd as the mbelib library does not do bit interleaving. It took some effort to figure out the interleave.

Both devices work good now, with the ThumbDV not supporting P25 or IMBE output file playback (of course).

I suspect DVSI did the interleaving so earlier chips would not do a partial decoding of the AMBE bitstream.

I just need to clean up the A3K code and do a commit/push. Then on to Yaesu System Fusion.

73 Eric

On 11/23/2015 08:10 PM, beaupeppybrandypip@... [UniversalDigitalRadio] wrote:
 

Hi

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.


Cath


---In UniversalDigitalRadio@..., wrote :

Hello,

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 data "backwards".

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

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.

73 Eric


Re: [SPAM] any news yet on mac software for the thumbdv

Jeremy McDermond <mcdermj@...>
 

Just as a quick update for folks, the app is “In Review” at Apple right now. I have no idea what the timeline is on this or whether I’ll have to make changes to get them to accept it, but we’re at the stage where it’s dealing with Apple and the App Store process.


On Oct 27, 2015, at 9:22 PM, Les Norton gm4jnw@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:

Thanks guys, I’m using parallels on my mac at the moment and it works but windows is not my favourite system!

Thats great news and will look forward to the release.

Thanks in advance Jeremy for all your hard work too and the beta testers for their hard work too.

Cheers
Les G4JNW
www.g4jnw.co.uk


On 27 Oct 2015, at 23:23, richark@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:

As one of the lucky Buster beta testers, I can tell you it will be worth the wait.....


73,
Kenny, KU7M




--
Jeremy McDermond (NH6Z)
Xenotropic Systems
mcdermj@...


Re: Yaesu AMBE chip

beaupeppybrandypip@...
 

Hi

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.

Cath


---In UniversalDigitalRadio@..., <wb1hbu@...> wrote :

Hello,

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 data "backwards".

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

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.

73 Eric


Re: Yaesu AMBE chip

wb1hbu@...
 

Hello,

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 data "backwards".

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

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.

73 Eric


Re: Yaesu AMBE chip

"John D. Hays" <john@...>
 



On Wed, Nov 18, 2015 at 9:47 AM, John D. Hays <john@...> wrote:
People can see your image by visiting https://groups.yahoo.com/neo/groups/UniversalDigitalRadio/files

Nice work, BTW.

On Wed, Nov 18, 2015 at 7:50 AM, beaupeppybrandypip@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

hmmmmm, no sure how to link to a picture I've uploaded to the groups file section. Or even how to attach a picture to a mesage.




--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  




--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  


Re: Yaesu AMBE chip

"John D. Hays" <john@...>
 

People can see your image by visiting https://groups.yahoo.com/neo/groups/UniversalDigitalRadio/files

Nice work, BTW.

On Wed, Nov 18, 2015 at 7:50 AM, beaupeppybrandypip@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

hmmmmm, no sure how to link to a picture I've uploaded to the groups file section. Or even how to attach a picture to a mesage.




--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  


Re: Yaesu AMBE chip

beaupeppybrandypip@...
 

hmmmmm, no sure how to link to a picture I've uploaded to the groups file section. Or even how to attach a picture to a mesage.


Re: Yaesu AMBE chip

beaupeppybrandypip@...
 


Re: Yaesu AMBE chip

beaupeppybrandypip@...
 

John, before I admit defeat, I was wondering if you could possibly and kindly do another C4FM recording for me (disc tap) ?

If so, and if/when your able too, could you do the C4FM recording in V/D mode (not FR mode) sending say a continuous second each of DTMF tones (not voice). IF Yaesu send these tones by using the DTMF option on the AMBE chip, then it may well show me what bit-interleaving/swapping is going on.

Anyway, no problem if you can't, don't worry :)


Re: Yaesu AMBE chip

beaupeppybrandypip@...
 

After studying and comparing the decoded bit streams from C4FM recordings and the bit stream from the AMBE-3000 chip it's becoming clear that Yaesu are doing some extra undocumented bit swapping/bit interleaving to the codec channel bits from the AMBE chip before inserting them into their C4FM frames.

grrrrrrrr


Re: Yaesu AMBE chip

beaupeppybrandypip@...
 

oh right.

Have requested to join the group John. Thank you !


Re: Yaesu AMBE chip

"John D. Hays" <john@...>
 

You may want to communicate with some of the folks on this thread --

https://groups.yahoo.com/neo/groups/YaesuSystemFusion/conversations/topics/10042

On Mon, Nov 16, 2015 at 10:23 AM, John D. Hays <john@...> wrote:
Cath,

My reading of the Yaesu spec is that type 2 adds some FEC bits, external to the AMBE+2 vocoder.  My suspicion is that they are applying those addition FEC bits to the AMBE sample but having the AMBE-3000 chip only handle the 'standard' HR packet.  I'll look into it further.

Also are you using the RATET commands to set the register values or individually setting them using RATEP? (Page 64 of the 3000F manual)


On Mon, Nov 16, 2015 at 12:46 AM, beaupeppybrandypip@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

ah !

Thank you John. Fresh samples !

The DN file is V/D type 2.
I've just looked at the DR-1X manual and see that Yaesu don't give you the option to specify which of the two HR modes (V/D type 1 or V/D type 2) it uses, which is a shame.

I can decode the DN voice OK by feeding the extracted voice channel bits to the software mbelib AMBE decoder, but when I feed them to the hardware AMBE-3000 chip it doesn't decode it correctly still (comes back garbled).

So, either Yaesu are using a none standard AMBE-3000 chip, or I've still got something wrong, or they have chosen not to document a required step before sending the voice channel bits to the AMBE-3000 chip.

Considering that encrypted/hidden voice or data transfers are forbidden on the ham bands, I'm surprised the radio manufactures are getting away with not making every protocol detail freely availabe (such as what happened with ICOM/DSTAR).

Anyway, I shall keep at it, because I can't yet rule out that I'm forgetting something or have got something slightly wrong.

For Fusion V/D mode type 2 (a HR mode), I'm setting the AMBE-3000 chip to a custom rate using the these parameters listed in the chip data sheet ..

Total rate    Speech rate   FEC rate   RCW0    RCW1    RCW2    RCW3    RCW4    RCW5
   2450           2450             0           0x0431   0x0754   0x0000   0x0000   0x0000   0x7031

And for Fusion FR mode I'm using ..

Total rate    Speech rate   FEC rate   RCW0    RCW1    RCW2    RCW3    RCW4    RCW5
   7200           4400           2800        0x0458   0x0986   0x8020   0x0000   0x0000   0x7390




--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  




--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  


Re: Yaesu AMBE chip

beaupeppybrandypip@...
 


Hi John

Yes I've done all the de-interleaving, de-whiteing and fec in the decoder which produces the original 49 bits ready to be decoded (V/D type 2 mode). All that works ok.
I've uloaded the decoded voice from your file into the same folder in the files section.

I've tried using the RATET with index and RATEP with the 6 code words, both with the same result (garbled audio).


Re: Yaesu AMBE chip

K6ST Barry Bettman <k6st@...>
 

Looks like there is a lot of technical discussion about the AMBE chip on this yahoogroup. .  Any plans for access on DMR yet on the NWdigital DVthumb?  Thanks.


Re: Yaesu AMBE chip

"John D. Hays" <john@...>
 

Cath,

My reading of the Yaesu spec is that type 2 adds some FEC bits, external to the AMBE+2 vocoder.  My suspicion is that they are applying those addition FEC bits to the AMBE sample but having the AMBE-3000 chip only handle the 'standard' HR packet.  I'll look into it further.

Also are you using the RATET commands to set the register values or individually setting them using RATEP? (Page 64 of the 3000F manual)


On Mon, Nov 16, 2015 at 12:46 AM, beaupeppybrandypip@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 

ah !

Thank you John. Fresh samples !

The DN file is V/D type 2.
I've just looked at the DR-1X manual and see that Yaesu don't give you the option to specify which of the two HR modes (V/D type 1 or V/D type 2) it uses, which is a shame.

I can decode the DN voice OK by feeding the extracted voice channel bits to the software mbelib AMBE decoder, but when I feed them to the hardware AMBE-3000 chip it doesn't decode it correctly still (comes back garbled).

So, either Yaesu are using a none standard AMBE-3000 chip, or I've still got something wrong, or they have chosen not to document a required step before sending the voice channel bits to the AMBE-3000 chip.

Considering that encrypted/hidden voice or data transfers are forbidden on the ham bands, I'm surprised the radio manufactures are getting away with not making every protocol detail freely availabe (such as what happened with ICOM/DSTAR).

Anyway, I shall keep at it, because I can't yet rule out that I'm forgetting something or have got something slightly wrong.

For Fusion V/D mode type 2 (a HR mode), I'm setting the AMBE-3000 chip to a custom rate using the these parameters listed in the chip data sheet ..

Total rate    Speech rate   FEC rate   RCW0    RCW1    RCW2    RCW3    RCW4    RCW5
   2450           2450             0           0x0431   0x0754   0x0000   0x0000   0x0000   0x7031

And for Fusion FR mode I'm using ..

Total rate    Speech rate   FEC rate   RCW0    RCW1    RCW2    RCW3    RCW4    RCW5
   7200           4400           2800        0x0458   0x0986   0x8020   0x0000   0x0000   0x7390




--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  


Re: Yaesu AMBE chip

beaupeppybrandypip@...
 

ah !

Thank you John. Fresh samples !

The DN file is V/D type 2.
I've just looked at the DR-1X manual and see that Yaesu don't give you the option to specify which of the two HR modes (V/D type 1 or V/D type 2) it uses, which is a shame.

I can decode the DN voice OK by feeding the extracted voice channel bits to the software mbelib AMBE decoder, but when I feed them to the hardware AMBE-3000 chip it doesn't decode it correctly still (comes back garbled).

So, either Yaesu are using a none standard AMBE-3000 chip, or I've still got something wrong, or they have chosen not to document a required step before sending the voice channel bits to the AMBE-3000 chip.

Considering that encrypted/hidden voice or data transfers are forbidden on the ham bands, I'm surprised the radio manufactures are getting away with not making every protocol detail freely availabe (such as what happened with ICOM/DSTAR).

Anyway, I shall keep at it, because I can't yet rule out that I'm forgetting something or have got something slightly wrong.

For Fusion V/D mode type 2 (a HR mode), I'm setting the AMBE-3000 chip to a custom rate using the these parameters listed in the chip data sheet ..

Total rate    Speech rate   FEC rate   RCW0    RCW1    RCW2    RCW3    RCW4    RCW5
   2450           2450             0           0x0431   0x0754   0x0000   0x0000   0x0000   0x7031

And for Fusion FR mode I'm using ..

Total rate    Speech rate   FEC rate   RCW0    RCW1    RCW2    RCW3    RCW4    RCW5
   7200           4400           2800        0x0458   0x0986   0x8020   0x0000   0x0000   0x7390


Re: Yaesu AMBE chip

"John D. Hays" <john@...>
 

Cath,

I have put some capture files in the Files -> DR-1X section of this group for you to use as samples.


On Sun, Nov 15, 2015 at 10:10 AM, beaupeppybrandypip@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 


What I'm hoping, is that Yaesu aren't using the AMBE-3000F-P25 or AMBE-3000F-SAT chips. If they are, then that would explain a couple of things.

Those two other variants of the AMBE-3000 chip both provide two different variants on the exact same channel bit rates (2450 and 7200) that Yaesu Fusion use (V/D type 2 and Voice FR).

I can't yet test Fusion V/D type 1 mode with the ThumbDV as I don't have any uncompressed recorded WAV files containing the raw C4FM. And our local Fusion repeater won't be installed and working till close to christmas time.




--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223 
  


Re: Yaesu AMBE chip

beaupeppybrandypip@...
 

None of the those WAV recordings seem to exists anymore John :(

Either that or the dropbox site is blocked by my ISP.


Re: Yaesu AMBE chip

"John D. Hays" <john@...>
 

On Sun, Nov 15, 2015 at 10:10 AM, beaupeppybrandypip@... [UniversalDigitalRadio] <UniversalDigitalRadio@...> wrote:
 


What I'm hoping, is that Yaesu aren't using the AMBE-3000F-P25 or AMBE-3000F-SAT chips. If they are, then that would explain a couple of things.

Those two other variants of the AMBE-3000 chip both provide two different variants on the exact same channel bit rates (2450 and 7200) that Yaesu Fusion use (V/D type 2 and Voice FR).

I can't yet test Fusion V/D type 1 mode with the ThumbDV as I don't have any uncompressed recorded WAV files containing the raw C4FM. And our local Fusion repeater won't be installed and working till close to christmas time.




--


John D. Hays
K7VE

PO Box 1223, Edmonds, WA 98020-1223