View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001963||3 - Current Dev List||Bug||public||2016-11-15 07:27||2019-08-15 03:57|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||Fixed in Version|
|Summary||0001963: Can't manually log frequencies above 2.3GHz|
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.
|Tags||No tags attached.|
|has duplicate||0001764||closed||K7ZCZ||Ham Radio Deluxe||Logbook - ALE Window Microwave Frequencies Incorrect|
|has duplicate||0001920||closed||K7ZCZ||Ham Radio Deluxe||Logbook will not allow logging of any feq above 9cm (3.456ghz)|
|related to||0003181||resolved||K7ZCZ||2 - Next Dev List (Holding Area)||Logbook requires a database schema migration solution|
||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 ...|
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?
Partially fixed with this checkin; still a lot more work to do.
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.
||Verified by NT9E (one of the requesters).|
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.
||I think that comment #4992 above enumerates most of the work that needs to be done to fully fix this issue.|
This checkin widens a couple of frequency formatting routines to accept 64-bit integers:
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
||Ticket #208701also marked for this Mantis issue|
|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||=> 184.108.40.2060|
|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||220.127.116.110 =>|
|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|