¿ªÔÆÌåÓý

sBitx Logging issue


 

OK - this logging issue is easy to duplicate. When either signal report is entered with either Sent or Received values positive, and without a leading "+" sign, the logging routine will reject the logging attempt for "log entry is empty".

And - it looks like the FT8 code is not adding that leading "+" sign to the Sent field, which just aggravates the problem.

Will have a look at the code later today.

73; Steve, N3SB


 

Additional testing - so a single digit positive number like "5" will be rejected, but a two digit number like "05" is accepted. The number "15" is accepted and logged as a 15, and the number " 5" (with a leading space) is accepted and logged as a 5.

Seems that the SW doesn't like a single digit number in either Sent or Received fields.

Will look at the code later today.

73; Steve, N3SB


 

Steve,
Your logic makes sense. Yes, you'll encounter some more oddities.
For example, long callsigns are recorded as <...> in the log, but the same is true on the screen.
Also, if there is no GRID at the CQ station, it is recorded as 73 or RR73.

I wish you patience, because I don't think it will be easy for you.
--
Gyula HA3HZ


 

On Tue, Jan 2, 2024 at 10:39 AM, HA3HZ wrote:
I wish you patience, because I don't think it will be easy for you.
Some people are meant to find failing capacitors, others to fix buggy code.?

It's wonderful to watch both in action.
?
--
Regards,
Dave, N1AI


 

Hi Gyula;

In file sbitx_gtk.c, line # 1342 (approximate) you will find the line of code:

?? if (strlen(callsign) < 3 || strlen(rst_sent) < 2 || strlen(rst_received) < 2){

Replace the two occurrences of the number 2 with the number 1, so that you end up with:

?? if (strlen(callsign) < 3 || strlen(rst_sent) < 1 || strlen(rst_received) < 2){

Then rebuild and try.

73; Steve, N3SB


 

My fat fingers got me into trouble - the code should be modified to:

?? if (strlen(callsign) < 3 || strlen(rst_sent) < 1 || strlen(rst_received) < 1){

N3SB - Paying the price for responding too fast.......


rdg
 

Steve -

We have so far fingered and/or failed to proofread, not to worry.?

Question¡­as I don¡¯t have the code in front of me. ?Are there numeric range?checks following the strlen checks? ?

Thx
73, Roy


Sent from for iOS


On Tue, Jan 2, 2024 at 10:32, Steve Beckman via groups.io <n3sb@...> wrote:
My fat fingers got me into trouble - the code should be modified to:

?? if (strlen(callsign) < 3 || strlen(rst_sent) < 1 || strlen(rst_received) < 1){

N3SB - Paying the price for responding too fast.......


 

Hi Roy - It doesn't appear that there are numeric range checks. In fact there's no requirement that the fields are numbers.

You can actually log a value such as 5NN or None - it does not matter. You just cannot leave the CALL, SENT, or RECV fields blank.

The EXCH and NR fields can be left blank, or you can log the other op's name and state abbreviation or section abbreviation (for example) if you wanted.

73; Steve, N3SB


 

On Tue, Jan 2, 2024 at 05:32 PM, Steve Beckman wrote:
My fat fingers got me into trouble - the code should be modified to:

?? if (strlen(callsign) < 3 || strlen(rst_sent) < 1 || strlen(rst_received) < 1){

N3SB - Paying the price for responding too fast.......
Steve,
I'm just letting you know that I'm testing it with the changes in pull request #69, #70, and #71.
Out of 6 qso's, 6 LOG saves were made.
I had a problem because one of the stations did not acknowledge my report, so I would like to delete it, but this is not directly possible.
Only with DB Browser (SQLite) and afterwards.
?
--
Gyula HA3HZ


 

It seems that something is still interfering with saving the log file.
It couldn't record twice today, even though I've only been testing it for two hours.
It records those who respond to its own CQ, unless something interferes.
I uploaded a video where it was recorded, but the valid connection was not established.
This cannot be deleted without a utility.
link:

--
Gyula HA3HZ


 

Hi Gyula;

I think you may have grabbed and incorporated the two source files I sent you early yesterday --BEFORE-- we discovered the one line source code change.

Please check sbitx_gtk.c, near line # 1342.

?? if (strlen(callsign) < 3 || strlen(rst_sent) < 2 || strlen(rst_received) < 2){

Replace the two occurrences of the number 2 with the number 1, so that you end up with:

?? if (strlen(callsign) < 3 || strlen(rst_sent) < 1 || strlen(rst_received) < 1){

Then rebuild and try.

73; Steve, N3SB


 

Steve,
Sorry, I think the problem is that this morning I found a zip file in my account, I unzipped it and overwrote yesterday's. It lacks this override. :-(
--
Gyula HA3HZ


 

Gyula - since the files I sent you early yesterday morning had a bunch of debugging info that is no longer required, recommend you retrieve the original two files from? the sbitx github then make the change to the one line we identified yesterday and re-build.

You're going to have to start at the beginning, and make 100 QSOs to verify the change....??? ;-)

73; Steve, N3SB


 

Steve,
I think I have 100 QSOs.
The sbitx_gtk.c file you modified is still working fine and logging connections.
Thanks for your work.

I found a few more things, if you have time please check them out:
When I call a CQ station and the report change happens, it logs it.
When the <mycall call 73> message comes, my machine wants to give an answer report again.
This sounds a little silly, but it's not the first time it's happened.
I think maybe the program uses the same logic for its own CQ and the other's CQ.
This is where the problem comes from. In such cases, it may be sufficient to exclude the possibility of answering.
I'm just thinking out loud.
--
Gyula HA3HZ