UHSDR
UHSDR copied to clipboard
df8oe
Using PTT via Virtual RTS radio stays in TX after software have unkeyed
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
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...
I will try...
//SM0TSC
Den mån 5 nov. 2018 kl 14:39 skrev DF8OE [email protected]:
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...
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/df8oe/UHSDR/issues/1603#issuecomment-435876446, or mute the thread https://github.com/notifications/unsubscribe-auth/AGRh35ea_Yv1QqTXqUtXqxT2NUrxCd43ks5usD-NgaJpZM4YMyZ_ .
CW Key via RTS does not work
//TSC
Den mån 5 nov. 2018 kl 14:02 skrev DF8OE [email protected]:
Can you test CW keying via RTS instead of DTS?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/df8oe/UHSDR/issues/1603#issuecomment-435866183, or mute the thread https://github.com/notifications/unsubscribe-auth/AGRh31ZsK8951uFEspscUt5vn5lrFQMTks5usDb8gaJpZM4YMyZ_ .
In both MRP40 and CWtype I need to activate PTT via RTS otherwise radio will not TX when sending CW message.. It´s same for other radios
//TSC
Den mån 5 nov. 2018 kl 14:02 skrev DF8OE [email protected]:
Can you test CW keying via RTS instead of DTS?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/df8oe/UHSDR/issues/1603#issuecomment-435866183, or mute the thread https://github.com/notifications/unsubscribe-auth/AGRh31ZsK8951uFEspscUt5vn5lrFQMTks5usDb8gaJpZM4YMyZ_ .
To clearify this is via USB to radio directly not via keyer input
//TSC
Den mån 5 nov. 2018 kl 14:02 skrev DF8OE [email protected]:
Can you test CW keying via RTS instead of DTS?
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/df8oe/UHSDR/issues/1603#issuecomment-435866183, or mute the thread https://github.com/notifications/unsubscribe-auth/AGRh31ZsK8951uFEspscUt5vn5lrFQMTks5usDb8gaJpZM4YMyZ_ .
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.
So TR4W was not to blame it was me. So please test the newest firmware and see if it works with your programs.
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
Hi, I will have to look into this then with my hardware and a real-time debugger later this week.
Hi, I will have to look into this then with my hardware and a real-time debugger later this week.
Great thank you...
//SM0TSC
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?
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
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...
To be able to send CW via the USB port of the mcHF you must raise PTT (RTS) and then Key CW via (CTS).. All CW keyboard encoder software I have tried behaves like this
//Johan
Den ons 7 nov. 2018 kl 12:45 skrev DF8OE [email protected]:
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...
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/df8oe/UHSDR/issues/1603#issuecomment-436597517, or mute the thread https://github.com/notifications/unsubscribe-auth/AGRh3-GPUwZ6eVrn6WPJrAeGIlzRvzSMks5ussfRgaJpZM4YMyZ_ .
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.
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
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).
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.
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.
@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?!
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.
I can close it soon as I have dialog with the CWtype author
//TSC
Den fre 9 nov. 2018 kl 13:23 skrev db4ple [email protected]:
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.
— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/df8oe/UHSDR/issues/1603#issuecomment-437344476, or mute the thread https://github.com/notifications/unsubscribe-auth/AGRh31-9cDOrUOp2aAdAwat1GL0LaJ1Gks5utXOzgaJpZM4YMyZ_ .
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
@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.
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.
@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.
Sorry but my radio only sends CW if PTT via RTS is set to on and CW is via DTS (All via USB Port) as this is the idea to use USB for everything
//Johan SM0TSC
Den sön 11 nov. 2018 kl 18:23 skrev DF8OE [email protected]:
@sm0tsc https://github.com/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.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/df8oe/UHSDR/issues/1603#issuecomment-437688017, or mute the thread https://github.com/notifications/unsubscribe-auth/AGRh38woary_5MRQfqpmbahv5-SIlLU_ks5uuF0MgaJpZM4YMyZ_ .