[digitalradio] Re: hi my first post Question? kc0mjp

2009-08-11 Thread frankk2ncc
Not that it helps you in your question much Mark, but thank you for the tip!

A mode/software I didn't know about, which I'm sure there's many.

Anyway, did a sample of what it sounds like here:
http://www.youtube.com/watch?v=N9Hbyre71Fg

Welcome to the forum!  Have you tried any digital modes yet?  Interested in any 
others besides JASON?

frank, k2ncc



Re: [digitalradio] Re: Soliciting suggestions

2009-08-11 Thread Stelios Bounanos
> On Tue, 11 Aug 2009 18:02:29 -, "Howard Z."  said:

[...]

> OK, then there is Olivia.  Nobody in our group wants to use
> Fldigi/Flarq because we are forced to use a custom mode.

Olivia is not a custom mode.  It is well supported and most (all?)
useful bandwidth/tones pairs can be set via RSID.  It is also not the
only effective mode for NBEMS.

> We can't just customize it and leave it alone.  Every time we select
> it - up pops a window to confuse people into diddling with it.  We
> don't need our custom mode embedded in fldigi software, just let us
> set it up and then have the software leave us alone when we select it.

You can choose any available combination of tones and bandwidth and save
it, and fldigi will remember it the next time you run it.  There are a
few commonly used presets (e.g. 8/250, 16/500 etc.) in a menu for quick
access.  We could possibly add your preferred settings if you ask.  We
also plan to make Olivia presets available as macro buttons.

> But, there is a worse problem.  The fldigi 3.12 is a nightmere that
> often will not even start - it pops up error messages and fails right
> and left - an unreliable useless software product.

3.12 made some very extensive changes to the Windows side of things;
little, if any, OS support code was left untouched.  3.12 was tested by
many users before release and I can assure you that it does not fail
right away for them or the developers.  It's likely that more time will
be needed until it is up to par with 3.11 (which had more than one year
of testing) in stability, but obviously we had to release it!

> However the fldigi 3.11 has possibilities - but try to get a group to
> all be using the same version of anything?  Especially tell them to
> not use the latest version?  And not the past 3 latest versions?  Ok -
> fldigi is a joke and waste of time - it's taken a global leaps
> backwards.  "This application has requested the Runtime to terminate
> it in an unusual way.  Please contact the application's support team
> for more information" - uh - no thank you.

Great, now please explain how we can possibly fix bugs that we know
nothing about.  You seem to think that we released a broken version on
purpose just so that we could show you the Windows crash handler -- but
that would be absurd.

> "fldigi.exe has stopped working.  Windows is checking for a solution
> to the problem" "A problem has caused the program to stop working
> correctly.. Windows will close the program and notify you if a
> solution is available".

Nothing we can do about the "reassuring" Windows messages, sorry.  We do
not receive those crash reports.  Please report bugs to us and we'll do
our best to squash them.  Basic bug report guidelines here:

  http://groups.yahoo.com/group/linuxham/message/7201

If you do not wish to email us directly or subscribe to any mailing
lists in order to report bugs, there is a bug tracker here (BerliOS
account required to file new reports, will try to get this changed):

  http://developer.berlios.de/mantis/set_project.php?project_id=9149

And if you subscribe to this list you'll receive regular notifications
of new test releases (including win32 binaries):

  http://lists.berlios.de/mailman/listinfo/fldigi-alpha

(This list is also used for discussion.  I will create an
announcements-only list shortly.)


Whatever problems are preventing you from using fldigi will be fixed
much sooner if you help.


[...]


-- 

73,
Stelios, M0GLD.


Re: [digitalradio] Re: Soliciting suggestions

2009-08-11 Thread kh6ty
See if Dave can help you, w...@bellsouth.net or go to NBEMSham. It 
should not be that hard!

You do not beacon first, but you first establish contact in the mode and 
then ask the other station to send an flarq beacon. His callsign should 
appear in your flarq and then you just press Connect.

73 Skip KH6TY

John Taylor wrote:
>  
>
> Thanks Skip,
>
> As I replied to Simon, we have been trying the NBEMS modes of FLdigi 
> and FLarq for a while now. We are able to communicate via fldigi in 
> virtually every mode, but have yet to establish a connection with flarq.
>
> Any ideas are welcome ...
>
> John
> KE5HAM
> --- In digitalradio@yahoogroups.com 
> , kh6ty  wrote:
> >
> > John,
> >
> > You might consider NBEMS for HF: www.w1hkj.com/NBEMS. We have optimized
> > the DominoEx and MFSK16 modes for high static conditions and also 
> have a
> > verification program called Wrap if you do not want to use flarq.
> >
> > 73 Skip KH6TY
> > NBEMS Development Team
> >
> >
> >
> >
> > John Taylor wrote:
> > >
> > >
> > > We are seeking to establish a standard for a digital "network" style
> > > system to handle emergency communications.
> > > We have established certain standards we are looking to follow.
> > > The mode/protocol/package etc. should be based on weak signal HF
> > > capability.
> > > The mode/protocol/package should be able to handle transferring of
> > > data in more than just ascii text format (ie: transfer files such as
> > > spreadsheets, etc.)
> > > The system must NOT require proprietary hardware such as pactor 
> II/III
> > > modems. In other words, standard modems and/or sound card based.
> > >
> > > Before the flames start, there are already some out there that are
> > > being tested that actually meet these requirements, but are still in
> > > testing stages.
> > >
> > > Any suggestions would be greatly appreciated 
> > >
> > > John
> > > KE5HAM
> > >
> > >
> >
> > --
> > *Skip KH6TY*
> > http://KH6TY.home.comcast.net 
> >
>
> 

-- 
*Skip KH6TY*
http://KH6TY.home.comcast.net


[digitalradio] Electronics Weekly - Bringing FUN back to the classroom

2009-08-11 Thread Trevor .
AMSAT-UK's FUNcube satellite project features on the front cover of
the August 12-18 edition of Electronics Weekly magazine

The printed edition of the magazine will be dropping through
letterboxes during Wednesday morning. You can read the digital
version of Electronics Weekly magazine online or download the pages in
PDF format at

http://cde.cerosmedia.com/1D4a803d8814a11352.cde 

The full FUNcube article titled 'Bringing FUN back to the classroom'
by Steve Bush is on page 8 and contains an interview with Graham
Shirville G3VZV. 

Electronics Weekly Magazine
http://www.electronicsweekly.com/ 

AMSAT-UK http://www.uk.amsat.org/ publish a colour A4 newsletter, OSCAR News, 
full of satellite information.
You can join online at https://secure.amsat.org.uk/subs_form/ 

73 Trevor M5AKA



  


[digitalradio] Soliciting suggestions

2009-08-11 Thread Patrick Lindecker
Hello John,

For transmissions without error, there is a mode which name is ARQ FAE, 
available at 125 or 50 bauds (ALE400).
You can transmit small files, messages, mails, APRS positions at a 
reasonable speed. There are a lot of possibilities.

This mode derives from ALE (DBM) and PAX but it is only available in 
Multipsk (however the specifications are public). Look at
a.. "ALE and ALE400 easy with 
Multipsk"(http://f6cte.free.fr/ALE_and_ALE400_easy_with_Multipsk.doc)
a.. "The ARQ FAE beacon easy with Multipsk" 
(http://f6cte.free.fr/The_ARQ_FAE_beacon_easy_with_Multipsk.doc)

You must consider also ALE ("141A") which has a lot of possibilities, is 
available in many pieces of softwares and hardware and has a very good 
support.

Call ID and Prop ID could also be of interest (but I don't know your needs).
"The_Call_ID_and_Prop_ID_easy_with_Multipsk.doc" (MS Word Doc,  425 KB)

73
Patrick 



Re: [digitalradio] Re: Soliciting suggestions- ALE is the answer

2009-08-11 Thread Andrew O'Brien
While awaiting Winmor, the only real alternatives are NBEMS/FLARQ,
ALE,  or PSKMAIL.  ALE is, in my opinion, the best conceptually.  It
is "free" and  does not need any fancy modems.  It does require a
network of stations world-wide and a fairly hefty (good SNR)  signal
to make a "link".  There is a basic network that exists, triple the
size of it, and it would really do well.  Maintaining a "listen before
transmitting" ethic would help with some current objections to the
"unattended soundings" aspects of ALE.  Switching from standard ALE to
ALE 400 would probably be best in the long run.

Both NBEMS and PSKMAIL would also work, same thing though.  They need
a network of active stations, if they had this, they would work well.



Andy K3UK


Re: [digitalradio] Soliciting suggestions

2009-08-11 Thread Steinar Aanesland
Hi John

Why not try ALE400 ARQ mode in Patrick's Multipsk?. It has all
qualification  you are looking for.

73 de LA5VNA Steinar





John Taylor wrote:
> We are seeking to establish a standard for a digital "network" style system 
> to handle emergency communications.
> We have established certain standards we are looking to follow.
> The mode/protocol/package etc. should be based on weak signal HF capability.
> The mode/protocol/package should be able to handle transferring of data in 
> more than just ascii text format (ie: transfer files such as spreadsheets, 
> etc.)
> The system must NOT require proprietary hardware such as pactor II/III 
> modems. In other words, standard modems and/or sound card based.
>
> Before the flames start, there are already some out there that are being 
> tested that actually meet these requirements, but are still in testing stages.
>
> Any suggestions would be greatly appreciated 
>
> John
> KE5HAM
>
>
>
>   



[digitalradio] Re: Soliciting suggestions

2009-08-11 Thread Howard Z.
Well,

IMHO, EasyPal has great potential for sending all file types - text, pictures, 
etc.. with error-correction/partial-retransmits.

The problem with EasyPal - it seems only people with 500+ watt amplifiers can 
transmit reliably via NVIS antennas to the majority of users listening in the 
region.  If one tries the more robust Easypal modes meant for bad conditions, 
then one get lambasted for their transmission taking too long.  I am not sure 
that even using mode E can really get through under lower power and our 
generally bad current band-conditions because we aren't testing this.  Those in 
charge love to blast their ALS-600 watt amplifiers - amplifiers that probably 
won't have power during an emergency.  It takes at least 2 people to 
try/practice low power during bad conditions - and I am alone in this regard.

Then EasyPal BSRs (partial retransmits) are being skipped because if even one 
person happens to receive the transmission correctly, he automatically FTPs it 
to a public web site, and nobody wants to ask for a BSR because they got the 
image off the internet.  So nobody knows any more how well he/she can transmit 
reliably to the entire region with Easypal.  The internet may not be available 
during an incident, and even if it is, the information may be sensitive and 
will be automatically blasted onto the internet if even one group member left 
that FTP feature turned on.

I have a suggestion for those who love the Easypal's FTP feature.  Turn off 
your radios and just FTP pictures to each other via the internet.  Better yet - 
Ebay your radios - you don't need them anymore.

So, in my opinion, EasyPal is just totally unsuitable.  The FTP feature needs 
to be completely ripped out and removed from the software - it can't even be 
left in as an option.  People need to practice the appropriate transmission 
mode that will actually work with under 50 watts under bad noisy conditions.  
If that means 5 minutes to send a picture - so be it.  If EasyPal won't work 
reliably in a FEMA region on 50 watts and a good antenna, then maybe it just 
isn't suitable?

OK, then there is Olivia.  Nobody in our group wants to use Fldigi/Flarq 
because we are forced to use a custom mode.  We can't just customize it and 
leave it alone.  Every time we select it - up pops a window to confuse people 
into diddling with it.  We don't need our custom mode embedded in fldigi 
software, just let us set it up and then have the software leave us alone when 
we select it.  But, there is a worse problem.  The fldigi 3.12 is a nightmere 
that often will not even start - it pops up error messages and fails right and 
left - an unreliable useless software product.  However the fldigi 3.11 has 
possibilities - but try to get a group to all be using the same version of 
anything?  Especially tell them to not use the latest version?  And not the 
past 3 latest versions?  Ok - fldigi is a joke and waste of time - it's taken a 
global leaps backwards.  "This application has requested the Runtime to 
terminate it in an unusual way.  Please contact the application's support team 
for more information" - uh - no thank you.  "fldigi.exe has stopped working.  
Windows is checking for a solution to the problem"  "A problem has caused the 
program to stop working correctly.. Windows will close the program and notify 
you if a solution is available".  Thus we need a better solution.

Next, what do we have?  MixW and Ham Radio Deluxe's DM780.  They work fine - no 
ARQ or retransmits in it.  Users may need to ask for partial retransmissions 
and may still have unnoticed errors in the text of messages.  These s/w 
products are excellent and DM780 is free.  (I really love DM780 - and I also 
loved the old VAX780 which inspired its name)  We've used Oliva ghost mode at 
under 5 watts - slow but works reliably.  But one needs the error correction 
like TCP/IP has on the internet.  You need to know the messages were delivered 
error-free.  As a minimum the modes need to be able to not print obvious junk 
from random band noise.  So, these sound card modes like Olivia, MT63, MFSK16 
are good - but not perfect enough.

Then there is the old Pactor 1/2/3 user-to-user connects using software like 
Alpha, NcWinPtc, XPWare, and WinPack.  This will get the message across error 
free.  The only problem is nobody is practicing these anymore.  Nothing will 
work unless you practice it.  I haven't seen a Pactor-1 net in some time.

Then we have Winlink - it works well.  Can it survive a massive internet 
failure?  I don't know.  Last I read, the issue is being addressed.  But, if 
Winlink is operational it is the best solution.

So, the result is - that no matter what we chose to use - the state of the art 
is far from perfect - and thus relayed messages will also be far from perfect.  
We need to take a large step backwards and start practicing Pactor-1 until the 
state of the art becomes artfully appealing again.


OK, that's my pessimistic 2 cent

[digitalradio] Re: Soliciting suggestions

2009-08-11 Thread John Taylor
Thanks again Simon,

Please understand, I appreciate your viewpoint. Please also understand, there 
are other viewpoints equally as valid. That is the whole purpose of this thread 
to begin with, to try to solicit suggestions for "existing" programs to try to 
resolve an existing problem. One of the issues with "current activity" is to 
make it all but mandatory for those wishing to participate to shell out large 
sums of their own hard earned cash to participate. This excludes far too many 
needed resources. That is not for me or you to decide. 
Put simply, many hams just can't afford the $1000 + price tag for pactor 
modems. The emergency communications world exists of more than just the elite 
rich folks.

Again, the solicitation stands .
We are trying to identify the most economical and reasonable mechanism to 
accomplish a specific goal. We are NOT trying to re-invent the wheel, just 
trying to determine which wheel will best suit our purpose.

Thanks again,

John
KE5HAM
--- In digitalradio@yahoogroups.com, "Simon \(HB9DRV\)"  wrote:
>
> - Original Message - 
> From: "John Taylor" 
> >
> > ... it does involve official emergency communications.
> >
> 
> Then surely the official part should put some money into the project if it's 
> so important?
> 
> I honestly implore you *not* to fragment current EMS activity and instead 
> focus your resources into one of the existing projects.
> 
> Simon Brown, HB9DRV
> www.ham-radio-deluxe.com
>




[digitalradio] hi my first post Question? kc0mjp

2009-08-11 Thread mark
has anyone tried a weaksignal program "JASON" i read on it seems ok.
its made for keyboard to keyboard rxtx 



[digitalradio] Re:30 Meter Multi Mode Weekend Aug 22/23

2009-08-11 Thread Dennis Bauer
All ok we'll be listing on the Atherton tablelands for everyone and trying to 
make contact's will put 
all my mates on to it there are 5 of us that use digital, only local so far we 
have been on Dominoex
8 or 11 most week nights on 3530mhz at 7pm east Australia time, Billy VK4WL  in 
Mareeba does
a fair bit of DX, i hope we can hear you cheers and thankyou Dennis Bauer 
VK4JDJ.
Dennis Bauer
2 Adcock Close Moomin
Herberton 4887
ph 07 4096 2574
VK4JDJ
dennisba...@bigpond.com

[digitalradio] Re: Contestia QSO with Iceland thanks to RSID

2009-08-11 Thread rich3x
Bravo -- and have had a similar experience under noisy low-signal contacts that 
would have been otherwise impossible w/o RSID (pn 14074).  What freq did you 
capture TF3G on?

   de Rich/N2JR  FM18

--- In digitalradio@yahoogroups.com, Tony  wrote:
>
> All, 
> 
> Made my first Contestia contact with Iceland (Gisli TF3G) thanks to RSID. 
> Gisli mentioned that he heard my CQ and went through several Olivia tone / 
> bandwidth combinations not knowing I was running Contestia; a close "cousin" 
> to Olivia. 
> 
> He then realized I was running RSID and finally turned his on which did the 
> trick. There's no doubt that we would have missed each other without RSID. 
> 
> It's becoming more popular now that it's available in more programs, but I 
> still hear many calling without RSID. This usually results in fewer contacts 
> due to the fact that it's sometimes difficult to figure out what mode is in 
> use by sight and sound. 
> 
> RSID is available in Fldigi, Multipsk, HRD/DM780 and soon to be Mixw. We need 
> to start using it more folks... 
> 
> Tony -K2MO
>




Re: [digitalradio] Soliciting suggestions

2009-08-11 Thread Per
I suggest you have a look at pskmail. The wiki is at 
http://pskmail.wikispaces.com

73 de Per, sm0rwo






From: John Taylor 
To: digitalradio@yahoogroups.com
Sent: Tuesday, August 11, 2009 6:45:18 PM
Subject: [digitalradio] Soliciting suggestions

  
We are seeking to establish a standard for a digital "network" style system to 
handle emergency communications.
We have established certain standards we are looking to follow.
The mode/protocol/ package etc. should be based on weak signal HF capability.
The mode/protocol/ package should be able to handle transferring of data in 
more than just ascii text format (ie: transfer files such as spreadsheets, etc.)
The system must NOT require proprietary hardware such as pactor II/III modems. 
In other words, standard modems and/or sound card based.

Before the flames start, there are already some out there that are being tested 
that actually meet these requirements, but are still in testing stages.

Any suggestions would be greatly appreciated 

John
KE5HAM


   

__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 

Re: [digitalradio] Re: Soliciting suggestions

2009-08-11 Thread Simon (HB9DRV)
- Original Message - 
From: "John Taylor" 
>
> ... it does involve official emergency communications.
>

Then surely the official part should put some money into the project if it's 
so important?

I honestly implore you *not* to fragment current EMS activity and instead 
focus your resources into one of the existing projects.

Simon Brown, HB9DRV
www.ham-radio-deluxe.com 



[digitalradio] Re: Soliciting suggestions

2009-08-11 Thread John Taylor
Thanks Skip,

As I replied to Simon, we have been trying the NBEMS modes of FLdigi and FLarq 
for a while now. We are able to communicate via fldigi in virtually every mode, 
but have yet to establish a connection with flarq.

Any ideas are welcome ...

John
KE5HAM
--- In digitalradio@yahoogroups.com, kh6ty  wrote:
>
> John,
> 
> You might consider NBEMS for HF: www.w1hkj.com/NBEMS. We have optimized 
> the DominoEx and MFSK16 modes for high static conditions and also have a 
> verification program called Wrap if you do not want to use flarq.
> 
> 73 Skip KH6TY
> NBEMS Development Team
> 
> 
> 
> 
> John Taylor wrote:
> >  
> >
> > We are seeking to establish a standard for a digital "network" style 
> > system to handle emergency communications.
> > We have established certain standards we are looking to follow.
> > The mode/protocol/package etc. should be based on weak signal HF 
> > capability.
> > The mode/protocol/package should be able to handle transferring of 
> > data in more than just ascii text format (ie: transfer files such as 
> > spreadsheets, etc.)
> > The system must NOT require proprietary hardware such as pactor II/III 
> > modems. In other words, standard modems and/or sound card based.
> >
> > Before the flames start, there are already some out there that are 
> > being tested that actually meet these requirements, but are still in 
> > testing stages.
> >
> > Any suggestions would be greatly appreciated 
> >
> > John
> > KE5HAM
> >
> > 
> 
> -- 
> *Skip KH6TY*
> http://KH6TY.home.comcast.net
>




[digitalradio] Re: Soliciting suggestions

2009-08-11 Thread John Taylor
Thanks Simon,

"WE" have been trying the NBEMS for a week or so now. "WE" have been able to 
operate peer-to-peer from within Fldigi in virtually every mode, but have yet 
to be able to make a connection using Flarq. Try as we will, it just has not 
happened no matter what.

The "WE" is not really that important right now, other than it does involve 
official emergency communications. Please understand, I am not trying to be 
secretive or vague, just for the sake of this issue, the "who" simply should 
have no bearing at all.

Thanks for your prompt reply,

John - KE5HAM

--- In digitalradio@yahoogroups.com, "Simon \(HB9DRV\)"  wrote:
>
> John,
> 
> Who's 'we' in this context? Why not join one of the existing teams - NBEMS 
> is working well.
> 
> Simon Brown, HB9DRV
> www.ham-radio-deluxe.com
> 
> - Original Message - 
> From: "John Taylor" 
> 
> 
> >
> > Before the flames start, there are already some out there that are being 
> > tested that actually meet these requirements, but are still in testing 
> > stages.
> >
>




Re: [digitalradio] Soliciting suggestions

2009-08-11 Thread kh6ty
John,

You might consider NBEMS for HF: www.w1hkj.com/NBEMS. We have optimized 
the DominoEx and MFSK16 modes for high static conditions and also have a 
verification program called Wrap if you do not want to use flarq.

73 Skip KH6TY
NBEMS Development Team




John Taylor wrote:
>  
>
> We are seeking to establish a standard for a digital "network" style 
> system to handle emergency communications.
> We have established certain standards we are looking to follow.
> The mode/protocol/package etc. should be based on weak signal HF 
> capability.
> The mode/protocol/package should be able to handle transferring of 
> data in more than just ascii text format (ie: transfer files such as 
> spreadsheets, etc.)
> The system must NOT require proprietary hardware such as pactor II/III 
> modems. In other words, standard modems and/or sound card based.
>
> Before the flames start, there are already some out there that are 
> being tested that actually meet these requirements, but are still in 
> testing stages.
>
> Any suggestions would be greatly appreciated 
>
> John
> KE5HAM
>
> 

-- 
*Skip KH6TY*
http://KH6TY.home.comcast.net


Re: [digitalradio] Soliciting suggestions

2009-08-11 Thread Simon (HB9DRV)
John,

Who's 'we' in this context? Why not join one of the existing teams - NBEMS 
is working well.

Simon Brown, HB9DRV
www.ham-radio-deluxe.com

- Original Message - 
From: "John Taylor" 


>
> Before the flames start, there are already some out there that are being 
> tested that actually meet these requirements, but are still in testing 
> stages.
>



[digitalradio] Soliciting suggestions

2009-08-11 Thread John Taylor
We are seeking to establish a standard for a digital "network" style system to 
handle emergency communications.
We have established certain standards we are looking to follow.
The mode/protocol/package etc. should be based on weak signal HF capability.
The mode/protocol/package should be able to handle transferring of data in more 
than just ascii text format (ie: transfer files such as spreadsheets, etc.)
The system must NOT require proprietary hardware such as pactor II/III modems. 
In other words, standard modems and/or sound card based.

Before the flames start, there are already some out there that are being tested 
that actually meet these requirements, but are still in testing stages.

Any suggestions would be greatly appreciated 

John
KE5HAM




[digitalradio] win98 and winpskse

2009-08-11 Thread John Lindsay
A fellow ham has a computer with win98 and is using winpskse. He has a 
situation where by if he puts the pointer at any particular frequency then 
selects his macro the pointer will jump. ie he places the pointer at a clear 
spot at 1500hz and selects the cq macro his pointer would jump to 1700hz (he 
couldn't tell me the exact amount so these are just figures to represent the 
jump). I don't have a similar set up so I can't duplicate it. Has anyone had 
this happen to them and if so -- how was it resolved?

John
ve3sjv