cw

[MDS Info]

Hello,

I got xmit working with a PC mike, but am unable to get the cw to transmit,
nor can I find a PSDR manual to read to figure
it out for myself. I have changed all kinds of things to no avail. I am
trying to use CWX, but would also like to
know how to tell it to use DTR. I see the COM port setting, but it does not
tell you what signal they are using!

73's

Glen K4KV

[John Williams]

read the flex site on powersdr CW mode. I think you may have to tell
PowerSDR how to sense a serial port for key closure and then let it
generate the CW to send to hermes, but I could be wrong. Not a CW guy...
HL has no CW hardware interface.

John

[John Laur]

I was wondering when the first CW op was going to chime in.

CW in regular HPSDR is now hardware generated. There is a basic NCO in the firmware that simply runs directly at the TX frequency to generate the tones (and the power ramp). It also produces the sidetone on the speaker output. There is a rather nice keyer that is part of the firmware.

CW is a very difficult mode to implement entirely on the host mainly because of the round trip latency. Doug and Warren fought with it in PowerSDR for a very long time, and it was pretty close, but the FPGA-based operation proved much nicer.

It does not appear that the hardware CW generation is incorporated into Hermes Lite at all. This is not necessarily a hard requirement to supporting CW, but it's a prerequisite to supporting CW in much of the current HPSDR software. The CW feature was written to take very few FPGA resources. The biggest thing is a LUT. Steve, have you looked at this? If Hermes Lite is to be used often in a QRP configuration, it might make the most sense to adopt the same approach for CW as the mainline HPSDR gear. The FPGA-based inputs for CW keys/paddles are also much easier to deal with than the PC-based options, FWIW.

73, John K5IT.

--
You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Rob Frohne]

Hi John, et. al.,

One solution that I've thought about is to use a keyboard rather than a keyer.  The latency could be much less of a problem that way, because the operator isn't having to worry about the timing.  I think it should be able to do in software that way.  You might not get nice QSK, but it would not require any fpga stuff, and especially for ghpsdr3-alex or situations where the network has a large latency, it would be much better than by hand or keyer.

73,

Rob
KL7NA

-- 
Rob Frohne, PhD, PE
Professor
EF Cross School of Engineering
Walla Walla University
100 SW 4th Street
College Place, WA 99324
(509) 527-2075

[John Laur]

This is what CWX does in PowerSDR, but it still relies on the hardware (FPGA-based) CW waveform generation. Indeed because the hardware takes care of everything including the rather complicated T/R transition sequence it makes it relatively easy for a software client to implement high performance CW rather trivially.

Again, nothing is stopping anyone doing it "the old way" by generating the waveform on the PC. You can even use audio-based CW if you want in a program like FLDIGI. That is probably the best approach at the moment for hermes lite.

73, John K5IT

[Rob Frohne]

I like the idea of using fldigi. It is the most immediate solution and should work pretty well.

73,

Rob
KL7NA

--
Sent from my Android device with K-9 Mail. Please excuse my brevity.

[Steve Haynal]

Reports on how well fldigi works for CW on the Hermes-Lite would be interesting. When I return home I will also investigate adding back the hardware CW support. We have a few extra pins and the resource overhead should be very low.

73,

Steve

KF7O

[James Ahlstrom]

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.

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

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

[Sid Boyce]

I use an old Curtis 8044 keyer with sidetone on the HiQSDR, works great.
73 ... Sid.

--
You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

-- 
Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot
Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support
Senior Staff Specialist, Cricket Coach
Microsoft Windows Free Zone - Linux used for all Computing Tasks

[ed...@hzeeland.nl]

hi,

I would love to have the possibility for "software" CW keying as I intend to operate my H.L remotely with VHF/ UHF / SHF transverters.

 

So a +1 to bring back the code into the H.L firmware to support this.

 

73 Eddy pe9ghz

On Monday, April 27, 2015 at 12:21:46 AM UTC+2, Glen Bankston wrote:

[ZL2APV]

Yes I agree with both. I have already alluded to this in another post here but I would like to add some more specific comments. When operating the station remotely a signal needs to be sent to the keyer/ptt inputs on the fpga  to set the key pin true. It can be other fpga outputs OR'd onto these inputs, a keyer at the site, dedicated wires from remote site, wifi link etc. but modern keyers offer a USB input and the radio (e.g. Quisk) could detect a key down, ramp up a sidetone (or use the keyer's sidetone) and send a true signal to the fpga which processes the signal as outlined by Jim. This also applies to serial and parallel ports. As we are sending a pure switching signal from sdr to hardware, latency is very much a lesser issue and direct signal generation in the fpga is as quick as you can get (I think).

In terms of sequencing, this would be great done in firmware but will carry a fair bit of work and maybe belongs in the sdr as well as the firmware. Also it needs to be borne in mind that the relay timings will be quite variable and settings would need to be provided for them e.g. a vacuum antenna changeover relay needs about 5 -7 mSec whereas a standard relay needs up to 30 mSec and an electronic one uSecs. The sdr on connection to the firmware should provide the delay parameters from a settings table and on ptt/keydown the firmware sends instant antenna changeover, PA bias after the antenna delay time then signal to be transmitted if CW. Otherwise for SSB etc. the radio provides the signal after the corresponding delays. Gets complicated and as Jim suggests a big sidetrack at this stage. Attached is my sequencer come 3.3 to 5 volt level translator and opto isolators for sequencing and 4 of 16 bandswitch decoders which works well and stops me transmitting into open circuits for brief periods or worse still into my receiver.

I am nearly completed on an electronic T/R switch for up to 100 watts which is going to be part of my project and will switch the 20 watt amplifier stage of my radio. This will ultimately drive a 250 Watt linear and that is as much power as I am looking at.

73 Graeme ZL2APV

[Steve Haynal]

Hi List,

Okay. My takeaways from this discussion are:

• The two CW options are not mutually exclusive: we can have a connection at the radio and over ethernet.
  
• Serious CW operators (not me) really want/need a low latency connection at the radio where the shaping is done on the FPGA.
• This is a solved problem as both openHPSDR and HiQSDR have implementations with low resource usage that provide key input at the radio that we can reuse.
• Sidetone is an issue but it is reasonable to require use of a keyer that generates a sidetone.

There are extra IOs on the Hermes-Lite which we can dedicate to CW use. I will eventually get around to adding CW support back to the firmware, but may take my time. Anyone interested is welcome to give it a go.

73,

Steve

KF7O