Re: [chirp_devel] Mode designator for YSF?
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
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.
Yeah, well, CHIRP has always been a bit sparse on the main editor, with multiple device-specific things in the properties dialog on memories. For someone that uses an FT2D for FM and APRS, they don't need to see all the digital stuff anyway. The Yaesu software (like many others) kinda ridiculously scrolls to the right forever because they have every possible thing visible all the time.
Anyway, the thing I'm trying to resolve here is not the UI aspect (yet), but the compatibility one. In order to enable copying one of these memories between two radios that both support YSF, we need a common, unique, and meaningful mode designator. D-STAR is a system, but DV is very clearly the mode that I'm looking for. The more I dig into the radio, their software, the manual, and your brain, the more I realize YSF is, well, not very clear-cut here. Regardless, CHIRP as an abstraction needs to call it something and I think DN for the basic case is what we should use. Messing with the radio a bit, I see that when VW is enabled, they show "VW" as the mode very clearly. So perhaps that means we really do need to add VW to the top-level list of modes as well, I dunno.
The UI aspect of exposing all (or the most important) device-specific characteristics of a memory in the main memory editor is something we can improve separately, but it brings all kinds of issues as well like bubbling up YSF-specific (or D-STAR or DMR) "rules" into the presentation layer that have to be wrangled. But even still, the mode designator for compatibility between radios, repeater directories, etc is necessary and where we need to start I think.
In the (most recent) bug asking for YSF support, the reporter even said "forget the analog bit, just call it DN and make it digital always". I guess in his area, they don't do the multi-mode part much :)
--Dan
participants (2)
-
Dan Smith -
Mathias Weyland