Topics

Linux RMS - headed for digital dustbin?

Randy Neals
 


It appears that LinuxRMS may stop working in the near future when Winlink CMS stops supporting legacy mode.

Has anyone made LinBPQ work with Direwolf?
I’d like to do that on. RPi w/UDRC.
(For clarity, as a Winlink RMS Gateway, not a client)

Thanks,
Randy W3RWN


---------- Forwarded message ---------
From: lor.kutchins@... [LinuxRMS] <LinuxRMS@...>
Date: Wed, Oct 3, 2018 at 11:08 AM
Subject: [LinuxRMS] Last attempt to reach a maintainer (From the WDT)
To: <LinuxRMS@...>


 

All,


Both Lee Inman and I have been trying at various times since June 2017 to reach either Brian, W3SG or Hans, the creator and maintainer of Linus RMS Gateway. The Winlink system changed it's web services last year and info was provided to them so they could update Linux RMS Gateway to be compatible with the new CMS web services. We have been maintaining both the old and new CMS web services as all our partner authors made their updates. The time to shut the legacy support down is approaching after a year or more. All other authors have managed to make the needed changes.


So, with numerous private emails going unanswered, this our last attempt to urge Brian, Hans, or whoever is now maintaining this software to engage and update version 2.4.0.0 to use the current Winlink standard CMS connections and web services.


If someone new is now managing this package, please contact us through the Winlink web site. We can provide all the technical information needed.


If this is not resolved and you operate a gateway using Linux RMS Gateway, please do your best to inform the authors of the urgency of this request, and if you also get no response, we strongly suggest you consider a move to a different software package. LinBPQ is well maintained, as are the WDT's Windows-based offerings.


Please pass this message along to anyone you think might be affected. Thanks!


73,

Lor Kutchins, W3QA

President,

Amateur Radio Safety Foundation, Inc.

Winlink Global Radio Email ®️

Winlink Development Team


__._,_.___

Posted by: lor.kutchins@...
Reply via web post Reply to sender Reply to group Start a New Topic

.

__,_._,___

Scott Currie
 

So, theoretically yes. I don't currently have a UDRC available, but I have run my plinBPQ node and pointed it to a Direwolf instance running on a different Linux machine on the local LAN. Running on the local host should work the same way. You can use either the AGW port or the KISS port on BPQ, here is the port config I used:

PORT
ID=DIREWOLF KISS
TYPE=ASYNC
PROTOCOL=KISS
IPADDR=192.168.1.88  <-change this to 127.0.0.1 for local host
TCPPORT=8100
CHANNEL=A
QUALITY=0
MAXFRAME=7
FULLDUP=0
FRACK=7000
RESPTIME=1000
RETRIES=10
PACLEN=255
TXDELAY=150
SLOTTIME=50
PERSIST=64
KISSOPTIONS=ACKMODE
ENDPORT

I was testing 4800b connections, so running PACLEN-255, YMMV.

So, the process would be something like:
Install the Compass load with UDRC support.
Install Direwolf and configure it to work with UDRC (well documented on NWDR)
Install plinBPQ and configure a KISS port pointing to localhost.

Then convince your users to run faster than 1200!

-Scott, NS7C

john.wiseman@...
 

Randy,

Yes, you can run LinBPQ as a Winlink Gateway on a RPi with Direwolf.

There are instructions for setting up an RMS Gateway on a Pi here:

http://www.cantab.net/users/john.wiseman/Downloads/LinBPQ_RMSGateway.html

The simplest way to link DIrewolf to LinBPQ is to use the KISS over TCP interface. For fore information contact me direct or join the BPQ32 Yahoo Group.

73,
John G8BPQ


On 03/10/2018 23:10, Randy Neals wrote:

It appears that LinuxRMS may stop working in the near future when Winlink CMS stops supporting legacy mode.

Has anyone made LinBPQ work with Direwolf?
I’d like to do that on. RPi w/UDRC.
(For clarity, as a Winlink RMS Gateway, not a client)

Thanks,
Randy W3RWN


---------- Forwarded message ---------

From: lor.kutchins@... [LinuxRMS] <LinuxRMS@...>
Date: Wed, Oct 3, 2018 at 11:08 AM
Subject: [LinuxRMS] Last attempt to reach a maintainer (From the WDT)
To: <LinuxRMS@...>


 

All,


Both Lee Inman and I have been trying at various times since June 2017 to reach either Brian, W3SG or Hans, the creator and maintainer of Linus RMS Gateway. The Winlink system changed it's web services last year and info was provided to them so they could update Linux RMS Gateway to be compatible with the new CMS web services. We have been maintaining both the old and new CMS web services as all our partner authors made their updates. The time to shut the legacy support down is approaching after a year or more. All other authors have managed to make the needed changes.


So, with numerous private emails going unanswered, this our last attempt to urge Brian, Hans, or whoever is now maintaining this software to engage and update version 2.4.0.0 to use the current Winlink standard CMS connections and web services.


If someone new is now managing this package, please contact us through the Winlink web site. We can provide all the technical information needed.


If this is not resolved and you operate a gateway using Linux RMS Gateway, please do your best to inform the authors of the urgency of this request, and if you also get no response, we strongly suggest you consider a move to a different software package. LinBPQ is well maintained, as are the WDT's Windows-based offerings.


Please pass this message along to anyone you think might be affected. Thanks!


73,

Lor Kutchins, W3QA

President,

Amateur Radio Safety Foundation, Inc.

Winlink Global Radio Email ®️

Winlink Development Team


__._,_.___

Posted by: lor.kutchins@...
Reply via web post Reply to sender Reply to group Start a New Topic

.

__,_._,___

sancudo
 

[Moderator - this should be in the UDRC subgroup.]
 
John
I've been looking for an alternative platform to run Winlink Express as a client on. I've had problems running the winlink program on the raspberry pi 3+ using Wine or EXAGEAR per instructions on the web. Now it looks like I can use LinBPQ on the pi with Direwolf to set up a setup similar to Winlink Express from what I'm reading here, is that correct?
Mario
WO5O

On Thu, Oct 4, 2018, 4:02 AM <john.wiseman@...> wrote:
Randy,

Yes, you can run LinBPQ as a Winlink Gateway on a RPi with Direwolf.

There are instructions for setting up an RMS Gateway on a Pi here:

http://www.cantab.net/users/john.wiseman/Downloads/LinBPQ_RMSGateway.html

The simplest way to link DIrewolf to LinBPQ is to use the KISS over TCP interface. For fore information contact me direct or join the BPQ32 Yahoo Group.

73,
John G8BPQ

Scott Currie
 

plinBPQ is not a platform you can run WE on. It can serve as a CMS gateway, or even a connection to a TNC/soundcard for WE to use, but you would still need to install WE "elsewhere". Getting WE to install and run on the Pi architecture is indeed difficult if not impossible. Certainly not something I would suggest.

-Scott, NS7C 

Basil Gunn
 

Scott Currie <@ns7c> writes:

plinBPQ is not a platform you can run WE on. It can serve as a CMS
gateway, or even a connection to a TNC/soundcard for WE to use, but
you would still need to install WE "elsewhere". Getting WE to install
and run on the Pi architecture is indeed difficult if not
impossible. Certainly not something I would suggest.
Yes my apologies if anyone thought I was promoting that. You can NOT run
WE or most/any windows apps on an ARM platform under wine. I am not a
fan of wine ... the not an emulator thing. The native linux apps work
pretty well for winlink messaging when using an RPi/Direwolf/UDRC.

/Basil

Steve
 

Wine has not been ported to the ARM architecture, so NO Windoze app will work on a RPi.

Is the real challenge here a Winlink development team which is myopic in their support for various operating systems? If W1HKJ can build, test, and support three operating systems for the FLDigi suite, why can't they? In Emcomm situations, where interoperability is the key, that just doesn't make sense.

It is most difficult to be boxed into a position where one has to tell a volunteer that they must pay homage to a large company in Redmond, Washington, in order to use Winlink Express forms. That would be like telling hams they all have to buy radios from the same company.

We need to have a viable RPi solution for very portable Emcomm use, both in the client (with forms) and RMS rolls.

Steve


Basil Gunn wrote on 10/4/18 2:29 PM:

Scott Currie<@ns7c> writes:

plinBPQ is not a platform you can run WE on. It can serve as a CMS
gateway, or even a connection to a TNC/soundcard for WE to use, but
you would still need to install WE "elsewhere". Getting WE to install
and run on the Pi architecture is indeed difficult if not
impossible. Certainly not something I would suggest.
Yes my apologies if anyone thought I was promoting that. You can NOT run
WE or most/any windows apps on an ARM platform under wine. I am not a
fan of wine ... the not an emulator thing. The native linux apps work
pretty well for winlink messaging when using an RPi/Direwolf/UDRC.

sancudo
 

I agree with Steve. The whole idea of Emcomm is for portability, in my opinion. I like using laptops too but I would like an option of using an OS other than WinDoze if the case arises that WinDoze has been compromised. And if the pi or another OS based microcomputer is available that's light and less power hungry the better.
Mario

On Thu, Oct 4, 2018, 5:09 PM Steve <yahoo-udr@...> wrote:
Wine has not been ported to the ARM architecture, so NO Windoze app will
work on a RPi.

Is the real challenge here a Winlink development team which is myopic in
their support for various operating systems?  If W1HKJ can build, test,
and support three operating systems for the FLDigi suite, why can't
they?  In Emcomm situations, where interoperability is the key, that
just doesn't make sense.

It is most difficult to be boxed into a position where one has to tell a
volunteer that they must pay homage to a large company in Redmond,
Washington, in order to use Winlink Express forms.  That would be like
telling hams they all have to buy radios from the same company.

We need to have a viable RPi solution for very portable Emcomm use, both
in the client (with forms) and RMS rolls.

Steve


Basil Gunn wrote on 10/4/18 2:29 PM:
> Scott Currie<scott.d.currie@...>  writes:
>
>> plinBPQ is not a platform you can run WE on. It can serve as a CMS
>> gateway, or even a connection to a TNC/soundcard for WE to use, but
>> you would still need to install WE "elsewhere". Getting WE to install
>> and run on the Pi architecture is indeed difficult if not
>> impossible. Certainly not something I would suggest.
> > Yes my apologies if anyone thought I was promoting that. You can NOT run
> WE or most/any windows apps on an ARM platform under wine.  I am not a
> fan of wine ... the not an emulator thing. The native linux apps work
> pretty well for winlink messaging when using an RPi/Direwolf/UDRC.



Stuart Longland VK4MSL
 

On 05/10/18 08:09, Steve wrote:
Is the real challenge here a Winlink development team which is myopic in
their support for various operating systems?  If W1HKJ can build, test,
and support three operating systems for the FLDigi suite, why can't
they?  In Emcomm situations, where interoperability is the key, that
just doesn't make sense.

It is most difficult to be boxed into a position where one has to tell a
volunteer that they must pay homage to a large company in Redmond,
Washington, in order to use Winlink Express forms.  That would be like
telling hams they all have to buy radios from the same company.
This is just a symptom of a larger problem, people who write software
for legacy operating systems only and don't document how their software
operates.

Really, it should not matter that Winlink Express is Windows-only. It
should not matter that they only support Windows.

The protocol should be open and documented. Sufficient for someone to
come up with an alternate but interoperable system.

Example: consider ECMAScript. Prior to that coming on the scene, there
were several attempts at doing scripting on web pages. Microsoft threw
their hat in the ring with, wait for it, VBScript, but it never took
off. The other way was to embed applets, again mostly using proprietary
extensions.

ActiveX only took off in enterprise circles, with it generally being
accepted as a poor solution elsewhere. Macromedia^WAdobe Flash and Java
were more common ways of filling in where JavaScript couldn't.
JavaScript has largely taken over, because it is open and royalty free.

I've actually considered some ideas for an emergency comms system here:
https://stuartl.longlandclan.id.au/blog/2017/03/26/digital-emergency-comms-ideas/

I've also considered the idea of whether to use a "blockchain" as a way
of indicating the route taken by a message. The idea that the sender
starts the chain (the message is the "genesis"), and each party
forwarding hashes and signs the previous block. That way you have
mathematical proof that a message was passed on via a particular route
and that the message received at the far end is "authentic".

It should be possible for anyone to obtain the relevant public keys,
verify each signature, and reproduce each hash, to prove that a message
was sent by a particular person and took a given route.

There was also scope for encryption in there, ACMA rules allow that for
bonafide emergencies, but I realise this is problematic elsewhere, so
would be a strictly optional feature. You'll have to go to special
effort to enable it.

Many of the ideas considered there would be compatible with the UDRC.
The project though is on the back burner whilst I deal with some more
pressing projects.

Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
...it's backed up on a tape somewhere.

Scott Currie
 

I'm going to regret wading into this, but here I go anyway....

I've been instructing EMCOMM teams on WE for quite some time now. It can be rather challenging to say the least. While the folks in this group are not likely to struggle at all with an RPi or Linux or even UNIX, and can probably compile a kernel blindfolded with one hand tied behind your back, you are not the average EMCOMM operator. Most of the EMCOMM teams I train struggle with zipped files! They really don't want to use anything that ends in X (except maybe a few OSX people). 

Do I like WE? Not really, but it does the job. Would I rather have something more robust that runs on Win, Linux, Unix, OSX, iOS and Android? Absolutely, but it's not going to happen. I can't even tell you how many people who have told me they were going to write something waaay better. It either never happens, or gets only as far as early and ugly beta with no documentation or support. Meanwhile WE plugs along, gets a little better with each revision, and is in continuous support and development. So you need a Windows box, get over it. My portable station is a Win10 Tablet with keyboard that cost me less than $80. It runs WE and Direwolf just fine, and it would happily connect to a DRAW for RF connectivity if one was in WiFi range (or it can use a number of other hardware options).

If you are going to write something waaay better, let me know when it is done, I'll beta test it.
Until then, we're getting by just fine with WE.

-Scott, NS7C

Randy Neals
 


For EmComm oriented clients, there are a few key functions necessary in client software:
-Forms ie: HTML/CSS Forms creation & content-only transport
-Tactical Address Support

Outpost, Pat, Paclink (but not Paclink-Unix) and Winmail Express support tactical addressing.
Only Winlink Express supports Forms.

I'd dearly love to see a client that supports Forms and Tactical addresses that would run on a Raspberry Pi, such as the new DRAWS station.

It has been my experience that nearly every time I fire up my ham radio ThinkPad, that it wants to download an update or do something other than the Winlink message I want to send.



On Thu, Oct 4, 2018 at 2:29 PM, Basil Gunn <basil@...> wrote:

Scott Currie <scott.d.currie@...> writes:

> plinBPQ is not a platform you can run WE on. It can serve as a CMS
> gateway, or even a connection to a TNC/soundcard for WE to use, but
> you would still need to install WE "elsewhere". Getting WE to install
> and run on the Pi architecture is indeed difficult if not
> impossible. Certainly not something I would suggest.

Yes my apologies if anyone thought I was promoting that. You can NOT run
WE or most/any windows apps on an ARM platform under wine.  I am not a
fan of wine ... the not an emulator thing. The native linux apps work
pretty well for winlink messaging when using an RPi/Direwolf/UDRC.

/Basil




Budd Churchward
 

Whatcom county is doing something very interesting to solve these problems and it works very well on a Rpi with a UDRC controller. We are using Fldigi with Flmsg running MT-63 2000L on VHF. Flmsg supports the ICS forms. MT-63 sends very fast with error correction. We also use FSQ. This works for us because all units only need to communicate with the county EOC and they talk to the rest of the state. MT-63 allows you to broadcast the message, which means that all stations copy it at the same time. Each one does not have to make its own connection and download the message separately. BTW Fldigi runs on all platforms, so it works with any computer.
 
At the Red Cross in Bellingham, when we want to send a message with WinLink, we use a Windows laptop which connects it to the same Rpi and UDRC using TCP/IP over our local network. Our regular WinLink operator is not a Linux guy. All we had to do was make a simple change in a menu and everything was the same as what he has always done.
 
Budd WB7FHC
 

Sent: Thursday, October 04, 2018 5:08 PM
Subject: Re: [nw-digital-radio] Linux RMS - headed for digital dustbin?
 
 
For EmComm oriented clients, there are a few key functions necessary in client software:
-Forms ie: HTML/CSS Forms creation & content-only transport
-Tactical Address Support

Outpost, Pat, Paclink (but not Paclink-Unix) and Winmail Express support tactical addressing.
Only Winlink Express supports Forms.

I'd dearly love to see a client that supports Forms and Tactical addresses that would run on a Raspberry Pi, such as the new DRAWS station.

It has been my experience that nearly every time I fire up my ham radio ThinkPad, that it wants to download an update or do something other than the Winlink message I want to send.


 
On Thu, Oct 4, 2018 at 2:29 PM, Basil Gunn <basil@...> wrote:

Scott Currie <scott.d.currie@...> writes:

> plinBPQ is not a platform you can run WE on. It can serve as a CMS
> gateway, or even a connection to a TNC/soundcard for WE to use, but
> you would still need to install WE "elsewhere". Getting WE to install
> and run on the Pi architecture is indeed difficult if not
> impossible. Certainly not something I would suggest.

Yes my apologies if anyone thought I was promoting that. You can NOT run
WE or most/any windows apps on an ARM platform under wine.  I am not a
fan of wine ... the not an emulator thing. The native linux apps work
pretty well for winlink messaging when using an RPi/Direwolf/UDRC.

/Basil



 

 

I looked on the winlink site and the HTML and CSS for existing forms does not appear to be independently downloadable, nor do I see a quick link to the data only transport. 

Open things up and maybe some development will follow. 

On Thu, Oct 4, 2018, 17:08 Randy Neals <randy@...> wrote:

For EmComm oriented clients, there are a few key functions necessary in client software:
-Forms ie: HTML/CSS Forms creation & content-only transport
-Tactical Address Support

Outpost, Pat, Paclink (but not Paclink-Unix) and Winmail Express support tactical addressing.
Only Winlink Express supports Forms.

I'd dearly love to see a client that supports Forms and Tactical addresses that would run on a Raspberry Pi, such as the new DRAWS station.

It has been my experience that nearly every time I fire up my ham radio ThinkPad, that it wants to download an update or do something other than the Winlink message I want to send.



On Thu, Oct 4, 2018 at 2:29 PM, Basil Gunn <basil@...> wrote:

Scott Currie <scott.d.currie@...> writes:

> plinBPQ is not a platform you can run WE on. It can serve as a CMS
> gateway, or even a connection to a TNC/soundcard for WE to use, but
> you would still need to install WE "elsewhere". Getting WE to install
> and run on the Pi architecture is indeed difficult if not
> impossible. Certainly not something I would suggest.

Yes my apologies if anyone thought I was promoting that. You can NOT run
WE or most/any windows apps on an ARM platform under wine.  I am not a
fan of wine ... the not an emulator thing. The native linux apps work
pretty well for winlink messaging when using an RPi/Direwolf/UDRC.

/Basil




Randy Neals
 

I don't disagree John.
But the EmComm leaders have decided that forms save critical bandwidth over the air, and forms must be used.
Regrettably, forms are proprietary in Winlink, so EmComm leaders have locked us into Winlink Express, and Windows in one fell swoop.

-R

On Thu, Oct 4, 2018 at 5:33 PM, John D Hays - K7VE <john@...> wrote:
I looked on the winlink site and the HTML and CSS for existing forms does not appear to be independently downloadable, nor do I see a quick link to the data only transport. 

Open things up and maybe some development will follow. 

On Thu, Oct 4, 2018, 17:08 Randy Neals <randy@...> wrote:

For EmComm oriented clients, there are a few key functions necessary in client software:
-Forms ie: HTML/CSS Forms creation & content-only transport
-Tactical Address Support

Outpost, Pat, Paclink (but not Paclink-Unix) and Winmail Express support tactical addressing.
Only Winlink Express supports Forms.

I'd dearly love to see a client that supports Forms and Tactical addresses that would run on a Raspberry Pi, such as the new DRAWS station.

It has been my experience that nearly every time I fire up my ham radio ThinkPad, that it wants to download an update or do something other than the Winlink message I want to send.



On Thu, Oct 4, 2018 at 2:29 PM, Basil Gunn <basil@...> wrote:

Scott Currie <scott.d.currie@...> writes:

> plinBPQ is not a platform you can run WE on. It can serve as a CMS
> gateway, or even a connection to a TNC/soundcard for WE to use, but
> you would still need to install WE "elsewhere". Getting WE to install
> and run on the Pi architecture is indeed difficult if not
> impossible. Certainly not something I would suggest.

Yes my apologies if anyone thought I was promoting that. You can NOT run
WE or most/any windows apps on an ARM platform under wine.  I am not a
fan of wine ... the not an emulator thing. The native linux apps work
pretty well for winlink messaging when using an RPi/Direwolf/UDRC.

/Basil





Randy Neals
 

Bud, that's an interesting solution - I've not used FL Digi forms capability.
I suppose you could fun FSQ and FLMSG simultaneously.

I'm wondering if the forms capability in FL Digi is compatible with the forms in Winlink Express?

Randy, W3RWN

On Thu, Oct 4, 2018 at 5:27 PM, Budd Churchward <budd@...> wrote:
Whatcom county is doing something very interesting to solve these problems and it works very well on a Rpi with a UDRC controller. We are using Fldigi with Flmsg running MT-63 2000L on VHF. Flmsg supports the ICS forms. MT-63 sends very fast with error correction. We also use FSQ. This works for us because all units only need to communicate with the county EOC and they talk to the rest of the state. MT-63 allows you to broadcast the message, which means that all stations copy it at the same time. Each one does not have to make its own connection and download the message separately. BTW Fldigi runs on all platforms, so it works with any computer.
 
At the Red Cross in Bellingham, when we want to send a message with WinLink, we use a Windows laptop which connects it to the same Rpi and UDRC using TCP/IP over our local network. Our regular WinLink operator is not a Linux guy. All we had to do was make a simple change in a menu and everything was the same as what he has always done.
 
Budd WB7FHC
 
Sent: Thursday, October 04, 2018 5:08 PM
Subject: Re: [nw-digital-radio] Linux RMS - headed for digital dustbin?
 
 
For EmComm oriented clients, there are a few key functions necessary in client software:
-Forms ie: HTML/CSS Forms creation & content-only transport
-Tactical Address Support

Outpost, Pat, Paclink (but not Paclink-Unix) and Winmail Express support tactical addressing.
Only Winlink Express supports Forms.

I'd dearly love to see a client that supports Forms and Tactical addresses that would run on a Raspberry Pi, such as the new DRAWS station.

It has been my experience that nearly every time I fire up my ham radio ThinkPad, that it wants to download an update or do something other than the Winlink message I want to send.


 
On Thu, Oct 4, 2018 at 2:29 PM, Basil Gunn <basil@...> wrote:

Scott Currie <scott.d.currie@...> writes:

> plinBPQ is not a platform you can run WE on. It can serve as a CMS
> gateway, or even a connection to a TNC/soundcard for WE to use, but
> you would still need to install WE "elsewhere". Getting WE to install
> and run on the Pi architecture is indeed difficult if not
> impossible. Certainly not something I would suggest.

Yes my apologies if anyone thought I was promoting that. You can NOT run
WE or most/any windows apps on an ARM platform under wine.  I am not a
fan of wine ... the not an emulator thing. The native linux apps work
pretty well for winlink messaging when using an RPi/Direwolf/UDRC.

/Basil



 


AE7G
 

From the perspective of EMCOMM leaders, forms are NOT proprietary (for the most part). 

 

The forms are part of the Incident Command System structure, and they dovetail well with all sorts of planning documents and principles as part of the overall ICS structure.

 

The government provides ICS forms on line, they are available to copy and integrate into any structure. 

 

From: main@nw-digital-radio.groups.io <main@nw-digital-radio.groups.io> On Behalf Of Randy Neals
Sent: Thursday, October 4, 2018 6:11 PM
To: main@nw-digital-radio.groups.io
Subject: Re: [nw-digital-radio] Linux RMS - headed for digital dustbin?

 

I don't disagree John.
But the EmComm leaders have decided that forms save critical bandwidth over the air, and forms must be used.
Regrettably, forms are proprietary in Winlink, so EmComm leaders have locked us into Winlink Express, and Windows in one fell swoop.

-R

 

On Thu, Oct 4, 2018 at 5:33 PM, John D Hays - K7VE <john@...> wrote:

I looked on the winlink site and the HTML and CSS for existing forms does not appear to be independently downloadable, nor do I see a quick link to the data only transport. 

 

Open things up and maybe some development will follow. 

 

On Thu, Oct 4, 2018, 17:08 Randy Neals <randy@...> wrote:

 

For EmComm oriented clients, there are a few key functions necessary in client software:
-Forms ie: HTML/CSS Forms creation & content-only transport

-Tactical Address Support

Outpost, Pat, Paclink (but not Paclink-Unix) and Winmail Express support tactical addressing.
Only Winlink Express supports Forms.

I'd dearly love to see a client that supports Forms and Tactical addresses that would run on a Raspberry Pi, such as the new DRAWS station.

It has been my experience that nearly every time I fire up my ham radio ThinkPad, that it wants to download an update or do something other than the Winlink message I want to send.

 

On Thu, Oct 4, 2018 at 2:29 PM, Basil Gunn <basil@...> wrote:


Scott Currie <scott.d.currie@...> writes:

> plinBPQ is not a platform you can run WE on. It can serve as a CMS
> gateway, or even a connection to a TNC/soundcard for WE to use, but
> you would still need to install WE "elsewhere". Getting WE to install
> and run on the Pi architecture is indeed difficult if not
> impossible. Certainly not something I would suggest.

Yes my apologies if anyone thought I was promoting that. You can NOT run
WE or most/any windows apps on an ARM platform under wine.  I am not a
fan of wine ... the not an emulator thing. The native linux apps work
pretty well for winlink messaging when using an RPi/Direwolf/UDRC.

/Basil


 

 

sancudo
 

What Scott is saying rings true with me bc I've taught ham classes locally and KISS is a big four letter word when it comes to my students trying get hardware to work with simple software. Most folks barely know how to access Windows, much less Linux or ARM based software. 
I really like WE. Probably the best it has been since it's inception in WinXP or earlier days. I was on forty miles from the eye of Hurricane Harvey last year... hunkered down in courthouse with high velocity winds blowing things sideways outside. And yet I was able to send messages thru my radio and pactor modem using WE on a Win7 desktop. The WE software worked flawlessly in send and receive mode. And even a non-ham could have operated the station. KISS. It worked for me.

On Thu, Oct 4, 2018, 7:07 PM Scott Currie <scott.d.currie@...> wrote:
I'm going to regret wading into this, but here I go anyway....

I've been instructing EMCOMM teams on WE for quite some time now. It can be rather challenging to say the least. While the folks in this group are not likely to struggle at all with an RPi or Linux or even UNIX, and can probably compile a kernel blindfolded with one hand tied behind your back, you are not the average EMCOMM operator. Most of the EMCOMM teams I train struggle with zipped files! They really don't want to use anything that ends in X (except maybe a few OSX people). 

Do I like WE? Not really, but it does the job. Would I rather have something more robust that runs on Win, Linux, Unix, OSX, iOS and Android? Absolutely, but it's not going to happen. I can't even tell you how many people who have told me they were going to write something waaay better. It either never happens, or gets only as far as early and ugly beta with no documentation or support. Meanwhile WE plugs along, gets a little better with each revision, and is in continuous support and development. So you need a Windows box, get over it. My portable station is a Win10 Tablet with keyboard that cost me less than $80. It runs WE and Direwolf just fine, and it would happily connect to a DRAW for RF connectivity if one was in WiFi range (or it can use a number of other hardware options).

If you are going to write something waaay better, let me know when it is done, I'll beta test it.
Until then, we're getting by just fine with WE.

-Scott, NS7C

AE7G
 

As one of the hordes of EMCOMM trainees, I agree wholeheartedly with this.

 

I have been in the EMCOMM and public service world for a long time.  People have been pushing Linux based ideas at me for 20 years.  I almost always have to rely on them to finish the installation and configuration because I can’t do it myself. 

 

Even if it gets running fine, something happens to my computer and things have to be reinstalled.  Now the person who helped me is no longer available and I no longer have the application. 

 

On the other hand, give me Windows and instructions on how to do it, and I can pretty much figure it out on my own.    If it goes, I can reconstruct what I did before and get it going.

 

 

From: main@nw-digital-radio.groups.io <main@nw-digital-radio.groups.io> On Behalf Of Scott Currie
Sent: Thursday, October 4, 2018 5:07 PM
To: main@nw-digital-radio.groups.io
Subject: Re: [nw-digital-radio] Linux RMS - headed for digital dustbin?

 

I'm going to regret wading into this, but here I go anyway....

I've been instructing EMCOMM teams on WE for quite some time now. It can be rather challenging to say the least. While the folks in this group are not likely to struggle at all with an RPi or Linux or even UNIX, and can probably compile a kernel blindfolded with one hand tied behind your back, you are not the average EMCOMM operator. Most of the EMCOMM teams I train struggle with zipped files! They really don't want to use anything that ends in X (except maybe a few OSX people). 

Do I like WE? Not really, but it does the job. Would I rather have something more robust that runs on Win, Linux, Unix, OSX, iOS and Android? Absolutely, but it's not going to happen. I can't even tell you how many people who have told me they were going to write something waaay better. It either never happens, or gets only as far as early and ugly beta with no documentation or support. Meanwhile WE plugs along, gets a little better with each revision, and is in continuous support and development. So you need a Windows box, get over it. My portable station is a Win10 Tablet with keyboard that cost me less than $80. It runs WE and Direwolf just fine, and it would happily connect to a DRAW for RF connectivity if one was in WiFi range (or it can use a number of other hardware options).

If you are going to write something waaay better, let me know when it is done, I'll beta test it.
Until then, we're getting by just fine with WE.

-Scott, NS7C

Andy KI6SEP
 

In Santa Clara County, CA we use a program that works with Outpost for forms. It is called PacFORMS.

A form needs a one time conversion to html. From then on, an operator merely needs to open the form in a browser, fill in the information, and click Submit to Outpost. The field contents alone are placed in a plain text message.

The operator needs merely to enter the destination station and transmit.

Upon receipt, Outpost detects the message is a PacFORM and calls the reverse read routine which then opens the same Form in a browser with all the fields filled in.

Yes, this requires that PacForms be installed at both the sending and receiving stations. The number of bytes transmitted is minimal as only the field contents are sent (with an identifier for each) and no html is transmitted. 

We have converted a number of ICS forms and even some WEBEOC forms.

Separately, Outpost has native support for the ICS-213 without even needing a browser.

Here's more information
https://www.scc-ares-races.org/pfpublic/pacforms.html

Andy

-------- Original message --------
From: AE7G <gthornton@...>
Date: 10/4/18 21:59 (GMT-05:00)
To: main@nw-digital-radio.groups.io
Subject: Re: [nw-digital-radio] Linux RMS - headed for digital dustbin?

From the perspective of EMCOMM leaders, forms are NOT proprietary (for the most part). 

 

The forms are part of the Incident Command System structure, and they dovetail well with all sorts of planning documents and principles as part of the overall ICS structure.

 

The government provides ICS forms on line, they are available to copy and integrate into any structure. 

 

From: main@nw-digital-radio.groups.io <main@nw-digital-radio.groups.io> On Behalf Of Randy Neals
Sent: Thursday, October 4, 2018 6:11 PM
To: main@nw-digital-radio.groups.io
Subject: Re: [nw-digital-radio] Linux RMS - headed for digital dustbin?

 

I don't disagree John.
But the EmComm leaders have decided that forms save critical bandwidth over the air, and forms must be used.
Regrettably, forms are proprietary in Winlink, so EmComm leaders have locked us into Winlink Express, and Windows in one fell swoop.

-R

 

On Thu, Oct 4, 2018 at 5:33 PM, John D Hays - K7VE <john@...> wrote:

I looked on the winlink site and the HTML and CSS for existing forms does not appear to be independently downloadable, nor do I see a quick link to the data only transport. 

 

Open things up and maybe some development will follow. 

 

On Thu, Oct 4, 2018, 17:08 Randy Neals <randy@...> wrote:

 

For EmComm oriented clients, there are a few key functions necessary in client software:
-Forms ie: HTML/CSS Forms creation & content-only transport

-Tactical Address Support

Outpost, Pat, Paclink (but not Paclink-Unix) and Winmail Express support tactical addressing.
Only Winlink Express supports Forms.

I'd dearly love to see a client that supports Forms and Tactical addresses that would run on a Raspberry Pi, such as the new DRAWS station.

It has been my experience that nearly every time I fire up my ham radio ThinkPad, that it wants to download an update or do something other than the Winlink message I want to send.

 

On Thu, Oct 4, 2018 at 2:29 PM, Basil Gunn <basil@...> wrote:


Scott Currie <scott.d.currie@...> writes:

> plinBPQ is not a platform you can run WE on. It can serve as a CMS
> gateway, or even a connection to a TNC/soundcard for WE to use, but
> you would still need to install WE "elsewhere". Getting WE to install
> and run on the Pi architecture is indeed difficult if not
> impossible. Certainly not something I would suggest.

Yes my apologies if anyone thought I was promoting that. You can NOT run
WE or most/any windows apps on an ARM platform under wine.  I am not a
fan of wine ... the not an emulator thing. The native linux apps work
pretty well for winlink messaging when using an RPi/Direwolf/UDRC.

/Basil


 

 

Tony <w7efs@...>
 

http://winlink.org/content/how_manually_update_standard_templates_version_10690 "Step 2" has the link I believe you're searching for.

On 10/04/2018 05:33 PM, John D Hays - K7VE wrote:
I looked on the winlink site and the HTML and CSS for existing forms does not appear to be independently downloadable, nor do I see a quick link to the data only transport. 

Open things up and maybe some development will follow. 

On Thu, Oct 4, 2018, 17:08 Randy Neals <randy@...> wrote:

For EmComm oriented clients, there are a few key functions necessary in client software:
-Forms ie: HTML/CSS Forms creation & content-only transport
-Tactical Address Support

Outpost, Pat, Paclink (but not Paclink-Unix) and Winmail Express support tactical addressing.
Only Winlink Express supports Forms.

I'd dearly love to see a client that supports Forms and Tactical addresses that would run on a Raspberry Pi, such as the new DRAWS station.

It has been my experience that nearly every time I fire up my ham radio ThinkPad, that it wants to download an update or do something other than the Winlink message I want to send.



On Thu, Oct 4, 2018 at 2:29 PM, Basil Gunn <basil@...> wrote:

Scott Currie <scott.d.currie@...> writes:

> plinBPQ is not a platform you can run WE on. It can serve as a CMS
> gateway, or even a connection to a TNC/soundcard for WE to use, but
> you would still need to install WE "elsewhere". Getting WE to install
> and run on the Pi architecture is indeed difficult if not
> impossible. Certainly not something I would suggest.

Yes my apologies if anyone thought I was promoting that. You can NOT run
WE or most/any windows apps on an ARM platform under wine.  I am not a
fan of wine ... the not an emulator thing. The native linux apps work
pretty well for winlink messaging when using an RPi/Direwolf/UDRC.

/Basil