headers
Nate Bargmann | 1 Mar 2007 01:39

Re: rx320, tentec patches

On Wednesday 28 February 2007 09:18, Martin AA6E wrote:
> I found a patch submitted by Ken Prox dating from 12/30/06 that had not
> been acted on.  I checked it in today, and the patch tracker item should
> be closed, but I don't have privs for that.

I will add you so you can take care of it, Martin.

> Is anyone monitoring the Project Trackers?  I suggest that a number of
> us should be doing that.  It shouldn't take 2 months to get something
> installed.

Something else to monitor?  :-)

I need to look through the README* files and ensure that this list is 
explicitly mentioned as the place to submit patches.  I am still learning 
SourceForge, but I find it cumbersome enough that I tend not to use it as 
often as I probably should.

I jumped in to keep the project moving since I'd been a member of the project 
for a long time.  When someone more capable of running the show than I 
volunteers, I shall step aside.  My goal is to keep the project from becoming 
stale.  

With these recent patches a 1.2.6.2 release may be in order this weekend.  I 
noticed that it didn't take 1.2.6.1 long to find its way into my Sid installs 
(thanks Joop!).

> How much scrutiny we should be giving to submitted patches?  I checked
> them superficially, but unfortunately there is no way we can test
> rig-specific patches "centrally".  That's a fundamental problem in the
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin AA6E | 1 Mar 2007 03:19

Re: rx320, tentec patches

Nate,

Your service is much appreciated!  There is a lot of hassle behind the 
scenes to make new releases, etc.  I hope you will call on us if there 
are any functions that can be delegated.  I have slowly been making some 
changes to the web site, for example.  We need to talk more about this 
one of these days.

I looked at the Tracker setup (using my new snazzy privs), and I think I 
have set them so that any new Tracker request will be forwarded to this 
list.  That should help a little.  Everything had been going only to 
Stephane.

73 - Cheers,
Martin AA6E

Nate Bargmann wrote:
> On Wednesday 28 February 2007 09:18, Martin AA6E wrote:
>> I found a patch submitted by Ken Prox dating from 12/30/06 that had not
>> been acted on.  I checked it in today, and the patch tracker item should
>> be closed, but I don't have privs for that.
> 
> I will add you so you can take care of it, Martin.
> 
>> Is anyone monitoring the Project Trackers?  I suggest that a number of
>> us should be doing that.  It shouldn't take 2 months to get something
>> installed.
> 
> Something else to monitor?  :-)
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Martin AA6E | 1 Mar 2007 18:02

Re: rx320, tentec patches

Diane Bruce wrote:
> On Wed, Feb 28, 2007 at 10:18:02AM -0500, Martin AA6E wrote:
>> I found a patch submitted by Ken Prox dating from 12/30/06 that had not
>> been acted on.  I checked it in today, and the patch tracker item should
>> be closed, but I don't have privs for that.
> ...
>> rig-control software game: nobody has a shack full of all supported
>> rigs.  Nobody can run a complete regression test.
> 
> No, but it would be possible to have agents that behave like a supported
> rig, they'd use a pseudo tty. They'd not be able to check
> all aspects of a radios operation but could be used to regression test
> that a command is not suddenly garbaged.
> 
> Unfortunately, building a set of agents would be a lot of work. Though it
> might be possible to build these in an automated fashion somehow.
> 
> - 73 Diane VA3DB
> 
> --
> - db <at> FreeBSD.org db <at> db.net http://www.db.net/~db

Yes, a good idea, but a lot of work.  If we were paying for our time, it 
would be cheaper to buy the rig than to emulate it!

It would be more sensible to develop the test package along with the 
backend, if we were that well organized...

73 Martin AA6E
(Continue reading)

Permalink | Reply | 0 comments |
headers
Berndt Josef Wulf | 3 Mar 2007 13:45
Picon

Re: ic-prc100

On Tuesday 20 February 2007 22:13:14 Berndt Josef Wulf wrote:
> G'day,
>
> I've become the proud owner of above rig. Unfortunately, I didn't have much
> joy in getting it to work with hamlib's rigctl and hence I'm now looking
> for information on the communications protocol. Does anyone have a manual,
> preferably a softcopy, with the protocol specifications?
>
> The rig works fine on MS XP using the software originally shipped with this
> unit.

Still no reply and hence one more try. Someone must have the information I 
need since there is code for the PCR100/1000 in hamlib.

Sofar I've been unsuccessful in getting the PCR100 to work. It won't even 
power-up unless I run it as a PCR1000 using rigctl.

There is a link on the hamlib site that refers to "The Getto Team". 
Unfortunately, this link doesn't work. Using Google didn't proof to be 
successful.

Who wrote the existing code for PCR100/1000 and what documentation is 
available?

I won't be able to write code for PCR100 unless I get some documentation on 
the protocol used by these rigs.

73, Berndt
VK5ABN
(Continue reading)

Permalink | Reply | 1 comment |
headers
Martin AA6E | 3 Mar 2007 15:31

Re: ic-prc100

Berndt,

Sorry you're having trouble getting documentation!

Looking at pcr.c and searching 
http://blog.gmane.org/gmane.linux.hams.hamlib.devel (a convenient way to 
access our archives) suggests that Darren.hatcher (at) bt.com, G0WCW, 
may be the source for this backend.

I will look for the bad link you mention and deal with it.  If anyone 
has suggestions for repairs to the web site, please let me know.

73 Martin AA6E

Berndt Josef Wulf wrote:
> On Tuesday 20 February 2007 22:13:14 Berndt Josef Wulf wrote:
>> G'day,
>>
>> I've become the proud owner of above rig. Unfortunately, I didn't have much
>> joy in getting it to work with hamlib's rigctl and hence I'm now looking
>> for information on the communications protocol. Does anyone have a manual,
>> preferably a softcopy, with the protocol specifications?
>>
>> The rig works fine on MS XP using the software originally shipped with this
>> unit.
> 
> 
> Still no reply and hence one more try. Someone must have the information I 
> need since there is code for the PCR100/1000 in hamlib.
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Berndt Josef Wulf | 3 Mar 2007 19:21
Picon

Re: ic-prc100

On Sunday 04 March 2007 01:30:00 you wrote:
> Berndt,
>
> Google turns up a sorry state of affairs, with lots of broken links.
> You may have found this, also.
>
> There is a resource list at http://qsy.to/pcr/control.html . The only
> live project with source that I found was
> http://www.mv.net/ipusers/cdwalker/pcrd.html
>
> I assume you've tried to wheedle info from Icom?
>
> Cheers,
>
> Martin AA6E

Just found site which lists some of the commands, see link below:

http://www.gm4jjj.co.uk/PCR1000.html

cheerio Berndt

-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
Permalink | Reply | 1 comment |
headers
Nate Bargmann | 4 Mar 2007 00:26

Re: ic-prc100

On Saturday 03 March 2007 12:21, Berndt Josef Wulf wrote:
> On Sunday 04 March 2007 01:30:00 you wrote:
> > Berndt,
> >
> > Google turns up a sorry state of affairs, with lots of broken links.
> > You may have found this, also.
> >
> > There is a resource list at http://qsy.to/pcr/control.html . The only
> > live project with source that I found was
> > http://www.mv.net/ipusers/cdwalker/pcrd.html
> >
> > I assume you've tried to wheedle info from Icom?
> >
> > Cheers,
> >
> > Martin AA6E
>
> Just found site which lists some of the commands, see link below:
>
> http://www.gm4jjj.co.uk/PCR1000.html

Icom doesn't document it in the manual?  That's odd as what little I know of 
Icom is that they document things rather well.  Here's hoping you find 
everything you need.

73, de Nate >>

--

-- 
 Wireless | Amateur Radio Station N0NB          |  Successfully Microsoft
  Amateur radio exams; ham radio; Linux info  <at>   | free since January 1998.
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Beierlein | 5 Mar 2007 16:57
Picon
Favicon
Gravatar

Re: Looking for help in testing TS-570S/SG backend

Hi Jon,

sorry for the late reply. I had to lay in bett with fever some days....

On Sun, Feb 25, 2007 at 06:45:31PM +0000, Jon Kåre Hellan wrote:
> Mine is a DG, just like yours. I am writing to ask if you have fixes since 
> 1.2.6.1.
> 
> I worked through a few examples with rigctl today, and noticed a few strange 
> things:

Thanks for giving us some test results.

> get_mode command:
> What's reported as passband is in fact the low cut-off frequency

Hmm. Tested it until now only in CW. But I see comments in the source that it reads only low cut-off for SSB, AM
and FM. The comment suggest a similar implementation in the TS870s backend. But there is no similar code. 

We could change it to calculate the difference between high and low cut-off. But I am not sure if that is the
best way. 
Any ideas?

> 
> get/set XIT commands do exactly the same thing as get/set RIT.
> 
That is by design of the rig. It cannot handle different XIT and RIT offsets. It is always the same. 

> get/set split tx frequency command:
> Simply reports/sets the frequency of the current CPU. Traces:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Thomas Beierlein | 7 Mar 2007 19:34
Picon
Favicon
Gravatar

Some questions about the API

Hi folks,

shortly Jon, LA4RT, reported some test results for the TS570D/DG rig. I 
tried fixing some of the problems but run into some questions regarding 
the API and its correct implementation. Maybe some of you can get me some
helping answers.

Here are my problems:

1. I do not understand fully how the API functions for split operations
shall be used. As I read from the  API documentation I would think it
should work as follows:

- With rig_get_split_vfo(rig, RIG_VFO_CURRENT, *split, *tx_vfo) you can
  always ask if split operation is active (split == RIG_SPLIT_ON) and if so
  you get the active tx_vfo back.

- With rig_set_split_vfo(rig, rx_vfo, *split, *tx_vfo) you can set
  split operation on (if split == RIG_SPLIT_ON) and off (if split ==
  RIG_SPLIT_OFF). Furthermore if you turn on split you can choose the
  tx_vfo.

- with rig_set/get_split_freq you control the tx frequency and with
  rig_set/get_split_mode you choose the mode for tx channel.

Now my questions:

a) The API documentation for rig_get_split_vfo says only it should give
information if split is on (The returned tx_vfo is not mentioned). And
indeed there are a lot of backend implementations which only checks for
(Continue reading)

Permalink | Reply | 2 comments |
headers
Martin AA6E | 8 Mar 2007 03:19

Re: Some questions about the API

Tom,

Yes RIT is disabled by setting RIT to zero, and the driver should set 
the RIT=off condition if your rig has such a switch.  I have had similar 
issues myself.  Two comments:

-We need a formal API specification that includes functional issues like
split operation, multiple VFOs, memories, etc.  It's nice to have a
parameter list, but we need more.  IMO, there is still some confusion
about whether we are working with a clearly defined "virtual rig" or
whether we are trying to provide access to all the bells & whistles of
advanced rigs.  If it is the former, we need to state what the virtual
rig is, what modes are supported, etc.  It would be great if someone
could work on this!

-Are there any Hamlib user apps that actually have used split
functionality and exotic modes that exist only in some rigs?  As others
have observed, most apps use very basic commands only.  So, in the
absence of a clear API & functional spec, it may be just as well to
leave things unimplemented...

BTW, I see that we do not have the 1.2.6 documentation (DOXYGEN 
produced) on the web site.  You can generate it from the sources, if you 
run 'make doc', but I will update it on the web.  It is somewhat 
expanded compared to earlier versions.  It seems to be the best we have 
for now.

[Nate - There were a bunch of web updates that Stephane would do 
"automatically" for each Hamlib release -- doc, driver status, etc.  I 
don't know if there was a script for that, but in any case I'll update
(Continue reading)

Permalink | Reply | 1 comment |

Gmane