Low Latency CW Sidetone

[Steve Haynal]

Hi Group,

For some time now I've been looking for a CW keyer with low latency sidetone Hermes-Lite 2 solution which meets these criteria:

• Supports both local and remote use of the HL2, where the HL2 can be in another room yet still be operated by a CW key.
• Conserves limited FPGA logic and memory resources for specialized high-speed digital signal processing, and not usage on low-speed audio buffering and control which can be done easily by cheaper technologies.
• Preserves the current application of HL2 IO pins for ATU control, HR50 interfacing, fan control, and synchronous radio linking.
• Is easy to setup and use, requiring no advanced software/audio card configuration or changes.
• Requires no desoldering of components on the HL2 board and potential limited warranty voiding.
• Costs under $40 for a complete, prebuilt solution.

Last weekend I had an idea which I think can meet all these criteria. I have started serious experiments towards realizing this solution. The core idea is to combine a CW keyer with a USB soundcard as shown below. There is a low latency path from CW-keypress to audio out through the custom USB soundcard. This is the latency which matters to some operators but not others. CW-keypress-to-ear latency on this path can be identical to what is seen on Apache Labs and openhpsdr radios. Since the PC is sending audio to the adapter, the CW sidetone can be mixed in or interrupt audio as currently done on openhpsdr radios. Note that there is no real difference in audio latency here, as in openhpsdr solutions the data must be passed from radio to computer for demodulation and then as audio data back to radio again. Here we are passing raw data from radio to computer and then audio to USB adapter with similar latencies. There is no magic possible by having an audio jack on the radio, as processing still must be done by the computer.

There is one other latency to note, and that is CW-keypress-to-RF latency. In this solution it will be slighly more, I suspect in the 50-70ms range, as CW-keypress must be passed to computer and then HL2. But I don't think this matters in practice. If you consider the speed of light, operators already see a ~130ms there and back latency when working someone half way around the globe.

Some may think that implementation of this idea will be a lot of work, but fortunately, there are several projects which make implementing a custom but universal (no custom driver) USB sound card easy. My first experiments are with the $20 Teensy 4.0 and $15 audio adapter. What is most attractive about the Teensy 4.0 is the well developed Teensy Audio Library.  This even has a drag-and-drop GUI design tool to create audio applications with USB audio, midi and serial endpoints plus final i2s interface. 

All that remains are CW keyer connections (very inexpensive prototype board to unused Teensy pins for now) and CW keyer code. For the CW keyer code, I'll probably first use N1GP's iambic keyer as it is simple yet covers all expected openhpsdr functionality. Finally, although there will some optional MIDI control, I think this can all be done with few if any host software changes. Instead of key down/up messages, the custom USB adapter can send shaped IQ CW data which is then just sent directly to the HL2 without software processing.

Even now one can kludge together 3 boards (Teensy, audio adapter, keyer connector board) like I am doing for under $50. But if this idea takes off, I'd like to make it easier for people. One option would be to create a combined audio adapter and keyer connector board and sell it on Makerfabs. i2s codecs cost under $5.0 and connectors are cheap. This would sell for under $20 as another addon for the HL2. Yet another option would be to replace the Teensy with the new $4 Raspberry Pi Pico. There is already an audio board for the Raspberry Pi Pico so we know its special IO FSMs can be used for i2s. Also, the teensy audio library has been ported to other platforms, and given Raspberry Pi's history, Raspberry Pi will also have well supported libraries of their own. A final option, although the most work, would be to make a single custom board, maybe with a SAMD21 or 51 part, or even a module. All of these lower cost MCUs support native FS 12Mb/s USB. The Teensy supports native HS 480Mb/s USB which could be an advantage.

I am looking for help with this project. I'm committed to trying at least the 3-board kludge, but there is much more which could be done. For example, maybe one would like to add a big MIDI-based tuning knob for tactile feel, create an enclosure, help with the coding, help with testing, port to a Pi pico, port the k3ng cw keyer code, etc. Please let me know if you have interest.

73,

Steve

kf7o

 

[Graeme Jury]

Hello Steve,

This is the sort of thing I like to do. I already have a modified K3NG keyer, midi interface with a teensy and another with an uno. I can operate remotely on my local lan at the maximum speeds that I can send at so hopefully have the experience that you are looking for plus (rare for a technician) I will document what I do.

73, Graeme ZL2APV

--
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.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/30c72b12-fa5c-4737-a2a3-0391e0bc4efen%40googlegroups.com.

[Steve Haynal]

Hi Graeme,

Sounds great. Do you have any postings of your code anywhere? It would help me to take a look. Also, which Teensy are you using?

73,

Steve

kf7o

[Graeme Jury]

Hi Steve,

I have attached what I can find which may not be too useful for you. The Teensy code is to take the signal from my keyer which is already debounced so I did no key debounce but simply converted to the midi commands. I'm pretty sure that it is a Teensy 2 that I am using but I made up a lead from my keyer with a phono plug and from the Teensy to computer with a usb lead and slipped a piece of heat shrink over it  and shrunk it down so it is a special cord. The setup works perfectly with Quisk.

Hope that you can get something useful from it.

73, Graeme ZL2APV

[Steve Haynal]

Hi Graeme,

Thanks for the documents. We had one on the wiki already, and I updated the wiki to include the other:

https://github.com/softerhardware/Hermes-Lite2/wiki/Software#sparksdr-and-group

I plan to start a github repository for this soon with some skeleton code. I will grant you access. I think you keyer work should be very helpful.

[Roger Critchlow]

Steve --

Sounds like a grand idea.

I don't think you need the codec, the Teensy 3.2, 3.5, 3.6, 4.0, and 4.1 all have onboard audio outputs, either integral DAC's on 3.X or the medium quality sound (MQS) pins on 4.X, mono on the 3.2, stereo elsewhere.  You'll find them listed as outputs in the Teensy Audio tool.

And I think the Teensy 3.2 will probably be enough.

There's a copy of the n1gp/vk6ph keyer in github.com/recri/keyer/dspmath/keyer_iambic_vk6ph.h as a c++ class.

Let me know if I can help.

73

-- rec -- ad5dz --

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/fc00ff02-b5b5-4791-b4ea-64d5eb1c6be4n%40googlegroups.com.

[Edwin]

Hi Steve,

You can look at https://github.com/DL3LSM/k3ng_cw_keyer_midi_teensy for the K3NG version with MIDI interface. I haven't tried this one yet. A Teensy with MIDI and a simple keyer .ino can provide CW and audio with SparkSDR and also with Quist and openhpsdr beta 10 from Reid.

73, Edwin.

Op 1-2-2021 om 05:54 schreef Steve Haynal:

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/df3f3578-1e10-4ddb-b109-a1d917806d97n%40googlegroups.com.

[Roger David Powers]

Would add a comment that if at all possible the line in should be true stereo so those who want to play with sound card radios can still do that.  I found that a lot of the current usb soundcard devices appear to have stereo line in but in fact are mono.  That seems to be because perhaps the mono chips are cheaper?  Regardless, most people are using them for headphones that only have mono mics so most people don't notice the lack of stereo, yet if you are doing something like sound card radio you need stereo in.  Having a device that definitely provides stereo line in could be one reason it finds favor.

Regards,

RDP.

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/600df594-2a91-8121-6316-96c3da610246%40vhfradio.nl.

[Roger Critchlow]

Hi Christoph --

I would expect that the Teensy would run as a Serial+MIDI+Audio composite device, so Winkeyer would be a possibility.  The K3NG_cw_keyer with lots of options enabled fits comfortably into a Teensy 3.2, and I see that recent K3NG source versions include Teensy and MIDI support.

One thing I verified yesterday is that the Teensy USB Audio only runs at 44100 samples/second.  That's the only supported sample rate for the entire Teensy Audio library.  There are (unsupported) ways to change the sample rate for I2S and the in memory pipeline, but 44100 is all that the USB Audio knows how to do.

-- rec -- ad5dz --

On Mon, Feb 1, 2021 at 3:55 AM "Christoph v. Wüllen" <DL1...@darc.de> wrote:

Take care the uC supports „Serial+MIDI“, such that you emulate a Winkeyer on the
serial port and talk to the SDR software via MIDI.

> There is one other latency to note, and that is CW-keypress-to-RF latency. In this solution it will be slighly more, I suspect in the 50-70ms range, as CW-keypress must be passed to computer and then HL2. But I don't think this matters in practice. If you consider the speed of light, operators already see a ~130ms there and back latency when working someone half way around the globe.
>
> Some may think that implementation of this idea will be a lot of work, but fortunately, there are several projects which make implementing a custom but universal (no custom driver) USB sound card easy. My first experiments are with the $20 Teensy 4.0 and $15 audio adapter. What is most attractive about the Teensy 4.0 is the well developed Teensy Audio Library.  This even has a drag-and-drop GUI design tool to create audio applications with USB audio, midi and serial endpoints plus final i2s interface.
>
> All that remains are CW keyer connections (very inexpensive prototype board to unused Teensy pins for now) and CW keyer code. For the CW keyer code, I'll probably first use N1GP's iambic keyer as it is simple yet covers all expected openhpsdr functionality. Finally, although there will some optional MIDI control, I think this can all be done with few if any host software changes. Instead of key down/up messages, the custom USB adapter can send shaped IQ CW data which is then just sent directly to the HL2 without software processing.
>
> Even now one can kludge together 3 boards (Teensy, audio adapter, keyer connector board) like I am doing for under $50. But if this idea takes off, I'd like to make it easier for people. One option would be to create a combined audio adapter and keyer connector board and sell it on Makerfabs. i2s codecs cost under $5.0 and connectors are cheap. This would sell for under $20 as another addon for the HL2. Yet another option would be to replace the Teensy with the new $4 Raspberry Pi Pico. There is already an audio board for the Raspberry Pi Pico so we know its special IO FSMs can be used for i2s. Also, the teensy audio library has been ported to other platforms, and given Raspberry Pi's history, Raspberry Pi will also have well supported libraries of their own. A final option, although the most work, would be to make a single custom board, maybe with a SAMD21 or 51 part, or even a module. All of these lower cost MCUs support native FS 12Mb/s USB. The Teensy supports native HS 480Mb/s USB which could be an advantage.
>
> I am looking for help with this project. I'm committed to trying at least the 3-board kludge, but there is much more which could be done. For example, maybe one would like to add a big MIDI-based tuning knob for tactile feel, create an enclosure, help with the coding, help with testing, port to a Pi pico, port the k3ng cw keyer code, etc. Please let me know if you have interest.
>
> 73,
>
> Steve
> kf7o
>
> 
>
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/30c72b12-fa5c-4737-a2a3-0391e0bc4efen%40googlegroups.com.
>
> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/fc00ff02-b5b5-4791-b4ea-64d5eb1c6be4n%40googlegroups.com.
>
> --
> 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.

> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/CAGayqouPF_BAu-qFqoFp%2BZdrep-LFZK%2BW9AddWrwnu-biAPPVw%40mail.gmail.com.

[Roger Critchlow]

Christoph --

We should keep this discussion on the Hermes-Lite list so we can hear other opinions.

Agreed, the sidetone is not delivered through USB Audio.  As I understand Steve's proposal, the sidetone is generated on the keyer and played through the keyer's audio output jack and is mixed with or suppresses the RX audio coming over USB Audio.  

You want to do the same thing with analog Audio, so the host SDR app would be talking to a different soundcard.  That's an idea.  Then we could use the Teensy LC, which doesn't support USB Audio.  

But it seems that if you have a USB connection, you should use it for as much as possible, rather than adding an extra cable and jack.

The sidetone could be a square wave or a sine wave with a raised cosine envelope.  I think the latter sounds better, but I probably couldn't hear the difference in a blind test.  I'm also not sure I could hear the 2.9ms latency of the 128 sample blocks in the Teensy Audio Library.

Your minimal Winkeyer emulation should be very useful.

73

-- rec -- ad5dz --

On Wed, Feb 3, 2021 at 4:06 AM "Christoph v. Wüllen" <DL1...@darc.de> wrote:

Oh no, no USB side tone from the Teensy.

Just produce a square wave at one of the output pins, *THIS* is zero latency.

See below the „hardware“ part of my keyer. It is fairly standard except that
I have a volume control for the side tone so in the keyer the side tone is always produced
irrespective of the WK2 control bits and is „switched off“ by turning the volume pot
ccw. Since the power comes from USB, I can afford a rather loud signal.

The part in the square is optional, I have it running
with a two-line LCD panel on a breadboard, but I think in the final version I will not
include the LCD.

The Teensy sends three types of MIDI messages:

CW key-down/up  via NoteOn/Off on key MIDI_CW in channel MIDI_CHANNEL
PTT on/off      via NoteOn/Off on key MIDI_PTT in channel MIDI_CHANNEL
CW speed        via controller value on controller MIDI_SPEED in channel MIDI_CHANNEL

MIDI_CW, MIDI_PTT, MIDI_SPEED and MIDI_CHANNEL are #defined in the top of the sketch.
The speed change messages are very comforable since then I see the speed of the keyer
in the piHPSDR window, and this will also control the speed of CW messages sent via
CAT commands.

To use the side tone from the keyer there are now two ways:

a) If you can comfortably hear the tone even with headphone simply use it.
b) otherwise feed it to the headphone in hardware (possibly after low-passing)

For b) the best is to have the primary side of an AF transformer in-line with the headphone
signal line and feed the audio from the Teensy to the secondary winding, because then
you have galvanic isolation.

For maximum comfort, add a „headphone in“ and a „headphone“ out jack to the keyer, such that the
headphone signal passes almost unchanged normally and gets the side tone „on top“ occasionally.
Use two audio transformers if you want the side tone on both ears with a stereo headphone.
Then, use a standard audio cable
from the source (computer) to „headphone in“ and plug your headphone into „headphone out“.

This suggestion seems rather low-tech, but I bet on getting the highest accuracy this way.
FYI, I also include my Teensy sketch, although K3NG etc. are more complete Winkey emulators
(but perhaps the sketch helps demonstrating what I mean).

[Steve Haynal]

Hi All,

Thanks for the comments. I have made some progress on this project. I have my Teensy 4.0 working in USB/Serial/Midi mode and can play audio to headphones. I have a raised cosine envelope tone generator. 

I agree there are many ways to do this. Here are some reasons for the choices I made:

** Teensy 4.0 versus Teensy 3.x: The 4.0 was similar price ~$20, has HS 480 Mb/s USB, and better processor. It might be used for other purposes in the future.

** i2s versus audio from Teensy DAC or mixed with analog: I want to avoid multiple wires. I want to reduce part count as an i2s codec has head phone amp, line out, line in, mic biasing, etc. An i2s code is a very inexpensive single part solution for most commodity audio requirements.

I am running at the default 44.1kHz so far. I may try to change that to 48kHz later but I am not sure it will matter. The Teensy clock is still slightly different than the host computer clock, so the host computer will have to resample for 44.1kHz or 48kHz. The Teensy operates in asynchronous USB audio mode and masters the i2s clock, which is true for most USB audio devices. I will try to measure host processing requirements for both.

The Teensy Audio Library does use default audio buffers of length 128 (2.9ms). Once done and I start optimizing, I think I can reduce that to 64 (1.5ms) or 32(0.8ms). There is one buffer between tone generation and the i2s. The raised cosine shaping I apply takes 2.9ms. Compare this to openhpsdr which takes 5ms.

73,

Steve

kf7o

["Christoph v. Wüllen"]

Hi steve,

How do you mix the sidetone from the teensy with the audio?

I have it now working on a breadboard, using a transformer. But

for this I need some decent output level so I produce a 3.3 Volt

square wave at a Teensy digital output pin and buffer it with

a transistor:

At digital pin D8, there is the square wave, and you put your headphone in one of the jacks

and connect the other one through a consumer audio cable with Radio/Computer/SoundCard,

whatever your audio source is.

The tricky thing is R6, a small resistor, whose optimal value will depend on the properties

of the transformer:

Making R6 smaller reduces the insertion loss but also weakens the side tone. So you have

to make R6 so small that during RX audio is equally loud on both ears, but the side

tone at maximum volume (volume pot RV2) should then be slightly more than loud enough

(reduce R1 to 500 ohms if still no success).

I admit that the square wave does not „sound“ optimal, and the audio envelope of

the side tone contains „hard brick walls“, but the „feeling“ in terms of accuracy

is absolutely fantastic.

P.S.: If you teach us how to produce a sine with a nice envelope at one of the Teensy 

pins, I shall try if I can get enough amplification of that signal to make it useful

with this schematic (note currently Q1 works „class C“).

P.P.S.: If you need the side tone on both ears one should use two transformers. On Amazon

I got 10 of them for the price of a glass of wine in a restaurant.

I think galvanic isolation is a good idea here.

The other parts of the hardware added to the Teensy (two opto-couplers and a speed pot)

are fairly standard.

Christoph DL1YCF.

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

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/5006e3bb-3e68-41c9-b35f-2c2729ac2c48n%40googlegroups.com.

[Steve Haynal]

Hi Christoph,

Thanks for sharing your circuit. It does look very simple and low latency.

I am mixing or muting the audio digitally within the Teensy. I am using the synth_sine function from the Teensy Audio Library to create a sine wave:

https://github.com/PaulStoffregen/Audio/blob/master/synth_sine.h

I apply a raised cosine or Hann window function to the beginning and end of the tone. 

If you are looking for something other than a square wave yet still very simple, you might consider using one of the PWM output pins:

 https://www.pjrc.com/teensy/td_pulse.html

73,

Steve

kf7o

[Steve Haynal]

Hi Group,

I have forked the k3ng_cw_keyer:

https://github.com/softerhardware/k3ng_cw_keyer

I applied a set of patches based on DL3LSM's fork to enable the teensy midi control. I turned on the USB audio and added my TeensyAudioTone. I am able to build this for the Teensy 4.0 and everything appears to be working. MIDI messages are sent to the host for CW key on/off. The HL2 audio is heard through the USB sound card. The low-latency shaped CW sidetone is also heard through the USB sound card.

This work is still in early phases, so expect changes, but I wanted to post what I have for those interested. I intend to either push changes back to the main k3ng repository if accepted, or keep my fork up to date with the latest from the main k3ng repository. 

This is my first look at the k3ng keyer and I am amazed at all the options and functionality it includes. It is truly the most feature rich keyer I have seen, with many more possibilities than the standard openhpsdr keyer.

My next immediate next step is to put together a MIDI control program for the host computer so that all the settings can be accessed and modified. Although SDR software may and can do this in the future, I also want a separate configuration program which is independent of any particular SDR software. I am looking at Ctrlr https://ctrlr.org/. With this one only has to create an XML file describing knobs, sliders, buttons to display and what MIDI messages they should send. It runs on all OS platforms. There is also web midi which looks interesting, but I think will require more coding/time. For this project, which I am trying to keep short, I am leveraging as much existing work as I can (Teensy USB audio hardware and library, k3ng keyer, ctrlr, etc.)

https://www.midi.org/17-the-mma/99-web-midi

73,

Steve

kf7o

["Christoph v. Wüllen"]

> Am 07.02.2021 um 08:21 schrieb Steve Haynal <softerh...@gmail.com>:
>
> Hi Group,
>
> I have forked the k3ng_cw_keyer:
> https://github.com/softerhardware/k3ng_cw_keyer
>

I looked at this, and here are my observations/suggestions/bug report:

- the code seems to require an external audio hardware „Teensy Audio Shield“.
Have you tried with the „MQS“ audio output machine, this will produce a
PWM stereo signal at pins 10 and 12. I have tested this for side tone only,
and it make a decent sound.

- I suggest to add a pot, read its position with an analog input, and
adjust side tone level accordingly. The pot need not be a „pot“
case-mounted, a trimmer on the small board where the opto-couplers are
will do as well

- Since I could not check: does the side tone work if there is no audio
stream from the computer, e.g. in standalone „practise“ mode?

- It seems that midi_ptt() and ptt_key() are mutually exclusive at some
places. This could mean that the hardware PTT line is not handled
correctly sometimes.

- This bug kills the keyer for me (possibly a setupt problem?):
I constantly loose PTT and shortly thereafter experience a new
PTT lead-in delay. Measuring the PTT hang time I found out that
(all times in milli-secs)

PTThang = 3*dotlen + 10*PTTtail

where dotlen is the dot length (1200/speed) and PTTtail is the
value from the WinKey protocol (between 0 and 25). This value
does not depend on the two „PTT hang bits“ of the WinKey protocol.

THIS IS WRONG. The correct calculation is

if (PTTail == 0)
PTThang = 10*PTTtail;
else
PTThang = (6+x)*dotlen;

where x=1,2,4,8 depending on the bit pattern of the two hang bits.


For the Non-CW-OPs: the lead-in time depends on the radio but not on the
CW speed, but the hang time must be proportional to the CW speed.
Therefore I always set PTTtail to zero and work with the hang bits.

Yours,

Christoph DL1YCF

[Scott AK5SD]

I actually built DL3LSM's Teensy-based keyer with MIDI output to key my FlexRadio remotely as well as the HL2. I have used it on the Flex but haven't tried it on the HL2 yet. It works very well. I put the Teensy into a 3D printed case that I found on Thingverse https://www.thingiverse.com/thing:1979816) and wired up a 3.5mm cable to the appropriate GPIO pins. That's all there was to it (other than downloading and compiling the code).

73,

Scott

AK5SD

[Steve Haynal]

Hi Christoph,

Thanks for the feedback. I haven't gotten to testing the PTT-related or even MIDI to software portions yet, but will definitely keep what you say in mind.

I am working on a ctrlr midi controller panel to control and configure the keyer. So far it is working pretty well. I'd like to depend on this for configuration to keep costs down and the design simple, but it should be possible to add a POT or quadrature encoder is a user wishes.

Although there several ways to create the tone, I am pretty set on using an i2s codec. These are a commodity part. Assembly houses like those which Makerfabs use have easy and inexpensive access to them. They are a single part solution to headphone amp/line in/mic in/line out and use at least CD quality 16-bit 44.1kHz.

73,

Steve

kf7o

[Steve Haynal]

Hi Scott,

Thanks for sharing your build. It looks very nice. When you use this with a FLEX, what is the latency like? Is the sidetone generated by software on the PC? One reason I am going for the Teensy 4.0 with USB audio is for low latency sidetone mixed with the HL2 audio.

73,

Steve

kf7o

[Scott AK5SD]

Steve,

If by latency you mean the delay from touching the paddle to when the FlexRadio keys, then it will be network dependent. On my local LAN, it is very low. I have not measured it so I cannot give you exact numbers. The client software xKey intercepts the MIDI commands from the Teensy and then sends keying commands to the Flex using its API. It's the same way that the Maestro keys the Flex remotely, if you are familiar with that product. It will perform as well, or as poorly, as the Maestro would under the same network conditions. As the ethernet latency increases, so will the keying latency. I'm not sure how the API handles ethernet jitter for maintaining proper timing of the keying. To really know for sure how it works under varying network conditions, I would either need to be able to simulate those conditions locally or set up the client remotely and listen to the Flex transmitter in a remote receiver (preferably an analog receiver with no latency).

My build does not have built-in sidetone like you are considering for the HL2. With piHPSDR I think that can be created in the software. I haven't compiled piHPSDR with CW support yet but it's on my to-do list. For the Flex, xKey can generate the sidetone. To test this, I set the keyer for 25wpm and sent some code. I was error free. I did not have a problem with latency creating problems for me. That's about as fast as I go. Keep in mind that this is on a Mac and results depend on the audio latency and coding of the xKey application. On a Windows machine or with other client software, results may be different.

73,

Scott

AK5SD

[Roger Critchlow]

Hey Steve --

There's another bunch of controller surface builders that use OSC, Open Sound Control, which is a natively networked superset of MIDI.

Not that I think you need more choices to sort through, but google "OSC controller" brings up a page of options.  

I was looking at https://openstagecontrol.ammd.net/ at one point.

-- 73 -- rec -- ad5dz --

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

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/1da096b7-258b-40a0-add0-92c06e0d4f34n%40googlegroups.com.

[Steve Haynal]

Hi Roger,

Thanks for the link. I did see that but was scared away by the heavy sounding nature of having to run a separate server. I've actually been quite happy with ctrlr once I figured out how to program it. I hope to add it to github this weekend.

I also just refactored the keyer code. I wanted less of my code in k3ng_keyer.ino (everything is very flat in that file) and more standard C++ organization. Everything I am working on is now in src/TeensyUSBAudioMidi with only a few hooks in the main .ino file and headers.

73,

Steve

kf7o

[J P Watters]

 Steve,

I have a Treensy 4.1 (IMXRT1062. Chip), Audio Shield ( for a Teensy 4.0), and a 2.8 SPI TFT Module (IL9341 driver)

Is that all the hardware I will need to implement your version of the K3NG Arduino CW Keyer, additionally I would like to include a CW decoder. 

..jpw J P Watters

KC9KKO

Morris, IL USA

k3ng_cw_keyer

--
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+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/30c72b12-fa5c-4737-a2a3-0391e0bc4efen%40googlegroups.com.

[Steve Haynal]

Hi JP,

I think just the Teensy 4.1 and Audio shield should work. I am using the Teensy 4.0 so not 100% sure about the Teensy 4.1.

73,

Steve

kf7o

To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.

[Steve Haynal]

Hi Group,

Here are a few updates on this project. I heard that some see think of this project as for remote use only. It is intended for both remote and local use. It is intended as a replacement for the AK4951 companion card, and improves on it by supporting both remote and local operation, conserving valuable FPGA resources for RF DSP, working with software such as SDR Console and Quisk which do not send audio back to the HL2, and costing less, all without any sacrifices.

Last year I posted this about using MIDI for CW to the HL2 and low latency audio on the PC for sidetone. I didn't do much work on that, but others in this group did. SparkSDR and Quisk both added features for MIDI CW input. ZL2APV made experiments and wrote up results. See the software wiki page as well as this and this. The overall feedback I heard was that MIDI CW input works, but latency of sidetone generation on the PC can be an issue at higher CW speeds. Furthermore, it is very difficult for software to be refactored and use low latency audio such as JACK and ASIO for the sidetone. Finally, even if it is possible to use low latency audio, it can be very difficult for an average user to set this up, especially across various OS platforms. Now I am taking this feedback and including USB audio and a keyer in the USB gadget. This addresses the latency concerns.

I've made updates to the github repository. The basics are working and I tested with Quisk this evening. Below is a picture of the MIDI ctrlr panel created to control the basics. More settings can be controlled as the project evolves.

This is for use when software doesn't support all features, or during development.

Here is a picture of my prototype setup. Note the Teensy 4.0 plugged into the audio shield at the back. I then have a small prototype board with connector for the key. I am using the same minimal 10nF filter for key input as seen on the k3ng schematics.

 

Anyone can build a prototype like this right now if they want to join in the development or experiments. I plan to post more details on the github site. But I do plan to have Teensy "shield" boards built for those who want a more finished product. For example, places like JLCPCB already include the SGTL5000 i2c codec used on the Teensy audio shield in their stock of standard parts. Even in small quantities this is under $4. Places like Makerfabs and JLCPCB will make the PCBs and assemble, with assembly under $0.01 per pin, for a complete turnkey solution. The shield will have keyer jack, audio line in/out, mic in, etc. I would like to fit it in a nice inexpensive enclosure. 

I am looking for help with this project and will reach out to some that have already expressed interest in helping. In particular:

** Decide on a final set of functionality and form factor for a first prototype.

** Measure and optimize sampling rates, pin debouncing, audio latencies in the current setup.

** Enable some of the other good k3ng features. Right now I have a very basic set enabled.

** Enhance the current code and ctrlr panel.

73,

Steve

kf7o

[RD Powers]

I read the email and kind of re-wrote it in what I think may be a more concise form, and ended up with a few questions. 

Note I am pretty new to this space, so please expect some basic misunderstandings.

Overall, perhaps a block diagram showing the various parts and connections, and how control (keying) and data (audio streams) are flowing, would be helpful.  

Here it is:

Goals:

  - Avoid delayed CW sidetone observed when radio applications that use MIDI 

    devices and protocols to support keying are operated at high CW rates

  - Avoid the need to refactor radio application software to use low-latency 

    audio servers to provide low latency CW sidetone functionality

  - Provide a dedicated device that avoids complex software configurations

  - Provide a replacement for the AK4951 companion card, with improvements

  - Support both local (i.e. operator co-located with radio) and remote use

  - Conserve valuable FPGA resources for RF DSP use, rather than CW sidetone

    functionality

  - Support software such as SDR Console and Quisk that does not sent audio

    back to HL2 (not sure what this means...)

Approach:

  - Create a USB CW Gadget that supports sidetone generation and keying

  - This device will initially be controlled via a software MIDI control panel

    function that can control sidetone amplitude, frequency and volume along

    with keyer rate in words per minute

  - Project will be based on a Teensy 4.x Arduino device running the K3NG 

    keyer code

  - Project will create a Teensy Shield (i.e. hardware add-on card) 

  - Teensy Shield will have keyer input jack, audio line in and out jacks, 

    microphone input jack, and perhaps other inputs and outputs

  - Teensy Shield will have an audio I2S chip to mix the side tone being 

    generated with the audio (from the audio-in jack? from the USB?)

  - Teensy and Shield are powered via USB

    

Questions:

  - Didn't we want to avoid MIDI, yet we are using a MIDI app for control?

  - What actually keys the radio?  Need a jack for keyed output?

  - What flows over the USB?  Power, yes.  Control, presumably.  Audio

    from the radio?  But how would that work in the "remote" use case?

    Do we always need a local computer connected to the USB?

Thank you for the effort, I am already planning to buy one.  

Regards,

RDP

[James Ahlstrom]

Hello,

I will try to add to this because if I get it wrong Steve will correct me and then we both will know!

I think the magic is that Steve's USB-connected device will present itself to the PC as a sound card, and the PC will play radio sound through it. The CW key is attached to the device, and the  device will also generate the sidetone and mix it with the radio sound. No MIDI is involved, as the key is on an IO pin. This is a great simplification over trying to this in software. So far we have radio sound plus instant sidetone. There must be a control interface to adjust volume and frequency. Doing this on the PC makes sense, but you could have knobs instead. I don't think it is required to use MIDI back to the PC for this.

The remaining problem is to tell the PC the key up/down state so it can actually key the transmitter. I am not sure how to do this. MIDI is one way but is not required.

The design hinges on the USB interface. A USB can present multiple end points, that is, interfaces. But we are trying to use off-the-shelf hardware and software. It is clear that we need a USB/microcontroller that presents itself as a sound card so no custom drivers are required. If it has sound maybe it has midi? Or maybe the USB can present a second end point to function as control?

Jim

N2ADR

[Roger Critchlow]

Steve --

I'm game.

If you're targeting a custom Teensy 4 for this, then you'll need the preprogrammed Teensy bootloader chip, https://www.pjrc.com/store/ic_mkl02_t4.html, which pjrc.com sells to support their software development costs when designs outgrow the Teensy hardware.  I think that it's a good idea to keep the benefits of the Teensy Audio library, the Teensy composite USB device, the Teensy reflash over USB, and all the rest of the Teensy ecosystem.

The real advantage of the Teensy 4.0 is in the appended screenshot showing the USB devices it implements out of the box.

I was underwhelmed by the k3ng keyer, I couldn't see how it knew when to do things in the midst of all the things it might be configured to do.  And the sort of random distribution of key polling calls throughout the code suggested that the author(s) probably weren't too sure how or when things were being delayed, too.

But I've actually prototyped a solution to this problem in https://keyer.elf.org, a keyer that runs in chrome using web audio and web midi.  The trick is to move all the timing logic into the audio processing loop and use the sample clock.   As long as the rest of the code doesn't stall the audio processing pipeline, everything just happens at the right time.  (Or it would, if google wasn't introducing 60-70ms of latency into its web midi implementation, sigh, measured relative to the JACK implementation of the keyer on the same hardware.)

There are a bunch of upgrades to the Teensy audio that we might look at: getting additional sample rates, optimizing audio streams of booleans, sample accurate MIDI in the audio pipeline, and so on.  But I think getting the hardware to work at 44100 with the library as it is would be a good initial target.  The only upfront consideration might be that we can generate accurate clocks for other sample rates when someone really wants to work on that.

I think this kind of project often devolves into a jack packing problem.  Let me suggest that we bring signals to be interfaced out to header pins and package as a configurable squid with audio jacks on short cables connecting through dupont headers to the interface pins.  Connect your choice of jack cables to your choice of interface pins and heat shrink the bundle.   Change your mind?  Cut the heatshrink off and redo.  Need shielding?  Wrap the first heatshrink layer in copper tape bonded to the USB shield and heatshrink again.

Does the codec by any chance have TRRS headset detection?  It would be really nice to support the gazillions of earbud headsets at large.  Use the headset button as emergency straight key.

But I really like the general scope as I hear it:  a stereo USB audio card, line in/out stereo for softrocks et al., key input, headphone output, keyer generating local sidetone mixed with USB audio input, sending MIDI and/or Serial keying events to the host,   Or run without the host using a 6V battery pack with a USB micro plug on it.

-- 73 -- rec -- ad5dz --

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/0e7b1c7b-abba-428c-a2a3-c3ec13730bben%40googlegroups.com.

[Roger David Powers]

Thanks, Jim for the note.  I was confused because I thought the Gadget would be connected to the key input of the HL2.  Your statement (if I understand it correctly) that the Gadget would send its keyer application's output to the radio application (through a yet-to-be-determined control path, perhaps MIDI) and then the radio application would key the radio through its current methods allows me to understand how the remote use case works. 

Thanks,

RDP

--
You received this message because you are subscribed to a topic in the Google Groups "Hermes-Lite" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hermes-lite/P-i_EYCN--k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hermes-lite...@googlegroups.com.

To view this discussion on the web visit

https://groups.google.com/d/msgid/hermes-lite/3374705d-c93e-427e-9ab3-0773b2f9b707n%40googlegroups.com

.

[Steve Haynal]

Hi RDP and Jim,

I've been using the Teensy 4.0 microcontroller. This is a USB 2.0 (HS) capable microcontroller. It presents Audio, MIDI and Serial endpoints to the PC. Currently I am sending the CW key up/down back to software via MIDI, but I'd like to also send just shaped IQ at 48kHz which software can then pass directly to the HL2.  I think the key idea is that it appears to host software as a sound card, so the host software (Quisk, SDR Console, etc.) just sends audio like normal to the USB gadget. But the gadget has a built-in keyer which will generate the low latency sidetone mixed with the HL2 audio for the user's headphones where low latency matters. For CW TX RF, the key up/down message is passed via USB to host computer software and then via ethernet to HL2.

73,

Steve

kf7o

[Steve Haynal]

Hi Roger,

I've also read about the bootloader chip also. I agree it is a good way for the developer to monetize his work. I don't know if I want to go through the trouble of creating a complete new board but was instead thinking of using the existing Teensy 4.0 and creating a shield for the audio and keyer connections. The Teensy developer actually lives less than 5km from me. I've seen him at some meetings and communicated about nearby Zel Pro Assembly solutions which he uses to assemble his boards. I was thinking that once this project is farther along, I could approach him about selling this keyer shield as a add on board as he is already setup for order fulfillment. 

I am not sold on the k3ng keyer, but thought it was a good place to start. The code in my github repository is already working. It sends the note on/off on channel 1 note 1. I tested it with Quisk last night.

I like the idea of supporting TRRS and the ubiquitous earbud headsets that are out there. I will check into that. The current codec already has mic input, so it may just be a matter of wiring up the correct jack. I was also thinking up putting a MEMS microphone directly on the PCB. The similar microphone in my laptop has been doing a great job these past 11 months of working from home with Zoom meetings.

73,

Steve

kf7o

[Steve Haynal]

Hi JP,

Connection 1 goes to my headphones. I am using the same circuit to connect the two paddle connections as in the k3ng schematic, direct connection but with 10nF to ground:

https://radioartisan.files.wordpress.com/2011/03/k3ng-keyer-schematic-2012052101.png

I am using pins 0 and 1 on the teensy for the paddle.

I hope to add more information to the github page this week.

73,

Steve

kf7o

On Mon, Feb 15, 2021 at 9:55 PM J P Watters <jpwa...@gmail.com> wrote:

Steve,

In your photo of the Teensy, Audio Shield and the prototype board.

The connection labeled 1) goes where, to a speaker?

and do you have a schematic of the wiring in area labeled number 2.

--

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/c7959eb0-ab29-408e-8bb8-16aebfd711d3n%40googlegroups.com.

[Robert Benedict]

Steve

   Thanks for taking this on. I suggest that you include straight key support by the preferred direct pin activation, even though this add a jack.

https://github.com/k3ng/k3ng_cw_keyer/wiki/400-Operating-Modes#straight-key-support

  73

    Bob   KD8CGH

[Mike Zabel]

Hi All,

I am very interested to try this out. I am ready for a prototype build with some of the required hardware gathered.

As I read here my memory was jogged to bring up this project

 https://sites.google.com/site/iqkeyerproject/

Although designed for radios that accept IQ directly the feature set is nice and code is open source so perhaps something to study.

73, KV4TT Mike 

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/ce36e963-401b-49db-93a2-9c3ba40d0740n%40googlegroups.com.

[Roger David Powers]

Ok, based on recent feedback, here's a summation of what I think the project is, hopefully not leaving out too much.  If you are using the device I think you are using (I have Fe-Pi sound card for RPi based on one of these devices) it has an Audio DSP built in so can do some audio signal processing on the transmit audio too, so I added that in.  It is a bit of a bear to figure out how to set up, but eventually it can be done using alsamixer.

Goals:

  - Avoid delayed CW side tone observed when radio applications that use MIDI 

    devices and protocols to support keying are operated at high CW rates

  - Avoid the need to refactor radio application software to use low-latency 

    audio servers to provide low latency CW sidetone mixing

  - Provide a dedicated device that avoids complex software configurations

  - Support both local (i.e. operator co-located with radio) and remote use

  - Conserve valuable FPGA resources for RF DSP use, rather than audio

    functionality

Approach:

  - Create a USB CW Gadget that presents itself as a USB sound card to software

  - The Gadget's key feature is that it provides a keyer along with an audio 

    device that mixes the receiver audio and the keyer sidetone with very low 

    latency, lower than can be achieved by the chosen radio application

  - Gadget can present Audio, MIDI and Serial endpoints via USB2 to host

  - This device will initially be controlled via a software MIDI control panel

    function that can control sidetone amplitude and frequency, keyer rate in 

    words per minute and master volume

Hardware:

  - Project will be based on a Teensy 4.x Arduino device initially running the 

    K3NG keyer code

  - Project will create a Teensy Shield (i.e. hardware add-on card) 

  - Teensy Shield will have keyer input jack, headphone jack, audio line in and     

    out jacks, and perhaps other inputs and outputs (straight key?) 

  - Teensy Shield will have an audio I2S chip to mix the sidetone generated 

    by the keyer with the receiver audio from the USB sound card and optionally

    perform audio signal processing on the voice input as well

  - Teensy and Shield are powered via USB

Physical Configuration:

  - HL2 is connected to host computer via Internet, may be local or remote

  - Gadget is connected to the host computer via USB

  - Headset (or speaker plus mic) is connected to Gadget

  - Keyer paddles are connected to Gadget

Event Flow:

  - Operator is listening to receive audio via headset or speakers

  - Operator may use mic for voice modes with audio device optionally enhancing

    transmitted audio

  - Operator uses keyer paddles to send CW 

  - Gadget's keyer generates sidetone which is mixed with receive audio and 

    presented to headphones / speaker

  - Binary keyer up/down events are currently sent via MIDI to the host computer

  - A shaped keying waveform represented by 48 kHz IQ samples will be sent

    via the USB soundcard function to the host computer

  - Radio application on host computer receives keying events/waveform

  - Radio application sends keying events/waveform to HL2 via Internet

Thanks,

RDP

[Roger Critchlow]

On Tue, Feb 16, 2021 at 12:55 AM Steve Haynal <softerh...@gmail.com> wrote:

Hi Roger,

I've also read about the bootloader chip also. I agree it is a good way for the developer to monetize his work. I don't know if I want to go through the trouble of creating a complete new board but was instead thinking of using the existing Teensy 4.0 and creating a shield for the audio and keyer connections. The Teensy developer actually lives less than 5km from me. I've seen him at some meetings and communicated about nearby Zel Pro Assembly solutions which he uses to assemble his boards. I was thinking that once this project is farther along, I could approach him about selling this keyer shield as a add on board as he is already setup for order fulfillment. 

Okay, a shield for the teensy works, too.

 

I am not sold on the k3ng keyer, but thought it was a good place to start. The code in my github repository is already working. It sends the note on/off on channel 1 note 1. I tested it with Quisk last night.

I like the idea of supporting TRRS and the ubiquitous earbud headsets that are out there. I will check into that. The current codec already has mic input, so it may just be a matter of wiring up the correct jack. I was also thinking up putting a MEMS microphone directly on the PCB. The similar microphone in my laptop has been doing a great job these past 11 months of working from home with Zoom meetings.

I don't see any headset detection in the SGTL5000.  The issues are 1) TRRS headsets have two wirings worldwide, TRRS = LRGM or LRMG, 2) three wirings counting plain stereo headphones, TRRS = LRGG, 3) four wirings counting plain mono headphones, TRRS = LGGG, 4) five wirings counting nothing plugged in at all.   Then 5) the headset button(s) shunt mic bias to ground through various resistances.

https://www.diodes.com/assets/Datasheets/AZV5001.pdf and https://www.nxp.com/docs/en/data-sheet/NCX8193.pdf both ignore the LRGM/LRMG issue, maybe it's history or maybe I didn't read closely enough.. https://www.ti.com/lit/ds/symlink/tpa6166a2.pdf distinguishes LRGM/LRMG, stereo headphones, stereo line out, and mono headphones, and provides button detection.  

I haven't spent much time researching options, but there are probably a lot since every phone with a headset jack has to deal with this one way or another.  I seem to remember a TI part which handled soup to nuts from I2S to headset button decoding.  Might see what MakerFabs and JLCPCB have on their standard parts lists.

Another question is whether we provide a key/ptt out that's suitable for directly plugging into the HL2.  I suppose we could even add a push button that temporarily shorts key to ptt.

I've used the MEMS I2S interfaced microphones, and they're great.

-- rec -- ad5dz --

 

73,

Steve

kf7o

[Alan Hopper]

Hi Steve,

this all looks like a really good solution, I had pondered an audio codec or mixer on my midi cw interface .  Jim made a really good point a while ago that people should not be tied to a given bit of software and this looks like you should be able to use it with most software.  David M0WID made an interesting suggestion here https://groups.google.com/g/sparksdr/c/zCPYaqpSyvE/m/EMl2_ODHAgAJ about using the web socket interface to spark for cw and ptt etc, I wonder if there could be a wifi esp32 variant.  An embedded microphone is attractive, especially if it has a ptt button, if you want to get really carried away there are devices like this H60 Wireless Handset | B&G Sailing Electronics (bandg.com) .  The audio cw input option is interesting, my initial thought for Spark is that I prefer a midi or other keying signal as it allows perfect generation of a 100% full power output without worrying about audio level/format settings and is probably a bit faster, but I can see the value of it.  An exciting project and maybe it could be sold at a profit to fund hL2 development  

73 Alan M0NNB

[Roger David Powers]

Re: WinKey compatibility: Does the K3NG keyer code offer that, or is it 

something that would need to be added?

Re: Audio processing: Datasheet linked below says the SGTL5000 has "Integrated 

Digital Audio Processing" with "Surround, bass, tone control / parametric 

equalizer / graphic equalizer" so it is already a part of Steve's Gadget.

Link: https://www.nxp.com/products/audio-and-radio/audio-converters/ultra-low-power-audio-codec:SGTL5000

Re: CW keying waveform: I took that out of Steve's previous email

Re: Role of the radio application / SDR program: Good point, but please keep 

in mind that I did my summary because I was having a hard time visualizing the 

roles of the various elements.

Re: Straight Key pin:  I like Roger Critchlow's suggestion yesterday:

> I think this kind of project often devolves into a jack packing problem.

> Let me suggest that we bring signals to be interfaced out to header pins

> and package as a configurable squid with audio jacks on short cables

> connecting through dupont headers to the interface pins.  Connect your

> choice of jack cables to your choice of interface pins and heat shrink

> the bundle.   Change your mind?  Cut the heatshrink off and redo.

> Need shielding?  Wrap the first heatshrink layer in copper tape bonded

> to the USB shield and heatshrink again.

Maybe make pre-made "minimalist" and "soup to nuts" harnesses available?

Thanks,

RDP

[Robert Benedict]

RD

  K3NG firmware includes the option for Winkey emulation. I have a MORTTY K3NG arduino keyer with WinKey enabled and it works well.

    73

    Bob   KD8CGH

[Roger Critchlow]

A quick point of information.  

While waiting for the correct hardware, I just dug out a Teensy 3.2 mated to the Teensy 3 version of the audio card.  I compiled softerharderware/k3ng_cw_keyer and downloaded it onto the Teensy 3.2.  The compile reported:

Sketch uses 51932 bytes (19%) of program storage space. Maximum is 262144 bytes.

Global variables use 14268 bytes (21%) of dynamic memory, leaving 51268 bytes for local variables. Maximum is 65536 bytes.

So there's plenty of headroom to run prototypes of this project on the Teensy 3.2, if that's what you have.

Now I need to find the app that runs the controller, ah, but it won't run:

$ ./Ctrlr
./Ctrlr: error while loading shared libraries: libbfd-2.34-system.so: cannot open shared object file: No such file or directory
$ find /usr/lib -name libbfd* -print
/usr/lib/x86_64-linux-gnu/libbfd-2.35.1-system.so

-- 73 -- rec -- ad5dz --

 

[Steve Haynal]

Hi Mike,

Thanks for the link. Yes this very similar. Some differences are that what we are doing with the Teensy is also a USB sound card, and uses a more powerful microcontroller which supports USB 2.0. Also, it should be about 1/3 the cost at least for an assembled PCB.

73,

Steve

kf7o

[Steve Haynal]

Hi RDP,

Thanks for capturing this. I think it is an accurate and comprehensive summary. I just want to comment that it isn't the use of MIDI which causes latency. MIDI has worked fairly well. It is the audio buffering required on a standard PC to avoid dropped audio and clicks which adds latency. It is hard to reduce the size/delay of these buffers without introducing audio artifacts.

73,

Steve

kf7o

[Steve Haynal]

Hi Roger,

Regarding a shield vs a single board, for small quantities the cost of the i.MX RT1062 plus license chip from pjrc is comparable to the cost of a Teensy 4.0. But there are also other less expensive members of this family which still have USB2.0, i2s and enough memory, such as the RT1010 or RT1021. Places like JLCPCB stock the MIMXRT1021 in a package that is easier to use on inexpensive 4-layer PCBs. I will check with pjrc about using their license chip with other members of this family. Also, ADAFruit is working on the Metro M7 iMX RT101. They may have a decent opensource boot loader we can use instead once they release it.

I need to research interfacing headsets to i2s devices more. It may be that the various voltage levels pulled on the mic bias can be read by one of the ADC inputs on the microcontroller. We can also use a different i2s device. There are several already supported in the library. Maybe one of those has better headset support.

I was also thinking a ptt/cw output for direct connection to the HL2 would be nice, but something I don't want to depend upon.

73,

Steve

kf7o

[Steve Haynal]

Hi Alan,

Thanks for the feedback. I'm starting to worry a bit about feature and option creep. I think with the HL2 I went a bit overboard with too many options. There are still things on the HL2 that no one has used... I'm anxious to get this project rolling and in small batch production, and then hopefully others will take over.

73,

Steve

kf7o

[Steve Haynal]

Hi Bob,

Yes, we can enable Winkey emulation. I have it turned off currently as I am using that serial port for debug, but shouldn't be an issue to enable it.

Also, I'd like straight key support too. What are the advantages to having a separate jack rather than just use the existing paddle jack? Just plug your straight key into the same jack and have the microcontroller interpret the pins differently?

73,

Steve

kf7o

[Steve Haynal]

Hi Roger,

Did you download the latest stable version of CTRLR? When I first tried it, I downloaded the latest build which didn't work and then built from github and that didn't work. The stable version 5.3.201 near the bottom of this page worked for me:

https://ctrlr.org/

That is great that it works with the Teensy 3.2 also. I wonder how much difference a USB 1.0 FS versus USB 2.0 HS makes. To me it just seems better to use USB 2.0 for a new device given the costs are comparable.

I have 48kHz working. I don't notice much difference on host CPU with converting 48kHz to 44.1kHz or 48kHz PC to 48kHz Teensy. Pulse Audio is always around 2% CPU usage. The Teensy loader is worse and chews up 18% constantly when it is up.

I also have reduced the default buffer size to 64 with everything including USB Audio working. I and Christoph have noticed that there are occasional crackles. I notice one maybe every 1 to 5 seconds. It would be unnoticeable when listening to a radio with static. I've instrumented the code and see that this is due to under/overflows of the USB audio buffers. It is a bit worse at 64. It is unusable at 32 but a bit better at 256. I think this can be improved by adjusting the USB clock frequency feedback, adjusting the Audio PLL (this microcontroller has a very nice fractional one) and/or increasing the USB audio buffers but still running the reset of the chain at 64 or 32. I'm becoming familiar with all these options and think it is doable. All these changes touch 6-7 files in the Teensy core and Audio libraries. I haven't come up with a clean way to share my changes besides just forking these two repositories. Any suggestions?

73,

Steve

kf7o

[Robert Benedict]

Steve

   The advantage of a separate jack for a straight key comes from the K3NG code which has limited straight key functionality unless a separate jack and pin is used.

from the K3NG WIKI:

"There are two ways to use a straight key with the keyer:

Go into straight key mode by holding down the right paddle when powering up or power resetting. This places the keyer exclusively in straight key mode with very limited functionality. Activate FEATURE_STRAIGHT_KEY in features_and_options.h and define pin_straight_key in keyer_pin_settings.h . Grounding the pin with a straight key will give you straight key operation in parallel with paddle operation and still give you access to all the normal keyer functionality."

  stay warm

      Bob

--
You received this message because you are subscribed to a topic in the Google Groups "Hermes-Lite" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hermes-lite/P-i_EYCN--k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hermes-lite...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/edf17920-249f-4363-bc24-f715f4629ffdn%40googlegroups.com.

--

["Christoph v. Wüllen"]

I absolutely opt for an independent straight key jack. I have this functionality
in my keyer and it is very nice that one can switch between paddle and key
in no time.

Make sure it is a stereo jack and both contacts are joined then go to the input pin.
This is important for single-lever paddles being used in „cootie“ mode.

Yours Christoph DL1YCF.

> 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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/CACe_BLG4mh1UCk0%2B3p82MQ8t_nb5vEDt8aqU-45AXVgf-C3-_g%40mail.gmail.com.

[Roger David Powers]

Thanks for the clarification on MIDI, Steve!  As I wrote earlier, I wrote the summary to try to wrap my head around what you were proposing, and the role of MIDI in all this was not clear to me.  I've rewritten the first line of the goals based on your last e-mail.  Also I have incorporated other comments on straight key and Winkey compatibility based on the replies over the last 24 hours or so.  At this point I think I'm close to being done updating this summary.

I agree feature creep is an issue.  I put the info about the audio processing based on my use of the Fe-Pi sound card for Raspberry Pi.  To be honest I wish it was a simpler device.  For whatever reason the one I have comes up in an unusable configuration and I had to go through its data sheet and the alsamixer settings bit by bit to get it configured to do what I wanted to do i.e. act like a traditional PC sound card without any DSP stuff enabled.  Yet the DSP stuff is there, and might be useful if we can come up with some recommended settings for radio use.  Or we might just want to publish settings with DSP off and avoid the complexity all together.  Again, though, my experience was that I had no choice but deal with the complexity because out of the box it came up in an unusable configuration.

And, thanks again for all your work on HL2.  As your recent email on HL2 production shows, success is building upon success.  I've only had mine a few weeks but am totally satisfied with it.  I'm already considering buying a second one for portable/remote use.  I've already recommended it to several friends.  I think a lot of people have fear of the unknown, as did I, but that seems to be only an initial hindrance.  The variety of software available is amazing, the amount of new ideas being tried on this device is amazing, and the community supporting it is also amazing.

So, here's my updated (and potentially last) updated summary of the USB Keyer Gadget:

Goals:

  - Avoid the delayed CW side tone observed at high CW rates due to high

    latency that occurs because large amounts of buffering is typically 

    being used by radio applications to avoid dropped audio and clicks

  - Avoid the need to refactor radio application software to use low-latency 

    audio servers to provide low latency CW sidetone mixing

  - Provide a dedicated device that avoids complex software configurations

  - Support both local (i.e. operator co-located with radio) and remote use

  - Conserve valuable FPGA resources for RF DSP use, rather than CW sidetone

    functionality

  - Provide Winkey compatibility

Approach:

  - Create a USB CW Gadget that presents itself as a USB sound card to software

  - The Gadget's key feature is that it provides a keyer along with an audio 

    device that mixes the receiver audio and the keyer sidetone with very low 

    latency, lower than can be achieved by mixing on the host computer

  - Gadget can present Audio, MIDI and Serial endpoints via USB2 to host

  - This device will initially be controlled via a software MIDI control panel

    function that can control sidetone amplitude and frequency, keyer rate in 

    words per minute and master volume

Hardware:

  - Project will be based on a Teensy 4.x Arduino device initially running 

    the K3NG keyer code

  - Project will create a Teensy Shield (i.e. hardware add-on card) 

  - Teensy Shield will have keyer input jack, audio line in and out jacks, 

    headphone jack, and perhaps other inputs and outputs (straight key?) 

  - Teensy Shield will have an audio I2S chip to mix the sidetone generated 

    by the keyer with the receiver audio from the USB sound card and optionally

    perform audio signal processing on the voice input as well

  - Note that the SGTL5000 device has Integrated Digital Audio Processing with 

    Surround, bass enhancement, tone control, parametric and graphic equalizers

  - Teensy and Shield are powered via USB

Physical Configuration:

  - Radio is connected to host computer via Internet, may be local or remote

  - Gadget is connected to the host computer via USB

  - Headset is connected to Gadget's headphone jack, or line in/out may be used

  - Keyer paddles (and/or straight key) are connected to Gadget

Event Flow:

  - Operator is listening to receive audio via headset or line out

  - Operator may use mic or line in for voice modes with audio device 

    optionally enhancing transmitted audio

  - Operator uses keyer paddles and/or straight key to send CW 

  - Gadget's keyer generates sidetone which is mixed with receive audio and 

    presented to headphones / speaker

  - Binary keyer up/down events are currently sent via MIDI to the host computer

  - A shaped keying waveform represented by 48 kHz IQ samples will be sent

    via the USB soundcard function to the host computer

  - Radio application on host computer can receive keying events/waveforms

  - Radio application can send keying events/waveforms to radio via Internet

Regards,

RDP

[Roger Critchlow]

Gosh, so much activity this morning.

Definitely a separate jack for straight key.  And there will be people who would really like to have two paddles available at the same time, maybe just to compare the two, or maybe because they like to change things up while operating.  And ability to easily switch speeds on the same paddle is also a useful feature, rag chew at a relaxed rate, then shift into turbo speed through the over.

And as Christoph mentions, some of the otherwise global properties of the keyer, like ptt hang time, change depending on the key being used.

I started my own version of a config file.  I think we should map the keyer parameters to the MIDI NRPN (Non-Registered Parameter Numbers) message which gives us a 2^14 slot parameter space to work in and no existing assignments to work around.

Ah, the version of Ctrlr from five years ago appears to work fine.  I'll need to reprogram the Teensy to try it out.

48000 works?  Nice.  The sample rate feedback as I recall from sdr-widget was particularly wonky to get right.  You're sort of hunting for the right number of packets per second, and the host is telling you how far off you are, and the sample clocks on the host and the device are all the time wobbling around out from under your solution.  USB-2 should be fine, we ran 192ksps, stereo, in/out, 32bps on the sdr-widget and it only got a little warm.

I'm thinking we can do the head set interface with a DPDT (mechanical switch, mosfet, solder bridge, or jumpers) to switch between LRGM and LRMG, user selectable, then a Teensy analog input can read the switch state off the microphone bias line.  Oh, maybe 2p3t to handle an onboard microphone.  I also see that the Audio library has a PDM input that could handle a MEMS microphone.

[Roger Critchlow]

As to what to do with the hacked core files for 48khz:  put a fork with the changes on github, open a thread at forum.pjrc.com in the Audio Projects, and see if you can get some of the long time users interested.  If they vet the changes and start lobbying for them, then Paul is much more likely to consider a merge.  He's been pretty clear on where he plans to spend his time, and rewriting the USB Audio stack is not on the list.  But if there were a simple way at compile time to reliably change everything from 44100 and 48000, and all of his senior audio users agreed that it worked, then he might go for it.  

As I recall, 4 channels 16 bits 48000 is the limit for UAC1.  Anything with more channels, wider samples, or higher sample rate has to use UAC2.  So the stack can remain as it is and implement 48000/44100 and lower sample rates or narrower sample widths.  But any bump up entails rewriting the stack into UAC2, which in turn makes for an explosion in the possible device configurations.

-- 73 -- rec -- ad5dz --

On Thu, Feb 18, 2021 at 12:34 AM Steve Haynal <softerh...@gmail.com> wrote:

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

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/edf17920-249f-4363-bc24-f715f4629ffdn%40googlegroups.com.

[Roger Critchlow]

On Thu, Feb 18, 2021 at 11:19 AM Roger Critchlow <r...@elf.org> wrote:

I'm thinking we can do the head set interface with a DPDT (mechanical switch, mosfet, solder bridge, or jumpers) to switch between LRGM and LRMG, user selectable, then a Teensy analog input can read the switch state off the microphone bias line.  Oh, maybe 2p3t to handle an onboard microphone.  I also see that the Audio library has a PDM input that could handle a MEMS microphone.

Or just swap the Ring2 and Shield wires in the dupont header for the headset jack.  

[Steve Haynal]

Hi RDP,

Thanks for the nice updated and comprehensive summary. I will copy this over to the github pages the next time I work on those.

There are several i2s devices supported by the Teensy. Maybe we will end up going with one without the DSP which costs a little less.

73,

Steve

[Steve Haynal]

Hi Roger,

I did some more experimentation with various rates tonight. At 44.1kHz, I don't hear any crackles but the there are buffer overflows. If I run at the Teensy clock at 47996 Hz (The Teensy 4.x has a very nice Audio PLL, different and incompatible with the Teensy 3.x) it is pretty much perfect for my system. So it is about getting the feedback correct and clocks better synchronized. 

One thing I like about the Teensy code is that since he is only supporting 16-bit 44.1kHz, it is easier to read and understand the code as it is not cluttered up with DEFINEs. So I am reluctant to add DEFINEs for 48kHz. Also, my goal is to operate the audio subsystem at 32 samples per graph processing, or 0.67ms latency. This requires some changes to the USB side as it must still run with larger buffers. All this may be a bit more than people want to see in the main branch. I will fork core and Audio to share my changes soon.

73,

Steve

kf7o

[Roger David Powers]

Hi, Steve.

Yes, please feel free to use the summary any way you decide.  I'm glad it is of use.  

Thank you for doing the technical "heavy lifting" and thank you for taking the time to explain the project in great detail.

Thanks,

RDP

[James Ahlstrom]

Hello Steve,

I don't see how a 44.1 ksps rate is compatible with the 48 ksps output of SDR software if we mix sidetone with audio output.

Jim

N2ADR

["Christoph v. Wüllen"]

As far as I understand it, Steve is now working on having the Teensy audio run at 48 kHz,
and the idea is to embed the key-down/up events in the "microphone audio“ data stream.

This targets the possible problem that MIDI timing is not accurate enough. While I do not
think so, it is an interesting route to follow.

I think the intention at the moment is that the mic samples are the RF pulse envelope
(that is, a value between 0 and 1). This can be directly taken as the Q samples for the
radio (I is zero constantly).

This can (easily) be implemented in SDR programs (I can do this for piHPSDR if there is demand), but
the result will be catastrophic if some other audio input than the Teensy card is selected.

To avoid this, the mic samples could entirely consist of two magic words, one for „key up“ and
one for „key down“. The SDR software could then interpret a sequence of three subsequent "key up“
words as a key-up event and a sequence of three subsequent „key down“ magic words as a key-down
event. This makes misinterpretation unlikely, and one still has defined pulse widths to a single
sample.

HOWEVER: everything hinges upon the assumption that the samples generated in the Teensy somehow
arrive un-modified in the target program. In MacOS for example, all sound data is converted to
32-bit floating point and handled as such in the operating system audio layer, and is then
converted to the format requested by the application. So „magic words“ won’t work (pulse
envelopes should still be reasonable).

The changes in the SDR programs are marginal. Instead of computing a batch of IQ samples from
a batch of microphone samples the standard way, one does it „the pedestrian“ way, e.g. setting
I=0 and Q=mic sample. For protocol2, one has to make and 1:4 expansion (one mic sample produces
4 Q samples) but it is not more complicated.

But to prepeare this, one should first investigate what changes the samples may undergo all
on the way from the Teensy sketch to the target program.

Just my $0.02, Christoph DL1YCF.

[Franz]

Hi Steve. 

I will be receiving my HL2 in a few days time and have been reading this group.

I was curious as to ehich unused features the HL2 has?

Thanks,

Franz

[Steve Haynal]

Hi Jim,

Maybe I am missing what is behind your question, but all OS which support standard USB audio devices have to support rate matching. The OS will convert the 48kHz sound from the SDR to 44.1kHZ for the USB gadget if that is what is supported. The 48kHz from the HL2 doesn't quite match the 48kHz of the computer's audio clock which also doesn't quite match the 44.1kHz or 48kHz clock of the USB gadget, so there are several places where resampling must occur. All though not ideal, so far I haven't noticed any significant penalties for this even on a Raspberry Pi.

73,

Steve

kf7o

[Steve Haynal]

Hi Christoph and Group,

Just to be clear, I want to experiment with shaped IQ from the Teensy, not make it the default. I imagine there can be a pulldown selection in CTRLR or software and a user can choose how CW is transferred:

A. MIDI (This will be the default and people should be able to select which note to use etc.)

B. Serial (RTS and CTS lines are used by some software for CW input. It would be nice to support this if possible, but may conflict with other uses of the serial ports.)

C. Shaped IQ (This is experimental where the Teensy shapes the IQ and sends it directly to software to pass to the HL2. This has advantages of the more accurate sample-level audio timing vs. MIDI or Serial, simple software changes, one place to configure IQ shaping, IQ shaping still done by software in the Teensy so extremely configurable, eliminate any CW shaping on the HL2 so that it is a pure IQ device.)

D. Direct cable connection from Teensy to HL2 when operating locally.

I don't see the accidental sound card input as a big issue. Software must still decide which audio input to pass to the HL2 as CW. Quisk already supports at least 3 different audio inputs. This would define yet a fourth, CW audio input, and then Quisk would only pass through when in CW mode.

I have also wondered how much "modification" of the envelope will occur due to the sound processing along the path. This is definitely something which will need investigation.

73,

Steve

kf7o

[Steve Haynal]

Hi Franz,

There are mainly a lot of optional connectors or multiuse footprints which haven't been experimented with. For example, there is a small prototyping area in one corner. Also, the PA LDMOS device footprints are multiuse and support a larger device with heatsinking to the side of the enclosure. Blocks like the preamp, input LPF and PA can all be bypassed with daughter boards. There is some information on the schematic and in the early build notes:

https://github.com/softerhardware/Hermes-Lite2/wiki/Build-Notes-2.0beta2

73,

Steve

kf7o

[James Ahlstrom]

Hello Steve,

First, I do not want to add 44.1 ksps to my list of audio rates. I didn't know that USB devices are required to convert rates, but after decades of dealing with sound cards I do not trust them to do so. As far as clock differences, that is always a problem, as the clock from the SDR and the clock on the Teensy will not match. Quisk has code to remove or add a sample to keep the rates equal.

Rate conversion in the USB system may introduce latency unless the OS can do this in real time. I don't know where the conversion occurs; the OS, the sound card drivers or the sound card hardware.

Have you tested on Windows? Windows has a "Feature" that allows shared access to sound devices. This means that several programs can access the same sound device at different sample rates, and Windows will convert the rates and mix the samples. It also enables sound processing. When Quisk uses "Fast sound" it tries to open the sound device in Exclusive mode to defeat this. I think that opening the Teensy on Windows will currently fail because Exclusive mode will defeat the rate conversion.

The question in my mind is why we want to use a rate other than 48 ksps.

Jim

N2ADR

[Steve Haynal]

Hi Jim and Group,

Quisk under Linux is working fine with USB audio at 44.1kHz, so nothing is required to change with Quisk. I've done limited testing on Windows, but the Teensy USB Audio has had wider use on Windows and Mac so there is some confidence all should work.

I actually want to run at 48kHz instead of 44.1kHz and am cleaning up some code which allows this. Currently the USB audio runs in asynchronous mode, which is the most common, even among high end USB audio devices. The Teensy 4.0 has a nice Audio PLL so it should be possible to run in synchronous and adaptive modes if needed. See this article for a nice overview of USB audio modes:

https://www.edn.com/fundamentals-of-usb-audio/

I don't think latency to the USB device matters much. This latency will be in the 10ms to 20ms and is very similar to the TX buffer latency when sending audio back to the HL2 over ethernet. The latency from key down to sidetone in the ear matters the most.

Unfortunately I suffered a computer hard drive malfunction which took all my free time this weekend to fix, so not much progress to report.

73,

Steve

kf7o

["Christoph v. Wüllen"]

Hi folks,

I just learned that the Teensy audio runs at 44117.6 khz sample
rate because it is derived from a 96 MHz time base.

This means each second the input (if running at exactly 44.1)
lags behind another 18 samples, this makes one audio buffer (128 samples)
every 7 seconds.

Cum grano salis, this is the rate of „cracks“ that I hear in the
ear-phone, which most likely comes from audio input underflow
or overrun (it goes away if input volume is zero).

Is this possible? And then the good news is that 48k can be
obtained exactly from a 96 MHz time base.

Yours Christoph DL1YCF.

[James Ahlstrom]

Hello Steve and Group,

Thank you for working on this. I am ready to change Quisk should any changes be needed to help this project. I didn't know that the Teensy audio was limited to 44.1 ksps and that it would be a major problem to go to 48.

Jim

N2ADR

[Roger Critchlow]

Well, it depends.

In arduino/hardware/teensy/avr/cores/teensy4/AudioStream.h you'll find:

#define AUDIO_SAMPLE_RATE_EXACT 44100.0f

But in arduino/hardware/teensy/avr/cores/teensy3/AudioStream.h you'll find:

#define AUDIO_SAMPLE_RATE_EXACT 44117.64706 // 48 MHz / 1088, or 96 MHz * 2 / 17 / 256

I heard cracking on one of the hardware/software setups, but none on the Teensy4 running TeensyWinkeyEmulator just now.

-- 73 -- rec -- ad5dz --

On Mon, Feb 22, 2021 at 3:46 AM "Christoph v. Wüllen" <DL1...@darc.de> wrote:
>
>
> Hi folks,
>
> I just learned that the Teensy audio runs at 44117.6 khz sample
> rate because it is derived from a 96 MHz time base.
>

> This means each second the input (if rIunning at exactly 44.1)

> lags behind another 18 samples, this makes one audio buffer (128 samples)
> every 7 seconds.
>
> Cum grano salis, this is the rate of „cracks“ that I hear in the
> ear-phone, which most likely comes from audio input underflow
> or overrun (it goes away if input volume is zero).
>
> Is this possible? And then the good news is that 48k can be
> obtained exactly from a 96 MHz time base.
>
> Yours Christoph DL1YCF.
>

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

> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/BF2AEA68-7BD5-4337-9A56-EA5711FB0F42%40darc.de.

[Steve Haynal]

Hi Christoph,

This is true for the Teensy 3.X and is still within the limits of acceptable rates.

The microcontroller on the Teensy 4.X has an advanced audio PLL which sets the clock. Search for "set_audioClock" in output_i2s.cpp and output_mqs.cpp. The reference to the audioClock is a 24MHz crystal. The 3 arguments to set_audioClock are a fractional multiplier, c0 + (c1/c2). Below is some Python code I've been using to experiment with this clock setting. When AUDIO_SAMPLE_RATE_EXACT is set to 44.1kHz, I calculate the PLL is generating 44.0999kHz. For 48kHz, the PLL can generate exactly 48kHz. Of course the crystal won't be precisely 24MHz. 

For my experiments, I've been forcing the PLL to run slightly slower or faster to cover the variation expected in user systems. You can try the same and see if your crackles dissappear.

As I have mentioned in other threads, I am cleaning up some changes which allow the Teensy to use 48kHz and small audio buffer sizes of 32. I do not hear crackles. I will check this code in soon.

73,

Steve

kf7o

s = 44100.0

## PLL between 27*24 = 648MHz und 54*24=1296MHz

n1 = 4 ##//SAI prescaler 4 => (n1*n2) = multiple of 4

n2 = int(1 + (24000000 * 50) / (fs * 256 * n1))

C = (fs * 256 * n1 * n2) / 24000000

c0 = int(C)

c2 = 10000

c1 = int(C * c2 - (c0 * c2))

m = c0 + (c1/c2)

d = n2 * 4

print(24000*m/d/256)

[Luca]

Hi Steve,

the latency of a cw key connected directly at HL2 is higher or lower than using Teensy 4.0 USB  MIDI connected with PiHPSDR ?

73

Luca IK2LRN 

Milano

On Sun, Jan 31, 2021 at 11:01 PM Steve Haynal <softerh...@gmail.com> wrote:

Hi Group,

For some time now I've been looking for a CW keyer with low latency sidetone Hermes-Lite 2 solution which meets these criteria:

• Supports both local and remote use of the HL2, where the HL2 can be in another room yet still be operated by a CW key.
• Conserves limited FPGA logic and memory resources for specialized high-speed digital signal processing, and not usage on low-speed audio buffering and control which can be done easily by cheaper technologies.
• Preserves the current application of HL2 IO pins for ATU control, HR50 interfacing, fan control, and synchronous radio linking.
• Is easy to setup and use, requiring no advanced software/audio card configuration or changes.
• Requires no desoldering of components on the HL2 board and potential limited warranty voiding.
• Costs under $40 for a complete, prebuilt solution.

Last weekend I had an idea which I think can meet all these criteria. I have started serious experiments towards realizing this solution. The core idea is to combine a CW keyer with a USB soundcard as shown below. There is a low latency path from CW-keypress to audio out through the custom USB soundcard. This is the latency which matters to some operators but not others. CW-keypress-to-ear latency on this path can be identical to what is seen on Apache Labs and openhpsdr radios. Since the PC is sending audio to the adapter, the CW sidetone can be mixed in or interrupt audio as currently done on openhpsdr radios. Note that there is no real difference in audio latency here, as in openhpsdr solutions the data must be passed from radio to computer for demodulation and then as audio data back to radio again. Here we are passing raw data from radio to computer and then audio to USB adapter with similar latencies. There is no magic possible by having an audio jack on the radio, as processing still must be done by the computer.

There is one other latency to note, and that is CW-keypress-to-RF latency. In this solution it will be slighly more, I suspect in the 50-70ms range, as CW-keypress must be passed to computer and then HL2. But I don't think this matters in practice. If you consider the speed of light, operators already see a ~130ms there and back latency when working someone half way around the globe.

Some may think that implementation of this idea will be a lot of work, but fortunately, there are several projects which make implementing a custom but universal (no custom driver) USB sound card easy. My first experiments are with the $20 Teensy 4.0 and $15 audio adapter. What is most attractive about the Teensy 4.0 is the well developed Teensy Audio Library.  This even has a drag-and-drop GUI design tool to create audio applications with USB audio, midi and serial endpoints plus final i2s interface. 

All that remains are CW keyer connections (very inexpensive prototype board to unused Teensy pins for now) and CW keyer code. For the CW keyer code, I'll probably first use N1GP's iambic keyer as it is simple yet covers all expected openhpsdr functionality. Finally, although there will some optional MIDI control, I think this can all be done with few if any host software changes. Instead of key down/up messages, the custom USB adapter can send shaped IQ CW data which is then just sent directly to the HL2 without software processing.

Even now one can kludge together 3 boards (Teensy, audio adapter, keyer connector board) like I am doing for under $50. But if this idea takes off, I'd like to make it easier for people. One option would be to create a combined audio adapter and keyer connector board and sell it on Makerfabs. i2s codecs cost under $5.0 and connectors are cheap. This would sell for under $20 as another addon for the HL2. Yet another option would be to replace the Teensy with the new $4 Raspberry Pi Pico. There is already an audio board for the Raspberry Pi Pico so we know its special IO FSMs can be used for i2s. Also, the teensy audio library has been ported to other platforms, and given Raspberry Pi's history, Raspberry Pi will also have well supported libraries of their own. A final option, although the most work, would be to make a single custom board, maybe with a SAMD21 or 51 part, or even a module. All of these lower cost MCUs support native FS 12Mb/s USB. The Teensy supports native HS 480Mb/s USB which could be an advantage.

I am looking for help with this project. I'm committed to trying at least the 3-board kludge, but there is much more which could be done. For example, maybe one would like to add a big MIDI-based tuning knob for tactile feel, create an enclosure, help with the coding, help with testing, port to a Pi pico, port the k3ng cw keyer code, etc. Please let me know if you have interest.

73,

Steve

kf7o

 

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

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/30c72b12-fa5c-4737-a2a3-0391e0bc4efen%40googlegroups.com.

[DL1YCF]

We are mostly talking about the key-to-ear latency (side-tone), not the key-to-air latency (RF).
I think nothing can beat key-to-ear when the key is connected directly to the HL2, simply because
otherwise the key-down information must come through the IP data stream PC->HL2.

Concerning key-to-ear when the key is connected to the HL2, the Teensy should have lower latency
simply because the side tone info „somehow“ must go through the IP data stream
HL2->PC when the key is connected to HL2.

[ron.ni...@gmail.com]

And interesting option that would minimize both key-to-ear and key-to-RF when operating locally might be to add an optional output jack from the Teensy keyer to the front panel key jack on the HL2.

73,

Ron

n6ywu

[Robert Benedict]

"add an optional output jack from the Teensy keyer to the front panel key jack on the HL2."

like a traditional keyer

  73

    Bob  KD8CGH

--
You received this message because you are subscribed to a topic in the Google Groups "Hermes-Lite" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/hermes-lite/P-i_EYCN--k/unsubscribe.
To unsubscribe from this group and all its topics, send an email to hermes-lite...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/b6837a98-8de7-4fdc-9977-5855ac4d948an%40googlegroups.com.

--

[ron.ni...@gmail.com]

Except with the CW sidetone mixed in with SDR receive headset audio, whether using the HL2 local or remote.

[Steve Haynal]

Hi Luca and Group,

Let us consider three latencies:

CWKey->Ear  (time from pressing a CW key to hearing a sidetone)

CWKey->RFAnt (time from pressing a CW key to transmit RF signal on the antenna connector)

RFAnt->Ear (time from receive RF arriving at the antenna connector to demodulated signal audio reaching your ear)

For the openhpsdr solution with local CW and audio at the radio:

CWKey->Ear is on the order of 3ms to 5ms as the path is CW Key -> FPGA -> i2s device -> ear. There is buffering and shaping which happen in the FPGA and i2s device and account for the latency.

CWKey->RFAnt is less than 1ms as the path is CW Key -> FPGA -> High Speed DAC -> Antenna.

RFAnt->Ear is probably 50ms or more as path is Antenna -> ADC -> FPGA -> Ethernet -> Software -> Ethernet -> FPGA -> i2s -> Ear. It is a common misconception that the openhpsdr solution provides low latency audio as the audio jack is on the radio. This is not true as audio must be sent back to the PC for processing and then back to the radio.

For the teensykeyer solution under development:

CWKey->Ear is on the order of 3ms to 5ms as the pasth is CW Key -> Microcontroller -> i2s device -> ear. The goal is similar or better latency than seen with openhpsdr. I am optimizing the microcontroller code. It is hard for a human to notice latencies less than 5ms.

CWKey->RFAnt via MIDI is probably 50 ms or more as path is CW Key-> Microcontroller -> USB -> Software -> Ethernet -> FPGA -> DAC -> antenna. I don't think this latency matters, even for pseudoQSK. From a user's perspective, everything will just be shifted by 50ms, even when doing psuedoQSK. The latency of RF going around the world is about ~133ms. A difference of 50ms is the same as a QSO 1000km away versus just less than half way around the world. Do people notice that?

CWKey->RFAnt via direct connection is less than 2ms as path is CW Key -> Microcontroller -> FPGA -> High Speed DAC -> Antenna. A week or two ago the idea was floated to have an output on the teensykeyer for direct connection to the HL2 when operated nearby. This is simple enough to have. It is mainly to appease those who don't follow or buy the argument that 50ms won't matter when it goes to the antenna.

RFAnt->Ear is probably 50ms or more as path is Antenna -> ADC -> FPGA -> USB -> Microcontroller -> i2s -> Ear. This is similar to the openhpsdr solution. The USB audio has similar latency of 10-25ms as the TX buffer in the HL2.

73,

Steve

kf7o

[Alan Hopper]

Hi Steve,

I measured midi to rf at <18ms here https://groups.google.com/g/hermes-lite/c/Cq7dyiBru6U/m/sjuDlE12BAAJ  the firmware has changed since then but I think 50ms is pessimistic.

73 M0NNB

[Steve Haynal]

Hi Alan,

Thanks for the reminder. 18ms sounds great.

73,

Steve

kf7o

[Roger Critchlow]

I've uploaded a new version of my proposed low-latency keyer to https://github.com/recri/hasak.  There are a few things still to do, but I've resisted fixing anything long enough to verify that this version will boot up on a Teensy 4 + Audio Adapter, or on a plain Teensy 4, or on a Teensy 3 + Audio Adapter.

It boots up as a keyer, so the paddle inputs and straight key input will key sidetone at power up, mixed with the RX audio coming from the usb interface.  If you enable TX on the Ctrlr panel, the CMOS key_out and ptt_out will become active.  If you enable IQ while TX is enabled, keyed IQ will be sent to the usb interface.  If you enable send midi while TX is enabled, midi note on/off for key_out and ptt_out will be sent to the usb interface.

This is a low latency keyer.  The input pins connected to paddles and keys are read and the output pins are written at the audio library sample rate (48k with Steve's mods, 44.1 otherwise).  All keying logic, tone generation, key envelope shaping happens inside the audio library update functions.  In most cases a key down on input will appear as a key_out down on output during the same buffer processing cycle.  (The exception would be when a PTT delay is specified with ptt_head, but ptt_head is broken.)  

On the Teensy 4, the keyer is consuming about 3-4% of the cpu cycles in the audio library, it occupies 3% of the program space, and is using 16% of the dynamic memory.   Adding additional paddles or keys is straight forward, the keyer has a priority structure for determining which lines pre-empt which others.

Note that you can twiddle knobs on the Ctrlr panel and change keyer parameters while the keyer is keying.   This should work for everything, but note that some knobs will mean nothing to the current voice, the speed control doesn't do anything when you hold a straight key down.  And there is a rudimentary serial monitor which will allow you to send text and view resource usage.

The things that are not working are listed in the doc/ToDo.org list, most prominent the ptt_head time for delaying keying so the ptt can warm up the TX, no winkey support, no command mode, and so on.

Please contact me with any issues, or file them on the github project.

73,

[Steve Haynal]

Hi Roger,

Thanks for the update. I hope to try it this weekend. I've become more involved with the USB audio than I intended or maybe need, but it is interesting. I hope to finalize my changes for this soon. 

It is great to see that there are some instructions on how to build a keyer. I'd like to add instructions too. I think there are three keyer implementations now: the k3ng in my fork, dl1ycf's keyer and yours.

After these get a bit of exposure, we should start discussing what we want on a Teensy cape.

73,

Steve

kf7o

[Joe LB1HI]

Hi,

To keep the idea of remote operation, and with this good advantage, the HL2 clearly distinguishes itself from other small transceivers,

it would be good to have at least one solution for CW paddle keying working properly remote.

Paddle at PC with controlling software. HL2 Somewhere on the LAN or even remote via Internet.

73, Joe

["Christoph v. Wüllen"]

This is what we are doing. The keyer sends key-up/down messages via MIDI (USB)
to the SDR software running on the computer, at the same time it gets RX audio
from the computer (USB) in digital form, does the DAC and sends it to the
headphone. In addition, it inserts the side tone into this audio stream,
that is what gives the low latency. This is working since some time (and I
use it every day). At the moment we are somewhat distracted from this
(improving the Teensy USB audio input in general). This in principle has
no relation to the keyer project but has achieved to improve the Teensy
audio such that there are no "audio cracks“ every now and then.

73, DL1YCF Chris.

> --
> 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.
> To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/d2cd6f0f-966c-42fc-835d-cfd8a8bca175n%40googlegroups.com.

[Roger Critchlow]

Yeah, I've been a little more obsessed with this than I planned, too.

On the USB, I've been running the 48k SOF version exclusively since a day or two after I installed in on 7-March.  I've been using the Teensy as my primary audio card, and even used it for a family Zoom call on Sunday, mic check was that I sounded a little fuzzy.

I restart my laptop as a last resort when I run out of ideas for why something isn't working, the first step in establishing a known start state.  A few times over the last week, the restart has gotten hung up part way through, while still displaying the Lenovo boot splash, which suggests I type Enter to interrupt the startup, with an LED lit on the Escape key.  Typing Enter doesn't do anything, but usually a full power cycle would bring the machine back up.  Last night it got hung up, at the same point, after a full power cycle, twice.  My Teensy is plugged into a USB hub that also delivers power to the laptop through a short Type-C cable, so the Teensy is powered even when the laptop is off.  Anyway, when the laptop got stuck on power up the second time, I unplugged the Teensy, and the laptop immediately completed its power up.   So, there's possibly a back-off in the Teensy code when it fails to establish a USB connection which needs to back a little further off.  I can do some more experiments, I suspect the stock Teensy USB drivers will have the same problem.  Googling suggests it is often a Lenovo BIOS problem.

By the way, the keyer continues to run fine even without its USB host connected.  It needs the power, but it doesn't need a peer that produces or consumes samples. 

-- 73 -- rec -- ad5dz --

--

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.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/6abac180-de8f-49a1-a3e4-995eac656426n%40googlegroups.com.

["Christoph v. Wüllen"]

>
> By the way, the keyer continues to run fine even without its USB host connected. It needs the power, but it doesn't need a peer that produces or consumes samples.
>

This is also the case for Steve’s usb-audio-midi module.

Running my Teensy off an USB power plug (providing only 5V to the USB jack) I can
use it as a Morse trainer, and even more, use it as a „real keyer“ because
I connect

key-down digital out pin —> OptoCoupler —> RCA jack

However, as a "standalone keyer“ the Teensy has a drawback compared to
my (K1EL) WinKeyer because it draws more current. Running
it from a battery probably costs a fortune in batteries.

Three AAA batteries in the WinKeyer last several years, and there is
no on/off switch. The power consumption of the Winkeyer is mostly
determined by whether and how often you use the built-in side tone
(at least this is what I beleive: the

Vcc —> R100 —> 2N2222 —> speaker —> GND

line by far draws the largest current, if the 2N2222 switches.

So at least in my view, the Teensy will always be connected to a
computer. But there are scenarios where I need the side tone
from the Teensy without using it as a sound card.


Yours,

Christoph

[Steve Haynal]

Hi Roger,

Are you running Windows, Linux or Mac? I recently discovered that that Windows is picky about some feedback formatting and feedback wasn't working properly with Windows. There is new code on my github which fixes this and might help with your issue. I've always plugged my Teensy in after the system is up, or usually into a system that is always up. I will have to try your scenario. Finally, the new code on github uses Audio sample buffers of length 32, which reduces the audio graph latency to 667us. With some improvements by Christoph, I've now run the SOF-based feedback method for hours without a single under/over run on both Linux and Windows.

73,

Steve

kf7o

[Roger Critchlow]

Steve --

I'm always running Linux. I was running Coherent, a precursor of Linux, on IBM PC's before the MacIntosh or Windows existed.

I pulled your new sources, rebuilt with my latest changes, and restarted.  The Lenovo sat with the Escape key lit for a second and then finished the restart.  I'll keep an eye on it going forward, but it passed once.

I've been compiling with ' Tools > CPU Speed: "150MHz" ' which reduces current consumption to 50mA from 100mA.  No issues with the keyer,  yet.

I should be pushing a new source sometime later today, need to add a new knob to the Ctrlr panel.

(Forwarding this to the list having accidentally replied just to Steve.)  

Also, it seems that your fixes may have fixed another problem I was having with sending MIDI note on/off interfering with the usb audio in.  Does that make sense?

-- 73 -- rec -- ad5dz --

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/f62301fb-b539-48bf-a37b-639647e421ebn%40googlegroups.com.

[Steve Haynal]

Hi Roger and Group,

I did get a chance to try hasak this weekend and was quite impressed. See the screenshot below of the ctrlr GUI for hasak which shows all the flexibility.

Can you remind me again why a jumper is needed between pin 20 and 22? If this is to have a regular external interrupt, why isn't the low priority Audio class update interrupt which is called every Audio buffer length samples adequate? When running with buffer lengths of 32 samples, this is an interval of 667us.

Thanks for testing the 150MHz option. I have been meaning to do that and it is nice to hear that it works and saves power.

Does hasak support winkeyer or the n1mm logger?

I think this project is ready for those interested group members who like to solder and tinker a little bit and are comfortable with programming an Arduino. We probably need a little more documentation, but hasak already has some to begin with. I think there are actually 3 keyers now:

AD5DZ's hasak

DL1YCF's TeensyWinkeyEmulator

Forks of the K3NG keyer KF7O DL1YCF

All of these use updated Teensy USB audio code for 48kHz, fewer over/underruns, and lower latency.

Teensy core library

Teensy audio library

These keyers can be built with the Teensy 4.0 and audio shield.

To reiterate, the goal of this project is to provide low latency CW sidetone mixed with RX data from the HL2 for either local or remote operation.

73,

Steve

kf7o

[Roger Critchlow]

On Mon, Mar 22, 2021 at 12:43 AM Steve Haynal <softerh...@gmail.com> wrote:

Hi Roger and Group,

[...]

Can you remind me again why a jumper is needed between pin 20 and 22? If this is to have a regular external interrupt, why isn't the low priority Audio class update interrupt which is called every Audio buffer length samples adequate? When running with buffer lengths of 32 samples, this is an interval of 667us.

I take an interrupt at sample rate to poll the input switch pins and to latch the output pins, so I can detect and effect pin changes at sample rate, because I do all the logic and synthesis steps at sample rate.

Yes, you could use the AudioStrean::update to poll and latch pins.  Then you would be detecting and effecting pin changes somewhere around sample rate/block size, because update() gets called within a window, not at a fixed time.   And you could do that and still do everything else at full sample rate.  But the key_out pin would be updating at the lower rate, and if the dit clock was not integral at the lower rate you could transmit a string of dits or dahs with beating between shorter and longer pulses.  You wouldn't hear it in your sidetone, but everyone listening to your signal would hear it.

My experience is that you cannot tell the difference in these kinds of timings at the level of the event, but you can hear the all the corners you cut when they're repeated and you vary the repetition speed.  I fully expect someone to tell me that they can hear the difference between my interpolated blackman-harris ramp and a sample accurate blackman-harris ramp, that they can hear the corners in the linear interpolation. They'll record an A/B test at 150wpm and I'll be able to hear the difference, too.

I use the jumper between pin 20 and 22 because I was using the LRCLK RISING interrupt on the Teensy 3, but it didn't work on the Teensy 4, so I jumpered LRCLK to 22, set 22 as an input pin, and took the 22 RISING interrupt.  It could be that there's a way to do the pin interrupt without the jumper, it could just as well be a timer interrupt, or it might be done with DMA programming, but I haven't looked into it.  I mean to add cpu_cycle counting to the interrupt service routine, but it hasn't seemed urgent.

I'm now suspecting that some incidental changes I made to the sample rate interrupt service routine fixed the MIDI/Audio interference issue I was seeing, as my other candidates for the fix haven't panned out and I'm not ready to admit I hallucinated the problem.  So I will be instrumenting the interrupt and looking at further improvements.  I think there're fast digitalRead() and digitalWrite() I could be using.

[...] 

 

Does hasak support winkeyer or the n1mm logger?

Not at present.  I am thinking that I may adapt Christoph's winkey state machine, if he finds that agreeable.  From comments I've seen here and there, I believe that N1MM is winkey compatible if the winkey emulation covers a few details with care.  

[Roger Critchlow]

Okay, I instrumented the sample rate interrupt routine.  

The Teensy has a free running cpu cycle counter register, ARM_DWT_CYCCNT, which makes it easy to count elapsed cpu cycles in a segment of code.  So I am accumulating the time spent in the interrupt routine into a global variable.  The Teensy Audio library also counts the cycles consumed in each library module and for the update loop as a whole on a per sample buffer basis.  I'm counting in loop() the total cpu cycles per sample buffer, the total interrupt cycles per sample buffer, and converting all of this to percentage of total cpu cycles per sample buffer.

  

The sample rate interrupt, as it was this morning, was using 1.5% of the cycles per sample buffer time.  That's the sum of 32 interrupts.

Changing to digitalReadFast() and digitalWriteFast() brought that down to 0.7%.   This is running a 600MHz clock.

I might be able to improve on that, too.

The audio library update() loop is running about 3.5% of the cycles per sample buffer.

Hasak has a simple serial monitor that can show you these numbers after I push the changes.  Type ?\n for a usage prompt.

Another thought about timing precision.  People spend a lot of time learning to squeeze initial A vs initial N, I wonder how close together they can get?  

-- 73 -- rec -- ad5dz --

[Roger Critchlow]

I've pushed a new version of hasak to https://github.com/recri/hasak last night, but I broke the vox priority preempt when I fixed the ptt delay.

A few notes about using ctrlr - #documentation

There are a lot of versions of ctrlr available for download at ctrlr.org, most of them don't work very well and I couldn't build from sources either.

I'm using the 5.3.201 version on Ubuntu Linux.

An important quirk on linux is that none of the file dialogs work by default.  You must open the Edit> Preferences and uncheck "Use OS native file open/save dialogs ..."

Once you start ctrlr you can use File> Open Panel to load the ctrlr panel from hasak/ctrlr/hasak.panel.

Once you load a panel into ctrlr, ctrlr bonds to that panel.  It will save the current state of the panel in its settings file and reload it when it is next started.  So you only need to load the panel once.

And if you do a File> Save, it will probably overwrite the hasak/ctrlr/hasak.panel.  Should do a File> Save As first.

As it stands, there is no automatic synchronization between the ctrlr panel and the hasak keyer.  

Programs> Send Snapshot will blast all the current settings to the keyer.

Programs> Program Snapshot copies the current settings into the Snapshot save area.

The Snapshot save area is available in the Panel> MIDI Library.  You can rename, delete, and copy Snapshots.

And a copied Snapshot can be pasted back into the panel to reset its values.

If the Teensy reboots, ctrlr loses its MIDI connection and can't get it back, but it claims to still be connected.  

If you do MIDI>Refresh devices, it will still claim to be connected, but it isn't.

Note that ctrlr remembers which panel it was running when you restart, just running ctrlr with no arguments will bring up the last panel.  

So you could actually run Ctrlr as a shell script with an infinite loop in a terminal:  

    while Ctrlr || true; do echo restart; done

and then kill the terminal when you're finished with it.

Manipulating Ctrlr knobs is easy with a mouse wheel, though the action of the wheel feels backwards to me.

Most knobs have a default value which is restored on double-click.

Normal interaction with knobs is to click-drag on the knob.  Drag up to increase the value, down to decrease the value.

The check buttons can be a little sticky.

More to come.

-- 73 -- rec -- ad5dz --

[Roger Critchlow]

I've been helping someone bring up hasak on a bare Teensy4 the past few days.

This lead to two discoveries:

First, hasak on a bare Teensy4 requires something in Steve's modified cores and/or Audio library.  With the standard Teensyduino install you get raspy, noisy audio.  With the modified install you get a nice clean tone.  I'm guessing it's the SOF code that's responsible, but I haven't gone into it in depth to verify.

Second, installing Steve's modified cores and Audio library is a pretty high bar for a Ham project.  I've made some mis-steps myself doing it, and I haven't gotten my first client successfully through the hoops yet.

-- rec --

[Steve Haynal]

Hi Roger,

Unfortunately there were problems with the Teensy4 USB audio high speed support. I don't think the stock usb_audio will work at high speed as is, and the Teensy4 defaults to high speed. I will generate a pull request for my changes.

We should also distribute the code as a .hex file. It is a lower bar for someone to install the Teensy loader and program an existing .hex file. The loader application can be run standalone and .hex file picked from the File menu.

https://www.pjrc.com/teensy/loader.html

73,

Steve

kf7o

[Jonathan Guthrie]

Through this whole conversation about low-latency CW sidetones, I've been kind of focused on getting my keyer project working.  It's intended to be a two-part thing with an arduino nano board doing the actual keying, reading the input from the key, and coincidentally generating the sidetone, and a Python program doing things like providing memory and configurability and things like that, with the idea that I would build a custom Raspberry Pi image and a touchscreen to make a standalone memory keyer with a GUI.  The dongle, as I've been calling it, is powered by the USB connection that also allows it to communicate with a computer, although there's a kind of a standalone mode so it can be used as a dumb keyer without the master.  Maybe some of the people here might find it of interest.  At the very least, it's a kind of a fork of the K3NG keyer because what inspired me to do it was the things I didn't like about Mr. Good's efforts.

Anyway, there's some info about it on my blog:  http://ka8kpn.org/node/65 with links to the hardware, the software, and the documentation (including the specification of the serial protocol used to control it, and not much else at the moment.)

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/dfd66ecc-bf13-43af-ae8f-f94dbd38ffaan%40googlegroups.com.

[Steve Haynal]

Hi Groups,

Thanks Jonathan for sharing your work!

Although it is still a work in progress but following the release early and often philosophy, I want to share the latest on the Teensy4 keyer with USB audio. I've started documenting the project here:

https://github.com/softerhardware/k3ng_cw_keyer

There are 3 keyer software packages which can run on the Teensy4 plus AudioShield hardware. All make use of the low latency Audio for sidetone. All firmware is in a usable state. The project is ready for those who are comfortable with a little bit of soldering or breadboarding plus some uploading of Arduino firmware. As you can see on the page, we are separating users from developers. User only need to download a precompiled .hex file and upload it to the Teensy4. There is no need to install custom libraries. All the development and changes are still open source, and developers are welcome to download, change and compile the source code.

We will continue fleshing out and deciding on what hardware features (knobs, enclosure, connections, etc.) the keyer should have using this prototype setup, but eventually I still want at least a Teensy 4.0 shield made by Makerfabs which encapsulates everything. Just plug the shield onto the Teensy 4.0 and you have a HL2 keyer!

I have been very impressed with the RT1062 crossover microcontroller used on the Teensy 4.0 and 4.1. See the end of this video for some performance metrics. It is truly in a different class with a M7 core and 400-600 MHz clock speeds. Yet there are family members like the RT1011 in easy to use 80 pin packages which cost ~$4.00. There is a lot of potential here.

73,

Steve

kf7o

[Robert Benedict]

Steve

   Thanks for the info. I think that you linked to features when you meant of pin.

       73

        Bob   KD8CGH

[Steve Haynal]

Hi Group,

There are 3 versions of software which can run on the Teensy keyer prototype:

https://github.com/softerhardware/k3ng_cw_keyer

Although the software is not final, it is usable by software developers and proves the concept. I am starting to think about the hardware and printed circuit board. I'd like to collect ideas on what the IO should look like. I am considering using 3.5mm jacks for headphones audio, paddle, straight key, PTT, and optional direct connection to the HL2. I am considering stacked jacks like you see on PC motherboards:

https://www.aliexpress.com/item/4000545373459.html

https://www.aliexpress.com/item/33025923006.html

What do people think?

For the audio codec, I am considering the TLV320AIC310X series or the WM8960. I'd like to stay with a 32 pin or less package, which both do. The Texas Instruments part has slightly better specs (not sure if it will matter) but requires an additional 1.8V supply and has no speaker amp. The Cirrus Logic part does not require an additional power supply and can also drive a small speaker. The Respeaker audio shield for the Raspberry Pi is built around the WM8960. Note that the respeaker board has two on board mics. For amateur radio use, I thought it would be nice to have one such onboard mic and then use the other input for a standard mono headset or external mic. Any comments?

73,

Steve

kf7o

[Steve Dick]

3.5 mm jacks are fine for all. For the straight key, I would stick with a stereo rather than mono jack. They are more standard and common with the other jacks. But you might want to get some opinions on this.
-Steve K1RF

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

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/2d5bd6a4-a43f-47ad-95b5-bbc249f2438bn%40googlegroups.com.

Virus-free. www.avast.com

[Brock Nanson]

I would agree that if you're using the 3.5mm jacks, it might be simpler to just go with three conductor for all of them.

If there was a way to include a USB connection for a USB headset as well, that would be pretty cool.  Those headsets are cheap and plentiful and would certainly expand the options for microphone and headphones.  Double duty - how many computers even provide 3.5mm connections now?

Brock

[DL1YCF]

> Am 08.05.2021 um 22:23 schrieb Steve Dick <sbd...@optonline.net>:
>
> 3.5 mm jacks are fine for all. For the straight key, I would stick with a stereo rather than mono jack. They are more standard and common with the other jacks. But you might want to get some opinions on this.
> -Steve K1RF
>

Exactly. I have built a keyer and use a stereo jack for the straight key, but I wire T and R together.

So a key with a mono *plug* works, and a key with a stereo plugs works no matter if T or R is
connected.

And, it is easier for me to have just one type of plugs and jacks in my junk-box.

Christoph DL1YCF.

[jpwa...@gmail.com]

Steve and Developers,

I like very much what I am seeing develop, it seems to be right on with the specific connectors, etc 

It was mentioned early on about supporting a tuning knob. Is that still on the list?

..jpw J P Watters

KC9KKO

Morris, IL USA

[Steve Haynal]

Hi Group,

Attached, please find a first version of the audio portion of the upcoming Teensy Keyer and Audio shield schematic. In particular, I'd like feedback on the microphone setup. There are several configurations possible:

1) Use head set with mic connected to J5 using TRRS plug. External PTT button can be wired to J6.

2) Use far field MEMS microphone MIC1 (similar to a phone or laptop mic). External PTT button can be wired to J6.

3) Use openhpsdr-compatible mic (Hermes/Angelia) on J6 and headphones on J5. The Hermes/Angelia boards provide jumpers so that the mic/PTT can be on the tip or ring. Do we need that flexibility?

73,

Steve

kf7o

[Steve Haynal]

Hi Christoph and Group,

Thanks for the feedback. I gather you would like to match the ANAN audio IO as much as possible which is probably and good and safe way to go.

What do people think of the TRRS feature? I know there are some TRRS headsets out there, but how often would they be used? Looking at most gaming headsets, there is a separate headphones and microphone jack. One can always use a splitter from TRRS to headphones/mic jack. It would simplify the component list to not have a TRRS jack. Everything could be TRS. 

Also, for PTT, I imagine if there is not one on a hand mic that someone wants to wire up, using enter or space on the keyboard should work. Do people see any problems with that?

73,

Steve

kf7o

[Duncan Clark]

Hi Steve,

Every headset I have is separate Mic and headphone jacks.

My PTT is a footswitch with a 3.5mm jack plug.

What about a header and people can wire what they want off that?

Duncan

In message <e14e7432-d9d4-4df2...@googlegroups.com>,
Steve Haynal writes

>--
>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.
>To view this discussion on the web visit

>https://groups.google.com/d/msgid/hermes-lite/e14e7432-d9d4-4df2-bee9-63ec51a06813n%40googlegroups.com
>.

--
Duncan Clark
G4ELJ

[Steve Haynal]

Hi Group,

Attached, please find updated schematics for the Teensy CW Shield. This includes a new sheet with the planned Teensy connections. It also updates the audio to remove the TRRS jack and make it closer to the Hermes/Angelia openhpsdr boards. These schematics include all features and functionality I was thinking about for this project. I will move on to PCB layout. Please provide feedback.

73,

Steve

kf7o