Grig offers you a simple, fast and easy to use graphical interface to your radio. And it offers you the same user interface regardless of what kind of radio you are using. Grig will not try to mimic the look and feel of a particular radio front panel, instead it tries to offer you an ergonomical graphical user interface.
Don’t let the simple user interface fool you. Beneath it there is robust and scalable architecture that has been designed for smooth, near-real-time user experience.
Below you can find a description of the most significant features of grig.
Quick-Tune
Most wiz-bang-moon-melter rig control applications will give you a tuning-knob on the screen as primary frequency control device. While a tuning knob is a great thing on the fornt panel of a radio, it is really useless in a software application. Just try to imagine sweeping the 15 meter band using a software tuning knob and a mouse as primary control devices…
Tuning in grig is much easier! You simply click on the frequency digit you whish to change. Clicking with the left mouse button will increase the value by one, while clicking with the right button will decrease the value by one. The middle button will reset the digit to 0. Of course you can also use the mouse wheel to take many repetitive steps. The size of the tuning steps is no longer an issue since you can click on any digit, be that 10Hz or 1MHz.
Upcoming releases may also include Auto-Tune mode (click-and hold) as well as support for external tuning devices like the Powermate.
Robust, Deadlock-Free Design
Developers of graphical rig control applications are faced with a serious challenge, namely the integration of synchronous hardware protocols into an asynchronous graphical user interface. Way too often you will see applications that freeze and eventually crash due to delays or errors on the communication line. Grig solves this problem by separating the synchronous and asynchronous parts into two independent layers:
1. A service layer, which is responsible for the communication with the hardware using Hamlib. This is the synchronous part.
2. An application layer – the GUI – which is activated by user actions, e.g. mouse clicks. This is the asynchronous part, since user actions come at random times.
The two layers communicate with each other via a data buffer that provides shared access to the rig data. This separation will not allow failures or bottle-necks at hardware level to influence the performance of the user interface. This architecture will also allow easy integration of other user applications, e.g. a network rig server.
Upcoming releases of grig will improve the robustness even more by adding a watchdog to the service layer.
Concurrent Radio Access
The use of a rig control application should not mean Keep your fingers from the front panel! On the contrary, for best user experience it should not matter whether the operator is using the software application or the radio front panel to change the rig parameters.
Grig does not mind if you alter your radio settings via the front panel, and will happily update it’s internal state whenever a parameter changes (Note: This will only work on radios that support both reading and writing of parameters. Older radios may only have one-way CAT support, e.g. write only).
Concurrent Access can even be taken to a higher level by using the RPC-rig backend in Hamlib. This will allow you to share a radio device between different applications, e.g. grig, Xlog and gMFSK.
Oh, by the way… You can do this over a network, too…