Announcement

Collapse
No announcement yet.

HRD is STILL broken for ADIF exports after over 4 years

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • K7RFW
    replied
    Re: HRD is STILL broken for ADIF exports after over 4 years

    This is only for the logbook to ADIF file export, the ADIF export file is modified from what the logbook database contains. The import from ADIF to the database does not modify the fields in question.

    See my post of 28 March 2015 at 12:47 in this thread, it has two jpegs of the ALE before I add the QSO to the database, the exported ADIF, and the logbook text dump (.CSV) for two different contest entry types (123 0123 and 1E UT). There is only one place I am aware of (DM780 and HRD) that fills SRX_STRING/STX_STRING and it fills them for ALL forms of exchanged data exactly as typed in, SRX/STX are not filled.

    As stated for several years now, if you fill the sent/received information field with a string starting with a numeric, the ADIF export splits off the leading numerics and places them in SRX/STX, if a NON-numeric is seen, then the parsing of the sent/received string to SRX/STX stops and the remainder is sent to SRX_STRING/STX_STRING except if the first non numeric is a space then the space is skipped until an alpha-numeric is seen (do not know if space is the only 'special' character).

    As far as I know, inputs from the logbook database starting with an alpha parse correctly to the ADIF SRX_STRING/STX_STRING and purely numerics will parse to the ADIF SRX/STX as noted above.

    This did not cause an issue in the original HRD because
    1. 4.x had a true database file merge feature instead of using export then import via adif to merge databases.
    2. 4.x exported the entire exchange to adif as <rst_sent:9> or <rst_rcvd:9>599 1E UT (yes, not the current standard).
    3. Cabrillo mostly worked with minor edits at least for what I used.

    Leave a comment:


  • W4PC
    replied
    Re: HRD is STILL broken for ADIF exports after over 4 years

    Which field in the ALE are you using for SRX_STRING.

    Leave a comment:


  • K7RFW
    replied
    http://www.ham-radio-deluxe.com
    #
    # Created: 28-Mar-2015 12:08:21
    #
    #--

    <ADIF_VERS:3>2.2
    <PROGRAMID:14>HamRadioDeluxe
    <PROGRAMVERSION:17>Version 6.2.8.324
    <EOH>

    <address:5>Chile <a_index:3>0.0 <ant_az:3>0.0 <ant_el:3>0.0 <band:3>20m <call:6>CE2YTR <cont:2>SA <country:5>Chile
    <cqz:2>12 <distance:8>9256.604 <dxcc:3>112 <eqsl_qsl_rcvd:1>N <eqsl_qsl_sent:1>N <force_init:1>N <freq:9>14.235000
    <ituz:2>14 <k_index:3>0.0 <lat:11>N000 00.000 <lon:11>E000 00.000 <lotw_qsl_rcvd:1>N <lotw_qsl_sent:1>N
    <mode:4>RTTY <my_city:6>Layton <my_cnty:5>Davis <my_country:13>United States <my_cq_zone:1>3 <my_gridsquare:6>DN41ac
    <my_itu_zone:1>6 <my_lat:11>N041 06.250 <my_lon:11>W111 57.500 <my_name:3>Ray <my_postal_code:5>84040
    <my_rig:62>FT897D, N8XJK booster, 50 Ah Battery, 10 Amp PS, SignaLink USB <my_state:2>UT <my_street:13>2141 E 2200 N
    <pfx:3>CE2 <qsl_rcvd:1>N <qsl_sent:1>N <qso_complete:1>Y <qso_random:1>N <qth:5>Chile <rst_rcvd:3>599
    <rst_sent:3>599 <rx_pwr:3>0.0 <sfi:3>0.0 <srx:3>123 <srx_string:4>1805 <station_callsign:5>K7RFW <stx:3>010
    <stx_string:4>1806 <swl:1>N <time_off:6>180716 <time_on:6>180604 <tx_pwr:6>35.000 <qso_date:8>20150328 <EOR>

    <address:13>United States <a_index:3>0.0 <ant_az:3>0.0 <ant_el:3>0.0 <band:3>20m <call:5>W6SJV <cont:2>NA
    <country:13>United States <cqz:1>5 <distance:8>1250.180 <dxcc:3>291 <eqsl_qsl_rcvd:1>N <eqsl_qsl_sent:1>N
    <force_init:1>N <freq:9>14.235000 <ituz:1>6 <k_index:3>0.0 <lat:11>N000 00.000 <lon:11>E000 00.000 <lotw_qsl_rcvd:1>N
    <lotw_qsl_sent:1>N <mode:4>RTTY <my_city:6>Layton <my_cnty:5>Davis <my_country:13>United States <my_cq_zone:1>3
    <my_gridsquare:6>DN41ac <my_itu_zone:1>6 <my_lat:11>N041 06.250 <my_lon:11>W111 57.500 <my_name:3>Ray
    <my_postal_code:5>84040 <my_rig:62>FT897D, N8XJK booster, 50 Ah Battery, 10 Amp PS, SignaLink USB <my_state:2>UT
    <my_street:13>2141 E 2200 N <pfx:2>W6 <qsl_rcvd:1>N <qsl_sent:1>N <qso_complete:1>Y <qso_random:1>N <qth:13>United States
    <rst_rcvd:3>599 <rst_sent:3>599 <rx_pwr:3>0.0 <sfi:3>0.0 <srx:2>12 <srx_string:5>A SJV <station_callsign:5>K7RFW
    <stx:1>1 <stx_string:4>E UT <swl:1>N <time_off:6>180543 <time_on:6>180436 <tx_pwr:6>35.000 <qso_date:8>20150328 <EOR>
    Attached Files

    Leave a comment:


  • K7RFW
    replied
    Re: HRD is STILL broken for ADIF exports after over 4 years

    Screen shot of what Mike? ADIF record, XML record, DM780 with the various/particular windows (add, text, etc)?

    Ray

    Leave a comment:


  • wa9pie
    replied
    Re: HRD is STILL broken for ADIF exports after over 4 years

    Can you give us a screenshot of one of your QSOs showing what fields the data is in?

    Mike, WA9PIE

    Leave a comment:


  • K7RFW
    replied
    Re: HRD is STILL broken for ADIF exports after over 4 years

    Ok, I am not so upset since I found a simple (a DUH! moment) way to get back where I started. To reparse <srx:3>640 <srx_string:4>0158 back into srx_string I first replaced all <srx_string:4> with a blank string, that gave me <srx:3>640 0158. Then I replaced <srx:3> with <srx_string:8> and now have <srx_string:8>640 0158 (same for stx). Not very hard once I thought a bit and started seeing the trees instead of the forest, and only one QSO had over 999 contacts. Hope that works with Field Day (may be more combinations, but better than doing line by line like I did last time!)

    Wish my stuff at work was that easy/symmetrical.

    Leave a comment:


  • HRD is STILL broken for ADIF exports after over 4 years

    Since the demise of version 4, this has been an issue. At Dayton in 2012 (I think that was the year of the delayed first V4 beta), when I made the decision to put down my money, they said it would be fixed soon (along with a few other broken common usage items since 4.X went to 5). BUT it has not been. Last year someone in the support staff said that the way they parse the sent/received exchanges is by the ADIF spec. Not having looked at the spec closely I can not believe that it allows the implementers to arbitrarily decide what part of a string is a numeric and what is a text string and split it up into two pieces.

    Example from the BARTG RTTY contest which requires a serial number, a space, and a four digit time. My ADIF file : <srx:3>640 <srx_string:4>0158. My Log book 640 0158.

    Now HOW in the names of all the programmer Saints can one take a string of "640 0158" and break that into two parts, "640" and "0158"? It is STORED correctly in the data base since the XML dump is correct, it is only the ADIF which is garbage. And ADIF is also the main (only?) way to merge logbook data files (another broken/missing feature in the new/improved version 6).

    Just try doing Field Day, the programers take 1E UT and make it <srx:1>1 <srx_string:4>E UT. And they say that the folks who wrote the ADIF spec says that is what to do?

    Sigh. Wish they would fix the low level, common usage stuff they broke instead just chasing bugs in the new bells and whistles stuff that make good sales hype.

    Looking at too many hours MANUALLY correcting Fouled up files, just like I do too much of in my federal GOVERNMENT job.
    Ray
    K7RFW

    I am using the latest version from Friday which I DL'ed and installed two hours before the BARTG contest.
    Last edited by K7RFW; 03-26-15, 00:36. Reason: version
Working...
X