Hi Eduardo.

Although your posting may be a little off-topic, it inspires the idea of perhaps incorporating an encoding/decoding soft modem ‘core’ within Logger32, giving Logger32 more direct control over the RF communications without the constraints of JTDX, WSJT-X, MMVARI etc.

I imagine the soft modem would purely and efficiently handle the timing, message generation and formatting, audio generation/modulation, audio demodulation and message unpacking for FT8 (initially at least, maybe other digimodes in time), leaving Logger32 to handle all the rest, the higher-level functions e.g. the user interface, callsign lookups, rig control, logging, alerting, spotting, propagation prediction, mapping, QSLing, awards tracking, satellite tracking …

The modem and logging programs might communicate/interoperate through an Application Program Interface, using structured messages with specified formats (e.g. ADIF for QSO info?) and protocols (ideally networkable for multi-computer shacks and remote operation) for specified services (e.g. ‘Encode the following message in FT8 and generate it on the next even cycle: …’ .  If that API was open, it might link other modems (e.g. for CW, RTTY, PSK, digital voice …) and other logging programs (e.g. N1MM+ …), allowing us to mix-n-match whatever best suits our purposes while encouraging further innovation (e.g. dedicated, specialised modem hardware for better performance, variant/novel digimodes, cloud-based logging, multi-band/multi-station coordination, dynamic frequency and power management for path optimisation and QRM evasion, negotiated QSYs, net control, message handling, updated backwards-compatible versions of the API itself …).

73

Gary  ZL2iFB