Date   

Re: NBEMS today

w1hkj <w1hkj@...>
 

Rick wrote:

Questions:

1) Does plain talk only work if you are connected? If you are trying to
connect and you place some thing in the flarq plain talk window to send,
is this ignored and never goes through?

Plain talk only works if you are connected.  It is not an ARQ keyboard to keyboard mode.  The only purpose is to allow short comments between the operators on the two ends of the ARQ connection.


2) Is it possible that a way could be found to stop transmission on
either end? If you make a mistake, (such as I did and forgot to change
the speed of the mode from 63 to 250, it would not stop sending and sent
a number of blocks before pausing. Otherwise the only way to stop things
is to close the program(s).

This is addressed in flarq-3.2 the most recent version


3) If one station shows connected status but the other one does not,
what should be the proper course of action to take? The station that is
showing no connection has no way of knowing the other station thinks it
is connected and if a sending station is attempting to send a file to
the receiving station and tried to connect, it appears that the
receiving station will not send any control codes out because it thinks
it is already connected. Thus the sending station can not connect.

Old problem reported by 3.0 testers.  Please use the newer suite.


4) When you are sending a file, you are still supposed to be able to use
plain talk? It seemed to just ignore that data when I tried to send
plain talk in the middle of the file transfer.

What size file, what mode, what were your configuration settings; ie: block size, etc.


5) When you are connected and not sending any files, but are sending
chat via the plain talk window, there is a lot of overhead with
additional CRC or other types of data that accompanies each line. Since
there is no ARQ with plain talk, what is that doing? It also drastically
slows down the communication speed, so I often would just key in the
chat on the VBdigi window.

Not recommended as there might be contention between flarq and the keyboard keying and unkeying of the transmitter.


6) Finally, could you review for me the procedure for making connections
and file sending? Which station should be sending a beacon and in every
case is the receiving station required to activate the connect button?

See if the updated help file answers this question: 

http://www.w1hkj.com/FlarqHelpFiles/flarq.html

Dave


Re: NBEMS today

w1hkj <w1hkj@...>
 

Rick wrote:

IMaybe I was not doing something quite right. My NBEMS software versions
are VBdigi with 1.2.0 and flarq 3.0.

This is direct quote from the http://www.w1hkj.com/NBEMS web page:

If you previously downloaded previous versions of NBEMS you have two ways to upgrade to the new test suite
  1. Uninstall the previous version (no data files will be lost) and then download and install 1.3.0, or
  2. Download the following two zipped executables and copy them to the NBEMS program directory (c:\Progam Files\NBEMS\) overwriting the existing flarq.exe and vbdigi.exe files.
For most users it will be easier to uninstall the old suite and install the new one.

This version IS NOT compatible with previous versions.  Please read through the flarq help for new information on using this ARQ application.  If you are testing with another amateur station be sure that both of you are using flarq-3.2.

The announcement of the new NBEMS suite was placed yesterday on this group and also on the linuxham yahoo group.

Please do not continue testing with the older suite of software and in particular do not expect the older version to work with the newer version.

73, Dave, W1HKJ


Re: NBEMS today

"kh6ty" <hteller@...>
 

. When it does, the station with the
traffic presses the Connect button, which sends a connect request to the
answering station and the label at the answering station changes to
Connecting.

This should read "Connected", not "Connecting".

73, Skip KH6TY

----- Original Message -----
From: "kh6ty" <hteller@...>
To: <NBEMSham@yahoogroups.com>
Sent: Saturday, March 15, 2008 8:37 PM
Subject: Re: [NBEMSham] NBEMS today


Rick,


What seems to be happening is that after the initial sending of the
first group of blocks, the program awaits the ACK/NAK or needed fills?
Yes, that is necessary for the ARQ process, but there is no guarantee the
other station can copy you.

... but the other station does not transmit anything so the sending
station repeats several characters and then when nothing comes back,
tries this until it times out.
It does not transmit anything, because it probably has not received a
request to confirm or not confirm.


Maybe I was not doing something quite right. My NBEMS software versions
are VBdigi with 1.2.0 and flarq 3.0.
The latest flarq is 3.2. the latest VBdig is 1.2.8. the version numbers will
show up on the caption bar now, so you can tell at a glance which version
you are using.

Everyone updating at the same time is always a problem, of course. Some get
the message and some do not.

Your difficulties could be with the older version. The newest flarq 3.2 will
not communicate properly as will 3.0, because there is a newer version to
improve the logic.


Questions:

1) Does plain talk only work if you are connected? If you are trying to
connect and you place some thing in the flarq plain talk window to send,
is this ignored and never goes through?
Plain Talk only works if you are connected.


2) Is it possible that a way could be found to stop transmission on
either end? If you make a mistake, (such as I did and forgot to change
the speed of the mode from 63 to 250, it would not stop sending and sent
a number of blocks before pausing. Otherwise the only way to stop things
is to close the program(s).
It will always try to complete a block. You can click Abort if it is
showing, but that is supposed to communicate to the other station also to
abort, and if it does not receive that instruction, it will try again.

We have to look again at the Abort logic, as I find myself also sometimes
killing flarq when the process appears not to be continuing and I am not
sure what is going on, as I may have not kept track of the exchanges.


3) If one station shows connected status but the other one does not,
what should be the proper course of action to take? The station that is
showing no connection has no way of knowing the other station thinks it
is connected and if a sending station is attempting to send a file to
the receiving station and tried to connect, it appears that the
receiving station will not send any control codes out because it thinks
it is already connected. Thus the sending station can not connect.
Just wait until the other station tells you it shows connected also. You can
ask this by just going on the air and asking, but the possibility exists
that you will double with the other station and then the other station is
transmitting and will not receive what you just sent.

If there is not a confirmation from the other station of a connect, it is
better for both to agree to kill flarq and start the beacon/connect button
process over, as a timeout is possible anyway. Remember that ARQ is
error-free, and regular communications may have errors, but our brains
usually can fill in the blanks.


4) When you are sending a file, you are still supposed to be able to use
plain talk? It seemed to just ignore that data when I tried to send
plain talk in the middle of the file transfer.
Yes. Plain talk will wait to send the data until the current reception or
transmission is finished, so it does not interrupt it.


5) When you are connected and not sending any files, but are sending
chat via the plain talk window, there is a lot of overhead with
additional CRC or other types of data that accompanies each line. Since
there is no ARQ with plain talk, what is that doing? It also drastically
slows down the communication speed, so I often would just key in the
chat on the VBdigi window.
ARQ in the form of ACK and NAK is not applied to plain talk, but the
overhead is. The advantage to using Plain Talk is being to talk during a
transfer and not interrupt it. It is sometime faster to just go the air and
type, but you run the risk of doubling or interrupting your own transmission
timed by flarq.


6) Finally, could you review for me the procedure for making connections
and file sending? Which station should be sending a beacon and in every
case is the receiving station required to activate the connect button?
The recommended procedure now is to first establish contact without any
beacon. Then the station with traffic tells the other station, in keyboard
to keyboard mode, "Send beacon". When the other station presses his beacon
button, the beacon transmission will be received by the station with
traffic. If, and only if, the beacon transmission (the part with your
callsign and message) is received, the answering station's callsign will
appear on your flarq callsign field. When it does, the station with the
traffic presses the Connect button, which sends a connect request to the
answering station and the label at the answering station changes to
Connecting. At that point the station with traffic still shows Connecting,
but since he is the one to send traffic, he has to wait until he also shows
connected, because you obviously cannot send traffic without being
connected. >

Upgrade to the latest versions on the NBEMS web page and see if things work
better, but be sure the station you are testing with is using the same
version as you are.

Keep the questions and feedback coming, as we want to do all we can to make
the process a little confusing as possible, in an environment that there is
no way to know if a station has copied your transmissions perfectly.

Tim, N4UM, and I exchanged files for about three hours today on 30m and then
on 40m, using several different modes. Sometimes things work better than
others, which pointed out the advantage of establishing dependable
point-to-point emcomm circuits on VHF where the operator is not faced with
QSB, static, QRM and varying propagation throught the day and night, with
some bands going out all together just as you are trying to transfer
messages.

In an actual emergency, stations with higher power and higher gain VHF
antennas will all beam toward the disaster area to serve as forwarding
stations, so you basically have several possible dependable point-to-point
paths that you may never achieve on HF. Tim was running 500 watts on 40m
PSK63 and I was running 20 watts. Tim was solid print almost all the time,
but he had difficulty copying me sometimes in the presence of QRM. This is
similar to the situation of my being a lower powered station, with a poorer
antenna in the disaster area, and he being the more powerful station with a
better antenna outside.

The people that have been testing on VHF have not had lot of the same
difficulty as those try to use HF for NBEMS.

I copied you almost 100% today, but at times the AL station was barely
visible on the waterfall in either MFSK16 or PSK63, which you turned back to
at the end, and my print on him was only about 10%. Remember that in order
for the exchanges to be successful, an error-free reception of the requests
or acknowledgements must take place at least once before timing out.

On 30m, Tim was over S9 here for 10 minutes and then dropped far enough that
the VBdigi level indicator sometimes did not show all green, dipping down
near the squelch threshold line with QSB.

MFSK16 is still the best mode for poor conditions we have in VBdigi, but
even with MFSK16, when there is no copy, there will be no acknowledgements.
If the signal has disappeared from the waterfall, it is not possible to know
how far down it has dropped, or even if it is still there at all.

If at all possible, make some tests on VHF with stations within 100 miles
that have decent gain antennas.

73, Skip KH6TY

Thanks for any help on this.

73,

Rick, KV9U

--------------------------------------------------------------------------------


No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.21.7/1329 - Release Date: 3/14/2008
12:33 PM


--------------------------------------------------------------------------------


No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.21.7/1329 - Release Date: 3/14/2008 12:33 PM


Re: NBEMS today

"kh6ty" <hteller@...>
 

Rick,


What seems to be happening is that after the initial sending of the
first group of blocks, the program awaits the ACK/NAK or needed fills?
Yes, that is necessary for the ARQ process, but there is no guarantee the other station can copy you.

... but the other station does not transmit anything so the sending
station repeats several characters and then when nothing comes back,
tries this until it times out.
It does not transmit anything, because it probably has not received a request to confirm or not confirm.


Maybe I was not doing something quite right. My NBEMS software versions
are VBdigi with 1.2.0 and flarq 3.0.
The latest flarq is 3.2. the latest VBdig is 1.2.8. the version numbers will show up on the caption bar now, so you can tell at a glance which version you are using.

Everyone updating at the same time is always a problem, of course. Some get the message and some do not.

Your difficulties could be with the older version. The newest flarq 3.2 will not communicate properly as will 3.0, because there is a newer version to improve the logic.


Questions:

1) Does plain talk only work if you are connected? If you are trying to
connect and you place some thing in the flarq plain talk window to send,
is this ignored and never goes through?
Plain Talk only works if you are connected.


2) Is it possible that a way could be found to stop transmission on
either end? If you make a mistake, (such as I did and forgot to change
the speed of the mode from 63 to 250, it would not stop sending and sent
a number of blocks before pausing. Otherwise the only way to stop things
is to close the program(s).
It will always try to complete a block. You can click Abort if it is showing, but that is supposed to communicate to the other station also to abort, and if it does not receive that instruction, it will try again.

We have to look again at the Abort logic, as I find myself also sometimes killing flarq when the process appears not to be continuing and I am not sure what is going on, as I may have not kept track of the exchanges.


3) If one station shows connected status but the other one does not,
what should be the proper course of action to take? The station that is
showing no connection has no way of knowing the other station thinks it
is connected and if a sending station is attempting to send a file to
the receiving station and tried to connect, it appears that the
receiving station will not send any control codes out because it thinks
it is already connected. Thus the sending station can not connect.
Just wait until the other station tells you it shows connected also. You can ask this by just going on the air and asking, but the possibility exists that you will double with the other station and then the other station is transmitting and will not receive what you just sent.

If there is not a confirmation from the other station of a connect, it is better for both to agree to kill flarq and start the beacon/connect button process over, as a timeout is possible anyway. Remember that ARQ is error-free, and regular communications may have errors, but our brains usually can fill in the blanks.


4) When you are sending a file, you are still supposed to be able to use
plain talk? It seemed to just ignore that data when I tried to send
plain talk in the middle of the file transfer.
Yes. Plain talk will wait to send the data until the current reception or transmission is finished, so it does not interrupt it.


5) When you are connected and not sending any files, but are sending
chat via the plain talk window, there is a lot of overhead with
additional CRC or other types of data that accompanies each line. Since
there is no ARQ with plain talk, what is that doing? It also drastically
slows down the communication speed, so I often would just key in the
chat on the VBdigi window.
ARQ in the form of ACK and NAK is not applied to plain talk, but the overhead is. The advantage to using Plain Talk is being to talk during a transfer and not interrupt it. It is sometime faster to just go the air and type, but you run the risk of doubling or interrupting your own transmission timed by flarq.


6) Finally, could you review for me the procedure for making connections
and file sending? Which station should be sending a beacon and in every
case is the receiving station required to activate the connect button?
The recommended procedure now is to first establish contact without any beacon. Then the station with traffic tells the other station, in keyboard to keyboard mode, "Send beacon". When the other station presses his beacon button, the beacon transmission will be received by the station with traffic. If, and only if, the beacon transmission (the part with your callsign and message) is received, the answering station's callsign will appear on your flarq callsign field. When it does, the station with the traffic presses the Connect button, which sends a connect request to the answering station and the label at the answering station changes to Connecting. At that point the station with traffic still shows Connecting, but since he is the one to send traffic, he has to wait until he also shows connected, because you obviously cannot send traffic without being connected. >

Upgrade to the latest versions on the NBEMS web page and see if things work better, but be sure the station you are testing with is using the same version as you are.

Keep the questions and feedback coming, as we want to do all we can to make the process a little confusing as possible, in an environment that there is no way to know if a station has copied your transmissions perfectly.

Tim, N4UM, and I exchanged files for about three hours today on 30m and then on 40m, using several different modes. Sometimes things work better than others, which pointed out the advantage of establishing dependable point-to-point emcomm circuits on VHF where the operator is not faced with QSB, static, QRM and varying propagation throught the day and night, with some bands going out all together just as you are trying to transfer messages.

In an actual emergency, stations with higher power and higher gain VHF antennas will all beam toward the disaster area to serve as forwarding stations, so you basically have several possible dependable point-to-point paths that you may never achieve on HF. Tim was running 500 watts on 40m PSK63 and I was running 20 watts. Tim was solid print almost all the time, but he had difficulty copying me sometimes in the presence of QRM. This is similar to the situation of my being a lower powered station, with a poorer antenna in the disaster area, and he being the more powerful station with a better antenna outside.

The people that have been testing on VHF have not had lot of the same difficulty as those try to use HF for NBEMS.

I copied you almost 100% today, but at times the AL station was barely visible on the waterfall in either MFSK16 or PSK63, which you turned back to at the end, and my print on him was only about 10%. Remember that in order for the exchanges to be successful, an error-free reception of the requests or acknowledgements must take place at least once before timing out.

On 30m, Tim was over S9 here for 10 minutes and then dropped far enough that the VBdigi level indicator sometimes did not show all green, dipping down near the squelch threshold line with QSB.

MFSK16 is still the best mode for poor conditions we have in VBdigi, but even with MFSK16, when there is no copy, there will be no acknowledgements. If the signal has disappeared from the waterfall, it is not possible to know how far down it has dropped, or even if it is still there at all.

If at all possible, make some tests on VHF with stations within 100 miles that have decent gain antennas.

73, Skip KH6TY

Thanks for any help on this.

73,

Rick, KV9U

--------------------------------------------------------------------------------


No virus found in this incoming message.
Checked by AVG.
Version: 7.5.519 / Virus Database: 269.21.7/1329 - Release Date: 3/14/2008 12:33 PM


Re: NBEMS today

roger g6ckr <radio@...>
 

Hi Rick
Just a quick response to say some of the items mentioned are ironed out
or at least run smoother in flarq 3.2.
73 roger G6CKR

On Sat, 2008-03-15 at 18:29 -0500, Rick wrote:
I was able to get together with Ed, W3NR. He was able to send a file to
me, but when I sent one to him it did not go through. Later on, George,
AL7BX from CO tried to connect with me and I found the same problem.
What seems to be happening is that after the initial sending of the
first group of blocks, the program awaits the ACK/NAK or needed fills?
... but the other station does not transmit anything so the sending
station repeats several characters and then when nothing comes back,
tries this until it times out.

Maybe I was not doing something quite right. My NBEMS software versions
are VBdigi with 1.2.0 and flarq 3.0.

Questions:

1) Does plain talk only work if you are connected? If you are trying to
connect and you place some thing in the flarq plain talk window to send,
is this ignored and never goes through?

2) Is it possible that a way could be found to stop transmission on
either end? If you make a mistake, (such as I did and forgot to change
the speed of the mode from 63 to 250, it would not stop sending and sent
a number of blocks before pausing. Otherwise the only way to stop things
is to close the program(s).

3) If one station shows connected status but the other one does not,
what should be the proper course of action to take? The station that is
showing no connection has no way of knowing the other station thinks it
is connected and if a sending station is attempting to send a file to
the receiving station and tried to connect, it appears that the
receiving station will not send any control codes out because it thinks
it is already connected. Thus the sending station can not connect.

4) When you are sending a file, you are still supposed to be able to use
plain talk? It seemed to just ignore that data when I tried to send
plain talk in the middle of the file transfer.

5) When you are connected and not sending any files, but are sending
chat via the plain talk window, there is a lot of overhead with
additional CRC or other types of data that accompanies each line. Since
there is no ARQ with plain talk, what is that doing? It also drastically
slows down the communication speed, so I often would just key in the
chat on the VBdigi window.

6) Finally, could you review for me the procedure for making connections
and file sending? Which station should be sending a beacon and in every
case is the receiving station required to activate the connect button?

Thanks for any help on this.

73,

Rick, KV9U

------------------------------------

Yahoo! Groups Links



Re: Digital EmComm a new way

Rick <mrfarm@...>
 

Shelby,

What information did you find inaccurate about Pactor?

73,

Rick, KV9U


Shelby Ennis, W8WN wrote:

I wonder -
I'm seeing a lot of comments concerning Pactor, primarily. P3.
I wonder how many who are commenting on it have actually used it, especially from the field???
I ask this because a number of comments and comparisons are not really accurate.

I have needed Pactor in the past and will likely need Pactor again, if weather, etc, continue in their "interesting mode".
I am in hopes that NBEMS can eventually do some things that Pactor can't do as well.
(I also have mikes, a key for my portable rig, a knee key for the mobile rig - and while in MS following Katrina, we wished for carrier pigeons!)

P3 is great! But you have to know how to use it. P1 does very well, but isn't used much any more. But other modes are definitely better for some things. And we (i.e., Amateur Radio) need a number of eggs in a number of baskets!




NBEMS today

Rick <mrfarm@...>
 

I was able to get together with Ed, W3NR. He was able to send a file to me, but when I sent one to him it did not go through. Later on, George, AL7BX from CO tried to connect with me and I found the same problem. What seems to be happening is that after the initial sending of the first group of blocks, the program awaits the ACK/NAK or needed fills? ... but the other station does not transmit anything so the sending station repeats several characters and then when nothing comes back, tries this until it times out.

Maybe I was not doing something quite right. My NBEMS software versions are VBdigi with 1.2.0 and flarq 3.0.

Questions:

1) Does plain talk only work if you are connected? If you are trying to connect and you place some thing in the flarq plain talk window to send, is this ignored and never goes through?

2) Is it possible that a way could be found to stop transmission on either end? If you make a mistake, (such as I did and forgot to change the speed of the mode from 63 to 250, it would not stop sending and sent a number of blocks before pausing. Otherwise the only way to stop things is to close the program(s).

3) If one station shows connected status but the other one does not, what should be the proper course of action to take? The station that is showing no connection has no way of knowing the other station thinks it is connected and if a sending station is attempting to send a file to the receiving station and tried to connect, it appears that the receiving station will not send any control codes out because it thinks it is already connected. Thus the sending station can not connect.

4) When you are sending a file, you are still supposed to be able to use plain talk? It seemed to just ignore that data when I tried to send plain talk in the middle of the file transfer.

5) When you are connected and not sending any files, but are sending chat via the plain talk window, there is a lot of overhead with additional CRC or other types of data that accompanies each line. Since there is no ARQ with plain talk, what is that doing? It also drastically slows down the communication speed, so I often would just key in the chat on the VBdigi window.

6) Finally, could you review for me the procedure for making connections and file sending? Which station should be sending a beacon and in every case is the receiving station required to activate the connect button?

Thanks for any help on this.

73,

Rick, KV9U


Re: Testng Today

"Bill - N8ET" <n8et@...>
 

Ed -

I am hanging out around 10.135 also for a bit. Nothing heard/worked as yet.

On 15 Mar 2008 at 16:16, Ed wrote:



We better make that 10.135 +1500 a little less busy !!!!

Ed W3NR
--
73 - Bill - N8ET
Kanga US
www.kangaus.com
419-423-4604 (Kanga)
419-423-5643 (home)


Re: Testng Today

"Ivan Privitera" <ivan.privitera@...>
 


Re: Testng Today

"Ivan Privitera" <ivan.privitera@...>
 


Re: Testng Today

roger g6ckr <radio@...>
 

On Sat, 2008-03-15 at 16:16 -0400, Ed wrote:
Ed wrote:
Anyone up to running some tests. I'll be on 30 meters.

10.140 +1500 I'll be CQn PSK63

I'll be around till 5 EDT 21z

Ed W3NR

------------------------------------

We better make that 10.135 +1500 a little less busy !!!!

Ed W3NR

------------------------------------
the band seems to have closed completely over here so good luck with
something more local.
73 Roger
G6CKR


Re: Testng Today

Ed <autek@...>
 

Ed wrote:
Anyone up to running some tests. I'll be on 30 meters.
10.140 +1500 I'll be CQn PSK63
I'll be around till 5 EDT 21z
Ed W3NR
------------------------------------

We better make that 10.135 +1500 a little less busy !!!!

Ed W3NR


Testng Today

Ed <autek@...>
 

Anyone up to running some tests. I'll be on 30 meters.

10.140 +1500 I'll be CQn PSK63

I'll be around till 5 EDT 21z

Ed W3NR


Re: NBEMS today

ae6la@...
 

Hi All,
 
George, AL7BX, and I have had success exchanging files using psk63.  I sent one OE email and one text file.  I received two text files from George.  All short test messages.  I've sent my received files by Internet back to George for his confirmation.
 
73, Ken - AE6LA




Re: Digital EmComm a new way

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

I wonder -
I'm seeing a lot of comments concerning Pactor, primarily. P3.
I wonder how many who are commenting on it have actually used it, especially from the field???
I ask this because a number of comments and comparisons are not really accurate.

I have needed Pactor in the past and will likely need Pactor again, if weather, etc, continue in their "interesting mode".
I am in hopes that NBEMS can eventually do some things that Pactor can't do as well.
(I also have mikes, a key for my portable rig, a knee key for the mobile rig - and while in MS following Katrina, we wished for carrier pigeons!)

P3 is great! But you have to know how to use it. P1 does very well, but isn't used much any more. But other modes are definitely better for some things. And we (i.e., Amateur Radio) need a number of eggs in a number of baskets!

73, Shelby, W8WN


"The President can make you a general, but only communications can make you a commander." General Curtis LeMay


NBEMS Testing

"tim.n4um" <N4UM@...>
 

I'll be "lurking" around 7070 or 10138 Plus 1.5 this afternoon
(Saturday) if anyone want to do some testing. I have vbdigi 1.3.0 and
FLARQ 3.2 running under Windows.

Tim, N4UM


Re: Update on testing - Digital EmComm a new way

Rick <mrfarm@...>
 

I have only used Pactor on HF many years ago, but have heard that the later Pactor 2 and 3 modes work very well on VHF and you would expect P3 to work at the top Level 6 speed which may not happen very often on HF.

However, if I was going to build a system that could perform at those speeds, I would move toward the MIL-STD/FED-STD/STANAG modems now that extremely low cost sound card technology is available. Either free for RFSM2400 or very low cost for hams for RFSM8000. These modems do not work all that fast on HF paths that are not of high quality based upon my testing, but I suspect that they will outperform Pactor 3 on VHF since they have a higher throughput on the fastest speed level.

The P3 speeds can only be obtained with fairly good signals. Did you find that you were experiencing +10 dB S/N or better?

At that point, I think you will find that the RFSM modems will perform similarly, and at the best S/N ratios, RFSM8000 will outperform P3 due to its higher speed levels. But that requires a very good link.

Due to our 300 baud limit in the RTTY/Data portions of the HF bands it is not legal to send text data using these high baud rate single tone modems here in the U.S. But it is completely legal to use on 6 meters and up and this may prove to be the best possible ultra low cost and readily available mode. I plan to test this on VHF since it is legal to send both text data as well as images. I have tested it on HF with John, VE5MU, and it was a fairly slow mode under zero to +10 dB S/N conditions, but as good as any sound card mode since the S.C. modes do not tend to scale up and down for conditions without manual control.

The cost of the SCS modem means that few hams will buy such a product, thus you simply will not have anyone to communicate with. Its primary utility is for casual use to avoid using the commercial circuits for sending e-mail, particularly for travelers on water or RV on land. I do not consider this very wise for emergency communications use unless you are doing like you are with specific point to point stations that you know will have the equipment. If anything fails, you may not have others who can back you up. This is the strong point of NBEMS.

73,

Rick, KV9U




Bruce N Haupt wrote:

--Hi Rick and group:

I have been following the discussion about how to cram digital modes with
different bandwidth's into the HF spectrum.
There are pro and con's on both sides, and it boils down to what
communications tools in your "tool box" work best for your served
agency's needs.
In San Diego, the Red Cross has a need, to be able to send digital E-mail
traffic from the Disaster Operations Center (DOC), to the field shelters.
We found during the October wild fires, that communications
infrastructure WILL FAIL! The search was on to find a means of passing
digital traffic from point to point, without depending on any
communications infrastructure. In January a test using 2 meter SSB, was
conducted over a 60 mile obstructed mountainous path. The weather was
very cold so there was no inversion layer to help in propagation.
At the DOC in San Diego, there was an Icom IC7000 running 50 watts to a
13 element horizontally polarized Yagi. At the Anza Borrego desert field
site, there was an Icom 7000 with 50 watts into a small 4 element beam.
At both stations there was an SCS PTC-II usb modem and laptop computer.
During the tests there was no problem hearing the weak SSB voice signals.
When the SCS modem was switched in, a digital contact was easily
established. A 40 Kb message, with a color map attachment, was passed
back and forth reliably. Yes it was NOT as fast as WiFi , it took about 3
minutes, but it worked!! The throughput for PACTOR III is around 5200 Bps
with a bandwidth of 2400 Hz. There is security to be had with this mode
as well. By choosing an obscure unused frequency on the low end of 144
MHz, it is doubtful that the weak horizontally polarized intermittent SSB
signals would be found by people who did not have "a need to know". They
would also need an expensive modem to decode the signals. For those that
cannot afford the SCS modem, MT63 should also work, at a much slower
speed, and it will require a cut-and-paste operation to move the message
traffic into the served agency's computer e-mail system. I keep hoping
that some one will cook up a software bridge for MT63 that would work as
well as Winlink does for Pactor III. Add PC-ALE and you have an EmComm
network.
I am always surprised on how far I can talk on 2 meter SSB. Even when the
band is "dead" and I cannot hear the N6NB/B beacon in Tehachapi, I can
still talk to Orange and Los Angeles Counties, 100 miles away over an
obstructed path. When there is an inversion I can talk to Lancaster,
Barstow, Victorville areas 150 miles away. I have heard Bakersfield in
the central valley, and Los Vegas, and all this with 50 watts into a 4
element beam! My field station is an FT897 with a Gel cell battery, 55
watt foldable P.V. Solar array, and charge controller. The antenna is
either a horizontally polarized Elk L.P. or a Diamond 5 element take down
yagi A144S5.
When I operate the State OES net from the EOC using 40 meter NVIS,
(TS570/G5RV), I often cannot copy local stations 20 to 150 miles away,
because high angle NVIS propagation is not supported, for the reason that
the MUF is below 7 MHz. During such conditions Northern California
stations will call stations in the South, and the South calls the North.
These poor conditions have been with us for years during the sunspot
minimum. For EmComm here in San Diego, 2 meter SSB, Digital Pactor III,
is MUCH more reliable, than HF, and the stations can be operated by any
technician class operator.
What Say? 73 Bruce WA6DNT@...


Re: Update on testing - Digital EmComm a new way

"kh6ty" <hteller@...>
 

Hi Bruce,

The speed of MT63 is the same as PSK250, and NBEMS already supports PSK250. MT63 is just more resistant to QRM than PSK250, and this is more valuable for HF than for VHF, where there is seldom any QRM except on the calling frequency.

VHF is certainly a more appropriate place for Pactor-3 than HF, since more bandwidth is available. If $1000 for a SCS modem is a problem for a volunteering ham, then there is NBEMS at less speed and no extra cost. For Pactor-3, "there is always Mastercard". <wink>

73, Skip KH6TY

I keep hoping
that some one will cook up a software bridge for MT63 that would work as
well as Winlink does for Pactor III. Add PC-ALE and you have an EmComm
network.
.

What Say? 73 Bruce WA6DNT@...


Update on testing - Digital EmComm a new way

Bruce N Haupt <wa6dnt@...>
 

--Hi Rick and group:

I have been following the discussion about how to cram digital modes with
different bandwidth's into the HF spectrum.
There are pro and con's on both sides, and it boils down to what
communications tools in your "tool box" work best for your served
agency's needs.

In San Diego, the Red Cross has a need, to be able to send digital E-mail
traffic from the Disaster Operations Center (DOC), to the field shelters.
We found during the October wild fires, that communications
infrastructure WILL FAIL! The search was on to find a means of passing
digital traffic from point to point, without depending on any
communications infrastructure. In January a test using 2 meter SSB, was
conducted over a 60 mile obstructed mountainous path. The weather was
very cold so there was no inversion layer to help in propagation.
At the DOC in San Diego, there was an Icom IC7000 running 50 watts to a
13 element horizontally polarized Yagi. At the Anza Borrego desert field
site, there was an Icom 7000 with 50 watts into a small 4 element beam.
At both stations there was an SCS PTC-II usb modem and laptop computer.
During the tests there was no problem hearing the weak SSB voice signals.
When the SCS modem was switched in, a digital contact was easily
established. A 40 Kb message, with a color map attachment, was passed
back and forth reliably. Yes it was NOT as fast as WiFi , it took about 3
minutes, but it worked!! The throughput for PACTOR III is around 5200 Bps
with a bandwidth of 2400 Hz. There is security to be had with this mode
as well. By choosing an obscure unused frequency on the low end of 144
MHz, it is doubtful that the weak horizontally polarized intermittent SSB
signals would be found by people who did not have "a need to know". They
would also need an expensive modem to decode the signals. For those that
cannot afford the SCS modem, MT63 should also work, at a much slower
speed, and it will require a cut-and-paste operation to move the message
traffic into the served agency's computer e-mail system. I keep hoping
that some one will cook up a software bridge for MT63 that would work as
well as Winlink does for Pactor III. Add PC-ALE and you have an EmComm
network.

I am always surprised on how far I can talk on 2 meter SSB. Even when the
band is "dead" and I cannot hear the N6NB/B beacon in Tehachapi, I can
still talk to Orange and Los Angeles Counties, 100 miles away over an
obstructed path. When there is an inversion I can talk to Lancaster,
Barstow, Victorville areas 150 miles away. I have heard Bakersfield in
the central valley, and Los Vegas, and all this with 50 watts into a 4
element beam! My field station is an FT897 with a Gel cell battery, 55
watt foldable P.V. Solar array, and charge controller. The antenna is
either a horizontally polarized Elk L.P. or a Diamond 5 element take down
yagi A144S5.

When I operate the State OES net from the EOC using 40 meter NVIS,
(TS570/G5RV), I often cannot copy local stations 20 to 150 miles away,
because high angle NVIS propagation is not supported, for the reason that
the MUF is below 7 MHz. During such conditions Northern California
stations will call stations in the South, and the South calls the North.
These poor conditions have been with us for years during the sunspot
minimum. For EmComm here in San Diego, 2 meter SSB, Digital Pactor III,
is MUCH more reliable, than HF, and the stations can be operated by any
technician class operator.

What Say? 73 Bruce WA6DNT@...


Re: Flarq Today

w1hkj <w1hkj@...>
 

Rick wrote:

What is the advantage of using Sylpheed over other e-mail programs,
especially because it says that Sylpheed is optimized for NBEMS? In what
way is it optimized or different?

I had asked this earlier, but I don't think I received a response.

73,

Rick, KV9U

Only from the aspect of being able to incorporate the ARQin ARQout and ARQsent folders into the Sylpheed folder scheme.  You cannot do that with any of the MS products such as Outlook or Outlook Express, or the open source Thunderbird.  With all of those email clients it is necessary to drag email messages to and from the ARQ folders.

Dave, W1HKJ

16681 - 16700 of 16972