groundstation-developer — Groundstation Developer Forum

[Groundstation-developer] [ANN] grig 0.9.0 released

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

Good News every one!

Finally here comes grig 0.9.0.

This is mainly a maintenance release in order to align with Hamlib-4.x, 
plus some cosmetic fixes.
Thanks to all the contributors and pull requests.

Download it at:
https://github.com/fillods/grig/releases/tag/GRIG-0_9_0

I might give a try at releasing a win32 version, but this will be on a 
low effort mode.

Please note that grig moved from sourceforge to 
https://github.com/fillods/grig/

Remember, Alexandru Csete, OZ9AEC, the original designer and developer
of grig is looking for people to take over and maintain the project.
The current release has been made on interim.

No further development of feature is planned.
However pull requests are welcome of course.

To me, we still need a full featured GUI to control rigs supported by 
Hamlib,
but IMO programmed in Python would be a better choice.

73
-- 
Stephane - F8CFE

[Groundstation-developer] Grig repository moved to GitHub

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

Hi there,

In any case someone is still reading this mailing list, this is to 
inform you
that the CVS repo of grig on SourceForge has been migrated to GitHub.

I've been using this excellent tool for the migration : 
https://github.com/akshmakov/cvs2git-migrator

Here is the new repo : https://github.com/fillods/grig

I'm planning a maintenance release soon to align with Hamlib 4.x.
It works right now (and pushed), but the "NET rigctl" needs some more work.

Remember, no further development of feature is planned.
However pull requests are welcome of course.
To me, we still need a full featured GUI to control rigs based on Hamlib,
but IMO programmed in Python would be a better choice.

73
Stephane, F8CFE

[Groundstation-developer] Grig for IC-7200

[Ralph B. <bar...@sb...>]

Is there an updated version for grig for the IC-7200.  Current version says Beta? Anything more current?
Ralph (WA9LKZ)

[Groundstation-developer] how to compile grig against an own Hamlib version?

[Michael R. <mic...@gm...>]

Moin,

I use a development version [1] of the Hamlib 3.3 with support for the Kenwood TH-D74. 
While the normal Hamlib (and many applications) are installed via ubuntu  packages the 
Hamlib with the TH-D74-Extension was compiled and installed with --prefix=/home/
renner/hamlib.

Now I wonder which parameter do I have to give to the grig source to compile it against 
the hamlib unter /home/renner/hamlib, not against the distribution version under /usr/
include/hamlib and /usr/lib/hamlib?


 [1] https://github.com/denzs/Hamlib
-- 
|Michael Renner      E-mail: mic...@gm...  |
|81541 Munich        Twitter: @dd0ul                |
|Germany             Don't drink as root!      ESC:wq

[Groundstation-developer] [ANN] grig 0.8.1 released

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

Good News every one!

After a long silence, here is coming grig 0.8.1.

This is mainly a maintenance release in order to ease the build process,
esp. relative to deprecated symbols in gthread.

Download it at:
  https://sourceforge.net/projects/groundstation/files/Grig/0.8.1/

I might give a try at releasing a win32 version, but beta-testers
will be needed since I'm not running on Windows OS.

Remember, Alexandru Csete, OZ9AEC, the original designer and developer
of grig is looking for people to take over and maintain the project.
The current release has been made on interim.

73
-- 
Stephane - F8CFE

Re: [Groundstation-developer] [Groundstation-user] grig 0.8.0 ./configure pkg-config error on Mac Os X 10.11.2

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

Hi,

ven, Dec 18, 2015, Tom Coleman skribis:
[...]
> Running make, you will get a linker error complaining about g_thread_supported. It’s deprecated in the latest gtk+ libraries.

I'm about to release a maintenance version 0.8.1 in order to address this point.
Stay tuned :)

Cheers
-- 
Stephane - F8CFE

Re: [Groundstation-developer] [Hamlib-developer] Windows rig control, anyone?

[Martin E. <mar...@gm...>]

Not currently!

On Sun, Apr 1, 2012 at 7:36 PM, P.J. Rovero <pr...@ct...>wrote:

> I thought there was a WIndows GRIG on the source forge downloads site.
>
>
> P.J. "Josh" Rovero        Ham Radio:  KK1D
> Web:           http://www.roveroresearch.info
> Web2:         http://www.roveroresearch.org
>
>
> On Sun 04/01/12 17:41 , Martin Ewing <mar...@gm...> wrote:
>
> > I&#39;m working on a remote rig control application, probably using
> > rigctld.  Alas, my club wants to run it under Windows.
> > So I could really use a Windows native Grig or Grig-like program that
> > works with rigctld.  Does anyone have any suggestions?
> > 73 Martin AA6E
> > --
> > Martin Ewing
> > Branford, Connecticut
> >
> >
> >
>



-- 
Martin Ewing
Branford, Connecticut
mar...@gm...

[Groundstation-developer] Windows rig control, anyone?

[Martin E. <mar...@gm...>]

I'm working on a remote rig control application, probably using rigctld.
 Alas, my club wants to run it under Windows.

So I could really use a Windows native Grig or Grig-like program that works
with rigctld.  Does anyone have any suggestions?

73 Martin AA6E

-- 
Martin Ewing
Branford, Connecticut
mar...@gm...

[Groundstation-developer] A few issues with v 0.8.0

[Martin E. <mar...@gm...>]

Hello all,

I am looking at grig for a rigctld HF application, and I have a few notes
to share.  (Or maybe they are questions, if there is something I am
misunderstanding.)  I am running grig under Ubuntu 11.04 64 bit with a link
to rigctld running on Ubuntu 11.10 32 bit and a Ten-Tec Orion.

1.  Since I'm working with HF gear, the 100/1000 MHz digits for keypad
entry are "unfriendly".  It would be nice to suppress them optionally.  Or
maybe better yet, to provide a "." button, so I could enter "7.234<ENT>"
for 7.234 MHz.

2.  It would be convenient to have a keyboard entry option, too.

3. I find that my mouse loses sanity after a while. I can use the mouse
wheel to lower frequencies, but not to raise them.  I also note that the
left/right arrow system has a similar problem.  I can go down in freq., but
not up.  If I quit and restart, I get the right behavior again - for a time.

3a.  Another mode.  The mouse still works - the radio tracks it, but the
grig display does not.  The display is frozen.

[I suspect the above are partly an Orion or Orion backend problem.  The
Orion *really* does not like to have its main Rx VFO set very much outside
an amateur band.  However, it is possible to set any arbitrary frequency
via the CAT interface.  The Orion backend does not filter these out because
it cannot easily know whether you are using the Main (ham-only) or Sub
(general coverage) receivers.  VFO A or B can be switched to either
receiver.  Also, in some conditions I don't understand, the Orion can
report a frequency slightly different from the frequency you command. These
are Hamlib issues, of course.]

4.  For HF rigs, particularly, it would be handy to have a band select
"switch", so I could jump to a band without having to type a complete
frequency.  (And it might be handy for grig to understand the legal band
limits, too.)

5.  Does grig need to dump so much debug-type info when starting up and
shutting down? (Debug level = "none".)

6.  The right/left arrow tuning works on 1 Hz increments on my radio.  This
should be programmable, e.g. a choice of 10 or 100 Hz steps at least.

I know there is not too much development going on for grig these days, but
I thought I would share my comments anyway.  Maybe I will be able to help
with coding.  We will see.

Cheers,
Martin
AA6E

-- 
Martin Ewing
Branford, Connecticut
mar...@gm...

Re: [Groundstation-developer] [Hamlib-developer] [ANN] grig 0.8.0 released / packaging

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

Ven, Aug 26, 2011, Nate Bargmann skribis:
> * On 2011 26 Aug 16:22 -0500, Stephane Fillod wrote:
> > - Requires Gtk+ 2.12 and Hamlib 1.2.8
> 
> Or newer versions, of course.  :-)

;-)

> It has already been accepted by Debian FTP so should be in Unstable soon
> 
Hopefully it will make it for Ubuntu 11.10 (Oneiric). In the meantime,
Kamal has been super fast and already made it available in his PPA, thanks! 

 https://launchpad.net/~kamalmostafa/+archive/grig

or from https://launchpad.net/~ubuntu-hams/+archive/ppa

Does anyone of you has contact with Fedora maintainers of ham programs?
I'd like to ask them to make Grig available for the latest FC.

Likewise, could somebody recommand us how to distribute binary package
for Mac OS X? Is it through macports? Any volunteer?
http://www.macports.org/ports.php?by=name&substr=grig

I'll take care of the (cross-compiled) win32 binary in the coming days.

FreeBSD appears well maintained by Matt at http://www.freshports.org/comms/grig/

Thanks!
-- 
Stephane- F8CFE

[Groundstation-developer] [ANN] grig 0.8.0 released

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

Good News every one!

After almost 5 years, here is coming grig 0.8.0.

The NEWS blurb:

- Frequency entry via keypad (thanks to Alessandro Zummo).
- Arrow LEFT/RIGHT will change the frequency with the smallest step.
  This can be used for tuning using external devices like the Powermate.
* Support for VFO->MEM and MEM->VFO function.
- Support on/off rig functions.
- Added an extra gigahertz digit in lcd display
- Added antenna control
- French l10n (feel free to contribute your language)
- Fixed crash that occurs when mouse is clicked between MHz and kHz digits.
  Reported as Ubuntu bug 517816.
- Requires Gtk+ 2.12 and Hamlib 1.2.8

Download it at: https://sourceforge.net/projects/groundstation/files/Grig/0.8.0/

But hold on, what is grig BTW?  http://groundstation.sourceforge.net/grig/

Alexandru Csete, OZ9AEC, the original designer and developer of grig
is looking for people to take over and maintain the project.
The current release has been made on interim by Nirgal and myself.
We are thinking about bringing all the nice Alex's ideas in a Python
code base, lowering the maintainance. Upon Alex proposal, Grig might
one day join the Hamlib project. Many thanks to Alex for his work so far.

73
-- 
Stephane - F8CFE

Re: [Groundstation-developer] TS, next release schedule

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

Jau, Jun 23, 2011, Nirgal skribis:
[...]
> On Tuesday 21 June 2011 21:46:37 Stephane Fillod wrote:
> > But expecting too
> > much features is only going to postpone the expected release :-/
> > Do you have any wishes before making the release? How long for
> > the beta-testing?
> 
> I have many wishes, but none that can't wait.
> Basic users who are allergic to the command line probably really miss the rig/port selection on startup.
> But I don't have a Window$, so that I won't be able to do/test serial port selection on that platform.

Indeed, even something really dead simple would be good.

> What would you advise for a testing period? Or what has been the practice so far for grig?
> Do we make a release candidate?

There's no defined practice right now. Let's say the testing period is over,
and trigger the release 0.8 tomorrow (friday).

Is it okay with you?
-- 
Stephane

[Groundstation-developer] gettext

[Nirgal <con...@ni...>]

As you might have noticed, I changed the translation system back to gettext:

My reasoning is than modern versions of libtool (>= 0.18) now provide an equivalent service through autopoint, and that using a standard system will ease packaging. The command "autoreconf -i" is supported by a simple build-extension in Debian for example. I guess maitainers will find it easier to use this common mechanism.

Can someone test the build on another OS, like Windows?

I also updated a bit the French traslation table.


I uploaded a snapshot for debian (might work on unbuntu) at:
http://www.nirgal.com/debian/pool/main/g/grig_0.7.2-cvs20110626.1_i386.deb
http://www.nirgal.com/debian/pool/main/g/grig_0.7.2-cvs20110626.1_amd64.deb
Note that in these test versions, I stoped packaging the whole source and now only provide a cvs.diff, so that version bumped backward.

[Groundstation-developer] compilation warning on amd64

[Nirgal <con...@ni...>]

When building on a 64 bit system, I got:
rig-gui-vfo.c: In function ‘rig_gui_vfo_memory_cb’:
rig-gui-vfo.c:211: warning: cast to pointer from integer of different size
rig-gui-vfo.c:217: warning: cast from pointer to integer of different size

I guess it will be a problem on big-endian 64 bits systems.

Re: [Groundstation-developer] (no subject)

[mrtembry <mrt...@ya...>]

I guarantee 100% you won’t be disappointed. You can’t miss such a good chance!... http://www.puropalmero.com/sites.friend.php?oCID=79ve2

Re: [Groundstation-developer] VFO LCD display

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

Jau, Jun 23, 2011, Nirgal skribis:
> On Tuesday 21 June 2011 21:46:37 Stephane Fillod wrote:
> > Mar, Jun 21, 2011, Nirgal skribis:
> > > Some minor glitches I noticed:
> > > - "VFO" information is not refresh in LCD when another windows goes over ours.
> > 
> > I remember experiencing that glitch, but I've been unable to reproduce
> > it on Ubuntu 11.04.
> 
> Here, the "VFO A" lcd display appears only once, and on change.
> If I just minimise and restore the window, that display is gone.

Thanks. Problem reproduced, problem solved :-)
-- 
Stephane

Re: [Groundstation-developer] TS, next release schedule

[Nirgal <con...@ni...>]

On Tuesday 21 June 2011 21:46:37 Stephane Fillod wrote:
> Fine, so let's first take care of the release of grig 0.8.
> We're going to need beta-testers. Your Debian package will be
> quite handy for that matter. BTW, is the version grig_0.7.2+cvs20100302 
> supposed to match current?

No, the number after cvs is the date of the cvs snapshoot.


On Thursday 23 June 2011 21:28:21 Stephane Fillod wrote:
> Now, one would expect some kind of basic tuning step (in combo-box?)
> instead of the default minimum freq resolution. 

Yes. For example, my rig has a single TS of 1 hertz. So the left/right arrows are useless.

> But expecting too
> much features is only going to postpone the expected release :-/
> Do you have any wishes before making the release? How long for
> the beta-testing?

I have many wishes, but none that can't wait.
Basic users who are allergic to the command line probably really miss the rig/port selection on startup.
But I don't have a Window$, so that I won't be able to do/test serial port selection on that platform.


What would you advise for a testing period? Or what has been the practice so far for grig?
Do we make a release candidate?

[Groundstation-developer] VFO LCD display

[Nirgal <con...@ni...>]

On Tuesday 21 June 2011 21:46:37 Stephane Fillod wrote:
> Mar, Jun 21, 2011, Nirgal skribis:
> > Some minor glitches I noticed:
> > - "VFO" information is not refresh in LCD when another windows goes over ours.
> 
> I remember experiencing that glitch, but I've been unable to reproduce
> it on Ubuntu 11.04.

Here, the "VFO A" lcd display appears only once, and on change.
If I just minimise and restore the window, that display is gone.

[Groundstation-developer] groundstation-commits@lists.sourceforge.net is back

[Nirgal <con...@ni...>]

I updated our CVSROOT/loginfo file using
http://sourceforge.net/apps/trac/sourceforge/wiki/CVS hook scripts
and
http://sourceforge.net/apps/trac/sourceforge/wiki/CVS syncmail
so that automatic mailings to gro...@li... is now fixed.

If you'd like to subscribe:
https://lists.sourceforge.net/lists/listinfo/groundstation-commits

Re: [Groundstation-developer] Now using left/right rather than up/down

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

Jau, Jun 23, 2011, Nirgal skribis:
> On Tuesday 21 June 2011 21:46:37 Stephane Fillod wrote:
> > > - I am anoyed by new up/down shortcuts. I've been using them to navigate through combo-boxes. What about changing these to left/right keys?
> > 
> > You've got my vote.
> 
> I've just commited that change.

Works great! Thanks.

Now, one would expect some kind of basic tuning step (in combo-box?)
instead of the default minimum freq resolution. But expecting too
much features is only going to postpone the expected release :-/

Do you have any wishes before making the release? How long for
the beta-testing?

Rem: I've just commited an automake silent rule in configure.ac

Cheers
-- 
Stephane

[Groundstation-developer] Now using left/right rather than up/down

[Nirgal <con...@ni...>]

On Tuesday 21 June 2011 21:46:37 Stephane Fillod wrote:
> > - I am anoyed by new up/down shortcuts. I've been using them to navigate through combo-boxes. What about changing these to left/right keys?
> 
> You've got my vote.

I've just commited that change.

Re: [Groundstation-developer] Commit

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

Mar, Jun 21, 2011, Nirgal skribis:
> On Sunday 19 June 2011 22:18:53 Stephane Fillod wrote:
> > BTW, what MEM/VFO switch are you talking about?
> 
> The NEWS file for 0.8 specifies new functionalities. One of them starts with a '*': Support for VFO->MEM and MEM->VFO function.
> I'm not quite sure what this mean.

I guess this is the "M / V" button, which toggles between Memory and
VFO. Rem: there's no such Memory mode on the PCR-1500, but you may
have a look at it with the Dummy backend.

Not to be confused with rig_vfo_op(FROM_VFO)/rig_vfo_op(TO_VFO)
which may be added later.

> > I'd say, the only expected feature missing before a release is
> > the support for frequencies in the GHz range, ie. adding one most
> > significant digit.
> 
> I just commited that change.

Great!

> > Maybe some patches have accumulated in Debian/FC/.. repos, so integrating
> > them in the 0.8 release would be a Good Thing(tm).
> 
> I checked Debian, Unbuntu, BSD, Fedore, Geentoo, RedHat: All hot fixes are already present in our CVS trunk. :)

Excellent :-)

> > It has to be said that grig is in semi-abandon state. Some features
> > are great, some others need refactoring. The double-buffered thread
> > for GUI responsiveness's sake is killing us. Hamlib's type channel_t
> > and channel_cap_t along with rig_get_channel() would make life easier
> > on grig_settings_t/grig_cmd_avail_t. If need be, Hamlib's API can be
> > extended so as to make writing generic rig UI simpler.
> 
> GUI responsiveness sure is a killer. I did not look enough into the code yet to suggest an improvement yet.

Alex sure did identify that issue, which led to the internal rig daemon.

In a nutshell, the issue lies with the fact that chatting with
a real rig is slow, because of the serial communication. Since Hamlib
calls are synchronous, it's killing GUI responsiveness, unless chatting
is done in its own thread.

> Some minor glitches I noticed:
> - "VFO" information is not refresh in LCD when another windows goes over ours.

I remember experiencing that glitch, but I've been unable to reproduce
it on Ubuntu 11.04.

> - I am anoyed by new up/down shortcuts. I've been using them to navigate through combo-boxes. What about changing these to left/right keys?

You've got my vote.

> - There are a few glitches when you press random buttons while in frequency enter mode, like VFO switch.
> 
> > Right now, after a 0.8 release, I'd advocate for a rewrite in python,
> > using either fltk or gtk. This is based on my experience with Pyrime[1],
> > where PyQt's QTableWidget was nice, but not necessary for a rig UI.
> 
> I love python...

Fine, so let's first take care of the release of grig 0.8.
We're going to need beta-testers. Your Debian package will be
quite handy for that matter. BTW, is the version grig_0.7.2+cvs20100302 
supposed to match current?

Cheers
-- 
Stephane

[Groundstation-developer] Commit

[Nirgal <con...@ni...>]

On Sunday 19 June 2011 22:18:53 Stephane Fillod wrote:
> BTW, what MEM/VFO switch are you talking about?

The NEWS file for 0.8 specifies new functionalities. One of them starts with a '*': Support for VFO->MEM and MEM->VFO function.
I'm not quite sure what this mean.

> I'd say, the only expected feature missing before a release is
> the support for frequencies in the GHz range, ie. adding one most
> significant digit.

I just commited that change.

> Maybe some patches have accumulated in Debian/FC/.. repos, so integrating
> them in the 0.8 release would be a Good Thing(tm).

I checked Debian, Unbuntu, BSD, Fedore, Geentoo, RedHat: All hot fixes are already present in our CVS trunk. :)

> It has to be said that grig is in semi-abandon state. Some features
> are great, some others need refactoring. The double-buffered thread
> for GUI responsiveness's sake is killing us. Hamlib's type channel_t
> and channel_cap_t along with rig_get_channel() would make life easier
> on grig_settings_t/grig_cmd_avail_t. If need be, Hamlib's API can be
> extended so as to make writing generic rig UI simpler.

GUI responsiveness sure is a killer. I did not look enough into the code yet to suggest an improvement yet.

Some minor glitches I noticed:
- "VFO" information is not refresh in LCD when another windows goes over ours.
- I am anoyed by new up/down shortcuts. I've been using them to navigate through combo-boxes. What about changing these to left/right keys?
- There are a few glitches when you press random buttons while in frequency enter mode, like VFO switch.

> Right now, after a 0.8 release, I'd advocate for a rewrite in python,
> using either fltk or gtk. This is based on my experience with Pyrime[1],
> where PyQt's QTableWidget was nice, but not necessary for a rig UI.

I love python...

[Groundstation-developer] [patch] dump_hex calling rig_debug() for full lines

[Nirgal <con...@ni...>]

Hi

I've been using grig for a week and I noticed that dump_hex function shows ok in hamlib, but shows as several lines in grig.

Exemple in rigctl:
TX 20 bytes
0000    4b 30 30 31 34 35 30 30 30 30 30 30 30 35 30 32    K001450000000502
0010    30 30 0d 0a                                        00..

Exemple in grig:
TX 20 bytes
0000    4b
 30
 30
 31
 34
 35
 30
 30
 30
 30
 30
 30
 30
 35
 30
 32
    K001450000000502
0010   
 30
 30
 0d
 0a
    00..

This is because dump_hex calls rig_debug() several time by line, and grig kinda assume last character of each call is \n.

Attached is a patch that changes dump_hex() so that there is only one rig_debug call by line.
(available at http://www.nirgal.com/hamlib/ if striped by mailing list software)

One could argue this is a bug in the front end that should assemble lines that don't ends with \n, but I believe it is a comon problem and the easiest thing is to fix at the source. It should not hurt anyways.

Enjoy!

Re: [Groundstation-developer] [patches] man, warnings, translation. developer offer.

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

Dim, Jun 19, 2011, con...@ni... skribis:
> I started to write a patch to fix the problems with the debug levels, then I realized it was fixed in csv more than a year ago!
> 
> What is preventing release of version 0.8? Only the MEM/VFO switch? And the lack of developer I guess...
> I'm volunteering. My sf account is nirgal-v.

Indeed, grig is in need of developers and a release.
Thanks for volunteering.

BTW, what MEM/VFO switch are you talking about?

I'd say, the only expected feature missing before a release is
the support for frequencies in the GHz range, ie. adding one most
significant digit.

Maybe some patches have accumulated in Debian/FC/.. repos, so integrating
them in the 0.8 release would be a Good Thing(tm).

It has to be said that grig is in semi-abandon state. Some features
are great, some others need refactoring. The double-buffered thread
for GUI responsiveness's sake is killing us. Hamlib's type channel_t
and channel_cap_t along with rig_get_channel() would make life easier
on grig_settings_t/grig_cmd_avail_t. If need be, Hamlib's API can be 
extended so as to make writing generic rig UI simpler.

Right now, after a 0.8 release, I'd advocate for a rewrite in python,
using either fltk or gtk. This is based on my experience with Pyrime[1],
where PyQt's QTableWidget was nice, but not necessary for a rig UI.

[1] https://sourceforge.net/apps/mediawiki/hamlib/index.php?title=Pyrime

> Attached are a few patches:
> - debian lintian was warning about usage of unescaped '-' in man
> - removed a bunch of unused vars
> - added some source files to the list that should be translated
> 
> I packaged last cvs version for debian (unofficial) i386 at http://www.nirgal.com/debian/pool/main/g/
[..]
>Looks like that list is striping the attachments. They are available
>here: http://www.nirgal.com/hamlib/grig/

Your access to the project is going to be granted so you can soon
commit the patches yourself.
-- 
Stephane