View Issue Details

IDProjectCategoryView StatusLast Update
00019633 - Current Dev ListBugpublic2019-08-15 03:57
ReporterKB3NPHAssigned ToK7ZCZ 
PrioritynormalSeverityminorReproducibilityhave not tried
Status assignedResolutionreopened 
Product Version 
Target VersionFixed in Version 
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.
TestingNot Started


has duplicate 0001764 closedK7ZCZ Ham Radio Deluxe Logbook - ALE Window Microwave Frequencies Incorrect 
has duplicate 0001920 closedK7ZCZ Ham Radio Deluxe Logbook will not allow logging of any feq above 9cm (3.456ghz) 
related to 0003181 resolvedK7ZCZ 2 - Next Dev List (Holding Area) Logbook requires a database schema migration solution 



2017-06-03 21:31

administrator   ~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

administrator   ~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

administrator   ~0004913

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


2018-05-10 19:44

administrator   ~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

administrator   ~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

administrator   ~0007029

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


2019-05-01 09:26

updater   ~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

updater   ~0008409

Ticket #208701also marked for this Mantis issue

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