Date
21 - 32 of 32
Linux RMS - headed for digital dustbin?
|
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
From: Randy Neals
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:
|
|||||||||
|
|
|||||||||
|
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:
|
|||||||||
|
|
|||||||||
|
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
|
|||||||||
|
|
|||||||||
|
Stuart Longland VK4MSL
On 05/10/18 08:09, Steve wrote:
Is the real challenge here a Winlink development team which is myopic inThis 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.
|
|||||||||
|
|
|||||||||
|
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
|
|||||||||
|
|
|||||||||
|
Steve
Wine has not been ported to the ARM architecture, so NO Windoze app will work on a RPi.
toggle quoted messageShow quoted text
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@gmail.com> writes:plinBPQ is not a platform you can run WE on. It can serve as a CMSWE or most/any windows apps on an ARM platform under wine. I am not a
|
|||||||||
|
|
|||||||||
|
Scott Currie <scott.d.currie@gmail.com> writes:
plinBPQ is not a platform you can run WE on. It can serve as a CMSYes 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
|
|||||||||
|
|
|||||||||
|
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
|
|||||||||
|
|
|||||||||
|
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:
|
|||||||||
|
|
|||||||||
|
John G8BPQ
Randy,
toggle quoted messageShow quoted text
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:
|
|||||||||
|
|
|||||||||
|
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
|
|||||||||
|
|
|||||||||
|
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 __._,_.___
.
__,_._,___
|
|||||||||
|
|