Call Search
     

New to Ham Radio?
My Profile

Community
Articles
Forums
News
Reviews
Friends Remembered
Strays
Survey Question

Operating
Contesting
DX Cluster Spots
Propagation

Resources
Calendar
Classifieds
Ham Exams
Ham Links
List Archives
News Articles
Product Reviews
QSL Managers

Site Info
eHam Help (FAQ)
Support the site
The eHam Team
Advertising Info
Vision Statement
About eHam.net

donate to eham
   Home   Help Search  
Pages: Prev 1 2 [3] 4 5 6 Next   Go Down
  Print  
Author Topic: Fully automated FT8 QSOs - a good idea for DXpeditions?  (Read 11703 times)
VA3VF
Member

Posts: 1455




Ignore
« Reply #30 on: January 07, 2018, 07:22:42 AM »

Quote
Quote
1) Remove call 1st;
2) Watchdog timer hard coded to 4 repeats max;
3) RR73 and 73 stops TX, always, regardless of whether you called or answered a CQ;
4) Unless you called CQ, the program should not TX on the current frequency, must move at least 100 Hz.

There are many improvements possible and even needed, but these would, sorry to say, be ineffective.

1) This will simply result in a lot of useless, extra retransmissions.  It will literally be a QRM machine to take it away.

Yes and no. It may increase the number of retransmissions, but I would not call it a QRM machine. As it works today, retransmissions are reality. Propagation or multiple competing signals being two examples. Then there is call 1st 'engaging' a station you don't want, compared to another that also called you. The operator may stop that TX and try to get to the other station.

Quote
2) It is downright trivial to overcome the watchdog timer.  Any outside, 3rd party process that can overcome today's limit can overcome tomorrow's.

That may be true, but making it harder to do seems to have removed the 'incentive' for it with other digital modes. All modes can theoretically be automated by a good programmer, provided the source code is available, or if really determined and proficient, from scratch. The difference here, is that in the case of FT8, it's easily done with the use of simple macros. May still not be accessible to all hams, but much easier than having to be a programmer. The other benefit is that it would stop repeats going on ad aternum? In some cases long after the other station is already on another QSO. Some people do behave like robots.


Quote
3) The problem with this is when the DX station doesn't hear it and then comes back to you with their R-03 or whatever R-xx it was.  If you are disabled, and don't get there in time, you waste another 30 seconds.  In what sense is this helpful?

I'm not suggesting the removal of Auto Seq. Its removal would prevent a lot of hams from enjoying the mode. Most hams, myself included, do not have the dexterity to do all the 'clicking' in the 2 to 3 seconds between cycles. But clicking Enable Tx again after each contact is not that taxing, even for a slow operator. Fine tuning to accommodate a repeat is needed. I was using JTDX, before my radio bit the dust, and there is provision for this in it, if I'm not mistaken.

Quote
4) There might be merit in this, though it appears that 100 Hz is probably a larger than necessary movement.  It might also cause more QRM than it solves when the band is crowded.  Then there is the question of consecutive QSOs.  A "CQ" is not a necessary part of the sequence.  The "CQer" may have last done so five QSOs ago.  Or more.  Nor is it a given which message sequence is performed given the ability to skip TX1.  How are you sure who "owns" the frequency anyway?

Ok...50Hz? That was only a suggestion. More QRM than what is caused now? I doubt it. Note that I did not say the software has to move 100Hz away, this would be automation. What I'm saying is that the software should not go into TX on the same frequency. The operator has to click somewhere else on the waterfall. The CQ may have been done five QSOs ago, but a good operator would know who was CQing, if he just took the time to monitor what was going on. Not any different than with other modes, see/listen what is going on before TXing. Again, this would only apply to the station that just completed a QSO, as in logged it, not other stations now vying for a contact with the CQing station.

Quote
The other thing to understand is that whatever we propose can be undone by whatever third party tricks enabled this fully automated mode to start with.  After all, as I just pointed out, the behavior was not desired by the development team anyway.  So, we are already talking about a group that has reversed some key design decisions.

It has always been the case, WSJT-X makes it a little easier by requiring simple macros to automate it.

This is in no way a criticism of the developers.The only things I have for them are praise, respect and gratitude.

All I'm trying to do is to disarm the FT8 critics, and ensure the ham remains in FT8 hamradio.

Always good to have a discussion with you, Larry.
« Last Edit: January 07, 2018, 07:35:24 AM by VA3VF » Logged
W9IQ
Member

Posts: 1845




Ignore
« Reply #31 on: January 07, 2018, 07:27:24 AM »

The entire WSJT-X suite source code is freely available on the WSJT home page:

Source Code: The package posted here contains all source code for WSJT-X...

- Glenn W9IQ
Logged

- Glenn W9IQ

I never make a mistake. I thought I did once but I was wrong.
K5GS
Member

Posts: 17




Ignore
« Reply #32 on: January 07, 2018, 07:45:09 AM »

Quote
It's ham radio + networking.

It is certainly true that for anyone spending north of 100,000 dollars to activate something expensive and remote, the relatively small cost of a BGAN terminal is very affordable and allows near real time uploads.  And, both we and even they will demand it.

A used BGAN terminal can be had for $500 - $700 depending on model.  The basic Wideye Sabre 1 or the more feature packed Hughes 9201 work well. 

The cost of data transfer is about $7(USD) per megabyte billed in both both directions (up and down) using a prepaid plan.

Plans similar to month to month mobile phone plans are available. They have monthly and usage charges and a contract term.

All BGAN  plans charge for data passed, the connection time is not billed. The monthly contract plan isn't cost justified for a few week DX-pedition.

The real cost driver is the efficiency of the software being used for real time updating, i.e how small are the packets and how often does it send data.

There is a BGAN prepaid plan sold by the calendar month with no contract. 1 gigabyte at $1,660(USD) per month. For a project that spans 2 calendar months you're looking at $3,320 for BGAN data transfer.  That's a lot of money to spend for data transfer.

I believe Inmarsat donated the BGAN data usage for the Heard Island project

Cheers,
GS
Logged
WO7R
Member

Posts: 2850




Ignore
« Reply #33 on: January 07, 2018, 08:43:28 AM »

Quote
Agree completely! Note that the 'act of hamming' remains intact in this type of DXped setup. In my view this is not automation, as far as a taking the ham out of hamradio.

I would certainly agree with you, but I think there would be those that would not.

The "out of band" interaction of the internet (never mind computers) with ham radio is creeping in everywhere and it is not clear that there is any valid platform on which we can stand and say "no more" because we cannot imagine all the coming "inter-twinings".  It is sometimes hard for me to figure out why many of us are squeamish about such-and-so, but not this-other-thing-here.

With SDRs we now have computers, and even the internet, inside our radios.  With the Flexradio design (all internet protocol-based), that is quite literally true.  Over time, I expect virtually all devices to have "IP protocol" access rather than RS232 or USB as we often do today.  Before long, we will be building them ourselves.  Heck, in my own very limited way, I am starting to do so myself.

What will it mean to object to "ham radio over the internet" if every radio operation has some internet packet in every single PTT transaction somewhere?  I promise you, five, ten, twenty years later, it will be the overwhelming norm.  Will today's arguments still sound so great when the argument is about internet packets that don't go out over the ISP's wire versus those that do?

I get, believe me, that we don't want ham radio to become a bunch of server farms talking to each other and have me waking up in the morning to find I've worked Bouvet on three bands.

But, as these clever macros go, our ability to have and enforce limits are going to be a tall order.  It will probably always be possible to stretch the boundary that one bit further than the originators of technology X planned.  We are already sending what amounts to our own ALL.TXT files out from FT8/JT65 right now.  Given that modern rigs are now taking ASCII input and producing the various RTTY protocols directly, this can and easily could spread to other modes.  Imagine every radio on the air as a skimmer.  We're closer to that already than you think.

How do we prevent what we don't like without crippling progress?  Or, without creating a thousand little ghettos where this version of DXing is counted up over there separately from this version of DXing counted up over here?

I really don't know.  It's a technical hobby.  I don't see how we can keep it from adopting technology.
« Last Edit: January 07, 2018, 08:46:16 AM by WO7R » Logged
NU1O
Member

Posts: 4465




Ignore
« Reply #34 on: January 07, 2018, 09:16:06 AM »

The other benefit is that it would stop repeats going on ad aternum?


Ad infinitum (again and again, or forever and ever) is what I think you're looking for. 

73,

Chris  NU1O
Logged
VA3VF
Member

Posts: 1455




Ignore
« Reply #35 on: January 07, 2018, 09:34:29 AM »

The other benefit is that it would stop repeats going on ad aternum?


Ad infinitum (again and again, or forever and ever) is what I think you're looking for. 

73,

Chris  NU1O

Correct, that's what I meant. I cut an 'e', it's ad aeternum. The dictionary I used says: adverb - to eternity, forever.

I'm fine with ad infinitum. Easier to understand by non Latin speakers. Wink
Logged
VA3VF
Member

Posts: 1455




Ignore
« Reply #36 on: January 07, 2018, 09:51:46 AM »

Quote
I really don't know.  It's a technical hobby.  I don't see how we can keep it from adopting technology.

True. Changes don't happen overnight, even if it feels that way. If hamradio is dominated by machines eventually, it may or may not be an issue for future ham generations. It is for us, since we are living during this transition. We are 'invested' in the hobby in this one way. Future generations may/will not have this legacy, or backward compatibility requirement, to think/worry about.

There was a report just this week, about robots being used in nursing homes. One group said it was good, the other said it was not, who is right?

Replacing a human with a robot has its advantages, sometimes it's even desirable, but would you like to be spoon fed by a robot at the end of your life?
Logged
AA4PB
Member

Posts: 14492




Ignore
« Reply #37 on: January 07, 2018, 10:01:28 AM »

"Unless you called CQ, the program should not TX on the current frequency, must move at least 100 Hz."

You don't like automation, but you want automation to force operators to use common courtesy? What if the other operator doesn't use that frequency for another CQ? How long will the automation keep that frequency blocked for me? What if someone calls me on that frequency? What if someone else calls CQ on that frequency?

Logged

Bob  AA4PB
Garrisonville, VA
NU1O
Member

Posts: 4465




Ignore
« Reply #38 on: January 07, 2018, 10:14:45 AM »

"Unless you called CQ, the program should not TX on the current frequency, must move at least 100 Hz."

You don't like automation, but you want automation to force operators to use common courtesy? What if the other operator doesn't use that frequency for another CQ? How long will the automation keep that frequency blocked for me? What if someone calls me on that frequency? What if someone else calls CQ on that frequency?



You ask too many what ifs!  Cheesy

I'm new to FT8.  I don't know any of the etiquette for the mode.  If I answer a CQ and another station then calls me on the CQers frequency am I supposed to reject the call unless I QRV?  I have about 200 QSOs using FT8 but I have no idea if I've been violating decorum.

73,

Chris  NU1O

Logged
VA3VF
Member

Posts: 1455




Ignore
« Reply #39 on: January 07, 2018, 10:18:44 AM »

"Unless you called CQ, the program should not TX on the current frequency, must move at least 100 Hz."

You don't like automation, but you want automation to force operators to use common courtesy? What if the other operator doesn't use that frequency for another CQ? How long will the automation keep that frequency blocked for me? What if someone calls me on that frequency? What if someone else calls CQ on that frequency?



Common courtesy cannot be automated. I'm trying to reduce collisions, since common courtesy is lacking.

As I said before, this suggestion would 'impact' only the station that just completed, and logged a QSO. The software would not make the move, the operator would. He can always come back to the same frequency (move and return=reset the lock), or reply to the other station a few hertz away.

Yes, we may be infringing on his/her constitutional and/or God given rights, by limiting his 'freedom'. Not the first time in recorded history, I think. Grin

Carry on as is, I'm. This is just a friendly discussion. We can contort and distort things in many possible ways.
« Last Edit: January 07, 2018, 10:33:42 AM by VA3VF » Logged
VA3VF
Member

Posts: 1455




Ignore
« Reply #40 on: January 07, 2018, 10:21:23 AM »

I'm new to FT8.  I don't know any of the etiquette for the mode.  If I answer a CQ and another station then calls me on the CQers frequency am I supposed to reject the call unless I QRV?  I have about 200 QSOs using FT8 but I have no idea if I've been violating decorum.

73,

Chris  NU1O

No, just reply to the other station a few hertz away. Unless the new frequency is blocked/occupied to the other station, he'll see you coming back to him.
« Last Edit: January 07, 2018, 10:25:23 AM by VA3VF » Logged
NU1O
Member

Posts: 4465




Ignore
« Reply #41 on: January 07, 2018, 10:32:03 AM »


Common courtesy cannot be automated. I'm trying to reduce collisions, since common courtesy is lacking.

Thanks for the answer about QSYing.

I have a feeling many are not intentionally being discourteous.  It's just that many, like myself, are new to the mode and we haven't learned the ground rules yet.

73,

Chris  NU1O
Logged
VA3VF
Member

Posts: 1455




Ignore
« Reply #42 on: January 07, 2018, 10:38:40 AM »

Thanks for the answer about QSYing.

I have a feeling many are not intentionally being discourteous.  It's just that many, like myself, are new to the mode and we haven't learned the ground rules yet.

73,

Chris  NU1O

That's most definitively the case, or so I fool myself into believing. The suggestion targets the innocent and the guilty alike, no discrimination whatsoever. The innocent will learn eventually, the guilty must be controlled. Grin Grin Grin Grin
« Last Edit: January 07, 2018, 10:43:30 AM by VA3VF » Logged
WO7R
Member

Posts: 2850




Ignore
« Reply #43 on: January 07, 2018, 11:12:29 AM »

Quote
All BGAN  plans charge for data passed, the connection time is not billed. The monthly contract plan isn't cost justified for a few week DX-pedition.

For a two week fly-in to Jamaica, no.

For a one month to <Rare South Atlantic> where the total bill is probably 300,000 to 500,000 USD these days, then yes.  If it reduces the dupe rate or the crazy rate by even a per cent or two, then it's well worth the incremental cost.  That's what VK0EK was suggesting in Visalia.

And I happen to know there is a very efficient data encoding that is directly supported by Clublog, which is what matters.  So, you don't have to send ADIF or XML or something.  Maybe 10 bytes a QSO; something like that.

If you are flying in to Jamaica, you will (one way or another) typically have much cheaper options than BGAN, so it is really only a question for an expensive DXped to start with.
Logged
WO7R
Member

Posts: 2850




Ignore
« Reply #44 on: January 07, 2018, 11:16:01 AM »

Quote
I have a feeling many are not intentionally being discourteous.  It's just that many, like myself, are new to the mode and we haven't learned the ground rules yet.

There is a bug in the most recent release that sometimes has you stay on the "other guy's" frequency by mistake.  You work Mr. Semi Rare, double click on something else, and only the rec. frequency changes.  Easy not to notice, too.

So, some of it is that.
Logged
Pages: Prev 1 2 [3] 4 5 6 Next   Go Up
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!