| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Mark as broken on i386
Note typo with include_directories had no effect on build but fixed anyway
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-----------------------------
Short list of new features
--------------------------
1. New modes: ISCAT, MSK144, QRA64.
2. Newly implemented submodes: JT65B-C, JT9B-H (wide and fast).
3. FT decoder replaces KV decoder for JT65; KVASD is no longer used.
4. Improvements to JT4, JT9, and JT65 decoders.
5. Multi-pass decoding now implemented for JT65 as well as WSPR.
6. Many improvements to Rig Control.
7. Improved convenience features for EME Doppler tracking.
8. Multiple configurations can be saved and restored.
9. Sample-file download facility.
10. Optional auto-sequencing for Fast modes.
11. Power settings optionally remembered for Transmit and Tune on a
band-by-band basis.
New Modes
---------
1. MSK144 is intended for meteor scatter at 50 MHz and higher. It
uses a low-density parity check code (LDPC) designed by Steve Franke,
K9AN. The mode is a direct descendant of the now-defunct mode JTMSK,
with a number of improvements for better performance on weak and short
meteor pings. The effective character transmission rate is about 250
cps, compared with 147 cps for FSK441. Like JT4, JT9, JT65, and
QRA64, MSK144 uses strong forward error correction. Message decoding
is all or nothing: partial decodes do not occur, and you will see
little or no garbage on your screen.
Standard MSK144 message frames are 72 ms long, compared with about 120
ms for an equivalent FSK441 message. The MSK144 waveform allows
coherent demodulation, allowing up to 3 dB better sensitivity. After
QSO partners have exchanged callsigns, MSK144 can use even shorter
messages, only 20 ms long. As in all the fast modes in WSJT-X, the 72
ms (or 20 ms) messages are repeated without gaps for the duration of a
transmission cycle. For most purposes we recommend a T/R cycle
duration of 15 s, but 5 s and 10 s sequences are also supported.
Short ("Sh") messages in MSK144 are intended primarily for 144 MHz and
higher frequencies, where most pings are very short. These messages
do not contain full callsigns; instead, they contain a hash of the two
callsigns along with a report, acknowledgement, or 73. Short messages
are fully decodable only by the station to whom they are addressed, as
part of an ongoing QSO, because only then will the received hash match
that calculated using the known strings for "My Call" and "DX Call".
If you are monitoring someone else's QSO, you will not be able to
decode its Sh messages.
An MSK144 signal occupies the full bandwidth of a typical SSB
transmitter, so transmissions are always centered at an offset of
1500Hz. For best results, selectable or adjustable Rx and Tx filters
should be set to provide the flattest possible response over at least
300 - 2700 Hz. The maximum permissible frequency offset between you
and your QSO partner is 200 Hz, and less is better.
2. QRA64 is a intended for EME and other weak-signal use. Its
internal code was designed by Nico Palermo, IV3NWV, and implemented in
WSJT-X by K1JT. The protocol uses a "Q-ary Repeat Accumulate" code --
along with LDPC, another one of the latest research areas in
communication theory. The QRA64 code is inherently better than the
Reed Solomon (63,12) code used in JT65, yielding already a 1.3 dB
advantage. QRA64 uses a new synchronizing scheme based on a 7 x 7
Costas array, so you will not see a bright sync tone at the lowest
tone frequency. This change yields another 1.9 dB advantage.
In most respects our implementation of QRA64 is operationally similar
to JT65. QRA64 does not use two-tone shorthand messages, and it makes
no use of a callsign database. Rather, additional sensitivity is
gained by making use of "already known" information as a QSO
progresses -- for example, when reports are being exchanged and you
have already decoded both callsigns in a previous transmission. QRA64
presently offers no message averaging capability, though that may be
added. In our early tests, many EME QSOs have already been made using
submodes QRA64A-E on bands from 144 MHz to 10 GHz.
3. ISCAT is essentially the same as in recent versions of program WSJT.
For details consult the WSJT User Guide:
http://physics.princeton.edu/pulsar/K1JT/doc/wsjt/
Program Setup
-------------
Many of the new program capabilities are enabled when you check
"Enable VHF/UHF/Microwave features" on the Settings | General tab.
For MSK144 mode, we suggest setting "T/R 15 s" and "F Tol 100 Hz".
Check "Sh" to enable the use of short messages and "Auto Seq" for
auto-sequencing. For QRA64 mode, set Tx and Rx frequencies to 1000
Hz. We encourage you to check "Save all" when making tests, and to
save any of the resulting .wav files that might help us to improve
program performance or behavior, or to illustrate a problem that you
identify.
Final Comments
--------------
We will be grateful for any and all reports from users; these will
surely help us to make further improvements to WSJT-X. The most
helpful bug reports describe the problem clearly and include a
complete recipe to reproduce it. Feature requests are also welcome.
Send your reports to wsjtgroup@yahoogroups.com, or to the developers
list wsjt-devel@lists.sourceforge.net.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
lang/gcc which have moved from GCC 4.8.5 to GCC 4.9.4 (at least under some
circumstances such as versions of FreeBSD or platforms), part II.
The first part covered ports with USE_GCC=yes, USE_GCC=any, or one of
gcc-c++11-lib, openmp, nestedfct, c++11-lib as well as c++14-lang,
c++11-lang, c++0x, c11 requested via USES=compiler.
This adds ports with USES=fortran and ports using Mk/bsd.octave.mk
which in turn has USES=fortran.
PR: 214965
Reported by: thierry
|
| |
|
|
| |
Approved by: portmgr blanket
|
| |
|
|
|
|
|
|
|
| |
Add missing dependancy so it builds man pages and user manual (db@)
Since they are using Sourceforge, clean up distfiles (db@)
No binary changes.
Reviewed by: shurd,db
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For quick reference, here's a short list of features and capabilities added
to WSJT-X since Version 1.5.0:
WSPR mode, including coordinated automatic band-hopping and a new
two-pass decoder that can decode overlapping signals.
EME-motivated features including JT4 (submodes A-G), Echo mode, and
automatic Doppler tracking. The JT4 decoder is more sensitive than
that in the latest WSJT, and message averaging is fully automated.
(Note that submodes JT65B and JT65C are also present in Version 1.6,
but the high-sensitivity decoder required for EME with JT65
is not yet included.)
Tools for accurate frequency calibration of your radio, so you can
be always on-frequency to within about 1 Hz.
Mode-specific standard working frequencies accessible from the
drop-down band selector.
A number of corrections to the Hamlib library, fixing balky rig-control
features. A few unreliable features peculiar to particular radios
have been removed.
Working around bugs with a2x for now
PR: ports/208350
Submitted by: takefu@airport.fm
|
| |
|
|
|
| |
With hat: portmgr
Sponsored by: Absolight
|
| |
|
|
|
| |
./WFPalette.hpp:53:1: error: unknown type name 'Q_DECLARE_METATYPE'
Q_DECLARE_METATYPE (WFPalette::Colours);
|
| | |
|
| |
|
|
| |
No change to actual port produced binaries results.
|
|
|
optimized for meteor scatter, ionospheric scatter, and EME (moonbounce)
at VHF/UHF, as well as HF skywave propagation. The program can decode
fraction-of-a-second signals reflected from ionized meteor trails and
steady signals 10 dB below the audible threshold.
This version is a non python Qt app.
|
