Start a new topic

Logbook is not able to store higher frequency than 2145Mhz

 Hello.

I started to work via QO-100 Satellite.

Transmitting on 13cm band - 2400 - 2400.500 and receive on 10GHz.

There is a bug in logbook. I t is not able to store higher frequency than approx 2145MHz. If I enter higher than this i.e. 2400.345 MHz for SO-100 Satellite, it converts it to something around 2145MHz. Fortunately band is assigned correctly, but for shorter waves than 13 cm it will be also band problem probably.


Any chance to get in fixed in next coming releases?




Hello Marcin,


this is not a bug but a basic issue of HRD logbook. The frequency value is stored as  a LONG INTEGER type in the access database. LONG INTEGER is a 4-byte value. So it can store values between -2.147.483.648 and +2.147.483.647 only (see here).


My work-around is: I enter the correct freq value, so that the band will be determined correctly and store the QSO. After that I open the QSO record again and delete the frequency. Then I can upload the QSO records to LOTW and eQSL.cc.


But don't forget to fill the fields PROP_MODE and SAT_NAME before uploading.


73

Wolf, DL6JZ

Hello Marcin,


this is not a bug but a basic issue of HRD Logbook. The fieldFREQ is stored as a Long Integer data type in the MS Access database. Long Integer means that 4 bytes are used to store the Frequency inthe computer memory. So there can be stored data between -2.147.483.648 and +2.147.483.647 only (see here).


My work around is: I enter the frequency in the ALE window so that the band is determined correctly and save the QSO record. After that I open it again and delete the frequency, the band will be saved. Then I upload the QSO records to LOTW and eQSL.cc.


But don't forget to fill the fields Prop Mode in  Propagation tab and Satellite Name in the Ant/Sat tab.


73

Wolf, DL6JZ

 

Hello Marcin,


this is not a bug but a basic issue of HRD Logbook. The fieldFREQ is stored as a Long Integer data type in the MS Access database. Long Integer means that 4 bytes are used to store the Frequency inthe computer memory. So there can be stored data between -2.147.483.648 and +2.147.483.647 only (see here).


My work around is: I enter the frequency in the ALE window so that the band is determined correctly and save the QSO record. After that I open it again and delete the frequency, the band will be saved. Then I upload the QSO records to LOTW and eQSL.cc.


But don't forget to fill the fields Prop Mode in  Propagation tab and Satellite Name in the Ant/Sat tab.


73

Wolf, DL6JZ

 

Hello Marcin,


this is not a bug but a basic issue of HRD Logbook. The fieldFREQ is stored as a Long Integer data type in the MS Access database. Long Integer means that 4 bytes are used to store the Frequency inthe computer memory. So there can be stored data between -2.147.483.648 and +2.147.483.647 only. You can goole for "Long Integer".


My work around is: I enter the frequency in the ALE window so that the band is determined correctly and save the QSO record. After that I open it again and delete the frequency, the band will be saved. Then I upload the QSO records to LOTW and eQSL.cc.


But don't forget to fill the fields Prop Mode in  Propagation tab and Satellite Name in the Ant/Sat tab.


73

Wolf, DL6JZ

Thanks Wolf for information.

Would it be difficult to change frequency field to unsigned long in the next release?

Frequency is naver negative, so it would not cause previous entries to be displayed incorrectly, but maximum number would increase to twice as much.

It would be not enough for 3 cm band, but OK fo 13cm.


At the moment bands are determined correctly, since +2.147.483.647 calculates band 13cm correctly, so the only qrg is stored incorrectly. It could be deleted as You suggested or left as it is.

Just to remember to not show qrg on qsl cards, but use band only instead.


Hello Marcin,


I am not a software developer but I have some experience in database management and basic programming.


To change the type of a field in a database table is not difficult for an experienced computer user. But this change has to be done in ALL user databases and there are not only experienced computer users out there.  So this can be a problem.


If the software code itself is strictly database oriented changes in the program routines shoul be necessary in formatting commands only. But there a lot of them in HRD, I think.


And a change into Unsigned Long Integer would allow correct frequency values up to the 13CM band only. And radio amateurs use frequencies up to 47 GHz.


73

Wolf, DL6JZ



Hi.


So it is an issue for developers.

Up to 13 cm band is much better than only below 13 cm. Change signed to unsigned looks minor and simple .

Correct way could be to store frequencies as text, but such change could require to supply users with database migration tool.

Also possible to split large number to 2 variables / fields. below 13 cm, more significant part will be zero and on and above 13 cm will be more significant part. Then it couldn't affect old data.

Also change in the software to check both fields and react accordingly.

There is many ways to overcome such limitations.


Anyway. HRD a few years ago migrated to new database as far as I remember. Maybe now is a time to make such step to open way for the future for this software.

Ham radio software which doesn't support all available bands is not "the best class".





Any news, plans to solve this problem?

I purchased commercial program HRD and have to use free logger32 for QO-100 satellite. It i curious isn't it?



Login or Signup to post a comment