Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Using PTT via Virtual RTS radio stays in TX after software have unkeyed #1603

Open
sm0tsc opened this issue Nov 3, 2018 · 51 comments
Open
Labels

Comments

@sm0tsc
Copy link

sm0tsc commented Nov 3, 2018

UHSDR Firmare Defect Issue (Bug) Template 1.0

Please fill out the appropriate values. Remove inapproriate/irrelevant values, but be prepare to provide more data. This template contains the most often asked questions.
We may adjust the template over time.

Please give as much information as necessary. At the same time, try to be concise. If you want to report something else than a defect, consider using a forum first. If you want report anything else but a defect remove the template if it does not make sense for your issue. Thank you!

Your Issue Data goes here:

When using PTT via virtual RTS it keys fine but when software in PC unkeys radio stays in TX mode
Your firmware version: 2.9.52
Your bootloader version: 4.1.2

Hardware

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

Describe the issue:

When trying CWtype CW encoder software radio using PTT via Virtual RTS radio stays in TX after software unkeys, CW keying is done via DTS

Your relevant settings

Hint: most of the information can be seen on a screenshot of the main display.

You have audio related problems:
PTT via Virtual RTS is set to on

//SM0TSC

@df8oe
Copy link
Owner

df8oe commented Nov 5, 2018

Can you test CW keying via RTS instead of DTS?

@sm0tsc
Copy link
Author

sm0tsc commented Nov 5, 2018

Still with PTT via Virtual RTS setting to ON?

//SM0TSC

@df8oe
Copy link
Owner

df8oe commented Nov 5, 2018

Why two settings? If I am working in CW I only need to key the keyer. There is no need to press PTT at any other place! You just need to key the rig - no PTT neccessary. I have not seen any rig where I first have to press PTT and then key with the keyer...

@sm0tsc
Copy link
Author

sm0tsc commented Nov 5, 2018 via email

@sm0tsc
Copy link
Author

sm0tsc commented Nov 5, 2018 via email

@sm0tsc
Copy link
Author

sm0tsc commented Nov 5, 2018 via email

@sm0tsc
Copy link
Author

sm0tsc commented Nov 5, 2018 via email

@db4ple
Copy link
Collaborator

db4ple commented Nov 6, 2018

Hi,
this look to me like a duplicate of #1174. And since it is not TR4W we are talking I am wondering if the conclusion in #1174 that the issue is on the TR4W side is still valid. Maybe it is a problem on the UHSDR side after all.

db4ple added a commit to db4ple/UHSDR that referenced this issue Nov 6, 2018
This fix will make Virtual RTS return to RX after RTS has been
cleared by the CAT program on PC side.
So  it was not a fault of TR4W in the end but a mistake on our side.
Wonder why it worked in UCXlog.
Please note: This has not been tested yet but should work. In any case it
cannot make it worse...
df8oe added a commit that referenced this issue Nov 6, 2018
Fix for #1174 and #1603: CAT PTT via RTS not returning to RX
@db4ple
Copy link
Collaborator

db4ple commented Nov 6, 2018

So TR4W was not to blame it was me. So please test the newest firmware and see if it works with your programs.

@sm0tsc
Copy link
Author

sm0tsc commented Nov 6, 2018

Tried with new firmware (2.9.62) issue still persists :-(

//SM0TSC

@sm0tsc
Copy link
Author

sm0tsc commented Nov 6, 2018

So TR4W was not to blame it was me. So please test the newest firmware and see if it works with your programs.

Can you also try with CWtype to rule out hardware problem on my end https://www.dxsoft.com/en/products/cwtype/

//SM0TSC

@db4ple
Copy link
Collaborator

db4ple commented Nov 6, 2018

Hi,
I will have to look into this then with my hardware and a real-time debugger later this week.

@sm0tsc
Copy link
Author

sm0tsc commented Nov 6, 2018

Hi,
I will have to look into this then with my hardware and a real-time debugger later this week.

Great thank you...

//SM0TSC

@df8oe
Copy link
Owner

df8oe commented Nov 7, 2018

Just for clarification if you use these software with "normal analog radio":

  • you connect RxD and TxD lines of a serial interface to CAT connector
  • you connect RTS to PTT line of radio
  • you connect DTS to key input of radio
    (DTS and RTS maybe swapped)

You can use two different serial ports (one for CAT and one for RTS/DTS handling. Maybe software can handle both at one port, too.

So you can change frequency and mode via CAT and switch TX/RX and keying via DTS and RTS lines.

Is that correct?

@sm0tsc
Copy link
Author

sm0tsc commented Nov 7, 2018

Just for clarification if you use these software with "normal analog radio":

  • you connect RxD and TxD lines of a serial interface to CAT connector
  • you connect RTS to PTT line of radio
  • you connect DTS to key input of radio
    (DTS and RTS maybe swapped)

You can use two different serial ports (one for CAT and one for RTS/DTS handling. Maybe software can handle both at one port, too.

So you can change frequency and mode via CAT and switch TX/RX and keying via DTS and RTS lines.

Is that correct?

This software CWtype is a CW Encoder keyboard (with macros etc) only so only the RTS/DTS via USB serial port on mcHF is relevant.. CAT to the mcHF works fine from the same computer testing with other software (not running while testing CWtype).. Please download the CWtype from the URL in earlier post to check / confirm

//SM0TSC

@df8oe
Copy link
Owner

df8oe commented Nov 7, 2018

Hi,
I am running Linux and that are Windows applications.

I thought it is a special feature regarding CAT... Now I completely do not understand what these software does.

None of my rig uses PTT line in CW mode. If I put GND to morse key tip all rigs go immediately to TX - no PTT neccessary. I cannot cross check the software you are using but I am unable to understand what function does double PTT and key have in CW. I compare morse key grounding to "VOX" function in SSB. If I key the rig it goes to TX. Additionally there is an adjustable delay where you can set time from last "morse key up" to RX. So you can do full-bk or bk between words and so on.

So normally in mcHF should only be interpreted ONE line (DTS or RTS) and this line should directly simulate a "key pressed" (like you are presing morse key). The PTT input should be discarded - that is my opinion. If you have muted sidetone I have an idea what to do with PTT line: you can connect a LED to see if you are transmitting...

@sm0tsc
Copy link
Author

sm0tsc commented Nov 7, 2018 via email

@db4ple
Copy link
Collaborator

db4ple commented Nov 8, 2018

Hi Johan, @S52CQ
I analyzed the issue and I have bad news for you. My fix is working perfectly, but it is not going to help you.
On Linux PTT via RTS and KEY via DTR works flawlessly. So our UHSDR does its job.

Using a USB analyzer on Windows 10, I found out, that TR4W and also CWType do not release RTS when they should. It simply stays on. Until the next transmission starts. Only then it goes briefly off and on again (and the UHSDR TRX reacts on that, I verified with the real-time debugger).
I found this message hinting at a problem in the usbser.sys driver of Windows 10:
https://groups.google.com/forum/#!topic/openthread-users/N3ZcHcmuH7M

Since the N1MM+ does work using our UHSDR firmware and the RTS/DTR approach, I think it could be fixed in the programs itself but not by us, since the UHSDR firmware works as expected: We keep the TRX on TX but unkeyed if RTS is set and DTR not.

Sorry guys, we can't fix this. Not our fault.

@S52CQ
Copy link

S52CQ commented Nov 9, 2018

Did you use Ctrl + J option to set TR to use CAT command as per @ny4i in this issue?

I did try Ctrl+J option to set PTT Via, but no help, RTS does not release TX.

73 de Jure

@db4ple
Copy link
Collaborator

db4ple commented Nov 9, 2018

No, I did not set the Ctrl + J option for CAT controlled PTT, this was not the scope of my experiments. I was working on the simple RTS / DTR control without CAT being involved (for that part).

BTW, I tried to understand the source code of TR4W but the weird file names and the programming language (Pascal, which I haven't used in the last couple of decades) itself made it impossible for me to even find where they handle the serial port stuff. And for the other programs with issues, there is no source code available AFAIK. So those guys have to get working, but I am afraid they also have to have access to a UHSDR TRX (or at least a keyer hardware which is controlled by the Windows usbser.sys driver) before being able to see the issue.
I tried with a USB serial adapter (CP2102), which uses a proprietary driver, and as far as I can see it, this USB adapter does not have the same problem (i.e. RTS is correctly return to being turned off when TX stops).

@df8oe
Copy link
Owner

df8oe commented Nov 9, 2018

So for clarification:

The issue is located at the software driver side of operating system. It is impossible to fix it in firmware side (UHSDR).

The best and ony correct bugfix can be done at the software driver.

A second possibility which seems to do the job is a workaround in the applications.

I am not sure if the driver is an open source project - I think it isn't. So you have to release an issue report at the supplier (maybe STM or Microsoft - I do not know) and hope it will be fixed. I can confirm that UHSDR is reacting of everything which is coming via USB is reacting as expected.

@db4ple
Copy link
Collaborator

db4ple commented Nov 9, 2018

Yes, as far as I can judge it, the issue is related to the usbser.sys driver provided by Microsoft. It may be the application not using it correctly or the driver itself behaves different than other serial device drivers for the Microsoft operating system.
I conclude:
There is nothing we, the UHSDR developers, could reasonably do about this. The only option would be to emulate on the USB device side (our TRX side) a vendor-specific serial chip protocol which would imply to write our own Windows driver for it. This is out of scope of what I am willing to do.

@df8oe
Copy link
Owner

df8oe commented Nov 9, 2018

@db4ple : Of course - that is not our job.
@ALL : Sorry for this - but we cannot do anything here. So I think this issue can be closed?!

@db4ple
Copy link
Collaborator

db4ple commented Nov 9, 2018

If there is a tag called "Won't fix" -> this would be appropriate. And please leave it open, otherwise we will get even more duplicates over time.

@sm0tsc
Copy link
Author

sm0tsc commented Nov 9, 2018 via email

@df8oe df8oe added the wontfix label Nov 9, 2018
@sm0tsc
Copy link
Author

sm0tsc commented Nov 9, 2018

Yes, as far as I can judge it, the issue is related to the usbser.sys driver provided by Microsoft. It may be the application not using it correctly or the driver itself behaves different than other serial device drivers for the Microsoft operating system.
I conclude:
There is nothing we, the UHSDR developers, could reasonably do about this. The only option would be to emulate on the USB device side (our TRX side) a vendor-specific serial chip protocol which would imply to write our own Windows driver for it. This is out of scope of what I am willing to do.

Would it be possible to have a "MOX" function in mcHF as a workaround?

//SM0TSC

@df8oe
Copy link
Owner

df8oe commented Nov 11, 2018

@db4ple : If you set "PTT via virtual RTS" to OFF in config menu I would expect UHSDR is discarding any signal on this line and immediately would TX if DTS goes low like I am pressing a connected morse key, isn't it? I cannot test at the moment but I would suggest that is the wanted behaviour of this setting. If not (if it is now waiting for a CAT PTT command) I would rename / refunction this menu entry to
"USB PTT in CW" with the possibilities OFF - RTS - CAT.

If it is set to OFF all these software which provide an additional PTT in CW (in what manner however) should work out-of-the-box by simply keying via DTS... No MOX needed.

@db4ple
Copy link
Collaborator

db4ple commented Nov 11, 2018

Hi,
@df8oe: It works exactly as described. If you do not enable Virtual RTS, then DTR will key the CW signal just as a normal straight key would.
Indeed, just letting DTR control the transmit works. However, for high speed CW our initial RX to TX delay may cause some distortion of the first dit/dah timingwise.

@df8oe
Copy link
Owner

df8oe commented Nov 11, 2018

@sm0tsc : Please test again with disabled virtual RTS. As you can see above it is sufficient to key DTR to go to TX. Of course this can get problems in high speed CW for the virst dits. If you want to do high speed CW you can key "vvv" at the beginning of your transmission :) ... Feedback is welcome.

@sm0tsc
Copy link
Author

sm0tsc commented Nov 11, 2018 via email

@sm0tsc
Copy link
Author

sm0tsc commented Nov 11, 2018

Same thing with the MRP40 it only go to TX if PTS via RTS is used.. Is there some other setting in the mcHF that I can have missed???

//SM0TSC

@db4ple
Copy link
Collaborator

db4ple commented Nov 11, 2018

  1. yes, I was wrong, DTR needs PTT via CAT command or virtual RTS. Well, at least it is implemented like this at the moment.
  2. But I have also some good news: I did one more test on Windows and I found out how to get the RTS working on Windows 10. In a nutshell, one need to set DTR to false (again) after setting RTS to false. This will make Windows set both signals to low and the transmission stops. I verified this using very simple Python code (see below). This means developers can relatively easily incorporate the workaround. It does not do any harm for other serial drivers, since DTR is simply set to low twice, which does not make a difference for properly working drivers, but fixes the usbser.sys issue.
    @S52CQ: You may want to communicate this finding to the TR4W developers
    @sm0tsc: You may want to communicate this finding to the CWType developers.
import time
import serial

ser = serial.Serial("COM15")

def beep():
    print ("Set DTR on");
    ser.setDTR(True)
    time.sleep(0.5)
    ser.setDTR(False)
    print("Set DTR off")
def sleep():
    time.sleep(0.5)


ser.setDTR(False)
ser.setRTS(False)

print("Set RTS on")
ser.setRTS(True)
time.sleep(2.5)
beep()
sleep()
beep()
sleep()
time.sleep(2.5)
print("Set RTS off")
# with the USB analyzer I verified that the setRTS(False) below does not cause the usbser.sys 
# driver ( written by Microsoft!)  to write the new state to the USB device
ser.setRTS(False)
time.sleep(2.5)
# if you comment out the two lines below, the UHSDR TRX will remain in TX with the usbser.sys 
# driver on Win 10.
# setting DTR to False again makes the driver write the new state
print("Set DTR off")
ser.setDTR(False)

@db4ple
Copy link
Collaborator

db4ple commented Nov 11, 2018

Hi, I updated the wiki page with the new information.

@m-chichikalov
Copy link
Contributor

m-chichikalov commented Nov 21, 2018

Hi guys, could I bring up another aspect of all of these.
Some HAMs are using this TRX with a transverter for VHF (1296 mHz 5.7Ghz and so on...) and for them it's very important to have ability to turn off the CW VOX... and transmitte only after PTT...

THe question is do we have this? I did not find information...
Thank you in advance

BTW, I'm going to contribute time to time... My main goal is to port all your code to a hardware which I have, and after that would be happy to help in implementing some stuff..
Thank you for what you did so far, it's amazing, even I have some disagreements on some aspects...

Max (RV9YW) 73!

@df8oe
Copy link
Owner

df8oe commented Nov 21, 2018

What do you mean? CW VOX is not available in CAT or USB (PC) driven way. Only by keying via straight key or paddles. And why is that wrong? You do have PTT for switching such devices located on ACC connector.. But if I think about transverting the very poor output signal of mcHF @10m to higher bands - I get stomach ache ;) I recommend NOT to use mcHF as a transverter or PA driver! Have you ever watched the TX signal using a spectrum analyzer?
73 de Andreas

@db4ple
Copy link
Collaborator

db4ple commented Nov 21, 2018

Hi Max,

welcome!
As Andreas (df8oe) mentioned, except for the virtual USB RTS/DTR control there is no CW vox function via GPIO implemented yet. It would not be too hard to implement software-wise, if using a straight key since we have 2 inputs available (which we use for PTT or CW keyer paddles currently). Integrated keyer plus PTT control via external input: That would be difficult due to only 2 available digital inputs.

Well, on the OVI40 and derived hardware, no such problem, at least on the extension header there is more GPIO available...

I think, if you want to have this idea discussed, it should be an separate issue, you may also want to see if others are interested by asking in the I40 forum (german&english) or in the Yahoo group for support for this function.

And of course, you're welcome to implement such a function and contribute it. Would be a good exercise to start a collaboration. To be clear, you don't have to collaborate, you can just use the source for your projects as long as you follow the rules of the GPLv3.

So please, if you're interested, create a new GitHub issue.

@m-chichikalov
Copy link
Contributor

m-chichikalov commented Nov 21, 2018

Thank you for your responses.

To clarify, by "CW VOX" I ment automatic switching to TX when CW paddle is pressed.

There is usually quite long chain For VHF with LNA at the end... And all this should switching from RX to TX properly. That's way people usually do "sequencer" to handle this chaine.

So many times, when we were in the field, our LNA just died because someone unforchanatly hit the CW paddle... After that we modified all ours TRX's...

About output. Yep, I did not take a look at it... I will when finish my...
But my friend using with different HW.. different LPF and BPF, he does not mention any problem... Thanks for headsUp.

Later I will open new issue for discuse further...
Thank you.

@db4ple
Copy link
Collaborator

db4ple commented Nov 21, 2018

Hi,
the UHSDR firmware automatically activates TX mode when you press the CW paddles. If you just want a (configurable) delay before the actual signal generation starts, that should be doable. Normally most ops want the opposite (no delay between paddle press and TRX transmission).

It is not exactly a sequencer solution. For that the cheapest solution is to throw in something like a raspberry pi and use CAT to control TX signal generation to circumvent the lack of GPIO on the mcHF.

@sm0tsc
Copy link
Author

sm0tsc commented Nov 21, 2018 via email

@sm0tsc
Copy link
Author

sm0tsc commented Nov 21, 2018

UHSDR Firmare Defect Issue (Bug) Template 1.0

Please fill out the appropriate values. Remove inapproriate/irrelevant values, but be prepare to provide more data. This template contains the most often asked questions.
We may adjust the template over time.

Please give as much information as necessary. At the same time, try to be concise. If you want to report something else than a defect, consider using a forum first. If you want report anything else but a defect remove the template if it does not make sense for your issue. Thank you!

Your Issue Data goes here:

When using PTT via virtual RTS it keys fine but when software in PC unkeys radio stays in TX mode
Your firmware version: 2.9.52
Your bootloader version: 4.1.2

Hardware

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

Describe the issue:

When trying CWtype CW encoder software radio using PTT via Virtual RTS radio stays in TX after software unkeys, CW keying is done via DTS

Your relevant settings

Hint: most of the information can be seen on a screenshot of the main display.

You have audio related problems:
PTT via Virtual RTS is set to on

//SM0TSC

Problem with CWtype is resolved, I have tried a new build from them and it works.. Unsure if we should close the issue as their seems to be other related problems?

//SM0TSC

@df8oe
Copy link
Owner

df8oe commented Nov 21, 2018

Hi Johan,
please leave it open. So everybody who uses software which does not work, too can quickly find this issue.
@m-chichikalov Hi Maxim, please open a new issue for the discussion about make builds & co. I will attach correct label to it.

@S52CQ
Copy link

S52CQ commented Nov 21, 2018 via email

@sm0tsc
Copy link
Author

sm0tsc commented Nov 21, 2018

Hi Johan, what new build from whom did you use? From /uhsdr/firmware-latest/mcHF? 73s de S52CQ, Jure

On 21.11.2018 18:44, sm0tsc wrote: UHSDR Firmare Defect Issue (Bug) Template 1.0 Please fill out the appropriate values. Remove inapproriate/irrelevant values, but be prepare to provide more data. This template contains the most often asked questions. We may adjust the template over time. Please give as much information as necessary. At the same time, try to be concise. If you want to report something else than a defect, consider using a forum first. If you want report anything else but a defect remove the template if it does not make sense for your issue. Thank you! Your Issue Data goes here: When using PTT via virtual RTS it keys fine but when software in PC unkeys radio stays in TX mode Your firmware version: 2.9.52 Your bootloader version: 4.1.2 Hardware * UI Board: mcHF 0.6 * RF Board: mcHF 0.6 Describe the issue: When trying CWtype CW encoder software radio using PTT via Virtual RTS radio stays in TX after software unkeys, CW keying is done via DTS Your relevant settings Hint: most of the information can be seen on a screenshot of the main display. You have audio related problems: PTT via Virtual RTS is set to on //SM0TSC Problem with CWtype is resolved, I have tried a new build from them and it works.. Unsure if we should close the issue as their seems to be other related problems? //SM0TSC — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#1603 (comment)>, or mute the thread https://github.com/notifications/unsubscribe-auth/AQuBPk-5Lt25NOBOgiReXCC3Eid4xrj2ks5uxZD4gaJpZM4YMyZ_.

No new beta build of Cwtype. I guess he will release it to production as I reported it working ok

//TSC

@df8oe
Copy link
Owner

df8oe commented Nov 21, 2018

It is a workaround about a driver issue. Best solution would be to fix the driver issue directly. Unluckily it is not Open Source and under the hood of Microsoft. Second choice is a workaround at the programs which uses the driver. Do something twice or in different order. And: BINGO... :)

@S52CQ
Copy link

S52CQ commented Nov 21, 2018

can I have a link to that beta build? There is CQ WW contest very close and I'd like to test rig before the contest.

@sm0tsc
Copy link
Author

sm0tsc commented Nov 23, 2018

can I have a link to that beta build? There is CQ WW contest very close and I'd like to test rig before the contest.

Here is a link to the beta binary.. Just replace the one installed

http://www.dxsoft.com/download/cwt233b.zip

//SM0TSC

@S52CQ
Copy link

S52CQ commented Nov 23, 2018

Hi, inside that link it was exe file not bin one...
73 de S52CQ

@sm0tsc
Copy link
Author

sm0tsc commented Nov 23, 2018 via email

@sm0tsc
Copy link
Author

sm0tsc commented Dec 14, 2018

As CWTYPE dev now have implemented the workaround.. Shall I close this?

@db4ple
Copy link
Collaborator

db4ple commented Dec 14, 2018

No, there is still the very same issue with other tools like TR4W. But can you tell me the version number of CWType which contains the fix? I'll add this to the wiki.

@sm0tsc
Copy link
Author

sm0tsc commented Dec 14, 2018

No, there is still the very same issue with other tools. But can you tell me the version number of CWType which contains the fix, I'll add this to the wiki.

There is no release of it yet.. But here is a link to the beta http://www.dxsoft.com/download/cwt233b.zip

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants