Date   

Re: N1MM Plus and AutoHotKey

Ed Gilliland
 

Hi Steve,  Thanks for the reply.  Running as administrator didn't help but I loaded AHK on a desktop and it worked perfectly.  Laptops are a different breed...hi.

73, Ed

On 11/15/2015 20:37, Steve London n2ic@... [N1MMLoggerplus] wrote:
 

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@... [N1MMLoggerplus]
wrote:
> 7-zip error 193



Re: WAE frustration when receiving QTCs

Larry K8UT
 

Art,
 
You can turn off DI scrolling entirely. From the DI windows: >Setup >Settings >Window Scroll = non-Scrolling.
 
But you can take advantage of the scrolling by positioning your cursor in one spot and letting the scrolling advance the next entry beneath your cursor. Take a look at the WAE RTTY video to see that in action:
 
-larry (K8UT)
 

Sent: Monday, November 16, 2015 1:28 PM
Subject: Re: [N1MMLoggerplus] WAE frustration when receiving QTCs
 
 

My 2 cents.  I had similar frustrations trying to edit QTCs or their headers.  For me I would simply like the DI window to stop scrolling.  When I click the left (green bar) and it turns to yellow it does stop scrolling but only for a couple of seconds then immediately goes back to green.  I tried turning off the radio, changing the DI to non-scrolling, and turning off the sound interface all to no avail,   If it stopped scrolling, I would lose only my time re-entering/fixing QTCs without impeding the person who sent them. My bad was not turning on MMTTY logging; instead I tried to time taking screen shots of a scrolling window to edit them in the log file.  

 
For me just enable the stop scrolling by clicking the left bar until it is clicked again.  I hope that isn't too complex.

Of course, you guys did a magnificent job and it is greatly appreciated even with this grousing ;-)

73,
Art - VE3UTT / W1AJT


Re: WAE frustration when receiving QTCs

Art - VE3UTT / W1AJT
 

Of course you wouldn't stop scrolling during a QTC exchange.  I am talking about after the full RX exchange to make corrections.   You should give WAE RTTY a try.  Just my thoughts during 270 RX QTCs this year.

Art - VE3UTT


Re: Bandmap data externally accessible?

Terry Glagowski / W1TR / AFA1DI
 

I did this for N1MM Classic when the DB was MS Access…

I haven’t updated the software that does this to use the SQLite DB yet.

You need SQLite Expert Personal 3 to have a look at the N1MM+ Database

 

The software would convert N1MM log format to HRD format, but I use a custom logging software instead of HRD but use the same log format.

 

73, Terry / W1TR  :  )

 

From: N1MMLoggerplus@... [mailto:N1MMLoggerplus@...]
Sent: Monday, November 16, 2015 13:05
To: N1MMLoggerplus@...
Subject: Re: [N1MMLoggerplus] Re: Bandmap data externally accessible?

 

 

Thanks Steve!  I assume then that Logger and the SDR would each maintain their own spot database and paint their bandmap from their respective database.  Would it ever make sense for the external software to have read access to the Logger database instead of maintaining its own database?

 

73, Barry N1EU

 

On Mon, Nov 16, 2015 at 12:45 PM, Steve London n2ic@... [N1MMLoggerplus] <N1MMLoggerplus@...> wrote:

 

Technically, what you want can be done by sending UDP messages with
bandmap information to another program running on the same or different
computer. On a crowded bandmap, there could be a performance hit for
N1MM+. Don't forget, not only would we have to indicate that there is a
new call on the bandmap, but also have to indicate when a call is
removed from the bandmap. Before considering implementing this, I would
like to see a commitment from panadapter vendors to actually implement
the N1MM+ bandmap information to give users a display that is more
useful than just marking the callsigns with the blips - such as the
color-coding N1MM+ provides in the bandmap and available window to
indicate the dupe/multiplier status of the call.

73,
Steve, N2IC

On 11/16/2015 10:28 AM, Barry N1EU n1eu.barry@... [N1MMLoggerplus]
wrote:
> 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@...
> n7un.guy@...> [N1MMLoggerplus]
> <N1MMLoggerplus@... N1MMLoggerplus@...>>
> wrote:
>
> __
>
> Barry,
>
>
> Take a look at CWSkimmer at http://www.dxatlas.com/cwskimmer/
>
> Manual at:
> http://www.dxatlas.com/cwskimmer/files/skimmerintro.pdf
>
> Guy/n7un
>
>
>

 


Re: IC-7600; Mode:RTTY and AFSK?

Uwe Hermanns
 

Thank you Rich and Knut!

73 de Uwe, DL4AC


Re: IC-7600; Mode:RTTY and AFSK?

Knut Meland
 

You can work in SPLIT mode, one VFO in LSB, one in RTTY mode. It’s OK as long as you run, but not good for working S&P.
I would prefer FSK mode.
73 de Knut LA9RY


Re: IC-7600; Mode:RTTY and AFSK?

Rich Seifert
 


On Nov 16, 2015, at 10:29 AM, uwe.dl4ac@... [N1MMLoggerplus] <N1MMLoggerplus@...> wrote:

 

Hello,

I wonder, if it is possible to receive RTTY in IC-7600-Mode "RTTY" and transmit AFSK generated by N1MM+?

At the moment I am using LSB-D1 to receive and transmit AFSK via USB. Downside of this: I can't use the Twin-Passband-Filter of my IC-7600.

73 de Uwe, DL4AC



Short answer is no. If you choose AFSK as your generation method, you must use a Digital SSB mode, which cannot use the TPF. If you choose FSK for transmit, you put the radio in RTTY mode and the TPF is available.

That said, I believe MMTTY has a TPF available in software. Does it really matter whether the hardware or the software does the filtering? I’m not even sure which one is a “better” filter. That said, I use FSK on my 7600 and enable the TPF. (I use a Microkeyer-II to do the FSK generation, as this is not possible through the USB connection.)

Now with all THAT said, believe it or not, what the radio does INSIDE in RTTY/FSK mode is to use the FSK signal to generate a pure tone in the DSP, which the radio injects into the SSB chain. That is, it’s AFSK in the radio either way. The advantage of treating it like FSK externally is that there is no need to make precise audio adjustments (ALC, etc.) and no need to keep a “clean” audio path from the computer to the radio.

Rich KE1B


Re: WAE frustration when receiving QTCs

Rich Seifert
 


On Nov 16, 2015, at 10:28 AM, W1AJT@... [N1MMLoggerplus] <N1MMLoggerplus@...> wrote:

 

My 2 cents.  I had similar frustrations trying to edit QTCs or their headers.  For me I would simply like the DI window to stop scrolling.


Interesting. That’s exactly what I *DON’T* want to happen.

When you’re getting clean QTC copy (and I don’t take QTC from weak stations), each QTC scrolls up one line. All I have to do is position my cursor at the right spot (one line above the bottom of the DI screen) and click as each QTC comes in. 

I agree if QSB/QRM/etc. causes the print to corrupt in cruddy ways (particularly missing line feeds) all of the problems discussed so far crop up. Yes, there may be a better way to deal with it than the current one, but stopping the scrolling is designing for defeat, rather than optimizing for success.

Rich KE1B





Re: WAE frustration when receiving QTCs

Greg Beam
 

FWIW, I had allot of troubles with RQTC's. TQTC's seemd OK. I found it easier to just clear the boxes and re-enter from the top. I tried editing a few times, that was a bust. I also lost, for some reason, ~2.5 sets of RQTC's, it simply did not save them, why I do not know.

I was also having trouble with the DI window. I'd click the call or rpt and it would not grab it. It was rota like Gammer Lag, where I was pointing and clicking the mouse, the item seemed to not be there for the app, as if it moved but the screen had not yet updated or something. I don't know how else to describe what was happening. I did notice, that clicking on the end of the QTC line / string was much more reliable than trying to clicking the beginning of the line / string.

I was having similar issues with clicking reports without QTC's. I found it easier / more reliable to simply use the keyboard number pad and enter them manually then {ENTER} for ESM and continue on.

73's
Greg, KI7MT

On 11/16/2015 11:28, W1AJT@atolda.com [N1MMLoggerplus] wrote:
My 2 cents. I had similar frustrations trying to edit QTCs or their
headers. For me I would simply like the DI window to stop scrolling.
When I click the left (green bar) and it turns to yellow it does stop
scrolling but only for a couple of seconds then immediately goes back to
green. I tried turning off the radio, changing the DI to non-scrolling,
and turning off the sound interface all to no avail, If it stopped
scrolling, I would lose only my time re-entering/fixing QTCs without
impeding the person who sent them. My bad was not turning on MMTTY
logging; instead I tried to time taking screen shots of a scrolling
window to edit them in the log file.


For me just enable the stop scrolling by clicking the left bar until it
is clicked again. I hope that isn't too complex.

Of course, you guys did a magnificent job and it is greatly appreciated
even with this grousing ;-)

73,
Art - VE3UTT / W1AJT


IC-7600; Mode:RTTY and AFSK?

Uwe Hermanns
 

Hello,


I wonder, if it is possible to receive RTTY in IC-7600-Mode "RTTY" and transmit AFSK generated by N1MM+?

At the moment I am using LSB-D1 to receive and transmit AFSK via USB. Downside of this: I can't use the Twin-Passband-Filter of my IC-7600.


73 de Uwe, DL4AC


Re: WAE frustration when receiving QTCs

Art - VE3UTT / W1AJT
 

My 2 cents.  I had similar frustrations trying to edit QTCs or their headers.  For me I would simply like the DI window to stop scrolling.  When I click the left (green bar) and it turns to yellow it does stop scrolling but only for a couple of seconds then immediately goes back to green.  I tried turning off the radio, changing the DI to non-scrolling, and turning off the sound interface all to no avail,   If it stopped scrolling, I would lose only my time re-entering/fixing QTCs without impeding the person who sent them. My bad was not turning on MMTTY logging; instead I tried to time taking screen shots of a scrolling window to edit them in the log file.  

For me just enable the stop scrolling by clicking the left bar until it is clicked again.  I hope that isn't too complex.

Of course, you guys did a magnificent job and it is greatly appreciated even with this grousing ;-)

73,
Art - VE3UTT / W1AJT 


Re: Bandmap data externally accessible?

Fred - NA2U
 

This could also be beneficial in assisted class.

73,

Fred/NA2U

On Nov 16, 2015, at 8:44 AM, Barry N1EU n1eu.barry@gmail.com [N1MMLoggerplus] <N1MMLoggerplus@yahoogroups.com> wrote:

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

------------------------------------
Posted by: Barry N1EU <n1eu.barry@gmail.com>
------------------------------------

N1MM+ FAQ: http://n1mmplus.hamdocs.com/tiki-index.php?page=Frequently+Asked+Questions&;structure=N1MM+Logger+Documentation
------------------------------------

Yahoo Groups Links



____________________________________________________________
Citi Simplicity® Card
http://thirdpartyoffers.juno.com/TGL3165/5649fa3f2a47a7a3d5f25ma01vuc


Re: Bandmap data externally accessible?

Barry N1EU
 

Thanks Steve!  I assume then that Logger and the SDR would each maintain their own spot database and paint their bandmap from their respective database.  Would it ever make sense for the external software to have read access to the Logger database instead of maintaining its own database?

73, Barry N1EU

On Mon, Nov 16, 2015 at 12:45 PM, Steve London n2ic@... [N1MMLoggerplus] <N1MMLoggerplus@...> wrote:
 

Technically, what you want can be done by sending UDP messages with
bandmap information to another program running on the same or different
computer. On a crowded bandmap, there could be a performance hit for
N1MM+. Don't forget, not only would we have to indicate that there is a
new call on the bandmap, but also have to indicate when a call is
removed from the bandmap. Before considering implementing this, I would
like to see a commitment from panadapter vendors to actually implement
the N1MM+ bandmap information to give users a display that is more
useful than just marking the callsigns with the blips - such as the
color-coding N1MM+ provides in the bandmap and available window to
indicate the dupe/multiplier status of the call.

73,
Steve, N2IC

On 11/16/2015 10:28 AM, Barry N1EU n1eu.barry@... [N1MMLoggerplus]
wrote:
> 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@...
> n7un.guy@...> [N1MMLoggerplus]
> <N1MMLoggerplus@... N1MMLoggerplus@...>>
> wrote:
>
> __
>
> Barry,
>
>
> Take a look at CWSkimmer at http://www.dxatlas.com/cwskimmer/
>
> Manual at:
> http://www.dxatlas.com/cwskimmer/files/skimmerintro.pdf
>
> Guy/n7un
>
>
>



Re: WAE frustration when receiving QTCs

DF1LX-Peter
 

I had not many challenges with receiving QTCs - it works somehow fine.

But it would be nice for next year if:

1. Someone have such MP3 Recordings from corrupted QTC traffic to have a check with this before
2. It is difficult to follow how someone want to receive QTCs - only CNTL Z or as I did "Press F12 - for a message" -> afterwards I open QTC window with CNTL Z without sending any request.
3. Then I often must click in the EW window to set the cursor behind the call -> then I can click in MMTTY and get the QTCs - but I did not see the mentionened ERROR that it happens if nr. 1 or nr2 is corrupted - I could request 1 or 2 afterwards - but maybe my workflow is not the one everyone else use.
4. Onetime it happens, that garbled text was before the sender CALL in the qtcs - how it happens - I cannot repeat - but afterwards easy to change

Overall - it worked well in my location - but we may have a kind of MP3 pool for check this quite near to the next WAE.

Other area: It would be nice, if the "Running" QRG Spot will be deleted after 3 or 4 minutes - it would prevent the crokodiles taking the QRG from other which do Run on this qrg and it was free for thie time :)

One more: QTC traffic is used in the "RUN" evaluation - I got around RUN´s with incredible 500 Q´s per hour which is really stupid :)

And once more: The sections are not counted as mults in the available window - why it cannot be counted to see if e.g. 3 Q´s on 10m with 3 different PYx station in 3 sections - but only 1 mult is seen in the AV Window (everytime I think that e.g. 3 EA8 are only online on 10m or ... but PY1, 2 ,5 are like mults in WAE and other contest).

Last: Could it be possible to set the power  to a predefined value LOW for user, which are only working with LOW power? Would be nice if a new Log is created (I often forget it and must change it afterwards)

Greetings Peter DF1LX


Re: Bandmap data externally accessible?

Steve London
 

Technically, what you want can be done by sending UDP messages with bandmap information to another program running on the same or different computer. On a crowded bandmap, there could be a performance hit for N1MM+. Don't forget, not only would we have to indicate that there is a new call on the bandmap, but also have to indicate when a call is removed from the bandmap. Before considering implementing this, I would like to see a commitment from panadapter vendors to actually implement the N1MM+ bandmap information to give users a display that is more useful than just marking the callsigns with the blips - such as the color-coding N1MM+ provides in the bandmap and available window to indicate the dupe/multiplier status of the call.

73,
Steve, N2IC

On 11/16/2015 10:28 AM, Barry N1EU n1eu.barry@gmail.com [N1MMLoggerplus] wrote:
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@gmail.com
<mailto:n7un.guy@gmail.com> [N1MMLoggerplus]
<N1MMLoggerplus@yahoogroups.com <mailto:N1MMLoggerplus@yahoogroups.com>>
wrote:

__

Barry,


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

Manual at:
http://www.dxatlas.com/cwskimmer/files/skimmerintro.pdf

Guy/n7un



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