Order Tray | Contact Us | Home | SIG Lists

[aprssig] CQ Field Day via CQSRVR

Bob Bruninga bruninga at usna.edu
Sun Oct 21 21:27:26 UTC 2007

> Please re-read my entire post. [Fixing CQSRVR 
> for Field Day overload] is a mute question because 
> #1) Internet contacts are not allowed for Field Day.

Right, and neither are APRS contacts, never have been.  APRS at field day is not about points, never was.  APRS at field day is about demonstrating emergency communicatiosn from the field and having fun.  

> #2) you are dreaming if you think 2000 Field Day 
> sites are going to be trying to make contacts 
> via APRS using CQSRVR with every station sending 
> a CQ message every 30 minutes.

Yes, I am a dreamer and that is why we have APRS inspite of all the naysayers that said that BEACONS are bad, the DIGIPEATERS are bad and that packet is DEAD.  I see no reason why we could not easily have nearly that many... now that that CQSRVR has solved the #1 problem with using APRS at field day and that is, there was no CQ mechanism beyond local RF.  Now there is GLOBAL CQ mechanism that can be initiated by every single user...

> I appreciate your concern but it is misplaced.  
> If CQSRVR becomes an issue, I can turn it off,

I would think that such draconian solutions are a disservice to users when more elegant solutions are easily designed in... especially when the problem is so easily predicted.

> extend the limits to every hour, etc.

That does little to prevent overload at each RF area.  In fact, it compounds the problem.  If you unilaterally change the fundamental timing of the system the net result will further compound the overload problem.  CQSRVR will start doubling he traffic by responding to every incomming message with a reject message.  And then users will try harder. and these added messages will in fact make things worse instead of better... People will just try harder and more frequently to login as their porbabiliyt of success dwindles and they get no apparent resposne from CQSRVR...

> We'll cross that bridge if it ever does become 
> a problem.  Until then, let's just let it do 
> what it was designed to and try not to over-engineer it.

Its not over-engineering to anticipate an overload scenario during the 1 day biggest HAM radio event of the year and not doing anything about it till it happens.  I'm not asking for immediate solution, but just noting that before Field Day comes around, CQSRVR will have to have a seamless coping mechanism to deal with the one-day orders of magnitude surge and to equitibly and unambiguously respond in an anticipated manner that all users can understand beforhand so that we dont end up with the melt-down scenario that will disappoint everyone.

I agree, lets see how it gets used, but we need to be thinking of the throtteling mechanism that will let it work seamlessly on Field Day.  It real day to shine, not fail...


More information about the aprssig mailing list