Date   
Re: Narrow Band Emergency Messages

Charles Hargrove
 

The various PSK modes may have issues going through an FM repeater because of reactance tuning. However, the 8PSK modes were made for
repeaters, especially when the 500hz pilot tone is activated. The
pilot tone keeps the signal within 1 or 2 hz so that it is stable.
Some repeaters will exhibit a notch in the waterfall when there is
a tone used for linking repeaters. Our main repeater system in NYC
has this as I see a deep notch at 2200 hz in the waterfall, so I
make sure that a 1500 hz centered signal does not reach 2200 hz on
the high end. The 500 hz pilot tone is above the PL squelch range
of 67-254 hz. And as was said previously, NO acoustic coupling.
A stable audio chain between the radio and computer is needed. If
you don't have a souncard interface dongle, then use regular audio
cables for mic and speaker and turn on the VOX with a short delay.

On 10/13/2018 8:44 PM, Frank Olaughlin wrote:
Steve,
Yes, you are spot on. Acoustic coupling and 8PSK modes are a dead end street. We have had excellent success with them using Signalink or other external interfaces.
Frank WQ1O
--
Charles J. Hargrove - N2NOV
NYC-ARECS/RACES Citywide Radio Officer/Skywarn Coord.

NYC-ARECS/RACES Nets 449.025/123.0 PL
ARnewsline Broadcast Mon. @ 8:00PM
NYC-ARECS Weekly Net Mon. @ 8:30PM
http://www.nyc-arecs.org

NY-NBEMS Net Saturdays @ 10AM & USeast-NBEMS Net Wednesdays @ 7PM
on 7.036 Mhz USB (alt 3.536)/1500 hz waterfall spot; MFSK-16 or 32

"Information is the oxygen of the modern age. It seeps through the walls topped
by barbed wire, it wafts across the electrified borders." - Ronald Reagan

"The more corrupt the state, the more it legislates." - Tacitus

"Molann an obair an fear" - Irish Saying
(The work praises the man.)

"No matter how big and powerful government gets, and the many services it
provides, it can never take the place of volunteers." - Ronald Reagan

Re: Narrow Band Emergency Messages

Frank Olaughlin
 

Steve,

Yes, you are spot on. Acoustic coupling and 8PSK modes are a dead end street. We have had excellent success with them using Signalink or other external interfaces.

Frank WQ1O

Re: Narrow Band Emergency Messages

Steve Bellner
 

Just a comment...

We here in NW Ohio have been using MT 63 through the repeaters for training. We just started playing with 8PSK and note that stations using audio coupling have a very limited success rate at copying the PSK modes. Those using soundcard interfaces with 8PSK seem to have more success.

Steve, W8TER


On 10/13/2018 12:16 PM, Frank Olaughlin wrote:
Jack,

Thanks for your thoughts on this and info about your operations. My apologies in my labeling......it should have read 8PSK500F/125F. The 125F is an old test mode for us. 8PSK500F is the repeater standard. We have had no issues with it on reliability. One big thing we found for higher 8PSK modes (not non-8PSK) is to use 1800 and not 1500 on sending. People have argued with me on his, but it doesn't matter. That's what we've found having sent many thousands of messages during real operations. 1800 works best, especially using 1000F and 1200F.( you have to use the pilot tone on 1200F...it's a huge difference!). The big issue with repeaters is that their quality of audio can vary from one to the other. MT632KL has always been reliable. It's just so slow. it's painful. This is especially true using Flamp. QPSK500 was a huge step up (despite no RSID...no biggie if your group uses a standard). We still keep it as a backup. I have to say that adopting 8PSK500F was major. A normal message runs about 12-14 seconds.
I'm always concerned about relying on repeaters too much. Our best and most reliable mode is 8PSK1000F and 8PSK1200F(need good signal) simplex. A message is usually less than 8 seconds. We have designated 5-7 stations with real good height and coverage. 8PSK1000F is so fast that they all can relay that message between them and cover about 100% of our area. This method, of course, is dependent on the size of your operations area. Many areas of the county are huge compared to mine, so this would be rendered impractical. Where there's a will, there's a way. Especially with the flexibility of the NBEMS programs. Jack, do you use one main repeater and have a backup? That is pretty much what is done here, although I like simplex where I can get away with it.

Thanks for your comments

Frank WQ1O
Cape Cod and Islands ARES DEC

Re: Narrow Band Emergency Messages

Richard E Neese
 

Where can I find the fldigi nbems macros you all use if any ?

 

Sent from Mail for Windows 10

 

Re: Narrow Band Emergency Messages

Frank Olaughlin
 

Jack,

Thanks for your thoughts on this and info about your operations. My apologies in my labeling......it should have read 8PSK500F/125F. The 125F is an old test mode for us. 8PSK500F is the repeater standard. We have had no issues with it on reliability. One big thing we found for higher 8PSK modes (not non-8PSK) is to use 1800 and not 1500 on sending. People have argued with me on his, but it doesn't matter. That's what we've found having sent many thousands of messages during real operations. 1800 works best, especially using 1000F and 1200F.( you have to use the pilot tone on 1200F...it's a huge difference!). The big issue with repeaters is that their quality of audio can vary from one to the other. MT632KL has always been reliable. It's just so slow. it's painful. This is especially true using Flamp. QPSK500 was a huge step up (despite no RSID...no biggie if your group uses a standard). We still keep it as a backup. I have to say that adopting 8PSK500F was major. A normal message runs about 12-14 seconds.
I'm always concerned about relying on repeaters too much. Our best and most reliable mode is 8PSK1000F and 8PSK1200F(need good signal) simplex. A message is usually less than 8 seconds. We have designated 5-7 stations with real good height and coverage. 8PSK1000F is so fast that they all can relay that message between them and cover about 100% of our area. This method, of course, is dependent on the size of your operations area. Many areas of the county are huge compared to mine, so this would be rendered impractical. Where there's a will, there's a way. Especially with the flexibility of the NBEMS programs. Jack, do you use one main repeater and have a backup? That is pretty much what is done here, although I like simplex where I can get away with it.

Thanks for your comments

Frank WQ1O
Cape Cod and Islands ARES DEC

Re: Narrow Band Emergency Messages

Jack Dellinger
 

Frank. WQ1O
Curious as to why you went to 8PSK125F after testing QPSK500.?
We did some testing after reading your article. ALL testing is on local 2 meter repeater with wide coverage area.  
Using your article as test message we found that:
MT632kL sent message in 2:30 minutes  copy by 5 stations no errors
QPSK500 sent message in 35 seconds  copy by 5 stations no errors
8PSK125F sent message in 1:18 minutes 2 of 5 stations not good copy.
We have used MT632KL for over 5 years for sending message (IS-213) traffic. Traffic is copied by multiple stations with near 100 percent copy rate.
We have tired the 8PSK modes several times over the last year.  There always seems to be stations that don't get a good copy and have to have resends.
So if QPSK500  is much faster and more reliable, why use the 8PSK modes???
MT632KL has been so reliable for us and usually any traffic we need to send fits within the repeater 3 minute time out window, so we are reluctant to change.
the QPSK500 mode looks very good to us so far.  Hope to do a lot more testing, including using FLAMP.   Like the 8PSK modes BUT reliability of good receive just doesn't seem to be there.

Jack KC3JD
York AREA RACES SKYWARN (YARS)
PA. SouthCentral Task Force (SCTF) Amateur Radio Work Group (ARWG)


On Tue, Sep 25, 2018 at 9:27 PM Frank Olaughlin <wq1o.frank@...> wrote:

Cape Cod and Islands uses NBEMS for our county MACC facility. We use it to communicate with other EOCs and the also the state. We have been using and testing NBEMS for some time. We started off with MT632KL for VHF/UHF. We started using it because it seemed to be a sort of standard. It worked fine, but after testing other modes in Fldigi, we realized there was no sense in continuing to use it since it was so slow. We quickly switched to QPSK500 and never looked back. In recent years, we use 8PSK125F/500F on one of our repeaters and 8PSK1000F/1200F on simplex. We have used 8PSK1200F successfully during very intense coastal storms last Winter. Winds were around 100mph or so and both AT&T and Comcast were basically offline. The multicast capability makes it a great system. Our incident management team was impressed by both the ICS forms in Flmsg and sending files with Flamp. They needed a codeplug for two Motorola CDM-1550s in different areas. Using Flamp, we sent it to both in one shot using 8PSK. This really impressed them.

I think Meshnet systems do have potential, but I agree with the poster who was concerned by increasing use of infrastructure. We have to be careful not to abandon tested communications options just because something new comes along. That doesn't mean we shouldn't use new ideas as they come along. We just have to watch that we don't become the very same infrastructure dependent system that agencies use us to back up. I think the people advancing MESH tech realize this and are keeping system redundant and as interoperable as they can. It has a great future, as long as we remember not to put all our eggs in any one basket.

We also use Winlink, but to a lesser degree. It will likely see more use here with ARDOP coming along for HF. Pactor 4 is too expensive for me and most others.

What I really like about NBEMS is that I can use an old laptop with Linux, cheap 10 dollar Kenwood mobile bought at a fleamarket, cheap J-pole, and still have good speed digital operations with Flmsg and Flamp. Got to hand it to Dave for that……This stuff works.

Re: Automating FLDIGI From Another Application

WA7SKG <wa7skg@...>
 

I have had good results with several <$10 USB sound dongles and fldigi. For some local ARES training/demonstrations, I have used a scanner and plugged the external speaker jack into a cheap USB sound dongle and run fldigi on the computer to display the traffic between stations.

I have also used a couple Baofengs set to VOX through USB sound dongles for training and demonstrations. Also works well with SSTV. For those, I use the cable sold for APRS (Google Baofeng APRS TRRS cable) through a TRRS> dual 3.5mm adapter > USB sound dongle. TRRS cables are used with smartphones with APRSDroid and various SSTV apps.

I find using the USB dongle easier than the built in sound card in laptops to avoid conflicts with the various computer sounds.

Michael WA7SKG


kk5it@... wrote on 09/29/2018 05:32 PM:

Any recommendations for sound card interfaces that may work well for anyone of the hams on our course that would like to also receive the files, but may not have an interface like a SignaLink?
_._,_._,_

Re: Automating FLDIGI From Another Application

kk5it@...
 

Thanks Perry. That makes sense.

Re: Automating FLDIGI From Another Application

k4pwo <k4pwo@...>
 

If the radio has a USB port on the rear panel it probably has internal sound device as well as virtual serial ports for CAT and PTT.

Perry K4PWO 



Sent from my Sprint Samsung Galaxy S7 edge.

-------- Original message --------
From: kk5it@...
Date: 9/29/18 9:43 PM (GMT-06:00)
To: nbems@groups.io
Subject: Re: [nbems] Automating FLDIGI From Another Application

Thanks Andrew. Trying to figure out the best and also the quickest way to get FLDIGI into use in our area and being able to use for public service events. Are there any specifics that will tell me whether a radio is going to need an interface so I can help people determine that? I have an older Alinco I use with a SignaLink myself that I used for an EchoLink RF-IS gateway and have used for NBEMS on ARES nets in South Florida when I lived there several years ago.

Re: Automating FLDIGI From Another Application

kk5it@...
 

Thanks Andrew. Trying to figure out the best and also the quickest way to get FLDIGI into use in our area and being able to use for public service events. Are there any specifics that will tell me whether a radio is going to need an interface so I can help people determine that? I have an older Alinco I use with a SignaLink myself that I used for an EchoLink RF-IS gateway and have used for NBEMS on ARES nets in South Florida when I lived there several years ago.

Re: Automating FLDIGI From Another Application

Andrew OBrien <k3ukandy@...>
 

Regarding the question about sound card to Interfaces , many modern transceivers have audio codecs that no longer necessitate an external sound card interface . For those that have older radios , the Microham Microkeyer devices work well . Also look for Rigblaster 
Andy K3UK


On Sep 29, 2018, at 8:32 PM, kk5it@... wrote:

Thanks for the quick answer Bob. Not sure I would have time to do it for this event next weekend with my work schedule this week, but good to know it can be done so perhaps I can work on testing it and have it ready by next year. Any recommendations for sound card interfaces that may work well for anyone of the hams on our course that would like to also receive the files, but may not have an interface like a SignaLink?

Re: Automating FLDIGI From Another Application

kk5it@...
 

Thanks for the quick answer Bob. Not sure I would have time to do it for this event next weekend with my work schedule this week, but good to know it can be done so perhaps I can work on testing it and have it ready by next year. Any recommendations for sound card interfaces that may work well for anyone of the hams on our course that would like to also receive the files, but may not have an interface like a SignaLink?

Re: Automating FLDIGI From Another Application

Dave
 

Excellent answer Bob.  Hope your having safe travels in VK land.

Dave

On 09/29/2018 04:49 PM, Bob Cameron wrote:

Possibly fldigi-shell?

For example launch (or leave running) fldigi then have it run a numbered macro using fldigi-shell. I do this regularly from a Linux shell script, but it should also work from Windows (perl).

Example;

fldigi-shell -c "main.run_macro 44"

Runs the macro from macros.mdf (the default) that is specified by /$ 44

In your case the macro would be written to TX the relevant CSV file, plus any other setup info like modem to use, operating freq etc. Only issue would be if more than one CSV is generated per fldigi TX session. A shell command within the macro could be used to handle/queue for this case. There would be no need to kill the fldigi instance.

flamp under fldigi can also be used to automate sending (say) the contents of a directory. I use to use this to send jpg images and compressed gpx files as I travel. In your case date stamped CSV's that a shell script ages (removes old) would work.

Cheers Bob VK2YQA


On 30/09/18 06:49, kk5it@... wrote:
Please forgive me if this has been answered elsewhere, but I did not see it. Can FLDIGI (once configured of course), be automated by specifying something like the path to the executable and one or more arguments for sending a csv file?

The scenario is for an event we support tracking 100 runners. The net control station has a laptop they do tracking on in Excel. The race team built a macro that generates a web page from the data and uploads it to the race website so crew and support staff can track runners via internet. Where we are there on the course, there is no cellular/internet service so I was wondering if I could setup something and build it into the same macro they use as an extra step that could call FLDIGI, send the file, and close FLDIGI.

Otherwise, I am guessing I could just update their Excel macro to also output a csv file and then build a macro in FLDIGI using <FILE:> and then let net control to pick the csv outputted by Excel to send?
_._,_._,_



Re: Automating FLDIGI From Another Application

Bob Cameron
 

Possibly fldigi-shell?

For example launch (or leave running) fldigi then have it run a numbered macro using fldigi-shell. I do this regularly from a Linux shell script, but it should also work from Windows (perl).

Example;

fldigi-shell -c "main.run_macro 44"

Runs the macro from macros.mdf (the default) that is specified by /$ 44

In your case the macro would be written to TX the relevant CSV file, plus any other setup info like modem to use, operating freq etc. Only issue would be if more than one CSV is generated per fldigi TX session. A shell command within the macro could be used to handle/queue for this case. There would be no need to kill the fldigi instance.

flamp under fldigi can also be used to automate sending (say) the contents of a directory. I use to use this to send jpg images and compressed gpx files as I travel. In your case date stamped CSV's that a shell script ages (removes old) would work.

Cheers Bob VK2YQA


On 30/09/18 06:49, kk5it@... wrote:
Please forgive me if this has been answered elsewhere, but I did not see it. Can FLDIGI (once configured of course), be automated by specifying something like the path to the executable and one or more arguments for sending a csv file?

The scenario is for an event we support tracking 100 runners. The net control station has a laptop they do tracking on in Excel. The race team built a macro that generates a web page from the data and uploads it to the race website so crew and support staff can track runners via internet. Where we are there on the course, there is no cellular/internet service so I was wondering if I could setup something and build it into the same macro they use as an extra step that could call FLDIGI, send the file, and close FLDIGI.

Otherwise, I am guessing I could just update their Excel macro to also output a csv file and then build a macro in FLDIGI using <FILE:> and then let net control to pick the csv outputted by Excel to send?
_._,_._,_



Automating FLDIGI From Another Application

kk5it@...
 

Please forgive me if this has been answered elsewhere, but I did not see it. Can FLDIGI (once configured of course), be automated by specifying something like the path to the executable and one or more arguments for sending a csv file?

The scenario is for an event we support tracking 100 runners. The net control station has a laptop they do tracking on in Excel. The race team built a macro that generates a web page from the data and uploads it to the race website so crew and support staff can track runners via internet. Where we are there on the course, there is no cellular/internet service so I was wondering if I could setup something and build it into the same macro they use as an extra step that could call FLDIGI, send the file, and close FLDIGI.

Otherwise, I am guessing I could just update their Excel macro to also output a csv file and then build a macro in FLDIGI using <FILE:> and then let net control to pick the csv outputted by Excel to send?

Re: Inserting message in raw screen log file

Wayne Santos
 

Aren't you a midshipman on the Indefatigable?

Wayne
N1CKM


On Fri, Sep 28, 2018, 9:51 AM Horatio Hornblower <guido@...> wrote:

Folks

I would like to insert a message in the raw screen log every time I formally log a contact.  I have searched and can't find a macro to do this, or any other way to do this.

Why would I want to do this?  Well, I have gotten a number of NIL back from people and I would like to see what went wrong with the contact.  Currently I have to grep all the logs for their call, then open the relevant log and search for their call.  A simple script to search for the logging of the contact and print the relevant lines for the contact would make things a lot easier.

Does anyone know how to insert a string into the raw screen log, or perhaps request that a macro be added to do it?

Thanks,

Bill

--
Bill Turini
KA4GAV

Inserting message in raw screen log file

Horatio Hornblower <guido@...>
 

Folks

I would like to insert a message in the raw screen log every time I formally log a contact.  I have searched and can't find a macro to do this, or any other way to do this.

Why would I want to do this?  Well, I have gotten a number of NIL back from people and I would like to see what went wrong with the contact.  Currently I have to grep all the logs for their call, then open the relevant log and search for their call.  A simple script to search for the logging of the contact and print the relevant lines for the contact would make things a lot easier.

Does anyone know how to insert a string into the raw screen log, or perhaps request that a macro be added to do it?

Thanks,

Bill

--
Bill Turini
KA4GAV

Re: Using FLDIGI with Vertex VX-1700

Daniel Miranda
 

Status update on the project:

1. Following KI6ZHD's suggestion, we retrieved the original base station licenses, pictures of the certificates stamps on the radios, and the applicable legislation (as far as I could find). My friend forwarded the documents to a telecommunications engineer to get a professional opinion. He replied that the licenses cover the intended use, so we're good to go.
2. My friend did not have time to test W1HKJ's XML for rig control yet. We were busy with the station license research.
3. I've been studying to get a HAM license since I first had an "email qso" with W1HKJ. I felt very welcome, and it would be nice to be a registered member of the community.
4. I may have found a bug with FLDIGI's "test signals". I neither see the noise on the waterfall, nor the noise is recorded when I use "TX generate". If anyone can reproduce this please let me know, so that I can file a proper bug report. I'm using version 4.0.18 compiled from the source tarball on Ubuntu 18.04 with the options --enable-optimizations=native --with-flxmlrpc --with-pulseaudio. I'm using linsim in the meantime.

If all goes well, I am looking forward to the first short-range transmissions in October, and maybe a first remote deployment by December.

Best,
Daniel



Em seg, 24 de set de 2018 às 11:59, Daniel Miranda <dumper.dam@...> escreveu:

Thank you so much Dave! I was digging into the documentation for FT-857 and VX-1700 as I received your e-mail!

I have contacted my friend, he will get back to me as soon as he has the time to test this.

Best,
Daniel


Em seg, 24 de set de 2018 às 09:09, Dave <w1hkj@...> escreveu:
Daniel,

I have created a rigcat transceiver control definition file, VX1700.xml, for your friend to test.  The file is attached.  I have also attached a Yaesu pdf document that contains the CAT command and H/W setup required to use CAT with the VX1700.  He is probably already aware of the need to set internal jumpers for CAT / GPS use.  Both use the same rear panel DATA port.

On Linux:
  • copy the vx1700.xml file to the directory $HOME/.fldigi/rigs/
  • start fldigi and configure the transceiver control to use RIGCAT
  • The control parameters will be read from the vx1700.xml file, but can be modified if necessary
    I did not find any requirements for setting either DTR or RTS in the Yaesu CAT document.
  • Make sure that the "Use RigCAT" control is selected
  • Open the fldigi events dialog (Help / Events) and set the recording level to DEBUG.
  • and then press the "Initialize" button.

The serial port initialization and serial i/o should be recorded in the event log.  That log is also written to the file

$HOME/.fldigi/status_log.txt

If necessary I could log on to your friends computer using Team Viewer.

73, David, W1HKJ
http://www.w1hkj.com/FldigiSupport.html


Re: Narrow Band Emergency Messages

Frank Olaughlin
 

Cape Cod and Islands uses NBEMS for our county MACC facility. We use it to communicate with other EOCs and the also the state. We have been using and testing NBEMS for some time. We started off with MT632KL for VHF/UHF. We started using it because it seemed to be a sort of standard. It worked fine, but after testing other modes in Fldigi, we realized there was no sense in continuing to use it since it was so slow. We quickly switched to QPSK500 and never looked back. In recent years, we use 8PSK125F/500F on one of our repeaters and 8PSK1000F/1200F on simplex. We have used 8PSK1200F successfully during very intense coastal storms last Winter. Winds were around 100mph or so and both AT&T and Comcast were basically offline. The multicast capability makes it a great system. Our incident management team was impressed by both the ICS forms in Flmsg and sending files with Flamp. They needed a codeplug for two Motorola CDM-1550s in different areas. Using Flamp, we sent it to both in one shot using 8PSK. This really impressed them.

I think Meshnet systems do have potential, but I agree with the poster who was concerned by increasing use of infrastructure. We have to be careful not to abandon tested communications options just because something new comes along. That doesn't mean we shouldn't use new ideas as they come along. We just have to watch that we don't become the very same infrastructure dependent system that agencies use us to back up. I think the people advancing MESH tech realize this and are keeping system redundant and as interoperable as they can. It has a great future, as long as we remember not to put all our eggs in any one basket.

We also use Winlink, but to a lesser degree. It will likely see more use here with ARDOP coming along for HF. Pactor 4 is too expensive for me and most others.

What I really like about NBEMS is that I can use an old laptop with Linux, cheap 10 dollar Kenwood mobile bought at a fleamarket, cheap J-pole, and still have good speed digital operations with Flmsg and Flamp. Got to hand it to Dave for that……This stuff works.

Re: Using FLDIGI with Vertex VX-1700

Daniel Miranda
 

Thank you so much Dave! I was digging into the documentation for FT-857 and VX-1700 as I received your e-mail!

I have contacted my friend, he will get back to me as soon as he has the time to test this.

Best,
Daniel


Em seg, 24 de set de 2018 às 09:09, Dave <w1hkj@...> escreveu:

Daniel,

I have created a rigcat transceiver control definition file, VX1700.xml, for your friend to test.  The file is attached.  I have also attached a Yaesu pdf document that contains the CAT command and H/W setup required to use CAT with the VX1700.  He is probably already aware of the need to set internal jumpers for CAT / GPS use.  Both use the same rear panel DATA port.

On Linux:
  • copy the vx1700.xml file to the directory $HOME/.fldigi/rigs/
  • start fldigi and configure the transceiver control to use RIGCAT
  • The control parameters will be read from the vx1700.xml file, but can be modified if necessary
    I did not find any requirements for setting either DTR or RTS in the Yaesu CAT document.
  • Make sure that the "Use RigCAT" control is selected
  • Open the fldigi events dialog (Help / Events) and set the recording level to DEBUG.
  • and then press the "Initialize" button.

The serial port initialization and serial i/o should be recorded in the event log.  That log is also written to the file

$HOME/.fldigi/status_log.txt

If necessary I could log on to your friends computer using Team Viewer.

73, David, W1HKJ
http://www.w1hkj.com/FldigiSupport.html