eQSL.cc Forum
Help!  eQSL.cc Home  Forums Home  Search  Login 
Viewing User Profile for: K0RC Robert Chudek
About Contact
Joined: Dec 27, 2000 10:38 PM
Last Post: Jan 21, 2008 09:51 PM
Last Visit: Feb 3, 2008 01:30 AM
Website: http://www.pclink.com/~k0rc
Location: Chisago Township, Chisago County, MN, USA
Interests:
Favorite Bands: 160, 15, 10, 40, 20
Favorite Modes: CW & RTTY
Avatar:
Captain
Email: k0rc@pclink.com


Send Private Message
Post Statistics
K0RC Robert Chudek has contributed to 16 posts out of 11671 total posts (0.14%) in 8,583 days (0.00 posts per day).

20 Most recent posts:
Support - English speaking » Tutorial for setting up multiple locations? Jan 21, 2008 09:51 PM (Total replies: 0)

Is there an online tutorial discussing the procedure for managing eQSL accounts from multiple locations? I looked but did not find anything.

Here's the (simplified) scenario I was trying to resolve:

I have a primary account as KØRC where I normally operate. The end date for this account is out in the future (2010 IIRC).

In November I operated the CW Sweepstakes from Grand Forks, ND as KØRC. I did not sign as a portable callsign because I was still within the Zero district and the contest exchange includes the QTH.

When I uploaded my log to eQSL, I created an associated account as KØRC-ND. The system would not let me create this account until I changed the primary account end date to a date prior to the start of the new ND account.

I made the adjustments and uploaded the ND log without any further problem. This batch of contacts will be the only QSO's entered using this associated account.

My first question: At this point it appears I cannot have overlapping date ranges. What do fellows do that have two operating locations and alternate between them?

Continuing on, my next step was most likely a mistake. I had "ended" my primary log and now also "ended" my ND log. So I created a new associated account in order to continue uploading my log from my normal location. (I wasn't finished with ham radio yet!)

I began to upload contacts into this new associated account. Using this new "3-log" configuration it quickly became apparent this was not going to be very efficient. I was having to exit and log into different accounts to manage the incoming eQSLs. I figured there must be a simpler way to deal with this scenario.

One evening I got the brilliant idea I would log into my original master account and see if I could move the end date into the future. I was surprised the system DID actually allow me to do this!

So where I stand right now is having 3 accounts, one for my ND operation, my original master account with the extended future date, and an unneeded associated account.

The second question: Can I (and how do I) delete the unneeded associated account without impacting the log(s) I have uploaded after the CW Sweepstakes contest?

73 de Bob - K0RC

Support - English speaking » Daylight Savings Time transition issue Jan 24, 2007 05:55 PM (Total replies: 0)

I am reconciling my 2006 logs. I noticed an issue with the eQSL logbook when processing records during the DST transition. Here's what I am seeing:

The 2006 EA RTTY contest ran from 1600z Saturday 1 April to 1600z Sunday 2 April. Within this 24-hour contest period, the USA daylight savings plan was executed. At 2:00 AM, local clocks are moved ahead 1 hour to show 3:00 AM. We all know the UTC clock does not change.

My contest logging program (N1MM Logger) logs contacts in UTC. It created the correct, sequential entries in the ADIF and Cabrillo files. In other words, it handled the DST transition properly even though the local clock changed.

The ADIF file I uploaded to eQSL has 30 contacts logged during 0200z ~ 0300z. When I examine my Outbox, these 30 contacts are shifted 1 hour forward. For example, my contact with WX4TM at 0214z is listed at 0314z in my eQSL Outbox.

It appears the eQSL system is making adjustments for the DST transition. It should not make a change to the date/time stamp because these are (should be) UTC time.

Is there a solution to this issue?

73 de Bob - K0RC in MN

73 de Bob - K0RC

General web site suggestions » Responding to eSWL requests... Jun 5, 2006 01:51 PM (Total replies: 2)

I am responding to eSWL requests and noticed the confirming card (at least on my screen when I'm preparing it) says:

Confirming 2-way CW QSO
Date: February 22, 1998 Time: 17:53 UTC
Band: 10M RST: 599
Comments: ______________________

The first line should really read:

Confirming 2-way CW reception report

I'm picking at nits here, but... :-)

73 de Bob - K0RC

73 de Bob - K0RC

Support - English speaking » Changing eQSL card graphic. Jun 4, 2006 09:41 PM (Total replies: 25)

You got TWO of them there 89-buck 300 giggers???

Man, you're living in luxury!!!



73 de Bob - K0RC

Support - English speaking » Changing eQSL card graphic. Jun 4, 2006 05:43 PM (Total replies: 25)

Quote: There's the issue of data aging. I do not beleive that holding QSL cards ever is the way to go, neither is a requirements. I do think that we proper requirements were to be done that many issues would resolved by themself. Then, some "way of using the system" rules could kick in. For example, (we need stats on this) but, if after an eQSL card is "seen" by the receipient, the user would have the card only for 30 or 60 days before it (the card, not the QSO record) gets destroyed. Meaning, hey, we provided you with the QSL card, now you have to download it and do what ever you want with it, or have us print and mail, etc... I think you get where i'm going.

Proper evaluation of the capacity requirements added to the % of not retreived QSL (which, badly I'm assuming very high since about 90% of my QSO and eQSL cards are done to Ham which are "not" on this system... so, holding SQL ad vitam aeternam?? That too is what I think the core of the problem... that we need to think around. Am I assuming right?

Sylvain, VE2FET

--- Original message by VE2FET Sylvain Faust on Jun 4, 2006 05:02 PM
Sylvain,

Whether a user retrieves a QSL or not is irrelavent to storage requirements. Vince, WA2RSX, wrote an excellent overview of the system design earlier in this thread.

The thing to remember is one grahic background takes up 50-Kb of space whether 1 user or 10,000 users retrieve my card. If I delete that graphic because user #1 has retreived it, the other 9,999 users would not get a background image on my card. The single "master" image would be gone.

The final slide here http://www.eqsl.cc/qslcard/Presentation.cfm?Slide=Step8 shows how the single master image is married to the QSO data "on the fly" and is sent to your computer when you ask to view and/or print a card. The N5UP image in the lower left corner is stored on the system only once. Again, if it is deleted, it won't print on any future card requests.

Addressing your second paragraph, no, whether cards are retrieved or not has no impact on the storage requirements either. An electronic card "not retrieved" is not taking up space like cards sitting in a physical QSL bureau. Slide number 6 of the slide show can be a little misleading. It uses file cabinets to convey a concept, which to most people would interpret as a transfer of something physical. Slide 8 is the best representation of how the eQSL retrieval and printing works.

73 de Bob - K0RC

Support - English speaking » Changing eQSL card graphic. Jun 4, 2006 04:46 PM (Total replies: 25)

Quote: A little piece of info that I just learned from Dave today while discussing another topic.

Currently the entire 65.1 million QSO database requires approximatly 30 GB of storage. A llittle rough math on that reveasls that each QSO requires approximately 461 bytes of storage, give or take a few. Thus, to add a 50K qsl image to each qso would increase the amount of storage space required by 108 times. And, that's just the basic storage. You have to back it up both on and off site. Perhaps that provides a little better perspective on this.

--- Original message by W3ZJ Rich Drake on Jun 4, 2006 01:30 PM
Thanks for the info Rich,

The first part of your calculations are correct... the average QSO requires 461 bytes of storage. But you can't simply add 50-Kb to each QSO and multiply this out to an astronomical figure. That isn't the right perspective!

To project storage requirements you need more information. For example; what percentage of existing users have already stored a graphic and what percentage of users would bother to store more than one graphic if the feature was offered.

If the entire existing 30-Gb database was consumed by 50-Kb graphic files, it would hold 600,000 images. That's about six times the number of existing users. From the aveage 461 bytes of data per QSO information you calculated, I can only speculate the percentage of graphic users is very very low.

In any event, Dave is the person who really needs to evaluate the statistics and determine what impact this feature would have on storage requirements. That said, I estimate if 20,000 users stored a second 50-Kb image, it would consume 1-Gb of storage.

Considering current storage costs, Dave might find it to be cost effective or not. The costs associated with mirrored storage in a data center environment are significant compared to you and me runing down to the "Computer Emporium" and buying a 300-Gb drive for $89.

73 de Bob - K0RC

73 de Bob - K0RC


I'm working on gettin 44+ years of logbooks uploaded to eQSL.cc and I seem to have run into a limit uploading a single, very large ADIF file. The error header says:

The request has exceeded the allowable time limit Tag: CFQUERY
The error occurred in
D:\www\eQSL\Htdocs\qslcard\uploadfile.cfm: line 629
Called from D:\www\eQSL\Htdocs\qslcard\uploadfile.cfm: line 625

The ADIF file I am working with is 22,250 entries and the file size is 8 Mb in size (This represents my CW & SSB logs from 1995 to present). I can break this down into smaller chunks, but I need to know the limits so I don't waste eQSL processing resources.

TIA

73 de Bob - K0RC

73 de Bob - K0RC

General web site suggestions » Please post any suggestions here May 30, 2006 06:35 PM (Total replies: 34)

Are there any plans for stronger statistical reporting from the eQSL database?

For example, currently:
The system tells me I have uploaded 17,200 entries to date.
The system tells me I have 105 countries, 50 states, and 33 zones confirmed.

Beyond that, I would find a chart along these line to be extremely valuable:


OVERALL:
Total eQSL master database entries: 64,900,000
Total eQSL countries represented: 309

SPECIFIC: Mixed Phone CW Digital
Total K0RC database entries: 17,200 4,500 6,500 6,200

Total K0RC QSO matches: 11,200 3,500 4,500 3,200
Total K0RC QSO AG matches: 8,000 2,500 3,500 2,000
Total K0RC QSO non-matches: 6,000 1,000 2,000 3,000

Total K0RC countries uploaded: 160 120 100 80
Total K0RC country matches: 140 90 80 60
Total K0RC country AG matches: 105 60 50 50

Total K0RC states uploaded: 51 51 51 51
Total K0RC state matches: 50 49 50 48
Total K0RC state AG matches: 50 45 50 46

Total K0RC zones uploaded: 36 31 29 25
Total K0RC zones matches: 34 29 27 24
Total K0RC zones AG matches: 30 26 25 22

These statistics would allow me to track my progress on toward the various goals on the different modes. It would also provide a "percent hit rate" for data that I am uploading. I just begun working from current logs back 44+ years. A periodic progress report like this is an item that would be an incentive to continue the manual logbook conversions!

Or is this way beyond the scope of summary reporting that is invisioned for the eQSL.cc architecture?

73 de Bob - K0RC

73 de Bob - K0RC

Support - English speaking » Changing eQSL card graphic. May 30, 2006 11:59 AM (Total replies: 25)

Hey Rich,

I was thinking along the lines of implementing something very simple.

For example, right now I can click on the "Display" button and the QSL for the QSO comes up automatically for preview and printing. This is where an intermediate window that displays the thumbnails of 4 QSL designs I have created would be displayed. As a QSL "retriever", I would decide which one I liked, clicked on it, and this is the design that would print. If I wanted to print a different design, I could come back and click on a different image.

So for your number 1, my thought was to leave the design decision up to the QSL retriever. The software would probably need a "Default" setting in case there are automated printing routines I am not aware of.

For your number 2, I don't see ADIF being involved in this process. But maybe I'm missing something here.

And number 3, I don't know, but again at the level of implementation I was thinking about this would not be an issue.

Of course there would need to be some programming work done on the user QSL card creation routine so you could design and save multiple cards.

Thanks for listening and passing along my thoughts. I see there is a "features" forum, but I'll let this rest here for the time being.

73 de Bob - K0RC

73 de Bob - K0RC

Support - English speaking » Changing eQSL card graphic. May 30, 2006 02:21 AM (Total replies: 25)

It's time to move forward. Storage space is not that big a deal anymore. Just look at the proliferation of "Myspace" and similar graphic oriented blogs on the internet.

If I wanted to "cheat" the system, I suppose I could setup multiple accounts with, as you pointed out, a separate QSL design for each account. But I would rather put the feature request on the table for serious consideration and not simply dismissed.

I'll look to see if there's a feature request forum where this idea belongs.

73 de Bob - K0RC

73 de Bob - K0RC

Support - English speaking » Spell checker May 5, 2006 05:50 PM (Total replies: 5)

FYI:

As of 1 May 2006, Spellbound has not updated their extension so it does not work with the current version of Firefox (1.5).

Bummer!

73 de Bob - K0RC

73 de Bob - K0RC

Support - English speaking » Received eQSL dissapeared! May 5, 2006 12:19 PM (Total replies: 3)

Is it possible UR5LY deleted this contact from his log for some reason?

I would send him a message and see if he changed something on his end.

73 de Bob - K0RC

73 de Bob - K0RC


Some fonts have the slashed zero available in the extended character set. To access this character, hold the Alt key down and type 216 into the numeric keypad (not the top row of numbers on the keyboard).

Also, make sure your keypad is in Num Lock or this technique won't work. Be aware not all fonts have the slashed zero character. You can experiment with different fonts.

Some other useful characters can be access using this method too. I have these shortcuts taped to my keyboard.

Alt + 155 gives you the cents sign
Alt + 171 gives you the 1/4 fraction
Alt + 172 gives you the 1/2 fraction
Alt + 216 gives you the slashed zero
Alt + 241 gives you the plus/minus sign
Alt + 246 gives you the division sign
Alt + 247 gives you the approximate equal sign
Alt + 248 gives you the degrees sign

Let's see if they work using the default font in this editor:

155 = ¢
171 = ½
172 = ¼
216 = ╪
241 = ±
246 = ÷
247 = ≈
248 = °

Well everything BUT the slashed zero seems to work in this online editor! You might find some of the symbols in different Alt + ### locations. There isn't a universal, consistent assignment of the numbers and characters.

But knowing this trick can get you some nifty symbols when you want them.

73 de Bob - K0RC

73 de Bob - K0RC

Support - English speaking » Changing eQSL card graphic. May 5, 2006 11:43 AM (Total replies: 25)

This thread triggered a question I wanted to ask... What is the possibility of having several graphics available for my eQSL design? In other words, a recipient could select say one of four designs when they want to print my card?

Right now I have a winter scene for my card. What are my options for saving this design and creating a summer scene.

My thought is 4 different designs to choose from would be adequate.

73 de Bob - K0RC

73 de Bob - K0RC

General web site suggestions » Browsing the survey results... May 5, 2006 11:35 AM (Total replies: 0)

I was looking at the Survey Results section of the website and found interesting information from the feedback received from the eQSL user base. I would like to see the origination date of these surveys posted with the topic. This would provide additional insight into the results that are posted. For example, a question regarding an increase in eQSL server speed provides a different perspective if this survey was complete in 2001 or 2006. (I am a recent subscriber so I don't have a running history of this system.)

Also, the MPEG server video holds little value to me as there is no dialog of what I'm looking at! IMO, an operator pushing a button and some lights blinking while a whirring sound is heard is about as interesting as watching grass grow. A waste of a 4.8-Mb of storage and bandwidth.

Don't get me wrong... I am a full supporter of the eQSL concept and system. Please take my comments as "constructive criticism" and keep forging ahead!

73 de Bob - K0RC

73 de Bob - K0RC

Other suggestions » Capture exact frequency in addition to "Band" Jan 15, 2006 12:26 PM (Total replies: 3)

What is the possiblity of capturing the exact frequencies (from the adif <FREQ:#> field and including it in the database and on eQSL's?

Recently, during a routine inspection of my log this information would help me determine whether I was in "run" or "s&p" mode during a contest. I was investigating a "not in log" error report.

This idea is more for convenience. I can always go back to the original contest log and extract this information. Or maybe the data is already there and I don't know how to view it?

73 de Bob - K0RC

K0RC Robert Chudek