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