HL2 with Hardrock-50 First CW QSO.

[rentwist]

Greetings all,

I had my first (CW) QSO with the HL2/HR-50 this afternoon, with a ham in Germany.  I was running about 40W.  I am using Taka-san's AK4951 companion board made to work with the HL2 and a custom version of Taka-san's gateware implementing a CW keyer on the HL2 CN4 CW Key/PTT jack.  The companion board also provides a local: Headphones jack, Speaker (controlled by the RX Random SW switch), a Microphone jack and control/bandswitching of the HR-50 using a DB-9 serial/PTT connection.  For the microphone I am using an Icom HM-12 hand microphone rewired to work with my KX3 (and now HL2).  I have not made a voice QSO but audio seems to sound good on a nearby transceiver.

Anyway, I noticed that the receiver seems to have low sensitivity for a short period of time after transmit to receive switch over.  That is, I did not hear the German ham well until maybe one second or so after I finished transmitting.  I am not sure what is causing this but was wondering if perhaps people have noticed the same thing.  It did occur to me that if the HL2 TX/RX was running full duplex (but I do not think it is), perhaps this could happen, a time delay for the RX to go from signal overload (from the TX) to receiving normally.

Any insight into this?

73,

Robert, WA2T

P.S.  Next I plan to design and build a version of Taka-san's companion board that will plug directly onto the HL2 DB1 and DB12 connectors and provide a HR-50 DB-9 serial/PTT connection.  If there is interest (please chime in), I can make more boards than I need (which would be only a few).

[Steve Haynal]

Hi Robert and Group,

Do you see the same behavior with the stock gateware? I don't see this timing issue. The timing hangs of Taka's gateware may be different.

Although it is great to see experimentation, I want to share some details that may not be widely understood. There is no audio processing or final demodulation done on the HL2 or any other SDR implementing the openhpsdr protocol. All RX or TX data to or from the HL2 is in chunks of at least 48kHz of bandwidth. Alll demodulation (SSB, AM, FM, etc) must occur in software. If you trace the mic audio data:

Mic->HL2->48KHz to PC->Software Processing->48kHz back to HL2->HL2 TX chain.

Likewise receive audio from the HL2 is

HL2 RX chain->48kHz to 384kHz to PC->Software Processing->48kHz audio back to HL2->Optional HL2 codec

As you can see from above, the HL2 is nothing more than an ethernet-based sound card when implementing audio in/out. You are better off using an $8 USB audio adapter or your built-in host computer audio. Handling the audio on the FPGA takes FPGA resources which can be better used for other purposes like more receivers. Given the commodity of existing sound cards, it makes no sense to me to duplicate this on the HL2.

73,

Steve

kf7o

[Takashi K]

Hi Robert-san,

> I noticed that the receiver seems to have low sensitivity for a short period of time after transmit to receive switch over. 

seems no problem in my shack.

I attached the short movie.

The signal at 3.525 was SG output. I sent the dot several times.

73,

Taka,   ji1udd

[Christopher KB3CS]

having gone round and round with C-Media USB audio and others some years ago (all cheap), and with reference to the soundcard recommended for use with the HobbyPCB RS-HFIQ SDR, the StarTech 96 ksps USB audio device should provide far better results than the suggested Sabrent USB.

  $26 at Walmart.com

  https://www.walmart.com/ip/StarTech-USB-Stereo-Audio-Adapter-External-Sound-Card-with-S-PDIF-Digital-Audio/35461503

 - 3g (base 19) -

On Tuesday, September 3, 2019 at 1:38:31 AM UTC-4, Steve Haynal wrote:

Hi Robert and Group,

Do you see the same behavior with the stock gateware? I don't see this timing issue. The timing hangs of Taka's gateware may be different.

Although it is great to see experimentation, I want to share some details that may not be widely understood. There is no audio processing or final demodulation done on the HL2 or any other SDR implementing the openhpsdr protocol. All RX or TX data to or from the HL2 is in chunks of at least 48kHz of bandwidth. Alll demodulation (SSB, AM, FM, etc) must occur in software. If you trace the mic audio data:

Mic->HL2->48KHz to PC->Software Processing->48kHz back to HL2->HL2 TX chain.

Likewise receive audio from the HL2 is

HL2 RX chain->48kHz to 384kHz to PC->Software Processing->48kHz audio back to HL2->Optional HL2 codec

As you can see from above, the HL2 is nothing more than an ethernet-based sound card when implementing audio in/out. You are better off using an $8 USB audio adapter or your built-in host computer audio. Handling the audio on the FPGA takes FPGA resources which can be better used for other purposes like more receivers. Given the commodity of existing sound cards, it makes no sense to me to duplicate this on the HL2.

73,

Steve

kf7o

 

[...]

[Takashi K]

Hi Robert-san,

I checked a little more.
After sending for a longer time, the phenomenon was reproduced.
I guess the low sensitivity after transmit is AGC cause on SDR software.

73,

Taka,  ji1udd

[Sid Boyce]

Hi Christopher,
DDC/DUC transceivers like HL2 only require a single cheap sound card
dongle to support Mic/Speakers.

RS-HFIQ/Softrock/UHFSDR, etc. rely on 2 sound cards, one for I-Q
processing and one for Mic/Speakers.
73 ... Sid.

On 03/09/2019 15:13, Christopher KB3CS wrote:
> having gone round and round with C-Media USB audio and others some
> years ago (all cheap), and with reference to the soundcard recommended
> for use with the HobbyPCB RS-HFIQ SDR, the StarTech 96 ksps USB audio
> device should provide far better results than the suggested Sabrent USB.

>   $26 at Walmart.com
> Â
> https://www.walmart.com/ip/StarTech-USB-Stereo-Audio-Adapter-External-Sound-Card-with-S-PDIF-Digital-Audio/35461503
>
>  - 3g (base 19) -

>
>
> On Tuesday, September 3, 2019 at 1:38:31 AM UTC-4, Steve Haynal wrote:
>
> Hi Robert and Group,
>
> Do you see the same behavior with the stock gateware? I don't see
> this timing issue. The timing hangs of Taka's gateware may be
> different.
>
> Although it is great to see experimentation, I want to share some
> details that may not be widely understood. There is no audio
> processing or final demodulation done on the HL2 or any other SDR
> implementing the openhpsdr protocol. All RX or TX data to or from
> the HL2 is in chunks of at least 48kHz of bandwidth. Alll
> demodulation (SSB, AM, FM, etc) must occur in software. If you
> trace the mic audio data:
>
> Mic->HL2->48KHz to PC->Software Processing->48kHz back to HL2->HL2
> TX chain.
>
> Likewise receive audio from the HL2 is
>
> HL2 RX chain->48kHz to 384kHz to PC->Software Processing->48kHz
> audio back to HL2->Optional HL2 codec
>
> As you can see from above, the HL2 is nothing more than an
> ethernet-based sound card when implementing audio in/out. You are

> better off using an $8 USB audio adapter
> <https://www.amazon.com/Sabrent-External-Adapter-Windows-AU-MMSA/dp/B00IRVQ0F8> or

> your built-in host computer audio. Handling the audio on the FPGA
> takes FPGA resources which can be better used for other purposes
> like more receivers. Given the commodity of existing sound cards,
> it makes no sense to me to duplicate this on the HL2.
>
> 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
> <mailto:hermes-lite...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/hermes-lite/4cb4f679-a4ba-43b8-a206-8dd12547c0d7%40googlegroups.com
> <https://groups.google.com/d/msgid/hermes-lite/4cb4f679-a4ba-43b8-a206-8dd12547c0d7%40googlegroups.com?utm_medium=email&utm_source=footer>.


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

[rentwist]

Hi Taka-san,

Aha!  So the plot thickens.  I was just playing with my HL2 also and found if I did what you did (short dit's while listening to a carrier in the RX passband), it recovers quickly, as you found.  But, when in QSO with another station, the return to proper RX is slower for some reason.  So I guess the AGC recovery time is too long.  I do not think there is anything in controller SW to control this although there is the AGC control.  I admit that (in PiHPSDR) I usually put that all the way up so the line in the spectrum is all the way down, I will have to play with having it up closer to the noise floor and see if that makes a difference.  I also want to recompile the PiHPSDR program with the Radioberry option so that the "Attenuation" control is translated to "RF Gain", that is much more intuitive.  All the way around, this all is a learning experience!

I know it is not Steve's cup of tea but I love having a local Headphones output, Mic input, CW keyer (which I guess is coming back HL2B9 via CN4?), Speaker and (especially) HR-50 band switching/PTT.  Call me crazy but to me an SDR comes "standard" with at least a mic, headphones and key jack.  Look at Flex and Anan.  Having said that, I am not really a radio by computer sort of guy (not a Flex'er).  I like knobs, switches (and of course) I/O's!  This is why along with my interest in building SDR's, I am equally interested in SDR controllers (along the lines of John Melton/Anan's PiHPSDR controller box).  Flex seems to be evolving that way too.  But, I digress...

Thanks for the follow-up and all of your help in my quest Taka-san!

73,

Robert, WA2T

[Alan Hopper]

Hi all,

this does sound very much like the software receive agc catching the end of the tx signal.  It is currently a bit of a guessing game for all software as to when the received iq signal changes from tx to rx data, I believe Steve has gateware plans that should help with this. Recent versions of SparkSDR http://www.ihopper.org/radio/previews.htm  have a fix for this, the rx agc is fixed at the previous pre tx level for a fraction of a second after ptt is released.

73 Alan M0NNB

[Christopher KB3CS]

i am aware of the differences in purpose in the use of the sound card. 

i am attempting to convey 'cheap' may be too cheap. 

lost interrupts, repeated glitching, and full-on USB interface lock up are terrible events to have to endure. worse for occurring during your QSO.

i am suggesting the use of an audio interface i have the pleasure owning, have put to the test, and have found worthy of my reliance.

furthermore, the suggested device has not been found wanting when used in any capacity by a fellow SDR constituency.

clear now, Sid?

  - 3g (base 19) -

[still have my USB and Firewire Behringers, and USB eMU audio interfaces around here somewhere]

On Tuesday, September 3, 2019 at 5:56:01 PM UTC-4, Sid Boyce wrote:

Hi Christopher,
DDC/DUC transceivers like HL2 only require a single cheap sound card
dongle to support Mic/Speakers.

RS-HFIQ/Softrock/UHFSDR, etc. rely on 2 sound cards, one for I-Q
processing and one for Mic/Speakers.
73 ... Sid.


On 03/09/2019 15:13, Christopher KB3CS wrote:
> having gone round and round with C-Media USB audio and others some
> years ago (all cheap), and with reference to the soundcard recommended
> for use with the HobbyPCB RS-HFIQ SDR, the StarTech 96 ksps USB audio
> device should provide far better results than the suggested Sabrent USB.
>   $26 at Walmart.com
> Â
> https://www.walmart.com/ip/StarTech-USB-Stereo-Audio-Adapter-External-Sound-Card-with-S-PDIF-Digital-Audio/35461503
>
>  - 3g (base 19) -
>

[...]

[Sid Boyce]

Quite clear Christopher though it's a problem I have not experienced.

My HL2 runs quisk at 384K samplerate on ODROID-C2 and ODROID-N2 and
cheap USB dongles, likewise with an ODROID-C2 and same USB sound dongle
in a  standalone HiQSDR at 960K samplerate. All using 7 inch LCD's.
root@hiqsdr64:~# lsusb
Bus 001 Device 006: ID 0d8c:013c C-Media Electronics, Inc. CM108 Audio
Controller
73 ... Sid.

On 04/09/2019 13:30, Christopher KB3CS wrote:
> i am aware of the differences in purpose in the use of the sound card.Â
> i am attempting to convey 'cheap' may be too cheap.Â

>
> lost interrupts, repeated glitching, and full-on USB interface lock up
> are terrible events to have to endure. worse for occurring during your
> QSO.
>
> i am suggesting the use of an audio interface i have the pleasure
> owning, have put to the test, and have found worthy of my reliance.
> furthermore, the suggested device has not been found wanting when used
> in any capacity by a fellow SDR constituency.
>
> clear now, Sid?
>

>   - 3g (base 19) -
>

> [still have my USB and Firewire Behringers, and USB eMU audio
> interfaces around here somewhere]
>
> On Tuesday, September 3, 2019 at 5:56:01 PM UTC-4, Sid Boyce wrote:
>
> Hi Christopher,
> DDC/DUC transceivers like HL2 only require a single cheap sound card
> dongle to support Mic/Speakers.
>
> RS-HFIQ/Softrock/UHFSDR, etc. rely on 2 sound cards, one for I-Q
> processing and one for Mic/Speakers.
> 73 ... Sid.
>
>
> On 03/09/2019 15:13, Christopher KB3CS wrote:
> > having gone round and round with C-Media USB audio and others some
> > years ago (all cheap), and with reference to the soundcard
> recommended
> > for use with the HobbyPCB RS-HFIQ SDR, the StarTech 96 ksps USB
> audio
> > device should provide far better results than the suggested
> Sabrent USB.

> >   $26 at Walmart.com
> > Â
> >
> https://www.walmart.com/ip/StarTech-USB-Stereo-Audio-Adapter-External-Sound-Card-with-S-PDIF-Digital-Audio/35461503
> <https://www.walmart.com/ip/StarTech-USB-Stereo-Audio-Adapter-External-Sound-Card-with-S-PDIF-Digital-Audio/35461503>
>
> >
> >  - 3g (base 19) -
> >
>
> [...]
> Â

>
> >
> > On Tuesday, September 3, 2019 at 1:38:31 AM UTC-4, Steve Haynal
> wrote:
> >

> >     Hi Robert and Group,
> >
> >     Do you see the same behavior with the stock gateware? I
> don't see
> >     this timing issue. The timing hangs of Taka's gateware may be
> >     different.
> >
> >     Although it is great to see experimentation, I want to
> share some
> >     details that may not be widely understood. There is no audio
> >     processing or final demodulation done on the HL2 or any
> other SDR
> >     implementing the openhpsdr protocol. All RX or TX data to
> or from
> >     the HL2 is in chunks of at least 48kHz of bandwidth. Alll
> >     demodulation (SSB, AM, FM, etc) must occur in software. If
> you
> >     trace the mic audio data:
> >
> >     Mic->HL2->48KHz to PC->Software Processing->48kHz back to
> HL2->HL2
> >     TX chain.
> >
> >     Likewise receive audio from the HL2 is
> >
> >     HL2 RX chain->48kHz to 384kHz to PC->Software
> Processing->48kHz
> >     audio back to HL2->Optional HL2 codec
> >
> >     As you can see from above, the HL2 is nothing more than an
> >     ethernet-based sound card when implementing audio in/out.
> You are
> >     better off using an $8 USB audio adapter
> >    
> <https://www.amazon.com/Sabrent-External-Adapter-Windows-AU-MMSA/dp/B00IRVQ0F8
> <https://www.amazon.com/Sabrent-External-Adapter-Windows-AU-MMSA/dp/B00IRVQ0F8>> or
>
> >     your built-in host computer audio. Handling the audio on
> the FPGA
> >     takes FPGA resources which can be better used for other
> purposes
> >     like more receivers. Given the commodity of existing sound
> cards,
> >     it makes no sense to me to duplicate this on the HL2.
> >
> >     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
> <mailto:hermes-lite...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/hermes-lite/bd100323-775b-486e-a3dd-835f156e6bf9%40googlegroups.com
> <https://groups.google.com/d/msgid/hermes-lite/bd100323-775b-486e-a3dd-835f156e6bf9%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Marty Wittrock]

Robert,

I'm interested in the the PTT/Serial board - let me know when they're available and cost + ship.

73 de Marty, KN0CK

[dick_...@hotmail.com]

Steve

Is there a system block diagram someplace on this site?  I think I saw one at one time - somewhere.

Something like the original Hermes Block diagram would be helpful for more than just the audio path(s)

Ref https://openhpsdr.org/img/Hermes-Hardware_Block_Diagram_V1_7.jpg

Also a question about the audio.  Using PowerSDR_mRX_PS_v3.4.9.0, I am using AISO drivers on a USB CMedia Pro device and I only hear mono left channel.  When I run Quisk  v4.1.43 I appear to be getting both channels in my headphones.  I wear hearing aids, but I like headphones with out the aids because the fancy digital ones do not work as well as my ears.  Is there a setting to mix the audio in PowerSDR or I could make a simple resistive combiner.  This is on an XP Pro system so far.  Will move on to Win7 later.

Dick K9IVB

[Christopher KB3CS]

thanks. yes, my experience was the cheap devices were better behaved with linux drivers. 'better' being a relative term, of course.

there were some devices with a C-Media chip which were just awful even with linux drivers. 

perhaps those have vanished from the market in the years that have passed?

however, there is the use case where the HL2 controller is PowerSDR. 

i learned not to trust windows drivers unless the USB audio device is a Behringer UCA202 or now the StarTech ICUSBAUDIO2D.

(or the sound card in the microHAM USB Interface III)

YMMV

  - 67 (base 11) -

On Wednesday, September 4, 2019 at 12:38:39 PM UTC-4, Sid Boyce wrote:

Quite clear Christopher though it's a problem I have not experienced.

My HL2 runs quisk at 384K samplerate on ODROID-C2 and ODROID-N2 and
cheap USB dongles, likewise with an ODROID-C2 and same USB sound dongle
in a  standalone HiQSDR at 960K samplerate. All using 7 inch LCD's.
root@hiqsdr64:~# lsusb
Bus 001 Device 006: ID 0d8c:013c C-Media Electronics, Inc. CM108 Audio
Controller
73 ... Sid.

[...]

[ROBERT ENTWISTLE]

Hi Marty,

Regarding the companion board. Here is what I bought and use to reprogram the FPGA memory: https://www.ebay.com/itm/altera-Mini-Usb-Blaster-Cable-For-CPLD-FPGA-NIOS-JTAG-Altera-Programmer-EC/362591376222?ssPageName=STRK%3AMEBIDX%3AIT&_trksid=p2057872.m2749.l2649 You might want to get one if you don't already have one.

Working hard on the companion board respin and making good progress.

73,

Robert, WA2T

--

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/44d6f2f1-0f06-4010-aaa8-9fd555e4fa18%40googlegroups.com.

 

[Sid Boyce]

I got mine about 5 years ago for the standalone HiQSDR and they just worked.

73 ... Sid.

On 04/09/2019 23:45, Christopher KB3CS wrote:
> thanks. yes, my experience was the cheap devices were better behaved
> with linux drivers. 'better' being a relative term, of course.
> there were some devices with a C-Media chip which were just awful even

> with linux drivers.Â

> perhaps those have vanished from the market in the years that have passed?
>

> however, there is the use case where the HL2 controller is PowerSDR.Â

>
> i learned not to trust windows drivers unless the USB audio device is
> a Behringer UCA202 or now the StarTech ICUSBAUDIO2D.
> (or the sound card in the microHAM USB Interface III)
>
> YMMV
>

>   - 67 (base 11) -

>
> On Wednesday, September 4, 2019 at 12:38:39 PM UTC-4, Sid Boyce wrote:
>
> Quite clear Christopher though it's a problem I have not experienced.
>
> My HL2 runs quisk at 384K samplerate on ODROID-C2 and ODROID-N2 and
> cheap USB dongles, likewise with an ODROID-C2 and same USB sound
> dongle

> in a  standalone HiQSDR at 960K samplerate. All using 7 inch LCD's.

> root@hiqsdr64:~# lsusb
> Bus 001 Device 006: ID 0d8c:013c C-Media Electronics, Inc. CM108
> Audio
> Controller
> 73 ... Sid.
>
> [...]
>

> --
> You received this message because you are subscribed to the Google
> Groups "Hermes-Lite" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to hermes-lite...@googlegroups.com
> <mailto:hermes-lite...@googlegroups.com>.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/hermes-lite/7212b883-8e0f-4b80-9e6c-f58818266f4e%40googlegroups.com
> <https://groups.google.com/d/msgid/hermes-lite/7212b883-8e0f-4b80-9e6c-f58818266f4e%40googlegroups.com?utm_medium=email&utm_source=footer>.

[Steve Haynal]

Hi Dick,

My guess is the PowerSDR or the VAC needs to be set to mono somewhere for both channels to work in the headphones. I haven't seen this problem.

There is an old block diagram for build2 attached. There is also a walk through and talk covering the HL2. See this thread for a link to the video as well as the slides:

https://github.com/softerhardware/Hermes-Lite2/tree/master/gateware/bitfiles

73,

Steve

kf7o

[Steve Haynal]

Hi Group,

I don't see the AGC problem. I regularly use WSJT-X with Quisk or SparkSDR. RX is always full strength after TX.

The USB Blaster clones can be a landmine. Some work and some don't. There are many threads about this over the past 5 years on this list. This is why the latest firmware uses network gateware updating. Anyone can do that without buying a programmer, and it works better. I recommend that Taka or someone add this feature to his gateware, or take the latest main gateware and add again Taka's enhancements. If Taka's enhancements can be added in such a way that a define or Verilog generate can turn them on or off, I am happy to include them in the main github. 

73,

Steve

kf7o

 

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

[rentwist]

Greetings All,

I have completed a HL2B8 (and what earlier versions I am not sure) compatible AK4951 Companion PCB and have ordered 20 of my design (only because I could get 4 on a panel and the order was still cheap with V-cuts to separate into 22.6mm x 64mm boards).

Looking forward to finishing the HW up and CNC front and rear panels to go with my version/vision as well.

73,

Robert, WA2T

[rentwist]

Hi Steve,

That's a wonderful idea regarding adding Taka's enhancements with switches to turn them on or off.  Unfortunately, I do not think I am the one to do this having no FPGA programming experience (but would love to learn).

I think I understood from Taka that the gateware is not commented so one (not familiar) could see what is being done in various parts of the code, is this true?  Taka indicated a large amount of effort was needed first to figure out what the code was doing and then to write his own code (to the tune of 1000 lines I think Taka said).

In any case, again, it would be wonderful if someone could merge Taka's enhancements into the current code base, it is what (with no knowledge of how hard this would be) I was pushing/hoping for at the outset of my HL2 adventures.  Whether or not Taka would or could or wants to entertain such an undertaking would be for him to decide/say.

Thanks and 73,

Robert

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

[rentwist]

P.S. I have not had a chance to try the current gateware for the AGC problem, I will try to do that.  Taka has sent me an updated version of his gateware where he has made changes to the PTT timing (my uneducated generalization of what he wrote in the message with the code he sent to me).

On Sunday, September 8, 2019 at 5:59:01 PM UTC-4, Steve Haynal wrote:

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

[Steve Haynal]

Hi Robert,

Just to make sure there is no misunderstanding, use of if/def or Verilog generates in the RTL means that Taka's enhancements can exist in the main code base, but still must be enabled and built separately. We couldn't turn the enhancements on or off dynamically in a single gateware since there is not enough room in the FPGA. But I would be willing to add targets to my Makefile so that when I build a release an additional gateware bitfile with Taka's enhancements is released with every release I make. I agree that Taka would be the best person to make these changes.

There are other disabled (since they are specialized are experimental) enhancements which exist in the RTL. For example the EER work or Alan's ADC distortion correction. These can be built with just a few setting changes. The goal is to try to capture all enhancements in the main RTL, and then users can build custom gateware images. 

73,

Steve

kf7o

[dick_...@hotmail.com]

Hi Steve

I think the Block Diagram attachment got lost

Dick

[Takashi K]

Hi all,

FYI.

I uploaded my new gateware on my git CTRX_HL2b5 branch. 

I think Low Rx sensitivity issue after transmit in CW mode is fixed. I changed the timing of PTT (C0 PTT bit on OpenHPSDR protocol) same as Hermes gateware v3.1. The uploaded gateware is not for Robert's designed new companion board. I will upload the gateware customized for it later.

Also I checked 20190907 gateware with piHPSDR in CW mode.  Low Rx sensitivity issue was reproduced.

> Taka would be the best person to make these changes.

Sorry. I have no plan to do that now. Because there is big difference between the current official code and old one that my gateware is based on, by refactoring. Merging needs much time to analyze the refactored code structure and modify. Of course, Steve's refactoring is very valuable and wonderful.

73,

Taka, ji1udd

[Steve Haynal]

The block diagram should be attached now.

73,

Steve

kf7o

[rentwist]

Greetings all,

My AK4951 Companion Board V3.0 boards arrived from China today and it just so happened that I timed it perfectly with delivery of my Digikey parts order as well.  Boards look good, built one up and tried it out, so far works perfectly.  Have not tried Hardrock-50 control or local mic but local speaker and headphones are working so I do not expect any problems (Taka-san's HL2B5 board works completely "haywired" into my HL2B8 so I am not expecting any surprises).

Having fun!  Albeit a "boutique" HL2 application, I am realizing what I envisoned for the rig and that is what it is all about.

73,

Robert, WA2T

[Takashi K]

Hi Robert-san,

Really nice board !

I have uploaded Companion Board V3.0 gateware on my git V3_Companion branch.

If you find any problems, please let me know.

73,

Taka,  ji1udd

[Paul Marbourg]

Hi Robert,

I would love to purchase one or two of your companion AK4951 PCBs, if you are making them available. 

If you have a copy of Taka-san’s BOM to include with the board, that would totally rock. Yes, I know I can probably pull the AK4951 BOM off of Taka-san’s GitHub branch. 

Thank you for your and Taka-san’s efforts to support “integrated” CW and audio codecking with the HL2.  

Personally, I feel the HL2 deserves better than being proscribed to life “in the back room” as Steve has envisioned.  I have worked the world with its 5 watts and a low 40 meter dipole using FT8 and Build 8. I have a Build 9 on order. 

Thanks!

73

Paul, WN7T

Sent from my iPhone

On Sep 8, 2019, at 7:48 PM, rentwist <rent...@comcast.net> wrote:

Greetings All,

I have completed a HL2B8 (and what earlier versions I am not sure) compatible AK4951 Companion PCB and have ordered 20 of my design (only because I could get 4 on a panel and the order was still cheap with V-cuts to separate into 22.6mm x 64mm boards).

Looking forward to finishing the HW up and CNC front and rear panels to go with my version/vision as well.

73,

Robert, WA2T

<HL2_Companion_V3.jpg>

On Monday, September 2, 2019 at 4:27:22 PM UTC-4, rentwist wrote:

Greetings all,

I had my first (CW) QSO with the HL2/HR-50 this afternoon, with a ham in Germany.  I was running about 40W.  I am using Taka-san's AK4951 companion board made to work with the HL2 and a custom version of Taka-san's gateware implementing a CW keyer on the HL2 CN4 CW Key/PTT jack.  The companion board also provides a local: Headphones jack, Speaker (controlled by the RX Random SW switch), a Microphone jack and control/bandswitching of the HR-50 using a DB-9 serial/PTT connection.  For the microphone I am using an Icom HM-12 hand microphone rewired to work with my KX3 (and now HL2).  I have not made a voice QSO but audio seems to sound good on a nearby transceiver.

Anyway, I noticed that the receiver seems to have low sensitivity for a short period of time after transmit to receive switch over.  That is, I did not hear the German ham well until maybe one second or so after I finished transmitting.  I am not sure what is causing this but was wondering if perhaps people have noticed the same thing.  It did occur to me that if the HL2 TX/RX was running full duplex (but I do not think it is), perhaps this could happen, a time delay for the RX to go from signal overload (from the TX) to receiving normally.

Any insight into this?

73,

Robert, WA2T

P.S.  Next I plan to design and build a version of Taka-san's companion board that will plug directly onto the HL2 DB1 and DB12 connectors and provide a HR-50 DB-9 serial/PTT connection.  If there is interest (please chime in), I can make more boards than I need (which would be only a few).

--

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/26bdcc4f-852b-4242-9bbe-dcb825a21f83%40googlegroups.com.

<HL2_Companion_V3.jpg>

[Takashi K]

Hi Robert-san and all,

I found that ADC1 overload indicator on PowerSDR did not work correctly.

It occurred by modification of LED function on 20190714 release.

I have updated Companion Board V3.0 gateware.

73,

Taka,  ji1udd

[Takashi K]

Hi Robert-san and all,

> It occurred by modification of LED function on 20190714 release.

Typo.

20190914 is correct.

And the updated gateware is 20190915.

73,

Taka   ji1udd

[Ron]

Hi Robert,

I would also like to purchase one of the companion AK4951 boards if possible.

I would like to make the Build 9 I have on order the complete daily use unit

Regards

Ron, G6BMY

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/4F2AF250-9456-4434-9379-8BBC5C828AC9%40gmail.com.

Virus-free. www.avg.com

[rentwist]

Greetings All (and Paul, Ron, Sven and Marty),

Thank you for your interest in the V3.0 AK4951 Companion Board  I had an inquiry from Sven off forum.

The board (and Taka-san's custom gateware) provide:

A CW keyer on HL2 CN4

CW sidetone in local headphones and local speaker

A headphones jack

A local speaker with 600 mW? output capability, good for a laptop type speaker.  Speaker (only) mute via repurposed RX Random SW button

A microphone jack suitable/configurable for dynamic and passive microphones

A Hardrock-50 power amplifier serial data and PTT connection via DB-9M

I need to lay out/explain a couple of things in the interest of each of your success.

First, yes, I can create either a BOM document or a sharable Digikey BOM.

The next few items each of you need to understand so you know what is required/what you are getting into.

1a.  To use the companion board and have the features it affords, the gateware of the HL2 must be changed to Taka-san's custom version.  Taka has made several revisions on my behalf, not the least of which includes the RX AGC after transmit issue that I recently discovered.  Taka's gateware is divergent from the current gateware and there does not appear to be a viable means to bring them back together currently.  As such, each version has its own features and is independent of the other.  Switching back and forth between Taka's gateware and the current (and future) gateware may be possible (likely?), if having 3.3V Vlvds would not be a problem (read more about this in #2 below).

1b.  As Taka-san's starting point for his fork of the gateware was around the time of HL2B5, the gateware update via Ethernet feature is not present.  As such, a USB Blaster II (or RPi - I personally have not tried this) is needed to do the gateware loading.

2.  There is one minor change on the HL2 board that is required for use with the companion board.  The HL2 FPGA IO Bank5 voltage (Vlvds) must change from 2.5V to 3.3V to match the AK4951 IO voltage.  To do this, FB28 on the HL2 board must be removed.  The companion board has its own ferrite bead (FB1) which ties HL2 3.3V to Vlvds.

3.  To build a companion board, one must be (very) comfortable with surface mount assembly.  The board uses 0603 surface mount components and is densely populated.  The kicker is the AK4951 is a QFN 32 leadless package with exposed (heatsinking) pad.  This IC can be very challenging to assemble correctly as the exposed pad must be soldered down but with a minimum of solder so that the IO leads do not end up accidentally shorted to the exposed pad.  This is similar to the HL2 AD9866 (but even more challenging), another QFN but larger and with more leads.  On four Radioberry boards I built, one had the problem I described above.  It was quite challenging to figure out and rework/remount the AD9866 multiple times in order to resolve the problem.

4. DB1 and DB12 need to be populated on the HL2 with twenty and six pin (respectively) double row 2.54mm spaced header pins to mate with the companion board CN1 and CN12 (which has female connectors of the same type).  A harness for the Hardrock-50 power amplifier serial/PTT DB-9M needs to be constructed.  On the companion board end, a four pin Dupont connector is used to mate with the four pin 2.54mm spaced header P2.  A speaker with two lead pigtail needs to constructed.  On the companion board end, a two pin Dupont connector is used to mate with the two pin 2.54mm spaced header P1

5.  A number of people who have expressed interest are asking for assembled boards (which is understandable in light of the above).  I am not opposed to providing assembled boards (for those who still are interested after having read the above!) but time is the problem.  As we get into winter I may be able to find the time.  Most of my ham radio operating and projects occur/make the most progress during winter (I live in the NE US).  During the rest of the year, life's demands make progress much slower than I would like.  As such I do not see myself being able to supply assembled boards until winter sets in.

6.  *I am uncertain if the policies of this forum allow monetary transactions to be discussed, please let me know if this ends up being a problem.*  For those wanting a bare board, I can provide them for $6.00 USD each including shipping to the lower 48 in a first class envelope (no tracking).  For international orders, the cost would be $5.50 plus the cost of letter postage.  For those wanting an assembled board, I envision being able to provide them (in the coming months) for ~$60 USD including shipping to the lower 48 in a first class padded envelope (with tracking).  For international orders, the cost would be ~$55 plus the cost of padded envelope postage,  Payment would be accepted by Paypal friends and family, 3% more if by regular Paypal payment.  Payment by means other than Paypal would be considered.  If this is your desire, we can discuss what works for you.

This is all that comes to mind currently, I will post further if I think of other considerations regarding the use of the companion board.

73,

Robert, WA2T

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

To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/26bdcc4f-852b-4242-9bbe-dcb825a21f83%40googlegroups.com.

<HL2_Companion_V3.jpg>

[rentwist]

To add a little more to the QFN 32 hand soldering details, a stereo microscope (what I use) or hi resolution camera (know others that like this method) is a must.  A heat gun is also a must to solder the exposed pad.  Very fine tipped soldering iron and liquid flux is needed to solder the very fine pitched, eight per side leads.  It is all doable but is a pretty specialized operation that may not be for everyone (most?).

On the board I just built (built Taka's HL2B5 V2 Companion Board before that), I lightly tinned the exposed pad and the 32 leads first.  Then, I applied water soluable flux to the PCB QFN 32 footprint.  Next, I positioned the part on the footprint (very difficult to get right).  Then I flowed the part down using the heat gun.   This is challenging in that depending on the gun used, the gun can blow the part away/off of its positioning.  After that, I hand solder the 32 leads to get proper filleted solder joints which are pleasing to the eye.

Please understand I am not tryjng to scare anyone off or dissuade them from board assembly (quite the contrary!  PLEASE assemble your own board ;-), but I want to do my best to inform/help prospective builders.

73,

Robert, WA2T

[Paul Marbourg]

Robert,

Even given all the warnings about assembly difficulties, I would love to give it a go. 

I am considering generating a silk screen mask for the PCB and using it for solder paste application and a toaster oven to make the parts dance into self-alignment as the paste melts. 

Probably it would work with sufficient resolution and precision in generating the silk screen. 

Thank you. 

73

Paul WN7T

Sent from my iPhone

--

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/03afd225-029e-492d-a5b8-8570c20bf435%40googlegroups.com.

[Takashi K]

Hi Robert-san,

I assembled Companion board V3.0 that arrived from you yesterday.
I soldered AK4951 using a normal soldering iron. Two 3.5mm jacks have not been installed yet as they are not in my stock.  So I connected a speaker to AK4951 SP output. Now I can hear receiver sound from the speaker.
I haven't checked the other functions yet, but it seems to work well.

73,

Taka,  ji1udd

[Bob A. Booey]

Hi Taka-san,

Great, glad to hear this!  I'll be interested to hear a full report once you have the jacks installed.

Just a note about the Mic Jack (J1), the PTT and Mic pins are reversed (the one mistake I made in the design of the board).  I came up with one way to correct this without cutting PCB traces, there are other ways I considered which would involve cutting traces.  Here is a link to a photo on my Github page for this board that shows my method of correcting the issue: https://github.com/WA2T/Hermes-Lite2/blob/master/CompBdMicJackMod.jpeg

For anyone else interested, here is the Github page itself: https://github.com/WA2T/Hermes-Lite2

73,

Robert, WA2T

--
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/255e11e7-2abf-4aae-a391-235ed436729c%40googlegroups.com.

[Takashi K]

Hi Robert-san,

Thank you for your information. It is not so serious for me. In my case, it will be matched with the wiring on the microphone assembly side.

73,

Taka, ji1udd

[Takashi K]

Hi Robert-san,

I have finished to check the full function of companion v3.0 board.

HR-50 Band/PTT control, Microphone/PTT input , HeadPhone output, all functions work well.

Nice!

73,

Taka,  ji1udd

[ROBERT ENTWISTLE]

Hi Taka-san,

This is great to hear, thank you for your validation of the design/board in such a short amount of time! I am very happy with what we have achieved together and I sincerely THANK YOU for everything you have done.

I will be making end panels for a 40mm high extruded case using my CNC machine to machine the holes and to make engraved lettering. I plan on using a small piece of aluminum bar stock to make a bracket to support the companion board using the large hole near J1. The bar stock will allow fastening of the PCB to the side of the enclosure.

Again, if you ever want or need another Companion Board V3.0 PCB, please let me know.

Thanks and 73 my friend!

Robert, WA2T

--
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/bf7e694f-cda8-4145-a44d-91cc77d91e0e%40googlegroups.com.

 

[ROBERT ENTWISTLE]

Also, I am very happy with CW operation. With 150mS break-in time set, the HL2 is closer to QSK than any non-QSK radio I have operated with. TX/RX turnaround with your latest tweak of your gateware is now very fast. Awesome!

On September 30, 2019 at 8:24 AM Takashi K <tak.k...@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/bf7e694f-cda8-4145-a44d-91cc77d91e0e%40googlegroups.com.

 

[Takashi K]

Hi Robert-san,

Thank you for sharing your ideas about mounting brackets and your feedback about my updated gateware. Actually I was wondering how to use the mounting hole. I also think that CW operation has improved very much. Thanks to an excellent beta tester, Robert.

> if you ever want or need another Companion Board V3.0 PCB, please let me know.

Thanks. I think that Companion Board V3.0 is an inexpensive and compact board that can be used for even other experiments. Only soldering is a challengeable ;)

73,

Taka,  ji1udd

[rentwist]

Hello Group,

Six bare PCB's have been sold and I will build complete boards for another two hams.  After these, I will have twelve boards left from what I had made.

Here is another build guidance note.  I did not make board edge cutouts for J1 and J2 because I believe complicating the board edge shape would have driven the board cost up.  Instead, I relieve the bottom of the PJ-307 jacks (or equivalent, PJ-307 is one the inexpensive Chinese versions) per this drawing I annotated:

The file can be found in the Companion Board V3.0 respository as well: https://github.com/WA2T/Hermes-Lite2/blob/master/PJ-307.jpg

73,

Robert, WA2T

[rentwist]

Correction, I will have ten boards left, I'll keep one more PCB for myself beyond the one I built up.

[rentwist]

Six boards left.  Thanks for the interest guys!

73,

Robert, WA2T

[rentwist]

Hi Group,

These things are flying out the door!  Two boards left.  I may have to do another run of 20 (or more)!

73,

Robert, WA2T

[rentwist]

Guys,

I have to ask, what is your main reason/interest in the AK4951 Companion Board V3.0?  I'm guessing it is the HR-50 control but I'd like to hear from you.

For me it is all of the above but that is because I am a CW op.

73,

Robert

[Nigel Head]

I'll kick off the response to reasoning...

I ordered the board mostly because of the interfacing to the HR-50 (which I also have) and it's ability to instruct the HR-50 to 'follow me' when band changing.

I also use the HR-50 with my FT-817, so not having to modify it to suit the HL2 is a bonus.

I just wish that the standard gateware/firmware did this rather than a customised version as I will forever have to use a 'non standard' version for the HR-50 and will have to rely on the ability of others for that (for which I am grateful).

Maybe Steve could consider adding the ability of the HL2 to work with external amp's (such as the HR-50) in standard gateware (just my personal wish list).
I wish I was smart enough to do it for myself, but alas these old grey cells aren't up to it !

Nigel - G4ZAL

[Jim Ancona]

I have a solution that works for me using the stock gateware and an Arduino Uno. I basically implemented the approach I asked about here[1]. It uses the filter configuration to determine which band is selected on the HL2 and uses that to set the Hardrock band. I'll try to put together a write-up in the next few days and post a link here.

Jim

N1ADJ

1 - https://groups.google.com/d/msg/hermes-lite/hHpBbzo2tGg/FR5NN2qgAwAJ

--
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/6c123ac5-4405-459c-80f2-a17c21d7c336%40googlegroups.com.

[Steve Haynal]

Hi Robert and Taka,

I am not happy about the proliferation of your project which requires a fork in the gateware. It makes it much harder to explain to people exactly what the HL2 is, and also to support as some functionality (or bug) appears in one gateware but not the other. This creates a mess which others (mainly me) then have to deal with. The proper way to add functionality to the HL2 is to make changes to the RTL that are conditioned by a define or generate variable so that they can be turned on or off, and then issue a pull request via github. I will then incorporate changes into the main fork and also build and release extra variants of the gateware that have this functionality turned on. Since all versions of the gateware will then have the network update functionality, people can easily switch between variants. It is not an acceptable reason to say "it is beyond our control and not easily unforked." Please take the time and develop the understanding to do this properly.

73,

Steve

kf7o

On Tuesday, October 8, 2019 at 7:44:45 AM UTC-7, rentwist wrote:

Hi Nigel.  I too have grappled with the forked gateware but it is something beyond our control and not easily unforked.  Having said that, I feel I must have the features that the HL2 Companion Board V3.0 and Taka-san's gateware provides.  It is perhaps a small consolation, but Taka-san has been VERY responsive in making changes to testing observations I have made and even things that border on feature requests (but I am not attempting to sign Taka-san up for more coding work!).  The latest changes Taka has made (overnight last night in fact) made a change so that the CW keyer works only in CW modes.  Previously, the CW keyer would work in any mode (but not transmit in anything but CW modes).  Also, the straight key mode was not working.  Taka came up with an innovation here, he has made the SKM work but using the dash input (which is non-standard for a straight key plug).  The reason he did this is he made the dot input still work in the SKM.  The result is an electronic bug, pretty neat!  But I digress.

Thank you for your reply to the question.

73,

Robert, WA2T

[rentwist]

Hi Steve,

I cannot speak for Taka-san but I can speak for myself.

I apologize for whatever part I may have played in this.  I am more of a hardware guy and do not know much more than (or perhaps even) "the first thing" about FPGA coding.  As I have described previously, I have a certain use case for the HL2 and have run with what I found available to make that use case work.

The fact is that I (personally) am currently unable to "take the time and develop the understanding to do this properly".  I would not know where to start nor do I have the time I believe it would take.  Further, it appears (to me) that the resources to effectively do this are not available in a form I am able to digest.

The "proliferation" of the project shows there is interest and that interest is showing signs of popularity.  To me, this indicates there is demand for certain features.  I apologize if those features do not align with your vision for the HL2.

73,

Robert, WA2T

[Steve Haynal]

Hi Robert,

I work professionally with RTL and other code development. It requires proper forward thinking, organizing and planning to make a large project a success. Sometimes this comes off as arbitrary. If you don't know about RTL coding, then I would recommend not promoting a fork as a hack to get what you want. It is true that I do not like the local audio functionality in this board. But I am willing to build and release gateware variants with this functionality for those interested. My goal is to have all interesting functionality in the main fork, but added in a sensible and maintainable way. Others have done that.

Sorry if this sounds harsh, but I am going with my experience and gut here on how make large code projects work.

[Steve Haynal]

Hi Robert and Taka,

Here is how I see this can move forward. Please suggest other ideas.

1. Integrate the HR50 support, Keyer and Audio Codec as three optional additions to the latest master github code repository. It should be possible to enable or disable any of these three with generate variables or defines. Create a github pull request to me to merge these changes. I will merge them and start build and releasing gateware variants with these changes.

2. Integrate the latest ethernet gateware update mechanism in Taka's fork. At least there would be a common method for people to switch between gateware variants.

3. Stop promoting the new board and fork to a wide audience until 1 and/or 2 are completed. Feel free to discuss your work in this group, but don't position it as something to share with dozens of people until 1 or 2 are done.

4. Make your work an entirely new project and start a new group/list with associated infrastructure.

73,

Steve

kf7o

[Steve Haynal]

HI Group,

I have been having some offline conversations about this. Now that almost 20 boards have been spoken for, I am worried about support of two forks and the mess it entails. I  am moderating Robert and Taka's posts, and have asked them to figure out how to reconcile their gateware with the main branch before continuing with this companion board. Robert asked to be told several weeks ago if selling boards becomes a problem, and now I think it has given the gateware forks.

I've said this in the past, but please remember that this project and group are not a democracy. I run this group and project as I see best, and have been doing so for 5+ years. Take a look at what Linus Torvalds does and the reputation he has for Linux, yet it is a very successful project.

https://www.computerworld.com/article/3004387/how-bad-a-boss-is-linus-torvalds.html  

Sorry if this seems harsh, but I really think we need to merge the gateware. 

73,

Steve

kf7o

[Jonas Sanamon]

Hi Steve,

I think that even if this call may seem hard to some, and some may even perceive it as unfair, I fully believe it is the kind of call we can look back on in 5 years time and say it was a really good one. Or perhaps more the opposite; a call we would regret not taking now, in 5 years, if we didn't take it now.

What you're demonstrating here is a skill that's in my opinion not so often found; the ability to have full control of all the bits at the lowest level of a project, and at the same time have the ability to take the helicopter view and look at the big picture also in a long time perspective. Respect!

@Robert & Taka-san, I also understand that your goals are probably different than Steves in some ways, and I'm impressed with Your skills!  However, I'm certain that what Steve proposes is the right thing to do, and something that would actually benefit everyone (including You in the long run) if You are able to find a way to re-merge the fork.

Respectfully,

Jonas - SM4VEY

Best Regards,

Jonas

[Nigel Head]

I guess that what we are seeing here is the gaining popularity of the HL2 project and the fact that some of us 'wish' for some extra/different functionality over what is currently available.

Currently I only wish for the control over my HR-50.

I do agree that it is best for one gateware, but surely that shouldn't stop anyone from developing something, and then, if successful and approved, being merged into the 'standard'.

Steve,

Is it at all possible for some kind of 'configurator' for gateware?

That is, the user selects from certain available options/functionality and then the appropriate gateware is generated for them?  Just thinking out loud.

I think you have made it pretty clear that HL2 is 'not a democracy' but that you are at least listening to the wishes of others.

Please keep listening and demonstrate that your rod of iron is a little bit malleable !

Nigel.

[Mathis Schmieder]

Dear Nigel,

I think Steve is listening quite carefully what a lot of people would like to see in the HL2. And while I myself very much would like to be able to control my HR50 directly with the HL2 and was very close to pulling the trigger on a set of interface boards, I held back because of the need for a forked gateway. It's totally understandable that Steve wants the functionality merged into the "mainline" gateway code instead of developed on a fork and I'm quite confident that we'll see a merged/configurable gateway in the future!

At no point (to my understanding) did Steve say he won't accept merge requests, he just doesn't want a fork of the project under the same name!

Best 73s,

Mathis, DB9MAT

[Christopher KB3CS]

a 'duino Feather might be a very fine choice for a HL2<->HR-50 interface.

  - 1k (base 53) -

On Wednesday, October 9, 2019 at 7:15:01 AM UTC-4, Mathis Schmieder wrote:

Dear Nigel,

I think Steve is listening quite carefully what a lot of people would like to see in the HL2. And while I myself very much would like to be able to control my HR50 directly with the HL2 and was very close to pulling the trigger on a set of interface boards, I held back because of the need for a forked gateway. It's totally understandable that Steve wants the functionality merged into the "mainline" gateway code instead of developed on a fork and I'm quite confident that we'll see a merged/configurable gateway in the future!

At no point (to my understanding) did Steve say he won't accept merge requests, he just doesn't want a fork of the project under the same name!

Best 73s,

Mathis, DB9MAT

[...]

[Takashi.K]

Hi Steve, Robert-san and group,

I'm really worried about spending much time in porting.
If it is gateware before refactoring, I do not worry at all.
Porting to current gateware after refactoring is very difficult.
Some modules no longer exist.
maybe they are replaced to another coding, I think.

So my idea is,
Robert-san once stop selling V3 boards, and users who have already
purchased V3 boards should use my customized gateware, and
I want to confirm the significance of porting from user's feedback.

73,
Taka, ji1udd

[James Ahlstrom]

Hello group,

I have some experience with this. About ten years ago I wrote the firmware for the HiQSDR. Someone started a fork with additional features. This created a mess. Features would work with one but not the other. Directions on the Internet were correct for only some versions. Gradually people wrote new radio software for the new features and compatibility was lost. Confusing discussions on newsgroups degenerated into how to make someone's cheap eBay dongle flash the firmware. Don't go there.

Steve is being very nice about this. I am not so nice. If you are not prepared to design a compatible architecture for added features do not write any firmware at all.

Jim
N2ADR

[Steve Haynal]

Hi Group,

Here are a few comments.

** Nigel suggested a "configurator." The Verilog generate variables and `define I proposed are essentially that. They allow the gateware to be built with different options turned on or off. As I said before, I would like the HR50, CW and Audio options added to the main repository but guarded with such configurator variables. I am willing to release gateware variants with these options turned on. Some of the options, like the HR50 support, could eventually be enabled in all gateware over time. The Linux kernel has many such "configuration" options, but at least there is one kernel maintained.

** Taka points out that porting the changes is a lot of work. I agree given that the main branch is now 137 commits ahead of his branch. Before the refactoring, an ADC predistortion option was added. This was done via a github pull request or patches sent directly to me. It was done with "configurator" variables so that it could be turned on or off. During the refactoring, I found it painful and extra work to try and keep that option, but I did. I may have made one or two minor mistakes during the refactoring, but the core of the option is still there and should be relatively easy to turn on again. Over the years I have made it clear in this group that a github pull request is the way to have RTL changes included in the main branch. I will add a wiki page that emphasizes this. Taka didn't do this and so his changes were lost over time and now it is more work to include them. 

** I agree with Jim. He provides a real world experience. He has done a lot of code development, both software and RTL, over the years. He has a PhD in Physics. There are people on this group at many levels, but we are fortunate to have some very experienced and talented people like Jim on this list. Those less experienced than Jim should listen carefully and respectfully and learn. I have over two decades of software/RTL experience in industry with large projects and a PhD in electrical and computer engineering. So people should listen to me too. ;)

** At this point, I consider Taka's gateware (137 commits behind main) and the hardware board Robert has made a different project. I think they should start their own Google Group or other group and give their project a unique name, for example Hermes-Lite 2.0 plus CW3. This way there is a clear distinction between projects, and where people should go for support. This is less than ideal, but at least there is a place to send people when the inevitable confusion arises. I don't see this as a drastic move as Google Groups are free and easy to start. I belong to several. I will refer people to this group if CW or HR50 needs are unmet by the main gateware. I will provide a link on the wiki to their fork. My first choice still remains incorporating the new options directly into the main gateware, but Taka and Robert are unwilling or unable to do that.

73,

Steve

kf7o

[Matthew]

I am sat here listening to my HL2 with linhpsdr, what a pleasure it is. When I consider the progression of ham open source SDR technology, the individual drive of Steve has got us to a *really* good place with the HL2 and the range good software that supports it. I've quietly sat in this group since the very early days. Since the outset and through the decisions, Steve has been very clear this would be an open source project, FPGA IP has been rejected on these grounds. Open source means anyone can contribute and understand both hardware and software aspects of this project. Nothing is hidden, nothing is impossible. To code the FPGAs, design the boards and then have the patience to organise all the group buys is a *huge effort* sustained over a number of years. As far as I'm aware all this fits around his work and family life. I frankly see it as unreasonable for people to expect Steve to bring other peoples forked versions of the gateware into the main branch when so much refactoring is required.

FPGAs can seem an incredibly daunting thing on first approach. However, there is a ton of information on the internet. Lots of free books, tutorials, and some very powerful tools provided by Altera for free use. I taught myself through this route and yes some days I felt like I was going backwards, but I learnt a lot. With some careful thought and understanding the requests people are asking for HR-50 are perfectly doable. You will learn a lot and might actually enjoy it? If FPGAs are too much, anyone capable of getting a ham licence must be capable of getting an arduino to perform this task.

There are so many examples of projects getting into a mess with different versions. This doesn't help anyone and will only increase these exact problems in the future. As a CW only OP with an HR50, I fully support Steve's approach to this matter.

73 de Matthew M5EVT (CEng and PhD).

[Graeme Jury]

Hello Group,

I feel that I can make a relevant comment as I have been through the HiQSDR, ghpsdr3 and now the HL2 variations. In each case I have gone back to the originals and stayed with the author's development - believe me it is the best way as many of the forks have just died away while the original is still going. I would suggest that the group could look at sub projects like interface boards and the like for tasks like controlling HR-50's which Nigel needs. It would be trivial for someone able to program a microprocessor to effect the switching. It simply needs the I2C bus, power and PTT brought to something like a DB9 socket on the back of the HL2 which can plug into say an Arduino interface in a small die-cast box and all the control lines brought out through isolators. No changes to firmware, only a few dollars and a few fun evenings building it also people with different amplifiers can adapt the interface for their needs. Steve can be left to get on with the fine tuning of the firmware.

73, Graeme ZL2APV

[Takashi.K]

Hi all,

I'm getting think that it is better "not" to merge gatewares.
Steve's policy and our project is really opposite.
I think that it will not go well even after merging.
and it ’s better to shift to another place.

73,
Taka ji1udd

[Alan Hopper]

Hi Taka,

I do understand your position but I would be sad to see you move, I've enjoyed and learnt a lot from your contributions over the years.  It is unfortunate that the gateware has changed so much since your mods and I realize it is not a trivial task to merge.  Steve's current firmware has a lot of features that I'm sure would benefit your version, the ethernet download is particularly useful to me as it makes testing my software over different gateware releases very easy.  I hope we can find a way to merge your work, perhaps there is someone out there looking for a fpga challenge.

I also understand Steve's position and from the perspective of supporting software I'd much prefer a single version. 

73 Alan M0NNB  

[Steve Haynal]

Hi Taka,

Yes, thank you for all your contributions. In hindsight I wish I would have encouraged (or pestered) you more to add your gateware changes to the main branch when they were fresh. I hope that eventually the main gateware will have better HR50 and CW support, and I will refer to your fork if I do work in those areas. I am also very pressed for time.

After the refactoring, the gateware is much easier to work with. This is not just my opinion as I have been told this privately by some who work on the gateware. There is less correspondence with the original Hermes RTL, so it is harder to just pull pieces from that code base. But the new organization has better structure and makes it easier to add functionality. Even the audio upstream/downstream is stubbed out for possible use.

73,

Steve

kf7o

[rentwist]

Hello Group,

I would like to announce the formation of a new forum, a fork of the Hermes Lite 2 called Hermes Lite 2 Plus.  The starting point design will include my Hermes Lite 2 Companion Board V3.0 and Taka-san's latest gateware (10/08/19) for the HL2 and the companion board (what you have seen here up until now).  The forum is co-owned by Taka-san and myself.  The description of the forum is as follows: "A fork of the Hermes Lite 2 SDR which promotes democratically determined desirable features, community involvement and furthering of the Hermes Lite architecture and capabilities."  All like-minded hams are welcome.

https://groups.io/g/HermesLite2Plus

Thank you and 73,

Robert, WA2T and Takashi, JI1UDD

[Takashi K]

Hello Steve,

Today I have finished to implement local audio and CW sidetone, etc functions for AK4951 companion board v3  into your main gateware 71p3. 

So I have a question. Is it possible to merge my code into your main gateware ?

This time, I used compiler directive 'ifdef to have compatibility with the current main gateware.

73,

Taka,  JI1UDD

[Steve Haynal]

Hi Taka,

This is great news! Thanks for your work on this. I am sure people will appreciate it. Yes, you can merge your changes into the main github. Here are some options:

** Issue a pull request. See this tutorial. This is the standard github mechanism.

** Make your changes visible in one of your gihtub forks, and I will complete the merge.

** Tar up your code and send it to me directly. I will need Hermes-Lite2/gateware/rtl and possibly Hermes-Lite2/gateware/boards and Hermes-Lite2/gateware/variants depending on where all your changes are.

73,

Steve

kf7o

[Takashi K]

Hi Steve,

Thank you for your acceptance.

I uploaded my code to ak4951v3 branch on my git and  issued a pull request.
If any problems, please let me know.

here is a simple explanation.

<  code changes >

1)  created hl2b5up_ak4951v3 folder in variants folder (copied hl2b5up_main) 

    and modified all files except Makefile

    hermeslite.qsf has

      set_global_assignment -name VERILOG_MACRO "AK4951=<None>"

  

2)  created hl2b5up_ak4951v3 folder in boards folder (copied hl2b5up)

    and modified only timing.sdc.

3)  put localaudio folder into rtl folder

    there are i2s, sidetone and the related files in this folder.

4) the following rtl files were modified

      control.v  fifos.v  hermeslite_core.v  i2c.v  i2c_bus2.v

      usopenhpsdr1.v

< AK4951v3 variant function >

  AK4951v3 variant supports AK4951 Companion Board Version 3.

  main function

   - local headphone (stereo) and speaker output (monoral)

        both are for hearing receiver audio and cw sidetone.

   - local microphone input (monoral)

   - external PTT input

   - Hardrock-50 control (BAND and PTT)

  software controllable function using openHPSDR protocol

   - Speaker On/Off : re-used "Dither"bit

   - Mic boost

   - CW sidetone frequncy

   - CW sidetone volume

  regarding i/o assignment, please refer to the attached file.

73,

Taka,  JI1UDD

[rentwist]

This is great news indeed, thank you VERY much for your efforts Taka-san!

73,

Robert, WA2T

[Steve Haynal]

Hi Taka,

Thanks for the pull request. I have accepted it. I did make changes from preprocessor ifndef to Verilog generate partly to help me understand your changes and also since I prefer that coding style. I still need to look at your i2c changes. I hope to fully review all your changes and make sure I have not broken anything by this weekend, and then will release a gateware build for your variant. I did notice the following:

** You are using the openhpsdr keyer but I remember you have your own keyer. You are welcome to add your own keyer. If you have a similar interface as cw_openhpsdr, it can be CW option 3 in the generate statement in control.v.

** I inverted the TXD output of ExtAmp to work with the new level shifters. I added a generate so that this is not inverted when built for your variant.

** Is the mic data correct for all receiver bandwidths and number or receivers?  The data rate through usiq_fifo will change depending on the number/speed of receivers, but the mic rate remains constant. Maybe it works but there can be wasted space by mic samples at high receiver speeds? This might be a place to find future RAM savings if needed.

** The new resource-saving NCOs enable you to have 4 receivers even with your additions.

I have sent you an invitation to be a github collaborator. This will allow you to commit changes to the main Hermes-Lite github repository without my involvement. Johan from radioberry plus a couple of others are collaborators. This is nice as you can easily and quickly make changes and fix bugs that affect your variant. Please discuss with the group if you plan to make changes that affect all variants.

73,

Steve

kf7o

[Takashi K]

Hello Steve,

Thank you so much for taking your time to merge my code.

> I did make changes from preprocessor ifndef ...

I thought it was easier to understand my changes using ifdef, but I will use parameter instead next time.

> I still need to look at your i2c changes.

It seems that software controllable function works well in my check.

> You are welcome to add your own keyer.

Thanks. But openhpsdr keyer is better than mine as it has full functions.

>  I inverted the TXD output of ExtAmp to work with the new level shifters.

The HR50's TXD polarity can be changed in its settings menu.

I've also heard from a user that the polarity should be reversed.

So It would be better if the polarity and baud rate settings could be saved  to EEPROM.

> Is the mic data correct for all receiver bandwidths and number or receivers?

I usually use PowerSDR. When I tested with 2-receiver and 192ksps setting, mic data was correct.

When 384ksps, both VAC and local audio receiver sound were broken. I guess it's another issue (CPU power?).

> This might be a place to find future RAM savings if needed.

sounds reasonable. but I have no idea now.

> The new resource-saving NCOs enable you to have 4 receivers even with your additions.

Your new NCO is very compact. nice !

> I have sent you an invitation to be a github collaborator.

I accepted your invitation. I will maintain my code part at least.

73,

Taka,  JI1UDD

[Takashi K]

Hi Steve,

> > Is the mic data correct for all receiver bandwidths and number or receivers?

> I usually use PowerSDR. When I tested with 2-receiver and 192ksps setting, mic data was correct.

> When 384ksps, both VAC and local audio receiver sound were broken. I guess it's another issue (CPU power?).

Today I used my newer PC (Ryzen5 Pro) instead of my old Core i5 PC, then the issue was solved. and mic data was also correct. 

I wanted to test more receivers, but I could not find the suitable SDR software.

( I tried the latest linHPSDR (I compiled the latest source files) but I felt it has still buggy)

73,

Taka,  JI1UDD

[Steve Haynal]

Hi Taka,

I looked at the mic samples saved in the FIFO more carefully today and I think it is correct with many receivers and various bandwidths. It is also a good straightforward solution. Only 82% of the memory resources are used, so there is no need right now to optimize. I do think that with many receivers and high bandwidth, the same mic sample is saved in the FIFO 16 or more times, but used only once as it should be when sent to the PC. There are possibly future savings here.

With PowerSDR, you should also be able to stitch receivers together for more visible bandwidth. 4 receivers can be 2 768kHz receivers.

For multiple receivers, I mainly use Quisk and SparkSDR. I haven't had issues with breaking sound on my midgrade PC.

You might consider M5EVT's fork of linHPSDR for the HL2: https://github.com/softerhardware/Hermes-Lite2/wiki/Software#linhpsdr

I was able to open 4 receivers with that.

One person told me that one of your gateware releases for PureSignal had the expected 4.08 setpk level. Would you share how you achieved this?

73,

Steve

kf7o

[Takashi K]

Hi Steve,

Thanks for your check and information.

I checked stitch receivers with PowerSDR,  the receivers and mic seem to work well.

I will check more using M5EVT's fork of linHPSDR later.

> I do think that with many receivers and high bandwidth, 

> the same mic sample is saved in the FIFO 16 or more times, 

> but used only once as it should be when sent to the PC. 

> There are possibly future savings here.

Yes, that's right. 

But I felt saving LEs is more important than saving memory at this moment.

Of course, the main reason is that the current code is simple.

> One person told me that one of your gateware releases for PureSignal had the expected 4.08 setpk level. 

> Would you share how you achieved this?

I have forgot the detail, but I think that I only adjusted receiver signal level to match Hermes.

Please refer to the attached PDF.

73,

Taka,  JI1UDD

[Steve Haynal]

Hi Taka,

Thanks for sharing your PureSignal changes. I suspected it was related to gains in the DSP path. I also suspect you were able to match Hermes exactly since the older gateware still used the Coridc. The Cordic has about 1.647 gain while the new NCOs and mixers have unity gain. It is about time I review the entire DSP path and make sure signals are utilizing all bits. I'm not sure how important it is to match the Hermes exactly here since it will be harder to match given no 1.647 Cordic gain, but we can make sure the DSP path is optimized and all gains are reasonable.

73,

Steve

kf7o

[Takashi K]

Hi Steve,

OK. It seems that it can be solved by updating the coefficients of the FIR filter.

73,

Taka,  JI1UDD

[Steve Haynal]

Hi Taka,

I did consider this but some coefficients will overflow 18-bits when multiplied by 1.647. We can probably get closer to X 1.647 though. I'd rather just make sure the DSP chain is optimized (max amplitudes occur at each state to use all bits, etc.) than try to target matching the Hermes. Reid has made changes to his PowerSDR fork for Hermes-Lite 2.0 so that it does not require this number to be .408. Matthew's LinHPSDR should be adjustable too. I still want to contact Warren to understand just how important this number is.

73,

Steve

kf7o

[Takashi K]

Hi Steve,

I understood. I feel that PS performance degrades when the signal level is low (the dynamic range is narrow).
But I don't know how much.

73,

Taka,  JI1UDD

[Steve Haynal]

Hi Taka,

Noted. I will try to make sure the dynamic range is maximized and the setpk value is increased the next time I clean up the DSP paths.

73,

Steve

kf7o