Page 1 of 1

Juma TRX-2 V3.00a Build 24

PostPosted: 13 Jan 2017 08:49
by 5B4AIY
Juma TRX-2 Firmware, Version: 3.00a Build 24.

Build 23 has been removed. As a result of a minor code move to resolve an internal low-level annoyance, I accidentally omitted the offset cancelation in the TX mode, and thus the CW/CWR/RIT offset from the RX mode was still present in the TX mode. My sincere apologies to all, please replace your previous build with this version.

I felt that in the interests of consistency the PWR button contact bounce suppression and primary/secondary function selection logic should be the same as that used by the other buttons, and to that end, this firmware incorporates this change.

Whilst this build does not offer any new features, it does provide an enhanced button de-bounce and function select logic. In all the previous versions, the logic of contact bounce suppression and primary/secondary function selection was implemented by separate functions. Build 20 improved the button contact bounce suppression logic, but there was a slight flaw which required a fix to correct. I inherently dislike 'fixes', and so over the Christmas and New Year period I decided to re-design the logic, and combine the contact bounce suppression and primary/secondary function selection logic with a view to simplifying and streamlining the code.

To understand how this now works, there is a description in the file juma-trx2.h, the header file, but briefly, a long integer global variable button_count is preset to a value each time through the main loop. If a button press is detected, then a loop of code is entered which checks to see if the button is still pressed, in which case button_count is decremented. If the contact has bounced open, button_count is incremented. The loop exits either when button_count reaches zero, or when it has reached the upper limit value. During the contact bounce phase the value of button_count will oscillate around some value near its original setting, but as soon as the contact has settled into its final state, then its value will rapidly increment if it is now open, or decrement if it is closed. If the exit value is zero, then this corresponds to a long push or secondary function, if it has reached its limit value, then this is a short push, or primary function.

This is implemented by the macro button_debounce() defined in the header file. One slight subtlety, if the code were implemented exactly as above then the value of button_count would increment or decrement at exactly the same rate. If this was done, then if the button was pressed and released just before the value reached zero, then button_count has to increment all the way to its limit value, and this took a noticeable amount of time. To avoid this, and give a 'snappier' short push selection, the value is decremented by 1 each time for a button contact closure, but it is incremented by 2 when the contact is open, thus ensuring a faster exit in the primary function selection case.

Code hounds will note that I have used the microprocessor's instructions as timing elements. Normally this practice is to be severely deprecated, and certainly for Complex Instruction Set Computers (CISC) this practice is highly unreliable! This is because these processors utilise various hardware techniques such as cache memory, look-ahead logic, etc, and thus the actual timing of a group of instructions is highly variable. However, the dsPIC30F6014A series of machines are Reduced Instruction Set Computers, (RISC), and in this case the vast majority of instructions take exactly 1 machine cycle to execute, with only a very limited number taking 2 or 3 cycles, and typically only branch instructions can be either 1 or 2 cycles depending upon whether the branch is taken or not. Interestingly, the multiply instruction only takes 1 machine cycle, but the divide takes 18! Thus, in this special case, bearing in mind the fixed known speed of the main clock, and as the timing does not need to be very precise - we are after all considering times of the order of 200mS or more - then I felt that using the instruction timing was justified. You, of course, are welcome to disagree!

This version therefore manages to fully suppress contact bounce without any false states, as well as positively determining both primary and secondary function selection.

This version does not change any EEPROM mapping or value, and therefore can be safely loaded over a previous version 3.00a. Nevertheless, as with any firmware update it is a wise precaution to make a note of your existing calibration and configuration settings prior to loading this new version. There are pages prepared for this at the back of the User Manual.

73, Adrian, 5B4AIY

Re: Juma TRX-2 V3.00a Build 23

PostPosted: 10 Apr 2017 17:15
With this and December 2016 builds I have problem with CW. TX transmits on the wrong frequency i.e. synthesizer remains on the same RX offset frequency instead going to actual transmit frequency. I went back to build 16, which has no problems on CW.


Re: Juma TRX-2 V3.00a Build 23

PostPosted: 11 Apr 2017 08:44
by 5B4AIY
You are so right, I sincerely apologise to everyone for this oversight on my part, and thank you for bringing it to my attention. Build 23 has now been removed and replaced with Build 24 which fixes this problem. It was caused by a 'minor' movement of some code, but I omitted to include the offset cancelation in the TX mode. As an old software adage states, "The more innocuous the change, the more widespread its effects!" and, of course, "There's always one more bug!"
Adrian, 5B4AIY

Re: Juma TRX-2 V3.00a Build 24

PostPosted: 13 Apr 2017 20:28
Hello Adrian

Thanks for the quick fix. New build 24 works fine.

73 Jorma OH8FIU