Closed endrec closed 11 months ago
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.
Working on it in the integer-frequencies
branch.
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.
Thanks, I can't test it right now, so I'll trust you that it works. :)
Hannes Matuschek @.***> ezt írta (időpont: 2023. jan. 15., V, 12:31):
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.
— Reply to this email directly, view it on GitHub https://github.com/hmatuschek/qdmr/issues/249#issuecomment-1383139176, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAAY3KLVU57WPLL5NGUFJX3WSPUZFANCNFSM6AAAAAAQJ2IXC4 . You are receiving this because you authored the thread.Message ID: @.***>
@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?
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.
Frequencies are converted to string with a small rounding error:
qdmr displays them correctly:
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.