Date   

Reposted from linuxham

w1hkj <w1hkj@...>
 

Dear Linux-Ham, I finally found out to whom we owe a *BIG Thank You* for
all this wonderful code and all their hard work.

Please join me in giving the Team a big round of applause. Send them a
thank you note and tell them how you use and appreciate their programs:

KH6TY/4 Skip Teller is the motivator, driver, and salesman for EMCpup.
We all know Skip for his innovation in creating the venerable DigiPan
for PSK31. Skip has innovated the development of PSK63 and several
hardware devices to promote the digital revolution.

W1HKJ Dave Freese is the principle programmer, guru, and industrious
creator of EMCpup with Fldigi and Flarq. Dave is also supporting gmfsk.
Dave recently created vbdigi for NBEMS on Windows - an especially
arduous task! Thanks for sticking with it Dave.

M0GLD Stelios Bounanos - sound card interface and pthreads expert - two
of the most difficult programming concepts to master.

WA5ZNU Leigh Lkotz - our XML parsing guru.

forgive me if I have missed anyone.
------------------------
IMHO: Ham Radio is in a time of tremendous change, adaptation, and
evolution. We have finally turned the corner from rigs that you repair
yourself to the rigs you can enhance yourself; from rigs you build out
of parts, to rigs you build out of functional blocks; from rigs that are
self contained trophy's of bent aluminum, to rigs that beat with an
invisible software heart.

The team who have given us all this wonderful code is our link to the
new era of Software Defined Ham Radio.
------------------------
Thank you Skip, Dave, Stelios, Leigh and others who have so graciously
given us pleasure and excitement by sharing your software engineering
skills.


Ken N9VV
-- What a fantastic time to be in Ham Radio!


The rest of the team(s)

w1hkj <w1hkj@...>
 

Here is the current list of programmer, support, and testing teams.  They put their computers and radios at risk by running alpha level programs - they enjoy the process, get to help determine the design, and just want to give back to the world-wide amateur radio community.  A hearty round of applause to all of these folks.  There is no significance to the ordering, it's just the way that the email program built the list.

fldigi team

Bob Christenson, WU9Q
Skip Fleming, NT1G - site moderator
Dave Cooper, VE3IXI - site moderator
David Munn, VK4BDJ
David Karipides, AC7JN
David Bastress, K3GAO
Diane Bruce, VA3DB - FreeBSD fldigi port maintainer
Ed Stout, W3NR - site moderator - the new Linux user's best friend
Gary Meyn, K1YAN
Jason Turning, N6WBL
Jim Haynes, W6JVE
Joe Barr, K1GPL
Joe Veldhuis, N8FQ - contributor to modem code
Leigh Klotz, WA5ZNU - xml code development
Michael Heim, KD0AR
Mike Phipps, KD8DKT
Phil Moore, KD4O
Rick Kunath, K9AO - Linux systems administrator with all the right answers
Skip Teller, KH6TY
Stelios Bounanos, M0GLD - expert Linux programmer / administrator
Victor Alger, K4XTT
Walter Fey, DL8FCL
Walter Giovanni, CX7BF - the RTTY guru
Mike Haynes, N4ZNV
Bill Evans, WD4FNY
Don Walters, W9DKI
Brian Kassel, K7RE
Thomas Beierlein, DL1JBE
Ken Hopper, N9VV
Steve Conklin, AI4QR - Red Hat fldigi RPM maintainer
Hamish Moffatt, VK3SB - Ubuntu gmfsk maintainer, contributed Domino-EX code

Kachina team

Don Jackson, AE5K - Kachina guru
Tom Mandell, W3FRG - principal Kachina tester on Windows
Jim Haynes, W6JVE - the idea man who loaned a Kachina to W1HKJ for over a year

NBEMS / vbdigi team

Skip Teller, KH6TY - co-developer of EMCpup / vbdigi / flarq
David Bastress, K3GAO
Lynn De Hart, KB3FN
Roger Beever, G6CKR

There were countless others who reported problems, requested changes or suggested improvements.  I apologize if I have missed a contributor.

73, Dave, W1HKJ


vbdigi 1.2.0

"ag7cpete" <ag7cpete@...>
 

Hi folks,

Just loaded vbdigi 1.2.0
With the mouse over the INVERT check box, the popup for the old SCALE
checkbox still comes up.

Trivial, but thought I'd mention it.

Pete AG7C


Re: vbdigi 1.2.0

w1hkj <w1hkj@...>
 

ag7cpete wrote:

Hi folks,

Just loaded vbdigi 1.2.0
With the mouse over the INVERT check box, the popup for the old SCALE
checkbox still comes up.

Trivial, but thought I'd mention it.

Pete AG7C

Good catch.  I will fix.

Dave, W1HKJ


NBEMS

"w7oze" <w7oze@...>
 

Hello Dave, Skip,

1. Have you considered the use of compression on files, etc. to be transmitted, thus
possibly cutting transmission times by one half?

2. Currently, when stations are disconnected, the displayed data on the receiving
flarq screen disappears. You are probably saving the info in a file.

Can you continue to save the data in a file, leave the data displayed in the window,
and have the ability to high-light selected data, right-click on the high-lighted
data, and choose to send the data to a printer. Likewise, the ability to right-click
the received data screen and choose to clear the screen.

Would make life easier for operators .... thinking out loud. :-) 73


NBEMS questions

w1hkj <w1hkj@...>
 

Hello Dave, Skip,

1. Have you considered the use of compression on files, etc. to be transmitted, thus
possibly cutting transmission times by one half?

Simple answer: it would not result in a reduction in transfer time

Long answer: Please read the ARQ specification. All data transmitted within the block must be valid ARQ characters. These are identical to base64 encoding characters. When you compress a file you produce binary data which is 8 bit, not base64. The compressed file would then have to be base64 encoded which has the effect of un-doing the compression.

2. Currently, when stations are disconnected, the displayed data on the receiving
flarq screen disappears. You are probably saving the info in a file.

flarq is a file transfer protocol, and nothing more than that and received data is always saved to a file if the ARQ transfer is successful.

Can you continue to save the data in a file, leave the data displayed in the window,
and have the ability to high-light selected data, right-click on the high-lighted
data, and choose to send the data to a printer. Likewise, the ability to right-click
the received data screen and choose to clear the screen.

The "clear" button does that.

Every incoming file is name iaw with the sending stations file descriptor. Incoming text, binary, and image files are always located in:
c:&#92;NBEMS&#92;ARQrecv

incoming emails are located in
c:&#92;NBEMS&#92;Mail&#92;ARQin

The purpose of displaying data on the flarq rx window is solely to give the operator a sense of what is happening. It may or may not represent what is finally put into the file. When sending a binary or image file the rx window will appear to contain random noise as you will be viewing the base64 data stream. The program will convert the base64 data back into its original format.

Windows has some excellent editors with print capability. flarq does not need to duplicate such a fine facility.

Would make life easier for operators .... thinking out loud. :-) 73

Might give the programmer a nervous breakdown :>(

Sorry for so many negative answers.

73, Dave, W1HKJ


Re: NBEMS questions

arthurwolfman@...
 

PLEASE TAKE ME OFF YOUR MAILING LIST AS i DO NOT USE YOUR PROGRAM AND TELL ANYBODY ELSE NOT TO MAIL ME ABOUT YOUR PROGRAM.
 
THANKS
Arthur
 

-------------- Original message --------------
From: w1hkj

Hello Dave, Skip,

1. Have you considered the use of compression on files, etc. to be
transmitted, thus
possibly cutting transmission times by one half?

Simple answer: it would not result in a reduction in transfer time

Long answer: Please read the ARQ specification. All data transmitted
within the block must be valid ARQ characters. These are identical to
base64 encoding characters. When you compress a file you produce binary
data which is 8 bit, not base64. The compressed file would then have to
be base64 encoded which has the effect of un-doing the compression.

2. Currently, when stations are disconnected, the displayed data on the
receiving
flarq screen disappears. You are probably saving the info in a file.

flarq is a file transfer protocol, and nothing more than that and
received data is always saved to a file if the ARQ transfer is successful.

Can you continue to save the data in a file, leave the data displayed in
the window,
and have the ability to high-light selected data, right-click on the
high-lighted
data, and choose to send the data to a printer. Likewise, the ability to
right-click
the received data screen and choose to clear the screen.

The "clear" button does that.

Every incoming file is name iaw with the sending stations file
descriptor. Incoming text, binary, and image files are always located in:
c:\NBEMS\ARQrecv

incoming emails are located in
c:\NBEMS\Mail\ARQin

The purpose of displaying data on the flarq rx window is solely to give
the operator a sense of what is happening. It may or may not represent
what is finally put into the file. When sending a binary or image file
the rx window will appear to contain random noise as you will be viewing
the base64 data stream. The program will convert the base64 data back
into its original format.

Windows has some excellent editor s with print capability. flarq does
not need to duplicate such a fine facility.

Would make life easier for operators .... thinking out loud. :-) 73

Might give the programmer a nervous breakdown :>(

Sorry for so many negative answers.

73, Dave, W1HKJ


Re: NBEMS questions

"Craig" <kc0kp@...>
 

Send an email to this address: NBEMSham-unsubscribe@...


--- In NBEMSham@..., arthurwolfman@... wrote:

PLEASE TAKE ME OFF YOUR MAILING LIST AS i DO NOT USE YOUR PROGRAM
AND TELL ANYBODY ELSE NOT TO MAIL ME ABOUT YOUR PROGRAM.

THANKS
Arthur

-------------- Original message --------------
From: w1hkj <w1hkj@...>
Hello Dave, Skip,

1. Have you considered the use of compression on files, etc. to be
transmitted, thus
possibly cutting transmission times by one half?

Simple answer: it would not result in a reduction in transfer time

Long answer: Please read the ARQ specification. All data transmitted
within the block must be valid ARQ characters. These are identical to
base64 encoding characters. When you compress a file you produce binary
data which is 8 bit, not base64. The compressed file would then have to
be base64 encoded which has the effect of un-doing the compression.

2. Currently, when stations are disconnected, the displayed data on the
receiving
flarq screen disappears. You are probably saving the info in a file.

flarq is a file transfer protocol, and nothing more than that and
received data is always saved to a file if the ARQ transfer is
successful.

Can you continue to save the data in a file, leave the data
displayed in
the window,
and have the ability to high-light selected data, right-click on the
high-lighted
data, and choose to send the data to a printer. Likewise, the
ability to
right-click
the received data screen and choose to clear the screen.

The "clear" button does that.

Every incoming file is name iaw with the sending stations file
descriptor. Incoming text, binary, and image files are always
located in:
c:&#92;NBEMS&#92;ARQrecv

incoming emails are located in
c:&#92;NBEMS&#92;Mail&#92;ARQin

The purpose of displaying data on the flarq rx window is solely to give
the operator a sense of what is happening. It may or may not represent
what is finally put into the file. When sending a binary or image file
the rx window will appear to contain random noise as you will be
viewing
the base64 data stream. The program will convert the base64 data back
into its original format.

Windows has some excellent editors with print capability. flarq does
not need to duplicate such a fine facility.

Would make life easier for operators .... thinking out loud. :-) 73

Might give the programmer a nervous breakdown :>(

Sorry for so many negative answers.

73, Dave, W1HKJ


Re: NBEMS questions

"Craig" <kc0kp@...>
 

Or got to: http://groups.yahoo.com/group/NBEMSham/join

and at the bottom of the page click on "Leave Group"



--- In NBEMSham@..., arthurwolfman@... wrote:

PLEASE TAKE ME OFF YOUR MAILING LIST AS i DO NOT USE YOUR PROGRAM
AND TELL ANYBODY ELSE NOT TO MAIL ME ABOUT YOUR PROGRAM.

THANKS
Arthur

-------------- Original message --------------
From: w1hkj <w1hkj@...>
Hello Dave, Skip,

1. Have you considered the use of compression on files, etc. to be
transmitted, thus
possibly cutting transmission times by one half?

Simple answer: it would not result in a reduction in transfer time

Long answer: Please read the ARQ specification. All data transmitted
within the block must be valid ARQ characters. These are identical to
base64 encoding characters. When you compress a file you produce binary
data which is 8 bit, not base64. The compressed file would then have to
be base64 encoded which has the effect of un-doing the compression.

2. Currently, when stations are disconnected, the displayed data on the
receiving
flarq screen disappears. You are probably saving the info in a file.

flarq is a file transfer protocol, and nothing more than that and
received data is always saved to a file if the ARQ transfer is
successful.

Can you continue to save the data in a file, leave the data
displayed in
the window,
and have the ability to high-light selected data, right-click on the
high-lighted
data, and choose to send the data to a printer. Likewise, the
ability to
right-click
the received data screen and choose to clear the screen.

The "clear" button does that.

Every incoming file is name iaw with the sending stations file
descriptor. Incoming text, binary, and image files are always
located in:
c:&#92;NBEMS&#92;ARQrecv

incoming emails are located in
c:&#92;NBEMS&#92;Mail&#92;ARQin

The purpose of displaying data on the flarq rx window is solely to give
the operator a sense of what is happening. It may or may not represent
what is finally put into the file. When sending a binary or image file
the rx window will appear to contain random noise as you will be
viewing
the base64 data stream. The program will convert the base64 data back
into its original format.

Windows has some excellent editors with print capability. flarq does
not need to duplicate such a fine facility.

Would make life easier for operators .... thinking out loud. :-) 73

Might give the programmer a nervous breakdown :>(

Sorry for so many negative answers.

73, Dave, W1HKJ


Vdigi unusual behavior on quit

"n0evh" <n0evh@...>
 

I uninstalled older versions and installed the latest download tonight.

I run Windows XP Pro.

The vdigi when you quit the app, continues to run. It does not show
on the screen, but is running. I had to go to the Windows Task
Manager and kill it that way. Never have seen that before.

John N0EVH


running in the background

w1hkj <w1hkj@...>
 

I uninstalled older versions and installed the latest download tonight.

I run Windows XP Pro.

The vdigi when you quit the app, continues to run. It does not show
on the screen, but is running. I had to go to the Windows Task
Manager and kill it that way. Never have seen that before.

John N0EVH

How did you exit the application John ... Did you use the Files/Exit menu item or press the big "X" in the window manager title bar?

I have not figured out why yet, but VB6 keeps an application running in the background when the second method is used.

BTW as a programmer I have always disliked that X.

73, Dave, W1HKJ


Re: running in the background

w1hkj <w1hkj@...>
 

Fixed for the next release.

Dave, W1HKJ


Re: Vdigi unusual behavior on quit

"n0evh" <n0evh@...>
 

Update

If I use File, Exit no problem.

If I click the close window X the app has the unusual behavior.

John


Re: running in the background

"n0evh" <n0evh@...>
 

--- In NBEMSham@..., w1hkj <w1hkj@...> wrote:

Fixed for the next release.

Dave, W1HKJ
Dave,

Thanks alot. I was mistified for awhile....then when brain came on
duh!

Yep, I'll bet the big X is a problem child.

I am looking forward to further testing with KB0EMB Larry on 2 meter
SSB soon. We are looking forward to adding this capability to our
RACES team.

73 and thanks for your contribution to the ARS.

John N0EVH


Cable suugestions

"Dean" <deansrealm@...>
 

Hi, I'm new to the group and to digital as well. I seek any
reccomendations you have for the purchase of or adaptaion a to speaker/
mic cable to use w/ NBEMS and a yaesu and or icom mobile. Thanks-Dean


Re: Cable suugestions

"Shelby Ennis, W8WN" <w8wn@...>
 

Dean wrote:
Hi, I'm new to the group and to digital as well. I seek any reccomendations you have for the purchase of or adaptaion a to speaker/ mic cable to use w/ NBEMS and a yaesu and or icom mobile. Thanks-Dean
Simplest - shielded cable.
Slightly better - shielded cable with small cap in series.
Better still - 1:1 tiny audio transformer.
(I'm currently using all 3 of these methods for several digital pgms, primarily WSJT).

There are other methods better still, but have not used them.
The standard commercial interface is West Mountain Radio's RigBlaster. MFJ's and others should also work, and all are much more sophisticated than the above.

The simpler you go, the more possible problems with hum. But I've done OK with 4 different rigs & 3 or 4 computers over the past 10 years using very simple (i.e., cheap) stuff. Must work, for I'm up to 500 grids & 73 DXCC countries on 144 MHz.

73, Shelby, W8WN

Shelby Ennis, W8WN - EM77bq - KY
w8wn@..., w8wn@...
Web: http://www.qsl.net/w8wn/
<><


Cable Suggestions

"rjkruis" <rkruis@...>
 

Hi Dean,

A sound card interface while not absolutely necessary, sure goes a
long ways towards reducing or eliminating ground loop, hum, and RF in
the audio problems that will most likely occur if you make a direct
connection from your rig to the computer sound card. Also, most
computers today have no COM port and most of the communications
software we as hams use requires a COM port, real or virtual. Some of
the more elaborate commercially available interfaces include a USB to
COM port adapter built in with drivers that assign a virtual COM
port. For those that don't, or if you want to build your own sound
card interface (a very simple and rewarding experience if you like to
home-brew), most computer and office supply stores sell a USB to COM
port adapter. Unfortunately some of them provide less than full RS-
232 (COM port) compatibility so you may have to try one or more to
get one that works. For folks new to the Soundcard modes, Randy K7AGE
has made up some great Utube tutorials. Below is the link and I think
you'll find them very informative and useful.

http://www.youtube.com/watch?v=FmsFhz_dyAg&feature=related

Rick K8CAV


Re: Cable suugestions

"Gene (AE5FT)" <gray_hair2@...>
 

--- In NBEMSham@..., "Dean" <deansrealm@...> wrote:

Hi, I'm new to the group and to digital as well. I seek any
reccomendations you have for the purchase of or adaptaion a to
speaker/
mic cable to use w/ NBEMS and a yaesu and or icom mobile. Thanks-Dean

I suggest you look at the Tigertronics interfaces as well. These are
simple and do not require a serial port. New ones have a USB interface
as well. Not expensive, easy to set up, and my experience has been
good with these units.

... Gene ae5ft


NBEMS Testing

John Bradley <jbradley@...>
 

so where is anyone doing any tests on NBEMS? 30m works well daytime from up here in western Canada.

 

Have successfully transferred mail using MFSK, since that day had a lot of Doppler or “flutter” on my signal, a problem living at this latitude.

 

John

VE5MU

 

 


Re: NBEMS Testing

"kh6ty" <hteller@...>
 

I have 30m capability and am avaiable any time for tests.
 
I am in South Carolina.

73, Skip KH6TY
 
 
 

----- Original Message -----
Sent: Sunday, February 03, 2008 10:50 PM
Subject: [NBEMSham] NBEMS Testing

so where is anyone doing any tests on NBEMS? 30m works well daytime from up here in western Canada.

Have successfully transferred mail using MFSK, since that day had a lot of Doppler or “flutter” on my signal, a problem living at this latitude.

John

VE5MU


No virus found in this incoming message.
Checked by AVG Free Edition.
Version: 7.5.516 / Virus Database: 269.19.19/1256 - Release Date: 2/2/2008 1:50 PM