Date   

Re: Bandmap data externally accessible?

Barry N1EU
 

CW Skimmer is not allowed for unassisted contesting.  I'm talking about tuning the band with a panadapter-centric SDR type radio as an unassisted contest participant.  Having the bandmap overlay the panadapter would be a game changer in terms of seeking stations to work.  Folks need to understand that a bandmap is a critical tool for unassisted contesting and not just a visual display of cluster spots for assisted contesters.

73, Barry N1EU

On Mon, Nov 16, 2015 at 12:10 PM, n7un.guy@... [N1MMLoggerplus] <N1MMLoggerplus@...> wrote:
 

Barry,


Take a look at CWSkimmer at http://www.dxatlas.com/cwskimmer/

 

Manual at: 

Guy/n7un



Re: 2Tone inserting QTC in WAE

Jeff AC0C
 

I don’t want to restart a FSK vs. AFSK war.   However, it seems a lot of guys are going to a lot of work to get FSK going on an otherwise perfectly functional AFSK system (meaning they can run PSK fine, but want FSK for RTTY).  A lot of guys tell me they want to use FSK because it’s simple.  But if you have to use outboard add-on stuff to patch it onto an existing and function AFSK system, that does not make a lot of sense.  There is no functional benefit between FSK and a properly setup AFSK system.  In fact, on a lot of rigs FSK sideband content is just miserable.
 
So unless a guy has a rig filter limitation they are trying to work around, then AFSK is really the way to go.  2Tone is a rock star with an audio feed and the uHam interfaces make doing AFSK a snap.
 
73/jeff/ac0c
www.ac0c.com
alpha-charlie-zero-charlie

 

Sent: Monday, November 16, 2015 11:10 AM
Subject: Re: FW: [N1MMLoggerplus] 2Tone inserting QTC in WAE
 
 

David,

First and foremost, thank you for developing 2Tone. It's receiver is simply amazing. RTTY contesting will never be the same without 2Tone.

However, I am not sure I follow this argument. MMTTY works just fine with microHam; is there a reason the same approach cannot be applied to 2Tone? The MMTTY source code is publicly available so it should be no secret how to do FSK via USB. Does 2Tone use the standard UART interface or implements its own?

Has anyone actually asked microHam for help integrating the two? Have they said "No"? After all, N1MM itself implements the mH SO2R protocol so I'd expect the company to be quite open to working with developers.

My computer, as most computers today, does not have any serial ports and using a USB-based radio interface is the most convenient way to interface with my radio.  microHam is not the only proprietary hardware interface. Does 2Tone NOT work with any of them?



Rudy N2WQ
---In N1MMLoggerplus@..., wrote :

2Tone is allowed to be used with logging programs that are free.

 

The same applies to hardware that comes with software the software source has to be public domain for instance TinyFSK or the hardware design is in the public domain, e.g. using pFSK.

 

I provided the FSK via the COM port system which comes with a lot of warnings as it will have timing jitter that will and does cause bit errors. Hardware interfaces are in the public domain. However for a  PC with at least 4 cores the probability of an TX caused error within a contest exchange is low.

 

However microHam products hardware design and software/firmware source are not in the public domain so no interface will ever be written for those boxes.

 

To get the best TX performance then use 2Tone’s DOOK which is audio based. It provides a very accurate narrow band signal which can be used by anyone with a sound card and interface to the audio input of their rig. A couple of resistors and a lead is all that is needed.

 

It is very unfortunate that virtually all rigs (K3 excepted) transmit a very wide FSK signal when direct FSK keying is being used. This can and does cause considerable QRM to adjacent band users.

 

73 David G3YYD

 

From: N1MMLoggerplus@... [mailto:N1MMLoggerplus@...]
Sent: 16 November 2015 09:53
To: N1MMLoggerplus@...
Subject: RE: [N1MMLoggerplus] 2Tone inserting QTC in WAE

 

 

Using 2Tone in the main window could be a challenge. 2Tone does not send proper FSK to my microHam MK2R+ box and I am forced to use MMTTY in the main window, with 2Tone in RX windows.


Rudy N2WQ
---In N1MMLoggerplus@..., <rellison@...> wrote :

QTC’s cannot be clicked on in any other window but the main RX window. So clicking in an RX window it will not work.. You can make the main window use 2tone since it is doing a better job for you..

 

73 Rick N2AMG

 

From: N1MMLoggerplus@... [mailto:N1MMLoggerplus@...]
Sent: Saturday, November 14, 2015 10:43 PM
To: N1MM Logger Plus Reflector <N1MMLoggerPlus@...>
Subject: [N1MMLoggerplus] 2Tone inserting QTC in WAE

 

 

I’m running N1MM+ v1.0.5295.0 and 2Tone v 15.2a in WAE RTTY.

 

When clicking on the QTCs from the 2Tone window: nothing happens.

From the MMTTY window: all is OK.

 

As usual, 2Tone inserts all the other regular QSO info with no problem: call, s/n, etc.  Only MMTTY will insert the QTC data.

Many times 2Tone is a better decoder than MMTTY and I rely on it.

 

Is this a feature or am I doing something wrong.

 

    73 James K1SD

< p class="MsoNormal">

 


Re: Bandmap data externally accessible?

Guy N7UN
 


Re: FW: [N1MMLoggerplus] 2Tone inserting QTC in WAE

N2WQ
 

David,

First and foremost, thank you for developing 2Tone. It's receiver is simply amazing. RTTY contesting will never be the same without 2Tone.

However, I am not sure I follow this argument. MMTTY works just fine with microHam; is there a reason the same approach cannot be applied to 2Tone? The MMTTY source code is publicly available so it should be no secret how to do FSK via USB. Does 2Tone use the standard UART interface or implements its own?

Has anyone actually asked microHam for help integrating the two? Have they said "No"? After all, N1MM itself implements the mH SO2R protocol so I'd expect the company to be quite open to working with developers.

My computer, as most computers today, does not have any serial ports and using a USB-based radio interface is the most convenient way to interface with my radio.  microHam is not the only proprietary hardware interface. Does 2Tone NOT work with any of them?


Rudy N2WQ
---In N1MMLoggerplus@..., <g3yyd@...> wrote :

2Tone is allowed to be used with logging programs that are free.

 

The same applies to hardware that comes with software the software source has to be public domain for instance TinyFSK or the hardware design is in the public domain, e.g. using pFSK.

 

I provided the FSK via the COM port system which comes with a lot of warnings as it will have timing jitter that will and does cause bit errors. Hardware interfaces are in the public domain. However for a  PC with at least 4 cores the probability of an TX caused error within a contest exchange is low.

 

However microHam products hardware design and software/firmware source are not in the public domain so no interface will ever be written for those boxes.

 

To get the best TX performance then use 2Tone’s DOOK which is audio based. It provides a very accurate narrow band signal which can be used by anyone with a sound card and interface to the audio input of their rig. A couple of resistors and a lead is all that is needed.

 

It is very unfortunate that virtually all rigs (K3 excepted) transmit a very wide FSK signal when direct FSK keying is being used. This can and does cause considerable QRM to adjacent band users.

 

73 David G3YYD

 

From: N1MMLoggerplus@... [mailto:N1MMLoggerplus@...]
Sent: 16 November 2015 09:53
To: N1MMLoggerplus@...
Subject: RE: [N1MMLoggerplus] 2Tone inserting QTC in WAE

 

 

Using 2Tone in the main window could be a challenge. 2Tone does not send proper FSK to my microHam MK2R+ box and I am forced to use MMTTY in the main window, with 2Tone in RX windows.


Rudy N2WQ
---In N1MMLoggerplus@..., <rellison@...> wrote :

QTC’s cannot be clicked on in any other window but the main RX window. So clicking in an RX window it will not work.. You can make the main window use 2tone since it is doing a better job for you..

 

73 Rick N2AMG

 

From: N1MMLoggerplus@... [mailto:N1MMLoggerplus@...]
Sent: Saturday, November 14, 2015 10:43 PM
To: N1MM Logger Plus Reflector <N1MMLoggerPlus@...>
Subject: [N1MMLoggerplus] 2Tone inserting QTC in WAE

 

 

I’m running N1MM+ v1.0.5295.0 and 2Tone v 15.2a in WAE RTTY. 

 

When clicking on the QTCs from the 2Tone window: nothing happens.

From the MMTTY window: all is OK.

 

As usual, 2Tone inserts all the other regular QSO info with no problem: call, s/n, etc.  Only MMTTY will insert the QTC data.

Many times 2Tone is a better decoder than MMTTY and I rely on it.

 

Is this a feature or am I doing something wrong.

 

    73 James K1SD

< p class="MsoNormal"> 

 


Re: WAE frustration when receiving QTCs

Larry K8UT
 

>I beleive that if we could send the header and all line one by one, it would be easier for the receiving station.
You can do that now. Don’t send “I am QRV”, instead just start sending the “Resend n n n “ one-at-a-time.
 
>...no easy task and we use QTC functionnality only once a year.
And therein lies the problem. Rick has managed to make a complicated task easy. If we over-engineer the options nobody will be able to do it.
 
-larry (K8UT)
 

Sent: Monday, November 16, 2015 11:29 AM
Subject: Re: [N1MMLoggerplus] WAE frustration when receiving QTCs
 
 

I agree.  I have also experienced a situation where 2 lines were merged as my decoder didn't decode the CR properly.   That messed the receiving process big time.
 
I beleive that if we could send the header and all line one by one, it would be easier for the receiving station.
 
Also, it would be nice if the focus would be put on a specific qtc line when clicking on the proper input field.  That would have give the opportunity to clear up some of the mess.  I did that a couple of time and the info ended up in the callsign or qtc header fields.
 
Keep up the good work N1MM folks.  I know rebuilding a software from scratch is no easy task and we use QTC functionnality only once a year.
 
73, Martin  VE2NMB
 
2015-11-16 11:07 GMT-05:00 'GL-DJ3IW-Web' gl-dj3iw@... [N1MMLoggerplus] <N1MMLoggerplus@...>:
 

I fully support this complaint.

A couple of us here in Germany suffered from exactly the same problem!

This problem really needs the attention of the N1MM+ crew.

 

Mike, you didn’t do anything wrong.

 

73 de Goetz DJ3IW

 

Von: N1MMLoggerplus@... [mailto:N1MMLoggerplus@...]
Gesendet: Montag, 16. November 2015 15:24
An: N1MMLoggerplus@...
Betreff: [N1MMLoggerplus] WAE frustration when receiving QTCs

 

 

Sending QTCs was very easy. Receiving QTCs was equally easy when each line decoded properly. A QTC that was garbled during decoding sometimes could not be entered with a mouse press depending on how severely it was garbled. Mouse pressing the next incoming QTC would upset the numbering sequence making it difficult to ask for a resend.

During other QSOs I tried manually entering a garbled QTC so that I could keep pace with the next QTCs. Once I began manually entering I could no longer mouse press the next decoded QTC and have it automatically fill. I was forced to manually enter all remaining lines. I couldn't type fast enough to keep pace with the sender.

I could have stopped at the garbled QTC and asked for repeats, however, the problem usually presented itself in the first or second QTC.

What was I doing wrong?

73,
Mike K2MK

 

 


Re: WAE frustration when receiving QTCs

Larry K8UT
 

Mike,
 
You’re not doing anything wrong, but there is only so much you can expect the logging software to do to solve a reception problem. I am a lousy typist, and there is no way I could keep up with a sending station if I were manually typing QTC entries. I generally follow these guidelines when getting garbled QTC data.
 
1. Always click on each QTC line – even if it’s busted - so that all subsequent lines are in the right slots (#1 – 10)
2. When there are only a few busted lines, I suffer through the “Resend # # #” process with the other station
3. When there are lots of busted lines OR the alignment is wrong (lines in the wrong slots), I request ”Resend All”
4. After repeated failures at resending (propagation or QRM make it impossible and I am wasting time and losing points) I abandon the effort and cancel the QTC exchange.
 
With changes made to the QTC routines this past year, Rick N2AMG has the very complicated QTC code working better-than-ever. Despite that, I had two instances of “Resend all” this past weekend and one time when I cancelled the QTC exchange entirely.
 
-larry (K8UT)
 

Sent: Monday, November 16, 2015 10:24 AM
Subject: [N1MMLoggerplus] WAE frustration when receiving QTCs
 
 

Sending QTCs was very easy. Receiving QTCs was equally easy when each line decoded properly. A QTC that was garbled during decoding sometimes could not be entered with a mouse press depending on how severely it was garbled. Mouse pressing the next incoming QTC would upset the numbering sequence making it difficult to ask for a resend.

During other QSOs I tried manually entering a garbled QTC so that I could keep pace with the next QTCs. Once I began manually entering I could no longer mouse press the next decoded QTC and have it automatically fill. I was forced to manually enter all remaining lines. I couldn't type fast enough to keep pace with the sender.

I could have stopped at the garbled QTC and asked for repeats, however, the problem usually presented itself in the first or second QTC.

What was I doing wrong?

73,
Mike K2MK



Re: WinKey not keying

Larry Knain
 

Interesting. It has always worked in Classic (5 years at least) and works on my home system NL+. Perhaps just lucky. I don’t know if it would have worked on the laptop if I hadn’t tried the W3YY CW scheme. I hadn’t tried the W3YY CW scheme on the home system which might have “broken” it as well. In light of your comment I would have guessed that the initial configuration of NL+ should have not worked on the home system. It did not inherit from Classic in my case. NL+ has been running since its initial release on the home system. Obviously some different code paths.
 
73, Larry  W6NWS
 

Sent: Monday, November 16, 2015 11:12 AM
Subject: Re: [N1MMLoggerplus] WinKey not keying
 
 

On 11/16/2015 08:59 AM, 'Larry' w6nws@... [N1MMLoggerplus] wrote:
> WinKey USB (ver 23)
> Win7 64 bit
> NL+ 1.0.5295.0 (SO1V)
> K3
> At home I use a desktop computer with WKUSB (CW and PTT) and a W3YY
> interface (RTTY and PTT). It works very well (a few thousand CW QSOs and
> a few thousand RTTY QSOs). The PTT outputs are in parallel.
> When I travel I use a laptop. I take the WKUSB and a RigBlaster Plus.
> The RB+ died so I was resetting for the W3YY interface instead of the
> RB+.Other than different port numbers the configuration was the same as
> the home setup. RTTY and PSK worked OK. I did not try CW. Instead I
> thought I would try the W3YY CW circuit to see if I could reduce my
> travel load by one box. Well, the W3YY setup for CW sort of worked –
> sometimes. (I am not sure what the problems were as there seemed to be
> multiple problems - not a circuit failure.) Rather than spend more time
> on it I reconfigured back to WinKey. I have always run WK with the
> default configuration in the Configurer. I should point out that the key
> 1 out of my WKUSB has not worked in years so I always use key 2 out.

Fix your Winkey first. In SO1V, it will always try to talk on key output
1. If you are really desperate, then configure for SO2R, with radio 1 as
a manual radio, and radio 2 as your usual radio. With enough tweaking,
you might get the Winkey talking on key output 2.

73,
Steve, N2IC


Re: WAE frustration when receiving QTCs

K2MK@...
 

Hi Goetz,

Then what we need is a SKIP button. Press the SKIP button and the entry is filled in with dummy information or it is left blank. Then pressing the next QTC in the decode window enters the data where it should go. At the end of the transmission we would only have to ask for the skipped QTCs to be resent.

73,
Mike K2MK


---In N1MMLoggerplus@..., <gl-dj3iw@...> wrote :

I fully support this complaint.

A couple of us here in Germany suffered from exactly the same problem!

This problem really needs the attention of the N1MM+ crew.

 

Mike, you didn’t do anything wrong.

 

73 de Goetz DJ3IW


Re: WAE frustration when receiving QTCs

Martin Berube <ve2nmb@...>
 

I agree.  I have also experienced a situation where 2 lines were merged as my decoder didn't decode the CR properly.   That messed the receiving process big time.

I beleive that if we could send the header and all line one by one, it would be easier for the receiving station.

Also, it would be nice if the focus would be put on a specific qtc line when clicking on the proper input field.  That would have give the opportunity to clear up some of the mess.  I did that a couple of time and the info ended up in the callsign or qtc header fields.

Keep up the good work N1MM folks.  I know rebuilding a software from scratch is no easy task and we use QTC functionnality only once a year.

73, Martin  VE2NMB

2015-11-16 11:07 GMT-05:00 'GL-DJ3IW-Web' gl-dj3iw@... [N1MMLoggerplus] <N1MMLoggerplus@...>:

 

I fully support this complaint.

A couple of us here in Germany suffered from exactly the same problem!

This problem really needs the attention of the N1MM+ crew.

 

Mike, you didn’t do anything wrong.

 

73 de Goetz DJ3IW

 

Von: N1MMLoggerplus@... [mailto:N1MMLoggerplus@...]
Gesendet: Montag, 16. November 2015 15:24
An: N1MMLoggerplus@...
Betreff: [N1MMLoggerplus] WAE frustration when receiving QTCs

 

 

Sending QTCs was very easy. Receiving QTCs was equally easy when each line decoded properly. A QTC that was garbled during decoding sometimes could not be entered with a mouse press depending on how severely it was garbled. Mouse pressing the next incoming QTC would upset the numbering sequence making it difficult to ask for a resend.

During other QSOs I tried manually entering a garbled QTC so that I could keep pace with the next QTCs. Once I began manually entering I could no longer mouse press the next decoded QTC and have it automatically fill. I was forced to manually enter all remaining lines. I couldn't type fast enough to keep pace with the sender.

I could have stopped at the garbled QTC and asked for repeats, however, the problem usually presented itself in the first or second QTC.

What was I doing wrong?

73,
Mike K2MK

 



Re: WinKey not keying

Steve London
 

On 11/16/2015 08:59 AM, 'Larry' w6nws@arrl.net [N1MMLoggerplus] wrote:
WinKey USB (ver 23)
Win7 64 bit
NL+ 1.0.5295.0 (SO1V)
K3
At home I use a desktop computer with WKUSB (CW and PTT) and a W3YY
interface (RTTY and PTT). It works very well (a few thousand CW QSOs and
a few thousand RTTY QSOs). The PTT outputs are in parallel.
When I travel I use a laptop. I take the WKUSB and a RigBlaster Plus.
The RB+ died so I was resetting for the W3YY interface instead of the
RB+.Other than different port numbers the configuration was the same as
the home setup. RTTY and PSK worked OK. I did not try CW. Instead I
thought I would try the W3YY CW circuit to see if I could reduce my
travel load by one box. Well, the W3YY setup for CW sort of worked –
sometimes. (I am not sure what the problems were as there seemed to be
multiple problems - not a circuit failure.) Rather than spend more time
on it I reconfigured back to WinKey. I have always run WK with the
default configuration in the Configurer. I should point out that the key
1 out of my WKUSB has not worked in years so I always use key 2 out.
Fix your Winkey first. In SO1V, it will always try to talk on key output 1. If you are really desperate, then configure for SO2R, with radio 1 as a manual radio, and radio 2 as your usual radio. With enough tweaking, you might get the Winkey talking on key output 2.

73,
Steve, N2IC


Re: WAE frustration when receiving QTCs

Goetz DJ3IW
 

I fully support this complaint.

A couple of us here in Germany suffered from exactly the same problem!

This problem really needs the attention of the N1MM+ crew.

 

Mike, you didn’t do anything wrong.

 

73 de Goetz DJ3IW

 

Von: N1MMLoggerplus@... [mailto:N1MMLoggerplus@...]
Gesendet: Montag, 16. November 2015 15:24
An: N1MMLoggerplus@...
Betreff: [N1MMLoggerplus] WAE frustration when receiving QTCs

 

 

Sending QTCs was very easy. Receiving QTCs was equally easy when each line decoded properly. A QTC that was garbled during decoding sometimes could not be entered with a mouse press depending on how severely it was garbled. Mouse pressing the next incoming QTC would upset the numbering sequence making it difficult to ask for a resend.

During other QSOs I tried manually entering a garbled QTC so that I could keep pace with the next QTCs. Once I began manually entering I could no longer mouse press the next decoded QTC and have it automatically fill. I was forced to manually enter all remaining lines. I couldn't type fast enough to keep pace with the sender.

I could have stopped at the garbled QTC and asked for repeats, however, the problem usually presented itself in the first or second QTC.

What was I doing wrong?

73,
Mike K2MK

 


WinKey not keying

Larry Knain
 

WinKey USB (ver 23)
Win7 64 bit
NL+ 1.0.5295.0   (SO1V)
K3
 
At home I use a desktop computer with WKUSB (CW and PTT) and a W3YY interface (RTTY and PTT). It works very well (a few thousand CW QSOs and a few thousand RTTY QSOs). The PTT outputs are in parallel.
 
When I travel I use a laptop. I take the WKUSB and a RigBlaster Plus. The RB+ died so I was resetting for the W3YY interface instead of the RB+.Other than different port numbers the configuration was the same as the home setup. RTTY and PSK worked OK. I did not try CW. Instead I thought I would try the W3YY CW circuit to see if I could reduce my travel load by one box. Well, the W3YY setup for CW sort of worked – sometimes. (I am not sure what the problems were as there seemed to be multiple problems -  not a circuit failure.) Rather than spend more time on it I reconfigured back to WinKey. I have always run WK with the default configuration in the Configurer. I should point out that the key 1 out of my WKUSB has not worked in years so I always use key 2 out. W3YY is connected to port 4 in my case and I reconfigured port 4 back to the house system configuration. But, no keying. PTT puts the K3 in transmit. RTTY and PSK work. If I terminate NL+ and bring up WKTEST (the K1EL WinKey Test Utility) I can put the K3 in transmit and key it (configured for key 2 out). If I bring up DXLab, it too can put the K3 in transmit and key it (configured for key 2 out). I did try the CW 2 for pin 5 on the NL+ WinKey configuration but that didn’t help. Cycling through modes on NL+ did not help. (For RTTY I run EXTFSK using the W3YY interface. Port 4 is configured with DTR on, RTS as PTT. Checked for Digi and CW/Other.)
 
Perhaps this is a variation or related to an observation made by Gary AB9M under the choppy CW thread? He could run with DXLab but had issues with NL+. I have not seen choppy CW on the house system. I haven’t seen it the past on the laptop.
 
I am guessing that I have missed something about configuration of WinKey but I am too close to it to see it. Thoughts?
 
 
73, Larry  W6NWS


Re: WAE frustration when receiving QTCs

kg4wyagi
 

Hi Mike, I had all the same situations you had and then some. Don't think you were doing
anything wrong. Conditions need to be near perfect to print 10 qtcs at once. Throw in qsb and qrm
and the print gets discombobulated. When I noticed a problem (say after on the 3rd qtc) I stopped
processing and then asked for qtcs 4 thru 10 again (one at a time). I think it may be more efficient
to (send & cfm) one qso at a time, like cw & phone !!

Ed
KG4W


On 11/16/2015 10:24 AM, K2MK@... [N1MMLoggerplus] wrote:
 

Sending QTCs was very easy. Receiving QTCs was equally easy when each line decoded properly. A QTC that was garbled during decoding sometimes could not be entered with a mouse press depending on how severely it was garbled. Mouse pressing the next incoming QTC would upset the numbering sequence making it difficult to ask for a resend.

During other QSOs I tried manually entering a garbled QTC so that I could keep pace with the next QTCs. Once I began manually entering I could no longer mouse press the next decoded QTC and have it automatically fill. I was forced to manually enter all remaining lines. I couldn't type fast enough to keep pace with the sender.

I could have stopped at the garbled QTC and asked for repeats, however, the problem usually presented itself in the first or second QTC.

What was I doing wrong?

73,
Mike K2MK




Re: Bandmap data externally accessible?

Barry N1EU
 

I just wanted to add that the principal interest of mine is to use
such a system for UNassisted operation. I want to be able to "paint"
the panadapter display with stations I've already worked and then tune
for new stations via the signal traces on the panadapter display. If
I was operating assisted, I would just tune via the spots/conventional
N1MM bandmap - for cw, virtually every workable signal is already
being spotted via RBN (filtered for geographically local nodes) so
signal traces are much less useful for finding workable stations.

73, Barry N1EU

On Mon, Nov 16, 2015 at 9:43 AM, Barry N1EU <n1eu.barry@gmail.com> wrote:
Let me say up front that I am NOT a programmer.

There's been a perennial discussion among SDR users (that contest) about
implementing a bandmap overlay on top of their panadapter display. This has
once again been recently discussed on the Flex and Apache Labs forum.
Roughly speaking, the result might look something like this:
http://www.tentecwiki.org/lib/exe/fetch.php?cache=&;media=orionpan3.jpg which
is a shot of NaP3's overlaid bandmap using its internal telnet cluster
connection.

To make such a feature truly useful, the bandmap that is overlaid should
really have all the info of the Logger+ bandmap, i.e. with font indicating
worked/unworked, mults etc. I'm wondering how feasible this might be. Is
the Logger+ bandmap data currently accessible or are there talks to make it
accessible going forward, etc? Maybe I'm asking the wrong question. But a
panadapter display with an overlaid Logger+ bandmap would be killer for
contesting.

Thanks & 73,
Barry N1EU


WAE frustration when receiving QTCs

K2MK@...
 

Sending QTCs was very easy. Receiving QTCs was equally easy when each line decoded properly. A QTC that was garbled during decoding sometimes could not be entered with a mouse press depending on how severely it was garbled. Mouse pressing the next incoming QTC would upset the numbering sequence making it difficult to ask for a resend.

During other QSOs I tried manually entering a garbled QTC so that I could keep pace with the next QTCs. Once I began manually entering I could no longer mouse press the next decoded QTC and have it automatically fill. I was forced to manually enter all remaining lines. I couldn't type fast enough to keep pace with the sender.

I could have stopped at the garbled QTC and asked for repeats, however, the problem usually presented itself in the first or second QTC.

What was I doing wrong?

73,
Mike K2MK



Re: Bandmap data externally accessible?

Mark N2QT
 

Yes please...

Mark. N2QT

On Nov 16, 2015, at 9:43 AM, Barry N1EU n1eu.barry@... [N1MMLoggerplus] <N1MMLoggerplus@...> wrote:

 

Let me say up front that I am NOT a programmer.

There's been a perennial discussion among SDR users (that contest) about implementing a bandmap overlay on top of their panadapter display.  This has once again been recently discussed on the Flex and Apache Labs forum.  Roughly speaking, the result might look something like this:  http://www.tentecwiki.org/lib/exe/fetch.php?cache=&media=orionpan3.jpg which is a shot of NaP3's overlaid bandmap using its internal telnet cluster connection.

To make such a feature truly useful, the bandmap that is overlaid should really have all the info of the Logger+ bandmap, i.e. with font indicating worked/unworked, mults etc.  I'm wondering how feasible this might be.  Is the Logger+ bandmap data currently accessible or are there talks to make it accessible going forward, etc?  Maybe I'm asking the wrong question.  But a panadapter display with an overlaid Logger+ bandmap would be killer for contesting.  

Thanks & 73, 
Barry N1EU


Bandmap data externally accessible?

Barry N1EU
 

Let me say up front that I am NOT a programmer.

There's been a perennial discussion among SDR users (that contest) about implementing a bandmap overlay on top of their panadapter display.  This has once again been recently discussed on the Flex and Apache Labs forum.  Roughly speaking, the result might look something like this:  http://www.tentecwiki.org/lib/exe/fetch.php?cache=&media=orionpan3.jpg which is a shot of NaP3's overlaid bandmap using its internal telnet cluster connection.

To make such a feature truly useful, the bandmap that is overlaid should really have all the info of the Logger+ bandmap, i.e. with font indicating worked/unworked, mults etc.  I'm wondering how feasible this might be.  Is the Logger+ bandmap data currently accessible or are there talks to make it accessible going forward, etc?  Maybe I'm asking the wrong question.  But a panadapter display with an overlaid Logger+ bandmap would be killer for contesting.  

Thanks & 73, 
Barry N1EU


FW: [N1MMLoggerplus] 2Tone inserting QTC in WAE

G3YYD <g3yyd@...>
 

2Tone is allowed to be used with logging programs that are free.

 

The same applies to hardware that comes with software the software source has to be public domain for instance TinyFSK or the hardware design is in the public domain, e.g. using pFSK.

 

I provided the FSK via the COM port system which comes with a lot of warnings as it will have timing jitter that will and does cause bit errors. Hardware interfaces are in the public domain. However for a  PC with at least 4 cores the probability of an TX caused error within a contest exchange is low.

 

However microHam products hardware design and software/firmware source are not in the public domain so no interface will ever be written for those boxes.

 

To get the best TX performance then use 2Tone’s DOOK which is audio based. It provides a very accurate narrow band signal which can be used by anyone with a sound card and interface to the audio input of their rig. A couple of resistors and a lead is all that is needed.

 

It is very unfortunate that virtually all rigs (K3 excepted) transmit a very wide FSK signal when direct FSK keying is being used. This can and does cause considerable QRM to adjacent band users.

 

73 David G3YYD

 

From: N1MMLoggerplus@... [mailto:N1MMLoggerplus@...]
Sent: 16 November 2015 09:53
To: N1MMLoggerplus@...
Subject: RE: [N1MMLoggerplus] 2Tone inserting QTC in WAE

 

 

Using 2Tone in the main window could be a challenge. 2Tone does not send proper FSK to my microHam MK2R+ box and I am forced to use MMTTY in the main window, with 2Tone in RX windows.


Rudy N2WQ
---In N1MMLoggerplus@..., <rellison@...> wrote :

QTC’s cannot be clicked on in any other window but the main RX window. So clicking in an RX window it will not work.. You can make the main window use 2tone since it is doing a better job for you..

 

73 Rick N2AMG

 

From: N1MMLoggerplus@... [mailto:N1MMLoggerplus@...]
Sent: Saturday, November 14, 2015 10:43 PM
To: N1MM Logger Plus Reflector <N1MMLoggerPlus@...>
Subject: [N1MMLoggerplus] 2Tone inserting QTC in WAE

 

 

I’m running N1MM+ v1.0.5295.0 and 2Tone v 15.2a in WAE RTTY. 

 

When clicking on the QTCs from the 2Tone window: nothing happens.

From the MMTTY window: all is OK.

 

As usual, 2Tone inserts all the other regular QSO info with no problem: call, s/n, etc.  Only MMTTY will insert the QTC data.

Many times 2Tone is a better decoder than MMTTY and I rely on it.

 

Is this a feature or am I doing something wrong.

 

    73 James K1SD

< p class="MsoNormal"> 

 


Re: 2Tone inserting QTC in WAE

N2WQ
 

Using 2Tone in the main window could be a challenge. 2Tone does not send proper FSK to my microHam MK2R+ box and I am forced to use MMTTY in the main window, with 2Tone in RX windows.

Rudy N2WQ
---In N1MMLoggerplus@..., <rellison@...> wrote :

QTC’s cannot be clicked on in any other window but the main RX window. So clicking in an RX window it will not work.. You can make the main window use 2tone since it is doing a better job for you..

 

73 Rick N2AMG

 

From: N1MMLoggerplus@... [mailto:N1MMLoggerplus@...]
Sent: Saturday, November 14, 2015 10:43 PM
To: N1MM Logger Plus Reflector <N1MMLoggerPlus@...>
Subject: [N1MMLoggerplus] 2Tone inserting QTC in WAE

 

 

I’m running N1MM+ v1.0.5295.0 and 2Tone v 15.2a in WAE RTTY. 

 

When clicking on the QTCs from the 2Tone window: nothing happens.

From the MMTTY window: all is OK.

 

As usual, 2Tone inserts all the other regular QSO info with no problem: call, s/n, etc.  Only MMTTY will insert the QTC data.

Many times 2Tone is a better decoder than MMTTY and I rely on it.

 

Is this a feature or am I doing something wrong.

 

    73 James K1SD

< p class="MsoNormal"> 

 


Re: N1MM Plus and AutoHotKey

Steve London
 

Try right click, Run As Administrator. Also, your problem isn't unique. Google is your friend.

73,
Steve, N2IC

On 11/15/2015 06:47 PM, Ed Gilliland w5tm001@gmail.com [N1MMLoggerplus] wrote:
7-zip error 193