Digital mode in software v.2.11.81

[SP5QAD]

UHSDR Firmware Defect Issue (Bug) Template 1.1

Issue Data goes here (please remove text above):

Your firmware version: 2.11.81 Your bootloader version: 5.0.4 (Please note, we will generally not accept issue reports if your bootloader is not at least 5.0.1)

Hardware

• UI Board: mcHF 0.6
• RF Board: mcHF 0.6

Describe the issue:

Welcome back. Here are my observations made while testing digital transmissions in v.2.11.81 software (apart from the problem described in the "PSK mode" post): (keyboard connected directly to the device: logitech k400 +)

1. Record macros (F1 - F3): a) entering a single line (without pressing "Enter") - works correctly, b) when entering multiline text (using the "Enter" key), despite the end of recording, it remains in the "REC" mode.

2.Playing recorded macro (F1 - F3): a) BPSK - plays correctly, b) RTTY - incorrect transmission. "Strange" text, but repetitive.

3. Direct typing on the keyboard while transmitting: a) BPSK - works correctly, b) RTTY - works correctly.

---

73, Marcin SP5QAD

[db4ple]

For 2b (RTTY play macro): Is the text shown correctly on screen while transmitting?

[SP5QAD]

Yes, on the mcHF display the text is displayed as it was saved in the macro, but it is not transmitted correctly -> the transmission is not correctly decoded on another device. Besides, it seems to me that, as for RTTY broadcast, the text appears on the display too quickly (maybe this is my subjective feeling). 73, Marcin.

[db4ple]

Yeah, from looking at the code and confirmed by your observation about the speed I think there is something wrong how the macro letters are read out and translated into rtty bits... Needs some further investigation on the real thing.

[SP5QAD]

As soon as there is a software update, I will be happy to test it. I like working in digital modes, and thanks to mcHF I can do it in the open air (WWFF etc.) without taking an extra computer with me - always a little less kilograms in my backpack ;-) Thank you to all programmers who devote their time to the development of this project. If my games (tests) help, I will be happy.

73 Marcin

[db4ple]

The RTTY thing could be fixed by #1853 (or at least one bug in the rtty code was fixed), but the ENTER issue not.

[db4ple]

@SP5QAD : I verified that my fix in #1853 does indeed solve the problem that only every second macro character was transmitted in RTTY mode.

However, I still don't understand your problem 1. If you use Enter in recording mode, the Enter is being added to the macro text, which permits to record multiline macros. Recording a macro is always ended by a short press on the respective macro key on the device. When playing macro in buffered mode (TX B shown above F5 button), the transmission stops after all macro text has been sent.

I don't seem to see the problem. Can you please elaborate?

[SP5QAD]

Hello, I uploaded a new version of the software and ... sending the macro works perfectly :-) When it comes to entering multiline text, it also works, but only if the macro begins with the text. If I would like the decoded text to start on a new line (without garbage before transmission), I should start the transmission with "Enter" so that the correct text appears on the new line - on the computer where it is decoded. And this is where the surprises start: If I start recording the macro with "Enter", then briefly pressing the button under which it is recorded does not exit the recording mode (the word "REC" is still there). I suppose this is due to the fact that after recording the macro, its description is the first word entered, and in this case it is "Enter" :-(

By the way: By running try RTTY I have the option in the second line of options on the display being able to change values ​​such as "BD" and "SFT". If I press "MODE" now - I switch to "LSB" mode, but the "BD" and "SFT" change options are still active. The transition to settings compatible with the current operating mode appears only after pressing "AF" and "RF": change from "BD" to "CMP" and change from "STF" to the speed of "AGC".

Thank you for enabling work on RTTY using macros. I hope that my above and subsequent observations will allow for even better operation of the device.

73 ' Marcin

[db4ple]

Hi Marcin, could you please create a separate report for the RTTY issue in your last comment. Otherwise things get very confusing.

[db4ple]

The Enter issue is basically a display issue. Everything except setting the label works as it should, i.e. the macro is recorded, recording stops once you press the respective button etc. The code just does not generate a proper label as far as I can see.

[SP5QAD]

Which problem in the new report?

1. Record a macro where the first "character" is "Enter".
2. Exit RTTY mode? Are two new reports?

[SP5QAD]

When it comes to recording macros that start with "Enter": I checked, and indeed the macros are recorded, are played correctly (as expected, the decoded text on another device appears from the new line) but:

1. the red label "REC" remains as the label,

2. after exiting the main menu and returning to the macro menu again, where the macro was recorded beginning with "Enter", the name assigned to the key from the main menu appears as the label. And so for such a macro attached to "F1" we have the label "MENU", for "F2" the label is "SNAP" and for the macro assigned to "F3" - "SPLIT". After pressing one of these buttons, the macros play correctly - starting with "Enter" as the first line. I've seen such miracles here ;-)

   Marcin, SP5QAD

[db4ple]

PR #1856 should solve the problem with macro keyer button labels. The new issue to create: the "BD/SFT" stuff you described. "One issue, one problem -> different problem, new issue" is the rule to apply.

[SP5QAD]

Done. And by the way: no images on the page downloaded updates in the table "Binaries Download Area" (at least for me, browser: Chrome). The link to v2.11.82 works fine :-)

[SP5QAD]

Software test results v.2.11.84:

1. Macro support: for me - perfect :-)

2. RTTY transmission test: Text entered from a wireless USB keyboard: logitech k400 (works as expected)

Transmissions decoded in the program "MULTIPSK v.4.43

noticed errors: instead of "0" -> "Ø" appears (in the "MULTIPSK" program it looks like 'R' with a bird at the top. maybe it's a character set, but it can leave '0' as '0' instead of replacing with 'Ø'? "0" on The display in mcHF and in MULTIPSK" looks as it should be, it differs from the letter 'O' - also checked after decoding the transmission broadcast from MULTIPSK)

Characters he didn't give: '!', '@', '#', '$', '%', '^', '&', '*', '_' '[', ']', '{', '}' ';', '"', '\', '|' '<', '>'

In my opinion, the signs: '!' and '@' could be broadcast.

3. Broadcasting from the MULTIPSK program, decoding to mcHF: characters incorrectly decoded: sent -> decoded '!', '@', '#' -> '.' '*' -> '#' '' '(single quotation mark, apostrophe) ->', '(comma) '?' -> '7'

signs: '%', '^', '&', '*', '_', '[', ']', '{', '}', ';', '"', '\', '| ' '<', '>' they were also not broadcast from the MULTIPSK program.

- Greetings, Marcin SP5QAD.

[SP5QAD]

I found it, this "R" stamp with a bird on top, which I wrote about earlier, has the code U+0216

[SP5QAD]

And it looks like this: Ř

[SP5QAD]

The main topic concerned macros. The operation and handling of macros has been improved in 2.11.84. This thread seems to be terminated. Additional issues that arose during the course were placed in separate entries.

Thank you to everyone who in such a short time contributed to the removal of noticed irregularities.

73, Marcin.