CW with only HPSDR in CWL or CWU not working

[on3vna]

Pavel,

It seems that with the latest SW release of HPSDR transceiver CW is not working anymore. When connecting the key to the dedicated pin of the RED PITAYA and putting HPSDR in CWU or CWL there is not RF output signal. Problem was detected by Heinz DK3IR. I my setup where I use HRD (Ham Radio Deluxe V5) and DM780 that controls the CW Winkeyer there is RF output because DM780 controls via HRD the PTT of the RED PITAYA. Can you plse have a look at it ?

73 de ON3VNA Johan

[pavel-demin]

Hi Johan,

It seems that with the latest SW release of HPSDR transceiver CW is not working anymore.

This is strange. I've just checked the latest version (0.94-1354). CW works as it should.

The only difference with some of the previous version is that CW is generated only when PTT is activated. PTT can be activated by the MOX button in PowerSDR mRX PS or by the PTT In pin (DIO0_N). This more correct behavior was introduced with this commit.

The CW working without PTT was a bug and it's fixed now.

Best regards,

Pavel

[pavel-demin]

I've just found the forum thread where Heinz DK3IR described the problem: http://forum.cq-nrw.de/viewtopic.php?f=11&t=123

It's not clear what version he is using. Most probably, the solution for him is to switch to the latest version of the SDR transceiver compatible with HPSDR.

Currently, the latest version is 0.94-1354.

[ka6s]

Pavel,

I don't think this IS correct behavior.

Consider that the CW key is itself like PTT.

How do you hook it up to a keyer? Do I have to push the PTT button before I start sending CW - that is REALLY inconvenient - in 40 years I have NEVER seen a ham radio operate like that. If I push the Key down - the transmitter works. It should work with just 1 input!

73 de Steve KA6S

On Tue, Nov 1, 2016 at 9:06 AM, Pavel Demin notifications@github.com wrote:

I've just found the forum thread where Heinz DK3IR described the problem: http://forum.cq-nrw.de/viewtopic.php?f=11&t=123

It's not clear what version he was using. Most probably, the solution for him is to switch to the latest version of the SDR transceiver compatible with HPSDR.

Currently, the latest version is 0.94-1354.

— 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/377#issuecomment-257608209, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJOI8ZqxGmhS3N7kM7Uf9pHPLDLJYIks5q52NqgaJpZM4KmOAq .

[pavel-demin]

Hi Steve,

Consider that the CW key is itself like PTT.

I'm not sure that it would be a usable configuration. Most probably, some delays (key-up, key-down, break-in) should be added to make it usable.

Anyway, with the current version, a very simple solution/workaround would be to connect CW Dot and PTT In together. It can be done with a simple jumper wire.

Best regards,

Pavel

[pavel-demin]

For information. The Hermes implementation of the pre- and post-delays can be found in the following file: http://svn.tapr.org/repos_sdr_hpsdr/trunk/Hermes/Source/Hermes_v3.1/profile.v

[pe0mgb]

Pavel,

When you give for CW the PTT-in the same functionality as the PTT using MOX then it is easy to add some delays with hardware and make them variable if necessary.

Regards, Gert PE0MGB

[pavel-demin]

Looks like we're back to the external keyer vs internal keyer discussion.

Current version is only usable with an external keyer. An external keyer would most probably provide a PTT output with all required delays.

For example, Arduino CW keyer has several PTT outputs and the required pre- and post-delays: https://github.com/k3ng/k3ng_cw_keyer/blob/master/k3ng_keyer/keyer_settings.h

Since Arduino CW keyer already provides all the required functionality, I'm not convinced that I should re-implement it on Red Pitaya.

[ka6s]

Pavel,

The normal usage is as follows:

1) I put the radio into CW mode. 2) I push the Morse Code key down. 3) Transmitter sends a signal. 4) I let up - switch back to receive.

Now internally -

key press is observed - PTT_OUT should switch - some delay, then start the CW signal ramp occurs.

Key release observed - Ramp down signal, some delay, PTT_OUT deasserts.

I can live with an external keyer - but the behavior above is what one expects a transceiver to do.

Steve

On Tue, Nov 1, 2016 at 2:29 PM, Pavel Demin notifications@github.com wrote:

Looks like we're back to the external keyer https://github.com/pavel-demin/red-pitaya-notes/issues/318#issuecomment-238093051 vs internal keyer https://github.com/pavel-demin/red-pitaya-notes/issues/318#issuecomment-238284809 discussion.

Current version is only usable with an external keyer. An external keyer would most probably provide a PTT output with all required delays.

For example, Arduino CW keyer https://blog.radioartisan.com/arduino-cw-keyer has several PTT outputs and the required pre- and post-delays: https://github.com/k3ng/k3ng_cw_keyer/blob/master/k3ng_ keyer/keyer_settings.h

Since Arduino CW keyer already provides all the required functionality, I'm not convinced that I should re-implement it on Red Pitaya.

— 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/377#issuecomment-257704177, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJODZYTiolKwoG7k4lpjR7zcLozGMTks5q569RgaJpZM4KmOAq .

[ka6s]

I'll also point out that pretty much ANY external keyer will have one keying circuit - not multiple.

Steve

On Tue, Nov 1, 2016 at 3:00 PM, Steven Wilson wevets@gmail.com wrote:

Pavel,

The normal usage is as follows:

1) I put the radio into CW mode. 2) I push the Morse Code key down. 3) Transmitter sends a signal. 4) I let up - switch back to receive.

Now internally -

key press is observed - PTT_OUT should switch - some delay, then start the CW signal ramp occurs.

Key release observed - Ramp down signal, some delay, PTT_OUT deasserts.

I can live with an external keyer - but the behavior above is what one expects a transceiver to do.

Steve

On Tue, Nov 1, 2016 at 2:29 PM, Pavel Demin notifications@github.com wrote:

Looks like we're back to the external keyer https://github.com/pavel-demin/red-pitaya-notes/issues/318#issuecomment-238093051 vs internal keyer https://github.com/pavel-demin/red-pitaya-notes/issues/318#issuecomment-238284809 discussion.

Current version is only usable with an external keyer. An external keyer would most probably provide a PTT output with all required delays.

For example, Arduino CW keyer https://blog.radioartisan.com/arduino-cw-keyer has several PTT outputs and the required pre- and post-delays: https://github.com/k3ng/k3ng_cw_keyer/blob/master/k3ng_keyer /keyer_settings.h

Since Arduino CW keyer already provides all the required functionality, I'm not convinced that I should re-implement it on Red Pitaya.

— 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/377#issuecomment-257704177, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJODZYTiolKwoG7k4lpjR7zcLozGMTks5q569RgaJpZM4KmOAq .

[pavel-demin]

Steve, thanks for the description of the CW transmission flow.

This flow is already possible with the current version and with the following connections:

• Morse Code key is connected to a keyer
• Key Output of the keyer is connected to Dot Input of the Red Pitaya board
• PTT Output of the keyer is connected to PTT Input of the Red Pitaya board

[ka6s]

Pavel - there are normally NOT two outputs from a keyer! That is the point we're trying to make - just the one. So no it isn't possible.

Steve

On Tue, Nov 1, 2016 at 3:19 PM, Pavel Demin notifications@github.com wrote:

Steve, thanks for the description of the CW transmission flow.

This flow is already possible with the current version and with the following connections:

• Morse Code key is connected to a keyer
• Key Output of the keyer is connected to Dot Input of the Red Pitaya board
• PTT Output of the keyer is connected to PTT Input of the Red Pitaya board

— 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/377#issuecomment-257716257, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJOGHyqWtOPtgL9h7RlGfsokER2Izmks5q57rggaJpZM4KmOAq .

[ka6s]

Another way to present the argument - PTT means Push-To-Talk. It is a voice related function. I use it to key the radio when I want to use a Microphone - for me -I want to use it with a foot switch.

Shorting the two externally isn't functionally convenient. It mixes modes.

Steve

On Tue, Nov 1, 2016 at 5:50 PM, Steven Wilson wevets@gmail.com wrote:

Pavel - there are normally NOT two outputs from a keyer! That is the point we're trying to make - just the one. So no it isn't possible.

Steve

On Tue, Nov 1, 2016 at 3:19 PM, Pavel Demin notifications@github.com wrote:

Steve, thanks for the description of the CW transmission flow.

This flow is already possible with the current version and with the following connections:

• Morse Code key is connected to a keyer
• Key Output of the keyer is connected to Dot Input of the Red Pitaya board
• PTT Output of the keyer is connected to PTT Input of the Red Pitaya board

— 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/377#issuecomment-257716257, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJOGHyqWtOPtgL9h7RlGfsokER2Izmks5q57rggaJpZM4KmOAq .

[pavel-demin]

there are normally NOT two outputs from a keyer!

OK. I see. I didn't know that there were keyers without PTT Output.

However, some of the keyers that I find on the web have both Key Output and PTT Output:

http://k1el.tripod.com/ https://blog.radioartisan.com/arduino-cw-keyer/

So, at least these keyers can be used with the current version of the transceiver.

[pavel-demin]

Another way to present the argument - PTT means Push-To-Talk. It is a voice related function. I use it to key the radio when I want to use a Microphone - for me - I want to use it with a foot switch.

So, it's another possibility to use the CW functionality in current version:

• push the foot switch
• start using the Morse Code key

[pavel-demin]

To summarize. The CW functionality in the latest version of the transceiver can be used in the following ways:

• external keyer with PTT Output: the keyer's PTT Output should be connected to PTT Input of the Red Pitaya board
• external keyer without PTT Output: the CW functionality should be activated by pushing the PTT switch

[ka6s]

I'll be adding the internal OR gate.

On Wed, Nov 2, 2016 at 2:31 AM, Pavel Demin notifications@github.com wrote:

To summarize. The CW functionality in the latest version of the transceiver can be used in the following ways:

• external keyer with PTT Output: the keyer's PTT Output should be connected to PTT Input of the Red Pitaya board
• external keyer without PTT Output: the CW functionality should be activated by pushing the PTT switch

— 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/377#issuecomment-257814285, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJOKaiuTuwqPLlEK4yOHbcHtUBbuYqks5q6FiHgaJpZM4KmOAq .

[pavel-demin]

Looks like an internal keyer could be implemented in software. Here is an example of Python code running on Raspberry Pi: http://m0xpd.blogspot.com/2012/12/keyer-on-rpi.html

I could try to code something similar in C. It would be much easier to do than to implement the keyer on the FPGA.

[ka6s]

I'm curious why you dont use the keyer rtl from hermes?

[pavel-demin]

I'm curious why you don't use the keyer rtl from hermes?

The internal structures of the Hermes code and of my code are quite different.

[ka6s]

I would think a wrapper could be built around the Hermes code to isolate it and make it look like what you need - would you like help with that. I'm a professional Verilog coder.

Steve

On Wed, Nov 2, 2016 at 6:13 AM, Pavel Demin notifications@github.com wrote:

I'm curious why you don't use the keyer rtl from hermes?

The internal structures of the Hermes code and of my code are quite different.

— 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/377#issuecomment-257860257, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJOP_Q69Aa1J804tN05UQpbX96UnfQks5q6IyMgaJpZM4KmOAq .

[pavel-demin]

Steve, it would be of course great if you could contribute to the development of this transceiver.

However, I'd prefer not to add the Hermes code to my red-pitaya-notes.

If the keyer could be implemented in C rather than Verilog, then I'd prefer to implement it in C.

[ka6s]

Pavel,

I'm currently working on adding a feature to PiHPSDR that is "complicated ;-)" in hopes of contributing the feature to that effort. I hope to have that done in about 2 weeks and submitted. After that I'll quite enjoy taking a whack at it as C code first.

One wonders whether this does need to be in hardware with that trade-off having been reversed once before (them moving the features into the verilog in HPSDR). However, this is different in that the server code is sitting awfully close to the hardware and won't incur cable travel time issues.

Steve

Steve

On Wed, Nov 2, 2016 at 7:30 AM, Pavel Demin notifications@github.com wrote:

Steve, it would be of course great if you could contribute to the development of this transceiver.

However, I'd prefer not to add the Hermes code to my red-pitaya-notes.

If the keyer could be implemented in C rather than Verilog, then I'd prefer to implement it in C.

— 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/377#issuecomment-257881304, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJOCKoaTScYksgZbDERxM502EcH24Uks5q6J6DgaJpZM4KmOAq .

[pavel-demin]

Do I have to push the PTT button before I start sending CW - that is REALLY inconvenient - in 40 years I have NEVER seen a ham radio operate like that.

Today, when I was browsing through the cqham.ru forum, I found that some radio operators are happy that the latest version of the Odyssey-TRX firmware has now a possibility to use a PTT footswitch when operating CW:

http://www.cqham.ru/forum/showthread.php?31020-Odyssey-TRX&p=1302252&viewfull=1#post1302252 http://www.cqham.ru/forum/showthread.php?31020-Odyssey-TRX&p=1302288&viewfull=1#post1302288

1st post translation: 'Finally, it becomes possible to fully work in CW' 2nd post translation: 'Turn on transmission with a foot switch in the CW mode'

http://www.cqham.ru/forum/showthread.php?31020-Odyssey-TRX&p=1302373&viewfull=1#post1302373

translation: 'Footswitch is useful when working with a CW key. Due to the unevenness of the transmission some pauses occur, the switching relays clap adding some discomfort and the risk of burning the contacts'

Then I found another post on the eham.net forum:

http://www.eham.net/ehamforum/smf/index.php?topic=48856.0

an extract from the above post: 'I'd like to hook up a footswitch to put the rig into transmit mode when I'm keying rather than use semi break-in as I'm currently doing (not interested in full QSK, either, as I find the relays distracting).'

And here is an youtube video showing Red Pitaya operated in a CW mode:

https://www.youtube.com/watch?v=lJD54oXqTp8

So, I'd say that even in its current state my SDR application for Red Pitaya is already usable for some CW operators.

Moreover, some operators do prefer to use a PTT footswitch when operating CW.

[ka6s]

Pavel - you made me QLF. I hope at least you laugh when you look up the term.

73 de steve KA6S

On Sun, Nov 6, 2016 at 11:41 AM, Pavel Demin notifications@github.com wrote:

Do I have to push the PTT button before I start sending CW - that is REALLY inconvenient - in 40 years I have NEVER seen a ham radio operate like that.

Today, when I was browsing through the cqham.ru forum, I found that some radio operators are happy that the latest version of the Odyssey-TRX firmware has now a possibility to use a PTT footswitch when operating CW:

http://www.cqham.ru/forum/showthread.php?31020-Odyssey- TRX&p=1302252&viewfull=1#post1302252 http://www.cqham.ru/forum/showthread.php?31020-Odyssey- TRX&p=1302288&viewfull=1#post1302288

1st post translation: 'Finally, it becomes possible to fully work in CW' 2nd post translation: 'Turn on transmission with a foot switch in the CW mode.

http://www.cqham.ru/forum/showthread.php?31020-Odyssey- TRX&p=1302373&viewfull=1#post1302373

translation: 'Footswitch is useful when working with a CW key. Due to the unevenness of the transmission some pauses occur, the switching relays clap adding some discomfort and the risk of burning the contacts'

Then I found another post on the eham.net forum:

http://www.eham.net/ehamforum/smf/index.php?topic=48856.0

an extract from the above post: 'I'd like to hook up a footswitch to put the rig into transmit mode when I'm keying rather than use semi break-in as I'm currently doing (not interested in full QSK, either, as I find the relays distracting).'

And here is an youtube video showing Red Pitaya operated in a CW mode:

https://www.youtube.com/watch?v=lJD54oXqTp8

So, I'd say that even in its current state my SDR application for Red Pitaya is already usable for some CW operators.

Moreover, some operators do prefer to use a PTT footswitch when operating CW.

— 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/377#issuecomment-258704796, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJOHyug4ukNNMf2vS0dOQdyn1mcCenks5q7i18gaJpZM4KmOAq .

[ka6s]

Pavel, not to restart the thread - but gather some information to help me with a software keyer that you said you would prefer, can you point out the steps the server takes to turn on the CW signal and turn it off.

Maybe just line numbers pointing at the relevant sections in the current server code would help greatly.

Thanks,

Steve KA6S

On Sun, Nov 6, 2016 at 12:17 PM, Steven Wilson wevets@gmail.com wrote:

Pavel - you made me QLF. I hope at least you laugh when you look up the term.

73 de steve KA6S

On Sun, Nov 6, 2016 at 11:41 AM, Pavel Demin notifications@github.com wrote:

Do I have to push the PTT button before I start sending CW - that is REALLY inconvenient - in 40 years I have NEVER seen a ham radio operate like that.

Today, when I was browsing through the cqham.ru forum, I found that some radio operators are happy that the latest version of the Odyssey-TRX firmware has now a possibility to use a PTT footswitch when operating CW:

http://www.cqham.ru/forum/showthread.php?31020-Odyssey-TRX& p=1302252&viewfull=1#post1302252 http://www.cqham.ru/forum/showthread.php?31020-Odyssey-TRX& p=1302288&viewfull=1#post1302288

1st post translation: 'Finally, it becomes possible to fully work in CW' 2nd post translation: 'Turn on transmission with a foot switch in the CW mode.

http://www.cqham.ru/forum/showthread.php?31020-Odyssey-TRX& p=1302373&viewfull=1#post1302373

translation: 'Footswitch is useful when working with a CW key. Due to the unevenness of the transmission some pauses occur, the switching relays clap adding some discomfort and the risk of burning the contacts'

Then I found another post on the eham.net forum:

http://www.eham.net/ehamforum/smf/index.php?topic=48856.0

an extract from the above post: 'I'd like to hook up a footswitch to put the rig into transmit mode when I'm keying rather than use semi break-in as I'm currently doing (not interested in full QSK, either, as I find the relays distracting).'

And here is an youtube video showing Red Pitaya operated in a CW mode:

https://www.youtube.com/watch?v=lJD54oXqTp8

So, I'd say that even in its current state my SDR application for Red Pitaya is already usable for some CW operators.

Moreover, some operators do prefer to use a PTT footswitch when operating CW.

— 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/377#issuecomment-258704796, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJOHyug4ukNNMf2vS0dOQdyn1mcCenks5q7i18gaJpZM4KmOAq .

[pavel-demin]

can you point out the steps the server takes to turn on the CW signal and turn it off

The CW signal generator is controlled by a AXI4-Stream switch (multiplexer) and one reset signal.

The corresponding C code can be found on lines 630-641 in sdr-transceiver-hpsdr.c:

https://github.com/pavel-demin/red-pitaya-notes/blob/master/projects/sdr_transceiver_hpsdr/server/sdr-transceiver-hpsdr.c#L630

The Verilog code of the CW signal generator is in the axis_keyer module: https://github.com/pavel-demin/red-pitaya-notes/blob/master/cores/axis_keyer_v1_0/axis_keyer.v

Its key_flag port is directly connected to Dot In: https://github.com/pavel-demin/red-pitaya-notes/blob/master/projects/sdr_transceiver_hpsdr/block_design.tcl#L250 https://github.com/pavel-demin/red-pitaya-notes/blob/master/projects/sdr_transceiver_hpsdr/block_design.tcl#L282

For the software keyer, key_flag should be connected to a software controlled register.

I think that the software keyer could be implemented as a thread that checks the state of the gpio_in register every 0.1-1.0 ms in a busy loop and then sets or reset the register connected to axis_keyer/key_flag.

The main state machine from the following code looks interesting: http://web.engr.oregonstate.edu/~traylor/ece473/newkeyer.c

[ka6s]

Thank you Pavel - this is very helpful!

On Sun, Nov 27, 2016 at 7:15 AM, Pavel Demin notifications@github.com wrote:

can you point out the steps the server takes to turn on the CW signal and turn it off

The CW signal generator is controlled by a AXI4-Stream switch (multiplexer) and one reset signal.

The corresponding C code can be found on lines 630-641 in sdr-transceiver-hpsdr.c:

https://github.com/pavel-demin/red-pitaya-notes/blob/master/projects/sdr_ transceiver_hpsdr/server/sdr-transceiver-hpsdr.c#L630

The Verilog code of the CW signal generator is in the axis_keyer module: https://github.com/pavel-demin/red-pitaya-notes/blob/ master/cores/axis_keyer_v1_0/axis_keyer.v

Its keyflag port is directly connected to Dot In: https://github.com/pavel-demin/red-pitaya-notes/blob/master/projects/sdr transceiver_hpsdr/blockdesign.tcl#L250 https://github.com/pavel-demin/red-pitaya-notes/blob/master/projects/sdr transceiver_hpsdr/block_design.tcl#L282

For the software keyer, key_flag should be connected to a software controlled register.

I think that the software keyer could be implemented as a thread that checks the state of the gpio_in register every 0.1-1.0 ms in a busy loop and then sets or reset the register connected to axis_keyer/key_flag.

The main state machine from the following code looks interesting: http://web.engr.oregonstate.edu/~traylor/ece473/newkeyer.c

— 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/377#issuecomment-263127583, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJOI7T6SSLMdaZ3rgggRvJDTswg2ugks5rCZ6FgaJpZM4KmOAq .

[pavel-demin]

I've just added the required registers and connections for the software keyer: https://github.com/pavel-demin/red-pitaya-notes/commit/4dcf67846423f4112daae663b73eeabb78313e1f

Here is a new version of sdr-transceiver-hpsdr.c with a thread that checks Dot In and starts and stops the CW signal generator: https://github.com/pavel-demin/red-pitaya-notes/blob/develop/projects/sdr_transceiver_hpsdr/server/sdr-transceiver-hpsdr.c

And here is a link to a bitsream file that works with this code: https://www.dropbox.com/sh/5fy49wae6xwxa8a/AACOzg6i5AVo7o0t4YSdeWW0a/sdr/sdr_transceiver_hpsdr_soft_keyer.bit?dl=1

[n1gp]

Pavel,

I ported the Hermes FPGA iambic-keyer.v over to C and use it with the PiHPSDR. Maybe the code would be of some use here?

See: https://github.com/n1gp/pihpsdr and: https://github.com/n1gp/iambic-keyer

I made a demo video here using a 5" PiHPSDR (uses capacitive touch) I built:

https://www.dropbox.com/s/8e10oey35zy95cq/mini_pihpsdr_cw.avi?dl=0

-Rick / N1GP

[ka6s]

Pavel,

I've attached a version of the sdr_transceiver_hpsdr.c with the keyer thread implemented. I've tested it to the point where I hear the CW tone and it works like a keyer should - but I don't see any power out. Maybe I'm not turning on the transmitter correctly - please take a look.

This is a clean-slate implementation, i.e. I built it into the thread you had already provided and implemented my own iambic keyer logic much in the manner you had previously suggested.

73 de Steve KA6S

On Wed, Nov 30, 2016 at 11:23 AM, Rick Koch notifications@github.com wrote:

Pavel,

I ported the Hermes FPGA iambic-keyer.v over to C and use it with the PiHPSDR. Maybe the code would be of some use here?

See: https://github.com/n1gp/pihpsdr and: https://github.com/n1gp/iambic-keyer

I made a demo video here using a 5" PiHPSDR I built:

https://www.dropbox.com/s/8e10oey35zy95cq/mini_pihpsdr_cw.avi?dl=0

-Rick / N1GP

— 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/377#issuecomment-263968737, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJOGB8hnPOl2HKBhhAIl6P0pNqhmhyks5rDc0ygaJpZM4KmOAq .

[pavel-demin]

Thanks Steve. But looks like github doesn't accept C files as attachments.

[ka6s]

What would be the best way to get you the file then please?

Steve

On Sat, Dec 3, 2016 at 10:38 AM, Pavel Demin notifications@github.com wrote:

Thanks Steve. But looks like github doesn't accept C files as attachments.

— 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/377#issuecomment-264656994, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJON9UbGthma-uL8YGsSgLa1iUK0fIks5rEbcTgaJpZM4KmOAq .

[pavel-demin]

Could you create a pull request or send the file to my e-mail address? You can find it in my profile: https://github.com/pavel-demin

[ka6s]

I will do that in about an hour. Away from home at the moment.

On Dec 3, 2016 12:20 PM, "Pavel Demin" notifications@github.com wrote:

Could you create a pull request or send the file to my e-mail address? You can find it in my profile: https://github.com/pavel-demin

— 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/377#issuecomment-264663015, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJOGE8hq1-YpJovlOaaZJKzLhX_QRfks5rEc70gaJpZM4KmOAq .

[ka6s]

I've emailed it to your email address on your profile.

Steve

On Sat, Dec 3, 2016 at 12:07 PM, Steven Wilson wevets@gmail.com wrote:

What would be the best way to get you the file then please?

Steve

On Sat, Dec 3, 2016 at 10:38 AM, Pavel Demin notifications@github.com wrote:

Thanks Steve. But looks like github doesn't accept C files as attachments.

— 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/377#issuecomment-264656994, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJON9UbGthma-uL8YGsSgLa1iUK0fIks5rEbcTgaJpZM4KmOAq .

[pavel-demin]

Thanks Steve. I've received the code.

[ka6s]

Great! I'm quite curious why I don't see transmitting.

On Dec 3, 2016 2:23 PM, "Pavel Demin" notifications@github.com wrote:

Thanks Steve. I've received the code.

— 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/377#issuecomment-264669640, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJOITG1CiOy76HqVGxpx8w9IoWGSyuks5rEev6gaJpZM4KmOAq .

[pavel-demin]

Steve,

I've restructured your code and added it to the repository with this commit. I've also enabled a couple of parameters (cw_weight, cw_mode == 2).

With this code, I have both the RF and sidetone signals.

[ka6s]

Wonderful. I'll give it a try tonite- I looked at the code and I see that you really did rewrite it - but hey - proof of concept I guess. I just glad to get this functionality because it really polishes off the requirements list of what the code can do.

Thanks again Pavel!

Steve (still thinking we don't need PTT too...) ;-)

On Dec 5, 2016 11:46 AM, "Pavel Demin" notifications@github.com wrote:

Steve,

I've restructured your code and added it to the repository with this commit https://github.com/pavel-demin/red-pitaya-notes/commit/8f0db0ee2da2ce6470554b3c7d5caeca236dc80d. I've also enabled a couple of parameters (cw_weight, cw_mode == 2).

With this code, I have both the RF and sidetone signals.

— 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/377#issuecomment-264956381, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJODDwJHD4hNZ6nu2eHI_qwNGHdB7Cks5rFGoHgaJpZM4KmOAq .

[pavel-demin]

I see that you really did rewrite it

Mostly copy&paste using your code as a starting point. I've tried to keep the behavior mostly unchanged.

I've just found a problem with mode B and attempted to fix it with the next commit. However, I'm still not sure if this mode behaves correctly.

still thinking we don't need PTT

Combining PTT with the keyer is the next step. It'll require some changes in the FPGA code to handle the cw_delay and cw_hang parameters.

[pavel-demin]

For information. Here is a link to the timing diagram of the original B mode keyer: https://inza.files.wordpress.com/2011/01/accu-keyer.pdf

[pavel-demin]

Just found a very detailed article about the iambic keyers: http://cq-cq.eu/DJ5IL_rt007.pdf

According to this article, the A and B keyers should check for inputs during each dot or dash:

a correctly programmed iambic keyer with dot/dash memory checks for paddle inputs during each dot or dash in type "A" as well as in type "B". But in type "A" (Curtis-keyer) it checks for the transient from unpressed to pressed whereas in type "B" (Accu-keyer) it checks just for the state pressed. And even in basic iambic mode without dot/dash-memory it does not check after the end of each dot or dash, but after the end of each dot- or dash-element which contains the following space.

[pavel-demin]

Here is a new version of the keyer that checks the state of the Dot and Dash inputs every 1 ms: https://github.com/pavel-demin/red-pitaya-notes/commit/9a9a2ce58601e97f75bf69a37b4ecc45bada6b69

I'd say that with this new version, the A and B modes work as described in the article from my previous comment.

[ka6s]

I did an update about 12 hours ago and compiled it so I assume I have the latest stuff.

1. In PiHPSDR with a foot switch for PTT. No carrier - but have side tone.
2. In PowerSDR with the foot switch I have to hit the MOX button AND the foot switch to see the carrier - but my amplifier isn't there - so I suspect that the PTT_OUT isn't operating.

Summary: MOX shouldn't be needed, and PTT_OUT should show up.

On Tue, Dec 6, 2016 at 12:35 PM, Pavel Demin notifications@github.com wrote:

Here is a new version of the keyer that checks the state of the Dot and Dash inputs every 1 ms: 9a9a2ce https://github.com/pavel-demin/red-pitaya-notes/commit/9a9a2ce58601e97f75bf69a37b4ecc45bada6b69

I'd say that with this new version, the A and B modes work as described in the article from my previous comment.

— 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/377#issuecomment-265264603, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJOPI8I-OQtAJukiuBNMWSHrLKsG6lks5rFcb6gaJpZM4KmOAq .

[ka6s]

Pavel,

I got to thinking about this - and I believe I heard the TX relay - so PTT_OUT is probably okay. I won't have a chance to take a scope to it until this evening - so I'll post what I find.

The observation about MOX button and the PTT foot switch is accurate though.

Steve

On Wed, Dec 7, 2016 at 3:44 AM, Steven Wilson wevets@gmail.com wrote:

I did an update about 12 hours ago and compiled it so I assume I have the latest stuff.

1. In PiHPSDR with a foot switch for PTT. No carrier - but have side tone.
2. In PowerSDR with the foot switch I have to hit the MOX button AND the foot switch to see the carrier - but my amplifier isn't there - so I suspect that the PTT_OUT isn't operating.

Summary: MOX shouldn't be needed, and PTT_OUT should show up.

On Tue, Dec 6, 2016 at 12:35 PM, Pavel Demin notifications@github.com wrote:

Here is a new version of the keyer that checks the state of the Dot and Dash inputs every 1 ms: 9a9a2ce https://github.com/pavel-demin/red-pitaya-notes/commit/9a9a2ce58601e97f75bf69a37b4ecc45bada6b69

I'd say that with this new version, the A and B modes work as described in the article from my previous comment.

— 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/377#issuecomment-265264603, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJOPI8I-OQtAJukiuBNMWSHrLKsG6lks5rFcb6gaJpZM4KmOAq .

[pavel-demin]

There is now a new version with working PTT. It can be downloaded from this link.

Here is how the dot RF signal and the PTT output look like when Key-Down and Break In delays are set to 10 ms and CW speed is set to 25 WPM:

[ka6s]

Stupid question - why is there a modulation envelope on the RF signal in your picture?

Steve

On Wed, Dec 7, 2016 at 2:30 PM, Pavel Demin notifications@github.com wrote:

There is now a new version with working PTT. It can be downloaded from this link https://www.dropbox.com/sh/5fy49wae6xwxa8a/AABs4WOr1T1M8ghQusdwLERPa/sdr/ecosystem-0.95-1-6deb253-sdr-transceiver-hpsdr-psk.zip?dl=1 .

Here is how the dot RF signal and the PTT output look like when Key-Down and Break In delays are set to 10 ms and CW speed is set to 25 WPM: [image: dot_ptt_10ms] https://cloud.githubusercontent.com/assets/8037893/20989365/b2afe160-bcd4-11e6-8024-f256738f72b4.png

— 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/377#issuecomment-265594268, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJOJn3SyXse6mybDSQo1zwSCUOERoPks5rFzN2gaJpZM4KmOAq .

[pavel-demin]

why is there a modulation envelope on the RF signal in your picture?

I suspect my power supply.

[ka6s]

Using PiHPSDR - I now have a CW transmitter with a keyer - and the side tone is missing ;-)

Mind you I have enough RF in my shack that I HEAR myself on the loud speakers... so it isn't fatal.

But it is indeed sending a RF signal out and successfully driving my Amplifier!

Thank you sir!

Steve

On Wed, Dec 7, 2016 at 4:12 PM, Pavel Demin notifications@github.com wrote:

why is there a modulation envelope on the RF signal in your picture?

I suspect my power supply.

— 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/377#issuecomment-265614610, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJOEQAj34GtLWd0AVfB-a_7JQ076Hlks5rF0tmgaJpZM4KmOAq .

[ka6s]

Pavel - cockpit error on my part. Didn't have the right server code loaded.. it has a side tone as well now. So I would call this one fixed!!!

Again - THANKS!

Steve

On Wed, Dec 7, 2016 at 5:51 PM, Steven Wilson wevets@gmail.com wrote:

Using PiHPSDR - I now have a CW transmitter with a keyer - and the side tone is missing ;-)

Mind you I have enough RF in my shack that I HEAR myself on the loud speakers... so it isn't fatal.

But it is indeed sending a RF signal out and successfully driving my Amplifier!

Thank you sir!

Steve

On Wed, Dec 7, 2016 at 4:12 PM, Pavel Demin notifications@github.com wrote:

why is there a modulation envelope on the RF signal in your picture?

I suspect my power supply.

— 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/377#issuecomment-265614610, or mute the thread https://github.com/notifications/unsubscribe-auth/ABsJOEQAj34GtLWd0AVfB-a_7JQ076Hlks5rF0tmgaJpZM4KmOAq .