The User Guide has been updated.
The other change will take longer to implement, but I think is needed, so hopefully be in the next Beta release
Channel timeslot confusion
Re: Channel timeslot confusion
BTW.
If the TS override system needs to have modes of operation, they could not be described as Ct override or User override, because that's not how it currently works.
If you press * to change the current TS and then change to a Contact / TG that has a TS override, the radio will switch to that TS as priority over the TS set by pressing *
So it effectively already has Contact TS priority.
I don't think that many people would want the radio to ignore the Contact TS priority just because they have changed the TS using * at some time in the past, and not cleared that override.
As far as I can see the other mode of operation would be for the Contact TS to be copied to the Override TS (as if the * had been pressed to change the TS).
I guess there could be 4 or 5 different modes of operation
1. Ignore Contact TS override:
2. Use the existing functionality, where the manual TS override is stored independently of the Contact TS override, so that for Contacts with no TS override, the TS would be the manual override TS, or if no manual override TS was set, then the Channel TS would be used.
3. Always use the manual override TS (set by pressing *), even if the Contact has a TS override.
4. The manual override value is updated from the Contact TS override when you change to a Contact /TG with a TS override.
5. The manual override is cleared when you change to a Contact which has a TS override, but the TS from the Contact is used until you change TG to one which does not have a TS override.
I think option 5 is probably even more confusing than the existing logic, and I can't see a Use Case for it.
Option 1 would also be fairly pointless, as the operator could simply remove the override from the Contact, and I can't see a Use Case for temporarily disabling all the Contact TS overrides.
I can see a Use Case for option 4, which is a kind of "follow" or "retain" option, so that once a TS is set from a Contact of manually, the firmware uses that TS until either you change to a TG which has a different override TS or you press * to manually change the TS.
Personally, I think I would probably use option / mode 4 in preference to the current system, even though ultimately the existing system is more logical.
Also, perhaps the Info setting should be defaulted to display the contact TS override if one has been set, as this is not displayed in bold text, so I don't expect anyone to object on text readability grounds.
If the TS override system needs to have modes of operation, they could not be described as Ct override or User override, because that's not how it currently works.
If you press * to change the current TS and then change to a Contact / TG that has a TS override, the radio will switch to that TS as priority over the TS set by pressing *
So it effectively already has Contact TS priority.
I don't think that many people would want the radio to ignore the Contact TS priority just because they have changed the TS using * at some time in the past, and not cleared that override.
As far as I can see the other mode of operation would be for the Contact TS to be copied to the Override TS (as if the * had been pressed to change the TS).
I guess there could be 4 or 5 different modes of operation
1. Ignore Contact TS override:
2. Use the existing functionality, where the manual TS override is stored independently of the Contact TS override, so that for Contacts with no TS override, the TS would be the manual override TS, or if no manual override TS was set, then the Channel TS would be used.
3. Always use the manual override TS (set by pressing *), even if the Contact has a TS override.
4. The manual override value is updated from the Contact TS override when you change to a Contact /TG with a TS override.
5. The manual override is cleared when you change to a Contact which has a TS override, but the TS from the Contact is used until you change TG to one which does not have a TS override.
I think option 5 is probably even more confusing than the existing logic, and I can't see a Use Case for it.
Option 1 would also be fairly pointless, as the operator could simply remove the override from the Contact, and I can't see a Use Case for temporarily disabling all the Contact TS overrides.
I can see a Use Case for option 4, which is a kind of "follow" or "retain" option, so that once a TS is set from a Contact of manually, the firmware uses that TS until either you change to a TG which has a different override TS or you press * to manually change the TS.
Personally, I think I would probably use option / mode 4 in preference to the current system, even though ultimately the existing system is more logical.
Also, perhaps the Info setting should be defaulted to display the contact TS override if one has been set, as this is not displayed in bold text, so I don't expect anyone to object on text readability grounds.
Re: Channel timeslot confusion
Hi Roger.VK3KYY wrote: ↑Sun Feb 28, 2021 2:56 amI can see a Use Case for option 4, which is a kind of "follow" or "retain" option, so that once a TS is set from a Contact of manually, the firmware uses that TS until either you change to a TG which has a different override TS or you press * to manually change the TS.
Personally, I think I would probably use option / mode 4 in preference to the current system, even though ultimately the existing system is more logical.
I have the same opinion.
However I think that it can work well with normal TGs, rather than with those which are intended for special purposes such as disconnection (TG4000), status (TG5000), parrot (TG9990), and so on: with this last ones the matter is more complicated.
As things are now any TG programmed in the codeplug that has his timeslot, does not matter if like TS# or cS#, exhibits a different behavior depending on whether the override option is enabled or not.
In the same scenario the same TG inserted manually (by pressing #) has a still different behavior depending on whether it is typed on the fly or taken from pre-existing contacts in the codeplug.
It can therefore happen that using a given TG that has a given timeslot, for example going to perform a disconnection (TG4000) by manually entering it from the keyboard (by pressing #) the resulting timeslot will be the same as that of the TG in use, while taking it from the contacts not necessarily the timeslot it would be the desired one, it may be necessary to adjust it manually (by pressing *).
Not that the thing is to be considered a problem, not being too tiring nor complicated to adjust the timeslot so that it is the right one.
In the end it would only be necessary to pay a little more attention.
However, it would be more logical than in any circumstance (ie always), using a given TG and wanting to make a disconnection (TG4000), a status check (TG5000), try an echotest on the repeater (Parrot TG9990) and so on, the timeslot remains the same of the TG in use without the need to pay attention to it and possibly having to retouch it (by pressing *).
With the normal TGs the matter is pretty different and much simpler because once the timeslot has been selected there would be no need to modify it if not if you decide to change TG.
Therefore in those cases it would be necessary to set the timeslot only once without worrying that it can change unexpectedly, unless you decide to use TGs belonging to the special type described above.
These are simply and only thoughts, not a criticism, nor are these thoughts a change request for the firmware.
They are only a mere thoughts, nothing else.
73 best regards de Fabio IZ2EIB