470c71dd93
I have an MD-01 controller running firmware 2.0.237 that is connected
to the computer via the COM0 DB9 port. When it receives a control
command to move the rotator, it prints debug logs to the serial output
that look like this:
input:
W3600\x0A4500\x0A\x2F\x20
output:
W\x03\x06\x00\x00\x0A\x04\x05\x01\x00\x0A\x20
287925671: in motion\r\n
287925673: Change motion state M0 to mcsStart\r\n
287925678: GO A 0.000000 0.000000 t ---\r\n
287925680: in motion\r\n
287925683: Change motion state M1 to mcsStart\r\n
287925686: GO E 90.000000 91.000000 t ---\r\n
287925690: distance to go M0 too small. End.\r\n
287925694: Change motion state M0 to mcsStopped\r\n
287925698: Stop on motor 0 on angle 0.000000\r\n
287925703: Change motion state M1 to mcsRunning\r\n
287926610: distance to go M1 too small. End.\r\n
287926613: Change motion state M1 to mcsStopped\r\n
287926617: Stop on motor 1 on angle 90.000000\r\n
Note that the response frame is not necessarily present in an specific
order relative to the log messages: I have seen it come after the logs
as well. Because the current implementation just slurps up response
bytes without checking the framing or anything, as soon as any of this
log data enters the command stream, all subsequent commands will read
completely bogus responses.
Regardless of whether it's due to a misconfiguration, a weird artifact
of the firmware, or something more sinister, the MD-01 is awkwardly
interspersing its normal fixed-size-frame response with these
line-based log messages. As shown above, the log messages appear to be
consistently of the format <timestamp>: <message>\r\n, where
<timestamp> is some kind of integer timestamp (possibly relative to
unit boot) and <message> is an ASCII string.
Due to poor(?) design decisions by the protocol designers, the frame
start and end bytes are both printable ASCII characters ('W' and ' '
respectively) and the MD-01 response frame contains no other
validation information (such as a CRC), which means that a valid log
line could fairly easily contain a character sequence that is
indistinguishable from a valid response frame, without actually being
a valid response frame.
However, since the log messages appear to be reasonably strictly
structured, we can make a small number of assumptions that will allow
us to reliably separate response frames from log lines without having
to fall back on a heuristic-based parsing strategy. These assumptions
are as follows:
1. A log line will always begin with an ASCII character in the range
[0-9], none of which are the frame start byte.
2. A log line will never contain \r\n in the middle of the line (i.e.
multi-line log messages do not exist). This means a log "frame" will
always be of the form [0-9]<anything>\r\n.
3. The controller will not emit a response frame in the middle of a log
line.
4. The operating system's serial port read buffer is large enough that
we won't lose data while accumulating log messages between commands.
Provided the above assumptions are true, a simple state machine can be
used to parse the response by treating the log lines as a different
type of frame. This could be made much more robust by applying
additional heuristics for specific packets (e.g. get_position has some
reasonably strict numerical bounds that could be used to sanity check
the contents of the reply frame).
|
||
|---|---|---|
| .github | ||
| amplifiers | ||
| android | ||
| bindings | ||
| c++ | ||
| doc | ||
| docker-build | ||
| extra | ||
| include | ||
| lib | ||
| macros | ||
| perl | ||
| rigs | ||
| rotators | ||
| scripts | ||
| security | ||
| simulators | ||
| src | ||
| tests | ||
| .editorconfig | ||
| .gitignore | ||
| AUTHORS | ||
| Android.mk | ||
| COPYING | ||
| COPYING.LIB | ||
| ChangeLog | ||
| INSTALL | ||
| LICENSE | ||
| Makefile.am | ||
| NEWS | ||
| PLAN | ||
| README | ||
| README.betatester | ||
| README.coding_style | ||
| README.developer | ||
| README.freqranges | ||
| README.md | ||
| README.multicast | ||
| README.osx | ||
| README.release | ||
| README.win32 | ||
| SECURITY.md | ||
| Segfault-award | ||
| THANKS | ||
| VFOs.txt | ||
| astyle.sh | ||
| bootstrap | ||
| configure.ac | ||
| cppcheck.sh | ||
| hamlib.m4 | ||
| hamlib.pc.in | ||
README.md
Hamlib - (C) Frank Singleton 2000 (vk3fcs@ix.netcom.com) (C) Stephane Fillod 2000-2011 (C) The Hamlib Group 2000-2022
The purpose of this project is to provide stable, flexible, shared libraries that enable quicker development of Amateur Radio Equipment Control Applications. The master repository is https://github.com/Hamlib/Hamlib Daily snapshots are available at https://n0nb.users.sourceforge.net/ Development happens on the github master (often by merging feature branches) and each release has a release branch.
Many Amateur Radio Transceivers come with serial interfaces that allows software to control the radio. This project will endeavour to provide shared libraries that greatly simplify the application programmer's interaction with radio equipment and other controllable devices such as rotators, switches, etc.
Supported Radios
The Hamlib Wiki page, Supported Radios, contains a snapshot of the supported radios at the time of the last Hamlib release. Go to http://www.hamlib.org to reach the Wiki.
Hamlib Design
The library provides functions for both radio and rotator control, and data retrieval from the radio or rotator. A number of functions useful for calculating distance and bearing and grid square conversion are included.
libhamlib.so - library that provides generic API for all RIG types. This is what Application programmers will "see". Will have different names on other platforms, e.g. libhamlib-2.dll on MS windows. Also contains all radio and rotator "backends" (formerly in their own dlopen'ed libraries) provided by Hamlib.
Backend Examples are:
-
yaesu will provide connectivity to Yaesu FT 747GX Transceiver, FT 847 "Earth Station", etc. via a standard API.
-
xxxx. will provide connectivity to the Wiz-bang moon-melter 101A (yikes..)
Hamlib will also enable developers to develop professional looking GUI's towards a standard control library API, and they would not have to worry about the underlying connection towards physical hardware.
Initially serial (RS232) connectivity will be handled, but we expect that IP (and other) connectivity will follow afterwards. Connection via a USB port is accomplished via the Linux kernel support. USB to serial converters are well supported. Other such devices may be supported as long as they present a serial (RS-232) interface to Hamlib.
Availability
Most distributions have the latest Hamlib release in their testing or alpha versions of their distribution. Check your package manager for the Hamlib version included in your distribution.
Developing with Hamlib API
API documentation is at:
https://github.com/Hamlib/Hamlib/wiki/Documentation
Take a look at tests/README for more info on simple programming examples and test programs.
C++ programming is supported and language bindings are available for Perl, Python, and TCL. A network daemon utility is also available for any programming language that supports network sockets (even netcat!).
Recompiling
Hamlib is entirely developed using GNU tools, under various Linux systems. The library may be recompiled by the familiar "three step":
Note: if ./configure does not exist run ./bootstrap first
./configure
make
sudo make install
For debugging use this configure ./configure CFLAGS=-g -O0 -fPIC --no-create --no-recursio
See the INSTALL file for more information.
Contributing
Consult the README.betatester and README.developer files in this directory if you feel like testing or helping with Hamlib development.
Contributions of rig specifications and protocol documentation are highly encouraged. Do keep in mind that in some cases the manufacturer may not provide complete control information or it is only available under a Non-Disclosure Agreement (NDA). Any documentation must be publicly available so we can legally write and distribute Free Software supporting a given device.
The Hamlib team is very interested to hear from you, how Hamlib builds and works on your system, especially on non-Linux system or non-PC systems. We try to make Hamlib as portable as possible.
Please report in case of problems at hamlib-developer@lists.sourceforge.net Git email formatted patches or in unified diff format are welcome!
Also, take a look at http://sourceforge.net/projects/hamlib/ Here you will find a mail list, link to the Wiki, and the latest releases. Feedback, questions, etc. about Hamlib are very welcome at the mail list:
<hamlib-developer@lists.sourceforge.net>
Hamlib Version Numbers
Like other software projects, Hamlib uses a version numbering scheme to help program authors and users understand which releases are compatible and which are not. Hamlib releases now follow the format of:
Major.minor.incremental
Where
Major: Currently at 4, but can be advanced when changes to the API require client programs to be rewritten to take advantage of new features of Hamlib. This number has advanced a couple of times throughout the life of Hamlib. Advancement of the major number is only for frontend API changes that require modification of client source. ABI compatibility is presently maintained to prior releases so that a program linked to an earlier 1.2.Y.[Z] release will work with a later 3.Y[.Z] release without recompiling. It is our intention to maintain such ABI compatibility as long as practical.
Minor: This number advances when either new backend(s) or new rig model(s) to existing backend(s) are added. Advancing this number informs client program authors (and users of those programs) that new model/backend support has been added. Will also include bug fixes since the last Incremental release.
Incremental: May be undefined (e.g. Hamlib 3.0) and would advance to 1 (e.g. Hamlib 3.0.1) for any bug fixes or feature additions to existing model(s) or backend(s), then to 2, etc. New rig models or backends are not included in Incremental. When Release is advanced, Incremental will reset to undefined and will not be included as part of the version number.
Release schedule
Hamlib has in the past maintained a "ready when it's ready" philosophy. However, given that much of the Linux user base is now influenced by the Ubuntu distribution and its timed six month release schedule, Hamlib releases will be scheduled in advance of Ubuntu releases. Planned release dates for Hamlib are now 1 February and 1 August of each calendar year. Between those dates various Incremental releases will occur as development warrants.
Have Fun / Frank S / Stephane F / The Hamlib Group
73's de vk3fcs/km5ws / f8cfe