Hello All,
Thanks for all the hard work on the new Database page. Looks great!
However, I just tried to enter yesterday’s summit-to-summit contacts and it seems you can no longer do that via a chaser entry.
I use the CSV upload for my logs but haven’t mastered the s2s protocol with the CSV, so I usually enter them one at a time via the chaser entry.
Is this no longer possible or am I just missing something?
TIA
73 Eric KG6MZS
I see what you describe.
A field for the S2S ref of the other station is missing.
I think it used to be a checkbox that enabled the field in the old sotadata.
Andrew will need to have a look @VK3ARR
I revise my statement.
S2S are part of the activation so use the activation form.
It never made sense on the chase section imho.
There you find the Other summit field.
73 Joe
Thanks for the reply Joe.
The problem I have with that method is that I’ve already logged the activation via a CSV upload.
I had 25 activation contacts yesterday and I don’t want to do each one separately. I used to do that and if you made one mistake… oh boy, well, you know. The method of allowing me to log s2s contacts via a chaser entry solved that.
I guess I need to learn how to get the CSV in the right format to log the summit-to-summit contacts at the same time I upload the entire activation log.
73 Eric KG6MZS
I don’t understand. CSV is simple, you just add a S2S reference at the right place:
V2,yourcall,yoursummit,date,time,freq,mode,othercall,othersummit,comment
V2,HB9GVW/p,HB/AG-008,13/04/23,11:11,7.133MHz,SSB,HB9AGH,
V2,HB9GVW/p,HB/AG-008,13/04/23,11:12,7.133MHz,SSB,DL1CR/p,DM/NS-107,
If you’ve already uploaded a CSV file for the activation, just delete it and upload the corrected version.
There was a change just a short time ago, so you might want to log out, refresh the page and log in again.
Hope this helps.
73 de Martin / HB9GVW
It is even easier.
You can edit the existing upload and just add the s2s references to the list.
https://www.sotadata.org.uk/en/upload/manage
Then hit the verify log and submit log buttons and the s2s are added.
Thanks for the reply Martin.
I wish it were that simple for me. I log in RumlogNG. I use the “Export Selected QSOs For SOTA…” menu command. This export does not include the summit-to-summit, or as you say, the “othersummit”. I just tried to import the CSV into ADIF Master but that program will not allow me to save as with the fields you describe (V2,yourcall,yoursummit,date,time,freq,mode,othercall,othersummit,comment)
I’ve had a lot of trouble in the past editing ADIFs and CSVs in a manner that makes everybody happy. This is why I have used the method I use in the past before the Database change.
Thanks again,
Eric
AHA! Brilliant! Thanks Joe!
73 Eric KG6MZS
I always think the easiest way is to get it right to begin with.
I fully agree Andy. But multiple ways lead to Rome 
Yes, but if your preferred logging tool doesn’t work you can contact the authors and point out the problem and see if they will fix it. Or switch to a logging tool that works. Persevering with something that doesn’t work and then some manual steps after… well I don’t have sufficient minutes left to waste them like that 
It was there because it used the existing chaser submission code when S2S was first added 10 years back. The second database program was essentially produced to enable SSO support and most everything else was moved as-is from the original to the replacement. Now Andrew has produced something new, it’s able to take the good bits, bits that worked well before and improve the bits that were not so good.
My comment was not intented to critique the way how it was established. I am familiar with the fact that it was added as a chaser feature for activators later on after establishing the database.
Changing things like database design that is up for years is not something to do on a weekend.
So I am happy to see that the overall design could be improved. Nothing more nothing less.
Especially for newcomers this is easier to understand. So big 
Worth a shot, I suppose. OE5JFE Joe’s suggestion combined with the new Database interface is a vast improvement to how I was doing things before. I do like 95% of the way RUMlogNG works for me now.
Thanks again for the great new interface!
73 Eric KG6MZS
Looks like it is supported in RumLOGNG:
You can upload ADIF that include the SOTA_REF and MY_SOTA_REF keywords. So no need to mess around with csv and manual uploads.
RumLogNG does fully support S2S CSV generation. It has quite a nice solution in that there are 4 user definable fields that can be mapped to ADIF fields in the settings.
For example, here’s mine, under Settings… => General:
And here’s how it looks in a S2S contact:
Just make sure you have your summit ref in the MY_SOTA_REF field and the other stations ref in SOTA_REF.
[Note for UK activators: If you add the STATION_CALLSIGN field as well, then RumLogNG also correctly handles generation of SOTA CSV files when you use a different regional prefix 
]
73 Jonathan
Wow. I wish I had paraded my ignorance around in here sooner. That is utterly trick Jonathan! Thank you so much.
73 Eric KG6MZS
You’re welcome Eric! You can also setup similar mappings in the iOS and iPadOs versions of RumLog if you use those. I use the iCloud sync logbook which works well.
I log on paper when activating so now use the FLEcli tool to quickly convert a paper log to ADIF and then import into RumLog, but with the fields mapped I can then see and edit the SOTA data if necessary in RumLog.
73 Jonathan
You can also uplaod your csv list of qsos, than you go to your logs and you edit the csv online on sotadata, there is a window to add the s2s.
