A Teensy Keyer prototype

[Robert Benedict]

I put together a Teensy keyer using long pin headers on the audio shield so that I could plug them into headers on a proto board. I was able to load Steve's "k3ng with USB audio"  hex file and when a key was closed the LED lite and I got the side tone in the headphone. I could also control the keyer by WinKey and Crtrl panel. I couldn't get it to key the HL2 or mix the side tone with HL2 audio.

I noticed in the source that direct keying wasn't enabled. I enabled and recompiled but couldn't load both libraries. After recompiling my version direct keying worked as expected along with WinKey emulation and the Crtrl control.

Questions:

  Is the keyer  designed to work with a particular software? I tried with SDR Console and Thetis but no joy.

  What are the program and Windows PC audio settings?

 

  73

     Bob  KD8CGH

he

[Steve Haynal]

Hi Bob,

You build looks very nice.

To mix sidetone and radio audio, you select the USB audio device as the output from software. For example, on SDR Console there is a pulldown under the frequency which allows you to select that output audio device. You will select either the Teensy or hasak device.

The software you use must accept CW keying via MIDI. I know that Quisk, SparkSDR and piHPSDR do. Take a look at the CW and Logging Setup document for linHPSDR:

https://github.com/softerhardware/Hermes-Lite2/wiki/Software#linhpsdr

The software and keyer have to agree on which MIDI channel and note to use for CW. You may have to change that in the source code for now.

I know SDR Conosle supports MIDI controllers, but I didn't see one in the options to enable. See Tools->Options->Controllers->MIDI. Maybe if you are in CW mode then TX on controls the key? If there is no support, it would be very easy for Simon to add.

When you rebuilt from source, did you use my forks of the Teensy core and Audio libraries? You must use those for reliable audio.

I suggest also trying the other two keyers. I don't think there are .hex files for those yet, but you can find more details at:

https://github.com/dl1ycf/TeensyWinkeyEmulator

https://github.com/recri/hasak

https://github.com/softerhardware/k3ng_cw_keyer

73,

Steve

kf7o

[Robert Benedict]

Steve

   Thanks for the reply. I reloaded your hex file

   I got the keying to work with Quisk with these settings:

     Timing and CW

       Midi note for CW key: 1

       Midi CW key device: Teensy MIDI/Audio

  And I can hear both signals and keyed side tone with

    Sound

       Audio output: Speaker / Headphone

  No luck with Thetis-HL2. There is a Config MIDI under CAT control. I set id 1 to Button, Cat Cmd to CWX key

CWX keys the HL2, but I can't get the Teensy to.

The audio library loaded without problem. I have been unable to load the core library. What's the trick?

  73

   Bob   KD8CGH

[Reid Campbell]

Hi Robert,

Thetis expect the note value to be 127. I think the keyer does 64 or 63. You will need to change that in the Teensy code.

Cheers

Reid
Gi8TME/Mi0BOT 

--
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/7b5bf069-0271-479b-87ad-17f82701d5c9n%40googlegroups.com.

[Robert Benedict]

Reid

The note is set to 1 in Steve's code, but I can't find where the value is set.

Unfortunately I can't load the "core" library in the IDE so I don't know if my recompile will function as intended.

I've also been trying to get it to work with SDR Console, which seems to have a different language for MIDI. It reports the "value" as 99 when my straight key is closed. Unfortunately, "Note On" doesn't turn the TX on.

  73

   Bob  KD8CGH

SDR Console:

in edit mode which tracks real time

[Steve Haynal]

Hi Bob,

I rebuilt the k3ng code to use 127 for the CW key note value. I also built and posted .hex files for Roger's hasak keyer and Christoph's TeenyWinkeyerEmulator.hex. I didn't extensively test the last two and am hoping Roger and Christoph will build and maintain the .hex file releases. You can find the links on the main keyer page:

https://github.com/softerhardware/k3ng_cw_keyer#programming-the-teensy-4

The 99 value in SDR Console sounds like an error. Does it work if you you set TX on to respond to note 99? Maybe Simon can respond. You may have better luck posting to the SDR Console group. This should be easy for SDR Console to support if it doesn't already.

73,

Steve

kf7o

[Robert Benedict]

Steve

Thanks for the new uploads.

 Unfortunately your new hex no longer keys Quisk.

I reloaded the old hex and it still works. In Quisk the Midi note for CW key is set to 1 and Midi CW key device set to Teensy/Audio. I tried setting the Midi note to different values and it keyed the HL2  for all of them. I didn't see a setting for value.

I retried the new hex with notes 1 and 127 and it never keyed the HL2.

With Thetis in the Midi Controller setup / Mapped controls tab, if I touch a key it recognizes it and says the control ID is 127 with values from 0 to 99. If I make the control type "button" I can assign it to CWX Key and save. Unfortunately it doesn't key the HL2.

If I go into Midi Control Setup / Diagnostics tab for Control # 7F it says Data is 0 or 63 for off and on when key is pressed. I'm guessing that this is in hex so the values are 127 and 99 as on the other tab.

I also tried the new hex with SDR Console. It reports the "Index" as 127 with values either 0 or 99.

Note, value, control ID, Index, ... every app seems to use different MIDI terms :(

   73

    Bob   KD8CGH

[Steve Haynal]

Hi Bob,

I remember another thread where Reid helped someone with MIDI CW keying. Did you find that? I will have fire up Windows and take a close look at PowerSDR/Thetis/SparkSDR MIDI.

Does the external (nonMIDI) keying directly to the HL2 work for you?

Have you tried hasak with the Ctrlr panel? Roger has a lot more configuration accessible via that interface.

73,

Steve

kf7o

[Reid Campbell]

Hi All,

It is the value of the note which is important for Thetis, not the note Id. It looks to me as it the note Id has been set to 127 but it's value is being set to 99. Thetis will take any note Id and allow it to be mapped to a command. That command will expect a value and for MIDI keying, the value is 127. All other values will unkey the Tx.

Cheers

Reid
Gi8TME/Mi0BOT

--
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/83e48a04-42a8-4960-a11b-a907a00d00d8n%40googlegroups.com.

[Robert Benedict]

Reid - thanks. It also looks to me like the note value is being set to 99 decimal.

Steve - see Reid's and my comment. I think that you set the note to 127, but the value is still 99. Unfortunately even when I set the note to 127 in Quisk it still didn't work.

No, direct keying doesn't work. Looking at your source it doesn't appear to be activated. You only flash the LED.

Perhaps note 1, value 127 might work for both Quisk and Thetis?

I tried to modify and recompile but my recompile didn't function. I don't know if I have a code error or it's because the IDE refused can't load the core "library". Too many unknowns. If someone could point me to a resource for loading  the core I could test more things myself.

  73

   Bob  KD8CGH

[Steve Haynal]

Hi Bob,

Okay, I moved the output back to note 1 but on value of 127. There are updated .hex files on the github site. I'm not sure where the original 99 came from. MIDI is a pretty straight forward (and old) protocol. There are several message types and then usually two values associated with the message, ranging from 0-127. For example, a note one message with the note and the velocity as data. See this good tutorial for details:

https://learn.sparkfun.com/tutorials/midi-tutorial/all

You are an early adopter so please expect some unfinished areas. I plan to add details about using the modified libraries on the main page but below are a few details I sent to developers. I think most people will just have to be able to program a .hex file.

 You can find the repos here:

https://github.com/softerhardware/cores

https://github.com/softerhardware/Audio

I usually create a symbolic link from where these would be installed in a standard Teensyduino setup to the path where I have the custom libraries.

73,

Steve

kf7o

[Robert Benedict]

Thanks Steve

  Got a chance to try the 4/19 hex out. Here's what I saw

keys HL2 with Quisk with very little lag

combines sidetone with received audio with Quisk audio output set to laptop speakers :), laptop audio out reset to "Digital Audio Interface (Teensy ... )

 Ctrlr panel is schizophrenic, on launch shows green bar on bottom with "Open OK  device Teensy ..." message

any panel control movement  yields [ERROR]  [19:55:34:000057] failed to open device 'Teensy..." message popup

WinKey emulation works with WinWarbler

keys HL2 with Thetis with very little lag

Midi settings:

ID- 1

control name-  keyer

control type- Button

min- 0  max- 127

Cat Cmd- CWX Key

no sidetone with VAC1 Output set to laptop speaker, with any other Output setting no received audio

makes a very brief squawk with lag at start of each CW transmission

if check sidetone and disable PTT produces usual sidetone with lag

  73

    Bob  KD8CGH

[Steve Haynal]

Hi Bob,

For the sidetone, you should only hear it at low latency when you plug headphones into the audio shield. The sidetone will not be generated for any other audio output. You may have to disable software sidetone in Quisk or Thetis. Is that the case for you? I am surprised when you say laptop speakers.

For Thetis, have you set your audio output devices to the Teensy and are you listening for audio on the audio shield headphones?

73,

Steve

kf7o

[Robert Benedict]

Steve

I didn't know that this was a headphones only approach.

Quisk

  Yes, in Quisk I hear both signal and sidetone through my headphone with Quisk Config: *HL2*:  Sound: Radio Sound  Output: "Digital Audio Interface (Teensy ... )". 

When I had set Quisk Radio Sound  Output: laptop speakers I must have been hearing the Quisk sidetone when keyed.

After listening for a few minutes I get a loud buzzing sound in the headphones that occasionally clears and occasionally gets very loud. It also clears after I transmit. After clearing it will return again.

order:

plug in keyer

Ctrlr  - Ctrl works as expected

Quisk, - Quisk says Could not open MIDI device, keyer doesn't key

plug in keyer

Quisk - functions as expected

Ctrlr  - says Open OK Teensy, on control movements says failed to open device, if click OK in popup starts working after a few tries, still fails intermittently

Thetis

sidetone not checked

Driver: MME

VAC1 output set to "Digital Audio Interface (Teensy ... )"

hear signal in laptop speaker and and sidetone  in headphones

Driver: Windows WDM-KS,

VAC1 output set to "Digital Audio Interface (Teensy ... )"

hear both signal and sidetone  in headphones

order:

plug in keyer

Ctrlr  - Ctrl works as expected

Thetis - keys, sound in headphone with Driver: WDM-KS

plug in keyer

Thetis - keys, sound in headphone with Driver: WDM-KS

Ctrlr  - says Open OK Teensy, on control movements says failed to open device, if click OK in popup starts working after a few tries, still fails intermittently

I haven't heard the audio buzzing in Thetis.

  73

    Bob   KD8CGH

[James Ahlstrom]

Hello Bob,

I don't think you need fast sound with this keyer, but I am not sure. Please try setting "Use fast sound" to False and let us know what you find.

Jim

N2ADR

[Robert Benedict]

Jim

  If I set fast sound to False and restart I don't hear anything in the headphones and config shows the error message in red:

DirectSound capture device Digital Audio Interface  (Teensy MIDI/Audio) buffer create failed (0x88780064)

Setting fast sound to True and restarting restores the audio.

BTW - I set Play latency to 100 and keyup delay to 250

  73

  Bob   KD8CGH

[Steve Haynal]

Hi Bob,

Yes, the Teensy keyer is an entire additional audio device. It is not headphones only. It is possible to connect to line out and speakers. This diagram in the original post may help:

https://groups.google.com/g/hermes-lite/c/P-i_EYCN--k/m/E_1i7smsAgAJ

By generating the sidetone in the Teensy when a key is pressed directly on the Teensy, we avoid any paths through the computer. This is how low latency is achieved. This is comparable to latency with the openhpsdr ethernet-audio solution. Note that even though openhpsdr radios have the key and sound in the radio, it is just a sound card. All the processing is still done in the computer and then sent back to the radio for audio rendering. Rather than do it that way, we have a separate USB sound card with builtin keyer. This allows us to split the radio (which can now be remote) from the audio and key.

I will have to take a look at some of your other issues later. I have been super busy recently with my real job and family responsibilities.

73,

Steve

kf7o

[Duncan Clark]

In message <45cd4416-ff4e-45aa...@googlegroups.com>,
Steve Haynal writes

>Yes, the Teensy keyer is an entire additional audio device. It is not
>headphones only. It is possible to connect to line out and speakers.

As it shows up as a windows or linux audio device, can one use the
microphone input on the audio board as the mic input for SSB? Will Quisk
or Thetis etc. recognise the Teensy also as audio in?

My wired headset would be a pain if I have to use it's microphone
connector plugged into the computer and then try and plug the headphone
lead into Teensy a couple of feet or so away!

Duncan
--
Duncan Clark
G4ELJ

["Christoph v. Wüllen"]

Yes if you use the audio shield, you can use the mic input for SSB.
But do not do this. Any low-cost USB audio stick is better, as is
any low-cost USB microphone.

Use the Teensy audio input for a purpose that cannot be realized with
a standard audio stick. For example, I route the audio that goes to the
headphone also to the Teensy USB audio output channel, such that
if you open the Teensy USB audio as input on the PC, you get exactly
that what goes to the headphone.

This I use in two different ways:

- I can record a CW QSO including the side tone from Teensy

- I use the Teensy audio as input to WSJTX, this way I do not
need to switch sound cards in the SDR application (the RX
audio goes to the Teensy, appears at the headphones, and
directly goes back to WSJTX).

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/u%24L1rmKNgzigFwcz%40ntlworld.com.
>

[Roger Critchlow]

The headset support in the hasak keyer is incomplete, but it can be configured to send microphone audio to the usb audio in and it sees the buttons wired into the headset microphone circuit.

The headphone wiring that the PJRC audio adapter uses by default has a virtual ground that allows a cap-less headphone out circuit, it's very neat and sounds clean.   But the microphone bias from the audio adapter won't power a microphone above the virtual ground, it doesn't even produce the specified bias voltages over real ground.  So I wire the headset capacitively coupling the headphones and biasing the microphone against real ground, and it works, though the headphones make an annoying crunch as they come online.  It may be that I missed some trick about configuring the audio adapter.

In addition to microphone in, you also get headset buttons.  I wire the microphone input to an ADC and get reliable detection of the buttons on my three button headsets.  The thresholds for the buttons are configurable through MIDI, but they appear to be pretty standard on my sample of two three button headsets.  I've currently soft wired the primary headset button as an auxiliary straight key, with vague plans to use it and the up/down buttons to control the keyer.

But that's all gotten back-burnered by winkeyer emulation, firmware installers, usb audio glitches, MIDI configuration, and other things.  I haven't even settled on how you tell the keyer to route mic-in to usb-out, the mixers are there to make the connection, but I haven't written the code to let you modify the mixer values.

So, yes, you can use a headset microphone as a usb input, and headset buttons as controls, but they're only partially supported in hasak, and the audio adapter hardware doesn't support them well, and Christoph thinks you should just get a decent microphone.  

It's sort of annoying that this audio codec's big feature, the capless headphone circuit, is essentially useless if you try to use it with a standard four wire headset, it's almost as if the part were designed when headsets were wired with separate phone and mic jacks, and I can't remember how long it's been since I had laptop wired like that.   I do remember buying (and losing) the adapter to split the TRRS plug into TRS+TS plugs.

-- 73 -- rec -- ad5dz --

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/5F330C82-FDB0-4F69-B463-DFEBE3F8D64F%40darc.de.

[Duncan Clark]

In message
<CAGayqou=xFXo+p=RFQY5xAY2KzbCzGTe...@mail.gmail.com>,
Roger Critchlow writes

>So, yes, you can use a headset microphone as a usb input, and headset
>buttons as controls, but they're only partially supported in hasak, and
>the audio adapter hardware doesn't support them well, and Christoph
>thinks you should just get a decent microphone.  
>
>It's sort of annoying that this audio codec's big feature, the capless
>headphone circuit, is essentially useless if you try to use it with a
>standard four wire headset, it's almost as if the part were designed
>when headsets were wired with separate phone and mic jacks, and I can't
>remember how long it's been since I had laptop wired like that.   I do
>remember buying (and losing) the adapter to split the TRRS plug into
>TRS+TS plugs.

But that's the point

USB headset - far to modern for my shack!

I'm on an a wired Yamaha CB500 headset, with an electret mic insert,
that I currently use plugged into a Behringer UMC202HD USB audio
interface for my HL2 under Windows.

My CB500 is wired with separate phone and mic jacks so to me, not
knowing very much about audio cards/devices, if Windows sees the Teensy
audio adapter as an audio device the mic output from it should be seen
and treated as such by PowerSDR/Thetis. The quality shouldn't be any
worse than my plugging the mic into the built in soundcard on any
standard computer (not talking laptops here). No?

I get great audio reports whether I use the built in soundcard or the
UMC and it is easy to tweak the Tx audio equalizer in PowerSDR as
required.

[Roger Critchlow]

Duncan --

Well, we won't be able to touch that setup.   The Teensy Audio Adapter is barely producing 2V of microphone bias when asked for 3V, we're not going to match a studio quality preamp with a 48V bias circuit.  But we're not going to retail for over $100, or be the size of a book, either.

The keyer, at least the hasak version, will provide a usb input which can provide microphone input, line input, sidetone input, or keyed IQ input, and any SDR should be able to see that input.  And you could wire separate headphone and microphone jacks for your headset, but I expect your Behringer will produce a better quality microphone signal.

-- 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/SqOq%2BPNfmHjgFwS9%40ntlworld.com.

[Steve Haynal]

Hi Group,

What we are shooting for is equivalent to or better than the mic, headphone, and key jacks that are on the front of every Apache radio. I know people use older headsets with that. We may not use the exact i2s codec as in the prototype teensy audio adapter. Just like other USB audio adapters, we will have the 5V from USB. This can be used for bias. It will also be available on the PCB if someone wants to create a 48V phantom buck-up voltage, although I think that will be rarely required. It has 24bit 48kHz stereo to host and 24bit 48kHz stereo from host. This is more than enough given most HF modes use voice at 2.7kHz or less, and human hearing is rarely above 20kHz. As we begin prototyping a PCB, here are some of features I am hoping to include in the hardware:

** Headphones jack

** Line out jack to external powered and amplified speakers

** Line in  

** Mic in(s) (supporting modern mics and older mics)

** CW paddle input

** CW straight key input

** Key down isolated output for direct connection to HL2 front panel

** i2c connector for optional display

** Power connector for microphone phantom voltage (no +48V by default, but someone can connect their own PCB) or other small addons

** 1-2 buttons for some local control

** 1-2 thumbwheel pots or encoders to change some settings locally
** Additional pins available for more encoders. Since we have a MIDI controller, users can easily add additional knobs for more tactile control. Imagine a big tuning know. Take a look at the latest project by G0ORX:

https://github.com/g0orx/HPSDR_MIDI/wiki

73,

Steve

kf7o

[Robert Benedict]

Steve

   In the present version the only audio out is the headphone jack. Correct?

  Are you now describing a device with audio out over USB to the host computer so we don't need a separate amplified speaker?

  73

    Bob   KD8CGH

[Duncan Clark]

In message <4c5c5eb1-d363-405b...@googlegroups.com>,
Steve Haynal writes

> It will also be available on the PCB if someone wants to create a 48V
>phantom buck-up voltage, although I think that will be rarely required.

48V is a red herring on the what I use. I actually use the adapter that
comes with the CM500 headset and that uses 2 x 1.5V batteries so I
actually use a bias of 3V.

Whilst browsing to see if I find other comments on how good/bad the
Teensy audio adapter microphone is I came across this thread:

http://openaudio.blogspot.com/2017/03/teensy-audio-board-self-noise.html

Which led to:

http://openaudio.blogspot.com/2017/03/tympan-self-noise.html

which led to:

https://forum.pjrc.com/threads/42665-New-Audio-Board!-TI-TLV320AIC3206

with the githubs here:

https://github.com/Tympan/Tympan_Rev_D_Hardware

https://github.com/tympan

So in short an alternative audio board that works with the Teensy and
the Teensy audio libraries with better S:N and an 'inexpensive' chip:

https://www.ti.com/lit/ds/symlink/tlv320aic3206.pdf

You are a better judge of whether it could be useful or not.

[Roger Critchlow]

Duncan --

Nice find!  The lower noise and greater dynamic range would be especially useful if running as a line-in input for a sound card SDR.  The cap-less headphone circuit runs referenced to ground by synthesizing a negative rail.  The chip has a headset detection capability to distinguish stereo headphones from cell phone headsets and also reads the primary button on the headset.   And it drops right into the Teensy Audio system.

-- 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/Mq8Ln3SFbGkgFwY%24%40ntlworld.com.

[Steve Haynal]

Hi Duncan,

Yes, the TLV320AIC series is a good family of i2c audio codecs. The TLV320AIC3106 appears to be a bit more common and less expensive.

Some i2s devices have a bigger amplifier for 1-2W speakers. How important is that to people? I'd think people could use power speakers meant to plug into line out.

One of the cheapest options for an i2s codec is everest semiconductor:

 http://www.everest-semi.com/en_products.php

Cirrus Logic and AKM are also a popular suppliers of i2s codecs.

73,

Steve

kf7o

[Steve Haynal]

Hi Bob,

No, low latency CW sidetone mixing is always at the audio headphone or speaker output right at the i2s codec, either in the openhpsdr radio or the teensy device, not the PC sound system. Sending audio through the PC always adds latency, often low enough for many operators.

If you want to use the computer speakers, then try some of the good work in Quisk, SparkSDR, piHPSDR, SDR Console and LinHPSDR. The authors of all these software programs have put effort into reducing latency from key press to sidetone heard in the speaker. Sometimes this latency is not low enough for those who wish to operate at high speeds or who are very sensitive to latency. This is an unavoidable problem as it takes time to send data to a host PC. Also, any openhpsdr solution pays similar latency penalties.

**openhpsdr solution:

RX RF -> openhpsdr radio -> IQ data over ethernet -> Host PC processing -> Audio data over ethernet -> openhpsdr radio (MIX in sidetone) -> i2s device -> speakers or headhones

Above you see several long latency ethernet hops, so the latency from antenna to sound is high, but the time from CW key press to sound in speakers or headphones (not those built into the computer, but from the front jack of an openhpsdr radio) is low.

**Quisk/SparkSDR/piHPSDR/LinHPSDR family of solutions:

RX RF -> HL2 -> IQ data over ethernet -> Host PC processing (MIX in sidetone) -> Audio to host computer sound card -> headphones or speakers

Here you see the latency is longer as it is hard to have low latency Audio in a standard host computer with sound card as the computer does so many other things. The authors of the software have worked hard to reduce latencies, and you can achieve the lowest latencies with audio backends such as Jack, but this can be difficult to configure. Latencies are often low enough for many operators.

Note with this setup you must also key the software, usually:

CW Key -> USB Midi -> Host PC processing

 

The USB Midi can also add some latency but usually less than any audio latencies.

**Proposed solution

RX RF -> HL2 -> IQ data over ethernet -> Host PC processing -> Audio via USB to Teensy gadget -> headphone or speakers connected to Teensy

Although the final audio link is over USB, this has similar latency to ethernet. The key idea is that the CW key to audio path is entirely within the Teensy to keep latencies as low as the openhpsdr solution:

CW Key -> Teensy -> i2s -> headphones or speakers on Teensy

At the same time

CW Key -> USB Midi -> Host PC processinng -> ethernet -> HL2 -> RF out

In both the openhpsdr and teensy case, you must connect headphones or speaker to the i2s device in the openhpsdr radio or teensy for the lowest latency. You will always add latency when sending data back to the host PC.

73,

Steve

kf7o

 

[Steve Haynal]

Hi Group,

I updated the k3ng .hex file to disable an audio loop that was enabled for testing and may have caused some audio issues. I also enabled pins 14 and 15 to be key state outputs, one is inverted. This is for anyone who wants to experiment with a direct connection to the HL2 CW key input. Finally, I pulled in the latest changes from the master k3ng repository. You can find everything here:

https://github.com/softerhardware/k3ng_cw_keyer

73,

Steve

kf7o

[Brian Holmes]

Sorry guys but I have to ask, what is wrong with the Hermes Lite 2 Companion Board?  

I have one and, it works great. Variant Gateware also works well.  

Keyer function in Open HPSDR works well as does the use of the straight key and sidetone. 

Brian

VE3IK 

On May 8, 2021, at 8:01 PM, Steve Haynal <softerh...@gmail.com> wrote:

Hi Group,

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/1b2fe970-4d2f-48aa-8d3b-72e82a7e7230n%40googlegroups.com.

[Steve Haynal]

Hi Brian,

Neither the AK4953 companion card nor the new Teensy keyer are necessary. Most software accepts MIDI CW keyer input via USB to the host computer and generates CW sidetone mixed with the received audio on the host computer. Also, the stock HL2 permits connection from an external keyer, and SDR Console has a mode to generate a relatively low latency sidetone with that method. There are posts in this list of successful participation in CW contests using the stock HL2. It is only the most picky CW operators who are annoyed with software sidetone latency at higher CW speeds who are interested in alternatives.

The original openhpsdr approach, of which the AK4953 companion card is a copy, requires the operator to be right in front of the radio. The Teensy keyer approach allows for either local or remote operation with low latency CW sidetone. A goal of the HL2 is to faciliate remote use. In hindsight, I wish I would have not even included the KEY/PTT jack.

The original openhpsdr approach implements the keyer and an audio device with buffers in the FPGA. This takes up valuable FPGA resources, which are limited in a cost-optimized radio. IQ data is sent from the radio back to the host computer, processed and demodulated in the host computer, and then audio sent back to the radio. There is nothing special about an audio jack on the radio as it is just another sound card with similar latencies to any other sound card. The functions of CW keyer and sound card can be handled by other cheaper components rather than a more expensive FPGA, so that available FPGA resources can be reserved for the high-speed DSP which only they can do. This is what the Teensy keyer does by using a microcontroller. The openhpsdr approach gives up a receiver (useful for multiband skimming) because of the extra FPGA demands. The concept of variants, which I developed 18 months ago, helps alleviate this concern as now people can easily switch to different gateware variants, for example one which implements just 10 receivers for skimming, but I would still rather use FPGA resources for tasks which only a FPGA can do.

The original openhpsdr approach requires additional IO pins on the FPGA, which are again in limited supply for a cost-optimized radio. The AK4953 gateware variant does not support external ATU, fan or synchronized radios since the hardware assigned IO without thought to these other functions. As discussed elsewhere on this list, this could be mitigated if a small inexpensive MCU (~$1 plus some programming) were added to the companion card. Because the Teensy keyer approach does not use FPGA IO, it works with the stock gateware which inlcudes ATU, fan and synchronized radio support.

Not all software supports sending audio back to the radio as required by the openhpsdr approach. You can't currently use SDR Console, SparkSDR or Quisk with the AK4953 companion card due to this. It is a bit awkward and unusual for software to have to send audio back to the unit, versus using a standard audio library to send audio to a standard sound card. The Teensy keyer approach is essentially a standard USB sound card. You just set you software to use that sound device and you will hear the RX audio with low latency CW sidetone. Currently SDR Console may not support MIDI CW keying, so you may need a supported secondary direct connection from the Teensy keyer to the HL2.

The original openhpsdr approach only offers a basic keyer. The Teensy keyer provides more functionality as it is software-based and uses ports of popular keyers. For example, one can use the K1EL Winkey interface for logging and contest programs with the Teensy keyer, but not the AK4953 companion card.

There are many microcontroller-based keyers available, but I am not aware of one that combines a keyer with a USB audio device for low latency CW sidetone mixed with the received audio. This is applicable not just to the HL2, but other SDRs too. This is an exciting opportunity to make something new with wider appeal, especially if the price point is in the $25-$50 range which I think is achievable.

For these reasons and others (there is much discussion and contention about this topic in previous posts if you search), I'd rather work on and promote a solution like the Teensy keyer instead of the original openhpsdr solution.

“Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away.” -- Antoine de Saint-Exupéry

73,

Steve

kf7o

[radi...@mail.com]

That's a superb summary Steve. Many thanks for taking the time to write it because it finally fully clarifies many questions I had in my head regarding this project. It sounds really exciting and I for one am very much looking forward to the result.

As an SDR Console user I can confirm for anyone reading that the work Simon did to add a low latency sidetone to SDRC when using CW via HL2 front panel key input works brilliantly for that method but the idea of being able to send CW remotely sounds fantastic, let alone all the other features you are cramming in. I hope Simon does manage to add midi-keying to SDRC to support the Teensy.

Thank you again for yet more great work. You spoil less capable mortals like myself with your brilliance.

73

Max

[radi...@mail.com]

Hi Steve

I have put in a request on the main SDR Console support forum (Requests section) for Simon to add MIDI keying to SDRC. He has replied that he will try and add it some time around the end of this month if possible. I hope I explained the issue to him correctly?

https://forum.sdr-radio.com:4499/viewtopic.php?f=53&t=1110

Here's hoping!

73

Max

On Saturday, 17 April 2021 at 05:49:54 UTC+1 softerh...@gmail.com wrote:

The software you use must accept CW keying via MIDI. I know that Quisk, SparkSDR and piHPSDR do. Take a look at the CW and Logging Setup document for linHPSDR:

https://github.com/softerhardware/Hermes-Lite2/wiki/Software#linhpsdr

The software and keyer have to agree on which MIDI channel and note to use for CW. You may have to change that in the source code for now.

I know SDR Console supports MIDI controllers, but I didn't see one in the options to enable. See Tools->Options->Controllers->MIDI. Maybe if you are in CW mode then TX on controls the key? If there is no support, it would be very easy for Simon to add.

[Steve Haynal]

Hi Max,

Thanks for that. Given the ~10ms jitter I recently saw to a VPN connection in the Ukraine, we may need an IQ method too. Roger has done some work in that area with his hasak software. MIDI cw key down/up is a single message subject to jitter, and one dit at 40wpm is 30ms. IQ data has resolution of 48kHz (0.02ms) and is buffered so does not vary with jitter. 

73,

Steve

kf7o

[K7MDL]

Looking at this project where it has received audio passing through the Teensy Sound card, and my goal to make my Teensy 4.1 based SDR as a HL2 control head, I think these 2 projects intersect.  In the control head the Teensy replaces the PC sound card loop, potentially also skipping ethernet so latency is minimal concern, but the receive audio is still present, regardless of how it gets into the Teensy sound card.  I can see incorporating much of this into my SDR build as it has the full graphics and UIO framework already done.  A concept could be accelerated be accelerated by stating out using the RX audio for a PC to the Teensy Line in, then proceed to replace the PC with a local ethernet connection (6"), a direct FPGA connection via QSPI, I2S, or what ever works.

- Mike

[Steve Haynal]

Hi Mike,

The picture looks very interesting. I also would like to make it easier to integrate a HL2 with a MCU-based software. Since you are already using the SD card, I'm thinking a PSRAM interface:

https://www.pjrc.com/store/psram.html

6 pins would provide a relatively high bandwidth interface, and the libraries to read/write PSRAM devices already exist. I looked at the 6404 and it would be pretty easy to emulate the device on the FPGA. I am currently working on the schematic and PCB for the Teensy Keyer and will add a port for this to facilitate experiments. At least on the Teensy 4.0 which we are using, the memory interface pins for PSRAM should be available as part of the header.

73,

Steve

kf7o

[K7MDL]

I was studying the QSPI interface specs and cruising the Teensy forum for clues on how it was used (via FlexSPI).  It seems they detect a chip by some mechanism and the use of EXTMEM tags maps the RAM into the memory map.  

Looking at the library at the link you provided, I see lots of read and write functions for various size data which seems useful.  What is not clear to me is what initialization has to pass startup checks before we can use those read/write commands. Seems like we would have to adapt the library to skip validation requiring a memory chip to be present.  The code is not commented much, so while I believe there are such init checks, I am not sure what they are and in what lines they occur at.  They are implementing features like wear leveling and erase, those could interfere with our desire to use it a as data bus.  Also cache might be involved.

Looking at the flash memory test program

teensy41_psram_memtest/teensy41_psram_memtest.ino at master · PaulStoffregen/teensy41_psram_memtest (github.com)

It appears rather simple, no calls to FlexSPI, a couple usages of  arm_dcache_flush_delete() , mapped at address 0x70000000

memory_begin = (uint32_t *)(0x70000000);
memory_end = (uint32_t *)(0x70000000 + size * 1048576);

Seems like somehow it has to use FlexSPI, but I do not see where or how.

The PJRC audio card also has pads for a SPI based memory chip, but that is the standard 4 wire SPI, not the QSPI. and uses pin 6 for CS. The SD card shares that SPI bus with pin 10 for CS.

Audio card link   PJRC Store

While I have a 4.0 on a breakout board, I find the T4.1 easier to use and expand on later, avoiding pogo pins, FPC connectors, external SD card socket, and access to more IO pins with out the need for a breakout board.  All of my builds so far are a T4.1 on a proto board, with minimal point to pint wiring underneath (except for my RF wattmeter/band decoder which uses every single pin on a T4.1).   In the last SDR build, I build the T4.1 on the back of the touchscreen display 2x20 header to keep the SPI bus short, ensuring max speed and most of all, reduced RMI.  The build in the sloped box uses a 7" ribbon cable, even with copper foil tape shielding was a good RFI generator at times. 

I do not see QSPI pins available on the T4.0.

[K7MDL]

Came across this

Can't seem to get FlexSPI to work for me; RT106X - NXP Community

User was trying to use FlexSPI to share data between 2 MCUs together.  Offers up some things he tried.

[Steve Haynal]

Hi Mike,

The PSRAM device does have an init sequence specified in the PSRAM device datasheet. It looked fairly simple and should be possible to emulate. I'm interested in emulating this type of device for the bandwidth. It may be possible to achieve close to 400Mbs. I plan to reserve 6 pins to experiment with this on the shield I am working on. I will try to pick 6 pins which can be used for EXTMEM and FlexSPI.

There are already cores and Audio library forks for the Teensy Keyer project:

https://github.com/softerhardware/cores

https://github.com/softerhardware/Audio

You can find more details in this post:

https://forum.pjrc.com/threads/66687-Alternate-USB-Audio-Code

73,

Steve

kf7o

[Mike Lewis]

For our SDR implementation we have been using chipaudette/OpenAudio_ArduinoLibrary: Arduino Library for OpenAudio Hacking (github.com), updated by Bob, W7PUA to support 32 bit floating point, along with it FFT up to 4096 I and Q. That is what I had configured in the screen shot.  The performance has been good.   

 

The question arises, if the changes you made would still be required, and of those changes, how much work would it take to apply them to the 32bit library?  Having the keyer and the SDR on the same audio library should make more possible merging  them.

 

The 4 lane FlexSPI does seem to offer a high bandwidth channel.  Seems like FlexIO could also have good throughput reading the app notes, I do not have numbers for their usage and I never touched either capability before. 

 

• Mike
•  

- Mike

On Sunday, May 16, 2021 at 4:54:09 PM UTC-7 softerh...@gmail.com wrote:

Hi Max,

 

Thanks for that. Given the ~10ms jitter I recently saw to a VPN connection in the Ukraine, we may need an IQ method too. Roger has done some work in that area with his hasak software. MIDI cw key down/up is a single message subject to jitter, and one dit at 40wpm is 30ms. IQ data has resolution of 48kHz (0.02ms) and is buffered so does not vary with jitter. 

 

73,

 

Steve

kf7o

 

On Thursday, May 13, 2021 at 2:12:30 AM UTC-7 radi...@mail.com wrote:

Hi Steve

 

I have put in a request on the main SDR Console support forum (Requests section) for Simon to add MIDI keying to SDRC. He has replied that he will try and add it some time around the end of this month if possible. I hope I explained the issue to him correctly?

 

https://forum.sdr-radio.com:4499/viewtopic.php?f=53&t=1110

 

Here's hoping!

 

73

 

Max

 

 

On Saturday, 17 April 2021 at 05:49:54 UTC+1 softerh...@gmail.com wrote:

 

 

The software you use must accept CW keying via MIDI. I know that Quisk, SparkSDR and piHPSDR do. Take a look at the CW and Logging Setup document for linHPSDR:

https://github.com/softerhardware/Hermes-Lite2/wiki/Software#linhpsdr

 

The software and keyer have to agree on which MIDI channel and note to use for CW. You may have to change that in the source code for now.

 

I know SDR Console supports MIDI controllers, but I didn't see one in the options to enable. See Tools->Options->Controllers->MIDI. Maybe if you are in CW mode then TX on controls the key? If there is no support, it would be very easy for Simon to add.

 

--

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/285b9d60-e856-44e0-a556-ac443d0f068fn%40googlegroups.com.

[Steve Haynal]

Hi Mike,

Most of our changes were to the cores library where we rewrote much of the audio USB code to prevent drops, glitches on all OSes as well as support 48kHz short low latency Audio buffer lengths. The changes to Audio were minor, mainly to support 48kHz on the sgtl5000:

https://github.com/softerhardware/Audio/commit/4c640795f743b8f572220d5b10e45f934f641523

I expect to make similar changes to support the WM8960. (There is actually some code for the WM8960 posted in the forum.)

I think our changes are orthogonal to what W7PUA is doing. Eventually I can start using his fork, port our changes over, and issue a pull request.

73,

Steve

kf7o

[Steve Haynal]

Hi Mike,

What is the part number for the display you are using? Does it use an i2c interface?

73,

Steve

kf7o

On Monday, May 17, 2021 at 7:45:51 PM UTC-7 K7MDL wrote:

[Mike Lewis]

I and a few others have used 2 displays.  The 4.3” uses the RA8875 and the 7” (and a 10” is available) uses the RA8876.  The feature BTE which off loads the CPU.

 

The ones I use I purchased through buydisplay.com either direct or through eBay.  Both use the same 2x20 connector and can support most common interfaces through jumper configuration.  You can order the jumper config you desire.  We are using the 4 wire SPI configuration. The touch controller is on I2C bus.   The displays will also run on 5V or 3.3V.  It has a 3.3V regulator onboard, just change a jumper.  I use the 5V versions. 

 

While touch response it very good (Capacitive version used), I elected to write my own touch gesture engine (swipes, pinch, drag) as the internal engine responds very poorly for me and the Arduino library author(s).  The RA8876 controller seems to be faster processing.  I monitor the main loop times and there is a noticeable difference. I use a few defines to account for the library selection and the code changes required for each controller type.  The RA8876 library used lets me easily change the SPI speed in the RA8876.init() function, where the RA8875 I believe changes the speed based on many factors like host CPU detected and even what operation it might be doing (optimized).

 

The WIKI on my SDR_8875 Github project has links to all the libraries used, the same should be in the code comments.

 

Here is my 7” order info from buydisplay.com

 

The 4.3” details, ran about $52 with normal free shipping option.

Capaptive Touch Screen SPI 4.3"800x480 TFT LCD Display Module w/RA8875,Tutorial | eBay

 

Capaptive Touch Screen SPI 4.3"800x480 TFT LCD Display Module w/RA8875,Tutorial

 

Beware of the 5” version, it uses a different touch controller which has been difficult to use for others.  There is a wide display 1280x600 I think that requires dual SPI connections.  After months, one person has go tit working but required special a MIPI controller.  The SPI on these controllers are not tri-state so do not share the SPI bus, a tri-state buffer (74HC125 I think) is required for that.  

 

• Mike

 

From: herme...@googlegroups.com <herme...@googlegroups.com> On Behalf Of Steve Haynal
Sent: Thursday, May 27, 2021 22:42
To: Hermes-Lite <herme...@googlegroups.com>
Subject: Re: A Teensy Keyer prototype

 

Hi Mike,

 

What is the part number for the display you are using? Does it use an i2c interface?

 

73,

 

Steve

kf7o

 

On Monday, May 17, 2021 at 7:45:51 PM UTC-7 K7MDL wrote:

Looking at this project where it has received audio passing through the Teensy Sound card, and my goal to make my Teensy 4.1 based SDR as a HL2 control head, I think these 2 projects intersect.  In the control head the Teensy replaces the PC sound card loop, potentially also skipping ethernet so latency is minimal concern, but the receive audio is still present, regardless of how it gets into the Teensy sound card.  I can see incorporating much of this into my SDR build as it has the full graphics and UIO framework already done.  A concept could be accelerated be accelerated by stating out using the RX audio for a PC to the Teensy Line in, then proceed to replace the PC with a local ethernet connection (6"), a direct FPGA connection via QSPI, I2S, or what ever works.

- Mike

On Sunday, May 16, 2021 at 4:54:09 PM UTC-7 softerh...@gmail.com wrote:

Hi Max,

 

Thanks for that. Given the ~10ms jitter I recently saw to a VPN connection in the Ukraine, we may need an IQ method too. Roger has done some work in that area with his hasak software. MIDI cw key down/up is a single message subject to jitter, and one dit at 40wpm is 30ms. IQ data has resolution of 48kHz (0.02ms) and is buffered so does not vary with jitter. 

 

73,

 

Steve

kf7o

 

On Thursday, May 13, 2021 at 2:12:30 AM UTC-7 radi...@mail.com wrote:

Hi Steve

 

I have put in a request on the main SDR Console support forum (Requests section) for Simon to add MIDI keying to SDRC. He has replied that he will try and add it some time around the end of this month if possible. I hope I explained the issue to him correctly?

 

https://forum.sdr-radio.com:4499/viewtopic.php?f=53&t=1110

 

Here's hoping!

 

73

 

Max

 

 

On Saturday, 17 April 2021 at 05:49:54 UTC+1 softerh...@gmail.com wrote:

 

 

The software you use must accept CW keying via MIDI. I know that Quisk, SparkSDR and piHPSDR do. Take a look at the CW and Logging Setup document for linHPSDR:

https://github.com/softerhardware/Hermes-Lite2/wiki/Software#linhpsdr

 

The software and keyer have to agree on which MIDI channel and note to use for CW. You may have to change that in the source code for now.

 

I know SDR Console supports MIDI controllers, but I didn't see one in the options to enable. See Tools->Options->Controllers->MIDI. Maybe if you are in CW mode then TX on controls the key? If there is no support, it would be very easy for Simon to add.

 

--

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/2859bc53-1c0b-40bf-8ef3-19f005d6955an%40googlegroups.com.

[Mike Lewis]

Given there are 40 pins, one of our SDR group produced a simple PCB to reduce the 40 pins to 14.  To get rid of SPI cable radiated noise and increase speed, my latest build has the Teensy directly connected to the display, no ribbon cable.

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/CO6PR18MB38587C2D0C00E359B16EFB7DF6229%40CO6PR18MB3858.namprd18.prod.outlook.com.

[Marijan Dujmovic]

Hello Bob,

Im  struggling to make midi work.

Where I can get this 4/19 hex and which Thetis version is correct one ?

Cant see any of those settings in 2.8.11 "min- 0  max- 127

Cat Cmd- CWX Key"

Thanks.

Dana subota, 24. travnja 2021. u 02:02:56 UTC+2 korisnik rka...@gmail.com napisao je:

Thanks Steve

  Got a chance to try the 4/19 hex out. Here's what I saw

keys HL2 with Quisk with very little lag

combines sidetone with received audio with Quisk audio output set to laptop speakers :), laptop audio out reset to "Digital Audio Interface (Teensy ... )

 Ctrlr panel is schizophrenic, on launch shows green bar on bottom with "Open OK  device Teensy ..." message

any panel control movement  yields [ERROR]  [19:55:34:000057] failed to open device 'Teensy..." message popup

WinKey emulation works with WinWarbler

keys HL2 with Thetis with very little lag

Midi settings:

ID- 1

control name-  keyer

control type- Button

min- 0  max- 127

Cat Cmd- CWX Key

no sidetone with VAC1 Output set to laptop speaker, with any other Output setting no received audio

makes a very brief squawk with lag at start of each CW transmission

if check sidetone and disable PTT produces usual sidetone with lag

  73

    Bob  KD8CGH

On Tuesday, April 20, 2021 at 12:50:29 AM UTC-4 softerh...@gmail.com wrote:

Hi Bob,

Okay, I moved the output back to note 1 but on value of 127. There are updated .hex files on the github site. I'm not sure where the original 99 came from. MIDI is a pretty straight forward (and old) protocol. There are several message types and then usually two values associated with the message, ranging from 0-127. For example, a note one message with the note and the velocity as data. See this good tutorial for details:

https://learn.sparkfun.com/tutorials/midi-tutorial/all

You are an early adopter so please expect some unfinished areas. I plan to add details about using the modified libraries on the main page but below are a few details I sent to developers. I think most people will just have to be able to program a .hex file.

 You can find the repos here:

https://github.com/softerhardware/cores

https://github.com/softerhardware/Audio

I usually create a symbolic link from where these would be installed in a standard Teensyduino setup to the path where I have the custom libraries.

73,

Steve

kf7o

On Monday, April 19, 2021 at 4:24:07 AM UTC-7 rka...@gmail.com wrote:

Reid - thanks. It also looks to me like the note value is being set to 99 decimal.

Steve - see Reid's and my comment. I think that you set the note to 127, but the value is still 99. Unfortunately even when I set the note to 127 in Quisk it still didn't work.

No, direct keying doesn't work. Looking at your source it doesn't appear to be activated. You only flash the LED.

Perhaps note 1, value 127 might work for both Quisk and Thetis?

I tried to modify and recompile but my recompile didn't function. I don't know if I have a code error or it's because the IDE refused can't load the core "library". Too many unknowns. If someone could point me to a resource for loading  the core I could test more things myself.

  73

   Bob  KD8CGH

On Monday, April 19, 2021 at 3:56:01 AM UTC-4 scumballc...@gmail.com wrote:

Hi All,

It is the value of the note which is important for Thetis, not the note Id. It looks to me as it the note Id has been set to 127 but it's value is being set to 99. Thetis will take any note Id and allow it to be mapped to a command. That command will expect a value and for MIDI keying, the value is 127. All other values will unkey the Tx.

Cheers

Reid
Gi8TME/Mi0BOT

On 19/04/2021 02:47, Robert Benedict wrote:

Steve

Thanks for the new uploads.

 Unfortunately your new hex no longer keys Quisk.

I reloaded the old hex and it still works. In Quisk the Midi note for CW key is set to 1 and Midi CW key device set to Teensy/Audio. I tried setting the Midi note to different values and it keyed the HL2  for all of them. I didn't see a setting for value.

I retried the new hex with notes 1 and 127 and it never keyed the HL2.

With Thetis in the Midi Controller setup / Mapped controls tab, if I touch a key it recognizes it and says the control ID is 127 with values from 0 to 99. If I make the control type "button" I can assign it to CWX Key and save. Unfortunately it doesn't key the HL2.

If I go into Midi Control Setup / Diagnostics tab for Control # 7F it says Data is 0 or 63 for off and on when key is pressed. I'm guessing that this is in hex so the values are 127 and 99 as on the other tab.

I also tried the new hex with SDR Console. It reports the "Index" as 127 with values either 0 or 99.

Note, value, control ID, Index, ... every app seems to use different MIDI terms :(

   73

    Bob   KD8CGH

On Sunday, April 18, 2021 at 7:52:50 PM UTC-4 softerh...@gmail.com wrote:

Hi Bob,

I rebuilt the k3ng code to use 127 for the CW key note value. I also built and posted .hex files for Roger's hasak keyer and Christoph's TeenyWinkeyerEmulator.hex. I didn't extensively test the last two and am hoping Roger and Christoph will build and maintain the .hex file releases. You can find the links on the main keyer page:

https://github.com/softerhardware/k3ng_cw_keyer#programming-the-teensy-4

The 99 value in SDR Console sounds like an error. Does it work if you you set TX on to respond to note 99? Maybe Simon can respond. You may have better luck posting to the SDR Console group. This should be easy for SDR Console to support if it doesn't already.

73,

Steve

kf7o

On Saturday, April 17, 2021 at 1:01:45 PM UTC-7 rka...@gmail.com wrote:

Reid

The note is set to 1 in Steve's code, but I can't find where the value is set.

Unfortunately I can't load the "core" library in the IDE so I don't know if my recompile will function as intended.

I've also been trying to get it to work with SDR Console, which seems to have a different language for MIDI. It reports the "value" as 99 when my straight key is closed. Unfortunately, "Note On" doesn't turn the TX on.

  73

   Bob  KD8CGH

--
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/83e48a04-42a8-4960-a11b-a907a00d00d8n%40googlegroups.com.

[Robert Benedict]

The "4/19" hex refers to Steve's hex file. Looks like it has been slightly updated to 4/20

https://github.com/softerhardware/k3ng_cw_keyer/blob/master/releases/TeensyWinkeyerEmulator_20210419.hex

The Thetis settings are in CAT Control/CAT/Configure MIDI button ->  opens a config window. I think it needs to find a MIDI device to config or you get a blank window.

    73

      Bob   KD8CGH.

[Marijan Dujmovic]

Thanks  Bob,

I will try with Steve's version.

Hasak works with mixed rx audio and keyer , but key/ptt via midi doesn't .

I can see midi messages in Thetis with values 00/01,   also can select CWX key command but nothing happens.