Juma TRX-2 Firmware Version 7.00a Build 3

[5B4AIY]

WARNING! THIS VERSION WILL CAUSE A CHECKSUM ERROR ON FIRST POWER UP BECAUSE THE EEPROM MAP HAS CHANGED. MAKE A NOTE OF YOUR CALIBRATION & CONFIGURATION SETTINGS PRIOR TO LOADING.


04/09/2023
I accidentally uploaded a slightly different version yesterday. The revised version is here. The only change is that the previous version incremented the TX Delay from 1mSec to 50mSec in 1mSec increments. This version is correct, it increments from 5mSec to 50mSec in 1mSec increments. My apologies. If you have already loaded the previous version, then this version can be safely loaded over it without incurring a checksum error. If you have set your delay to less than 5mSec, simply enter the User Configuration Menu, skip to the TX Delay page, select your preferred setting and then save the new setting. I have also added some additional screenshots showing the normal and delayed TUNE and normal and delayed CW transmitted waveforms.

Version 7.00 adds a new feature - TX Delay. If the transceiver is used to drive a linear amplifier, for example a SPE Expert, then the HIGH SWR alarm can be triggered when switching into transmit because the linear's TX/RX changeover relays take some time to settle, and there is thus a momentary operation into an open-circuit. This version provides a delay to allow safe operation. Note that this delay is NOT required for either the PA-100 or the PA-1000 amplifiers. Since there is now an added page in the Configuration Menu to allow setting this delay, the EEPROM map had to be extended, and thus when the firmware is loaded on first power up the checksum will be incorrect, and thus the defaults will be loaded. Make a note of your calibration and configuration settings before loading this new version.

The delay can be set to OFF, or from 5mSec to 50mSec in 1mSec increments. For the SPE Expert linear tests have shown that 5mSec is satisfactory. Whilst this version is OK for SSB speech and CW, it may not be entirely satisfactory for DATA modes such as FT-8/JT-65/RTTY, etc. This is because the TX/RX logic of the transceiver is entirely in hardware, and although the microprocessor senses the TX Request from either a Morse key contact closure or the PTT switch, it does not intercept this request, and hence cannot introduce a delay. To effect a delay a bit of 'lateral thinking' was required such that in the CW/CWR and TUNE modes the CW modulator was turned off, and in the SSB modes the synthesiser was disabled so that no RF drive was present. The CW modes operate perfectly because in this case the CW logic is driven by the 1mSec interrupt timer and the CW modulator could be easily controlled. A side effect of this is that regrettably the first element, either a dot or a dash that is keyed will be shortened by the length of the delay, but as only 5 or 10mSec is normally required this is usually unnoticeable. Note also that it is the CW modulator that is being controlled, the CW rise time is preserved resulting in a clickless transmission. In the case of SSB speech, then this delay is entirely unnoticeable.

DATA modes are a different problem. If the DATA signal is present as the TX Request is made then there is a good possibility of a short RF spike being generated before the delay logic can catch things. See the attached oscilloscope screenshot for details. This is a 'worst-case' event which took several keying attempts to provoke. Unfortunately without a serious hardware and software modification, there is no way of avoiding this. Whether this spike will be troublesome is uncertain, certainly the PA might well see an open-circuit for 2 - 3mSec, too fast for the SWR logic to catch, but certainly undesirable. In any case, this transceiver is not well suited to 100% duty-cycle data mode operation. The heat sink has always been a bit marginal, and so if you intend to operate a data mode, do not drive the amplifier to more than about 3 - 5W maximum. This admonition to operate at no more than 50% maximum power is common with many other transceivers as well, so it is not really a reflection on this design.

Note that this version is only really required if you intend to use the transceiver with a linear amplifier other than the companion PA-100 or PA-1000 amplifiers. Consequently if you have no intention of operating with other linear amplifiers, then there is no need to update your firmware. In this case load the previous version which has been upgraded to a more robust out-of-band inhibit. Even in that version there is a possibility of a brief spike of radiated RF in a DATA mode before the out-of-band logic kicks in, depending upon exactly where in the main loop's cycle the TX Request occurred, again, a hardware limitation.

I would like to acknowledge the patience, cooperation and assistance of Juho Kontio, OH6EEC, who was instrumental in both suggesting this modification as well testing out several versions before arriving at the present revision.

73, Adrian, 5B4AIY

[ok1rp]

Dear Adrian,

thank a lot for latest build rev.
Is it necessary to make new cal pls?

73 - Petr, OK1RP

[5B4AIY]

Hi, Petr,
You would only need to recalibrate the transceiver if, when loading the new firmware it showed a checksum error on initial power up, showing that the defaults have been loaded. This is why I provided a page in the User Manual where you can note your current calibration and configuration settings. You can also dump them using the Serial Test facility. Most terminal programs will permit you to 'capture' the send and receive data into a text file, and when I rewrote the firmware I tried to make this serial test printout a nicely formatted text for just this purpose.

So, to summarise:
1. If you are updating the firmware to a higher major revision, i.e, from Version 6 to Version 7, or where I state that the EEPROM maps have changed, then yes, you must either save the current calibration and configuration data or else re-calibrate.

2. Calibration and Configuration data can be saved to a text file using the Serial Test facility and a terminal program.

73, Adrian, 5B4AIY