K7BV of Yaesu Introduces System Fusion & DR-1 Digital/FM Repeater at ARRL/TAPR DCC in Seattle

[WB9QZB]

Dennis, K7BV of Yaesu

 

Introduces

 

System Fusion & DR-1 Digital/FM FDMA C4FM Repeater

 

at ARRL/TAPR DCC in Seattle

 

Presentation Video

http://youtu.be/uXj5fmZKPps

 

[Ronny Julian]

OK.  So there is NO USB/Ethernet/ or even an "old" serial port to link a simple computer at each end? BOO Yaesu!  That should have been a first priority to give us at least as much as D-Star and others have. 

I  hope I'm wrong and this does not just send pretty pics from the speaker mic camera.   Pardon me if I have my figures off but I can take a SSTV shot with my N1VG camera and use any analog FM radio to send it in about 70 seconds.  $80 and home made cables to hook one up to the radio I have.  

Thanks to those there for asking what I thought were very good questions!  Gary captured it well!  Everyone there tell us what you saw in the demo room and anything else learned please.

Ronny

K4RJJ

--
You received this message because you are subscribed to the Google Groups "digitalvoice" group.
To unsubscribe from this group and stop receiving emails from it, send an email to digitalvoice...@googlegroups.com.
To post to this group, send email to digita...@googlegroups.com.
Visit this group at http://groups.google.com/group/digitalvoice.
For more options, visit https://groups.google.com/groups/opt_out.

[Michael Carey]

Very interesting video.

Poor Dennis was out of his depth a little with that audience! :-)

Saying the radios/repeater is C4FM is like describing D-Star as GMSK.  C4FM is just the modulation.
I hope Yaesu publish the protocol specifications (like specs D-Star, P25, DMR, dPRM, Tetra)

It didn't take long for the Icom proprietary protocol that their G2 software uses to link repeaters to be reverse engineered... hopefully Yaesu will be more open and forthcoming with how their systems can be linked.

Michael.
VK5ZEA

[Kristoff Bonne]

Hi All,

On 22-09-13 11:12, Michael Carey wrote:

Very interesting video.

Poor Dennis was out of his depth a little with that audience! :-)

I agree on this. We will see in the next couple of months and see how much information will be made public.

However, to see that a company like yaesu descides to send somebody to a technical forum like TAPR who does not have the least some least technical  knowledge of a system he is supposted to sell, it doesn't look very possitive on how much commitment yaesu really has in this product.
I hope they will clean up their act.

If yaesu where really smart, they would much more then just release the specs. It would be much better for them to get a couple of their guys to develop an open-source module for their system to plug it in allstar, Jonathan's code or the like. That would a good move to close in to D-STAR.

Saying the radios/repeater is C4FM is like describing D-Star as GMSK.  C4FM is just the modulation.
I hope Yaesu publish the protocol specifications (like specs D-Star, P25, DMR, dPRM, Tetra)

It didn't take long for the Icom proprietary protocol that their G2 software uses to link repeaters to be reverse engineered... hopefully Yaesu will be more open and forthcoming with how their systems can be linked.

The choice of C4FM is already a good thing as this does makes creating hardware for it a lot easier and -in contrast to TDMA systems- something most people can do.

One interest element in this will be the choice of the codec. If it is AMBE or AMBE2+, it would make it compatbie with some of the other DV systems and we it would be interesting to see if we cannot not interconnect these systems without needing to do transcoding.

Michael.
VK5ZEA

73
kristoff - ON1ARF

[Bruce Perens]

On 09/22/2013 02:47 AM, Kristoff Bonne wrote:

If it is AMBE or AMBE2+, it would make it compatbie with some of the other DV systems and we it would be interesting to see if we cannot not interconnect these systems without needing to do transcoding.

Actually, this would only be true if the same parameters are sent to AMBE as on those other platforms. AMBE has variable bitrates and variable FEC size. If Yaesu does use the same ones as D-STAR, you can only gateway to D-STAR by going from AMBE to analog audio and then back to AMBE.

[Bruce Perens]

On 09/22/2013 09:44 AM, Bruce Perens wrote:

If Yaesu does use the same ones as D-STAR, you can only gateway to D-STAR by going from AMBE to analog audio and then back to AMBE.

Typo. Does _not_ use.

[Kristoff Bonne]

Bruce,

Agreed for bitrate / AMBE-version. FEC should in theory not be an issue.

E.g. for D-STAR, it are in theory able to send a pure 2400 bps AMBE stream ("AMBE" stream, not D-STAR) to a repeater and let *it* create the D-STAR stream (including golay FEC) to be transmitted on the radio-channel.

P25 phase 2, DMR, dPMR and NXDN all use AMBE2+ (or have an option to do so), so it might be interesting to see exactly what version of AMBE2+ they use and it we can extract the "pure" AMBE2+ stream from them.


73
kristoff - ON1ARF

[Bruce Perens]

Do we have documentation of AMBE's FEC?

--
Sent from my Android phone with K-9 Mail. Please excuse my brevity.

[Kristoff Bonne]

Bruce,


It's in the DTMF decoding code.


Of the top of my head, it goes like this:
- A 25 ms AMBE frame at 2400 bps is 48 bits
- This is split into 2 blocks of 24 bits
- For the first blocks, golay is applied: i.e. the block in divided in two blocks of 12 bits, and golay is applied on each block. This results in an additional block of 24 bits (twice 12 bits of golay FEC data)


At this point, you have three blocks of 24 bits:
- data of first 24 AMBE bits
- golay-FEC data for the first 24 bits
- data of the last 24 AMBE bits

These three blocks are then interleaved. This form the 72 bits of AMBE data presents in each D-STAR frame. Add 24 bits of syncronisation or slow-speed data and you have the 96 bits of a D-STAR frame (25 ms @ 4800 bps).


As said, this is of the top of my head, so I propose you double-check on this code to be sure.
It is used in the D-STAR repeaters to do DTMF decoding, silence detection. It is also used to calculate the BER-rates that you can find on the ircddb "live" webpage.

This was not in the specification but was found by somebody by reverse-engineering the AMBE frames. (I don't know who, I was surely not involved in this).


73
kristoff - ON1ARF

[Bruce Perens]

Thank you, that's very useful. Do I understand correctly that half the data has FEC and half does not ?

[Tony Langdon]

Not quite correct, you only have to go back to PCM, not all the way to analog, assuming you build a protocol translator with AMBE chips in it.

-- 
73 de Tony VK3JED/VK3IRL
http://vkradio.com

[Kristoff Bonne]

Hi Bruce,



Yes. That's correct.


I know you probably know this. ... however, for the sake of my "demythify digital" project:

D-STAR has a fixed structure of 2400 bps of voice, 1200 bps FEC and 1200 bps sync/slow-speed data: 48 bits + 24 bits + 24 bits per 20 ms D-STAR frame.

Golay has a FEC rate of 2/1, as it adds 12 (*) bits of forward-error correction bits for every of 12 bits of data is needs to protect. And, as D-STAR uses golay to protect the voice data, the developers of D-STAR had no other choice then to apply error-correction on only half of the voice data.


But, to be fair, this isn't all that uncommon in digital voice. FreeDV and c2gmsk(2400) also apply FEC on only part of the voice data.

The 'trick' is to apply it on that part of the voice-frame that is the most important, i.e. that produce the most audiable "R2D2" effect when the bits are corrupted due to transmission-errors.

This is where Digital Voice is fundamentally different from Digital Data. In DD, the transport-layer has no idea what kind of information is it carrying so it needs to protect all data equally well. In Digital Voice, "not all bits are equal". Some bits are more worth protecting then others.



One final note:
The AMBE chip in the DVdongle does implement the FEC operations too (or at least how it used by the DVdongle application). If you send it 20 ms of PCM audio, you get back 72 bits of AMBE data: i.e. AMBE data + FEC.
But, as far as I know, is it strictly speaking not part of AMBE and that part of the operation isn't patented neither.



73
kristoff - ON1ARF


(*) there are multiple versions of golay. Two of them are golay12/23 and golay12/24. The latter one adds some extra abbility to detect errors. I'm not really sure which of these variants is used by D-STAR.

Sent from my Android phone with K-9 Mail. Please excuse my brevity. --

[Bruce Perens]

On 09/23/2013 12:18 PM, Kristoff Bonne wrote:

I know you probably know this. ... however, for the sake of my "demythify digital" project:

It's appreciated. I have to write about this and not be off base.

But, to be fair, this isn't all that uncommon in digital voice. FreeDV and c2gmsk(2400) also apply FEC on only part of the voice data.

Yes, but this explains why our FEC is more effective. We do it on a lot less than 50% of the data, and we actually know the meaning of the fields we are protecting.

Is it actually _documented_ that the critical information is in the first half of the AMBE frame, and is applying FEC to only half the frame a DVSI-suggested strategy?

    Thanks

    Bruce

[Reuven Z Gevaryahu]

The one step you missed is that the first golay block's output keys a simple prng that is XORed over the second block to be before degolayed it, in order to amplify any corruption of the first block and create a "digital cliff" if the signal is too bad to decode. Also the second golay is a 23 bit golay instead of 24, leaving 25 unprotected bits. I have a feeling that some of the convolution exists primarily to make it patent-able. :-)

(On a related note, does anybody have the time/desire to fix dsd to decode DSTAR voice? As far as I saw the biggest thing broken is the interleave and the mapping of the bits to the ambe_fr structure...)

--Reuven (KB3EHW)

On Sunday, September 22, 2013 3:02:23 PM UTC-4, kristoff wrote:

Bruce,


It's in the DTMF decoding code.


Of the top of my head, it goes like this:
- A 25 ms AMBE frame at 2400 bps is 48 bits
- This is split into 2 blocks of 24 bits
- For the first blocks, golay is applied: i.e. the block in divided in two blocks of 12 bits, and golay is applied on each block. This results in an additional block of 24 bits (twice 12 bits of golay FEC data)


At this point, you have three blocks of 24 bits:
- data of first 24 AMBE bits
- golay-FEC data for the first 24 bits
- data of the last 24 AMBE bits

These three blocks are then interleaved. This form the 72 bits of AMBE data presents in each D-STAR frame. Add 24 bits of syncronisation or slow-speed data and you have the 96 bits of a D-STAR frame (25 ms @ 4800 bps).


As said, this is of the top of my head, so I propose you double-check on this code to be sure.
It is used in the D-STAR repeaters to do DTMF decoding, silence detection. It is also used to calculate the BER-rates that you can find on the ircddb "live" webpage.

This was not in the specification but was found by somebody by reverse-engineering the AMBE frames. (I don't know who, I was surely not involved in this).


73
kristoff - ON1ARF


On 22-09-13 20:45, Bruce Perens wrote:

Do we have documentation of AMBE's FEC?

[Bruce Perens]

On 09/23/2013 12:35 PM, Reuven Z Gevaryahu wrote:
> The one step you missed is that the first golay block's output keys a
> simple prng that is XORed over the second block to be
> before degolayed it, in order to amplify any corruption of the first
> block and create a "digital cliff" if the signal is too bad to decode.
> Also the second golay is a 23 bit golay instead of 24, leaving 25
> unprotected bits.

Not really what we want for ham radio, is it? Is there a good document
of this algorithm somewhere?

> I have a feeling that some of the convolution exists primarily to make
> it patent-able. :-)

We have more reasons for Open Source than people usually consider. Like
if you do something really stupid for nontechnical reasons, everyone can
see it.

[David Rowe]

> Yes, but this explains why our FEC is more effective. We do it on a
> lot less than 50% of the data, and we actually know the meaning of the
> fields we are protecting.

In March I actually went a little further - designed a new codec mode to
better suit the error patterns of HF channels, and make it easier to
protect with a small amount of FEC. Try doing that with closed
source......

- David

[Reuven Z Gevaryahu]

It sounds pretty bad the way I described it, but it works pretty well. If the combined sum of the golay errors exceeds 6, the decoder repeats the frame with the parameters of the previous frame. If the count of repeated frames hits 3 (if I recall) the sound drops out. The FEC is not "randomly" on certain bits in AMBE, it is protecting the most significant bits of the fundamental frequency, voicing, gain, etc. The designers took care to protect the more important bits, just as we are doing- See claim 12 in the patent.

This part of the algorithm I mentioned is partially documented in the patent (https://www.google.com/patents/US8359197) see the text and claims 12-15. The DTMF decoder widely used in DSTAR (ircDDB-mheard) implements basic decoding of the packets and implements this part, but only looks at tone frames- see https://github.com/dl1bff/ircDDB-mheard/blob/master/dstar_dv.c and related. The only open-source implementation that I'm aware of that decodes the packets fully to sound is mbelib; you can see the handling here https://github.com/szechyjs/mbelib/blob/master/ambe3600x2250.c (for example) and the associated header file.

--Reuven (KB3EHW)

[Steve]

On Monday, September 23, 2013 2:18:25 PM UTC-5, kristoff wrote:

...And, as D-STAR uses golay to protect the voice data, the developers of D-STAR had no other choice then to apply error-correction on only half of the voice data.

Bottom line, the FEC is completely within the DVSI chip.

You can turn it on, or turn it off, but the AOR and DSTAR modems don't extend that option to the user, and the FEC is always on, and the rate is 2400.  A complete waste of a good chip, by fixing the mode. You'd think the Japs would be more adventurous...

I found that if you put a butane torch to the AMBE chip on my AOR modem, that the pins get hot and you can just tap it on the bench and the chip will fall out.  Now I can use some wire-wrap wire and bring all the pins out to the breadboard...

[Kristoff Bonne]

Hi Reuven,


Yes. I'm sorry. You did already mention this in this list.

As I said, this was "off the top of my head". The last time I looked at
this code was the DTMF decoder / channel quality "wrapper code" I once
did for D-STAR.
It was a wrapper around code written my Michael DL1BFF as part of the
ircddb package so we could do some experiments with DTMF controlling a
D-STAR repeater. I did take the opportunity to peek into the code to
find out how DTMF decoding actually worked and how it looked inside the
AMBE stream, but that surely does not make me an expert in this. :-)

On 23-09-13 21:35, Reuven Z Gevaryahu wrote:
> The one step you missed is that the first golay block's output keys a
> simple prng that is XORed over the second block to be
> before degolayed it, in order to amplify any corruption of the first
> block and create a "digital cliff" if the signal is too bad to decode.

OK, that's a bit strange as this means that you actually carry biterrors
of the 1ste block into the 2nd block.

But if the goal is to create a digital cliff, it will probably will have
a slightly negative impact on sensitity anyway you implement it.

> Also the second golay is a 23 bit golay instead of 24, leaving 25
> unprotected bits. I have a feeling that some of the convolution exists
> primarily to make it patent-able. :-)

OK, let me see if I get this correct.

40 ms of AMBE data is not 48 bits bit 49!
Then add 12 bits for the first golay block12/24 (protecting 12 bits) and
11 bits for the 2nd golay block (which uses golay12/23, protecting 12
bits with only 11 FEC bits). This all results in 72 bits in total.

Correct?

> (On a related note, does anybody have the time/desire to fix dsd to
> decode DSTAR voice? As far as I saw the biggest thing broken is the
> interleave and the mapping of the bits to the ambe_fr structure...)

I leave that to the real hackers. :-)


> --Reuven (KB3EHW)
73
kristoff - ON1ARF

[Reuven Z Gevaryahu]

No problem. I'm far from an expert on this as well, I just happened to have read up on it a few months ago. I saw the DL1BBF code and your DTMF decoder based on it; a bunch of what I learned on the format and interleave came from his and your code. You are correct in your totaling of the bits. 49 bits audio + 12 FEC + 11 FEC = 72 bits. The layout of the bits in the deinterleaved post-FEC frame is in table 6 in the patent.

Following up on the other post- The dvDongle source code is available (GPLv2 - see http://www.moetronix.com/dvdongle/), and the FEC mode can be changed in the software in ambe2000.c, around line 180. For anybody daring enough, you can flash the dvDongle with code to make the FEC parameters configurable. Note- I don't own one of these and therefore have never attempted this.

> I leave that to the real hackers. :-) 

I figure we're hams, most of us have a little hacker in us. Decoding DSTAR voice in software would be useful to many hams I'd guess. The worst that could happen is a nasty-gram from a DVSI lawyer if you're doing it in the wrong country. (Which is part of the point of codec2).

--Reuven (KB3EHW)

[Kristoff Bonne]

Steve,

On 23-09-13 22:47, Steve wrote:

On Monday, September 23, 2013 2:18:25 PM UTC-5, kristoff wrote:

...And, as D-STAR uses golay to protect the voice data, the developers of D-STAR had no other choice then to apply error-correction on only half of the voice data.

Bottom line, the FEC is completely within the DVSI chip.

You can turn it on, or turn it off, but the AOR and DSTAR modems don't extend that option to the user, and the FEC is always on, and the rate is 2400.  A complete waste of a good chip, by fixing the mode. You'd think the Japs would be more adventurous..

Hmm. I don't know if that is really fair to say.

In the end, developing a DV system is more then just implementing a codec and a modem. Any system requires a balance between "what is possible" and "what is needed". Making a DV system to complex isn't good neither.

I think D-STAR is designed for what most people use it for: to make QSOs on a repeater. (in fact, 99.999 % of the QSOs in D-STAR probably pass over a repeater).
Things like changing the parameters of the underlying protocol, etc. was probably not a design requirement. The fact that the protocol has very few options to expand it -I think- a good indication that D-STAR is simply a "buy it, use it" system.


I know, this is not very "ham" like. And it does not satify my interest in digital communication neither. (why do you think I am interested in codec2?).
But, that is not the point here. Adding all these other "experimenter options" would have made the protocol more complex and I think we can safely asume that the designers wanted to avoid that. D-STAR is designed to do what it is supposted to do: allow people to make QSOs over a repeater. And it does do that pretty good.


For me, D-STAR interests me as it exists, and because many people use it and it relative simple, it is a good basis to teach people about digital voice. If you manage to get people interested in the internals of digital voice by showing how D-STAR works, the steps to a system that does allow experimentation (read: codec2 based DV) isn't that hard.

.I found that if you put a butane torch to the AMBE chip on my AOR modem, that the pins get hot and you can just tap it on the bench and the chip will fall out.  Now I can use some wire-wrap wire and bring all the pins out to the breadboard...

Aw! How many does these AOR modems cost? :-)


BTW. You do can access the AMBE chip in a DVdongle via software. It is just a serial interface and you just need to send the correct initialisation strings to the chip to put in another mode.
I did do some experimentation with this when I worked on the "D-STAR voice announcement" software. (but that is now about 2 years ago).

There is quite a bit of information in the datasheets that document how to use the different modes of the chip (see table 5D on page 30).  You can put the chip in 2000/nofec, 2400/nofec, 2400/1200blockfec, 2400/1200convolutionfec and quite a number of modes at higher bitrates.


I don't know how much the DVdongle still costs these days. Is it still 200 dollar?


73
kristoff - ON1ARF

[Steve]

On Monday, September 23, 2013 4:29:57 PM UTC-5, kristoff wrote:

Aw! How many does these AOR modems cost? :-)

This is a technique I used on a scanner in the 80's. I removed the CPU and wire-wrapped to a breadboard, and was able to control the scanner using parallel port pins.

The AOR modem is now fully obsolete. I haven't heard anyone on the air in a couple of years. So basically it is not worth anything, except as a breadboard tool. The problem with the AOR was it is too wide-band, and worked equally poor on both FM and SSB.  By deleting the DSP and AMBE chips, it is still a good interface to a radio :-)

[Kristoff Bonne]

Hi Reuven,

On 23-09-13 23:25, Reuven Z Gevaryahu wrote:
> Following up on the other post- The dvDongle source code is available
> (GPLv2 - see http://www.moetronix.com/dvdongle/), and the FEC mode can
> be changed in the software in ambe2000.c, around line 180. For anybody
> daring enough, you can flash the dvDongle with code to make the FEC
> parameters configurable. Note- I don't own one of these and therefore
> have never attempted this.

As far as I remember, you don't really need to change the code in the
DVdongle firmware for this. (perhaps it is just the default
configuration mode that you are looking at).

This is what I found in my own code for the D-STAR voice-announcement
software: (hmm. Source-code of a year and a half ago ... a small wonder
I actually managed to find it :-) )

unsigned char ambe_configframe[] = {0x32, 0xA0,0xEC, 0x13, 0x00, 0x00,
0x30, 0x10, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x48, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0xFF, 0x00, 0x04, 0xF0, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00,
0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x00};
(...)
ret=write (global.donglefd,ambe_configframe,50)


The first octet (0x32) + the 5 LSB bits of the 2nd octet (0xa0) is the
length (0x032 = 50 characters)
0xa0: the 3 MSB bits are the message type: 0b101 = "data item 1".
Page 16 of the "DV Dongle Technical Reference" describes this. That page
also contains the same information as found of page 28 of the
AMBE-2020TM Vocoder Chip User�s Manual.

The rate-info is 0x30, 0x10, 0x00, 0x40, 0x00, 0x00, 0x00, 0x00, 0x48, 0x00.
This is -according table 5D of the User's Manual- 2400 bps + 1200 bps
block-fec.


I think if you just need send a different rate-info to use another rate.
But I do not have access to a dvdongle anymore so I cannot test this.




73
kristoff - ON1ARF

[Mel Whitten]

There are still many of them around... most collecting dust, but I still work stations using the AOR. And it is still being sold today http://www.universal-radio.com/catalog/hamacc/2899.html

 

Mel

 

[Marciniak, Ed]

Wouldn't it be simpler to 'digitally squelch' when the errors exceed a threshold without adding extra complexity?

[Marciniak, Ed]

DVSI offers the ambe codec chips for around $20 each in 100 quantities as I recall from an inquiry a number of years ago.

I'd guess if you asked nicely for a sample chip or two they might offer to send you one or two or at least provide a name for a distributor. I've had luck with that sort of thing before because a certain amount of 'loss' in free samples is still cheaper than bookkeeping (for example getting stuck collecting sales tax in states where they have a rep or a warehouse)

From: Kristoff Bonne
Sent: Monday, September 23, 2013 4:30 PM
To: digita...@googlegroups.com
Reply To: digita...@googlegroups.com