-
Notifications
You must be signed in to change notification settings - Fork 189
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
Comments
Can you test CW keying via RTS instead of DTS? |
Still with PTT via Virtual RTS setting 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
<#1603 (comment)>, 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
<#1603 (comment)>, 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
<#1603 (comment)>, 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
<#1603 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGRh31ZsK8951uFEspscUt5vn5lrFQMTks5usDb8gaJpZM4YMyZ_>
.
|
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...
So TR4W was not to blame it was me. So please test the newest firmware and see if it works with your programs. |
Tried with new firmware (2.9.62) issue still persists :-( //SM0TSC |
Can you also try with CWtype to rule out hardware problem on my end https://www.dxsoft.com/en/products/cwtype/ //SM0TSC |
Hi, |
Great thank you... //SM0TSC |
Just for clarification if you use these software with "normal analog radio":
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 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
<#1603 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGRh3-GPUwZ6eVrn6WPJrAeGIlzRvzSMks5ussfRgaJpZM4YMyZ_>
.
|
Hi Johan, @S52CQ 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). 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. |
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. |
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
<#1603 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGRh31-9cDOrUOp2aAdAwat1GL0LaJ1Gks5utXOzgaJpZM4YMyZ_>
.
|
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 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, |
@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
<#1603 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AGRh38woary_5MRQfqpmbahv5-SIlLU_ks5uuF0MgaJpZM4YMyZ_>
.
|
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 |
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) |
Hi, I updated the wiki page with the new information. |
Hi guys, could I bring up another aspect of all of these. THe question is do we have this? I did not find information... 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.. Max (RV9YW) 73! |
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? |
Hi Max, welcome! 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. |
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... Later I will open new issue for discuse further... |
Hi, 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. |
But it does not via keying via USB port, then you need to raies ptt
(Virtual RTS PTT) first to make it TX... Hence the original report..
//SM0TSC
Den ons 21 nov. 2018 kl 14:56 skrev db4ple <[email protected]>:
… 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.
—
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/AGRh3wXMuxrJgcMD2C69Oiu7jUWsBnQpks5uxVuNgaJpZM4YMyZ_>
.
|
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 |
Hi Johan, |
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 |
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... :) |
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 |
Hi, inside that link it was exe file not bin one... |
It is the update for CWTYPE as earlier explained.. I use the normal mcHF
firmware
//SM0TSC
Den fre 23 nov. 2018 kl 09:06 skrev S52CQ <[email protected]>:
… Hi, inside that link it was exe file not bin one...
73 de S52CQ
—
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/AGRh3-eSzScv6kYid7SkON1p0fgsu-yjks5ux6yigaJpZM4YMyZ_>
.
|
As CWTYPE dev now have implemented the workaround.. Shall I close this? |
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. |
There is no release of it yet.. But here is a link to the beta http://www.dxsoft.com/download/cwt233b.zip |
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
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
The text was updated successfully, but these errors were encountered: