Topics

uBitX on CW #v6


Vic WA4THR
 

I do not have a V6, but a friend who is not on the group has and is having some issues with CW operation. This is a quote from his email to me. Have others ruin into this and is there a fix? I don't see this issue on my V4:

The V6 sends a short dot, maybe a 1/4 dot, when keyed; then there is a short space, maybe a 1/4 space; then it sends good code until you stop sending; then there is a short space, maybe a 1/8 space; then, finally, a short dot, maybe a 1/8 dot.  I can see it on my spectrogram.  (Maybe I can figure a way to capture the spectrogram and send it to you.)  So, it looks like the first character is being truncated, but that is really not the case; it's sending extra characters at the start and end of sending.  After you get passed the initial keying it sends very good code..  The extra character at the end of a series of characters can be lived with; however the extra character at the being makes is very difficult.  It's like in the army using the BC610 transmitter:  you had to turn the transmitter on and then send -- a sort of missing push to talk deal  It's like that with the V6 except that when you turn the V6 on it sends the extra small dot character..  It does this whether the first character begins with a dot such as "R" or a dash such as "Q".

 

This must be fixed before the thing can be used in any meaningful way on CW.


Curt
 

Vic

He didn't say he was using strait key or paddle, but it seems he is describing normal behavior if the op doesn't compensate in straight key mode. I have made hundreds of cw contacts using my v4, but its different than the best qsk rigs with electronic TR like the qcx or k2 etc. I even have to adjust with my yaesu that uses a relay. There is a cw delay setting on v4 stock firmware, I found its default value works best for me.

73 curt


Vic WA4THR
 

He has the same results either using a keyer or a straight key, although it isn't clear to me whether it is happening with the internal keyer and a set of paddles as opposed to an external keyer. He describes it as having to "turn it on" by sending a dit or a dah (they result in the same truncated did on the output) and then when the relay is engaged sending is normal. it sounds like it is sending something as the transmit relay engages, and again when it disengages, so even if he toggled the relay on before sending, he would get a burst of RF just like he does when it times out at the end.  I'll suggest he play with the CW delay, but it seems to output that RF whenever it times out, anyway.

He is a long-time CW op and currently an NCS on a CW traffic net.

=Vic=


Bob Bennett
 

In my case, using a dual paddle, it takes about a second for the initial dit or dah. After that operation os OK as long as you maintain your rhythm. If your pause is too long, the next dit or dah is delayed that second again. 
--
Bob
NZ2Z


Dave Dixon
 

Hi Bob,
           ive found the same on my V6 and am very pleased with it now ive eventually got into the settings to change it from straight to paddle key .now on the hunt for a nice add on cheapishadjustable external cw filter.Dave G0AYD..


On Mon, 13 Jan 2020 at 16:52, Bob Bennett via Groups.Io <bobsmacbox=yahoo.com@groups.io> wrote:
In my case, using a dual paddle, it takes about a second for the initial dit or dah. After that operation os OK as long as you maintain your rhythm. If your pause is too long, the next dit or dah is delayed that second again. 
--
Bob
NZ2Z


Bob Bennett
 

Dave, 
   I’ll have to find out how to change that setting
--
Bob
NZ2Z


Jim
 

Would the (now discontinued) CW Conditioning Board (here) help fix this?  Seems easy enough to home brew this circuit.  Still waiting on my V6 to arrive, but I'm a CW-only kind of op and keenly interested in this.

73, Jim KK0U


Reed N
 

For straight key operation, I noticed that the delayBeforeCWStartTime variable was set to 50ms, which significantly messed up sending initial dots. Perhaps it's the same problem for paddle?


Reed


Gil Palmer
 

From Lou KI5FTY, posted on the uBitx Forum:
 
https://groups.io/g/BITX20/topic/39852896?p=,,,20,0,0,0::Created,,%23cw,20,2,0,39852896,ct=1&ct=1
 
"Found the problem with the transmit with trailing tone. In memory manager you can set CW DELAY (TX-RX) and it was set to 0. One would assume no delay. Not true, it must use some system default. Changing it to 1 (10ms) shortened the relay hang time to an noticeable amount and the wave form looks ok. 2 Questions:
 
1) is that a bug or undocumented feature ;-)
2) why would there be tone output while the relay is closed but no keyup?"


Andy_501 <andrew.webb.501.ve4per@...>
 

Can't attain that low a setting on my V6. I get two choices 200 Msec or 100 msec and nothing else. TX indiciator is immediate but with standard hand key actual code signal and sidetone are way out of whack and no coincident with TX indicator at all

On 2020-01-27 08:13, Gil Palmer wrote:
From Lou KI5FTY, posted on the uBitx Forum:
 
 
"Found the problem with the transmit with trailing tone. In memory manager you can set CW DELAY (TX-RX) and it was set to 0. One would assume no delay. Not true, it must use some system default. Changing it to 1 (10ms) shortened the relay hang time to an noticeable amount and the wave form looks ok. 2 Questions:
 
1) is that a bug or undocumented feature ;-)
2) why would there be tone output while the relay is closed but no keyup?"


Reed N
 

Hi Andy,

On the v6 there isn't a menu option for it. Looks like the value was copied from the CEC software, and is now hard coded as 50ms. I'll make a new branch with that change to let you try it out if you can't make the change yourself.


Reed


Bill Cromwell
 

Hi,

I have been working on sombody else's V6 and I found the same thing. It makes the V6 *useless* for CW. I am going to put in the latest software and see what happens with that. My V3 *never* had that problem. V3 came with it's own warts. Different software corrected some of them:)

73,

Bill KU8H

On 1/27/20 10:29 AM, Andy_501 wrote:
Can't attain that low a setting on my V6. I get two choices 200 Msec or 100 msec and nothing else. TX indiciator is immediate but with standard hand key actual code signal and sidetone are way out of whack and no coincident with TX indicator at all
--
bark less - wag more


Reed N
 

Hi Gil,

The "CW DELAY" time is how long the radio waits before it switches from TX mode back to RX, so while somewhat related, I don't think it's part of Andy's specific issue, where the problem is switching from RX to TX.

1) based on that copied comment, it sounds like the bug is that he wasn't prevented from setting the value to 0 in the first place.
2) The tone played by the v6 is actually completely independent of the transmitting tone of the radio, so it's not too surprising that the local tone might persist without transmitting if the radio was in a weird state. I'm not sure if this is true of the radio he was using or not.


Reed


Reed N
 

Hey Bill,

I'll see if I can get the change I mentioned in https://groups.io/g/BITX20/message/75328 pulled into the Morse menu branch too.


Reed


Bill Cromwell
 

Hi Reed,

With semi break-in there is an adjustable delay when going from TX back to RX. I wondered if that was being applied to switching the other way as well. Some of the digital modes DO have a delay going from RX to TX. I reduced it as far as it would go (non zero) and there was no difference. Not relevant. DSP in receivers can cause a lag too. There are other workarounds. When a CW op taps the key he needs the tone in his ear in sync with the tap felt in his fingertips. Any noticeable latency is anathema. V6 has a pretty big lag there.

Using fldigi or other sound card generated CW from the keyboard does not work the same way (and is in SSB mode) so it would not be noticed by those ops. Using such soundcard generated CW is a possible workaround for radios like the V6.

Other workarounds require additional, external hardware and wiring changes in the radio(s).

I am going to take your updates and install them in our friend's radio to see what happens. I will post back here.

73,

Bill KU8H

On 1/27/20 12:31 PM, Reed N wrote:
Hey Bill,
I'll see if I can get the change I mentioned in https://groups.io/g/BITX20/message/75328 pulled into the Morse menu branch too.
Reed
--
bark less - wag more


W2CTX
 

line 208 keyer code a 100 msec arbitrary delay to check for CAT activity before paddle transmit.
line 259 keyer code a 100 msec arbitrary delay to check for CAT activity before handkey transmit.

On January 27, 2020 at 1:12 PM Bill Cromwell <wrcromwell@...> wrote:


Hi Reed,

With semi break-in there is an adjustable delay when going from TX back
to RX. I wondered if that was being applied to switching the other way
as well. Some of the digital modes DO have a delay going from RX to TX.
I reduced it as far as it would go (non zero) and there was no
difference. Not relevant. DSP in receivers can cause a lag too. There
are other workarounds. When a CW op taps the key he needs the tone in
his ear in sync with the tap felt in his fingertips. Any noticeable
latency is anathema. V6 has a pretty big lag there.

Using fldigi or other sound card generated CW from the keyboard does not
work the same way (and is in SSB mode) so it would not be noticed by
those ops. Using such soundcard generated CW is a possible workaround
for radios like the V6.

Other workarounds require additional, external hardware and wiring
changes in the radio(s).

I am going to take your updates and install them in our friend's radio
to see what happens. I will post back here.

73,

Bill KU8H

On 1/27/20 12:31 PM, Reed N wrote:
Hey Bill,

I'll see if I can get the change I mentioned in
https://groups.io/g/BITX20/message/75328 pulled into the Morse menu
branch too.


Reed
--
bark less - wag more



Andy_501 <andrew.webb.501.ve4per@...>
 

Thanks Reed I will look forward to it. But not being able to run CW mode normally with a standard hand key as well as not finding a solution to the problem of the latest github file and Arduino IDE to allow me or other noobie students to be able to correct things for themselves is a real BIG NEGATIVE as far as using this as a kit for practical lab time  on a course for sure.

Something else I have noticed here in this group there are many keen and interested chaps that are able to code and generate the proper files to upload and happily willing to help by giving others hex files to up load; problem with that is so many different priorities and interests are involved and what one person has tailored or coded into their preferred priority may not be what the standard GitHub original code file contains. So by accepting these files any default variable values may differ depending on each opr's preferred modes of operation.

So by accepting just a hex file a noobie can have a fair bit of difficulty trying to keep a standard code set to use. As an example setting the default code delay to "1" or someone else uses "50"; In my case the hex file that I received has cw delay of only 1 of 2 choices 100 ms or 200 msec and nobody else mentions these as options at all. Without an ino file associated with that specific hex file one can't open it and compare where the differences exist to kind of keep things in some semblance of a standard package.

Again if Ashhar comes out with another "final" update release on his GitHub link, we have no real idea what versions of tuning speeds and acceleration coding is including or code delays etc. In my case the latest release I have running has "SET FREQ' at a totally different frequency than the original prompt asked for (ie 10,000KHz)  and the BFO zero beat freq is different again. If I get things working properly where I can check coding myself and modify it I will have to have an ongoing spreadsheet file to itemmize all the differences from the initial standard so that when a new one is issued I can adjust the release in the arduino IDE to meet my custom needs before I export the code to a master .ino file and associated hex files to upload into the system. I see the version number on the main display in the bottom corner, but that could conceivably be the same for any number of customized packages from different oprs and with no .ino file to check into it can be totally different.


On 2020-01-27 11:15, Reed N wrote:
Hi Andy,

On the v6 there isn't a menu option for it. Looks like the value was copied from the CEC software, and is now hard coded as 50ms. I'll make a new branch with that change to let you try it out if you can't make the change yourself.


Reed


Andy_501 <andrew.webb.501.ve4per@...>
 

OK Reed will give it another look SAP

On 2020-01-27 11:15, Reed N wrote:
Hi Andy,

On the v6 there isn't a menu option for it. Looks like the value was copied from the CEC software, and is now hard coded as 50ms. I'll make a new branch with that change to let you try it out if you can't make the change yourself.


Reed


Reed N
 

Hi Andy,

If you go to my cw-tx-issue branch (https://github.com/reedbn/ubitxv6/tree/cw-tx-issues) and download that code, I have set the constant mentioned in my comment (https://groups.io/g/BITX20/message/75357) to 0. Compile this version, and see if it transmits straight key for you nicely or not. In my testing (with the PTT button) it seemed to do the right thing, but I'd be interested to get a second opinion on it before I merge it into my master.


Reed


Reed N
 

"Latest github file" meaning Ashhar's master branch, I assume?

I kind of see what you're saying about there not being a single standard, but I think you're also missing some of the picture. So far, the changes in my master version include:
  • Faster screen updates (when the stock was still snail-speed)
  • Faster tuning knob response (when stock was using polling - big thanks to Mark on this one, which I merged in)
  • Smoother tuning acceleration
  • Tiered menus with help text
  • Non-return-to-default calibrations

Of these, the only one that strikes me as "user preference" would be the acceleration, and maybe I should add an option to turn it off. The rest I don't think are custom tailored to my person in any way - I aimed for general usability improvements, and many of them are based on OTHER people specifically asking for them. I've also tried to keep things generic, so that if Ashhar wants, he could merge all of my changes back in to his "official" branch. I'm making changes because I want to make the software better, but it's not my job, and I can't fix everything at once, so have some patience.

I think you're confused about the parameters. The "CW DELAY" option in Ashhar's code is NOT the RX->TX delay. He has that hard coded as 50ms, which I've changed to 0ms (aka no delay) in the cw-tx-issues branch mentioned in https://groups.io/g/BITX20/message/75378. The "CW DELAY" is ONLY the delay from TX->RX. Changing the value of "CW DELAY" will not fix your problem, as I said in https://groups.io/g/BITX20/message/75360

SET FREQ and BFO are two settings that reset to default when you enter Ashhar's setting menu for them. This is not the case in my version, since several people complained about it, and I had some issues with it too.

git (the utility) and GitHub are tools that are literally designed to track changes between code versions, and allow you to tag versions. If I were to build my own custom toolchain for this project, I'd have it auto-version the code so that it displayed the exact commit it was built with, but unfortunately the stock Arduino chain doesn't allow for that, and I don't want to roll a custom toolchain, because that's moving away from the "user-friendly" side of things. However, I do intend to get a version put into my code at some point in the near future. For now, if you just note the commit number that you build from (e.g. Ashhar's master is currently at 4e0516076a43401c506862b93e4196331f519c49), you will have all of the information you need to exactly identify what the code was.


Reed