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.

Sign up for GitHub

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

Jump to bottom

Frequency rounding error #249

Closed
endrec opened this issue Sep 11, 2022 · 6 comments
Closed

Frequency rounding error #249

endrec opened this issue Sep 11, 2022 · 6 comments
Assignees
@hmatuschek
Labels
enhancement New feature or request
Milestone
Version 0.12.0

Comments

@endrec
Copy link

endrec commented Sep 11, 2022 •
edited
Loading

Frequencies are converted to string with a small rounding error:

# [...]
channels:
# [...]
  - analog:
      id: ch14
      name: A-V16-145.2000
      rxFrequency: 145.19999999999999
      txFrequency: 145.19999999999999
      # [...]
  - analog:
      id: ch15
      name: A-V17-145.2125
      rxFrequency: 145.21250000000001
      txFrequency: 145.21250000000001
      # [...]
  - analog:
      id: ch16
      name: A-V18-145.2250
      rxFrequency: 145.22499999999999
      txFrequency: 145.22499999999999
      # [...]
  - analog:
      id: ch17
      name: A-V19-145.2375
      rxFrequency: 145.23750000000001
      txFrequency: 145.23750000000001
      # [...]
  - analog:
      id: ch18
      name: A-V20-145.2500
      rxFrequency: 145.25
      txFrequency: 145.25
# [...]

qdmr displays them correctly:
image

image

The issue does not seem to have any adverse effect so far, so it's only cosmetics. :)
Built from bc79685, and tested with AT878UV II.
@hmatuschek
Copy link
Owner

It does not, as the frequency is usually encoded as an integer in multiple of 10Hz in the binary codeplugs. However, the yaml file gets ugly. This issue is hard to solve for now, as the frequency is actually stored as a double precision floating point number. I would need to touch a lot of code to change that to an uint64_t (in case there are frequencies above 4Ghz to be stored). However, I know that there is this issue and if I find time, I'll fix it. So, lets keep that issue open to remind me.

@hmatuschek hmatuschek added the enhancement New feature or request label Sep 26, 2022
@hmatuschek hmatuschek added this to the Version 0.12.0 milestone Jan 11, 2023
hmatuschek added a commit that referenced this issue Jan 14, 2023
@hmatuschek
Implemented YAML parsing and encoding of integer frequencies. Addresses
dc6e49a 
#249.
@hmatuschek
Copy link
Owner

Working on it in the integer-frequencies branch.

@hmatuschek hmatuschek self-assigned this Jan 14, 2023
hmatuschek added a commit that referenced this issue Jan 14, 2023
@hmatuschek
Fixed channel dialogs. Addresses #249.
d70f495
hmatuschek added a commit that referenced this issue Jan 15, 2023
@hmatuschek
Fixed roaming channel frequencies to be stored in Hz. Addresses #249.
b0cc967
hmatuschek added a commit that referenced this issue Jan 15, 2023
@hmatuschek
Cleanup. Fixes #249.
d56a819
hmatuschek added a commit that referenced this issue Jan 15, 2023
@hmatuschek
Fixed codeplug encoding/decoding, addresses #249.
fac8ce4
@hmatuschek
Copy link
Owner

Should be work now. If you like, you can test the integer-frequency branch. This issue will be closed automatically when I merge the branch into mast.

@endrec
Copy link
Author

endrec commented Jan 15, 2023 via email

@hmatuschek hmatuschek mentioned this issue Jan 30, 2023
Merged
hmatuschek added a commit that referenced this issue Jan 30, 2023
@hmatuschek
Integer frequency (#292)
ba935da 
* Implemented YAML parsing and encoding of integer frequencies. Addresses #249.
* Fixed ChannelListWrapper to display integer frequencies in MHz.
* Fixed channel dialogs. Addresses #249.
* Fixed roaming channel frequencies to be stored in Hz. Addresses #249.
* Fixed codeplug encoding/decoding, addresses #249.
* Added some unittest.
* Fixed unit tests.
@hmatuschek hmatuschek mentioned this issue Feb 11, 2023
Closed
hmatuschek added a commit that referenced this issue Jul 5, 2023
@hmatuschek
Added anytone settings extension for FM APRS systems. Addresses #249.
1566e6b
hmatuschek added a commit that referenced this issue Aug 14, 2023
@hmatuschek
Fix update anytone FM arps settings (#363)
ba64a9a 
* Documented changes in the APRS settings encoding. Addresses #349.
* Fixed exisiting props of APRSSettings.
* Merged FM and DMR APRS settings. Fixed frequency issue. Addresses #349.
* Fixed APRS settings for DMR6X2UV.
* Cleanup of DMR6X2UV codeplug.
* Fixed crash in D878UV read. Addresses #349.
* Added anytone settings extension for FM APRS systems. Addresses #249.
* Implemented FM APRS frequency list and experimental storage of labels. Addresses #349.
* Added some docs for FM APRS settings extension. Addresses #394.
* Fixed missing encoding/decoding of report flags for Anytone APRS settings extension.
* Fixed decoding of D878UV codeplugs of older DFU images.
@allesand
Copy link

allesand commented Oct 5, 2023

@hmatuschek Since devel branch now uses integer frequencies (as seen in #385 ), can this considered to be solved or wait for 0.12? (Trying to reduce the number of open issues..) Ah, in #306 you said this will be closed on release?

@hmatuschek
Copy link
Owner

No, it will not close automatically. So I close it now. Will be part of the 0.12.0 release, currently in the devel branch.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@hmatuschek hmatuschek

Labels
enhancement New feature or request
Projects
None yet
Milestone
Version 0.12.0
Development

No branches or pull requests
3 participants
@endrec @hmatuschek @allesand