TX delay missing on 1.9.13

Simon Lewis

Eric but the delay in CW is not delaying closing the PTT like on SSB /RTTY etc ie the PTT comes across yet RF is released without delay - I have tested this within my EME system as have a few others

The delay implementation needs to act the same way and this is poorly implemented in CW - the indicator should follow the delay too like in SSB

What about setting TX1/2/3 PTT delay - is the RF delayed then vs PTT in CW - my tests showed that the delay is being ignored in CW 

what occurred for Nick DL/GM4OGI was RF was released before a PTT was completed in the transverter (slower switching) and RF hit the IF line killing the transverter (In CW Mode)

TX Delay according to the documentation works the same way in all modes ... clearly its not and this is dangerous in a system that relies on numerous relays like transverters/mast head preamps

Simon Lewis

yes I raised a ticket

Eric-KE5DTO

How are you determining whether the "PTT is closed"?  The LED is not a good indicator of the state of the TR relay in CW mode due to rapid switching.

So a timed delay is probably not the best solution for a situation where you need to protect external hardware.  This is why we have the TX REQ line.  This line allows external hardware to positively determine when transmission is allowed.

I again confirm that in my testing the RF *IS* delayed when using CW with paddles (or CWX).  The LED switches do switch immediately, but do not reflect when the RF comes out.

I also tested adding TX1/2/3 into the mix and these do add additional delay prior to RF coming out as well.

Simon Lewis

Hi Eric

because I can hear my relay stack click .... for tvtrs, amps, preamps etc - in SSB the delay is correctly implemented - the stack switches inline with the delay set in

not looking at the indicator .... which also isn't helpful not following the real delay

the timed delay and PTT delays are more than capable of supporting sequencer events in SSB .... just implement it the same way in CW, the manual says it works that way in any mode... but doesn't

For any VHF-UHF one of the most used functions would be these delays to act a timed delay sequencer which in SSB works perfect

I will retest CW that was not my experience using MOX / tune - which might be why I am seeing no delay 

Bottom line - it should be implemented as per the manual and as in SSB and you will remove any issue for a VHF-SHFr





 

EA4GLI

Is it also supposed to add the time between letters on cwx?

Eric-KE5DTO

How is your XVTR attached to the radio?  Via the TX1 port?

We will fix up the TUNE function.  I have yet to find a problem with the sequencing based on the design and testing.  

Note that even with a delay, the TX1 Delay will occur, then the TX1 line will flip and THEN the TX Delay will happen.  See the attached pic.

Eric-KE5DTO

This depends entirely on the CW Delay selected.  If the transmitter drops out (shorter CW Delay), then the delay will be incurred on the transition back into transmit.  To avoid this, use longer CW Delays with longer TX Delays.  Note that long TX Delays and fast CW do not go together.

EA4GLI

OK. So if I where to put a CW Delay of 2000ms and a TX Delay of 1000ms, and then I go to CWX and send my call sign at 35 wpm there should be a 1000ms delay before I start transmitting and a 2000ms at the end of my call sign.... correct? 

Care to try that and see what happens? This setting will produce a 1000ms delay between letters!!!! That is not normal.

EA4GLI

And after that try TX Delay 0 ms, CW Delay 0 ms, CWX speed 5 wpm and see if you get any QSK. Enable and disable BREAKIN. It really doesn't matter, it does not work.

K5CG

Perhaps a video clip is in order to make it clear and irrefutable.

EA4GLI

A video from me or from FRS?
I feel like lately the onerous is always on the side of the users.... 

I will humor you.... and post video below so it gets its own set of comments.

EA4GLI

CWX Delay Issue


https://www.youtube.com/watch?v=TNmJ1iYDP9w


As an added feature bug, when you have REMOTE enabled the audio of the CW gets sent at the right speed but the actual transmission has the 1000 ms delay between letters.

EA4GLI

And now with a superimposed video of the amplifier in operation.
I am driving with 5w

Once I click F1 in CWX the audio of my callsign can be heard at the right 35 wpm however, as you can see in the amplifier the code is being sent with a 1000 ms delay between letters.


https://www.youtube.com/watch?v=OlhwOHARoFc

EA4GLI

So QSK doesn't work AT ALL.
Delay on TX gets translated to a delay between words in CWX
The Audio that I hear on Remote has nothing to do with what is actually happening. This is just horrible.

Since 1.7 (pretty much since Maestro) we have not had an uneventful software update. It is clear that 1.9.13 is buggy in basic functionality, and it is the 3rd iteration in a month of 1.9.x

At this point FRS needs to take a closer look at Quality Control, they need to take a closer look at the alpha program (nothing personal against its members... your work is appreciated, but a lot of things are getting through) and consider the option of BETA testing as your current system doesn't cover the long list of permutations of operational environments.

Furthermore, and the part I am more concerned about... if basic functionality breaks with software updates that do not offer any major new feature... what are the chances for us to get NEW features in the future??  I am afraid FRS will become very conservative when considering new features as regular updates seem to break too many things.

Eric-KE5DTO

So QSK doesn't work AT ALL

I just went and tested QSK on v1.9.13 and it seems to be working fine for me.  Note that QSK with any delay settings at all doesn't make sense (TX or CW Delay).

TX Delay says that you want to delay RF transmission when going from RX to TX.  If you have the CW Delay set such that the transmitter drops out between words (or characters), then yes, the Delay will be applied.  Again, if you don't want this to happen, you can set a longer CW Delay -- this will have the effect of hanging in transmit longer after completing a transmission, but it will prevent dropping out between words (or characters).  This is how it has always been in SmartSDR.  This is not a regression, rather it is designed and intended to work this way.

The sidetone audio that you hear is always sent as soon as possible.  When using paddles, this audio feedback is extremely important for proper sending.  This is probably not nearly so important in CWX and we could certainly compensate for things like TX Delay.  I've added Issue #4142 to handle this feature request.

I think we will have to agree to disagree about the software quality.  I'm very proud of what our team has accomplished in SmartSDR for Windows and SmartSDR for Maestro.  Do we have room to improve?  Sure.  In instances where we do find problems, I'm proud of how quickly we respond while at the same time going to root cause on the issues so we understand them and they don't happen again.

Eric-KE5DTO

Thanks for posting the videos.  That does help to see what you are seeing.  See my note below that explains what is going on.

Bill -VA3WTB

Eric, It seems to me many here look at SSDR software much like any other software. You write it, test it, use it. But writing software as complicated as SSDR for a complicated radio is not the same in my opinion. It still amazes me you guys even got SSDR were it is now.

EA4GLI

<<This message above got moved and then became the official response to the thread. So I also moved my response here so it makes sense.>>

Then let me rephrase, QSK doesn't work at all with CWX. And maybe this is by design.

Please try it!!
Put a series of "eeeeee" in one of the CWX setup F keys. Speed 5, Delay for both TX and CW at ZERO 0. And then use your manual key and do the same number of eeeeee manually. Then come back and report. Better yet, why don't you post a video like I did, on how QSK works on CWX?? I just posted 2!

TX Delay says that you want to delay RF transmission when going from RX to TX.  If you have the CW Delay set such that the transmitter drops out between words (or characters), then yes, the Delay will be applied.  Again, if you don't want this to happen, you can set a longer CW Delay -- this will have the effect of hanging in transmit longer after completing a transmission, but it will prevent dropping out between words (or characters).  This is how it has always been in SmartSDR.  This is not a regression, rather it is designed and intended to work this way.

Care to explain what should happen if CW Delay and TX Delay are both ZERO? Better yet, the one that drive me crazy, if I have a CW Delay of 2000 ms, and TX Delay at 0 that means that from the moment I engage PTT (which is immediately because the TX Delay = 0) the TX line will remain engaged for 2000 ms and that counter restarts anytime there is a new dot or dash. After my last dot or dash from my CW 2000 ms will pass until TX is released.

However, with CW Delay set at the same 2000 ms and TX Delay set at 1000 ms, that 1000 ms gets added in between each letter of anything I send with CWX. Having a TX Delay of 1000 ms, a second shorter in time than the CW Delay, the reality is that that TX Delay shouldn't have any effect until I am done with the transmission because the CW Delay is larger.

But it doesn't do that, it adds that 1000 ms between words.... that makes no sense.
If I had CW Delay at a smaller value than TX Delay, it could make a bit of sense if my CWX speed was so slow that the time between words happened to surpass the CW Delay, therefore disengaging PTT and having TX Delay be a factor again.

I can post another video... but I don't see them doing any good. Please test this things, and if you can't test things with CWX please have someone else test it.

I think we will have to agree to disagree about the software quality. 

If you extract from my multiple posts, and my ownership of 5 Flex products and my direct connection with the purchase by others of over 20 x 6000 series radio that I consider your software sub par then you really are misreading my posts. 

But if you are that interested about my opinion here it is:

I consider your Testing of the software before release subpar. As proven by the many issues lately.
I consider your approach to ALPHA testing and lack of public BETA testing less than ideal - Compared to the world standard of software testing.
I consider your approach to non English speaking community appalling. There are no publicly available documents in your website in any other language than English (there is a German version of the user manual.... I haven't check of which version of SmartSDR)

I consider SmartSDR the best software out there for SDR, that is why I personally purchased the Flex radios over the Anan or other alternatives. It used to be the best software by a mile a year ago only bested by PowerSDR in some NR and ANF aspects, it is barely ahead the competition nowadays.

I went as far as being an early adopter of the Maestro. Decision I now regret as I do not see the Maestro close to what I expect it to be. But that is my fault for being an early adopter. I will keep it in the hopes that it will eventually provide the portable experience I was hoping to get (no TNF when ANF doesn work sucks, lack of DExpander is another big issue for me.... no idea when and if those will be fixed)

I post videos trying to teach others how to use your software, I have a blog dedicated to it, I answerdaily (even on weekends) to colleagues whose SmartSDR for Windows is not working because of updates, unsigned drivers and a myriad of other issues. I get on the phone with them. I team viewer into their computers and I help them..... and I do all of this for nothing in return. Because, unlike you, I do not work at FRS.

Maybe, just maybe you should consider me an asset to your company, a small part of a bunch of us that are willing to put our time and money into the betterment of FRS. Instead of thinking of me as the enemy that questions the quality of your software because I have found an issue with it. 

Lastly, I am truly sorry, that you, Eric, whom I do not know that much, are the recipient of my rant; at the very least you showed up on this thread and tried to answer my concerns....

Eric-KE5DTO

QSK doesn't work at all with CWX.

Gosh, I totally missed this (CWX).  My apologies as somehow I wasn't putting QSK with CWX.  Yes.  See this thread: https://community.flexradio.com/flexradio/topics/cwdx-issue-with-v-1-9-7.  This will be fixed in v1.10 with an option to turn QSK on for CWX.  Thanks for getting this point through to me.

On Delays, I can't tell whether you understand the design and have found a problem with it or whether we haven't communicated the design well enough.  In other words, I can't tell whether it is the design itself you are taking issue with or that the design is OK, but the implementation has a problem.  The only way I know to resolve that is to thoroughly explain the design.

CW Delay - This field is designed to act as a Hang after the last CW element has completely finished sending.  This allows the user to control how often the transmitter drops out while sending CW.  At a setting of 0, the transmitter will drop out as quickly as possible (QSK).  At 20 WPM, a dot is 60ms, so setting the delay to something like 100 ms would cause the transmitter to stay engaged between characters (char space = 1x dot = 60ms), but it would drop out between words (word space = 3x dot = 180ms).

TX Delay - As shown in the image attached above, the TX Delay is designed to allow the user to delay RF output when transitioning from RX to TX.  The delay follows the maximum of the TX1/2/3 output delays (see image).  The most common use case for this delay is to allow slower hardware to switch prior to putting any RF out.  Note that positive control of transmission is better suited to the TX REQ input on the radio.

With these descriptions in place, let's look at the examples you gave.  At CW Delay = 0 and TX Delay = 0, this is what I would recommend for optimal QSK operation (aside from the CWX issue mentioned above!).

With CW Delay = 2000, TX Delay = 0, this says that there is no delay on the front edge, but that transmission will hang for 2 seconds after the last element completes before returning to RX.

To the rest, I suspect we just got off on the wrong foot.  I definitely do not consider you an enemy -- just the opposite.  I'm glad for the opportunity to address your concerns.  Especially as a member of the community offering to help others (huge thank you for that!).

EA4GLI

Thanks for that Eric!
No issue on my part!

With these descriptions in place, let's look at the examples you gave.  At CW Delay = 0 and TX Delay = 0, this is what I would recommend for optimal QSK operation (aside from the CWX issue mentioned above!).

This works OK as it should

With CW Delay = 2000, TX Delay = 0, this says that there is no delay on the front edge, but that transmission will hang for 2 seconds after the last element completes before returning to RX.

This also works as it should.

It is Cw Delay = 2000 TX Delay = 1000 that adds the 1000 ms in between letters on CWX.

Try that one. The only reason to use 2000 and 1000 is so that it is obvious to the **** eye. I understand I will not find myself in a situation where I would use those values on CWX.

But if I were to send CWX with a transverter and I wanted to add a significant delay of 50 to 100 ms before RF is sent with TX Delay I would get the added ms in between each letter. I do not think this is supposed to be this way. 

Eric-KE5DTO

Let me give it a try.  What speed are you using?

EA4GLI

It really doesn't matter. You can try with any CW Speed.

Try CW Speed=35   CW Delay= 2000 ms and TX Delay = 500ms

Eric-KE5DTO

I confirm that this is misbehaving.  I would not expect the TX Delay to be incurred unless the transmitter drops out (which it shouldn't with a 2000ms CW Delay).  I have added this as Issue #4148.  Thanks again for helping me to understand the issue.

EA4GLI

Sure! Thanks for sticking around till we figured it out.

EA4GLI

I think the official response of this thread should be the last comment made by Eric acknowledging the issue and not the one that says there isn't an issue.