[chirp_devel] Mode designator for YSF?

[Mathias Weyland]

On 2023-01-11 02:17, Dan Smith via chirp_devel wrote:

> Wow, yeah. It sounds to me from the above (correct me if I'm wrong)
> that maybe DN encompasses two things, sort of layer 1 and layer (or
> 7). Layer 1 being the lowest protocol and Layer 7 being some of the
> voice/data/codec stuff , and that VW mode would reuse a lot of layer 1
> but swap out more of the Layer 7 stuff than just "twice as many voice
> packets" (so to speak). Maybe?

I'm not sure if it helps if I lay this out but we can try... So 
basically every single digital Fusion transmission has the following 
structure; each frame is 0.1 s and 960 bits:

Header Frame, Frame, Frame, Frame, ..., Frame, Termination Frame

All frames have the same structure, which is as follows:

frame sync (40) -- frame information (200) -- payload (720).


For DN, the payload of 720 bits comes in two variants. Variante (I) 
consists of 10 sub-frames with 72 bits each. Except for the header and 
termination frame, the payload sub-frames are voice data and metadata 
sent in an alternating fashion. The voice data sub-frames are produced 
by algorithm "A" and the metadata sub-frames are produced by algorithm 
"X". Alternatively, (II) the payload consists of 5 digital voice 
sub-frames of 104 bits and 5 metadata sub-frames of 40 bits, again 
arranged in alternating fashion. The voice sub-frames are produced by 
algorithm "B" (this is not documented by Yaesu and is the part that I 
reverse engineered) and the metadata sub-frames are produced by 
algorithm "Y". "X" and "Y" are very similar and which of the two 
variants is used depends on the amount of metadata that is to be sent.

For VW, the first non-header frame is special and contains metadata 
produced according to algorithm "Z" wich is similar to "X" and "Y". The 
remaining regular frames have a payload that consists of five voice 
sub-frames of 144 bits each, back to back. They are produced by 
algorithm "C". "A" and the algorithm used in DMR to create digital voice 
frames are the same. Algorithms "A" and "B" are moderately similar (we 
can discuss the details but there's probably no point in doing that 
here...). "C" is very different from "A" and "B", yet still based on the 
MBE speech model like all the other ones...

Is that somehow compatible with your layer concept? In my world, the 
layers would be as follows:

0: Physics
1: Modulation scheme
2: Structure of frames
3: Structure of payload into sub-frames
4: "Algorithms"


> Well, I'm not planning to actually expose these as columns in the main
> editor, but options in the RightClick->Properties dialog, like D-STAR
> stuff is now.

I see. What bothers me the most about this approach (and I guess that is 
more important than the technobabble from above): At least around here, 
some repeaters are multimode analog & digital and some others are 
digital only. With the solution you propose, I would want to set the 
multimode ones to DN with the default AMS and the digital only ones to 
DN with no AMS. I would definitely not want to leave AMS on for the 
latter ones, as that would leave me with random analog squelch openings 
when I hit QRM, or it would require met to set up some kind of mock-TSQL 
to avoid that. But what I should do instead is turn AMS off. And 
entering a context menu and property dialog to do that would annoy me 
quite a bit in particular if I would not see the current setting in the 
main editor.

Regards

Matt