sm0tsc commented 5 years ago

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 commented 5 years ago

Can you test CW keying via RTS instead of DTS?

sm0tsc commented 5 years ago

Still with PTT via Virtual RTS setting to ON?

//SM0TSC

df8oe commented 5 years ago

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 commented 5 years ago

I will try...

//SM0TSC

Den mån 5 nov. 2018 kl 14:39 skrev DF8OE notifications@github.com:

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_ .

sm0tsc commented 5 years ago

CW Key via RTS does not work

//TSC

Den mån 5 nov. 2018 kl 14:02 skrev DF8OE notifications@github.com:

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_ .

sm0tsc commented 5 years ago

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 notifications@github.com:

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_ .

sm0tsc commented 5 years ago

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 notifications@github.com:

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_ .

db4ple commented 5 years ago

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 commented 5 years ago

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

sm0tsc commented 5 years ago

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

//SM0TSC

sm0tsc commented 5 years ago

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 commented 5 years ago

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

sm0tsc commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 notifications@github.com:

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_ .

db4ple commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

I can close it soon as I have dialog with the CWtype author

//TSC

Den fre 9 nov. 2018 kl 13:23 skrev db4ple notifications@github.com:

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_ .

sm0tsc commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 commented 5 years ago

@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 commented 5 years ago

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 notifications@github.com:

@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_ .

sm0tsc commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

m-chichikalov commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 notifications@github.com:

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 https://github.com/df8oe/UHSDR/issues/1603#issuecomment-440670120, or mute the thread https://github.com/notifications/unsubscribe-auth/AGRh3wXMuxrJgcMD2C69Oiu7jUWsBnQpks5uxVuNgaJpZM4YMyZ_ .

sm0tsc commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 https://github.com/df8oe/UHSDR/issues/1603#issuecomment-440753459, or mute the thread https://github.com/notifications/unsubscribe-auth/AQuBPk-5Lt25NOBOgiReXCC3Eid4xrj2ks5uxZD4gaJpZM4YMyZ_.

sm0tsc commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

sm0tsc commented 5 years ago

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 notifications@github.com:

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 https://github.com/df8oe/UHSDR/issues/1603#issuecomment-441175263, or mute the thread https://github.com/notifications/unsubscribe-auth/AGRh3-eSzScv6kYid7SkON1p0fgsu-yjks5ux6yigaJpZM4YMyZ_ .

sm0tsc commented 5 years ago

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

db4ple commented 5 years ago

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.

df8oe / UHSDR

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

UHSDR Firmare Defect Issue (Bug) Template 1.0

Your Issue Data goes here:

Hardware

Describe the issue:

Your relevant settings

UHSDR Firmare Defect Issue (Bug) Template 1.0

Your Issue Data goes here:

Hardware

Describe the issue:

Your relevant settings