View Issue Details

IDProjectCategoryView StatusLast Update
0001963Ham Radio DeluxeBugpublic2020-07-16 07:33
ReporterKB3NPHAssigned ToK7ZCZ 
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version6.7.0.244 
Summary0001963: Can't manually log frequencies above 2.3GHz
DescriptionTicket #722646

In Logbook, if I hit (+) Add button to add a log entry manually, I am unable to enter a frequency in the upper microwave bands.
The data entry converts what I type in to a nonsense value.
Award tracking allows you to have entries for 6cm, 3cm, and smaller wavelengths to 1mm.
Yet you can't enter frequencies up there.
1300.000.000 is fine
2650.000.000 is fine
3500.000.000 gets mapped to 1630.032.704 which is total nonsense
5925.000.000 same nonsense
10368.100.000 gets converted to 1778.165.408 nonsense
24250.000.000 gets converted to 2775.163.520 nonsense
47000.000.000 becomes 4050.327.040 nonsense

You can also try 3.500.000.000 for example, and it converts to nonsense.
TagsNo tags attached.
Testing Beta Successful


has duplicate 0001764 closedK7ZCZ Logbook - ALE Window Microwave Frequencies Incorrect 
has duplicate 0001920 closedK7ZCZ Logbook will not allow logging of any feq above 9cm (3.456ghz) 
related to 0003181 closedK7ZCZ Logbook requires a database schema migration solution 



2017-06-03 21:31

developer   ~0003190

The limit is at 2147483648 Hz, which is 2**31 - 1, which is the limit of a signed 32-bit integer. I'll see if I can figure out where we're using this data type and see what we can do ...


2017-06-04 11:32

developer   ~0003192

Bad news for this one: it turns out that the limitation is essentially system wide.

1) The database is created to store frequency in a NUMBER (limited to 2^31), and should use a LONG NUMBER (with a limit of 2^63).
2) The Frequency edit control is declared to produce and store a UINT (limited to 2^32) and should use a UINT64 (with a limit of 2^64).
3) Might be an issue in XML data exchange, too, but fixing #2 would fix most of the issue with that.

This is a pretty big change, since fixing it means changing the database schema. Certainly, the team has done this before -- what mechanism do we have for migrating database schema between versions of the product, so upgrading users have their database rebuilt with the correct schema?


2018-04-30 23:51

developer   ~0004913

Partially fixed with this checkin; still a lot more work to do.


2018-05-10 19:44

developer   ~0004992

Here's what I can think of:

1) Find all places where input is accepted from Frequency Edit control. Widen it to 64 bits.

2) Repair, rewrite, or wrap locations where 32-bit frequencies are passed with Windos messages. This will probably be the most difficult (error prone) area, since the late-bound nature of Windows messages makes it hard to get compiler verification of changes.

3) Widen communication between app components (most notably, XML files) to be sure that 64-bit values are transferred correctly.

4) Widen the Frequency and RxFrequency columns in the database. code that creates the QSO table uses FLOAT or INTEGER depending on the database vendor type (INTEGER for Access and MySQL, FLOAT for others). There is no existing schema migration code in the product applicable to this issue. We should have it for the general case.

5) Verify that comparisons and tests against frequences (bands, awards) are functioning

6) figure out how 64-bit frequencies are sent to radios; any SDRs support high frequenceis, for instances? Down converters?

Each is a couple days work, execpt for 4, which is a substantial project.


2018-06-01 13:20

administrator   ~0005170

Verified by NT9E (one of the requesters).


2018-06-03 21:32

administrator   ~0005191

After hearing from Mike (K7ZCZ), it seems that the Requester was incorrect when he validated this.

As a result, I'm reopening it and putting it back to Assigned status in the Current Dev project.


2018-06-05 18:13

developer   ~0005211

I think that comment #4992 above enumerates most of the work that needs to be done to fully fix this issue.


2019-01-19 10:27

developer   ~0007029

This checkin widens a couple of frequency formatting routines to accept 64-bit integers:


2019-05-01 09:26

viewer   ~0007900

I went through and setup and added a frequency range as suggested by Tim. Once this was accomplished. I got the same result as the customer.

Also reference ticket 685859


2019-08-15 03:57

viewer   ~0008409

Ticket #208701also marked for this Mantis issue


2019-09-25 08:28

developer   ~0008657

In the team call on 2019-09-19, this issue was identified as not a priority. Note, though, that with the resolution 3181 and some of the previous check ins, this work is mostly complete.


2019-09-25 15:06

administrator   ~0008672

If work towards a resolution has already been done, of course we don't want to discontinue working on this. Our discussion during the 2019-09-19 call again was for Mike B to set his own priority level on this. Since 3181 has been resolved and has brought us closer to a total resolution on this, it's ridiculous to halt all work on this, especially if it's noted that other issues can put us in a position to totally resolve this problem in the very near future. Our discussion on this also noted that the majority of the complaints about this issue came from European stations.


2020-07-16 07:33

administrator   ~0009798

I re-tested this in the build. I manually logged all allocated frequency bands 2.3Ghz and above. I found them all to be working as expected.

Issue History

Date Modified Username Field Change
2016-11-15 07:27 KB3NPH New Issue
2017-05-23 15:23 WA9PIE Severity minor => feature
2017-06-03 21:31 K7ZCZ Note Added: 0003190
2017-06-03 21:31 K7ZCZ Assigned To => K7ZCZ
2017-06-03 21:31 K7ZCZ Status new => assigned
2017-06-04 11:32 K7ZCZ Note Added: 0003192
2017-06-04 11:32 K7ZCZ Relationship added has duplicate 0001764
2017-06-30 18:47 K7ZCZ Relationship added related to 0001814
2018-04-26 07:41 K7ZCZ Relationship deleted related to 0001814
2018-04-26 07:41 K7ZCZ Relationship deleted has duplicate 0001764
2018-04-26 07:45 K7ZCZ Relationship added has duplicate 0001764
2018-04-26 07:45 K7ZCZ Relationship added has duplicate 0001920
2018-04-30 23:51 K7ZCZ Note Added: 0004913
2018-05-10 19:44 K7ZCZ Note Added: 0004992
2018-06-01 13:20 WA9PIE Project 2 - Next Dev List (Holding Area) => 3 - Current Dev List
2018-06-01 13:20 WA9PIE Status assigned => closed
2018-06-01 13:20 WA9PIE Resolution open => fixed
2018-06-01 13:20 WA9PIE Fixed in Version =>
2018-06-01 13:20 WA9PIE Testing => Not Started
2018-06-01 13:20 WA9PIE Note Added: 0005170
2018-06-01 13:21 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe
2018-06-03 21:32 WA9PIE Status closed => assigned
2018-06-03 21:32 WA9PIE Resolution fixed => reopened
2018-06-03 21:32 WA9PIE Fixed in Version =>
2018-06-03 21:32 WA9PIE Note Added: 0005191
2018-06-03 21:32 WA9PIE Project Ham Radio Deluxe => 3 - Current Dev List
2018-06-05 18:13 K7ZCZ Note Added: 0005211
2019-01-19 10:27 K7ZCZ Note Added: 0007029
2019-02-16 18:08 K7ZCZ Relationship added related to 0003181
2019-05-01 09:26 KC7FPF Note Added: 0007900
2019-05-09 14:18 WA9PIE Severity feature => minor
2019-05-09 14:18 WA9PIE Category Enhancement => Bug
2019-08-15 03:57 PD9FER Note Added: 0008409
2019-09-25 08:28 K7ZCZ Note Added: 0008657
2019-09-25 15:06 KB3NPH Note Added: 0008672
2020-07-02 02:20 WA9PIE Project 3 - Current Dev List => 2 - Next Dev List (Holding Area)
2020-07-16 07:31 WA9PIE Project 2 - Next Dev List (Holding Area) => Ham Radio Deluxe
2020-07-16 07:33 WA9PIE Status assigned => closed
2020-07-16 07:33 WA9PIE Resolution reopened => fixed
2020-07-16 07:33 WA9PIE Fixed in Version =>
2020-07-16 07:33 WA9PIE Testing Not Started => Beta Successful
2020-07-16 07:33 WA9PIE Note Added: 0009798