Date   

Re: Linux RMS - headed for digital dustbin?

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





Re: Linux RMS - headed for digital dustbin?

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


Re: Linux RMS - headed for digital dustbin?

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.


Re: Linux RMS - headed for digital dustbin?

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.




Re: Linux RMS - headed for digital dustbin?

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.


Re: Linux RMS - headed for digital dustbin?

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


Re: [udrc] [nw-digital-radio] Linux RMS - headed for digital dustbin?

Basil Gunn
 

Scott Currie <@ns7c> writes:

None of these options support the forms function of Winlink Express. I
realize there are other ways to achieve this, but that train has
left. The vast majority of Winlink users are using WE and its forms
function. You will not be fully compatible.
Yep. If you just want messaging then the options I mentioned will work
if you need to use Winlink Express features then go with Windows.
You could use your rasperry Pi running Direwolf in AGWPE or TCP/IP mode
as a remote TNC and run WE on your Windows machine.

You can get WE running on Linux:
https://winlink.org/content/installing_express_linux
Yes you could run WE under wine.

/Basil


Re: Linux RMS - headed for digital dustbin?

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 


Re: [udrc] [nw-digital-radio] Linux RMS - headed for digital dustbin?

Scott Currie
 

None of these options support the forms function of Winlink Express. I realize there are other ways to achieve this, but that train has left. The vast majority of Winlink users are using WE and its forms function. You will not be fully compatible. 

You can get WE running on Linux:
https://winlink.org/content/installing_express_linux

-Scott, NS7C


Re: [udrc] [nw-digital-radio] Linux RMS - headed for digital dustbin?

Basil Gunn
 

I've been looking for an alternative platform to run Winlink Express
as a client on.
For most linux platforms:

paclink-unix
https://github.com/nwdigitalradio/paclink-unix

pat
http://getpat.io/

pigate
http://www.pigate.net/

linbpq

You have choices.

Full disclosure, I'm one of the maintainers of paclink-unix. If you are
using an UDRC it sets up with a couple of scripts.

/Basil n7nix


Re: [udrc] Linux RMS - headed for digital dustbin?

Basil Gunn
 

It appears that LinuxRMS may stop working in the near future when Winlink
CMS stops supporting legacy mode.
Linux RMS Gateway will be supported and will continue to work.
/Basil n7nix

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


Re: Linux RMS - headed for digital dustbin?

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


Re: Linux RMS - headed for digital dustbin?

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

.

__,_._,___


Re: Linux RMS - headed for digital dustbin?

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


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

.

__,_._,___


Re: DRAWS

 

This block Diagram might help. DRAWS is based on the UDRC-II which has been shipping for 2 years.


Re: DRAWS

 

Nothing is being 'hidden', this is a new product. What exists is available. 


On Wed, Sep 26, 2018, 12:56 WW3N <squeeze.box@...> wrote:
Gwen,
Did you ever get a functional description document, youtube, powerpoint, smoke signals  on Draws from anyone?   Oct QST or the schematic posted to groups.io  doesn’t do it for me.. Maybe there is a West Coast secret club keeping the East Coast folks in the dark.. Sorry in advance for being so thick….

Dan ww3n


Re: DRAWS

WW3N <squeeze.box@...>
 

Gwen,
Did you ever get a functional description document, youtube, powerpoint, smoke signals  on Draws from anyone?   Oct QST or the schematic posted to groups.io  doesn’t do it for me.. Maybe there is a West Coast secret club keeping the East Coast folks in the dark.. Sorry in advance for being so thick….

Dan ww3n


Re: DRAWS

 

NW Digital Radio has both a 1 year warranty and a 30 day money-back guarantee on all of it’s products.

Bryan K7UDR


Re: DRAWS

 

Frankly, that is one person's experience/opinion.  As I stated earlier, my experience with WSJT-X on the Raspberry Pi, with the CODEC used in the DRAWS, is that FT-8 runs fine.   This also seems to be the experience of those in this thread. https://groups.io/g/ft8call/topic/26219896#533

Two points --


"What technical support is provided for DRAWS?

NW Digital Radio supports the DRAWS HAT hardware and its driver software.  All other applications are provided on an ‘as is’ basis, with support for configuration and operation of those applications provided by the authors and user community for those applications.  NW Digital Radio’s DRAWS HAT driver and configuration is Open Source Software and is free for amateur radio use."

  • Secondly, NW Digital Radio has a generous Warranty 


On Wed, Sep 26, 2018 at 10:21 AM <kc7pmu@...> wrote:

[Edited Message Follows]

In light of the article in QST, Oct 2018, "The WSJT-X Appliance" ( page 44) that states the Raspberry Pi does not have sufficient performance to run the FT8 and FT8Call protocols, have you test results on prototypes that would contradict this article?



--


John D. Hays
Edmonds, WA
K7VE