Quisk, K2 and Softrock IF

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Quisk, K2 and Softrock IF

Chris_g3wie
I have an Elecraft K2 which I've adapted to contain a Softrock IF SDR which takes its input from the ~4915 KHz IF at the output of the mixer. I have compiled Quisk and it runs happily (after the usual messing about with USB sound systems) under Ubuntu 10.04 using the example configuration files suitable for a Softrock.

My aim is to get it to integrate more closely with the K2 using a serial port for rig control and have real TX and Rx frequencies displayed. I operate on VHF and microwave bands and the K2 has transverter support so that you can add your own dial readings with useful features such as offsets for slightly off-frequency local oscillators.

That's the good news, the slightly less good news is that

1)  the K2 moves its BFO around to accommodate changes in filter bandwidth as well as USB/LSB/CW modes.
2) the Softrock "local oscillator" is a crystal at about 4898KHz so there is an additional offset of abut 17 KHz.
3) The K2 changes the "side" of its LO injection on bands above 24MHz so I and Q will require swappiong on a per-band basis

I've looked through some of the source of Quisk and don't see any place to correct for all of these. In the quisk_hardware_K3 module, I see a fixed value of 8215 which is the if for the K3 which could be changed to 4915, possibly with a 17 further correction, but beyond that I'm uncertain how to manage the variable offsets. I feel some sort of lookup table coming on with entries per band, per mode and per filter bandwidth....

I'm not familiar with Python, my software skills end around the Fortran77 era, but I could be persuaded to learn, especially with a concrete project in mind.

Any views/suggestions welcome

Chris g3wie
Reply | Threaded
Open this post in threaded view
|

Re: Quisk, K2 and Softrock IF

ahlstromjc
Administrator
First let me apologize for the tardy response.  I thought I would be emailed on a nabble post, but I guess there is a missing setting for that.  If I seem absent, please feel free to email jahlstr at my account on gmail.

Basically you need your own quisk_hardware.py and quisk_conf.py files, both written in the Python programming language.  Python is easy to learn but powerful; start with http://docs.python.org/tutorial/.

Plan on using Python from the command prompt; for example enter "import serial" to test whether you have the Python serial module.  Enter "python quisk.py" to run Quisk and have error messages and your "print" statements (for debugging) appear on the terminal output.

You mentioned a hardware module quisk_hardware_K3.  I have no such module in my Quisk distribution, so someone else must have written it.  That is normal.  Quisk is specifically written so others can hack it to suit their own needs.  I assume your ultimate objective is to tune and operate from Quisk, and control your K2 and down-converters automatically.  That should be fairly easy.

Since the K2 is controlled by a serial port, you need the "python-serial" package.  To see how to use it, look at other hardware files using "import serial" such as my quisk/n2adr/quisk_hardware.py file.

Read through quisk_conf_defaults.py to look for useful items to add to your config file.  To add your VHF bands (for example, two meters), replace an unwanted band in bandLabels with "2M", and add a BandPlan and BandEdge for it.  I would wait to do this until after you have basic K2 code working.

Your key job is to write a new ChangeFrequency() method in your hardware file;  see quisk_hardware_model.py.  Quisk calls this when you change frequency.  Quisk tuning frequencies are +/- offsets to the VFO, and the VFO is the RF frequency at the center of the display.  Basically you write ChangeFrequency() so that when the VFO frequency changes, you set all your hardware (especially the K2) so band center is equal to VFO.  As a rough start, just set the K2 frequency to the VFO, and that will be close.  Then add additional refinements for other sources of offset.  If the VFO changes to a frequency that uses a different side for local oscillator injection, you can adjust for that too.  If you find it awkward to set the exact VFO, set the hardware's VFO as best you can and return the VFO you set.  Quisk will adapt to the value you return.

> 1)  the K2 moves its BFO around to accommodate changes in filter bandwidth

That is a well known "feature" of the K2, and there is a serial port command to query for this offset.  I don't remember what it is, so check the K2 published serial spec.

> 2) the Softrock "local oscillator" is a crystal at about 4898KHz so there is an additional offset

No problem, just include this offset in ChangeFrequency().

> 3) The K2 changes the "side" of its LO injection on bands above 24MHz so I and Q will require

Use QS.invert_spectrum(1) (or zero) to invert (or un-invert) the spectrum.

Good luck on learning Python and hacking Quisk!

73 - Jim
N2ADR
Reply | Threaded
Open this post in threaded view
|

Re: Quisk, K2 and Softrock IF

Chris_g3wie
Thanks Jim, that's interesting and thought-provoking. I hadn't realised that so much could be done without touching the main code of Quisk, I'll go and do some more reading. And yes, the python documentation site has attracted my attention.

I intend to write specifically for the K2. Reports suggest the K3 module operates ok with the K2 so I will use it as a worked example that is close to what I'll need. In the longer term, I'm planning a SDR for 10GHz so the K2 isn't needed (except for talkback to line up the dishes) and I could control the SDR from Quisk. That's a little way off yet!

I have checked the K2 KIO programmers' ref again and there is no command to return details of the if/bfo parameters. The K3 has an FI command which does this, but it's not supported on the K2. Changes in BFO frequency have the effect of modifying the ~17KHz offset from the Softrock's LO so I guess I could manually enter a table of values from the K2 calibration menus which show the BFO frequency, and then fine-adjust ChangeFrequency() on the basis of band, mode and K2 IF filter bandwidth all of which I can get from the K2. A nice little programming exercise (as if I don't have enough other projects on the go!)

Chris g3wie
Reply | Threaded
Open this post in threaded view
|

Re: Quisk, K2 and Softrock IF

ahlstromjc
Administrator
The lack of an FI command on the K2 is disappointing.  But yes, if you can find a rule for figuring out the offset, you can program it in Python.

Your 10 GHz project sounds interesting.  My transceiver project offers 960 ksps bandwidth with a chance to go twice that.  I always thought that this might be useful for finding signals at UHF and above.

My earlier post describes how to control the K2 and use Quisk as a receiver.  But then I realized you may be interested in using the K2 as the receiver and using Quisk as a pan adapter just for viewing the band.  This is also possible.  Quisk polls for frequency changes by calling ReturnFrequency() at frequent intervals.  For pan adapter use, you return the current tuning and VFO frequency (or None, None for no change) and Quisk will adapt.

73 - Jim
N2ADR
Reply | Threaded
Open this post in threaded view
|

Re: Quisk, K2 and Softrock IF

Chris_g3wie
To start with, it will be K2 as transceiver and Quisk as panadapter, though this is partly a run-up to the 10GHz design.

I have most of a satellite station built for linear transponding birds which require decent doppler correction on Tx and Rx. I'm using an old FT747+70cm transverter for Tx and the K2 + 2m transverter for Rx, and the tracking and rig tuning software is gpredict as a front end to hamlib. I've spent some time debugging the hamlib support for my variant of the 747 and also helped in the writing of a backend for the EA4TX  rotator controller. The panadapter will help me spot signals in the transponder's passband (~50KHz). I'd then like to be able to pounce on these in the panadapter, which will retune the K2 at which point gpredict will retune the FT747 to match. The wrinkle in this logic is that both quisk and gpredict/hamlib will want to control the K2:
- The quick and dirty answer is perhaps to use a serial switch and not run both programs at once and on two separate PCs.
- Possibly, as part of my additions to quisk, I might be able to adapt quisk so that I can start with quisk controlling the K2 then if I switch the serial line over to the other PC running hamlib, quisk can gracefully timeout on a command send to the K2 that receives no response and thereafter go into a listen only panadapter mode where it monitors where the K2 is tuned but doesn't attempt to tune it.
- Or, I could get quisk to talk to hamlib which listens on a socket for rig control commands, that's how gpredict does it. If I can persuade quisk and gpredict not to fight, I might run everything on one PC and lose the serial switch

That sort of logic would, in part, be reusable for 10GHz where you can have a similar spotting problem if using a LO that's not locked to a reference and hence is 10s of kHz off frequency. The standard LO uses a crystal on 108MHz multiplied by 96 = 10368. A 1ppm error at 108MHz is 108Hz, or 10+KHz at 10GHz, so finding your QSO contact without a panadapter is hard!

Just another goal! I'll be starting (very) simple first. I've a lot to learn

73
Chris G3WIE
Reply | Threaded
Open this post in threaded view
|

Re: Quisk, K2 and Softrock IF

ahlstromjc
Administrator
Hi,

It seems that you have invested a lot of time in hamlib, so I think the focus should be getting Quisk to talk to hamlib.  You mentioned that hamlib listens on a socket.  It is very easy to write socket code in Python.  Since Quisk is the pan adapter, it is mostly passive; it just shows a piece of spectrum that was tuned by hamlib.  So write Python code within your Quisk hardware file that sends a packet to hamlib's socket requesting a frequency change when you click on a signal in Quisk.  Apart from that, Quisk has no control function.

Since you need integrated tx/rx, I don't think trying to run on two PC's or switching serial ports is a good idea.  If I were writing this from scratch, I would just write it all in Python within Quisk.  But that is my prejudice.

73 and good luck
Jim N2ADR
Reply | Threaded
Open this post in threaded view
|

Re: Quisk, K2 and Softrock IF

Chris_g3wie
On Fri, 2010-12-10 at 07:02 -0800, ahlstromjc [via quisk] wrote:
> Hi,
> It seems that you have invested a lot of time in hamlib, so I think
> the focus should be getting Quisk to talk to hamlib.

Hi Jim

I'm talking with the hamlib folks at the moment, partly regarding how to
get hamlib to do what's necessary to keep quisk happy, and partly to
help with testing of the K2 hamlib backend. Hence I've been quiet in the
quisk area.

>   You mentioned that hamlib listens on a socket.  It is very easy to
> write socket code in Python.  Since Quisk is the pan adapter, it is
> mostly passive; it just shows a piece of spectrum that was tuned by
> hamlib.  So write Python code within your Quisk hardware file that
> sends a packet to hamlib's socket requesting a frequency change when
> you click on a signal in Quisk.  Apart from that, Quisk has no control
> function.
>

Unreasonable as ever, I'd like dual control of the K2 from quisk and
gpredict, but that could be in phase 2.

A hardware file that talks to the hamlib socket is my aim as this will
immediately give a wider range of rig owners access to quisk. I may get
there via the serial port route, learning by adapting the current K3
hardware file, or I may have to do both (see below)

Reading the K2 programmer's reference, I have discovered that it is
possible to effectively operate the front panel using the SW command
which simulates button presses. Using a terminal emulator, I have
navigated through the menus to CAL FIL and successfully read back the
BFO frequency. This means that I should be able to correct the quisk
display for the effect of changing BFO frequencies. However, the only
way to use the SW command in hamlib is to use the "raw" command transfer
(w command), and thus far I have not been able to make this work across
the socket, only with a direct serial connection.

As this data won't change unless you re-calibrate the K2, I could use a
separate program (Python of course!) to write it into a file as a
one-off operation, then access that file from the quisk hardware file.
I'm currently considering if there's anything else I require that isn't
supported by hamlib, which might be added to that file.

I'm also working through the Python tutorials which is blowing away a
lot of cobwebs in my FORTRAN brain.


> Since you need integrated tx/rx, I don't think trying to run on two
> PC's or switching serial ports is a good idea.  If I were writing this
> from scratch, I would just write it all in Python within Quisk.  But
> that is my prejudice.
>
I'm about to ask the developer of gpredict how his software will react
in detail to competition on the socket. Apart from possible collisions
on the socket itself which should just produce a timeout which is
recoverable, I don't know if gpredict can handle having the K2's
frequency changed while it's not looking.

I think the pieces are starting to fall into place. I can probably
initially circumvent the contention issue by choosing a sensible way of
operating the station. For example, I could (perhaps) disengage
gpredict's control of the K2 while I look for stations on quisk and make
K2 changes: mode, frequency, and filter bandwidth. Once I have found a
station, put quisk into completely passive mode (no socket calls) and
engage gpredict's radio control. The qso would walk across the
panadapter display with the doppler but that wouldn't matter.


> 73 and good luck
> Jim N2ADR

May well be needing it

73  Chris G3WIE

Reply | Threaded
Open this post in threaded view
|

Re: Quisk, K2 and Softrock IF

Leigh L. Klotz Jr WA5ZNU
Administrator
I don't see any advantage to using hamlib for the k2.
The K2 and K3 control codes are almost identical.

The K3 package I wrote in python can do everything that hamlib can do, and it's parameterized with definition files are mirror the rig.xml format used by fldigi (which can use rigxml or hamlib).  So the k3 python backend is a partial implementation of the rigxml format.

Hamlib is very slow to update their code; until fldigi started pushing on it, they were even slower.  If you need changes made, you'll be stuck for years waiting for hamlib to get pushed out to the various distros. 

Leigh/WA5ZNU

On 12/10/2010 08:19 AM, Chris_g3wie [via quisk] wrote:
On Fri, 2010-12-10 at 07:02 -0800, ahlstromjc [via quisk] wrote:
> Hi,
> It seems that you have invested a lot of time in hamlib, so I think
> the focus should be getting Quisk to talk to hamlib.

Hi Jim

I'm talking with the hamlib folks at the moment, partly regarding how to
get hamlib to do what's necessary to keep quisk happy, and partly to
help with testing of the K2 hamlib backend. Hence I've been quiet in the
quisk area.

>   You mentioned that hamlib listens on a socket.  It is very easy to
> write socket code in Python.  Since Quisk is the pan adapter, it is
> mostly passive; it just shows a piece of spectrum that was tuned by
> hamlib.  So write Python code within your Quisk hardware file that
> sends a packet to hamlib's socket requesting a frequency change when
> you click on a signal in Quisk.  Apart from that, Quisk has no control
> function.
>

Unreasonable as ever, I'd like dual control of the K2 from quisk and
gpredict, but that could be in phase 2.

A hardware file that talks to the hamlib socket is my aim as this will
immediately give a wider range of rig owners access to quisk. I may get
there via the serial port route, learning by adapting the current K3
hardware file, or I may have to do both (see below)

Reading the K2 programmer's reference, I have discovered that it is
possible to effectively operate the front panel using the SW command
which simulates button presses. Using a terminal emulator, I have
navigated through the menus to CAL FIL and successfully read back the
BFO frequency. This means that I should be able to correct the quisk
display for the effect of changing BFO frequencies. However, the only
way to use the SW command in hamlib is to use the "raw" command transfer
(w command), and thus far I have not been able to make this work across
the socket, only with a direct serial connection.

As this data won't change unless you re-calibrate the K2, I could use a
separate program (Python of course!) to write it into a file as a
one-off operation, then access that file from the quisk hardware file.
I'm currently considering if there's anything else I require that isn't
supported by hamlib, which might be added to that file.

I'm also working through the Python tutorials which is blowing away a
lot of cobwebs in my FORTRAN brain.


> Since you need integrated tx/rx, I don't think trying to run on two
> PC's or switching serial ports is a good idea.  If I were writing this
> from scratch, I would just write it all in Python within Quisk.  But
> that is my prejudice.
>
I'm about to ask the developer of gpredict how his software will react
in detail to competition on the socket. Apart from possible collisions
on the socket itself which should just produce a timeout which is
recoverable, I don't know if gpredict can handle having the K2's
frequency changed while it's not looking.

I think the pieces are starting to fall into place. I can probably
initially circumvent the contention issue by choosing a sensible way of
operating the station. For example, I could (perhaps) disengage
gpredict's control of the K2 while I look for stations on quisk and make
K2 changes: mode, frequency, and filter bandwidth. Once I have found a
station, put quisk into completely passive mode (no socket calls) and
engage gpredict's radio control. The qso would walk across the
panadapter display with the doppler but that wouldn't matter.


> 73 and good luck
> Jim N2ADR

May well be needing it

73  Chris G3WIE




View message @ http://quisk.973856.n3.nabble.com/Quisk-K2-and-Softrock-IF-tp1967712p2064372.html
To start a new topic under Quisk Panadapter, email [hidden email]
To unsubscribe from Quisk Panadapter, click here.

Reply | Threaded
Open this post in threaded view
|

Re: Quisk, K2 and Softrock IF

Chris_g3wie
On Fri, 2010-12-10 at 08:24 -0800, Leigh L. Klotz Jr WA5ZNU [via quisk]
wrote:

Hi Leigh

Thanks for your reply. I had been wanting to correspond to record my
thanks for your K2/3 package for quisk, but you leave no email trail...

> I don't see any advantage to using hamlib for the k2.
> The K2 and K3 control codes are almost identical.
>
> The K3 package I wrote in python can do everything that hamlib can do,
> and it's parameterized with definition files are mirror the rig.xml
> format used by fldigi (which can use rigxml or hamlib).  So the k3
> python backend is a partial implementation of the rigxml format.
>
There is inevitably more opportunity to make special-to-type support
more comprehensive than a generalized approach such as hamlib, and it's
likely that I will have to implement some specialised support myself.
See the previous discussions of the K2 BFO frequency change problem
which the K3 does not suffer/has the FI command to keep track of. Hence
your K3 package will be the source and inspiration for much of what I
do, and I am grateful for your work here.

To summarise my previous posts, my reasons for the hamlib route are:

- it makes quisk widely available (albeit in a non-specialised way).
I've not found any other linux sdr which worked as well/as easily.
- I will be running quisk at the same time as gpredict to track
satellites. gpredict uses hamlib via its socket interface for antenna
tracking and control of separate rigs for uplink (FT-747) and
downlink(K2). Hence that interface is the only access to the K2 while I
am tracking

> Hamlib is very slow to update their code; until fldigi started pushing
> on it, they were even slower.  If you need changes made, you'll be
> stuck for years waiting for hamlib to get pushed out to the various
> distros.  
>
Perhaps you are a little out of date with hamlib's progress? I've been
involved in the hamlib project over just the last 12 months as a
non-developer who could offer only to test and debug. In that time, I've
requested and seen updates delivered for: a bugfix for the antique
FT-747GX I have which had a non-standard CAT protocol; a completely new
backend written for the EA4TX rotator controller; and an updated K2
backend (in progress as I write). Afaik, there are just two principal
developers and a bunch of occasional helpers effectively supporting
dozens of rigs and rotators. Looking at the Sourceforge d/l page, major
releases appear about every six months and packages are quickly
available for *buntu via a PPA. The September release (1.2.12) is
presently in Ubuntu 10.10, Fedora 13/14, and Debian unstable.

73  Chris G3WIE

Reply | Threaded
Open this post in threaded view
|

Re: Quisk, K2 and Softrock IF

Leigh L. Klotz Jr WA5ZNU
Administrator
Hi Chris!


On 12/11/2010 07:10 AM, Chris_g3wie [via quisk] wrote:
On Fri, 2010-12-10 at 08:24 -0800, Leigh L. Klotz Jr WA5ZNU [via quisk]
wrote:

Hi Leigh

Thanks for your reply. I had been wanting to correspond to record my
thanks for your K2/3 package for quisk, but you leave no email trail...

I'm not sure what this means but perhaps Nabble is "helping" us.  My ham email address is [hidden email].

> I don't see any advantage to using hamlib for the k2.
> The K2 and K3 control codes are almost identical.
>
> The K3 package I wrote in python can do everything that hamlib can do,
> and it's parameterized with definition files are mirror the rig.xml
> format used by fldigi (which can use rigxml or hamlib).  So the k3
> python backend is a partial implementation of the rigxml format.
>
There is inevitably more opportunity to make special-to-type support
more comprehensive than a generalized approach such as hamlib, and it's
likely that I will have to implement some specialised support myself.
See the previous discussions of the K2 BFO frequency change problem
which the K3 does not suffer/has the FI command to keep track of. Hence
your K3 package will be the source and inspiration for much of what I
do, and I am grateful for your work here.

I'm one of the authors of fldigi, and we support hamlib and another generalized package called rigxml.
Rigxml uses text-based configuration files to control the rig control. It can't support every strange old rig, but it does a good job of supporting the RS232 and other text-command based rigs that are available now and in the future. hamlibs main claim to fame for support is its ability through bespoke C code to handle the delicate timing nature of some of the older rigs, which of course hams being hams, we'll be using well into the next century.

I don't think that a hamlib integration is a bad idea, but I don't think it's the best route to a K2 integration.  So, I agree with your at least 50%!

Leigh/WA5ZNU

To summarise my previous posts, my reasons for the hamlib route are:

- it makes quisk widely available (albeit in a non-specialised way).
I've not found any other linux sdr which worked as well/as easily.
- I will be running quisk at the same time as gpredict to track
satellites. gpredict uses hamlib via its socket interface for antenna
tracking and control of separate rigs for uplink (FT-747) and
downlink(K2). Hence that interface is the only access to the K2 while I
am tracking

> Hamlib is very slow to update their code; until fldigi started pushing
> on it, they were even slower.  If you need changes made, you'll be
> stuck for years waiting for hamlib to get pushed out to the various
> distros.  
>
Perhaps you are a little out of date with hamlib's progress? I've been
involved in the hamlib project over just the last 12 months as a
non-developer who could offer only to test and debug. In that time, I've
requested and seen updates delivered for: a bugfix for the antique
FT-747GX I have which had a non-standard CAT protocol; a completely new
backend written for the EA4TX rotator controller; and an updated K2
backend (in progress as I write). Afaik, there are just two principal
developers and a bunch of occasional helpers effectively supporting
dozens of rigs and rotators. Looking at the Sourceforge d/l page, major
releases appear about every six months and packages are quickly
available for *buntu via a PPA. The September release (1.2.12) is
presently in Ubuntu 10.10, Fedora 13/14, and Debian unstable.

73  Chris G3WIE




View message @ http://quisk.973856.n3.nabble.com/Quisk-K2-and-Softrock-IF-tp1967712p2069132.html
To start a new topic under Quisk Panadapter, email [hidden email]
To unsubscribe from Quisk Panadapter, click here.

Reply | Threaded
Open this post in threaded view
|

Re: Quisk, K2 and Softrock IF

Chris_g3wie
Hi Leigh

> I'm not sure what this means but perhaps Nabble is "helping" us.  My
> ham email address is [hidden email].

What I meant was, I'd been looking through your website and your other
appearances on the web and you not found a way of contacting you. I'd
not registered the hidden email feature on nabble

> I'm one of the authors of fldigi, and we support hamlib and another
> generalized package called rigxml.
> Rigxml uses text-based configuration files to control the rig control.
> It can't support every strange old rig, but it does a good job of
> supporting the RS232 and other text-command based rigs that are
> available now and in the future. hamlibs main claim to fame for
> support is its ability through bespoke C code to handle the delicate
> timing nature of some of the older rigs, which of course hams being
> hams, we'll be using well into the next century.
>
My FT-747 is definitely in that category. Its CPU is so limited that you
have to byte reverse the binary CAT command strings you send it,
presumably as it only has half the stack instructions it should. I spent
ages with a scope reverse engineering the CAT timing on my particular
rig whose timing and return string length turned out to be completely at
odds with the spec ...

> I don't think that a hamlib integration is a bad idea, but I don't
> think it's the best route to a K2 integration.  So, I agree with your
> at least 50%!
I agree! With my satellite application I'm in the 80/20 or "sometimes
good is good enough" area. I also work the VHF bands and HF/QRP, and a
tighter integration here is going to be a must

btw, I saw your posts re the EMU-0202 USB sound interface working at
96ksps on linux. I'm going to get something better than my current
SBLive which does seem to perform at 96k, do you know if the EMU support
is fully in the kernel/ALSA now?

73  Chris G3WIE

Reply | Threaded
Open this post in threaded view
|

Re: Quisk, K2 and Softrock IF

Leigh L. Klotz Jr WA5ZNU
Administrator
On 12/12/2010 02:08 AM, Chris_g3wie [via quisk] wrote:
> Hi Leigh
>
> > I'm not sure what this means but perhaps Nabble is "helping" us.  My
> > ham email address is [hidden email].
>
> What I meant was, I'd been looking through your website and your other
> appearances on the web and you not found a way of contacting you. I'd
> not registered the hidden email feature on nabble
Hi Chris! Thanks for the report.
QRZ has a good address for me as does the typical [hidden email].
I guess I'm used to being on the ham mailing lists where people
generally find me by the mail there.
But you're right, it's not on my wa5znu home page, so I've updated
http://wa5znu.org to have my address at the bottom of the page.

> btw, I saw your posts re the EMU-0202 USB sound interface working at
> 96ksps on linux. I'm going to get something better than my current
> SBLive which does seem to perform at 96k, do you know if the EMU support
> is fully in the kernel/ALSA now?
The EMU-0202 support has been in ALSA for a year now, but distros are
slow sometimes.
If you're willing to compile your own (as you do with hamlib) then it's
trivial.
Otherwise you need to check with the distribution.  I have some mild
involvement with the ham stuff on Fedora, but I can't tell you if Core
14 has the updated drivers.  Ubuntu Maverick definitely does, and Lucid
definitely doesn't.  It was in Lucid backports for a few months but then
got broken, but in Maverick it just works out of the box.  I can't
comment about Suse or any of the other smaller or ham-oriented
distributions.

I've put my quick test data here:
http://wa5znu.org/2010/11/emu-0202/

Leigh/WA5ZNU

>
> 73  Chris G3WIE

Reply | Threaded
Open this post in threaded view
|

Re: Quisk, K2 and Softrock IF

Chris_g3wie
On Sun, 2010-12-12 at 13:15 -0800, Leigh L. Klotz Jr WA5ZNU [via quisk]
wrote:

> The EMU-0202 support has been in ALSA for a year now, but distros are
> slow sometimes.
> If you're willing to compile your own (as you do with hamlib) then
> it's
> trivial.
> Otherwise you need to check with the distribution.  I have some mild
> involvement with the ham stuff on Fedora, but I can't tell you if
> Core
> 14 has the updated drivers.  Ubuntu Maverick definitely does, and
> Lucid
> definitely doesn't.  It was in Lucid backports for a few months but
> then
> got broken, but in Maverick it just works out of the box.  I can't
> comment about Suse or any of the other smaller or ham-oriented
> distributions.
>
Thanks, I'll go away and think if I want to stick with Lucid and
recompile Alsa or do the Maverick upgrade.

> I've put my quick test data here:
> http://wa5znu.org/2010/11/emu-0202/
>
Looks good! I'm still running basic tests on the K2 setup and finding
what's wrong, so not able to compare the SBLive in any detail. I've
already convinced myself to take the Softrock out of the K2 chassis
where I installed it, box it separately and do some proper isolation on
it. It introduces all sorts of birdies into the K2 and almost certainly
vice versa to judge from the signals which runs up and down the band as
you tune (without an antenna!)

73 Chris G3WIE

Reply | Threaded
Open this post in threaded view
|

Re: Quisk, K2 and Softrock IF

Leigh L. Klotz Jr WA5ZNU
Administrator
Maverick's been pretty good for me.  Occasionally I get a non-response sound system with the emu-0202 hanging somehow, but it may be a legacy of a series of upgrades.  It's definitely better than Lucid. 

I think K8ZOI has a Z10000 buffer board for the K2 that provides isolation from the softrock LO.   I had one but upgraded to the K3 before I finished the project, and sold it to another local ham.

Leigh/WA5ZNU

On 12/12/2010 02:38 PM, Chris_g3wie [via quisk] wrote:
On Sun, 2010-12-12 at 13:15 -0800, Leigh L. Klotz Jr WA5ZNU [via quisk]
wrote:

> The EMU-0202 support has been in ALSA for a year now, but distros are
> slow sometimes.
> If you're willing to compile your own (as you do with hamlib) then
> it's
> trivial.
> Otherwise you need to check with the distribution.  I have some mild
> involvement with the ham stuff on Fedora, but I can't tell you if
> Core
> 14 has the updated drivers.  Ubuntu Maverick definitely does, and
> Lucid
> definitely doesn't.  It was in Lucid backports for a few months but
> then
> got broken, but in Maverick it just works out of the box.  I can't
> comment about Suse or any of the other smaller or ham-oriented
> distributions.
>
Thanks, I'll go away and think if I want to stick with Lucid and
recompile Alsa or do the Maverick upgrade.

> I've put my quick test data here:
> http://wa5znu.org/2010/11/emu-0202/
>
Looks good! I'm still running basic tests on the K2 setup and finding
what's wrong, so not able to compare the SBLive in any detail. I've
already convinced myself to take the Softrock out of the K2 chassis
where I installed it, box it separately and do some proper isolation on
it. It introduces all sorts of birdies into the K2 and almost certainly
vice versa to judge from the signals which runs up and down the band as
you tune (without an antenna!)

73 Chris G3WIE




View message @ http://quisk.973856.n3.nabble.com/Quisk-K2-and-Softrock-IF-tp1967712p2075393.html
To start a new topic under Quisk Panadapter, email [hidden email]
To unsubscribe from Quisk Panadapter, click here.

Reply | Threaded
Open this post in threaded view
|

Re: Quisk, K2 and Softrock IF

ahlstromjc
Administrator
In reply to this post by Chris_g3wie
I don't think collisions are a problem on the socket if you are using UDP.  The packets should remain independent.  But what is the nature of your socket access?  If it is just a byte stream there is a problem.

If it helps, Quisk can be made to poll the K2 for a frequency change; for example, a change made by turning the tuning knob.  So maybe it can just react to tuning changes made by gpredict.  

Jim
N2ADR
Reply | Threaded
Open this post in threaded view
|

Re: Quisk, K2 and Softrock IF

Leigh L. Klotz Jr WA5ZNU
Administrator
In reply to this post by Chris_g3wie

I think CAL FIL BFO readings can be done only when the K2 frequency counter cable is in place, and Elecraft recommends that you remove the cable because it causes spurious emissions on 20m and above.

A calibration table might make more sense.  You can read the current filter setting and mode and then just do a lookup.

Leigh/WA5ZNU

On Dec 10, 2010 8:19 AM, "Chris_g3wie [via quisk]" <[hidden email]> wrote:
>
>
> On Fri, 2010-12-10 at 07:02 -0800, ahlstromjc [via quisk] wrote:
>> Hi,
>> It seems that you have invested a lot of time in hamlib, so I think
>> the focus should be getting Quisk to talk to hamlib.
>
> Hi Jim
>
> I'm talking with the hamlib folks at the moment, partly regarding how to
> get hamlib to do what's necessary to keep quisk happy, and partly to
> help with testing of the K2 hamlib backend. Hence I've been quiet in the
> quisk area.
>
>> You mentioned that hamlib listens on a socket. It is very easy to
>> write socket code in Python. Since Quisk is the pan adapter, it is
>> mostly passive; it just shows a piece of spectrum that was tuned by
>> hamlib. So write Python code within your Quisk hardware file that
>> sends a packet to hamlib's socket requesting a frequency change when
>> you click on a signal in Quisk. Apart from that, Quisk has no control
>> function.
>>
>
> Unreasonable as ever, I'd like dual control of the K2 from quisk and
> gpredict, but that could be in phase 2.
>
> A hardware file that talks to the hamlib socket is my aim as this will
> immediately give a wider range of rig owners access to quisk. I may get
> there via the serial port route, learning by adapting the current K3
> hardware file, or I may have to do both (see below)
>
> Reading the K2 programmer's reference, I have discovered that it is
> possible to effectively operate the front panel using the SW command
> which simulates button presses. Using a terminal emulator, I have
> navigated through the menus to CAL FIL and successfully read back the
> BFO frequency. This means that I should be able to correct the quisk
> display for the effect of changing BFO frequencies. However, the only
> way to use the SW command in hamlib is to use the "raw" command transfer
> (w command), and thus far I have not been able to make this work across
> the socket, only with a direct serial connection.
>
> As this data won't change unless you re-calibrate the K2, I could use a
> separate program (Python of course!) to write it into a file as a
> one-off operation, then access that file from the quisk hardware file.
> I'm currently considering if there's anything else I require that isn't
> supported by hamlib, which might be added to that file.
>
> I'm also working through the Python tutorials which is blowing away a
> lot of cobwebs in my FORTRAN brain.
>
>
>> Since you need integrated tx/rx, I don't think trying to run on two
>> PC's or switching serial ports is a good idea. If I were writing this
>> from scratch, I would just write it all in Python within Quisk. But
>> that is my prejudice.
>>
> I'm about to ask the developer of gpredict how his software will react
> in detail to competition on the socket. Apart from possible collisions
> on the socket itself which should just produce a timeout which is
> recoverable, I don't know if gpredict can handle having the K2's
> frequency changed while it's not looking.
>
> I think the pieces are starting to fall into place. I can probably
> initially circumvent the contention issue by choosing a sensible way of
> operating the station. For example, I could (perhaps) disengage
> gpredict's control of the K2 while I look for stations on quisk and make
> K2 changes: mode, frequency, and filter bandwidth. Once I have found a
> station, put quisk into completely passive mode (no socket calls) and
> engage gpredict's radio control. The qso would walk across the
> panadapter display with the doppler but that wouldn't matter.
>
>
>> 73 and good luck
>> Jim N2ADR
>
> May well be needing it
>
> 73 Chris G3WIE
>
>
> ______________________________________
> View message @ http://quisk.973856.n3.nabble.com/Quisk-K2-and-Softrock-IF-tp1967712p2064372.html
> To start a new topic under Quisk Panadapter, email [hidden email]
> To unsubscribe from Quisk Panadapter, visit
Reply | Threaded
Open this post in threaded view
|

Re: Quisk, K2 and Softrock IF

Leigh L. Klotz Jr WA5ZNU
Administrator
In reply to this post by Chris_g3wie

On the subject of collisions, you generally get a jumble of mixed command results and parsing errors.  One program sends FA; and from its point of view it gets back A;14060000F instead of the whole correct response.  The other program gets F000; and is equally confused.

Fldigi provides a tcp port and xml-rpc responses (not my choice, but it works).  Having a tcp arbiter makes a lot of sense.

The Windows people get by with fake serial devices and programs think they are serial devices.  I think N8LP has one for free use on Windows with his devices.

Leigh/WA5ZNU

On Dec 10, 2010 8:19 AM, "Chris_g3wie [via quisk]" <[hidden email]> wrote:
>
>
> On Fri, 2010-12-10 at 07:02 -0800, ahlstromjc [via quisk] wrote:
>> Hi,
>> It seems that you have invested a lot of time in hamlib, so I think
>> the focus should be getting Quisk to talk to hamlib.
>
> Hi Jim
>
> I'm talking with the hamlib folks at the moment, partly regarding how to
> get hamlib to do what's necessary to keep quisk happy, and partly to
> help with testing of the K2 hamlib backend. Hence I've been quiet in the
> quisk area.
>
>> You mentioned that hamlib listens on a socket. It is very easy to
>> write socket code in Python. Since Quisk is the pan adapter, it is
>> mostly passive; it just shows a piece of spectrum that was tuned by
>> hamlib. So write Python code within your Quisk hardware file that
>> sends a packet to hamlib's socket requesting a frequency change when
>> you click on a signal in Quisk. Apart from that, Quisk has no control
>> function.
>>
>
> Unreasonable as ever, I'd like dual control of the K2 from quisk and
> gpredict, but that could be in phase 2.
>
> A hardware file that talks to the hamlib socket is my aim as this will
> immediately give a wider range of rig owners access to quisk. I may get
> there via the serial port route, learning by adapting the current K3
> hardware file, or I may have to do both (see below)
>
> Reading the K2 programmer's reference, I have discovered that it is
> possible to effectively operate the front panel using the SW command
> which simulates button presses. Using a terminal emulator, I have
> navigated through the menus to CAL FIL and successfully read back the
> BFO frequency. This means that I should be able to correct the quisk
> display for the effect of changing BFO frequencies. However, the only
> way to use the SW command in hamlib is to use the "raw" command transfer
> (w command), and thus far I have not been able to make this work across
> the socket, only with a direct serial connection.
>
> As this data won't change unless you re-calibrate the K2, I could use a
> separate program (Python of course!) to write it into a file as a
> one-off operation, then access that file from the quisk hardware file.
> I'm currently considering if there's anything else I require that isn't
> supported by hamlib, which might be added to that file.
>
> I'm also working through the Python tutorials which is blowing away a
> lot of cobwebs in my FORTRAN brain.
>
>
>> Since you need integrated tx/rx, I don't think trying to run on two
>> PC's or switching serial ports is a good idea. If I were writing this
>> from scratch, I would just write it all in Python within Quisk. But
>> that is my prejudice.
>>
> I'm about to ask the developer of gpredict how his software will react
> in detail to competition on the socket. Apart from possible collisions
> on the socket itself which should just produce a timeout which is
> recoverable, I don't know if gpredict can handle having the K2's
> frequency changed while it's not looking.
>
> I think the pieces are starting to fall into place. I can probably
> initially circumvent the contention issue by choosing a sensible way of
> operating the station. For example, I could (perhaps) disengage
> gpredict's control of the K2 while I look for stations on quisk and make
> K2 changes: mode, frequency, and filter bandwidth. Once I have found a
> station, put quisk into completely passive mode (no socket calls) and
> engage gpredict's radio control. The qso would walk across the
> panadapter display with the doppler but that wouldn't matter.
>
>
>> 73 and good luck
>> Jim N2ADR
>
> May well be needing it
>
> 73 Chris G3WIE
>
>
> ______________________________________
> View message @ http://quisk.973856.n3.nabble.com/Quisk-K2-and-Softrock-IF-tp1967712p2064372.html
> To start a new topic under Quisk Panadapter, email [hidden email]
> To unsubscribe from Quisk Panadapter, visit
Reply | Threaded
Open this post in threaded view
|

Re: Quisk, K2 and Softrock IF

Leigh L. Klotz Jr WA5ZNU
Administrator
In reply to this post by ahlstromjc
>
>
> I don't think collisions are a problem on the socket if you are using
> UDP.  The packets should remain independent.  But what is the nature of
> your socket access?  If it is just a byte stream there is a problem.
>

I don't mean network collisions; I mean we can't have two processes
reading the serial port.  That is when you get partial reads.

> If it helps, Quisk can be made to poll the K2 for a frequency change; for
> example, a change made by turning the tuning knob.  So maybe it can just
> react to tuning changes made by gpredict.

gpredict and quisk can't both read the serial port at the same time.
If you have a network server then the problem becomes trivial, as I've
done with the K3 or K3 via fldigi version.

I don't think there's any need to use unreliable data packets; a
connection seems fine.

Leigh/WA5ZNU

>
> Jim
> N2ADR
> ______________________________________
> View message @
> http://quisk.973856.n3.nabble.com/Quisk-K2-and-Softrock-IF-tp1967712p2087155.html
> To start a new topic under Quisk Panadapter, email
> [hidden email]
> To unsubscribe from Quisk Panadapter, visit
>
Reply | Threaded
Open this post in threaded view
|

Re: Quisk, K2 and Softrock IF

Chris_g3wie
In reply to this post by Leigh L. Klotz Jr WA5ZNU
On Tue, 2010-12-14 at 11:41 -0800, Leigh L. Klotz Jr WA5ZNU [via quisk]
wrote:
> I think CAL FIL BFO readings can be done only when the K2 frequency
> counter cable is in place
That's correct and that's the place Elecraft recommended to leave it...

> , and Elecraft recommends that you remove the cable because it causes
> spurious emissions on 20m and above.
>
I've not heard that before, but then my model is an early one built many
years ago. I wonder if it explains why I have a few more birdies than I
would expect (even after I've shut down the Softrock)

> A calibration table might make more sense.  You can read the current
> filter setting and mode and then just do a lookup.
Agreed: my plan is to write a standalone program that read all the
hard-to-get values and writes them to a file which quisk then reads when
it starts. The values don't change unless you recalibrate the K2

Chris G3WIE

Reply | Threaded
Open this post in threaded view
|

Re: Quisk, K2 and Softrock IF

Chris_g3wie
In reply to this post by Leigh L. Klotz Jr WA5ZNU
On Tue, 2010-12-14 at 13:40 -0800, Leigh L. Klotz Jr WA5ZNU [via quisk]
wrote:

> >
> >
> > I don't think collisions are a problem on the socket if you are
> using
> > UDP.  The packets should remain independent.  But what is the nature
> of
> > your socket access?  If it is just a byte stream there is a
> problem.
> >
>
> I don't mean network collisions; I mean we can't have two processes
> reading the serial port.  That is when you get partial reads.
>
My proposed arrangement is (hope the picture get through ok)

gpredict ---
.           socket:rigctld:hamlib --- K2 serial port
quisk*------

where quisk* is quisk with my new hardware file that talks to a socket
not a serial port. gpredict does likewise, it isn't linked with hamlib.
: indicates rigctld is linked with hamlib and provides a socket to
gpredict and quisk*


I have checked Gpredict and it reacts happily to manual tuning of the K2
as it reads the VFO before doing anything else. It sounds from what Jim
says below that quisk can do the same. So at the command level both
wouldn't care what the other has done while they weren't looking. Hence
my thought was that the potential problem could be collisions on the
socket if the socket doesn't block in some way between receiving a
packet and replying. I can ask at hamlib. In any case, the best thing is
perhaps for me to write some code and try it!


> > If it helps, Quisk can be made to poll the K2 for a frequency
> change; for
> > example, a change made by turning the tuning knob.  So maybe it can
> just
> > react to tuning changes made by gpredict.
>
> gpredict and quisk can't both read the serial port at the same time.
> If you have a network server then the problem becomes trivial, as
> I've
> done with the K3 or K3 via fldigi version.
>
> I don't think there's any need to use unreliable data packets; a
> connection seems fine.
>
> Leigh/WA5ZNU
>
> >
> > Jim
> > N2ADR
> > ______________________________________
> >


12