hamlib-developer — hamlib developers forum

[Hamlib-developer] rigctl

[<pol...@so...>]

Hi there!
when I use the "rigctl" I use this line command

rigctl -vvvv -r /dev/ttyS0 -m 105 -s 4800

to control the FT-747GX. There is no response on the tranceiver when I try any command, the only thing I see is the "CAT" signal displaying on the rig, but nothing more. Any information is sent to the rig but...??
The cable is good (tested in Window$).

73!s 

-- 
---_-_---_-___---_---_-_--- = CQ
KDE SUCKS!!!
-------------------------
Alejandro Weber LU7MGP
pol...@so...
po...@li...
lu...@qs...
Linux user number 242893
-------------------------
KDE SUCKS!!!

[Hamlib-developer] branch_ts2k: parser, menus, tests

[Dale E. E. <de...@w-...>]

Hi all,

My apologies to those that monitor the cvs-list.  I had to make several
attempts to get things in (branch_ts2k).

Anyway, the new files are in.  Anybody can play with the command
parser.  Just use:

        cvs checkout -r branch_ts2k hamlib

and the new stuff will be there.  I create ./tmp directory to make
sure cvs don't overwrite important stuff.

The tests/testcmd will run the parser.  If you have two rigs connected
try:

        model[0] = 1901; port[0]="localhost"; rig.open(model[0],
port[0]);
        model[1] = 299; port[1]="/dev/ttyS1"; rig.open(model[1],
port[1]);
        rig[0].freq = rig[1].vfo(VFO_A).freq();    // should copy
frequency!
        close(rig[0]); close(rig[1]);
        help;
        exit;

It works also for copying between VFO_A and VFO_C.  My rig won't
do this on its own so I thought this would be a very cool feature.
The grammar is ill defined and I'm writing a proper grammar that I hope
will cure some ambiguities.   Stay tuned.   :)

The ts2k_menu is only available for RIG_MODEL_TS2k which is 299.

Any comments from anybody testing the parser will be greatly
appreciated.
Don't spend too much time though as it is all changing fast (I only
started
the parser Sunday.)

73's and enjoy!

Dale
kd7eni

[Hamlib-developer] ft747.c

[<pol...@so...>]

Hi everyone!
Iam new on this list and Im interested on develop some CAT for the Yaesu FT-747.
And my first question is:
When I try to compile the ft747.c located on

/usr/src/hamlib1.1.3/yaesu/

this is what I get:

ft747.c: In function `ft747_set_freq':
ft747.c:405: warning: passing arg 1 of `write_block' makes integer from pointer without a cast
ft747.c:405: too few arguments to function `write_block'
ft747.c: In function `ft747_get_update_data':
ft747.c:785: warning: passing arg 1 of `write_block' makes integer from pointer without a cast
ft747.c:785: too few arguments to function `write_block'
ft747.c:793: warning: passing arg 1 of `read_block' makes integer from pointer without a cast
ft747.c:793: too few arguments to function `read_block'
ft747.c: In function `ft747_send_priv_cmd':
ft747.c:841: warning: passing arg 1 of `write_block' makes integer from pointer without a cast
ft747.c:841: too few arguments to function `write_block'

Why does not work?
The line command I use is this 
gcc ft747.c

Thanks! 73!!


-------------------------
Alejandro Weber LU7MGP
pol...@so...
po...@li...
lu...@qs...
Linux user number 242893
-------------------------
KDE SUCKS!!!

[Hamlib-developer] menus, command parser.

[Dale E. E. <de...@w-...>]

Hi all,

I've been doing a lot of work on my own copy of the "branch_ts2k" of
Hamlib.
My menus are now working and I have started on a very basic command
parser.

The menus are read from the rig, from one of the assigned "public"
PM's.  The
parameters aren't converted but only requires a little code to finish
up.  User's
can list menus and get/set the values.  (PM's are on some of the
Kenwood's.)

The command parser only has a few commands but it works!  Here is an
example of commands that may be used:

    model = ts2k;
    port = "/dev/ttyS1";
    open(rig, model, port);

    model[2] = dummy;
    port[2] = "/dev/null";
    open(rig[2],  model[2], port[2]);    // haven't tested dummy

    help

    exit;

Everything works as shown--except the dummy rig may cause
errors as shown.  There is no ';' for help.  All of this stuff is
*only* available for the branch_ts2k.  The port command may
be either lhs or rhs.  port[0] = port[2] actually works.  I'm using
a c/c++ style syntax and hope to have several commands working
before I commit.  Since I'm creating the syntax as I go, work is real
slow on the parser.  bison and flex are the generators I'm using.

I'll be commiting the files to CVS soon.  Let me know if you have any
questions (or complaints).  They should be there by Wednesday evening
unless I break something again.  :)  There is more stuff but I've
mentioned the biggest two.

I can easily create scripts of output if anybody's interested.  Just
ask and I'll run them.

73's

Dale
kd7eni

[Hamlib-developer] Contact Needed... / http://www.hamlib.sourceforge.net

[CyberMultilingual T. D. <rt...@cy...>]

Let us submit http://www.hamlib.sourceforge.net for FREE on Japanese search engines, German search engines, Hispanic search engines , French search engines , Chinese search engines etc.....!

After reviewing http://www.hamlib.sourceforge.net, we have noticed that your website cannot be found on foreign search engines. Could you please put me in touch with your marketing director or whoever is in charge of web promotion for your website?
As it stands Internet users searching on German search engines, French search engines, Hispanic, Portuguese, Italian, Japanese or Chinese search engines cannot find your website! In fact, it has not been optimized nor listed accordingly ....

We will show you how to reach these multilingual markets without even having to translate your website! 
International search engines submission is not about doing business with foreigners in their native language but rather bringing foreigners to your website to do business with you in English!

There are millions of foreigners who speak English but would rather use their native language to conduct a search. From the Japanese Yahoo to the German AltaVista, from the Spanish Lycos to the French Excite, get users to find your website when searching with Your Keywords in Their Mother Tongue. 

Let us submit your website on International search engines for FREE! Visit us at http://www.CyberMultilingual.com for full details!

I do believe that a website like yours deserves a better exposure to international markets and this is why I would like to introduce you to our company: CyberDifference Corp. is an international website development agency mainly specialized in multilingual search engines submission in French, German, Spanish, Portuguese, Italian, Japanese, Chinese and Korean.

You may request additional info by email at rt...@cy... or call my office to schedule a free phone consultation: 1(727) 539-6178...

Test a few markets! What will it be? The German web? The Japanese web? The French web? The choice is yours!! Let's double your Web exposure: reach "the other half of the Internet"! We will perform FREE monthly submissions for your site on foreign search engines....


Regards,


Thomas DeGroot
rt...@cy...
___________________________________________________________________
C Y B E R D I F F E R E N C E C O R P. 
2225 Nursery Rd. 6-102 
Clearwater FL 33764 
TEL:1(727) 539-6178 - FAX: 1(413) 622-3040 
http://www.CyberMultilingual.com: 
Multilingual search engine submission. 
http://www.MetaNovation.com: 
Advanced search engine promotions through mirror site marketing 
http://www.SearchEngineJungle.com: 
Search Engine Promotion Seminars.
This is not a spam: You are receiving this message because  " ham...@li... " is in our data base from a subscription to one of Cyberdifference Corp.'s international / multilingual e-marketing newsletters. If you want to opt-out and remove your records from our databases please email re...@cy... and mention "http://www.hamlib.sourceforge.net" in the subject line. We comply with every removal / opt-out requests. 

Re: [Hamlib-developer] Re: gnuradio and Hamlib

[Stephane F. <f4...@fr...>]

Quoting Matt Ettus <ma...@et...>:
> I checked out from cvs, but configure is missing.  I tried ./autogen.sh,
> but I get:
> 
> [matt@localhost hamlib]$ ./autogen.sh 
> I am going to run ./configure with no arguments - if you wish 
> to pass any to it, please specify them on the ./autogen.sh command
> line.
> /usr/bin/m4: configure.in: No such file or directory
               ^^^^^^^^^^^^
> kylix/Makefile.am:1: invalid variable `dist_sharedstate_DATA'
> autoconf: configure.in: No such file or directory
> ./autogen.sh: ./configure: No such file or directory

hmm, it seems like you have an old autoconf (like 2.13).
You can check it with "autoconf --version" and "automake --version".
autoconf must be at least 2.50 or higher, and automake at least 1.5.


> 1> It's been about 10 years since I did any RPC stuff...  How is security
> handled?  I wouldn't want to put a rig or rotator on the net only to
> have it hacked.

AFAIN, RPC security has been left in the state it was 10 years ago.
There are some session oriented management in RPC, but Hamlib does
not support it yet. This can change in the future.
Another cheap way to protect your rpc daemon is to use a tcp/udp wrapper,
that restricts acces based on client IP address.

Anyone knows how to secure RPC?

> 2> Has there been any thought/work on alternate pathways for audio/signals?  I
> guess I mean that while with my FT-1000 I might want all audio to go through 
the
> standard speaker/mike,  what happens if I want to pass rig audio through the 
PC
> soundcard for processing?  Or what if I wanted to send the audio from my  
remote
> rig over ethernet back to the point where I am operating grig over rpc?

I guess we'll be making some configuration (rig_set_conf) or "extra" parameter 
(rig_set_ext_parm) in the gnuradio backend, to tell it what the output
should be, provided it has support for it.
The difference between rig_set_conf and rig_set_ext_parm is that set_conf
can only be done before rig_open, whereas set_ext_parm can be done any time 
afterwards.
IOW, do you want to change the ouput sink dynamically while gnuradio is running?


Cheers,
Stephane

PS: I'll add support for the FT-1000 next month, after my vacation 
    in 5U (sri, not qrv).

Re: [Hamlib-developer] Re: gnuradio and Hamlib

[Matt E. <ma...@et...>]

Quoting Stephane Fillod <f4...@fr...>:

> Problem of vocabulary. When I say FI, I mean a tap, a sampled source. What
> is the best word anyway?
> About the microtune and MC4020, I'll need some specs, like the bandwidth
> of the FI (around 5MHz?) and the frequency range of the tuner.

I see.  It looks like you want the hamlib plugin to be the actual radio.  I
guess that's reasonable.

> Allright Matt, I have good news for you. I have just checked in an initial
> gnuradio backend. It does not MC4020 yet, but there're should be enough
> for you to see if I'm on the right track.

Great.  

> >From a fresh checkout, add the --with-gnuradio to autogen.sh (after
> doing chmod +x on the script). For the build to work, you'll have to put
> libgnuradio.a in the gnuradio subdirectory (sorry, libgnuradio.la is
> still not suitable for use, I'll explain you why in a future mail),
> and have gnuradio-0.3 in the same parent directory as your hamlib
> checkout. Having gnuradio installed in /usr/include and /usr/lib should
> work also. And of course, libfftw must be already installed too :)
> 
> Let me know if you encounter any build problem.
> I've provided a simple gnuradio/testgr program to be hack. Right now, it
> should display a GUI with a scope, but dies with segfault:

I checked out from cvs, but configure is missing.  I tried ./autogen.sh, but I get:

[matt@localhost hamlib]$ ./autogen.sh 
I am going to run ./configure with no arguments - if you wish 
to pass any to it, please specify them on the ./autogen.sh command line.
/usr/bin/m4: configure.in: No such file or directory
kylix/Makefile.am:1: invalid variable `dist_sharedstate_DATA'
autoconf: configure.in: No such file or directory
./autogen.sh: ./configure: No such file or directory




On 2 totally unrelated notes...   

1> It's been about 10 years since I did any RPC stuff...  How is security
handled?  I wouldn't want to put a rig or rotator on the net only to have it hacked.

2> Has there been any thought/work on alternate pathways for audio/signals?  I
guess I mean that while with my FT-1000 I might want all audio to go through the
standard speaker/mike,  what happens if I want to pass rig audio through the PC
soundcard for processing?  Or what if I wanted to send the audio from my remote
rig over ethernet back to the point where I am operating grig over rpc?

Matt

[Hamlib-developer] Last Tone/CTCSS message.

[Dale E. E. <de...@w-...>]

Stephane,

No need for you to write ts2k_get_tone(), and ts2k_get_ctcss_tone()
etc...
My version works the way the rig does and I'll have to use the stuff
that
works correctly or I won't be able to access local repeaters via Hamlib
(which I can with my version).

Thanks anyway.

Dale

Re: [Hamlib-developer] configure is missing in CVS

[John R. M. <jo...@jr...>]

On Wednesday 10 July 2002 04:43 am, Alexandru Csete wrote:
> > Any Suggestions? Can I just copy configure from the tarball?
>
> Yes, it will probably work, but you can just run the autogen.sh script,
> which will create and run the configure script for you (any arguments
> you want to pass the configure script can be passed to autogen.sh).

Thanks that did the trick :-)

-- 
John R. Marshall - Web Developer

JRM Studios - http://www.jrmstudios.com
The Hotrodding Network - http://www.hotrodding.net

[Hamlib-developer] Re: vfo_t merging into trunk.

[Dale E. E. <de...@w-...>]

Stephane,

Yes, I'm *very* aware of your most discriptive dislike of parts of the
vfo_t I've described.

My current focus is not so much convincing you as proving the concept
with working code.  I'm getting real close to what I consider a fully
functional version.  Discussions can be pointless if the proposal is
easily
shown to be flawed.  Also, a working model will support my argument
if the current Hamlib can be demonstrated to be flawed or inadequate.
Either way, a working accessible model is a must.

I was happy to hear you like at least the CALL.  It very much made
sense to me.

The individual bits of my proposed vfo_t are of *much* less concern
to me than the way the API constructs it.  The current scheme is not
extensible.  Even if *none* of my bitmasks are added, the vfo_t should
be changed.  This bears repeating.  The additional masks are not as
important to me as how the vfo_t is handled.  Of this, the RIG_SET_VFO
is all important.  If you find something better that is likewise as easy

to understand, modify, and eliminates or reduces ambiguity, I'll be
quite happy (though maybe not entirely).

Thanks again for the feedback.

73's

Dale
KD7ENI

Re: [Hamlib-developer] problem with Icom 756 Pro

[Stephane F. <f4...@fr...>]

Hi Bob!

First of all, thanks for your feedback on Hamlib.

Quoting Bob Lisbonne <bo...@li...>:
> 1) Hamlib sounds terrific, however when I installed it last night and
> tried it on my Icom 756 Pro, the results were mixed: using rigctl, I can
> get the frequency and mode. But when I try to retrieve PTT (command "t")
> or signal strength (command "l" then "STRENGTH") it gives an error. I
> would be grateful for any suggestions on how to resolve the problem, if
> possible.

okay, I would be very please to help you. But first, you'll have to help me :)
Can you send a report of rigctl with the traces turned on? Make sure
serial traces are included.

  rigctl -vvvvvv -m <xxx>

Note: all available functions on Icom 756 Pro may not be implemented yet.
      Patches are welcome..

> 2) I was able to communicate with the serial port only as root. Does
> anyone know how to get Red Hat 7.3 to allow normal users to access the
> serial port? (/dev/sttyS0)

I don't know RedHat 7.3. Looks at the file permission on the file (ls -l),
look at the group, and make sure your account is in that group,
and the group has rw- access to /dev/ttyS0.

> 3) In addition to my own programming projects, I am planning to using
> hamlib with xlog. Does anyone recommend a better x-windows logging
> program?

hey, xlog is great! I use it regularly (the beta version though).
And you're free to improve it even more.
Maybe you can find others on freshmeat or http://radio.linux.org.au

73's
Stephane

Re: [Hamlib-developer] Tone.

[Stephane F. <f4...@fr...>]

Quoting "Dale E. Edmons" <de...@w-...>:
> Tone:
> My argument is *for* adding.  My reasoning was simple: the manual
> states, "You cannot use DCS with the Tone or CTCSS functions".
> (page 36)  Even though I may independently set all three frequencies,
> I can *only* enable one.  It made sense to me, since it seemed you
> didn't want to add the variable for Tone, that we could at least split
> the two existing variables into RX/TX and *assume* that would
> suffice.

Note: I assume that for you, "Tone" is the tone encoding, not to be mistaken
with the 1750Hz tone burst.

Okay, it's not because the ts2k can enable *only* one at a time
(ie. DCS and tone/CTCSS mutually exclusive), that Hamlib API 
must be this restrictive.
Until proved wrong, current API covers the ts2k, plus the mmelter
(which supports both CTCSS and DCS at same time).
The only information missing in the caps is how "1750 tone burst",
CTCSS and DCS are eventually exclusive.

Then the side effect will be that when setting DCS for example,
it will disable CTCSS if previously set, etc.

In other words, for the ts2k, just implement set&get for ctcss_tone/ctcss_sql,
dcs_tone/dcs_sql (note that dcs_tone/dcs_sql are identical, setting one
sets the other for this rig), and set_func/get_func RIG_FUNC_TBURST.

If you don't know/see how to implement this, just let me do it.
It's breaking simple.


> ts2k.c:
> testing right now.  (I've threw a testvfo.c into tests/.  Its simple
> but fun to watch all the modes changing and is a great quick check.)

Just a reminder. You will have to convince me if you want 
*everything* of your new VFO scheme to be merged in the trunk. 

What I dislike:
- CTRL_SCAN, CTRL_SAT, etc.  irrelevant for the current API design
- the VFO_AB and such (split are not to be handled here),
  vfo_t is complex enough.

What I like though (i.e. may be merged after discussion):
- the CALL channel that can be seen as a VFO (not true on some rigs
  that can only see it as a memory channel)
- RIG_VFO_TEST macro, that tell you if it's a vfo or mem.


Cheers,
Stephane

[Hamlib-developer] Tone.

[Dale E. E. <de...@w-...>]

Stephane,

Tone:
My argument is *for* adding.  My reasoning was simple: the manual
states, "You cannot use DCS with the Tone or CTCSS functions".
(page 36)  Even though I may independently set all three frequencies,
I can *only* enable one.  It made sense to me, since it seemed you
didn't want to add the variable for Tone, that we could at least split
the two existing variables into RX/TX and *assume* that would
suffice.

But, if you'd rather, just add the tone capability.  :)  Wasn't that
what
started all of this in the first place....

ts2k.c:
I just finished rewriting major sections.  Got too complex and
code changes became buggy.  After the second attempt at a fix,
I just redesigned the whole thing.   It looks like the current stuff
will hold up a lot longer.  It'll take some work to get back to the
same or better functionality that is in branch_ts2k right now.  I'm
testing right now.  (I've threw a testvfo.c into tests/.  Its simple
but fun to watch all the modes changing and is a great quick check.)

I'd sure be nice if a bunch of Hamlib users would run out and buy
a TS-2000 so I could get live feedback on the thing.  Hi.  (Don't
know if I'd recommend the TS-2000 though.)


73's

Dale, KD7ENI

Re: [Hamlib-developer] configure is missing in CVS

[Alexandru C. <al...@vp...>]

Hi John,

On Wed, 2002-07-10 at 04:06, John R. Marshall wrote:
> Like the subject said there is no configure script in CVS.
> 
> Normaly when there is no configure I just do a "make -f Makefile.cvs" But this 
> also fails (No rule to make target `Makefile.cvs'.)
> 
> Any Suggestions? Can I just copy configure from the tarball?

Yes, it will probably work, but you can just run the autogen.sh script,
which will create and run the configure script for you (any arguments
you want to pass the configure script can be passed to autogen.sh).

Alex, OZ9AEC

> 
> 
> -- 
> John R. Marshall - Web Developer
> 
> JRM Studios - http://www.jrmstudios.com
> The Hotrodding Network - http://www.hotrodding.net
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Stuff, things, and much much more.
> http://thinkgeek.com/sf
> _______________________________________________
> Hamlib-developer mailing list
> Ham...@li...
> https://lists.sourceforge.net/lists/listinfo/hamlib-developer
> 

-- 

Re: [Hamlib-developer] problem with Icom 756 Pro

[John R. M. <jo...@jr...>]

On Tuesday 09 July 2002 06:07 pm, Bob Lisbonne wrote:
> 2) I was able to communicate with the serial port only as root. Does anyone
> know how to get Red Hat 7.3 to allow normal users to access the serial
> port? (/dev/sttyS0)

(as root)

chmod 750 /dev/sttyS0

>
> 3) In addition to my own programming projects, I am planning to using
> hamlib with xlog. Does anyone recommend a better x-windows logging program?

I'm not a ham, but take a look at http://www.kmyvrlog.org/en/start.html looks 
pretty good to me. :-)

-- 
John R. Marshall - Web Developer

JRM Studios - http://www.jrmstudios.com
The Hotrodding Network - http://www.hotrodding.net

[Hamlib-developer] configure is missing in CVS

[John R. M. <jo...@jr...>]

Like the subject said there is no configure script in CVS.

Normaly when there is no configure I just do a "make -f Makefile.cvs" But this 
also fails (No rule to make target `Makefile.cvs'.)

Any Suggestions? Can I just copy configure from the tarball?


-- 
John R. Marshall - Web Developer

JRM Studios - http://www.jrmstudios.com
The Hotrodding Network - http://www.hotrodding.net

[Hamlib-developer] problem with Icom 756 Pro

[Bob L. <bo...@li...>]

1) Hamlib sounds terrific, however when I installed it last night and tried it on my Icom 756 Pro, the results were mixed: using rigctl, I can get the frequency and mode. But when I try to retrieve PTT (command "t") or signal strength (command "l" then "STRENGTH") it gives an error. I would be grateful for any suggestions on how to resolve the problem, if possible.

2) I was able to communicate with the serial port only as root. Does anyone know how to get Red Hat 7.3 to allow normal users to access the serial port? (/dev/sttyS0)

3) In addition to my own programming projects, I am planning to using hamlib with xlog. Does anyone recommend a better x-windows logging program?

thanks,
--Bob

Re: [Hamlib-developer] CTCSS

[Stephane F. <f4...@fr...>]

Quoting "Dale E. Edmons" <de...@w-...>:

> Another concern was that Hamlib controls tone via a parameter
> call (rig_set_parm()) but CTCSS and DCS each have their own
> functions (rig_set_dcs()).  This is a confusing interface and users
> (plus at least one developer) will complain.  We should move them
> both to the same place.  Either all three are parm's or all three are
> functions.

The 1750 tone burst has to be a RIG_FUNC because it's an on/off setting.
The tone/ctcss, code/dcs could have been a RIG_LEVEL (and actually they were
at the beginning), but they were made separate calls for clarity.

Looking at rig.h, we might have to check consistency, and better specify 
function semantics. For example, about FUNC_TSQL, rig_set_ctcss_sql could have 
suffice.
But it's not that simple. Some rigs allow to turn on/off TSQL, but do NOT
allow to change the tone frequency. Right now, the (poorly documented) API
is designed this way: to activate CTCSS, one has to set the decoding tone 
frequency, and then turn function on:

  rig_set_ctcss_sql(rig, vfo, tone);
  rig_set_func(rig, vfo, RIG_FUNC_TSQL, 1);

It gives the best (IMHO) mapping for existing rigs and combination of supported
features.
Note: some rigs may have rig_set_ctcss_sql but no RIG_FUNC_TSQL, which is
okay with this design.

It's always good to have to argue, it shows loopholes. Here, it looks like a 
RIG_FUNC_TBURST is missing (in my previous idea, the 1750 would have been in 
the ctcss list, but this was a wrong design if you want to use both).

Note: Function semantics are supposed to be documented in doxygen in-source 
code comments (mainly src/rig.c). They are supposed to be the reference.
In the future, rig.c will be split and documentation augmented, especially
for all those RIG_FUNC, RIG_LEVEL, RIG_PARM, etc.

> Since CTCSS and DCS cannot be used at the same time they may
> share the same variable.  Tone on the other hand may be used at
> the same time and should have its own variable.  

Is there a reason why CTCSS and DCS cannot be used at the same time?
Is it because no rig implement it (not a reason)? or because the encodings 
would mess up each other (same frequencies) ? 
It's a bit far fetched, but the mmelter may use 1750 tone burst, tone encoding, 
CTCSS, DCS code encoding and a different DCS code for squelch, all
at the same time. Hence the actual design of the API, which covers all
the cases.

Comments?


Cheers,
Stephane

[Hamlib-developer] CTCSS

[Dale E. E. <de...@w-...>]

Nate,

Thanks.  After I RTFM yet again I finally found the part I'd been
missing.  Tone is what I transmit (usually to a repeater) and both
CTCSS and DCS are what I receive/decode.  1750Hz is an once
only burst transmitted to a repeater to open the squelch (European).

Got it.  The manual says in fine print, "You can select a tone
frequency independent of a CTCSS frequency."  So I can TX
using tone=103.5Hz and receive using CTCSS=88.5Hz.  The
1750Hz is a menu item which may be turned on/off.  This all may
seem of dubious value but I think it is primarily indended for use
with a handheld while controlling the TS2K remotely (It's nice
walking around talking on a HT through the base rig.  Kind of
like a portable phone or cell phone--bleh!)  Either that or for
cross-band repeater operation.  I've only played with it a little
but it was fun!

Another concern was that Hamlib controls tone via a parameter
call (rig_set_parm()) but CTCSS and DCS each have their own
functions (rig_set_dcs()).  This is a confusing interface and users
(plus at least one developer) will complain.  We should move them
both to the same place.  Either all three are parm's or all three are
functions.

Since CTCSS and DCS cannot be used at the same time they may
share the same variable.  Tone on the other hand may be used at
the same time and should have its own variable.  (How come I'm
always on the other side disagreeing with everyone?!)   :)

73's all.  Thanks for the information and patience!

Dale
KD7ENI

[Hamlib-developer] reduce your mercant service rates 8763yvzQ1-424BOGh7164DT-22

[<k.f...@ly...>]

DQoNCjxodG1sPg0KPGRpdiBhbGlnbj0iY2VudGVyIj4gPHN0cm9uZz48Zm9u
dCBmYWNlPSJUcmVidWNoZXQgTVMiIGNvbG9yPSIjZmYwMDAwIiBzaXplPSI2
Ij5DcmVkaXQgQ2FyZCBTaG9wcGVycyBBcmUgSGVyZSBUbyBTdGF5ITwvZm9u
dD48L3N0cm9uZz48L2Rpdj4NCjxkaXYgYWxpZ249ImNlbnRlciI+PHN0cm9u
Zz48Zm9udCBmYWNlPSJUcmVidWNoZXQgTVMiIGNvbG9yPSIjMDAwMDgwIiBz
aXplPSI2Ij5NYWtlIFN1cmUgVGhleSBBcmUgQnV5aW5nIGZyb20gWW91ITwv
Zm9udD48L3N0cm9uZz48L2Rpdj4NCjxkaXYgYWxpZ249ImxlZnQiPiA8c3Ry
b25nPiA8Zm9udCBzaXplPSI0IiBmYWNlPSJUcmVidWNoZXQgTVMiPlRoZSBm
YWN0cyBhYm91dCB0b2RheSdzIGNvbnN1bWVyOjwvZm9udD4gPC9zdHJvbmc+
DQogIDxmb250IHNpemU9IjQiIGZhY2U9IlRyZWJ1Y2hldCBNUyI+IEhlIG9y
IHNoZSBpcyBhIGZhc3QtcGFjZWQsIG9uLXRoZS1nbywgIkkgd2FudCBpdCBu
b3ciIGtpbmQgb2Ygc2hvcHBlci4gVGhlaXIgd2FsbGV0cyBhcmUgc3R1ZmZl
ZCBmdWxsIG9mIGNyZWRpdCBjYXJkcywgYW5kIHRoZSBjaGVja2Jvb2sgaXMg
IHVzdWFsbHkgbm93aGVyZSB0byBiZSBmb3VuZC48L2ZvbnQ+DQo8ZGl2IGFs
aWduPSJsZWZ0Ij4gPHAgYWxpZ249ImxlZnQiIHN0eWxlPSJtYXJnaW4tbGVm
dDogMDsgbWFyZ2luLXJpZ2h0OiAwIj48Yj48Zm9udCBjb2xvcj0iI2ZmMDAw
MCIgc2l6ZT0iNCIgZmFjZT0iVHJlYnVjaGV0IE1TIj5USEVTRQ0KICBTSE9Q
UEVSUyBBUkUgRVZFUllXSEVSRSE8L2ZvbnQ+IDwvYj48L2Rpdj4NCjxkaXYg
YWxpZ249ImxlZnQiPiA8cCBhbGlnbj0ibGVmdCIgc3R5bGU9Im1hcmdpbjog
MCI+PGZvbnQgY29sb3I9IiNmZjAwMDAiIHNpemU9IjQiIGZhY2U9IlRyZWJ1
Y2hldCBNUyI+PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudDogc21hbGwtY2Fw
cyI+b24NCiAgdGhlIHdlYjwvc3Bhbj48L2ZvbnQ+PGZvbnQgZmFjZT0iVHJl
YnVjaGV0IE1TIj48c3BhbiBzdHlsZT0iZm9udC12YXJpYW50OiBzbWFsbC1j
YXBzIj4mbmJzcDs8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBhbGlnbj0i
bGVmdCI+IDxwIGFsaWduPSJsZWZ0IiBzdHlsZT0ibWFyZ2luOiAwIj48Zm9u
dCBjb2xvcj0iI2ZmMDAwMCIgc2l6ZT0iNCIgZmFjZT0iVHJlYnVjaGV0IE1T
Ij48c3BhbiBzdHlsZT0iZm9udC12YXJpYW50OiBzbWFsbC1jYXBzIj5vbg0K
ICB0aGUgcGhvbmU8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBhbGlnbj0i
bGVmdCI+PHAgYWxpZ249ImxlZnQiIHN0eWxlPSJtYXJnaW46IDAiPjxmb250
IGNvbG9yPSIjZmYwMDAwIiBzaXplPSI0IiBmYWNlPSJUcmVidWNoZXQgTVMi
PjxzcGFuIHN0eWxlPSJmb250LXZhcmlhbnQ6IHNtYWxsLWNhcHMiPmluDQog
IHRoZSBhdXRvIHNob3A8L3NwYW4+PC9mb250PjwvZGl2Pg0KPGRpdiBhbGln
bj0ibGVmdCI+IDxwIGFsaWduPSJsZWZ0IiBzdHlsZT0ibWFyZ2luOiAwIj48
Zm9udCBjb2xvcj0iI2ZmMDAwMCIgc2l6ZT0iNCIgZmFjZT0iVHJlYnVjaGV0
IE1TIj48c3BhbiBzdHlsZT0iZm9udC12YXJpYW50OiBzbWFsbC1jYXBzIj5h
dA0KICB0aGUgZ2lmdCBzaG9wPC9zcGFuPjwvZm9udD48L2Rpdj4NCjxkaXYg
YWxpZ249ImxlZnQiPiA8cCBhbGlnbj0ibGVmdCIgc3R5bGU9Im1hcmdpbjog
MCI+PGI+PGZvbnQgY29sb3I9IiNmZjAwMDAiIGZhY2U9IlRyZWJ1Y2hldCBN
UyIgc2l6ZT0iNSI+PHNwYW4gc3R5bGU9ImZvbnQtdmFyaWFudDogc21hbGwt
Y2FwcyI+RVZFUllXSEVSRSE8L3NwYW4+PC9mb250PjwvYj48L2Rpdj4NCjxk
aXYgYWxpZ249ImNlbnRlciI+PHAgYWxpZ249ImxlZnQiPjxlbT48Zm9udCBz
aXplPSIyIiBjb2xvcj0iIzAwMDAwMCIgZmFjZT0iVHJlYnVjaGV0IE1TIj5B
bGwgUmV0YWlsLFdob2xlc2FsZSwgT3JkZXIgQ2VudGVycywgTWFpbC1PcmRl
ciBCdXNpbmVzcywgQ29uc3RydWN0aW9uIFRyYWRlcywgYW5kIFNlcnZpY2Ug
UHJvdmlkZXJzIG5lZWQgdG8gYWNjZXB0IGNyZWRpdCBjYXJkcyE8L2ZvbnQ+
PC9lbT48L2Rpdj4NCjxkaXYgYWxpZ249ImNlbnRlciI+PHA+PC9kaXY+DQo8
ZGl2IGFsaWduPSJjZW50ZXIiPjxzdHJvbmc+PHNwYW4gc3R5bGU9ImZvbnQt
dmFyaWFudDogc21hbGwtY2FwcyI+PGVtPjxkZm4+PGZvbnQgY29sb3I9IiNG
RjAwMDAiIHNpemU9IjMiIGZhY2U9IlRyYWphbiI+T3Zlcg0KICA5MiUgb2Yg
bWFpbCBvcmRlcnMgJmFtcDsgcGhvbmUgb3JkZXJzIGFyZSBkb25lIHdpdGgg
Y3JlZGl0IGNhcmRzLjwvZm9udD48L2Rmbj48L2VtPjwvc3Bhbj48L3N0cm9u
Zz48L2Rpdj4NCjxkaXYgYWxpZ249ImNlbnRlciI+IDwvZGl2Pg0KPGZvbnQg
c2l6ZT0iNCI+PGgxIHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IiBhbGln
bj0iY2VudGVyIj48c3BhbiBzdHlsZT0iRk9OVC1TSVpFOiAxNHB0OyBtc28t
YmlkaS1mb250LXNpemU6IDEwLjBwdCI+PGZvbnQgY29sb3I9IiMwMDAwODAi
IGZhY2U9IlRyYWphbiIgc2l6ZT0iNSI+PGI+V2h5IE5vdCBJbmNyZWFzZSB5
b3VyIHNhbGVzIGJ5IDQwMCU/PC9iPjwvZm9udD48L3NwYW4+PC9oMT4NCjxw
IHN0eWxlPSJNQVJHSU46IDBpbiAwaW4gMHB0IiBhbGlnbj0iY2VudGVyIj4m
bmJzcDs8L3A+PC9mb250Pg0KPGRpdiBhbGlnbj0iY2VudGVyIj48c3Ryb25n
Pjxmb250IGZhY2U9IlRyYWphbiIgc2l6ZT0iNCIgY29sb3I9IiNGRjAwMDAi
PjxpPllPVSBDQU4gQkVHSU4gQUNDRVBUSU5HIENSRURJVCBDQVJEUyBJTiBB
UyBMSVRUTEUgQVMgMjQgSE9VUlMhPC9pPjwvZm9udD48L3N0cm9uZz48L2Rp
dj4NCjxkaXYgYWxpZ249ImNlbnRlciI+PGZvbnQgZmFjZT0iVHJlYnVjaGV0
IE1TIiBzaXplPSI0IiBjb2xvcj0iIzAwMDAwMCI+KERlcGVuZGluZyB1cG9u
IHRoZSBjcmVkaXQgY2FyZCAgcHJvZ3JhbSB3ZSBnZXQgeW91IHF1YWxpZmll
ZCBmb3IpPC9mb250Pg0KPC9kaXY+DQo8Zm9udCBzaXplPSI0Ij48Zm9udCBm
YWNlPSJUdyBDZW4gTVQiIGNvbG9yPSIjMDAwMDAwIiBzaXplPSI1Ij48Zm9u
dCBmYWNlPSJUdyBDZW4gTVQiIHNpemU9IjUiPjxkaXYgYWxpZ249ImNlbnRl
ciI+PGI+PGZvbnQgc2l6ZT0iNSIgZmFjZT0iVHJlYnVjaGV0IE1TIiBjb2xv
cj0iIzAwMDA4MCI+VmlzYSwgTWFzdGVyQ2FyZCwgQW1lcmljYW4gRXhwcmVz
cywgRGlzY292ZXI8L2ZvbnQ+PC9iPjwvZGl2Pg0KPGRpdiBhbGlnbj0iY2Vu
dGVyIj48L2Rpdj48L2ZvbnQ+PC9mb250Pg0KPGg0IHN0eWxlPSJNQVJHSU46
IDBpbiAwaW4gMHB0IiBhbGlnbj0ibGVmdCI+PGZvbnQgZmFjZT0iVHJlYnVj
aGV0IE1TIiBjb2xvcj0iIzAwMDAwMCIgc2l6ZT0iNCI+U2FtZSBkYXkgYXBw
cm92YWwgLSBubyB0dXJuIGRvd25zIC0gZWFzeSBmYXggYXBwbGljYXRpb248
L2ZvbnQ+PC9oND48aDQgc3R5bGU9Ik1BUkdJTjogMGluIDBpbiAwcHQiIGFs
aWduPSJsZWZ0Ij48Zm9udCBmYWNlPSJUcmVidWNoZXQgTVMiIHNpemU9IjQi
PjxzcGFuIHN0eWxlPSJtc28tYmlkaS1mb250LXNpemU6IDEwLjBwdCI+PGZv
bnQgY29sb3I9IiMwMDAwMDAiPlJldGFpbDwvZm9udD48Zm9udCBjb2xvcj0i
I0ZGMDAwMCI+KjwvZm9udD4NCjxmb250IHNpemU9IjUiIGZhY2U9IlR3IENl
biBNVCIgY29sb3I9IiMwMDAwMDAiPldlYiBWaXJ0dWFsIHRlcm1pbmFsIDwv
Zm9udD48Zm9udCBjb2xvcj0iI0ZGMDAwMCI+KjwvZm9udD4NCjxmb250IGNv
bG9yPSIjMDAwMDAwIj5NYWlsIG9yZGVyPC9mb250Pjxmb250IGNvbG9yPSIj
RkYwMDAwIj4qPC9mb250Pjxmb250IGNvbG9yPSIjMDAwMDAwIj4gVGVsZXBo
b25lIG9yZGVyPC9mb250Pjwvc3Bhbj48L2ZvbnQ+PHN0cm9uZz48c3BhbiBz
dHlsZT0ibXNvLWJpZGktZm9udC1zaXplOiAxMC4wcHQiPjxmb250IHNpemU9
IjQiIGZhY2U9IlRyZWJ1Y2hldCBNUyIgY29sb3I9IiMwMDAwMDAiPjxPOlA+
DQo8L086UD48L2ZvbnQ+PC9zcGFuPjwvc3Ryb25nPjwvaDQ+DQogIDxoNCBz
dHlsZT0iTUFSR0lOOiAwaW4gMGluIDBwdCIgYWxpZ249ImxlZnQiPjxmb250
IGZhY2U9IlRyZWJ1Y2hldCBNUyIgc2l6ZT0iNCI+RXhpc3RpbmcgTWVyY2hh
bnRzOiA8aT48Zm9udCBmYWNlPSJUdyBDZW4gTVQiIGNvbG9yPSIjMDAwMDAw
IiBzaXplPSI1Ij5Mb3dlciB5b3VyIHJhdGVzIC0tRlJFRSBzdGF0ZW1lbnQg
YW5hbHlzaXM8L2ZvbnQ+PC9pPjwvZm9udD4NCiAgPC9oND4NCjxQPjxmb250
IHNpemU9IisyIiBmYWNlPSJUdyBDZW4gTVQiIGNvbG9yPSIjMDAwMDAwIj48
YSBocmVmPSJodHRwOi8vd3d3Lmxvd2VzdC1yYXRlLm5ldC9jZ2ktYmluL21l
cmNoYW50X3NlcnZpY2VzLmNnaT9hZmZpbGlhdGU9NTUwNDYzIj4gSnVzdCBD
bGljayBIZXJlIHRvIFN0YXJ0IEFjY2VwdGluZyBDcmVkaXQgQ2FyZHMgUmln
aHQgQXdheSE8L2E+ICANCjxwPkEgcmVwcmVzZW50YXRpdmUgd2lsbCBjb250
YWN0IHlvdSB3aXRoaW4gMjQgaG91cnMhPC9mb250Pg0KPGZvbnQgZmFjZT0i
VHcgQ2VuIE1UIiBjb2xvcj0iIzAwMDAwMCIgc2l6ZT0iNSI+DQo8UD48Zm9u
dCBmYWNlPSJBcmlhbCIgc2l6ZT0iMyI+DQpKdXN0IFZpc2l0IE91ciBXZWJz
aXRlIHRvIHRha2UgeW91ciBuYW1lIG91dCBvZiBvdXIgbWFzdGVyIGRhdGFi
YXNlLg0KPGZvbnQgY29sb3I9ImZmZmZmZiI+DQo8cD4NCjwvZGl2Pg0KDQo8
L2g0Pg0KDQo8L2h0bWw+DQoxMzQzZlZNWjMtNTYwYkpSZTA2NjVSY2xmNi0z
MTRoZkRNODg4N1pPYUo2LTQ0MGw0NA==

Re: [Hamlib-developer] Tone -vs- CTCSS

[Nate B. <n0...@ne...>]

* Dale E. Edmons <de...@w-...> [2002 Jul 06 21:24 -0500]:
> Chuck,
> 
> That sounds quite like actual operation.  I've only read
> bits and pieces.  After keying up a repeater and getting
> on the air I haven't spent much time on it.  It also explains
> why repeaters wouldn't key-up with CTCSS on.
> 
> However it works is fine.  As long as hamlib works as expected
> all is well.  I'll have to do more reading on this soon.

Perhaps I shall take a stab at this.

CTCSS, Continuous Tone Coded Squelch System, is the generic name for the
subaudible tone frequencies ( < 300 Hz) used to minimize co-channel
interference.  This system went under a number of trade names including
Motorola's Private Line (this is why you'll see CTCSS also referenced as
PL tones) and GE's Channel Guard.  Regardless of the name there are a
number of "standard" and a number more non-standard tone frequencies.

Normally, in a commercial setup, all the radios for a given group will
transmit (encode) the same tone and the associated receivers will
unsquelch only when an FM carrier with the proper tone is received
(decode).  To facilitate more than one group of users on a repeater,
each group will be assigned a CTCSS tone by the repeater operater and
the repeater will use a "shared tone panel" that is programmed to
respond to the various tones in use.  Each transceiver has a monitor
function so that when the microphone is removed from its hanger the
receiver now will operate in carrier squelch mode and receive everything
on frequency.  This is to prevent "doubling" or "talking over" another
station.

We hams tend to use CTCSS only for two reasons.  In the early days it
was a crude means to operating a "closed" repeater as few radios had
CTCSS capability and adding it was often expensive.  The most common
reason we use CTCSS is to avoid the repeater from keying up due to
receiver intermodulation products or from distant stations not intending
to use the local machine during band openings.

Most ham rigs support the following three states:

encode off, decode off
encode on, decode off
encode on, decode on

Encode always applies to the transmitter and decode to the receiver.

It appears from your note above the TS2K supports a fourth state, encode
off, decode on.  None of my Yaesu gear will do this and it seems to be
of dubious value to me, but whatever.

So now, following along with your threads, it appears there is a
seperate command to set the TS2K to encode "ON" or "OFF" and another to
set the decode in either state and both are independent of the other.

Keep in mind that "tone", "CTCSS", "Subaudible tone", "PL tone" are
references to the same thing, a steady tone modulated on the FM carrier
for the purpose of allowing a receiver expecting that tone to be present 
to unsquelch and receive your transmission.  Nothing more.

DCS, Digital Coded Squelch, is a variation on the same theme, however,
instead of a steady tone the FM carrier is modulated by a data stream.
The datastream contains a multidigit code programmed into the radio.
The system works the same way except many more codes are available, thus
a DCS system is harder to "crack".

"Tone burst" refers to the system in use in Europe when at the beginning
of a transmission a short 1750 Hz tone is transmitted and the repeater's
receiver will unsqelch and the repeater can be used.  This system is
seldom used in North America.

I hope this helps to clarify some of the terms and their operation.

With regard to Hamlib, it seems to me that the CTCSS routines in rig.c
ought just be mapped to the correct command codes in the ts2k backend to
enable/disable encode/decode.  Is it not this simple (I haven't read any
of the ts2k code)?

73, de Nate >>

-- 
 Wireless | Amateur Radio Station N0NB          | "We have awakened a
 Internet | n0...@ne...               | sleeping giant and
 Location | Bremen, Kansas USA EM19ov           | have instilled in him
  Amateur radio exams; ham radio; Linux info @  | a terrible resolve".
             http://www.qsl.net/n0nb/           | - Admiral Yamomoto

[Hamlib-developer] Tone -vs- CTCSS

[Dale E. E. <de...@w-...>]

Chuck,

That sounds quite like actual operation.  I've only read
bits and pieces.  After keying up a repeater and getting
on the air I haven't spent much time on it.  It also explains
why repeaters wouldn't key-up with CTCSS on.

However it works is fine.  As long as hamlib works as expected
all is well.  I'll have to do more reading on this soon.


73's

Dale

RE: [Hamlib-developer] DCS, TONE, CTCSS, 1750; Who knows what el

[Chuck H. <n2...@am...>]

Looks to me, looking at the manual (I don't have a TS2k) that:

Tone: transmit a tone
CTCSS: check for tone on receive and only pass audio on receipt of the tone
DCS: Digital Coded Squelch

Many repeaters will pass or generate a tone on transmit.

This can be used (with CTCSS receive):
a. If there is noise on the frequency, you can open the squelch and only listen
   if there is a tone.
b. If there are multiple repeaters that you can hear on a given frequency with
   different tones.
c. Many times the repeater only transmits the tone when passing audio, so you
   don't have to listen to the tail and/or repeater ids.
d. On a simplex frequency if the users you want to talk to all transmit the
   tone, you only hear them.
e. On a repeater that doesn't use a tone and passes any tones it hears, you can
   do the same as d over it.

Many radios only let you select one tone, and then give you the option of
transmitting it, checking for it on receive, or both.  Looks like the TS2k gives
you the option of transmitting one tone, and checking for a different one.  I
can see where this might be useful in certain places, but I haven't heard of
anyone actually using it that way.

Hope this makes sense and helps explain things.

[Hamlib-developer] hamlib_ts2k

[Dale E. E. <de...@w-...>]

Stephane,

The RIG_CHFLAG_SKIP would be prefered.  Either
is needed but not both (unless you are giving me the
RIG_CHFLAG_LOCK so I can use it as READONLY--
hi).

See my response to Robert for more info on READONLY.

The 1750Hz item is a menu option and will be treated as
such unless otherwise notified.  (Again, see my reply to
Robert for more info.)  The "one-shot" is not standard
on my rig  (U.S./Canada version) but is a menu option.

Ignoring the 1750Hz there are three unique tone types:
    1) Tone, 2)CTCSS, 3) DCS.
In my area only 1) is used and 2) and 3) are not, at least
to my limited knowledge.  I have used CTCSS on my
HT to operate my rig via remote control, but if you
accidently enable CTCSS on an actual repeater, you
will not be able to talk on it.  There is no 1750 Hz
activation (again, to my limited knowledge).

Yes, the "Programmable Memories" are different.
The manual only lists the command.  I don't think
it may be accessed via the panel.

The name rig_set_pm() would be wrong but it would
be okay to have ts2k_set_pm().  Maybe we could
write rig_set_state() or rig_set_setup() or even
rig_set_conf() if rig_set_menu() replaces your
previous.

Later, it may be required to backup PM[0:5] and it
would be done (by some application) as follows:
    for( pm=0, pm<=5; pm++) {
    rig_set_conf(rig, pm);
    rig_save_channel(rig, RIG_CTRL_MAIN);
    rig_save_channel(rig, RIG_CTRL_SUB);
    rig_get_menus(rig, MENU_FIRST, MENU_LAST);
    rig_set_menu(rig, MENU_B);
    rig_get_menus(rig, MENU_FIRST, MENU_LAST);
     }
Or something very close to this.

I have begun working on the Menu stuff as it is
important to the user.  I haven't even tried compiling
anything so far but I think I'm on the right track.
Much input will be needed and appreciated.

I don't know what all will be needed for the menu
API.  The backend may need to initialize stuff
which can be called with the mmelter_init().
I've anticipated Hamlib's complete lack of know-
ledge of Menu items and suggest rig_menu_list()
which will return a char * to the menu items
description.  See my ts2k_menu.h if you find
the time.  The ts2k_menu.c is not very far and
will change.  The application will do something
like the following to change a menu item:
    rig_get_menu(rig, MENU(12));
    fprintf(menu, "%s: ", rig_menu_list(rig, MENU(12)) );
     /* read user response and set value */
    rig_set_menu(rig, MENU(12),  value);
Or something vaguely like this.  The application
should be able to setup its own complete menus
so the user may browse the entire set.  I think
we're thinking along the same lines.


My work on the TS440 stopped after I said it
was similar to existing stuff.  I saw you had
some stuff for it and got busy with other stuff.
The same goes with the kenwood_transaction().

P.C.T. is very cool but completely useless if
only the rig can access it.  The user can use
the panel until other things are sorted out.

rig_save_channel() should work as you suggested
but I'll have to see what you write or show you
what I write.  As long as the backend can take
over, life is good.  Any of the channel() stuff
should have a channel_t.  The called function
should always be passed the needed values
of chan_t, or vfo_t, or both in this struct or
as parameters.  The backend can't guess
and setting them in the rig may be the wrong
thing to do.  If needed, the backend can set
them in the rig (or if generic_save_channel()
is called).

Sorry for running on so long again.

73's

Dale
kd7eni

Re: [Hamlib-developer] Re: gnuradio and Hamlib

[Stephane F. <f4...@fr...>]

Hi Matt!

On Wed, Jul 03, 2002, Matt Ettus wrote:
> > Alright, seems pretty feasible. Since you're going to be first "user",
> > what is your FI source ? Is it the MC4020+microtune_eval_board ?
> 
> I'm not sure what FI stands for, but yes, I have the microtune and MC4020 combo.
>  That would be a great demo.

Problem of vocabulary. When I say FI, I mean a tap, a sampled source. What
is the best word anyway?
About the microtune and MC4020, I'll need some specs, like the bandwidth
of the FI (around 5MHz?) and the frequency range of the tuner.

 
> > Hmm. Please correct me if I'm wrong. IOW, you're not gonna use Grig right
> > out-of-the-box. Your idea/need is to take Grig as a base, and hack it
> > specifically for gnuradio extension, in such a way that may not work
> > with a stock GRig. Right?
> > (I'm a bit exagerating, but this is to better understand what interfaces
> > will be needed in the backend).
> 
> My intention was that GRig could be used unmodified.  I'd like the user not to
> be able to tell whether they are using a ft-1000 or gnuradio-based SDR.

Okay, so we have a dilemma about the main loop. Either GRig, Hamlib, or
gnuradio will have to suffer a (little) modification. Explicit main loop
for GRig and Hamlib or -DTHREAD for gnuradio.
A temporary solution would be to put the main loop in a modified
rpc.rigd daemon. We'll see.


Allright Matt, I have good news for you. I have just checked in an initial
gnuradio backend. It does not MC4020 yet, but there're should be enough
for you to see if I'm on the right track.

From a fresh checkout, add the --with-gnuradio to autogen.sh (after
doing chmod +x on the script). For the build to work, you'll have to put
libgnuradio.a in the gnuradio subdirectory (sorry, libgnuradio.la is
still not suitable for use, I'll explain you why in a future mail),
and have gnuradio-0.3 in the same parent directory as your hamlib
checkout. Having gnuradio installed in /usr/include and /usr/lib should
work also. And of course, libfftw must be already installed too :)

Let me know if you encounter any build problem.
I've provided a simple gnuradio/testgr program to be hack. Right now, it
should display a GUI with a scope, but dies with segfault:

  (fillods@charybde:gnuradio)$ ./testgr
  could not load logo file '/dev/null'
  testgr:hello, I am your main() !
  rig:rig_init called
  rig: loading backend gnuradio
  gnuradio: _init called
  rig_register (2001)
  gr_init called
  rig:rig_open called
  gr_open called
  VrNullSink cachedSize = 131072
  VrNullSink.setup[0x80869e0] 131072 freq 5e+06 (0.026214 sec)
  GrFFTSink cachedSize = 65536
  GrFFTSink.setup[0x8087cc0] 65536 freq 5e+06 (0.013107 sec)
  VrSource.setup[0x8086950] 500000 freq 5e+06 (0.100000 sec)
  Warning: could not allocate more than 33554432 bytes for shared memory
  buffer.
  VrSource output bufferSize = 4194304 (0.838861 sec)
  gr_get_vfo called: VFOA
  Erreur de segmentation

If I comment out line 84 in testgr.cc priv->m->process(), then I get the
GUI, and set_my_freq is called correctly. I must have messed up
something in the source and sink wiring.
Matt, can you have a look and tell me what I've done wrong?
BTW, the "Warning: could not allocate more than 33554432 bytes ...."
looks suspicious.

As a final note, yes, for now, this backend does nothing useful. Source
and sink are fake. And some data structures have to be better tought
(esp. the gnuradio_priv_data).
This first release is only to devise the glue between Hamlib and gnuradio.


> P.S.  If anyone is interested, I will be giving a talk and demos for gnuradio at
> TAPR's DCC this year.  See http://www.tapr.org

Hey, that's great!
If only I were still in AZ, I would have loved to attend!


Cheers,
Stephane


P.S. and see you in the contest "Rallye des points hauts" (kind of field 
     day on 2m and up) for those in Europe!