Date   
Re: Scanning feature for QCX

jjpurdum
 

I don't see scanning as useful, but I do like spectrum (and waterfall) displays and find them useful, especially during contests.

Jack, W8TEE

On Wednesday, December 18, 2019, 6:43:08 PM EST, Bill Cromwell <wrcromwell@...> wrote:


Hi,

I had and (still have) an HF radio that can scan as described. I tried
it a few times. Your questions are directly to the point. It was next to
useless and I never considered using that mode again. I know you won't
consider making the system open source and I don't even want you to do
that. There are some systems that *ARE* open source (just not from QRP
Labs). Maybe if that is important hams should buy one of those. They
might discover it is no panacea:)

73,

Bill  KU8H

On 12/18/19 4:43 AM, Hans Summers wrote:
> Hi George
>
> I'm wondering how useful it would be in practice. How long should it
> stay on each frequency? Presumably long enough that you could react,
> drop whatever you were doing, and jump on the radio to stop it from its
> scan, so you could work the station? How long is that? Configurable?
>
> I'm not saying I have time or space to put it in the QCX code
> necessarily... I am just wondering, how such features are normally
> implemented in order to be useful and practical.
>
> 73 Hans G0UPL
> http://qrp-labs.com
>
> On Wed, Dec 18, 2019 at 6:24 AM George Korper <georgekorper@...
> <mailto:georgekorper@...>> wrote:
>
>    Being a relative newcomer to the group I would like to ask if anyone
>    has suggested adding a scanning feature to the QCX. If I could press
>    a button and have
>    the QCX scan the band or a patch of the band as I listen, without
>    having to turn the encoder,
>    I could hunt and pounce while I do other things around the shack,
>    like build more QCX's.
>    The scan feature would have a start, a stop, and automatic return,
>    and use the three frequency speeds.
>    20 is awful quiet and lightly populated where I live so just hearing
>    other stations pop up would be a sign to listen around and operate.
>
>    Now I don't mind looking like a fool if this is possible already,
>    and I am missing it in the manual.
>       I think it would be a great sales feature for those of us who don't
>    want to use CAT or a computer. Hans makes the firmware and actually
>    I think this would not
>    be to difficult to add to Other. Hans if your listening, what am I
>    missing here?
>
>

--
bark less - wag more



Re: Software extensions

jjpurdum
 

I'll start collecting stuff as I can. If you have docs on your NIWire, I'd like to see it. If anyone else has related docs, please send them to me.

Jack, W8TEE

On Wednesday, December 18, 2019, 6:29:55 PM EST, jmh6@... <jmh6@...> wrote:



Hi Jack and All,

    I think a new simpler open CAT type interface is all that will really
work? Right now there is a very confusing mess of different protocols all
of which seem radio-centric rather than CAT centric.

    Since you are into writing documents, how about doing a first crack at
an 'open' CAT centric standard that we can all comment on?

    Our products used a 'simple' protocol we called NIWire that worked
pretty well, had a small software footprint and seemed to work reliably. I
doubt that it would be suitable as a 'standard', but it was simple both as
to signals on the wire and code complexity.

    Lots of fun :).


On Wed, 18 Dec 2019, jjpurdum via Groups.Io wrote:

> Arv:
>
> I agree. I know there are products out there being sold that use Open Source software, including my own. Still, I made that decision when I made it Open Source. My theory
> is that, if someone stands on my shoulders and makes something I started better for everyone, we all win. However, I do get a little miffed when someone takes something
> that is not Open Source and either sells it (M0NKA's SDR transceiver) or gives it away (my books on torent sites).
>
> I do think the CAT interface does offer a way to extend the software without making all of it Open Source. It appears that we are slowly standardizing the CAT protocol. I
> would like to see the community pull together and formalize a CAT interface. It would require support from The Big Three and that could dissolve into a pissing contest. If
> that happens, I say screw 'em and we as users form our own CAT standard interface. (If this is all Greek to you, check out http://www.plicht.de/ekki/civ/civ-p41.html for a
> simple way to specify a series of CAT commands.)
>
> For CAT to work, processors need to be on the "radio end" and the "user end" of the CAT connection. For Hans QSX, the radio end will be a processor in the STM32F4 family.
> On the user end, it could be whatever the user wants. Me? I plan on having a touch screen waterfall display that doesn't rely on a PC. It will be a self-contained SDR a la
> M0NKA or the G-90. For others, write a PC program in your favorite language that can read ASCII data from a port and do whatever you want with the data you get via CAT.
>
> All of this could be super cool stuff. I know Al and I are going to dig into it when the dust settle a bit.
>
> Jack, W8TEE
>
>
> On Wednesday, December 18, 2019, 3:45:59 PM EST, Arv Evans <arvid.evans@...> wrote:
>
>
> Jack
>
> Well-said.  You made it very clear what the pro's and con's are regarding giving away
> intellectual property versus securing said property.   Micro-controller based systems are
> particularly problematic because some of the micro-controller chips can be read back
> and copied at the bit or byte level.  The AVR is one of the micro-controller chips that
> does have fuse bits that can be used to help protect the device from being copied. 
>
> We are seeing some of this problem over on the BITX discussion group, where individuals
> have made their own junk-box variations of the hardware, modified the open-source software,
> and now seem to expect that Farhan will troubleshoot their mistakes. 
>
> Micro-processor ICs that do not have built-in copy protection have to rely on "mouse-
> traps" that use hidden code to erase or mutilate the code if it is tampered with. 
>
> Since recent trends seem to indicate that even homebrew rigs need to support some form
> of CAT control, maybe that is where the user customization needs to reside.  If there
> is an adequate set of basic functions, then maybe user code in the CAT software could
> allow those who want something else could add that feature or function?
>
> Arv
> _._
>
>
> On Wed, Dec 18, 2019 at 7:58 AM jjpurdum via Groups.Io <jjpurdum=yahoo.com@groups.io> wrote:
> Everything I've written since I retired is Open Source and, for me at least, doing so is a true dilemma. That is: Two choices, both bad. I'll bet Hans has waded
> through the same decision-making process.
>
> If you make your code Open Source, you lose control of it and it does end up being stolen, sometimes for profit. Even worse, some people will attempt to modify your
> code and, when it doesn't work, they actually have the audacity to ask you to fix it...for free! Not good...not fair.
>
> On the other hand, if you don't make it Open Source, some people think you're a Grinch because they can't make your code do exactly whatever it is they want it to
> do.  They, too, want you to add such-and-such a feature, but fail to realize there are not a lot of deaf, blind, people who only speak Latin. (The Grinch Factor, to
> me, is a myth. It's my code...you don't like it, write your own.)
>
> So, what's the answer? First of all, given what Hans has managed to stuff into a Nano, there can't be more than a few bytes left. So, my guess is that putting
> something in means taking something else out. For most of us, that means "Leave it alone." However...
>
> The QSX is going to be another beast altogether, since it will be using the STM32F4 series of microcontroller. Hans has some headroom there because of the memory
> resource depth and a faster clock. Yet, from Hans' perspective, how does he address the dilemma of lost control versus the Grinch factor? I think the best solution is
> an API--Application Programmer Interface. An API provides entry points to methods that allow you to extend the functionality of the program in much the same way that
> libraries allow you to extend the Arduino core. The downside is that it takes a lot more effort on Hans part to provide an API for us.
>
> So...what's the correct answer from everyones' standpoint? I don't have a clue.
>
> Jack, W8TEE
>
>
>
> On Wednesday, December 18, 2019, 9:23:11 AM EST, R. Tyson via Groups.Io <tysons2=btinternet.com@groups.io> wrote:
>
>
> Hi,
> As pointed out in another post I doubt there is sufficient memory left. The radio has a remarkable set of facilities and Hans has done a brilliant job on it.
>
> Someone suggested that the software should be open source... that would enable others to produce cloned versions of Hans' work - in effect he does the work and
> someone else steals it and profits from it.
>
> Tuning up and own the band is good exercise - I remember when we had to get out of our chair and walk across the room to change T.V. channels and there were only 2 or
> 3 of them.
>
> The facilities available from these little radios is amazing but there is not the infinite capacity to keep adding stuff from "wish lists".
>
> Reg              G4NFR
>
>  
>
>
>
>


Re: Software extensions

Arv Evans
 

Jack

You are probably aware of "grig" (Gnu Rig Interface).  It has been around for many years and might be a place to start with a universal CAT protocol.  Mostly it is just a simple communication link with user modules for each end. 

Arv
_-_


On Wed, Dec 18, 2019, 3:36 PM jjpurdum via Groups.Io <jjpurdum=yahoo.com@groups.io> wrote:
Arv:

I agree. I know there are products out there being sold that use Open Source software, including my own. Still, I made that decision when I made it Open Source. My theory is that, if someone stands on my shoulders and makes something I started better for everyone, we all win. However, I do get a little miffed when someone takes something that is not Open Source and either sells it (M0NKA's SDR transceiver) or gives it away (my books on torent sites).

I do think the CAT interface does offer a way to extend the software without making all of it Open Source. It appears that we are slowly standardizing the CAT protocol. I would like to see the community pull together and formalize a CAT interface. It would require support from The Big Three and that could dissolve into a pissing contest. If that happens, I say screw 'em and we as users form our own CAT standard interface. (If this is all Greek to you, check out http://www.plicht.de/ekki/civ/civ-p41.html for a simple way to specify a series of CAT commands.)

For CAT to work, processors need to be on the "radio end" and the "user end" of the CAT connection. For Hans QSX, the radio end will be a processor in the STM32F4 family. On the user end, it could be whatever the user wants. Me? I plan on having a touch screen waterfall display that doesn't rely on a PC. It will be a self-contained SDR a la M0NKA or the G-90. For others, write a PC program in your favorite language that can read ASCII data from a port and do whatever you want with the data you get via CAT.

All of this could be super cool stuff. I know Al and I are going to dig into it when the dust settle a bit.

Jack, W8TEE


On Wednesday, December 18, 2019, 3:45:59 PM EST, Arv Evans <arvid.evans@...> wrote:


Jack

Well-said.  You made it very clear what the pro's and con's are regarding giving away
intellectual property versus securing said property.   Micro-controller based systems are
particularly problematic because some of the micro-controller chips can be read back
and copied at the bit or byte level.  The AVR is one of the micro-controller chips that
does have fuse bits that can be used to help protect the device from being copied. 

We are seeing some of this problem over on the BITX discussion group, where individuals
have made their own junk-box variations of the hardware, modified the open-source software,
and now seem to expect that Farhan will troubleshoot their mistakes. 

Micro-processor ICs that do not have built-in copy protection have to rely on "mouse-
traps" that use hidden code to erase or mutilate the code if it is tampered with. 

Since recent trends seem to indicate that even homebrew rigs need to support some form
of CAT control, maybe that is where the user customization needs to reside.  If there
is an adequate set of basic functions, then maybe user code in the CAT software could
allow those who want something else could add that feature or function?

Arv
_._


On Wed, Dec 18, 2019 at 7:58 AM jjpurdum via Groups.Io <jjpurdum=yahoo.com@groups.io> wrote:
Everything I've written since I retired is Open Source and, for me at least, doing so is a true dilemma. That is: Two choices, both bad. I'll bet Hans has waded through the same decision-making process.

If you make your code Open Source, you lose control of it and it does end up being stolen, sometimes for profit. Even worse, some people will attempt to modify your code and, when it doesn't work, they actually have the audacity to ask you to fix it...for free! Not good...not fair.

On the other hand, if you don't make it Open Source, some people think you're a Grinch because they can't make your code do exactly whatever it is they want it to do.  They, too, want you to add such-and-such a feature, but fail to realize there are not a lot of deaf, blind, people who only speak Latin. (The Grinch Factor, to me, is a myth. It's my code...you don't like it, write your own.)

So, what's the answer? First of all, given what Hans has managed to stuff into a Nano, there can't be more than a few bytes left. So, my guess is that putting something in means taking something else out. For most of us, that means "Leave it alone." However...

The QSX is going to be another beast altogether, since it will be using the STM32F4 series of microcontroller. Hans has some headroom there because of the memory resource depth and a faster clock. Yet, from Hans' perspective, how does he address the dilemma of lost control versus the Grinch factor? I think the best solution is an API--Application Programmer Interface. An API provides entry points to methods that allow you to extend the functionality of the program in much the same way that libraries allow you to extend the Arduino core. The downside is that it takes a lot more effort on Hans part to provide an API for us.

So...what's the correct answer from everyones' standpoint? I don't have a clue.

Jack, W8TEE



On Wednesday, December 18, 2019, 9:23:11 AM EST, R. Tyson via Groups.Io <tysons2=btinternet.com@groups.io> wrote:


Hi,
As pointed out in another post I doubt there is sufficient memory left. The radio has a remarkable set of facilities and Hans has done a brilliant job on it.

Someone suggested that the software should be open source... that would enable others to produce cloned versions of Hans' work - in effect he does the work and someone else steals it and profits from it.

Tuning up and own the band is good exercise - I remember when we had to get out of our chair and walk across the room to change T.V. channels and there were only 2 or 3 of them.

The facilities available from these little radios is amazing but there is not the infinite capacity to keep adding stuff from "wish lists".

Reg              G4NFR

 

Re: Scanning feature for QCX

Bill Cromwell
 

Hi,

I had and (still have) an HF radio that can scan as described. I tried it a few times. Your questions are directly to the point. It was next to useless and I never considered using that mode again. I know you won't consider making the system open source and I don't even want you to do that. There are some systems that *ARE* open source (just not from QRP Labs). Maybe if that is important hams should buy one of those. They might discover it is no panacea:)

73,

Bill KU8H

On 12/18/19 4:43 AM, Hans Summers wrote:
Hi George
I'm wondering how useful it would be in practice. How long should it stay on each frequency? Presumably long enough that you could react, drop whatever you were doing, and jump on the radio to stop it from its scan, so you could work the station? How long is that? Configurable?
I'm not saying I have time or space to put it in the QCX code necessarily... I am just wondering, how such features are normally implemented in order to be useful and practical.
73 Hans G0UPL
http://qrp-labs.com
On Wed, Dec 18, 2019 at 6:24 AM George Korper <georgekorper@... <mailto:georgekorper@...>> wrote:
Being a relative newcomer to the group I would like to ask if anyone
has suggested adding a scanning feature to the QCX. If I could press
a button and have
the QCX scan the band or a patch of the band as I listen, without
having to turn the encoder,
I could hunt and pounce while I do other things around the shack,
like build more QCX's.
The scan feature would have a start, a stop, and automatic return,
and use the three frequency speeds.
20 is awful quiet and lightly populated where I live so just hearing
other stations pop up would be a sign to listen around and operate.
Now I don't mind looking like a fool if this is possible already,
and I am missing it in the manual.
 I think it would be a great sales feature for those of us who don't
want to use CAT or a computer. Hans makes the firmware and actually
I think this would not
be to difficult to add to Other. Hans if your listening, what am I
missing here?
--
bark less - wag more

Re: Software extensions

jmh6@...
 

Hi Jack and All,

I think a new simpler open CAT type interface is all that will really work? Right now there is a very confusing mess of different protocols all of which seem radio-centric rather than CAT centric.

Since you are into writing documents, how about doing a first crack at an 'open' CAT centric standard that we can all comment on?

Our products used a 'simple' protocol we called NIWire that worked pretty well, had a small software footprint and seemed to work reliably. I doubt that it would be suitable as a 'standard', but it was simple both as to signals on the wire and code complexity.

Lots of fun :).

On Wed, 18 Dec 2019, jjpurdum via Groups.Io wrote:

Arv:
I agree. I know there are products out there being sold that use Open Source software, including my own. Still, I made that decision when I made it Open Source. My theory
is that, if someone stands on my shoulders and makes something I started better for everyone, we all win. However, I do get a little miffed when someone takes something
that is not Open Source and either sells it (M0NKA's SDR transceiver) or gives it away (my books on torent sites).
I do think the CAT interface does offer a way to extend the software without making all of it Open Source. It appears that we are slowly standardizing the CAT protocol. I
would like to see the community pull together and formalize a CAT interface. It would require support from The Big Three and that could dissolve into a pissing contest. If
that happens, I say screw 'em and we as users form our own CAT standard interface. (If this is all Greek to you, check out http://www.plicht.de/ekki/civ/civ-p41.html for a
simple way to specify a series of CAT commands.)
For CAT to work, processors need to be on the "radio end" and the "user end" of the CAT connection. For Hans QSX, the radio end will be a processor in the STM32F4 family.
On the user end, it could be whatever the user wants. Me? I plan on having a touch screen waterfall display that doesn't rely on a PC. It will be a self-contained SDR a la
M0NKA or the G-90. For others, write a PC program in your favorite language that can read ASCII data from a port and do whatever you want with the data you get via CAT.
All of this could be super cool stuff. I know Al and I are going to dig into it when the dust settle a bit.
Jack, W8TEE
On Wednesday, December 18, 2019, 3:45:59 PM EST, Arv Evans <arvid.evans@...> wrote:
Jack
Well-said.  You made it very clear what the pro's and con's are regarding giving away
intellectual property versus securing said property.   Micro-controller based systems are
particularly problematic because some of the micro-controller chips can be read back
and copied at the bit or byte level.  The AVR is one of the micro-controller chips that
does have fuse bits that can be used to help protect the device from being copied. 
We are seeing some of this problem over on the BITX discussion group, where individuals
have made their own junk-box variations of the hardware, modified the open-source software,
and now seem to expect that Farhan will troubleshoot their mistakes. 
Micro-processor ICs that do not have built-in copy protection have to rely on "mouse-
traps" that use hidden code to erase or mutilate the code if it is tampered with. 
Since recent trends seem to indicate that even homebrew rigs need to support some form
of CAT control, maybe that is where the user customization needs to reside.  If there
is an adequate set of basic functions, then maybe user code in the CAT software could
allow those who want something else could add that feature or function?
Arv
_._
On Wed, Dec 18, 2019 at 7:58 AM jjpurdum via Groups.Io <jjpurdum=yahoo.com@groups.io> wrote:
Everything I've written since I retired is Open Source and, for me at least, doing so is a true dilemma. That is: Two choices, both bad. I'll bet Hans has waded
through the same decision-making process.
If you make your code Open Source, you lose control of it and it does end up being stolen, sometimes for profit. Even worse, some people will attempt to modify your
code and, when it doesn't work, they actually have the audacity to ask you to fix it...for free! Not good...not fair.
On the other hand, if you don't make it Open Source, some people think you're a Grinch because they can't make your code do exactly whatever it is they want it to
do.  They, too, want you to add such-and-such a feature, but fail to realize there are not a lot of deaf, blind, people who only speak Latin. (The Grinch Factor, to
me, is a myth. It's my code...you don't like it, write your own.)
So, what's the answer? First of all, given what Hans has managed to stuff into a Nano, there can't be more than a few bytes left. So, my guess is that putting
something in means taking something else out. For most of us, that means "Leave it alone." However...
The QSX is going to be another beast altogether, since it will be using the STM32F4 series of microcontroller. Hans has some headroom there because of the memory
resource depth and a faster clock. Yet, from Hans' perspective, how does he address the dilemma of lost control versus the Grinch factor? I think the best solution is
an API--Application Programmer Interface. An API provides entry points to methods that allow you to extend the functionality of the program in much the same way that
libraries allow you to extend the Arduino core. The downside is that it takes a lot more effort on Hans part to provide an API for us.
So...what's the correct answer from everyones' standpoint? I don't have a clue.
Jack, W8TEE
On Wednesday, December 18, 2019, 9:23:11 AM EST, R. Tyson via Groups.Io <tysons2=btinternet.com@groups.io> wrote:
Hi,
As pointed out in another post I doubt there is sufficient memory left. The radio has a remarkable set of facilities and Hans has done a brilliant job on it.
Someone suggested that the software should be open source... that would enable others to produce cloned versions of Hans' work - in effect he does the work and
someone else steals it and profits from it.
Tuning up and own the band is good exercise - I remember when we had to get out of our chair and walk across the room to change T.V. channels and there were only 2 or
3 of them.
The facilities available from these little radios is amazing but there is not the infinite capacity to keep adding stuff from "wish lists".
Reg              G4NFR
 

Software extensions

jjpurdum
 

Arv:

I agree. I know there are products out there being sold that use Open Source software, including my own. Still, I made that decision when I made it Open Source. My theory is that, if someone stands on my shoulders and makes something I started better for everyone, we all win. However, I do get a little miffed when someone takes something that is not Open Source and either sells it (M0NKA's SDR transceiver) or gives it away (my books on torent sites).

I do think the CAT interface does offer a way to extend the software without making all of it Open Source. It appears that we are slowly standardizing the CAT protocol. I would like to see the community pull together and formalize a CAT interface. It would require support from The Big Three and that could dissolve into a pissing contest. If that happens, I say screw 'em and we as users form our own CAT standard interface. (If this is all Greek to you, check out http://www.plicht.de/ekki/civ/civ-p41.html for a simple way to specify a series of CAT commands.)

For CAT to work, processors need to be on the "radio end" and the "user end" of the CAT connection. For Hans QSX, the radio end will be a processor in the STM32F4 family. On the user end, it could be whatever the user wants. Me? I plan on having a touch screen waterfall display that doesn't rely on a PC. It will be a self-contained SDR a la M0NKA or the G-90. For others, write a PC program in your favorite language that can read ASCII data from a port and do whatever you want with the data you get via CAT.

All of this could be super cool stuff. I know Al and I are going to dig into it when the dust settle a bit.

Jack, W8TEE


On Wednesday, December 18, 2019, 3:45:59 PM EST, Arv Evans <arvid.evans@...> wrote:


Jack

Well-said.  You made it very clear what the pro's and con's are regarding giving away
intellectual property versus securing said property.   Micro-controller based systems are
particularly problematic because some of the micro-controller chips can be read back
and copied at the bit or byte level.  The AVR is one of the micro-controller chips that
does have fuse bits that can be used to help protect the device from being copied. 

We are seeing some of this problem over on the BITX discussion group, where individuals
have made their own junk-box variations of the hardware, modified the open-source software,
and now seem to expect that Farhan will troubleshoot their mistakes. 

Micro-processor ICs that do not have built-in copy protection have to rely on "mouse-
traps" that use hidden code to erase or mutilate the code if it is tampered with. 

Since recent trends seem to indicate that even homebrew rigs need to support some form
of CAT control, maybe that is where the user customization needs to reside.  If there
is an adequate set of basic functions, then maybe user code in the CAT software could
allow those who want something else could add that feature or function?

Arv
_._


On Wed, Dec 18, 2019 at 7:58 AM jjpurdum via Groups.Io <jjpurdum=yahoo.com@groups.io> wrote:
Everything I've written since I retired is Open Source and, for me at least, doing so is a true dilemma. That is: Two choices, both bad. I'll bet Hans has waded through the same decision-making process.

If you make your code Open Source, you lose control of it and it does end up being stolen, sometimes for profit. Even worse, some people will attempt to modify your code and, when it doesn't work, they actually have the audacity to ask you to fix it...for free! Not good...not fair.

On the other hand, if you don't make it Open Source, some people think you're a Grinch because they can't make your code do exactly whatever it is they want it to do.  They, too, want you to add such-and-such a feature, but fail to realize there are not a lot of deaf, blind, people who only speak Latin. (The Grinch Factor, to me, is a myth. It's my code...you don't like it, write your own.)

So, what's the answer? First of all, given what Hans has managed to stuff into a Nano, there can't be more than a few bytes left. So, my guess is that putting something in means taking something else out. For most of us, that means "Leave it alone." However...

The QSX is going to be another beast altogether, since it will be using the STM32F4 series of microcontroller. Hans has some headroom there because of the memory resource depth and a faster clock. Yet, from Hans' perspective, how does he address the dilemma of lost control versus the Grinch factor? I think the best solution is an API--Application Programmer Interface. An API provides entry points to methods that allow you to extend the functionality of the program in much the same way that libraries allow you to extend the Arduino core. The downside is that it takes a lot more effort on Hans part to provide an API for us.

So...what's the correct answer from everyones' standpoint? I don't have a clue.

Jack, W8TEE



On Wednesday, December 18, 2019, 9:23:11 AM EST, R. Tyson via Groups.Io <tysons2=btinternet.com@groups.io> wrote:


Hi,
As pointed out in another post I doubt there is sufficient memory left. The radio has a remarkable set of facilities and Hans has done a brilliant job on it.

Someone suggested that the software should be open source... that would enable others to produce cloned versions of Hans' work - in effect he does the work and someone else steals it and profits from it.

Tuning up and own the band is good exercise - I remember when we had to get out of our chair and walk across the room to change T.V. channels and there were only 2 or 3 of them.

The facilities available from these little radios is amazing but there is not the infinite capacity to keep adding stuff from "wish lists".

Reg              G4NFR

 

Re: QCX Displayed Frequency vs CW Offset #qcx #manual

Dan Pflugrath
 

Hans,
Yes my calibration was off my by offset frequency of 600 Hz.  For me it is hard to make the adjustment by zero beat so I used my FT450 as a standard and set both radios to the same frequency.  I then adjusted the QCX to give the same CW note tone on both radios where I can hear the beat frequency between both radios.  This allowed me to get real close.  I checked the RBN and found that with the RBN resolution I am right on as you described with display now showing the transmit frequency on receive.  Checked it out with a contact between here in Seattle to Denver 1,000 miles with a 559 report.  Still one more check as described by Dave k0mbt below to verify the same CW note when switching from CW to CW-R.  
Thanks  73 Dan KA7GPP

Re: QCX 40m Version 4 new build problem

James Daldry W4JED
 

Hi, Wes

IC10A is a zero-gain voltage follower. Pins 1, 2, and 3 should be at exactly the same voltage. Anything else means (a) you have a bad IC10 (HIGHLY unlikely) or (b) there is no connection between pins 1 and 2. Check it on the top side with an ohmmeter. Then resolder pins 1 and 2 anyway. Maybe cover the 2 with a single "blob" of solder.

73

Jim W4JED

On 12/18/19 1:21 PM, Wesley Matthews wrote:
Alan,

Thanks for sticking with me. I checked all the parts again, re-soldered some questionable joints, and even wiggled every part on the board with a ceramic screw driver. Pin 1 on IC10, using an external DVM, is still 13v.
R21, R35 all read correct. I double checked the AF Gain pot also.

Could there be a short in T1 that might wreak havoc with audio gain?

Wes
WM7WM
--
72/73

Wes
WM7WM

Re: WSPR Data

Graham, VE3GTC
 

Walter (and Tim),

No, there is no easy way to directly get altitude and other telemetry data for these balloon from wsprnet.

This additional telemetry data is usually encoded in a second wspr transmission. These transmissions appear on wsprnet not as the usual callsign of the balloon (for example N2NXZ) but rather as a non-valid amateur radio callsign.

These telemetry frame callsigns start with a 0 (zero) or Q and the additional telemetry is encoded within. 

Details of the special wspr telemetry protocol here: https://www.qrp-labs.com/flights/s4.html#protocol

In order to decode the additional telemetry you would need to find the appropriate wspr telemetry transmissions and apply the decoding rules to that wspr data to derive the additional data.

cheers, Graham ve3gtc


On Tue, Dec 17, 2019 at 4:19 AM Walter Holmes K5WH <walterh@...> wrote:

Is there a way to get the Altitude and other data from the LightAPRS-W on WSPRnet.org?

 

Or is that only sent out via APRS?

 

Many thanks,

Walter/K5WH

Re: four state QRP

Adam
 

I built a 4SQRP Regen transceiver a few years back and still go portable with it to this day! It also has etched coils in the board. I only had to wind one toroid to allow freedom of frequently adjustment in the tickler and main coil because of its Hartley configuration.
Built correctly, there are no hand capacity effects.
I use my rig regularly from Australia. I recently had a D7 CW contact in South Korea some 7500km away on 40m, 5 watts.
Their kits really are good. Their manuals are great because they include all of the voltage test point tables and explain in detail how the circuit works rather than only just assembling it (which helps greatly in DIY fault diagnosis and repair).

VK8FEET

Re: Scanning feature for QCX

Arv Evans
 

Jack

Well-said.  You made it very clear what the pro's and con's are regarding giving away
intellectual property versus securing said property.   Micro-controller based systems are
particularly problematic because some of the micro-controller chips can be read back
and copied at the bit or byte level.  The AVR is one of the micro-controller chips that
does have fuse bits that can be used to help protect the device from being copied. 

We are seeing some of this problem over on the BITX discussion group, where individuals
have made their own junk-box variations of the hardware, modified the open-source software,
and now seem to expect that Farhan will troubleshoot their mistakes. 

Micro-processor ICs that do not have built-in copy protection have to rely on "mouse-
traps" that use hidden code to erase or mutilate the code if it is tampered with. 

Since recent trends seem to indicate that even homebrew rigs need to support some form
of CAT control, maybe that is where the user customization needs to reside.  If there
is an adequate set of basic functions, then maybe user code in the CAT software could
allow those who want something else could add that feature or function?

Arv
_._


On Wed, Dec 18, 2019 at 7:58 AM jjpurdum via Groups.Io <jjpurdum=yahoo.com@groups.io> wrote:
Everything I've written since I retired is Open Source and, for me at least, doing so is a true dilemma. That is: Two choices, both bad. I'll bet Hans has waded through the same decision-making process.

If you make your code Open Source, you lose control of it and it does end up being stolen, sometimes for profit. Even worse, some people will attempt to modify your code and, when it doesn't work, they actually have the audacity to ask you to fix it...for free! Not good...not fair.

On the other hand, if you don't make it Open Source, some people think you're a Grinch because they can't make your code do exactly whatever it is they want it to do.  They, too, want you to add such-and-such a feature, but fail to realize there are not a lot of deaf, blind, people who only speak Latin. (The Grinch Factor, to me, is a myth. It's my code...you don't like it, write your own.)

So, what's the answer? First of all, given what Hans has managed to stuff into a Nano, there can't be more than a few bytes left. So, my guess is that putting something in means taking something else out. For most of us, that means "Leave it alone." However...

The QSX is going to be another beast altogether, since it will be using the STM32F4 series of microcontroller. Hans has some headroom there because of the memory resource depth and a faster clock. Yet, from Hans' perspective, how does he address the dilemma of lost control versus the Grinch factor? I think the best solution is an API--Application Programmer Interface. An API provides entry points to methods that allow you to extend the functionality of the program in much the same way that libraries allow you to extend the Arduino core. The downside is that it takes a lot more effort on Hans part to provide an API for us.

So...what's the correct answer from everyones' standpoint? I don't have a clue.

Jack, W8TEE



On Wednesday, December 18, 2019, 9:23:11 AM EST, R. Tyson via Groups.Io <tysons2=btinternet.com@groups.io> wrote:


Hi,
As pointed out in another post I doubt there is sufficient memory left. The radio has a remarkable set of facilities and Hans has done a brilliant job on it.

Someone suggested that the software should be open source... that would enable others to produce cloned versions of Hans' work - in effect he does the work and someone else steals it and profits from it.

Tuning up and own the band is good exercise - I remember when we had to get out of our chair and walk across the room to change T.V. channels and there were only 2 or 3 of them.

The facilities available from these little radios is amazing but there is not the infinite capacity to keep adding stuff from "wish lists".

Reg              G4NFR

 

Re: What happened?.

Arv Evans
 

Dan NM3A

Hans does not make his software source code available in public domain because that would open
the door to flagrant duplication and misuse of the code.  There are methods built into the code and
in the AVR chips that can be used to block making multiple copies of his hex-code.  The hardware
obviously can be easily duplicated which would make it very easy for unscrupulous individuals to
steal the design and produce an inferior product if the proprietary software were readily available.

Some have tried to duplicate Hans` code by "reading the AVR" but this usually results in a bricked
IC and defective code files.  Remember that there are multiple ways to block software theft.  Hans
has been very gracious in providing replacement AVRs for supposedly bad microprocessors, even
when the problems were not his fault, and even when the problem was due to hardware errors
that the purchaser did not understand. 

Having said that...there is no reason you could not write your own operating system for one of
the QRP-Labs hardware boards.  You would need to establish project requirements, design your
own code, and them implement and test that design as integrated into the target hardware.  . 

Also... "bricking" an AVR is is a term usually used to indicate that the fuse bits have been set to a
configuration that does not allow any further reading, writing, or use of the built-in software.  Chips
that have been "bricked" can usually be recovered by doing a "high-voltage-write".  This procedure
is described in the AVR datasheets.  High-voltage-programming does erase all the code in the chip
without allowing that code to be read and analyzed.  This clears the microprocessor for  normal
installation of new code, possibly including a new boot loader if the AVR is to be used as an Arduino.

Arv  K7HKL
_._

QCX AGC ?

Mike
 

Has anyone fitted an agc for the qcx? istr a mod, but unable to locate it.

seasons greetings to all, 73 Mike G8NXD

Re: QCX 40m Version 4 new build problem

Alan G4ZFQ
 

Pin 1 on IC10, using an external DVM, is still 13v > Could there be a short in T1 that might wreak havoc with audio gain?
Wes,

The fault is either in IC10 or very close to it.
You say pin 1 is 13V but have not said what pins 2 & 3 read.
Is pin 2 actually connected to pin 1?

73 Alan G4ZFQ

Hans's Ergonomic Tuning

George Korper
 

All I really want is very, very simple. I want after I start the radio to press the right button and have the radio at a desired tuning rate
go up the band and press again to stop the tuning. In the 100 or even 500 hertz mode it is a lot of turning! 
When you press again it would start from the current freq. To go back to the beginning double press. 
For me that would be a practical advantage. I love the radio and it is my main radio. Just a little automation
would make it "ergonomic" In fact call it ERGONOMIC TUNING" The word Ergonomic Tuning would be in the VFO menu. 

Re: WSPR Data

Tim Wiwel
 

Walter, 
I asked the same question on another thread.  Answer is only standard WSRP packet,  power, grid and call sign. 

Tim. 

Re: QCX 40m Version 4 new build problem

Wesley Matthews
 

Alan,

Thanks for sticking with me. I checked all the parts again, re-soldered some questionable joints, and even wiggled every part on the board with a ceramic screw driver. Pin 1 on IC10, using an external DVM, is still 13v.
R21, R35 all read correct. I double checked the AF Gain pot also.

Could there be a short in T1 that might wreak havoc with audio gain?

Wes
WM7WM
--
72/73

Wes
WM7WM

Re: Scanning feature for QCX

Don, ND6T
 

George- After thinking about your original request I believe that you might want to: 1) return to the original frequency, and 2) scan only a defined number of steps. So the addition would require a wire to each of the encoder switches (up and down). This would be best handled by a simple microcontroller (like an Arduino) and a couple of isolating diodes.
No schematic. I'm not interested in building one. Like some have already said, it doesn't sound too useful to me. What I did was to put a bypass switch on the audio filter so I can hear a few KHz around my tuned frequency. That way I can monitor nearby frequencies for activity that I wouldn't notice through the narrow filter.
Now a channelized band, like 60m, is a different story. My 60m BITX scans the channels and alerts me to the infrequent activity. But the rest of the HF bands? No.
Yes, it could be integrated into the operating system of the QCX except that Hans has completely filled the existing memory available with all sorts of very exciting and useful features.
Here's another option: Write your own firmware. Jack has some excellent books that will teach you how. Only incorporate the features that you wish. Completely customize it for you. The hardware need not be touched, just re-program the controller. You can always re-load the original (or the latest) hex code from QRP Labs later. The hardware is all revealed, there is nothing hidden or special.
When you have completed your firmware project then you can make it public, of course, but I believe that you will also then appreciate the vast amount of effort that Hans has put into it and may then agree with his proprietary approach.
73, Don

Re: What happened?.

Daniel Walter
 

It may have been 'use original ic' rather than what I said. Whatever the QCX spits out, anyway.


As far as using the proper tools, boards etc; I used exactly the same boards and tools and script ( except for -c m328 vs -c m328p for the specific chip) for all the chips that I tried. 


I realize a new chip from Hans will work, but I am trying to learn how to do it so I can avoid the long shipping wait in the future. Also, I still do have a working chip that I'd like to upgrade. (I have two QCXes but 5 chips from upgrades I already bought from Hans.)
--
73, Dan  NM3A

Re: Scanning feature for QCX

George Korper
 

Thank you. Do you have a schematic? If that is the case, however adding to firmware should be a snap. As to the comment that scanning is useless, I thought so once as well. The QCX is my primary radio and I could say the same thing about the decoder. CW scanning is different because if the code is part of you it enables contacts that otherwise rely on good luck.

Hans you sell firmware chips. Just selling a separate chip with selected features at a higher price would be excellent. No decoder and a scanner for instance. That solves the problem of open source which seems a marketing decision.


On Wed, Dec 18, 2019, 8:32 AM Don, ND6T via Groups.Io <nd6t_6=yahoo.com@groups.io> wrote:
George, I should imagine that it could be accomplished by some additional hardware. Perhaps that would simply plug in. All you would need to do would be to parallel the "up" switch connection on the rotary encoder. A simple '555 timer in astable mode could do it. Add a switch to power (or de-power) the circuit and maybe a speed control if you wanted to get fancy.
73,
Don