Date   

Re: NBEMS application version scheme

Dave
 

Current distribution versions of the NBEMS suite of programs can be found at http://www.w1hkj.com/files/

Current development versions of the NBEMS suite of can be found at http://www.w1hkj.com/alpha/

Drill down to the folder named for the application of interest.

Program Distribution Version Development Version
flaa 1.0.2 1.0.2.02
flamp 2.2.04 2.2.04.13
flcluster 1.0.4 1.0.4.02
fldigi 4.1.04 4.1.04.10
fllog 1.2.6 ---
flmsg 4.0.8 4.0.8.04
flrig 1.3.44 1.3.44.07
flnet 7.3.2 7.3.2.07
flwkey 1.2.3 1.2.3.05
flwrap 1.2.5 ---
linsim 2.0.3 ---
comptext 1.0.1 ---
comptty 1.0.1 ---

73,  David, W1HKJ


NBEMS application version scheme

Dave
 

At the request of 3rd party NBEMS developers I am changing the version numbering scheme for all NBEMS applications including fldigi, flarq, flrig, fllog etc.

The current triad numbering is still in effect: primary . secondary . tertiary, ie: fldigi-4.1.04

The change only applies to development cycle numbering: primary . secondary . tertiary . quaternary.  In the past the tertiary . quarternary would have bumped the tertiary number to the next release value.  In the future the tertiary will remain at the current release value.

fldigi-4.1.04  - current release

fldigi-4.1.04.28 - 28th development cycle release post 4.1.04.

73, David, W1HKJ


Re: 8PSK on 2 meters

Dave
 

Unless the transfer is 1:1 then use flmsg with ARQ.

Dave

On 5/15/19 6:29 PM, Ron via Groups.Io wrote:
Hi Klaus,

We also have an NBMES net on 2 meters and use either 8psk1000F or 8psk1200f.  Even though I have full scale at my location there still is a slight crackling noise and I don't get 100% copy. With that speed your reception has to be pretty close to full quieting. A few things to get better copy. I usually turn off digital squelch and unsquelch my radio. You get more noise text but better weak signal reception. In the PSK modem setting make sure everyone turns on the Pilot tone. If it's a repeater turn on the Pre-Signal Tone in the ID RsID setting to send a tone before your text. Make sure that your PTT delay is set. On my Signalink I have the DLY set to 12 o'clock. Of course audio setting, both transmit and receive has to be perfect. Not too low and not too high to distort the audio.

My personal opinion is if a large file is being sent with high speed then Flamp is better than Flmsg because you can ask for missing blocks instead of getting errors on the Flmsg and asking for the whole thing to be resent.

73, Ron NY3J

On 5/15/19 7:09 PM, khberkner@... wrote:
We run aa small fldigi/flmsg practice net on 2 meters.  Our workhorse mode has been MT63-2000L, but we have been exploring 8PSK and have been amazed by the increased speed (recognizing we give up the  error correction of MT63).

Here's my problem:  I used to have no problem decoding 8PSK 1200F until a few weeks ago.  Now I can't decode 1200F, although usually 1000F still works (most of the time).   None of the others on the net have this problem, and they can readily decode my 1200F transmissions.

I am running fldigi 4.1.03 and flmsg 4.0.8 on Windows 10.

Sometimes I get only gibberish, other times I see the text in the yellow screen, but no "wrap" at the beginning and hence no coupling to flmsg and my browser.

This has me baffled, and any thoughts would be appreciated.

Klaus K6KHB



Re: 8PSK on 2 meters

 

Hi Klaus,

We also have an NBMES net on 2 meters and use either 8psk1000F or 8psk1200f.  Even though I have full scale at my location there still is a slight crackling noise and I don't get 100% copy. With that speed your reception has to be pretty close to full quieting. A few things to get better copy. I usually turn off digital squelch and unsquelch my radio. You get more noise text but better weak signal reception. In the PSK modem setting make sure everyone turns on the Pilot tone. If it's a repeater turn on the Pre-Signal Tone in the ID RsID setting to send a tone before your text. Make sure that your PTT delay is set. On my Signalink I have the DLY set to 12 o'clock. Of course audio setting, both transmit and receive has to be perfect. Not too low and not too high to distort the audio.

My personal opinion is if a large file is being sent with high speed then Flamp is better than Flmsg because you can ask for missing blocks instead of getting errors on the Flmsg and asking for the whole thing to be resent.

73, Ron NY3J

On 5/15/19 7:09 PM, khberkner@... wrote:
We run aa small fldigi/flmsg practice net on 2 meters.  Our workhorse mode has been MT63-2000L, but we have been exploring 8PSK and have been amazed by the increased speed (recognizing we give up the  error correction of MT63).

Here's my problem:  I used to have no problem decoding 8PSK 1200F until a few weeks ago.  Now I can't decode 1200F, although usually 1000F still works (most of the time).   None of the others on the net have this problem, and they can readily decode my 1200F transmissions.

I am running fldigi 4.1.03 and flmsg 4.0.8 on Windows 10.

Sometimes I get only gibberish, other times I see the text in the yellow screen, but no "wrap" at the beginning and hence no coupling to flmsg and my browser.

This has me baffled, and any thoughts would be appreciated.

Klaus K6KHB


8PSK on 2 meters

khberkner@...
 

We run aa small fldigi/flmsg practice net on 2 meters.  Our workhorse mode has been MT63-2000L, but we have been exploring 8PSK and have been amazed by the increased speed (recognizing we give up the  error correction of MT63).

Here's my problem:  I used to have no problem decoding 8PSK 1200F until a few weeks ago.  Now I can't decode 1200F, although usually 1000F still works (most of the time).   None of the others on the net have this problem, and they can readily decode my 1200F transmissions.

I am running fldigi 4.1.03 and flmsg 4.0.8 on Windows 10.

Sometimes I get only gibberish, other times I see the text in the yellow screen, but no "wrap" at the beginning and hence no coupling to flmsg and my browser.

This has me baffled, and any thoughts would be appreciated.

Klaus K6KHB


Re: Modem Macro not working

 

WT,

I had the same thing happen with 4.1.03. I was able to fix it by entering <WAIT:00.1> between the MODEM and the TX command. Dave fixed it in 4.1.04.02. The latest Alpha is 4.1.04.07 so give that a try.

73, Ron NY3J

On 5/10/19 11:42 PM, W. T. Jones wrote:
Good Evening All,

I usually put a modem command in my macros so that I switch back to Thor22 as NCS for typing.
Last Thursday night I noticed that I was not switching modes after sending in Flamp. So I put a quick macro together to test it.

This is the macro...
<MODEM:THOR22>
<!DIGI>
<TX>

de <MYCALL>
-----
Fldigi was in 8PSK1200F modem. The macro should have changed the modem to Thor 22. The <!DIGI> reported 8PSK1200F and Fldigi's status line at the bottom reported 8PSK1200F as well. Tested with other modems and the same results. The MACRO command in the modem did not change the modem.

If the modem command is changed to inline execution it works.

System: Ubuntu 18.04LTS (latest patches)
Also tested on Windows 10 - same results.
Downloaded the 4.01.04.01 Alpha and tested on Ubuntu with the same results.

Anyone else seeing this behavior?

Regards,

WT
Real heroes do not wear capes. They wear dog tags, turnout gear, and badges!


Modem Macro not working

W. T. Jones <wn3lif@...>
 

Good Evening All,

I usually put a modem command in my macros so that I switch back to Thor22 as NCS for typing.
Last Thursday night I noticed that I was not switching modes after sending in Flamp. So I put a quick macro together to test it.

This is the macro...
<MODEM:THOR22>
<!DIGI>
<TX>

de <MYCALL>
-----
Fldigi was in 8PSK1200F modem. The macro should have changed the modem to Thor 22. The <!DIGI> reported 8PSK1200F and Fldigi's status line at the bottom reported 8PSK1200F as well. Tested with other modems and the same results. The MACRO command in the modem did not change the modem.

If the modem command is changed to inline execution it works.

System: Ubuntu 18.04LTS (latest patches)
Also tested on Windows 10 - same results.
Downloaded the 4.01.04.01 Alpha and tested on Ubuntu with the same results.

Anyone else seeing this behavior?

Regards,

WT
Real heroes do not wear capes. They wear dog tags, turnout gear, and badges!


Re: Raspberry PI 7 Touchscreen and Resolution at 800x600 #flmsg

Dave
 

Download the source archive, fldigi-4.1.03.tar.gz.  You cannot just reduce the size of the main dialog without seriously effecting the final product.  Some of the contained controls (widgets in Unix speak) are size constrained by design.  The raster image controls for feldhell and wefax are in that category.

What steps have you take to reduce the vertical height of the main dialog?

Try reduce the vertical size of the waterfall to the minimum of 100 (or less by code change)

Dave


Re: Raspberry PI 7 Touchscreen and Resolution at 800x600 #flmsg

w7lpn.ham@...
 

Unsubscribe


On Tue, May 7, 2019, 12:46 Aaron Jones <aaron@...> wrote:
Hello,

I researched this a bit but couldn't find a thread specifically to use of the Raspberry PI3 and the Raspberry PI 7" touchscreen.  The max you can run the screen at is 800x600 resolution which is pretty small.  I have been able to resize the FLDIG interface such that everything fits by using fewer macro rows and smaller fonts.  However, when I run FLMSG I cannot get the full screen to fit so if I try to use ARQ when you open  the ARQ inteface on FLMSG it goes below the screen, moving the window as far above the title bar as you can move with the mouse allows a partial view.  Is there a way to allow screens to be further sizeable vertically below current limits?


Re: Raspberry PI 7 Touchscreen and Resolution at 800x600 #flmsg

Ronald Pfeiffer
 

If the user interface was developed using fluid is the file available to
users for editing?

On May 7, 2019 at 4:14 PM Brian <@VE3IBW> wrote:


I have the same setup as you and here is what I found works:
1. Change the geometry when you startup FLxxx programs. Most FLxxx
programs support a -g switch. See
http://www.w1hkj.com/FldigiHelp/command_line_switches_page.html for the
command line switch. I set mine to 750x480 (e.g., fldigi *-g 750x400)*
2. Use the alt key and the mouse to move the window around. This is a
Linux thing, not an FLxxx thing. See this link for an explanation:
https://forums.linuxmint.com/viewtopic.php?t=264172

regards,
Brian
VE3IBW


On Tue, May 7, 2019 at 2:46 PM Aaron Jones <aaron@...> wrote:

Hello,

I researched this a bit but couldn't find a thread specifically to use of
the Raspberry PI3 and the Raspberry PI 7" touchscreen. The max you can run
the screen at is 800x600 resolution which is pretty small. I have been
able to resize the FLDIG interface such that everything fits by using fewer
macro rows and smaller fonts. However, when I run FLMSG I cannot get the
full screen to fit so if I try to use ARQ when you open the ARQ inteface
on FLMSG it goes below the screen, moving the window as far above the title
bar as you can move with the mouse allows a partial view. Is there a way
to allow screens to be further sizeable vertically below current limits?





Re: Raspberry PI 7 Touchscreen and Resolution at 800x600 #flmsg

Brian
 

The other thing I do is "maximize" the Fldigi main window.  This seems to help resize many of the UI controls so that it can mostly fit within the 7" screen 800x480.  I do still have to use the alt-mouse trick to move the FLdigi window up so that it covers the Raspbian main menu bar across the top of the screen.  If I am running FLdigi, I really don't need access to the Raspbian top bar all that often.  When I do, I just alt-mouse to nudge the maximized window down.

Aaron, you are correct, now that I recall, the geometry switch setting only helped somewhat.  Other apps, like wsjtx, seem better at resizing to fit smaller form factors than FLdigi.

regards, 
Brian
VE3IBW

On Tue, May 7, 2019 at 6:07 PM Aaron Jones <aaron@...> wrote:

All,


thanks for the feedback.  I find that no matter how i set my command line switch I can't get below the minimum geometry of 800x600. 


HOWEVER - the alt key + mouse click to move the window helps a ton, I did not know that linux feature. 


Thanks again.


Aaron

AG7GK

https://www.ag7gk.org


On 5/7/2019 1:14 PM, Brian wrote:
I have the same setup as you and here is what I found works:
1. Change the geometry when you startup FLxxx programs.  Most FLxxx programs support a -g switch.  See http://www.w1hkj.com/FldigiHelp/command_line_switches_page.html for the command line switch.  I set mine to 750x480 (e.g., fldigi -g 750x400)
2. Use the alt key and the mouse to move the window around.  This is a Linux thing, not an FLxxx thing.  See this link for an explanation: https://forums.linuxmint.com/viewtopic.php?t=264172

regards,
Brian
VE3IBW


On Tue, May 7, 2019 at 2:46 PM Aaron Jones <aaron@...> wrote:
Hello,

I researched this a bit but couldn't find a thread specifically to use of the Raspberry PI3 and the Raspberry PI 7" touchscreen.  The max you can run the screen at is 800x600 resolution which is pretty small.  I have been able to resize the FLDIG interface such that everything fits by using fewer macro rows and smaller fonts.  However, when I run FLMSG I cannot get the full screen to fit so if I try to use ARQ when you open  the ARQ inteface on FLMSG it goes below the screen, moving the window as far above the title bar as you can move with the mouse allows a partial view.  Is there a way to allow screens to be further sizeable vertically below current limits?


Re: Raspberry PI 7 Touchscreen and Resolution at 800x600 #flmsg

Aaron Jones
 

All,


thanks for the feedback.  I find that no matter how i set my command line switch I can't get below the minimum geometry of 800x600. 


HOWEVER - the alt key + mouse click to move the window helps a ton, I did not know that linux feature. 


Thanks again.


Aaron

AG7GK

https://www.ag7gk.org


On 5/7/2019 1:14 PM, Brian wrote:
I have the same setup as you and here is what I found works:
1. Change the geometry when you startup FLxxx programs.  Most FLxxx programs support a -g switch.  See http://www.w1hkj.com/FldigiHelp/command_line_switches_page.html for the command line switch.  I set mine to 750x480 (e.g., fldigi -g 750x400)
2. Use the alt key and the mouse to move the window around.  This is a Linux thing, not an FLxxx thing.  See this link for an explanation: https://forums.linuxmint.com/viewtopic.php?t=264172

regards,
Brian
VE3IBW


On Tue, May 7, 2019 at 2:46 PM Aaron Jones <aaron@...> wrote:
Hello,

I researched this a bit but couldn't find a thread specifically to use of the Raspberry PI3 and the Raspberry PI 7" touchscreen.  The max you can run the screen at is 800x600 resolution which is pretty small.  I have been able to resize the FLDIG interface such that everything fits by using fewer macro rows and smaller fonts.  However, when I run FLMSG I cannot get the full screen to fit so if I try to use ARQ when you open  the ARQ inteface on FLMSG it goes below the screen, moving the window as far above the title bar as you can move with the mouse allows a partial view.  Is there a way to allow screens to be further sizeable vertically below current limits?


Re: Raspberry PI 7 Touchscreen and Resolution at 800x600 #flmsg

Brian
 

I have the same setup as you and here is what I found works:
1. Change the geometry when you startup FLxxx programs.  Most FLxxx programs support a -g switch.  See http://www.w1hkj.com/FldigiHelp/command_line_switches_page.html for the command line switch.  I set mine to 750x480 (e.g., fldigi -g 750x400)
2. Use the alt key and the mouse to move the window around.  This is a Linux thing, not an FLxxx thing.  See this link for an explanation: https://forums.linuxmint.com/viewtopic.php?t=264172

regards,
Brian
VE3IBW


On Tue, May 7, 2019 at 2:46 PM Aaron Jones <aaron@...> wrote:
Hello,

I researched this a bit but couldn't find a thread specifically to use of the Raspberry PI3 and the Raspberry PI 7" touchscreen.  The max you can run the screen at is 800x600 resolution which is pretty small.  I have been able to resize the FLDIG interface such that everything fits by using fewer macro rows and smaller fonts.  However, when I run FLMSG I cannot get the full screen to fit so if I try to use ARQ when you open  the ARQ inteface on FLMSG it goes below the screen, moving the window as far above the title bar as you can move with the mouse allows a partial view.  Is there a way to allow screens to be further sizeable vertically below current limits?


Re: Raspberry PI 7 Touchscreen and Resolution at 800x600 #flmsg

J T
 

You can commpress desktop space down so as to get more on the screen by setting the resolution in the config.txt file to a resolution of 1280 x 760 which will fill the screen - a type of “pixel-doubling.” Get your reading glasses out though - you’ll need’em.

Jeff - KG7HDZ

On May 7, 2019, at 11:46 AM, Aaron Jones <aaron@...> wrote:

Hello,

I researched this a bit but couldn't find a thread specifically to use of the Raspberry PI3 and the Raspberry PI 7" touchscreen.  The max you can run the screen at is 800x600 resolution which is pretty small.  I have been able to resize the FLDIG interface such that everything fits by using fewer macro rows and smaller fonts.  However, when I run FLMSG I cannot get the full screen to fit so if I try to use ARQ when you open  the ARQ inteface on FLMSG it goes below the screen, moving the window as far above the title bar as you can move with the mouse allows a partial view.  Is there a way to allow screens to be further sizeable vertically below current limits?

<FLMSG_SIZING_RPI.jpg><FULLSCREENFLDIGIRPI.jpg>


Re: Raspberry PI 7 Touchscreen and Resolution at 800x600 #flmsg

Dave
 

You would need to modify the flmsg source to reduce the vertical space needed by the user interface.

David


Raspberry PI 7 Touchscreen and Resolution at 800x600 #flmsg

Aaron Jones
 

Hello,

I researched this a bit but couldn't find a thread specifically to use of the Raspberry PI3 and the Raspberry PI 7" touchscreen.  The max you can run the screen at is 800x600 resolution which is pretty small.  I have been able to resize the FLDIG interface such that everything fits by using fewer macro rows and smaller fonts.  However, when I run FLMSG I cannot get the full screen to fit so if I try to use ARQ when you open  the ARQ inteface on FLMSG it goes below the screen, moving the window as far above the title bar as you can move with the mouse allows a partial view.  Is there a way to allow screens to be further sizeable vertically below current limits?


flrig 1.3.44 posted

Dave
 

Version 1.3.44 * Maintenance release

?? IC mode type
?????? * add missing generic get_modetype

Effects the sideband sense of modes like CW/CW-R, RTTY/RTTY-R for a number of Icom transceivers including the Icom 7300.

73, David, W1HKJ


Shortwave Radiogram: Olivia 64-2000 15 dB under music

kd9xb
 

Shortwave Radiogram this weekend is in MFSK32, MFSK64 (with eight images), and Olivia 64-2000. To make it more interesting, the Olivia 64-2000 is mixed with, and 15 dB under, music.

You can decode the show yourself from this audio ...

https://soundcloud.com/voaradiogram/shortwave-radiogram-program-98

It was transmitted UTC Saturday at 0230-0300 UTC on 9265 kHz from WINB in Red Lion, Pennsylvania, and received at the SDR of KPH, the Maritime Radio Historical Society, at Point Reyes, California.

The Olivia 64-2000 starts at 23:12 into the audio file.

Due to the peculiarities of WINB's audio, the RSIDs probably won't work. You'll have to change the modes manually.

It's also possible that at least one MFSK64 image preamble will be garbled, resulting in no image. A solution that might work is to start the recording just when the preamble starts.

This weekend, you can still receive and decode the program "live" UTC Sunday at 0800-0830 UTC on 5850 and 7730 kHz and 2330-2400 UTC on 7780 kHz, all frequencies from WRMI Florida.

Kim
KD9XB
Shortwave Radiogram
https://twitter.com/swradiogram


Re: FT4 for NBEMS net call / other suitable digital-net modes 4 HF

Doug K7KY
 

Aaron...  I appreciate your summary of ORCA DIGITAL NET.  ORCA was founded to teach and practice digital traffic-handling with NBEMS software.  We quickly discovered that digital nets were more difficult to run than Phone & CW because doubles can be frequent and they scramble both signals. Fortunately, Amateur Directed Net protocols are a good fit for digital nets too.  When all transmissions go through NCS, it's possible to keep order and conduct business smoothly and rapidly.  An orderly net is essential to passing traffic efficiently.  Directed net structure and PC file-system familiarity are also important for digital traffic Operators.

We use MFSK for net business and most traffic handling when condx permit.  Next on ORCA is THOR.  For terrible condx, we use OLIVIA, as do most digital nets. We've experimented with many of the modes on FLDIGI's menu.  We usually experiment with mode during the weekly FLAMP exercise and run a Mode Shoot-Out every month or so.  We often fill an experimental mode with a faster MFSK mode.  Although MFSK-128 is faster and wider than THOR-100, we can often fill stations who've not CONFIRMED THOR-100 with MFSK-128.  Solar Minimum is providing lots of opportunity to explore digital mode characteristics. When this solar-phase is over, those who stick with the digital operations will be outstanding digital Ops. 73 Doug K7KY


Re: FT4 for NBEMS net call ?

Bruce Bohannon WA1YZN
 

I think it's time to stop this thread and start a new thread.


Bruce WA1YZN

On 5/2/2019 11:52 AM, Aaron Jones wrote:
Doug,

I've really enjoyed monitoring and participating in the ORCA net, it's a real experience in effective NET control, station engagement, and exercising of a LOT of software and RF capabilities.   Recently I've been running a local VHF net for folks not ready for HF bigtime.  In reference to modes, as the subject of this thread is about FT4, I was hoping to expand on it a bit in general around successful and RELIABLE modes in your many years of experience.  Anecdotally in my experience on our VHF net - MFSK(32,64,128) always work - we've experimented with multi-PSK modes, MT63 modes, and FSQ, but always come back to MFSK (32,64, and 128).  Without going into painful detail and understanding some modes are just too slow for a reliable VHF connection (Olivia, Thor, slower PSK modes etc)  is it just my imagination or is MFSK really one of the more stable and reliable modes across different band conditions?

Granted there is "no one size fits all" in reference to a digital mode selection, but, when I reviewed digital mode comparison on the W1HKJ site: http://www.w1hkj.com/FldigiHelp-3.21/Modes/Compare.htm  MFSK kind of sites in the sweetspot for bandwidth, speed, efficiency, and copy %.   Couple that with the ability to send Images, and several bandwidth options, FEC, and again  my perceived reliability I kind of just keep going back to MFSK as my "old reliable" during my experimentation.

Do you have any anecdotal / experience to provide on mode selections and preferences?

Does the overall group have input on their preferred modes?

Again - i'm sure the comment really is "it depends"...

Aaron

AG7GK


On 5/1/2019 9:01 AM, Doug K7KY wrote:
Andy... We've been using MFSK-32 for net business @ ORCA DIGITAL NET for over 6yrs on 80m.  It works very well for us.  Ck-ins average from 15 - 21; our top was 27.  We take earlies 15min b4 net. While mode selection is crutial to net flow, so is content. ORCA is a directed net; we ck-in regular members with their CALL only.  New stations check in with CALL, NAME, QTH.  Monitoring stations use, CALL IN&OUT. Instruction for ck-in are in the Preamble and @ the website. Stations also ck-in by VidID on the WF.  I can work multiple ck-ins simultaneously by logging the VidIDs while working a station on 1500.  ORCA is a digital-traffic training and practice net; we don't need traffic listing @ ck-in.

Some new digital Ops like to populate their macros with their Bio, FLDIGI version#, License grade,  etc, all irrelevant to NCS @ ck-in.  Establishing a brief ck-in process is as important as choosing the best mode.  Monitor our net, if you can.  I've not seen an easier digital ck-in process.  ORCA is a complex and busy net; we don't have time to waste.  Nets usually run 1-1.5hr and we're busy throughout the net.  Members have busy lives and don't want to sit idle while extraneous test is printing.

Dave developed VidID for us years ago and we use it every net. VidID is also useful when we send Ops off freq to pass traffic. They easily notify me they want to recheck with VidID.  I can complete what I'm doing and bring them in.  Overall it saves time and work for NCS and makes the net more efficient.  These individual savings are small, but add up over the net to a significant increase in net efficiency.  It's not unusual for me to make 80 discreet transmissions in an hour as we practice handling  NBEMS traffic.  Our website and net Preamble sets out net protocols clearly.  Members know net routines and we usually get a lot done every net, even in solar minimum.  Last night, we ran a Mode Shoot-Out between DominoEX & MFSK.  I run with TxID & RxID active.  Members only run RxID unless they're changing modes for their practice traffic.  We don't waste time pre-announcing mode changes.  We're training to pass traffic in emergency conditions and we want to be very familiar with all the tools in the NBEMS suite.

Dave also made all 4 macro rows visible-at-once for us.  I use two sets of macros every net.  A button on each instantly call the other set.  I don't need all 96 buttons every net, but all 96 are occupied and I often rewrite them mid-net.  Hats off to Dave for outstanding software and his kind and patient technicial support.

Doug K7KY
http://orcadigitalnet.com