Date   

flamp will not receive

Kyle
 

I am a fairly new ham and have been learning to use the nbems/fldigi suite with my local ARES group on an VHF repeater.

I'm using a FTM-400XDR with a signalink and a rPi 4.

So far I have had success with fldigi, flmsg, and flarq.  I have even been able to transmit a file with flamp.  When I try to receive a file via flamp I see the data in fldigi, but the flamp window never populates.  I am at a loss as to what could be the problem.

Kyle KI5JCL


Re: FLARQ new version

Ed W3NR
 

On 9/12/20 10:54 AM, pat obrien wrote:
I understand FLARQ has a newer version, anyway to download it as a separate item or does one have to download with fldigi?
I have  found a way to remove messages from email finally.
POB/K8LEN

Check here ::

http://www.w1hkj.com/

Ed W3NR


FLARQ new version

pat obrien <2WR796@...>
 

I understand FLARQ has a newer version, anyway to download it as a separate item or does one have to download with fldigi?
I have  found a way to remove messages from email finally.
POB/K8LEN


Re: flarq

Ed W3NR
 

On 9/11/20 3:36 PM, pat obrien wrote:
HI GUYS;
I have FLARQ  setup but have a few questions

1.  in messages going out, e-mail I want to delete it out, but the delete on the computer will not do it, any suggestions?

2. When the other  station tries to get his message does the operator have to be here to press his connect or does it do it automatically?

Other than that it sets up easily,but the above needs a bit of help.
TNX/73 POB

Have you looked under Help > How To ??

Ed W3NR


flarq

pat obrien <2WR796@...>
 

HI GUYS;
I have FLARQ  setup but have a few questions

1.  in messages going out, e-mail I want to delete it out, but the delete on the computer will not do it, any suggestions?

2. When the other  station tries to get his message does the operator have to be here to press his connect or does it do it automatically?

Other than that it sets up easily,but the above needs a bit of help.
TNX/73 POB


Re: fldigi signal browser 50 vs 100 Hz

roland.hartmann@...
 

Hi,

 

short an additional awareness.

Have worked with option --config-dir where all settings are starting with default.

There is still same issue of wrong frequencies in signal-browser. But in both cases only in CW-Mode. As least in PSK mode frequencies are shown correctly. Also selecting by clicking on an found entry is working in PSK (but not in CW).

 

So I think it is not an issue in settings – seems it is a software issue ?!

 

73 de Roland, DK4RH


flmsg 4.0.17 posted

Dave
 

at http://www.w1hkj.com/files/flmsg

and at Source Forge.

Tue Sep 8 17:24:15 2020

Version 4.0.17
  * Maintenance release

  Seg fault on Send bug
    * test for empty string in arq log

  Memory leaks
    * fix memory leaks in following source files
      - csv.cxx
      - custom.cxx
      - flmsg.cxx
      - transfer.cxx
      - parse_xml.cxx
      - status.cxx

Bug fixes courtesy of Richard Shaw, Fedora maintainer.

73, David, W1HKJ


ARRL/TAPR Digital Communications Virtual Conference (DCC), September 11 - 12 (THIS WEEK)

Mark Thompson
 


39th Annual ARRL / TAPR Digital Communications Conference (DCC)

THIS WEEK - Friday, September 11th & Saturday, 12th  

DCC will be a virtual conference using Zoom video communications and YouTube video-sharing platforms.

DCC information, Technical Papers, Presentation Schedule & Registration Available at: 


Registered DCC attendees participating via Zoom will be able to interact with presenters and other attendees via a chat room as well as raise a virtual hand to ask questions. 
(you don’t need a Zoom account to register).

Non-registered DCC attendees can watch the live stream for free on YouTube,
however non-registered DCC attendees will not be able to ask questions or chat.

No registration is required for YouTube access.
The YouTube URL will be announced and posted on this webpage preceding the DCC.


DCC registration is free for TAPR members and $30 for non-members.
Members receive a 100% discount at checkout. 

Non-members who would like to join TAPR and receive the free DCC pass can simply add TAPR membership and DCC registration to their shopping carts.
After checkout, they will receive the free DCC pass when their membership is processed.



fldigi signal browser 50 vs 100 Hz

roland.hartmann@...
 

Hi,

 

maybe I have a configuration issue – but not found what has to be changed…

 

fldigi show the signals in 50 Hz steps in signal browser.

See attachment, have reduced the SQL for this example. Here a CQ seems to be found at 950 Hz. But in reality it is at 1900 Hz. See waterfall and text above. And that is also what I can hear.

If I click on the CQ of  signal browser, it jumps to 950 Hz. And there is nothing.

It is still the same, even I switch to channels or frequency.

Have tried the newest alpha version (4.1.14-48) but still the same.

Taking a look into the manual the signal browser should present the signals in 100 Hz steps. What it is doing, but not showing.

 

Think if those would be no issue of the software. If so also other user would ask. But have found nothing.

I’m using here an IC-7300. Connected with USB to Windows10 64bit system (if those could be relevant)

 

73 de Roland, DK4RH

 


update to nanoIO / fldigi for MORTTY V4

Dave
 

fldigi 4.1.14.48 corrects WPM timing issues with MORTTY used with nanoIO sketch versions 1.4.0 and 1.4.1,

http:www.w1hkj.com/alpha/fldigi/

nanoIO sketch 1.4.1 provides improved dot-dash-space timing,

http://www.w1hkj.com/files/nanoIO

If you elect to install the nanoIO sketch version 1.4.1 be sure to set the sketch baud to the desired rate, default is 9600.

Accurate WPM timing requires some compensation to achieve very accurate results.

Open the fldigi configuration dialog to the nanoCW panel

Select the correct port, set the baud to 9600 or the baud compiled into the sketch.  Press the connect.  The connect may take a second or two.  When connected the "CW i/o" indicator will be checked and the status echo displayed in the text panel.

Execute the WPM compensation by:

  • set the "Comp'" value to zero.
  • set the Comp' WPM to your anticipated default value (compensation is good over a +/- 10 WPM range)
    The next step will transmit a full 1 minute of "PARIS " at the compensation WPM rate.  You might want to use a dummy load or QRP power level
  • press the "Test ==>" button
    at the conclusion of the 1 minute transmission, the compensation value will be computed and displayed in the "Comp'" control.
  • Press the Adjust button to send that value to the MORTTY.
  • clear the text panel (right click and select clear)
  • press the Status button to read the status and insure that the "corr usec" is OK.
  • press the Save button to write the status contents to the Arduino ROM.

You can tweak the "Comp'" value if you are not satisfied with the computed value.

Results shown for 24 WPM compensation on Windows 7.  The compensation is primarly a correction for read/write on the Arduino serial port and will be dependent on the OS and OS version.

You can perform the test again and the transmit time should be within 20 milliseconds of 1 minute.

73, David, W1HKJ


Re: [Mortty] New Mortty User - Fldigi Crashes - #fldigi #nanoio-keyer #mac

Dave
 

Download nanoIO sketch version 1.4.0

http://www.w1hkj.com/files/nanoIO/

and fldigi version 4.1.14.47 at http://www.w1hkj.com/alpha/fldigi/

Both have been successfully tested with V3 and V4 MORTTY units on:

  • a 2011 miniMac booted to High Sierra 10.13.6, Mojave 10.14.6, and Catalina 10.15.4.
  • Windows 7 / 10
  • Linux Mint 19.4
73, David, W1HKJ

On 9/1/20 3:18 PM, Billy NN5EE via groups.io wrote:
I have two Mortty devices, a V3 and a V4 and am trying to run on a late 2012 Mac mini I7 on 10.15.6 Catalina. I didn't pay too much attention to this thread because I didn't originally equate my issues to a Mortty Crash. I bought the V3 but had not assembled it due to other issues and a relocation which took me off the air for many months. 

I asked for the V4 to run nanoIO. I could not get it to run with nanoIO. I then assembled the V3 and it did not run nanoIO  either. 

I tried most everything under the sun I could think of since receiving the V4. My results were too wide varied to enumerate here completely. Mostly I would get just one CW character sent in a string, a continuous string of dits or dahs or no characters sent in K3NG mode. I now have the V4 running with the K3NG emulation sketch ---after--- I download the CH341SER_MAC V1.5 drivers from Sparkfun. The pot works and less flash although the yellow flashes along with the green???. I am using a TRS line directly to a Kenwood  TS590S w/o any PTT connection. Fldigi did hang up quite a bit before I tried the new driver. 

Now I can't seem to update or load new sketches into the V3 on this Mac. I will be working on that with other Mac boxes. I do have access to a 2010ish MacBook with much older macOS than Catalina so will try that. 

Suffice to say, Mortty/Fldigi operation on Macs does seem to be problematic. 

Billy NN5EE


Re: NBEMS and Winlink can work together

K6ETA
 

westerndigitalnet.org


Re: NBEMS and Winlink can work together

Jim
 

It has been interesting reading this tread for the past few days. 
Around the world it shows different situations that appear good and bad depending on the cooperation of the hams in the various areas. 

In our state they have basically opted for Winlink on HF and VHF due to the short learning curve. 
Operationally there are no beacons on HF hence no interference.
On VHF we have asked all stations to set their BEACON using AFTER 255 command. This means my station or their's will not beacon for a time after it last hears a signal (I think  255 is 40 minutes, you'd have to check the TNC's manual). With this settings we seldom hear beacons during he day and very few at night. I think the last time my station sent out my beacon was 2 months ago. 
Why? Well we have an extensive mountain top VHF Packet Node system that allows Las Vegas operators to connect into Nye county, Southern Utah, Northern and Southern Arizona where frequent beacons would tie up the system. We lost our California link. 
Along with that we recommended stations within the valley set their PBBS to ssid (call -1) and their node to ssid (call-7). With this stations can run lower power and relay around the valley causing little interference to mountain tops due to FM capture effect.  

In operation our ARES/SHARES/RACES/MARS/County Emergency Management all work together when we have communications exercise or event. Last major event in the valley was the Trump/Clinton debate where we added to the above list Secret Service radios in the Communications Unit (mobile command post type unit). This unit is manned by hams and has radios for Fire/Police/Amateur Radio built in. It has 7 operator consoles. Along with Secret Service radios we brought in VHF packet, and MESHNET Telephone. Telephone provided a direct link to the county Multi-Agency Command Center/EOC. MESHNET has since been expanded to include data channels.  

During Storm Area 51 event ARES in Lincoln county NV invited Clark County ARES to participate for the needed manpower. This deployment was out of VHF range so we switched to HF Winlink. NVIS antenna system was needed due to the distance of a couple hundred miles. We maintained a Peer-to-Peer link using Winmor due to one station not having Pactor. The station in Clark County left the monitor up 24/7 should additional resources be required. This event also used the Communications Unit as an operating platform. 

ICS213 forms are only used locally. Any message leaving the county goes on NTS Radiogram/MARS depending on which system is avaiable/appropriate. During an event we don't enforce the NTS Radiogram 25 word limit. There is no mixing of 213 and radiogram as those only cause confusion due to different groups having created their own format. We find standardization to be the best for reducing mistake in message handling.  

For those using VHF packet without Winlink....some have chosen to use Outpost to a County BBS. This is coordinated using a voice net. For some rather than use outpost they just type it in on the keyboard.

As you can see lots of variations in emergency communications systems and operations. 
Common goal is to get the message through accurately. 

Fun Stuff this ham radio!

73

Jim Bassett, RMC(AC), USN, Retired
NNZ9KQ-SHARES, Southwest Region Net Operations Manager
W1RO-ARRL Life Member-A1 Op
Nevada Section Traffic Manager


Re: NBEMS and Winlink can work together

K3eui
 

I hesitate to comment on Winlink vs. NBEMS, but here are a few thoughts from the Pa NBEMS net manager (80 meters). I've been licensed since 1958 and have a lot of experience on HF bands, all modes.


Almost all of  Chester County (PA)  ARES/RACES EMCOMMS are on VHF/UHF and higher due to the available bandwidth, multiple linked repeaters, and ease of use with simple equipment.  We train both by voice and NBEMS (FLDIGI) each week. We usually use FLDIGI in bulletin mode (non ARQ) on 2m/70cm with fast modes like 8PSK1000F (3000 bps) on FM radios. We can also operate slower digi modes, like THOR 100, MFSK128 and even MT63-2K when appropriate.


For statewide EMCOMM, the PaNBEMS chose 80m (3583.0 kHz) using THOR 22 (very robust and very fast at 78 wpm and 500 Hz BW) and Sunday mornings from 0730 to 0900 local time. It works very well. We get checkins from all over PA, as well as NJ, NY, VA, NC, New England. Each Sunday propagation permits from 50-70 checkins now, with the present solar cycle. We are getting quite a few stations checking in QRP (under 5W) and simple antennas and battery power. We practice with FLMSG and sometimes, FLAMP. We RARELY get any kind of interference from anyone, and almost never from a Winlink station (again, 3583.0 kHz Sunday mornings).

The boundary on 80m is where I see the potential conflicts with Winlink; that is, from 3580 to 3600 kHz.

The Mid-Atlantic  (NY, NJ, PA) NH and MASS  NBEMS nets all operate between 3580 to 3585 kHz.  Most of the nets use THOR 22 (525Hz) We usually state the frequency of the net as the upper sideband, suppressed carrier frequency. But since all of the nets use a center frequency around 1500 Hz (audio) our actual RF lands 1.5 kHz higher than our VFO readings. We don't "own" any frequency, of course, but ops always give us the space to operate the net successfully.


Winlink usually states the RF frequency as the "signal" and not the USB suppressed carrier (VFO) frequency.  On the RMS Express software, you can "see" a list of every Gateway operating on each band, so you can find potential conflicts. I notified one Gateway op, and he kindly moved his Gateway up 1 kHz on 80m: problem solved.


Once in a while, NBEMS nets do collide with Winlink stations operating below 3585 kHz, but that is rare on the North-East Coast. And usually, the NBEMS net switches to a narrow BW mode like THOR 16 or even MFSK16 and we can live peacefully next to a 2 kHz wide VARA Winlink station.

New VARA Narrow BW mode for SSB
VARA HF  (500 Hz BW limit) is very fast and very successful. I suspect more stations will switch to the "narrow BW" 500 Hz VARA modes soon.
VARA works well with simple sound cards (SignaLink) and typical phone filters (2.4 kHz) on USB rigs. Running 25W is usually sufficient for a solid "link" with VARA HF and a decent antenna.


I operate both NBEMS modes, as well as VARA and Pactor III Winlink modes when I need to contact someone on HF via a Winlink RF Gateway. Most of the Winlink traffic is pretty fast:  on/ARQ connect/traffic/ARQ disconnect.  When I watch and listen to what is happening on 80m from 3585 to 3600 kHz, most of the Winlink VARA and Pactor III connects are pretty fast unless the traffic is a very large file (which sometimes happens).

80 meters
I think if we were to have the agreement that CW has an exclusive region from 3500 to 3550 kHz (for now) we alleviate one issue. If we then were to designate say 3550 to 3570 for casual digi mode rag chew, we alleviate another conflict. And if we were to designate a region like 3570-3578 for the very narrow bandwidth modes like FT8/FT4  we give them some space to play without interference from the wider modes. If we were to designate 3580-3585 kHz (VFO) as an exclusive EMCOMM frequency for NBEMS nets using 500 Hz modes (THOR, MFSK)  then that takes care of one more potential conflict. So 3585-3600 kHz becomes, by default, an exclusive Winlink (radio email) region. 

"Walls (often) make good neighbors" comes to mind (Frost).

I still see a CW traffic net at 7 pm operating on 3585 kHz and wonder WHY there? I can not imagine a busier location to operate CW, let alone a traffic net. The band from 3500-3550 is mostly empty of CW in the early evenings. The response from the Traffic Net on 3585 kHz: "we've been here for years, so why should we move?" Thus, the problem becomes pretty self evident. New conditions, adjust. 

I don't know what happens on the other HF bands since we (Pa) do not use them for Pa regional state-wide NBEMS functions.

It helps to keep the conversation civil in either case.

73
Barry  k3eui
PaNBEMS net manager
West Chester   PA
k3euibarry - at - gmail.com




On Aug 30, 2020, at 10:39 PM, Jeff Moore - KE7ACY <tnetcenter@...> wrote:

Sorry Larry,

Everything he said IS NOT 100% accurate!!!

LEt's keep this to facts NOT ridiculous unsubstantiated accusations!

1.   Winlink nodes don't take up a frequency AND an OFFSET.  They operate on one frequency just like every other mode!  Do they use bandwidth??   YES - JUST LIKE EVERY OTHER MODE DOES!

2.  Winlink nodes DON'T BEACON!!   I've been using the Winlink system for years now - I've NEVER heard a Winlink node, gateway, or any other part of the system BEACON!

3.  Winlink systems don't sit on any frequency and prevent other users from using the frequency.  In FACT - Winlink systems don't do a thing UNLESS someone connects to them.  Then they pass traffic and DISCONNECT freeing the frequency for others to use.

4.  Inconsiderate operators use EVERY mode, not just the Winlink system - so blaming every problem on HF on Winlink users and operators is ludicrous and highlights not the problems but the complainers agenda ( and YES - they have an agenda, look at some of these messages and you can spot it immediately).

Let's keep these discussions honest people!!

This is a conversation that is needed!!

Emergency comms should use EVERY TOOL in the toolbox!!!   That includes using Winlink AND NBEMS together if needed!!!

You don't agree - that's your problem!  Don't make it everybody else's!

7   3
Jeff Moore  --  KE7ACY
CN94



On Sun, Aug 30, 2020 at 6:12 PM Larry Levesque <ka1vgm@...> wrote:
Give it up??
Can't people have differing opinions with you or does that not fit with your narrative?

Winlink has it's uses but everything he said was 100% the truth.


On Mon, Aug 31, 2020 at 07:20:04AM +1000, Jack Chomley wrote:
> Chris,
>
> Give it up, we don’t live in a perfect world and never will.  Generally people just try to get along in our shared spectrum like anything else that human beings have to share.
> Stirring up anarchy helps no one.  Go take a Valium and have good lay down for a while, it’s not all that bad :-)
>

>
> 73,
>
> Jack VK4LM
>
> Club.    www.cqara.org.au
>
>
> > On 31 Aug 2020, at 6:18 am, Chris E. <kc2rgw@...> wrote:
> >
> > 
> > There's no "sharing" with other users when a Winlink node is dumped. I know well how they work and I've been watching for a bunch of years as people instruct each other on mailing lists how to disable the busy detect on their TNCs to disrupt any other co-channel traffic. People know how they should be configured and choose to misconfigure them.
> >
> > I've been involved in OEM/RACES for quite a while and had two Winlink ops intentionally disrupt a 20yr established VHF packet network just so they could have their own creation running. This caused us to have to relocate an established packet network during actual hurricane activations.  Where were the Winlink people?  Nowhere to be found, but their nodes were occupying frequency space that could have been useful. Two inconsiderate people took down the packet network for a region. It's bad enough on VHF but with HF the impact is even greater.
> >
> > A Winlink node occupies a frequency and offset as soon as it's parked, they beacon 24/7 rendering the spot unusable by any other people. They currently disrupt digital operations of many other modes as they have spread to cover several hundred kHz above any of the PSK windows and they continue to even encroach on those lately. The users on this list know full well what I'm talking about, particularly in the Northeast where Winlink nodes have been littered shoulder to shoulder where NBEMS traffic and other keyboard to keyboard ops run. 3.582-3.586 is a Winlink graveyard at this point, they are everywhere and propagation is lousy, just wait until it picks up again.
> >
> > There is NO need for so many nodes within a single region to be left running full time. This is completely inconsiderate use of the spectrum. If there is a disaster, then turn them up but don't ruin the use of the spectrum 24/7 waiting for "the big one" to happen.
> >
> > I know what is happening with regard to the zombie Windows based gateways, because when I connect and the service is unresponsive it's due to the node needing a reboot. After contacting the admins and they reboot, the nodes function again. Many of the RMS gateways are in this dead state and do not respond upon connect, the service is dead, but they continue to beacon and occupy the offset they were dumped on.
> >
> > It's one of the worst sources of QRM going right now for digital ops.
> >
> > The voluntary nature of gentlemans' agreements just shows how inconsiderate people are. So I guess it would take it being outright illegal for people to be considerate of other users of the spectrum?
> >
> > Just because you may not use any other digital modes doesn't give the gateway ops the right to just dump them wherever without either consideration or knowledge of where they have dumped them.
> >
> > In an actual disaster, internet is down so how do you expect this wonder of email to save the day? Most people won't have any connectivity to receive the emails even if the gateways have a connection at the time.  It's a waste of time and spectrum and the only people it truly serves are wealthy boat owners who won't pay for a satellite connection.
> >
> > I've been through multiple hurricanes now, internet providers were down, cell providers were down, municipal comms were down, all for several days after the impact.  The only thing that was effective was simplex traffic handling via voice, packet or NBEMS modes. Email would have been of very little use.
> >
> > At the very least, Winlink needs to be channelized since the ops won't apply any discipline or courtesy as to where they dump the nodes. There should be no more than two in a coverage region that run all the time, there's no point to it when there isn't an activation.
> >
> >
> > On Sat, Aug 29, 2020 at 11:32 AM Dave Colter WA1ZCN <dbcolter@...> wrote:
> >> Chris,
> >>
> >> You’re making a lot of unsubstantiated claims here. First, “vanity” RMS stations – that’s not a thing. During a disaster, we need as many RMS stations as possible to avoid a severe bottleneck, so we’re encouraging more RMS stations. In NH, our plan is to have “regional” Winlink field stations handle all our in and outbound traffic and transfer it to its destination via P2P mode or NBEMS on HF or VHF. This helps to reduce the problem, but doesn’t solve it. In a widespread emergency, the few RMS stations that can be reached at any given time will still be clogged.
> >>
> >>
> >>
> >> Second, having a lot of RMS stations all on one frequency doesn’t work. I’ve never heard that that was in anyone’s plan. During an emergency, we need to have many stations available at one time. If they’re sharing a frequency, the only separation you’ll have is what propagation offers.
> >>
> >>
> >>
> >> If Winlink users at home connect to RMS stations several times a day via RF to check for messages, (I know some who do), I consider that excessive, and it likely creates the overcrowding issue you describe. We should all do our daily email checks via Telnet, and test the RF path once a week at most. That will help avoid the constant interference with other band users. I’ve never had a problem finding a quiet spot to operate digital modes, though. Our regular ARES digital net frequency is generally totally quiet.
> >>
> >>
> >>
> >> Regarding Windows crashing – how would you know what’s happening in someone else’s station?
> >>
> >>
> >>
> >> Remember that digital band plans are voluntary. FT8, Olivia, and other modes do have preferred frequencies or band segments, but our bands are simply not large enough (nor will they ever be) to allow a special frequency for every mode. So, we share.
> >>
> >>
> >>
> >> 73,
> >>
> >> Dave Colter WA1ZCN
> >>
> >> ASEC, Training - NH-ARES
> >>
> >> www.nh-ares.org
> >>
> >> Hamshack Hotline: Ext. 4806
> >>
> >> SHARES Voice: NNA1DC
> >>
> >>
> >>
> >>
> >>
> >
> >
> > --
> > 73  de Chris -- KC2RGW
> > https://sites.google.com/view/kc2rgw/
> > ------------------------------------------------------------
> > ˙dn ǝpıs ʇɥƃıɹ ɹoʇıuoɯ ɹnoʎ uɹnʇ
> > ǝsɐǝןd 'sıɥʇ ƃuıpɐǝɹ ǝɹɐ noʎ ɟı
> >
>
>
>

--
Larry Levesque
KA1VGM




Re: NBEMS and Winlink can work together

Dave
 

OK boys and girls, I think it is time to pull the plug on this topic and move on to something productive.

73, David, W1HKJ

Group owner


Re: NBEMS and Winlink can work together

Jeff Moore - KE7ACY
 

Sorry Larry,

Everything he said IS NOT 100% accurate!!!

LEt's keep this to facts NOT ridiculous unsubstantiated accusations!

1.   Winlink nodes don't take up a frequency AND an OFFSET.  They operate on one frequency just like every other mode!  Do they use bandwidth??   YES - JUST LIKE EVERY OTHER MODE DOES!

2.  Winlink nodes DON'T BEACON!!   I've been using the Winlink system for years now - I've NEVER heard a Winlink node, gateway, or any other part of the system BEACON!

3.  Winlink systems don't sit on any frequency and prevent other users from using the frequency.  In FACT - Winlink systems don't do a thing UNLESS someone connects to them.  Then they pass traffic and DISCONNECT freeing the frequency for others to use.

4.  Inconsiderate operators use EVERY mode, not just the Winlink system - so blaming every problem on HF on Winlink users and operators is ludicrous and highlights not the problems but the complainers agenda ( and YES - they have an agenda, look at some of these messages and you can spot it immediately).

Let's keep these discussions honest people!!

This is a conversation that is needed!!

Emergency comms should use EVERY TOOL in the toolbox!!!   That includes using Winlink AND NBEMS together if needed!!!

You don't agree - that's your problem!  Don't make it everybody else's!

7   3
Jeff Moore  --  KE7ACY
CN94



On Sun, Aug 30, 2020 at 6:12 PM Larry Levesque <ka1vgm@...> wrote:
Give it up??
Can't people have differing opinions with you or does that not fit with your narrative?

Winlink has it's uses but everything he said was 100% the truth.


On Mon, Aug 31, 2020 at 07:20:04AM +1000, Jack Chomley wrote:
> Chris,
>
> Give it up, we don’t live in a perfect world and never will.  Generally people just try to get along in our shared spectrum like anything else that human beings have to share.
> Stirring up anarchy helps no one.  Go take a Valium and have good lay down for a while, it’s not all that bad :-)
>

>
> 73,
>
> Jack VK4LM
>
> Club.    www.cqara.org.au
>
>
> > On 31 Aug 2020, at 6:18 am, Chris E. <kc2rgw@...> wrote:
> >
> > 
> > There's no "sharing" with other users when a Winlink node is dumped. I know well how they work and I've been watching for a bunch of years as people instruct each other on mailing lists how to disable the busy detect on their TNCs to disrupt any other co-channel traffic. People know how they should be configured and choose to misconfigure them.
> >
> > I've been involved in OEM/RACES for quite a while and had two Winlink ops intentionally disrupt a 20yr established VHF packet network just so they could have their own creation running. This caused us to have to relocate an established packet network during actual hurricane activations.  Where were the Winlink people?  Nowhere to be found, but their nodes were occupying frequency space that could have been useful. Two inconsiderate people took down the packet network for a region. It's bad enough on VHF but with HF the impact is even greater.
> >
> > A Winlink node occupies a frequency and offset as soon as it's parked, they beacon 24/7 rendering the spot unusable by any other people. They currently disrupt digital operations of many other modes as they have spread to cover several hundred kHz above any of the PSK windows and they continue to even encroach on those lately. The users on this list know full well what I'm talking about, particularly in the Northeast where Winlink nodes have been littered shoulder to shoulder where NBEMS traffic and other keyboard to keyboard ops run. 3.582-3.586 is a Winlink graveyard at this point, they are everywhere and propagation is lousy, just wait until it picks up again.
> >
> > There is NO need for so many nodes within a single region to be left running full time. This is completely inconsiderate use of the spectrum. If there is a disaster, then turn them up but don't ruin the use of the spectrum 24/7 waiting for "the big one" to happen.
> >
> > I know what is happening with regard to the zombie Windows based gateways, because when I connect and the service is unresponsive it's due to the node needing a reboot. After contacting the admins and they reboot, the nodes function again. Many of the RMS gateways are in this dead state and do not respond upon connect, the service is dead, but they continue to beacon and occupy the offset they were dumped on.
> >
> > It's one of the worst sources of QRM going right now for digital ops.
> >
> > The voluntary nature of gentlemans' agreements just shows how inconsiderate people are. So I guess it would take it being outright illegal for people to be considerate of other users of the spectrum?
> >
> > Just because you may not use any other digital modes doesn't give the gateway ops the right to just dump them wherever without either consideration or knowledge of where they have dumped them.
> >
> > In an actual disaster, internet is down so how do you expect this wonder of email to save the day? Most people won't have any connectivity to receive the emails even if the gateways have a connection at the time.  It's a waste of time and spectrum and the only people it truly serves are wealthy boat owners who won't pay for a satellite connection.
> >
> > I've been through multiple hurricanes now, internet providers were down, cell providers were down, municipal comms were down, all for several days after the impact.  The only thing that was effective was simplex traffic handling via voice, packet or NBEMS modes. Email would have been of very little use.
> >
> > At the very least, Winlink needs to be channelized since the ops won't apply any discipline or courtesy as to where they dump the nodes. There should be no more than two in a coverage region that run all the time, there's no point to it when there isn't an activation.
> >
> >
> > On Sat, Aug 29, 2020 at 11:32 AM Dave Colter WA1ZCN <dbcolter@...> wrote:
> >> Chris,
> >>
> >> You’re making a lot of unsubstantiated claims here. First, “vanity” RMS stations – that’s not a thing. During a disaster, we need as many RMS stations as possible to avoid a severe bottleneck, so we’re encouraging more RMS stations. In NH, our plan is to have “regional” Winlink field stations handle all our in and outbound traffic and transfer it to its destination via P2P mode or NBEMS on HF or VHF. This helps to reduce the problem, but doesn’t solve it. In a widespread emergency, the few RMS stations that can be reached at any given time will still be clogged.
> >>
> >>
> >>
> >> Second, having a lot of RMS stations all on one frequency doesn’t work. I’ve never heard that that was in anyone’s plan. During an emergency, we need to have many stations available at one time. If they’re sharing a frequency, the only separation you’ll have is what propagation offers.
> >>
> >>
> >>
> >> If Winlink users at home connect to RMS stations several times a day via RF to check for messages, (I know some who do), I consider that excessive, and it likely creates the overcrowding issue you describe. We should all do our daily email checks via Telnet, and test the RF path once a week at most. That will help avoid the constant interference with other band users. I’ve never had a problem finding a quiet spot to operate digital modes, though. Our regular ARES digital net frequency is generally totally quiet.
> >>
> >>
> >>
> >> Regarding Windows crashing – how would you know what’s happening in someone else’s station?
> >>
> >>
> >>
> >> Remember that digital band plans are voluntary. FT8, Olivia, and other modes do have preferred frequencies or band segments, but our bands are simply not large enough (nor will they ever be) to allow a special frequency for every mode. So, we share.
> >>
> >>
> >>
> >> 73,
> >>
> >> Dave Colter WA1ZCN
> >>
> >> ASEC, Training - NH-ARES
> >>
> >> www.nh-ares.org
> >>
> >> Hamshack Hotline: Ext. 4806
> >>
> >> SHARES Voice: NNA1DC
> >>
> >>
> >>
> >>
> >>
> >
> >
> > --
> > 73  de Chris -- KC2RGW
> > https://sites.google.com/view/kc2rgw/
> > ------------------------------------------------------------
> > ˙dn ǝpıs ʇɥƃıɹ ɹoʇıuoɯ ɹnoʎ uɹnʇ
> > ǝsɐǝןd 'sıɥʇ ƃuıpɐǝɹ ǝɹɐ noʎ ɟı
> >
>
>
>

--
Larry Levesque
KA1VGM




Re: NBEMS and Winlink can work together

Jack Chomley
 

And then in Australia, our ham radio peak body the WIA does not want to know about Winlink and never has :-( So we just make our own plans, something that most Australians know well :-)


73,

Jack VK4LM

Club.    www.cqara.org.au


On 31 Aug 2020, at 11:39 am, Ronald Pfeiffer via groups.io <w2ctx@...> wrote:


This discussion should have happened the day after Winlink was announced and blessed by papa corporate (ARRL)!




On Sunday, August 30, 2020, 9:21:18 PM EDT, Craig Lundborg <kd7cl@...> wrote:


Chris... Isn't it interesting that we are supposed to learn to share on the amateur bands that a commercial organization is using to send on and tie up substantial sections of the band.
   When all these unmanned gateways eventually take over... Will it be too late to complain or "share"...???

--
Sent from EmailForOutlook for mobile


01:17 PM from kc2rgw@...:
There's no "sharing" with other users when a Winlink node is dumped. I know well how they work and I've been watching for a bunch of years as people instruct each other on mailing lists how to disable the busy detect on their TNCs to disrupt any other co-channel traffic. People know how they should be configured and choose to misconfigure them.

I've been involved in OEM/RACES for quite a while and had two Winlink ops intentionally disrupt a 20yr established VHF packet network just so they could have their own creation running. This caused us to have to relocate an established packet network during actual hurricane activations.  Where were the Winlink people?  Nowhere to be found, but their nodes were occupying frequency space that could have been useful. Two inconsiderate people took down the packet network for a region. It's bad enough on VHF but with HF the impact is even greater.

A Winlink node occupies a frequency and offset as soon as it's parked, they beacon 24/7 rendering the spot unusable by any other people. They currently disrupt digital operations of many other modes as they have spread to cover several hundred kHz above any of the PSK windows and they continue to even encroach on those lately. The users on this list know full well what I'm talking about, particularly in the Northeast where Winlink nodes have been littered shoulder to shoulder where NBEMS traffic and other keyboard to keyboard ops run. 3.582-3.586 is a Winlink graveyard at this point, they are everywhere and propagation is lousy, just wait until it picks up again.

There is NO need for so many nodes within a single region to be left running full time. This is completely inconsiderate use of the spectrum. If there is a disaster, then turn them up but don't ruin the use of the spectrum 24/7 waiting for "the big one" to happen.

I know what is happening with regard to the zombie Windows based gateways, because when I connect and the service is unresponsive it's due to the node needing a reboot. After contacting the admins and they reboot, the nodes function again. Many of the RMS gateways are in this dead state and do not respond upon connect, the service is dead, but they continue to beacon and occupy the offset they were dumped on.

It's one of the worst sources of QRM going right now for digital ops.

The voluntary nature of gentlemans' agreements just shows how inconsiderate people are. So I guess it would take it being outright illegal for people to be considerate of other users of the spectrum?

Just because you may not use any other digital modes doesn't give the gateway ops the right to just dump them wherever without either consideration or knowledge of where they have dumped them.

In an actual disaster, internet is down so how do you expect this wonder of email to save the day? Most people won't have any connectivity to receive the emails even if the gateways have a connection at the time.  It's a waste of time and spectrum and the only people it truly serves are wealthy boat owners who won't pay for a satellite connection.

I've been through multiple hurricanes now, internet providers were down, cell providers were down, municipal comms were down, all for several days after the impact.  The only thing that was effective was simplex traffic handling via voice, packet or NBEMS modes. Email would have been of very little use.

At the very least, Winlink needs to be channelized since the ops won't apply any discipline or courtesy as to where they dump the nodes. There should be no more than two in a coverage region that run all the time, there's no point to it when there isn't an activation.


On Sat, Aug 29, 2020 at 11:32 AM Dave Colter WA1ZCN <dbcolter@...> wrote:

Chris,

You’re making a lot of unsubstantiated claims here. First, “vanity” RMS stations – that’s not a thing. During a disaster, we need as many RMS stations as possible to avoid a severe bottleneck, so we’re encouraging more RMS stations. In NH, our plan is to have “regional” Winlink field stations handle all our in and outbound traffic and transfer it to its destination via P2P mode or NBEMS on HF or VHF. This helps to reduce the problem, but doesn’t solve it. In a widespread emergency, the few RMS stations that can be reached at any given time will still be clogged.

 

Second, having a lot of RMS stations all on one frequency doesn’t work. I’ve never heard that that was in anyone’s plan. During an emergency, we need to have many stations available at one time. If they’re sharing a frequency, the only separation you’ll have is what propagation offers.

 

If Winlink users at home connect to RMS stations several times a day via RF to check for messages, (I know some who do), I consider that excessive, and it likely creates the overcrowding issue you describe. We should all do our daily email checks via Telnet, and test the RF path once a week at most. That will help avoid the constant interference with other band users. I’ve never had a problem finding a quiet spot to operate digital modes, though. Our regular ARES digital net frequency is generally totally quiet.

 

Regarding Windows crashing – how would you know what’s happening in someone else’s station?

 

Remember that digital band plans are voluntary. FT8, Olivia, and other modes do have preferred frequencies or band segments, but our bands are simply not large enough (nor will they ever be) to allow a special frequency for every mode. So, we share.

 

73,

Dave Colter WA1ZCN

ASEC, Training - NH-ARES

www.nh-ares.org

Hamshack Hotline: Ext. 4806

SHARES Voice: NNA1DC

 

 



--
73  de Chris -- KC2RGW
https://sites.google.com/view/kc2rgw/
------------------------------------------------------------
˙dn ǝpıs ʇɥƃıɹ ɹoʇıuoɯ ɹnoʎ uɹnʇ
ǝsɐǝןd 'sıɥʇ ƃuıpɐǝɹ ǝɹɐ noʎ ɟı


Re: NBEMS and Winlink can work together

Ronald Pfeiffer
 

This discussion should have happened the day after Winlink was announced and blessed by papa corporate (ARRL)!




On Sunday, August 30, 2020, 9:21:18 PM EDT, Craig Lundborg <kd7cl@...> wrote:


Chris... Isn't it interesting that we are supposed to learn to share on the amateur bands that a commercial organization is using to send on and tie up substantial sections of the band.
   When all these unmanned gateways eventually take over... Will it be too late to complain or "share"...???

--
Sent from EmailForOutlook for mobile


01:17 PM from kc2rgw@...:
There's no "sharing" with other users when a Winlink node is dumped. I know well how they work and I've been watching for a bunch of years as people instruct each other on mailing lists how to disable the busy detect on their TNCs to disrupt any other co-channel traffic. People know how they should be configured and choose to misconfigure them.

I've been involved in OEM/RACES for quite a while and had two Winlink ops intentionally disrupt a 20yr established VHF packet network just so they could have their own creation running. This caused us to have to relocate an established packet network during actual hurricane activations.  Where were the Winlink people?  Nowhere to be found, but their nodes were occupying frequency space that could have been useful. Two inconsiderate people took down the packet network for a region. It's bad enough on VHF but with HF the impact is even greater.

A Winlink node occupies a frequency and offset as soon as it's parked, they beacon 24/7 rendering the spot unusable by any other people. They currently disrupt digital operations of many other modes as they have spread to cover several hundred kHz above any of the PSK windows and they continue to even encroach on those lately. The users on this list know full well what I'm talking about, particularly in the Northeast where Winlink nodes have been littered shoulder to shoulder where NBEMS traffic and other keyboard to keyboard ops run. 3.582-3.586 is a Winlink graveyard at this point, they are everywhere and propagation is lousy, just wait until it picks up again.

There is NO need for so many nodes within a single region to be left running full time. This is completely inconsiderate use of the spectrum. If there is a disaster, then turn them up but don't ruin the use of the spectrum 24/7 waiting for "the big one" to happen.

I know what is happening with regard to the zombie Windows based gateways, because when I connect and the service is unresponsive it's due to the node needing a reboot. After contacting the admins and they reboot, the nodes function again. Many of the RMS gateways are in this dead state and do not respond upon connect, the service is dead, but they continue to beacon and occupy the offset they were dumped on.

It's one of the worst sources of QRM going right now for digital ops.

The voluntary nature of gentlemans' agreements just shows how inconsiderate people are. So I guess it would take it being outright illegal for people to be considerate of other users of the spectrum?

Just because you may not use any other digital modes doesn't give the gateway ops the right to just dump them wherever without either consideration or knowledge of where they have dumped them.

In an actual disaster, internet is down so how do you expect this wonder of email to save the day? Most people won't have any connectivity to receive the emails even if the gateways have a connection at the time.  It's a waste of time and spectrum and the only people it truly serves are wealthy boat owners who won't pay for a satellite connection.

I've been through multiple hurricanes now, internet providers were down, cell providers were down, municipal comms were down, all for several days after the impact.  The only thing that was effective was simplex traffic handling via voice, packet or NBEMS modes. Email would have been of very little use.

At the very least, Winlink needs to be channelized since the ops won't apply any discipline or courtesy as to where they dump the nodes. There should be no more than two in a coverage region that run all the time, there's no point to it when there isn't an activation.


On Sat, Aug 29, 2020 at 11:32 AM Dave Colter WA1ZCN <dbcolter@...> wrote:

Chris,

You’re making a lot of unsubstantiated claims here. First, “vanity” RMS stations – that’s not a thing. During a disaster, we need as many RMS stations as possible to avoid a severe bottleneck, so we’re encouraging more RMS stations. In NH, our plan is to have “regional” Winlink field stations handle all our in and outbound traffic and transfer it to its destination via P2P mode or NBEMS on HF or VHF. This helps to reduce the problem, but doesn’t solve it. In a widespread emergency, the few RMS stations that can be reached at any given time will still be clogged.

 

Second, having a lot of RMS stations all on one frequency doesn’t work. I’ve never heard that that was in anyone’s plan. During an emergency, we need to have many stations available at one time. If they’re sharing a frequency, the only separation you’ll have is what propagation offers.

 

If Winlink users at home connect to RMS stations several times a day via RF to check for messages, (I know some who do), I consider that excessive, and it likely creates the overcrowding issue you describe. We should all do our daily email checks via Telnet, and test the RF path once a week at most. That will help avoid the constant interference with other band users. I’ve never had a problem finding a quiet spot to operate digital modes, though. Our regular ARES digital net frequency is generally totally quiet.

 

Regarding Windows crashing – how would you know what’s happening in someone else’s station?

 

Remember that digital band plans are voluntary. FT8, Olivia, and other modes do have preferred frequencies or band segments, but our bands are simply not large enough (nor will they ever be) to allow a special frequency for every mode. So, we share.

 

73,

Dave Colter WA1ZCN

ASEC, Training - NH-ARES

www.nh-ares.org

Hamshack Hotline: Ext. 4806

SHARES Voice: NNA1DC

 

 



--
73  de Chris -- KC2RGW
https://sites.google.com/view/kc2rgw/
------------------------------------------------------------
˙dn ǝpıs ʇɥƃıɹ ɹoʇıuoɯ ɹnoʎ uɹnʇ
ǝsɐǝןd 'sıɥʇ ƃuıpɐǝɹ ǝɹɐ noʎ ɟı


Re: NBEMS and Winlink can work together

Jack Chomley
 

Interesting Craig, my WinLink RMS base makes no money as a ‘commercial’ entity and only provides a community service for which I am happy to spend thousands of dollars setting it up and running, it For others to benefit........

73,

Jack VK4LM

Club.    www.cqara.org.au


On 31 Aug 2020, at 11:21 am, Craig Lundborg <KD7CL@...> wrote:



Chris... Isn't it interesting that we are supposed to learn to share on the amateur bands that a commercial organization is using to send on and tie up substantial sections of the band.
   When all these unmanned gateways eventually take over... Will it be too late to complain or "share"...???

--
Sent from EmailForOutlook for mobile


01:17 PM from kc2rgw@...:
There's no "sharing" with other users when a Winlink node is dumped. I know well how they work and I've been watching for a bunch of years as people instruct each other on mailing lists how to disable the busy detect on their TNCs to disrupt any other co-channel traffic. People know how they should be configured and choose to misconfigure them.

I've been involved in OEM/RACES for quite a while and had two Winlink ops intentionally disrupt a 20yr established VHF packet network just so they could have their own creation running. This caused us to have to relocate an established packet network during actual hurricane activations.  Where were the Winlink people?  Nowhere to be found, but their nodes were occupying frequency space that could have been useful. Two inconsiderate people took down the packet network for a region. It's bad enough on VHF but with HF the impact is even greater.

A Winlink node occupies a frequency and offset as soon as it's parked, they beacon 24/7 rendering the spot unusable by any other people. They currently disrupt digital operations of many other modes as they have spread to cover several hundred kHz above any of the PSK windows and they continue to even encroach on those lately. The users on this list know full well what I'm talking about, particularly in the Northeast where Winlink nodes have been littered shoulder to shoulder where NBEMS traffic and other keyboard to keyboard ops run. 3.582-3.586 is a Winlink graveyard at this point, they are everywhere and propagation is lousy, just wait until it picks up again.

There is NO need for so many nodes within a single region to be left running full time. This is completely inconsiderate use of the spectrum. If there is a disaster, then turn them up but don't ruin the use of the spectrum 24/7 waiting for "the big one" to happen.

I know what is happening with regard to the zombie Windows based gateways, because when I connect and the service is unresponsive it's due to the node needing a reboot. After contacting the admins and they reboot, the nodes function again. Many of the RMS gateways are in this dead state and do not respond upon connect, the service is dead, but they continue to beacon and occupy the offset they were dumped on.

It's one of the worst sources of QRM going right now for digital ops.

The voluntary nature of gentlemans' agreements just shows how inconsiderate people are. So I guess it would take it being outright illegal for people to be considerate of other users of the spectrum?

Just because you may not use any other digital modes doesn't give the gateway ops the right to just dump them wherever without either consideration or knowledge of where they have dumped them.

In an actual disaster, internet is down so how do you expect this wonder of email to save the day? Most people won't have any connectivity to receive the emails even if the gateways have a connection at the time.  It's a waste of time and spectrum and the only people it truly serves are wealthy boat owners who won't pay for a satellite connection.

I've been through multiple hurricanes now, internet providers were down, cell providers were down, municipal comms were down, all for several days after the impact.  The only thing that was effective was simplex traffic handling via voice, packet or NBEMS modes. Email would have been of very little use.

At the very least, Winlink needs to be channelized since the ops won't apply any discipline or courtesy as to where they dump the nodes. There should be no more than two in a coverage region that run all the time, there's no point to it when there isn't an activation.


On Sat, Aug 29, 2020 at 11:32 AM Dave Colter WA1ZCN <dbcolter@...> wrote:

Chris,

You’re making a lot of unsubstantiated claims here. First, “vanity” RMS stations – that’s not a thing. During a disaster, we need as many RMS stations as possible to avoid a severe bottleneck, so we’re encouraging more RMS stations. In NH, our plan is to have “regional” Winlink field stations handle all our in and outbound traffic and transfer it to its destination via P2P mode or NBEMS on HF or VHF. This helps to reduce the problem, but doesn’t solve it. In a widespread emergency, the few RMS stations that can be reached at any given time will still be clogged.

 

Second, having a lot of RMS stations all on one frequency doesn’t work. I’ve never heard that that was in anyone’s plan. During an emergency, we need to have many stations available at one time. If they’re sharing a frequency, the only separation you’ll have is what propagation offers.

 

If Winlink users at home connect to RMS stations several times a day via RF to check for messages, (I know some who do), I consider that excessive, and it likely creates the overcrowding issue you describe. We should all do our daily email checks via Telnet, and test the RF path once a week at most. That will help avoid the constant interference with other band users. I’ve never had a problem finding a quiet spot to operate digital modes, though. Our regular ARES digital net frequency is generally totally quiet.

 

Regarding Windows crashing – how would you know what’s happening in someone else’s station?

 

Remember that digital band plans are voluntary. FT8, Olivia, and other modes do have preferred frequencies or band segments, but our bands are simply not large enough (nor will they ever be) to allow a special frequency for every mode. So, we share.

 

73,

Dave Colter WA1ZCN

ASEC, Training - NH-ARES

www.nh-ares.org

Hamshack Hotline: Ext. 4806

SHARES Voice: NNA1DC

 

 



--
73  de Chris -- KC2RGW
https://sites.google.com/view/kc2rgw/
------------------------------------------------------------
˙dn ǝpıs ʇɥƃıɹ ɹoʇıuoɯ ɹnoʎ uɹnʇ
ǝsɐǝןd 'sıɥʇ ƃuıpɐǝɹ ǝɹɐ noʎ ɟı


Re: NBEMS and Winlink can work together

Craig Lundborg
 

Chris... Isn't it interesting that we are supposed to learn to share on the amateur bands that a commercial organization is using to send on and tie up substantial sections of the band.
   When all these unmanned gateways eventually take over... Will it be too late to complain or "share"...???

--
Sent from EmailForOutlook for mobile


01:17 PM from kc2rgw@...:
There's no "sharing" with other users when a Winlink node is dumped. I know well how they work and I've been watching for a bunch of years as people instruct each other on mailing lists how to disable the busy detect on their TNCs to disrupt any other co-channel traffic. People know how they should be configured and choose to misconfigure them.

I've been involved in OEM/RACES for quite a while and had two Winlink ops intentionally disrupt a 20yr established VHF packet network just so they could have their own creation running. This caused us to have to relocate an established packet network during actual hurricane activations.  Where were the Winlink people?  Nowhere to be found, but their nodes were occupying frequency space that could have been useful. Two inconsiderate people took down the packet network for a region. It's bad enough on VHF but with HF the impact is even greater.

A Winlink node occupies a frequency and offset as soon as it's parked, they beacon 24/7 rendering the spot unusable by any other people. They currently disrupt digital operations of many other modes as they have spread to cover several hundred kHz above any of the PSK windows and they continue to even encroach on those lately. The users on this list know full well what I'm talking about, particularly in the Northeast where Winlink nodes have been littered shoulder to shoulder where NBEMS traffic and other keyboard to keyboard ops run. 3.582-3.586 is a Winlink graveyard at this point, they are everywhere and propagation is lousy, just wait until it picks up again.

There is NO need for so many nodes within a single region to be left running full time. This is completely inconsiderate use of the spectrum. If there is a disaster, then turn them up but don't ruin the use of the spectrum 24/7 waiting for "the big one" to happen.

I know what is happening with regard to the zombie Windows based gateways, because when I connect and the service is unresponsive it's due to the node needing a reboot. After contacting the admins and they reboot, the nodes function again. Many of the RMS gateways are in this dead state and do not respond upon connect, the service is dead, but they continue to beacon and occupy the offset they were dumped on.

It's one of the worst sources of QRM going right now for digital ops.

The voluntary nature of gentlemans' agreements just shows how inconsiderate people are. So I guess it would take it being outright illegal for people to be considerate of other users of the spectrum?

Just because you may not use any other digital modes doesn't give the gateway ops the right to just dump them wherever without either consideration or knowledge of where they have dumped them.

In an actual disaster, internet is down so how do you expect this wonder of email to save the day? Most people won't have any connectivity to receive the emails even if the gateways have a connection at the time.  It's a waste of time and spectrum and the only people it truly serves are wealthy boat owners who won't pay for a satellite connection.

I've been through multiple hurricanes now, internet providers were down, cell providers were down, municipal comms were down, all for several days after the impact.  The only thing that was effective was simplex traffic handling via voice, packet or NBEMS modes. Email would have been of very little use.

At the very least, Winlink needs to be channelized since the ops won't apply any discipline or courtesy as to where they dump the nodes. There should be no more than two in a coverage region that run all the time, there's no point to it when there isn't an activation.


On Sat, Aug 29, 2020 at 11:32 AM Dave Colter WA1ZCN <dbcolter@...> wrote:

Chris,

You’re making a lot of unsubstantiated claims here. First, “vanity” RMS stations – that’s not a thing. During a disaster, we need as many RMS stations as possible to avoid a severe bottleneck, so we’re encouraging more RMS stations. In NH, our plan is to have “regional” Winlink field stations handle all our in and outbound traffic and transfer it to its destination via P2P mode or NBEMS on HF or VHF. This helps to reduce the problem, but doesn’t solve it. In a widespread emergency, the few RMS stations that can be reached at any given time will still be clogged.

 

Second, having a lot of RMS stations all on one frequency doesn’t work. I’ve never heard that that was in anyone’s plan. During an emergency, we need to have many stations available at one time. If they’re sharing a frequency, the only separation you’ll have is what propagation offers.

 

If Winlink users at home connect to RMS stations several times a day via RF to check for messages, (I know some who do), I consider that excessive, and it likely creates the overcrowding issue you describe. We should all do our daily email checks via Telnet, and test the RF path once a week at most. That will help avoid the constant interference with other band users. I’ve never had a problem finding a quiet spot to operate digital modes, though. Our regular ARES digital net frequency is generally totally quiet.

 

Regarding Windows crashing – how would you know what’s happening in someone else’s station?

 

Remember that digital band plans are voluntary. FT8, Olivia, and other modes do have preferred frequencies or band segments, but our bands are simply not large enough (nor will they ever be) to allow a special frequency for every mode. So, we share.

 

73,

Dave Colter WA1ZCN

ASEC, Training - NH-ARES

www.nh-ares.org

Hamshack Hotline: Ext. 4806

SHARES Voice: NNA1DC

 

 



--
73  de Chris -- KC2RGW
https://sites.google.com/view/kc2rgw/
------------------------------------------------------------
˙dn ǝpıs ʇɥƃıɹ ɹoʇıuoɯ ɹnoʎ uɹnʇ
ǝsɐǝןd 'sıɥʇ ƃuıpɐǝɹ ǝɹɐ noʎ ɟı