Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

th_uv88 : optional signaling implementation #11110 #916

Open
wants to merge 5 commits into
base: master
Choose a base branch
from

Conversation

velter
Copy link
Contributor

@velter velter commented Feb 10, 2024

Add settings to configure :

  • dtmf
  • 2 tones
  • 5 tones

updated test image file to have a wider variety of settings

- dtmf
- 2 tones
- 5 tones

update test image file to have a wider variety of settings
Copy link
Owner

@kk7ds kk7ds left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not much to complain about, other than asking for space around operators and a few suggestions. Thanks for doing this work!

# Encode channels
for i in range(16): # 0 - 15
sigchan = RadioSettingSubGroup("dtmfencchan%d" % i,
"Channel %02d" % (i+1))
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice use of SubGroup. This is new, I just added it recently, but I think it really helps organize things better. Note that the "FM radio" section of this radio could probably use some similar cleanup, if you feel like it :)

I wish the style checker would complain, but python conventional style is space around operators (so i + 1), with = being the exception when used in parameter lists.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I found the SubGroup while looking at recent commits :) Yes FM settings would also benefit the use of subgroup. I will add this to the #11153 issue

just commited the style fix


def _set_int10(setting, obj, atrb):
vx = float(str(setting.value))
vx = int(vx * 10)
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think you should need these int and float casts here. If you do, maybe there's some work that needs doing elsewhere.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right. Removing the cast do the job.

if bool(setting.value): # Enabled = 1
vx = 1
else:
vx = 0
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think you should be able to just int(setting.value) or just use setting.value without the cast, no? Not sure if you did this out of habit or need, but let me know and I could maybe make some more native fixes so they behave properly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

just copy pasted this code from the myset_mask (used in fm settings). I think this is to be sure that vx is either 0 or 1 because the _do_map function accept also a 2 value which just return the state.
using bool(setting.value) is working and I think it guarantee a value of 0 à 1

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, but int(bool) in python will give you a 0 or 1 and save you three lines. Anyway, I know it's copy/paste, just thought I'd point it out since you asked about pythonic code style :)

@kk7ds
Copy link
Owner

kk7ds commented Feb 23, 2024

This is still marked as draft, so I've been leaving it alone. No pressure, but if/when you're ready for it to merge just un-draft it .

@velter velter marked this pull request as ready for review February 24, 2024 17:36
@velter
Copy link
Contributor Author

velter commented Feb 24, 2024

I just undrafted it as it works well in the current state. I only own a TH-UV88 and got no feedback for RA89/QRZ-1. While those radios ae very close I was not able to do tests.
It seems that there is a conflict due to PR #906 merge. Im' not sure how to resolve these with git.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants