CW TX

[rz3qs]

At me does not go CW how to find my error.

[pavel-demin]

If you're using the SDR transceiver compatible with HPSDR, then the required CW functionality is not implemented.

On the HPSDR hardware, a significant part of the CW/CWX functionality is implemented in FPGA and consists of the following modules:

http://svn.tapr.org/repos_sdr_hpsdr/trunk/Hermes/Source/Hermes_v3.1/iambic.v http://svn.tapr.org/repos_sdr_hpsdr/trunk/Hermes/Source/Hermes_v3.1/profile.v

There is an interesting discussion of this problem on the Hermes-lite mailing list:

https://groups.google.com/forum/#!topic/hermes-lite/XuhZmuDNZko https://groups.google.com/forum/#!topic/hermes-lite/QPte1OypQBQ

At the moment, it's not clear to me how to implement the CW/CWX functionality in the Red Pitaya SDR transceiver compatible with HPSDR.

A possible workaround could be using fldigi: http://www.w1hkj.com

Some instructions on how to interface fldigi with PowerSDR mRX can be found at the following link: http://www.coilgun.info/hamradio/hermes-sdr.htm

[rz3qs]

Hello Pavel Thanks. I am far from programming. But very much I love CW, whether there is a possibility though in the theory to make telegraph formation in FPGA.

[mike6000]

As James Alstom and Jim, writes cw can be generated with sending a high/low signal to a pin on the FPGA. A numeric oscillator directly on the transmit frequency generates cw. Cw means continuous wave. It is nothing more than a sinusouis that is switched on and off with a slight ramp to make on off transitions not generate an unclean signal thru too fast amplitude modulation

" I heartily agree with John Laur here. If you want to support CW on an SDR, you must have a key input pin, and the FPGA must generate CW when the key pin goes True.

This is based on my own hardware experience, and also my users on the HiQSDR hardware. Adding minimal support is easy, and can be done in stages.

1. There must be some sort of hardware key input on the board. When this input goes True, the FPGA starts a linear ramp from zero output to maximum output at the Tx frequency over 5 millisecs or so. When the key goes False, the output ramps down. The FPGA in/out pins should be protected from damage by a high impedance resistor network, or even by an optocoupler. The state True/False of the key input is sent to the PC as C0 bit 1 or 2. C0 bit zero is PTT. If we have three input pins, we could send the state to the PC as C0[2:0]. On my hardware, the key input also works as PTT, because I send the mode to the FPGA; CW or not. But my HiQsdr users demanded a second input for a mic switch for PTT, and they were insistent. So let's say we need two input pins, or three.

When the PC sees the key is down, it mutes the audio and provides a sidetone. It can switch to Rx when the key goes up, or can wait and implement semi-breakin. The problem so far is that we need sequencing; that is, we must first switch the T/R relay and next key the FPGA. A second problem is that the sidetone may be too choppy at high speed due to PC and soundcard delays. But if we want to improve this, it takes a lot more work.

1. In my shack, I use a separate box and an MCU to provide sequencing. It keys the T/R relay first and then keys the FPGA. But we could add a protocol to tell the FPGA what sequencing delays we want, and then the FPGA would provide the T/R signal on an output pin, and key the RF output after the delay.
2. For very fast CW that exceeds the ability of PC sidetone generation, the user can use a separate keyer that provides its own sidetone. Otherwise we need to add an audio codec to the hardware, and generate the sidetone from the FPGA. The Flex radios do this, and also add the keyer to the FPGA so the user only has to connect the paddle. Too much work for now in my opinion.

I have no faith in any CW scheme that depends on the PC to key the output.

Jim N2ADR

"

[pavel-demin]

For information. I've checked how the CW signal ramp is implemented in the Hermes and Hermes-Lite projects.

Hermes reads the profile from a ROM block: http://svn.tapr.org/repos_sdr_hpsdr/trunk/Hermes/Source/Hermes_v3.1/profile.v

Hermes-Lite implements a simple linear ramp: https://github.com/softerhardware/Hermes-Lite/blob/master/rtl/hermes_lite_core.v#L2024

[mike6000]

Lookup table ok. Linear ramp... perhaps but wouldnt you get transitions if you want the risetime fast?

I was thinking about x(t)=sin(2pif)*e^exp(rise-factor) instead. Would that be an idea? The e^exp() modulates the sine.

[mike6000]

Ahh sorry forgot to include t in the equation but you get the idea I guess

[k3it]

I ran across an interesting reference re CW bandwidth and how it affects signal readability. the best rise time seems to be dependent on the sending speed. Shovkoplyas, Alex, @VE3NEA, CW Shaping in DSP Software, QEX, May/June 2006. (article attached) 73! cw-shaping-in-dsp.pdf

[on3vna]

CW implementation on an SDR is really a tough case due to the timings. It is a designing challenge in all forms. All High level design is provided in previous posts here. Looking forward to see this small sdr do CW. 73 de ON3VNA Johan

[mike6000]

I would recommend an IO signal approach directly on the Zync fpga. Then it would be possible to connect a cw keyer or straight key directly. This would simplify things consideraly I think. Later someone can develop a pc controlled approch and we would have both options available. In a pileup or contest a direct no delay cw tx is important. Summarized: first develop via a hardware approach. THEN develop a software / pc functionality.

[on3vna]

@mike6000 , that would do the trick indeed, i also use a winkeyer (arduino based) with a speaker on the arduino works great with DM780 with a flex-3000 and flex-1500. IO on the FPGA and tone generation in the FPGA.

Controlled from the PC to much overhead and latency to get the sound from hw to sw and controlling the signals. Taking care of break-in and all other features of CW ... a hell of a job. My 50 Eurocents.

73 johan

[ka6s]

Pavel,

In looking at the HPSDR approach - the only thing that confuses me is where to patch it into the current system? I'm a bit confused by the clocking scheme - still looking at the block diagram. Do you have a clock that runs at 192KHz or is everything up at 125MHz? To use the HSPDR code I believe you would want to play the rom file into the transmit path at 192KHz if I understand the mechanisms involved. Is there a way to do that in a straight-forward manner?

73 de Steve KA6S

On Fri, Aug 5, 2016 at 6:37 AM, mike6000 notifications@github.com wrote:

I would recommend an IO signal approach directly on the Zync fpga. Then it would be possible to connect a cw keyer or straight key directly. This would simplify things consideraly I think. Later someone can develop a pc controlled approch and we would have both options available. In a pileup or contest a direct no delay cw tx is important. Summarized: first develop via a hardware approach. THEN develop a software / pc functionality.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pavel-demin/red-pitaya-notes/issues/318#issuecomment-237852231, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJODXLGGbnqq7_5Yryt-sOBe_bGI03ks5qczyfgaJpZM4Jb4z4 .

[pavel-demin]

After reading the "CW Shaping ..." article, I'd try a very simple solution with a keyer connected more or less directly to the input of the very first FIR filter in the TX chain. The ramp should be automagically done by the FIR and CIC filters.

[pavel-demin]

For information. Just found another interesting discussion on the Hermes-Lite mailing list: https://groups.google.com/forum/#!topic/hermes-lite/CKg0Wl6zHhI

BTW, is it important to support the iambic key or nobody really uses it?

[mike6000]

Almost everyone uses ianbic cw keyer and paddles today but that is often an external unit. If there is a keyer onboard there needs to be a way to adjust speed (usually a pot or encoder). If you implement very low latency cw keying via an IO pin we can use external keyer first. Then later you could as an option implement a jeyer on the fpga.

[ghost]

Hi Pavel,

Without the Iambic keyer you can not use paddles. So this is essential. [Irony on] If the others use only Straight Keys, then the problem of bk and latency is of no relevance. [Irony off]

After all the discussions I would still say that serious CW begins at 20 wpm upwards and except the Elecraft solution I have not seen a sdr solution with full bk, so ...

73 de Hajo

---

Cela est bien dit, ...,mais il fault cultiver notre jardin.

[mike6000]

Most people uses their own external iambic keyer so in my mind it is not essential at this stage. What is most important is cw support. Then iambic support can come later.

[pavel-demin]

Thanks for the explanation. It's now much clearer for me.

[ka6s]

Pavel,

I don't know that most people use external keyers - that is an assumption that doesn't make sense, especially when the cost is trivial within the FPGA and you have already brought out the Dit/Dash pins to be driven by the paddles. It DOES mean that you would want to have local storage for the several parameters needed to control the keyer logic - but that should be something the server code can handle easily.

Steve KA6S

On Sun, Aug 7, 2016 at 10:14 AM, Pavel Demin notifications@github.com wrote:

Thanks for the explanation. It's now much clearer for me.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pavel-demin/red-pitaya-notes/issues/318#issuecomment-238094902, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJOKCPUZ6erYGliGD_hXuPXFK-dYvhks5qdhJ1gaJpZM4Jb4z4 .

[rz3qs]

Hi Pavel. Can I ask you a question by e-mail.

[pavel-demin]

Can I ask you a question by e-mail.

Yes, sure. The address is in my profile.

[mike6000]

Hi Pavel. Here is an example of an external keyer https://blog.radioartisan.com/arduino-cw-keyer/ You may probably use that as a source of ideas if you decide to implement a cw keyer on the FPGA. This has all the bells and whistles but as a basics you need speed control, Iambic A and B, weighting.

There is also a protocol named "K1EL Winkey" in versions 1.0 and 2.0 (this is an interface protocol that a pc contest program typically uses to send commands to a cw keyer. It is widely in use by the contest community and DXers). You may want to look into that.

My recommendation is to prioritize to implement basic IO input for CW first. Then when we have that, all the other more fancy stuff can come :)

[pavel-demin]

Here is a preliminary version of the SDR transceiver compatible with HPSDR with a very basic CW functionality: https://www.dropbox.com/sh/5fy49wae6xwxa8a/AACLFBWYdfqdy_2thVpETeHla/sdr/ecosystem-0.95-1-6deb253-sdr-transceiver-hpsdr-cw.zip?dl=1

It's expected to work only with a straight key or an external keyer connected to the pin DIO2_N of the extension connector E1. The CW signal is generated when one of the CW modes is selected in PowerSDR mRX PS and the pin DIO2_N is connected to GND.

The CW signal shaping is inspired by the "CW Shaping in DSP Software" article. Here is how the CW signal spectrum looks like:

[rz3qs]

Hello! Thanks Pavel. It is already possible to work CW.

https://youtu.be/Nn1ZWlup_Q8

[pavel-demin]

For information. I've just added some notes and illustrations about the CW functionality. They can be found at this link.

[ghost]

Hi Pavel,

Seems like you are still developing . Good!

The shape of the Cw signal looks good and I assume that the envelope when the signal stops is equivalent to the rising. One minor point: I am sure? you mean 50 wpm?

So the time is short enough to enable Qsk. Still I will wait with high hopes for your implementation of the t/r switching which is crucial.

Keep up the good work. On Sunday I will be on holidays but can read the mail.

73 de Hajo

---

Cela est bien dit, ...,mais il faut cultiver notre jardin.

[pavel-demin]

you mean 50 wpm?

Yes, I've fixed the typo. Thanks.

I will wait with high hopes for your implementation of the t/r switching which is crucial.

Could you please explain me what kind of t/r switching is required for QSK?

[ghost]

Tomorrow, my wife just sent me a priority signal ;-)

Am 08.09.2016 11:46 nachm. schrieb "Pavel Demin" notifications@github.com:

you mean 50 wpm?

Yes, I've fixed the typo. Thanks.

I will wait with high hopes for your implementation of the t/r switching which is crucial.

Could you please explain me what kind of t/r switching is required for QSK?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pavel-demin/red-pitaya-notes/issues/318#issuecomment-245751738, or mute the thread https://github.com/notifications/unsubscribe-auth/AGsHhYO4yUK_WZCbtPCb_dEzkz67_JBiks5qoIIcgaJpZM4Jb4z4 .