Assessing the need for front-end bandpass filters

[irbsu...@yahoo.co.uk]

Hi,
I now have a selection of bandpass filters including a nice Dunestar set (now I have fixed it!), and would like to carry out some on-air tests to help determine what difference bandpass filters will make to the receiver.
Here in the south of the UK I have very strong local MW transmitters that are a real test of IP2 performance with IMD products falling in the 160m amateur band.
What I would like to do is make a note of the ADC dBFS level with and without various filters. This will help define the number and specs.
If I could extract wideband adc data I could do it mathematically but it would be better to actually do a live test.
So my question is: do we have any software that can display the ADC dBFS level accurately?
Could QUISK or Spark be easily modified?
Thanks,
Andrew
G4XZL

[Alan Hopper]

Hi Andrew,

sorry I meant to add this ages ago when you first mentioned it.  I could not decide how to handle the dc offset on the adc, this matters for low readings to be accurate but then raises the question as to what value to use for the full scale value, if there is a standard approach or you have a preference let me know, otherwise I'll pick whatever appeals at the time.

73 Alan M0NNB

[in3otd]

Hello,
I had in mind to do something similar, recording the noise floor every second or so with and without a bandpass filter switched in, should not be too difficult to have all this automated and record the noise floor over the day to see if and when the bandpass filter makes a difference. I thought that in general the IMD will appear as an increased noise floor, if caused by several strong signals over a large bandwidth.
Quisk currently does not handle the wideband ADC data, I did a quick hack to extract and show them on the time-domain scope some time ago but we should probably convince Jim to add the proper code to Quisk, hi.

Alan, I saw that the ADC DC offset can change a lot between gain steps, IMHO if you show the ADC "dBFS" reading this should include also the DC offset, otherwise if you remove it from the data one could wonder why the ADC clips at less than the maximum code.

73 de Claudio, IN3OTD / DK1CG

[Alan Hopper]

Claudio,

  so simply 20log(max(2048/abs(adc))) over some time period? I guess this is a good measure of how close to overload we are which is what we are after, it will be a bit odd at low levels but only if thought of as a signal strength meter.

73 Alan M0NNB

[Alan Hopper]

or even 20log(max(abs(adc)/2048)) 

[James Ahlstrom]

Hello Andrew,

On Wednesday, June 21, 2017 at 5:18:07 PM UTC-4, irbsu...@yahoo.co.uk wrote:

What I would like to do is make a note of the ADC dBFS level with and without various filters. This will help define the number and specs.

Quisk currently does not keep the raw ADC data.  I could add this.  But even if I do, I question whether it would be useful to test IP2.  The ADC is linear up to clip.  Non-linearity could show up as an increased noise floor.  Or a couple of unfortunate signals could mix to in-band even if the ADC is not at a high level.  A better test is to observe a wide piece of the 160 meter band (for example) and add the filter to see if it causes the in-band noise level to drop, or spurs to disappear.

Jim

N2ADR

[in3otd]

On Thursday, June 22, 2017 at 11:18:50 AM UTC+2, Alan Hopper wrote:

or even 20log(max(abs(adc)/2048)) 

yep, this is what I think gives the right "dBFS" reading. As you said, this would be an "ADC level meter" not an "input signal level meter", due to the DC offset.

[Graeme Jury]

In this thread on 9/13/16 headed "OK Steve, here are some simple test results." I published some basic tests done on 30 Metre band showing the effect of just Hi Pass filtering with a 60 MHz roofing filter and band pass filtering with a Mesh filter vs no filtering. I have exceptional noise from a nearby 15 Kw broadcast source and the screenshots show the very big improvement the filters give.

73, Graeme zl2apv

[irbsu...@yahoo.co.uk]

Hi Jim, Alan, Graeme,
Regarding the dc offset - yes it must be included, I would have thought that the effect would be small compared to full scale, do you have an idea of the difference it will make by including it?

Basically what I am trying to do here is get a metric on the highest LNA gain that can be tolerated before ADC clipping with and without various filters. I'm not specifically looking at IP2 although we know the receiver is not particularly good in that respect. I only mentioned it really as a comment about the strong local broadcast and what it does to poor receivers, or actually even good receivers!
Having the dBFS value allows other measurements like rising of noise floor to be referenced back also.
HDSDR has one now and I find it quite useful.

Graeme, thanks for the link, very interesting, here too if you had a dBFS value would have been useful as it would give you a figure for the improvement the filter gives.

One last comment, I do realise that every QTH will be different depending on antenna and local transmitters but I still think the information would be useful guide for people, and perhaps others could do similar tests.
Andrew
G4XZL
G4XZL

[Alan Hopper]

Andrew,

version 0.151 http://www.ihopper.org/radio/hlradio_0_151.zip now has the dBFS meter. It is the peak over a few seconds.  The raw adc data is a small sample so can miss peaks that the fpga spots so you might see the overload red block flash without dBFS going to 0.  I could force it to zero on overload but I'm not sure that is useful.  At some point it would be good to add a peak reading to the fpga.  Do shout if the period or anything else should be tweaked.

73 Alan M0NNB

[irbsu...@yahoo.co.uk]

Hello Alan,
I have tried the new version with my Hermes-lite and works very well, I like the dBFS display, its response time is a little long though, could it be sped up a bit?
Steve is obviously doing some clipping calculations in the FPGA which outputs to the string of leds, maybe that could be accessed?
By the way it doesn't work very well with my Hermes board, is this expected?
Thanks,
Andrew
G4XZL

[Steve Haynal]

Hi Graeme,

Yes, I remember that thread. Thanks for the measurement. It it good evidence of how filtering helps.

When I try to duplicate your experiment, I do not see similar results. With and without the bandpass filter look more or less the same to me on 40M. I am using my ZM-2 as a "bandpass" filter, but I believe it is a pretty good BPF. At 384 kHz, I can see drop off of ~5dB at each end of the spectrum. I can turn the LNA up to +40 dB before seeing any clipping. I have no strong AM stations nearby, perhaps a higher noise floor overall than you, and some difficulty doing an apples-to-apples comparison as my antenna is not tuned for 40M without the ZM-2, but I see none of the rough noise humps as in your screen captures.

I have no doubt that you, Andrew and others who live nearby strong AM stations will benefit from RX filters. Where I have questions is how different a HPF/LPF combination will be if compared to the best bandpass filter. In your experiment, you said the difference was not that dramatic between HPF at 1.7MHz and 30M bandpass. Would the results be closer to the bandpass filter if you used a 5MHz HPF? The question I'd like to answer is this: What is the minimum number of HPFs required (1,2,3...) and at what frequencies (1.7, 5, 9, ... MHz) when used in series with the TX LPFs for a particular amateur radio band which will give me 90 to 95 percent of the advantages provided by the best bandpass filter? If this can be done with 3 or less HPFs, then I think it is a space, part and assembly savings as well as wide band RX permissive choice for a budget rig such as the HL2.

73,

Steve

KF7O

[Alan Hopper]

Andrew,

ver 0.152 is twice as fast and should be hermes friendly http://www.ihopper.org/radio/hlradio_0_152.zip .  I'd like to have the fpga send a peak adc value since last sent and maybe a count of number of clips, my feeling is the current overload indicator could tempt you to set a lower than optimum gain in noisy areas.

73 Alan M0NNB

[in3otd]

Hello,
I've added an external BPF which can be switched in and out via USB and recorded the RX signals levels in the 20 m band with and without it over a few hours; the idea was that the strong signals from the broadcasting stations in the 41 m band could cause some second-order intermodulation at 14 MHz. The antenna here is a good ol' 14AVQ trap vertical in a noisy urban environment.
The filter passband goes from about 12 MHz to 17 MHz and the 41 m band is attenuated by more than 30 dB; the losses in the passband are very small, about 0.3 dB or so. The filter was switched by two mechanical relays to avoid adding any intermodulation and also because using the PE4259 would have needed doing another PCB, prototyping dead-bug style with SC-70 components is no fun, hi.

A python script extracted the min, median and max values from every 48 kHz spectrum centered around 14.2 MHz computed by the Quisk routines, averaged these values over 30 seconds, saved them to a file then switched the BPF and started over again.

I was quite convinced that some of the noise floor was caused by the IM2 but this does not actually seems to be the case:

the difference in the levels with and without the BPF is quite constant at around 0.5 dB, especially for the min and median values; there is some more variation in the max values but this is likely due to the signals levels variation in the 30 second periods.
The relays USB control interface got stuck in the early morning for some reason, so I had to restart the capture and I'll try to do a recording over a whole day.

Note that there are some periodic increases in the noise floor here, didn't notice this before and I don't know where that comes from.

73 de Claudio, IN3OTD / DK1CG

[James Ahlstrom]

Hello Andrew,

OK, I will add an ADC full scale meter to Quisk.  I guess I might as well display the wide band data too while I am at it.

Jim

N2ADR

[irbsu...@yahoo.co.uk]

Hello Jim,
Great on the meter, fantastic about displaying the wideband data!! Don't like to push my luck, but any chance of a waterfall too:)
Thanks,
Andrew
G4XZL

[irbsu...@yahoo.co.uk]

Hi Claudio,
Great work!
I am dubious also that IM2 would raise the noise floor these days anyway. Some years ago there were many suggestions that noise floor raising due to IP3 was happening. I'm not convinced its a problem these days.
Even if many stations are causing IMD that resembles noise, its probably below the many other noise sources we have to deal with these days. Maybe you would notice it if you are in the countryside with low noise levels and a big antenna. A switched attenuator would easily reveal if it is IMD.
Your script would be really useful for general noise monitoring as you have already found. Is it something that can be easily run?
Andrew
G4XZL

[Steve Haynal]

Hi Claudio,

Very interesting result. I see noise spikes similar to yours when my son plugs in his phone to charge! 

At what LNA gain setting do you typically see clipping with the HL2 at your QTH? Are you able to increase the gain significantly more before clipping with the BPF in play? I just want to "calibrate" your setup in my mind with how I see mine behave.

Your experiments appear to indicate that there is not much to gain from a BPF on 20M at your QTH. Would you conclude the same? What are your filter recommendations given this experiment?

73,

Steve

KF7O

[Steve Haynal]

Hi Jim,

This sounds great! I look forward to using it.

73,

Steve

KF7O

[James Ahlstrom]

Hello Andrew,

OK on the waterfall.  But I am so busy on filters I am not sure when it will be done.

Jim

N2ADR

[in3otd]

Hello Steve,
I tried to run the spectrum measurements for a longer time but got some issues with one of the relays, that started to show high losses in the "normally closed" position. Its behavior was quite strange, just after switching it showed a loss greater than 10 dB then, over a few seconds, it recovered to the usual practically zero losses. Had to add some "wetting current", a few mA immediately restored the normal functionality - maybe those surplus RF relays had switched thousands of times already and needed come cleaning, hi.

I'm wondering if we should do this too with the relay on the H-Lv2b3? It's a completely different relay but likely not immune to this kind of problems.

Here is an updated noise floor graph, covering a whole day:

not much difference w.r.t. the previous one, maybe between midnight and 6:00 AM a slightly higher difference between with and without filter can be seen but not that much really.
So, based on these measurements, a BPF seems not really necessary on 20 m here...  For the other bands some more measurements would be needed to draw some conclusions, which would be of course valid only for my QTH and current antenna, but I start wondering if we could have just a couple of HPF to cut the broadcast stations in the lower HF.
I can surely increase the gain significantly before clipping when using the bandpass filter, right now (11:00 pm local time) I can go until 18 dB without BPF and until 37 dB with the BPF (at 14.2 MHz, with the BPF described above). BTW, I'm using 10 dB of gain for the measurements above, IIRC that is more than enough to bring the external noise quite above the H-L noise floor.

73 de Claudio, IN3OTD / DK1CG

[Alan Hopper]

Claudio,

very interesting. Do you think the improvement from 00.00 to 06:00 could be caused by the lack of 'incidental dithering' . I realize my back to back tests would have been insensitive to differences at this time of day as there are fewer signals to receive.  Next time I'll store all spot data.  I really like this long term noise floor monitoring idea, I think I'll add it into Spark and just treat it like another datamode ( CNFM ).

73 Alan M0NNB

[James Ahlstrom]

Hello Claudio,

On Monday, June 26, 2017 at 5:05:12 PM UTC-4, in3otd wrote:

I can surely increase the gain significantly before clipping when using the bandpass filter, right now (11:00 pm local time) I can go until 18 dB without BPF and until 37 dB with the BPF

That is very interesting.   It seems the bandpass filter is removing a substantial amount of out-of-band signals.  But even without the BPF the preamp and ADC are so linear that little IMD is produced in-band.  So a bandpass filter would only be necessary if out-of-band signals forced a lower preamp gain that was too low to raise the antenna noise above the HL2 noise level.  As you say, it is QTH dependent.

It would be nice to know where the out-of-band signals are.  So I will put my bandscope project on the front burner.

Jim

N2ADR

[James Ahlstrom]

Hello Andrew and Group,

A new quisk 4.1.8 is available with a bandscope to display the wide band data from the ADC.  Push the "Bscope" button.  When using this screen, the S-meter displays the peak ADC value seen.  Since the display is 36 MHz wide and the graph is about 1500 pixels wide, there are about 24 kHz per pixel.  That makes tuning difficult.  But you can click on a signal and then switch to the graph to tune it in and identify it.  Remember that Y-scale and Y-zero adjust the waterfall.  To adjust the graph, hold down the Shift key.

This feature is useful to study the need for HL2 bandpass filters.  Attached is a screenshot from 9AM today at my QTH in New Jersey, USA.  I turned up the LNA gain to 25 dB, and there are occasional clips.  The ADC shows a 52% level because that was the level at the time, and clips are infrequent.  The USA AM broadcast band is evident at 1 MHz.  I am working through the other large signals and most are foreign broadcasters located in the USA.  The spectrum is zero above 18 MHz.  The antenna was a fan dipole cut for 60, 40 and 20 meters.

Jim

N2ADR

[Jack Generaux]

Jim,

Thanks for doing that -- it is interesting. I have attached the output from my HL 1 radio using a OCF dipole that is currently resting on the top of my root -- wind got it and I haven't reattached.  For some reason the Bandscope display is not working with my HL 2 Beta.  It shows no trace nor waterfall in the Bandscope mode but those display modes work if selected individually.

73

Jack (W0FNQ)

[James Ahlstrom]

Hello Jack,

I only tested the bandscope with my Hermes Lite Version 1, not HL2.  I just assumed the firmware was compatible.  Perhaps others could test with HL2 and see if it works.

Jim

N2ADR

[in3otd]

Hello,
also here with my H-Lv2b2 the bandscope is not showing anything. It could be that the data are not properly sent by the H-Lv2, I tried to dump the EP4 data as received and they are all zero. Due to this I also get an error

Traceback (most recent call last):
  File "/usr/lib64/python2.7/site-packages/wx-2.8-gtk2-unicode/wx/_core.py", line 14665, in <lambda>
    lambda event: event.callable(*event.args, **event.kw) )
  File "quisk.py", line 5199, in OnReadSound
    self.smeter.SetLabel(" ADC %.0f%% %.0fdB" % (d / 20.48, 20 * math.log10(d / 2048)))
ValueError: math domain error

73 de Claudio, IN3OTD / DK1CG

[Dani EA4GPZ]

El 30/06/17 a las 22:09, James Ahlstrom escribió:

Hi Jim,

I'm running Quisk 4.1.8 with the latest HL2 firmware. This firmware has
the newer protocol for the HL2, which includes a different way to set
LNA gain. Quisk has to be patched as below.

The bandscope doesn't work (nothing displayed in the spectrum or
waterfall). The following traceback occurs continuously when bandscope
is selected:

Traceback (most recent call last):

File "/usr/lib64/python2.7/site-packages/wx-3.0-gtk2/wx/_core.py",
line 16762, in <lambda>

lambda event: event.callable(*event.args, **event.kw) )

File "/home/daniel/quisk-4.1.8/quisk.py", line 5199, in OnReadSound

self.smeter.SetLabel(" ADC %.0f%% %.0fdB" % (d / 20.48, 20 *
math.log10(d / 2048)))
ValueError: math domain error

However, this may not be completely Quisk's fault. I have used before
the wideband data with gr-hermeslite2 (with the HL2 and older firmware),
and it worked well. I've just checked and it doesn't work now, perhaps
because of changes in the new firmware.

I'll try to look at this more carefully in the next few days.

73,

Dani.


------------------------
diff -ur a/hermes/quisk_hardware.py b/hermes/quisk_hardware.py
--- a/hermes/quisk_hardware.py 2017-06-06 19:33:11.000000000 +0200
+++ b/hermes/quisk_hardware.py 2017-06-30 22:35:24.027703667 +0200
@@ -244,13 +244,7 @@
QS.pc_to_hermes(self.pc2hermes)
if DEBUG: print ("Change AGC to", value)
def ChangeLNA(self, value):
- # value is -12 to +48
- if value < 20:
- self.pc2hermes[2] |= 0x08 # C0 index == 0, C3[3]: LNA +32 dB
disable == 1
- value = 19 - value
- else:
- self.pc2hermes[2] &= ~0x08 # C0 index == 0, C3[3]: LNA +32 dB
enable == 0
- value = 51 - value
+ value = ((value + 12) & 0x3f) | 0x40
self.pc2hermes[4 * 10 + 3] = value # C0 index == 0x1010, C4[4:0]
LNA 0-32 dB gain
QS.pc_to_hermes(self.pc2hermes)
if DEBUG: print ("Change LNA to", value)

[irbsu...@yahoo.co.uk]

Hi Jim,
Appears to be working on my H-L v1 with the original clock at 61.44MHz, but the bandscope starts at 1.5MHz not 0MHz?? Is there a way to adjust this please?
(does not quite work correctly with real Hermes, I get a display but the dBFS meter is not correct, presumably that's due to it being 16 bit?)
Thanks,
Andrew
G4XZL

[Steve Haynal]

Hi All,

Thanks Jim for implementing this! It is a very nice feature to have in Quisk.

The plan for HL2 is to also generate the same bandscope data as HL1. I haven't tested bandscope on HL2 yet so there may be some problem that crept into the RTL. I am away on a short vacation to celebrate my wife's birthday, but will try to debug this on Monday or Tuesday.

73,

Steve Haynal

[James Ahlstrom]

Hello Steve,

On Friday, June 30, 2017 at 7:51:01 PM UTC-4, Steve Haynal wrote:

 but will try to debug this on Monday or Tuesday.

Please carry on with the HL2 boards instead of fixing this.  The new feature is only important for studying the need for bandpass filters, and most of us can use it with HL1 for now.

Jim

N2ADR 

[James Ahlstrom]

Hello Claudio,

The math domain error is the attempt to take the log of zero.  Zero is the samples from HL2.  I can fix this, but it doesn't solve the problem of the HL2 data being zero.

Jim

N2ADR

[Graeme Jury]

Hello Jim and group,

This is such a useful addition to quisk and is an excellent tool to evaluate what filters are needed. You may be interested to know that the spectrum in New Zealand is very similar to that shown in your bandsccope attachment except that the absolute levels were higher in the first 3 MHz. It appears that in ZL it is not necessary to have a high pass filter after the 30/20 M one although in my test bed I will continue to add the 17/15/12/10 M HPF as originally planned if I can fit it on the 100x100 board as it may be useful in transverter service or as an experimental tool. It would be useful to capture the bandscope at intervals to get a picture of signal levels over a 24 hour period and of course when there is a band opening although that is near impossible in the present state of the sunspot cycle. My observations on the upper HPF not being so valuable may not apply at the peak of the cycle.

Jim I hate to call on your time but it would be a great feature for HiQSDR please. I use this radio as my main rig and test bed but having said that I feel the Hermes-Lite will occupy an equal place as it matures.

73, Graeme zl2apv

[Dani EA4GPZ]

El 30/06/17 a las 22:51, Dani EA4GPZ escribió:

> However, this may not be completely Quisk's fault. I have used before
> the wideband data with gr-hermeslite2 (with the HL2 and older firmware),
> and it worked well. I've just checked and it doesn't work now, perhaps
> because of changes in the new firmware.
>
> I'll try to look at this more carefully in the next few days.

Hi all,

I've just been looking into the issue with the HL2 wideband data.

Firmware 20170226 works fine with Quisk.

Firmwares 20170228 though 20170510 only send zeros as wideband data.
This produces the problems I was experiencing with Quisk and gr-hermeslite2.

I don't know what were the changes between 20170226 and 20170228, but it
seems that they introduced a bug which broke wideband data.

73,

Dani.

[in3otd]

Thanks Dani,
if I read the H-Lv2 git repository history correctly, the only change between these two releases was this commit. There were quite a few changes in hermeslite.v but I don't understand the code well enough to see where the problem is.

73 de Claudio, IN3OTD / DK1CG

[James Ahlstrom]

Hello Graeme,

On Saturday, July 1, 2017 at 12:45:21 AM UTC-4, Graeme Jury wrote:

Jim I hate to call on your time but it would be a great feature for HiQSDR please. I use this radio as my main rig and test bed but having said that I feel the Hermes-Lite will occupy an equal place as it matures.

 

I will add this to my to-do list, but I need to finish up my filter work first.

Jim

N2ADR

[irbsu...@yahoo.co.uk]

Hi Jim,
My bandscope starts at 1.5MHz, it doesn't start at zero like your plot.
Is there a trick I'm missing??
Thanks,
Andrew
G4XZL

[James Ahlstrom]

Hello Andrew,

It should start at zero.  What is your clock frequency?  Mine is 73728 kHz.

Jim

N2ADR

[irbsu...@yahoo.co.uk]

Hello Jim,
Its 61.44MHz.
Andrew
G4XZL

[James Ahlstrom]

Hello Andrew,

I changed my clock to 61.44 MHz and my graph starts at zero.  Try attaching a signal generator and see if the signal appears at the right frequency.  Send a screen shot so I can see what is going on.  The graph should end at 61.44 / 2.  The software assumes there are 2048 samples in the data block.  Maybe one of these ideas will help.

Jim

N2ADR

[irbsu...@yahoo.co.uk]

Hello Jim,
Here's a screenshot. It shows my off-air spectrum received via my antenna plus a 5MHz signal from my signal generator at a level of -30dBm coupled in with a combiner. Also noticed the top frequency is limited to ~29MHz.
Could it be something in my config file?
Loads of interference at my QTH due to broadband and PLT as you can see between 10 and 25MHz.
Andrew
G4XZL

[James Ahlstrom]

Hello Andrew,

Under Config and for your HermesLite, look at the Windows screen.  Make sure "Display fraction" is 1.00.

Jim

N2ADR

[irbsu...@yahoo.co.uk]

Hi Jim,
That's it! I had it set to 0.9 because I don't like seeing the roll-off you normally see.
Maybe for the Bandscope this could be automatically switched to 1.0 then switched back to whatever the user has selected before?
Working well, shame there can't be more resolution, maybe in the new protocol?
Thanks,
Andrew
G4XZL
pic attached, mediumwave broadcast can now be seen!

[James Ahlstrom]

On Saturday, July 15, 2017 at 5:05:44 PM UTC-4, irbsu...@yahoo.co.uk wrote:

Maybe for the Bandscope this could be automatically switched to 1.0 then switched back to whatever the user has selected before?

Yes, for Bandscope this should always be 1.0.  I will fix this.

Jim

N2ADR 

[James Ahlstrom]

Hello Group,

My current design for a simple HL2 filter has a 5-pole Chebyshev high pass filter in-line at all times.  The cutoff is 3.4 MHz with 0.1 dB ripple.  The values are a series 820p capacitor, a 1.8uH inductor to ground, a 470p series capacitor, another 1.8 uH inductor to ground and a series 820p capacitor.  I built this filter on a scrap of PCB to test it.

I measured the effect of this filter using HL1 hardware and my 60-40-20 meter fan dipole.  Without the filter, the LNA gain can be raised to 20 dB and there are frequent clips (ADC overload).  With the filter in-line, the LNA gain can be raised to 36 dB with the same clipping.  So we get another 15 dB dynamic range calculated as 36 - 20 less one dB for filter loss.  I also measured the ADC level at 20 dB LNA using the Quisk bandscope.  Without the filter the ADC level was erratic 50 to 80%.  With the filter the ADC level was a steady 12%.   I was a bit surprised the level was so steady with the filter in-line.   These results depend on the antenna, the QTH (central New Jersey, USA) and the time of day (12 noon local time).

I think having the extra 15 dB is worth including the high pass filter.  But listening to some weak signals on 40 meters, the filter did not make any difference I could hear.  This means the AD9866 ADC and LNA are very linear until they clip.  I wanted to test with weak signals on 10 meters but the band was dead.  Where I am coming out is that a single high pass filter at 3.4 MHz is desirable, and that more high pass filters at higher frequencies will not be worth the extra effort for typical use.  I also plan to omit support for 160 meters because it makes the design more complicated.

Jim

N2ADR

[Graeme Jury]

Hello Jim,

I am following your project with great interest and your results are in line with what I would have expected from my own experiments. Unfortunately I can't provide the exact numbers at present due to having partially dismantling my unit pending a partial rebuild. I used a 1.7 MHz HP filter permanently in circuit and then HP filters for 80, 40, 30/20. 17/15. I would agree with your findings that the filters above 80M don't help a lot but I can see a little improvement with the 40M on 40M vs the 80M one on 40M  one but can't at present tell you by how many dB. My filter system looks good on the quiskVNA with the broadcast band being down by 80 dB and 1.7 to 3.4 MHz being down 40 dB with the 80M HP filter switched in. I guess you are going to have an LP filter set for TX set up to cover 2 bands where appropriate like 30/20 etc.

I am wondering if you are making plans to to be able to operate on say 30M but skim from maybe 80M to 15M. This is going to mean having the 80M HP filter (always in circuit in your case) and 15M LP filter in circuit while on receive for the skimming receiver but when you go to transmit you will need to switch in the 30/20M LP filter and then restore the previous configuration when back on receive. Maybe to keep things simple you don't intend to support skimming or other wideband operation. I know that I am getting very complex with my own filter set but it is meant to be a general purpose set which has the dimensions and inputs to match Hermes-Lite.

I don't know if you have looked at this yet but I also got a very worthwhile improvement from having a roofing filter on RX. Currently it is a 6M one but for the HL a 30 MHz filter would have been even better. The breakthrough from FM broadcasting is possibly an alias issue rather than filter breakthrough but anyway the filter eliminated it.

73, Graeme zl2apv

[Steve Haynal]

Hi Jim and Group,

Your extra headroom is similar to what I saw with the band pass effect of my Z-match and also to what Claudio and Graeme reported. I agree that a HPF is desirable, but I am not ready to give up on 160M. It is great that you observe a 3.4 MHz HPF may be sufficient. Here is the filter configuration I've had in mind for almost a year now and intend to build and test. 

8 relays, RL1 through RL8 are configured in series. There are 8 because the simplest i2c decoder specified will provide 8 relay control outputs. Also, 8 may fit on a 10x5 cm extension board. Three relays, RL1-RL3, are used for HPF switching, and the other 5 for LPF switching. Only at most 2 relays are active at a given time. 

HPF: (May be able to reduce filters and relays given Jim's latest experiment)

RL1 default off: pass through

RL1 on: HPF in the 2 MHz range, footprints support wind your own and maybe SMT

RL2 default off: pass through

RL2 on: HPF in the 4 MHz range, footprints support wind your own and SMT

RL3 default off: pass through

RL3 on: HPF in the 8 MHz range, footprints support SMT and maybe wind your own

LPF:

RL4 default off: pass through

RL4 on: LPF for 160M, footprints support wind your own and maybe SMT

RL5 default off: pass through

RL5 on: LPF for 80M, footprints support wind your own and SMT, starting values taken from RS-HFIQ

RL6 default off: pass through

RL6 on: LPF for 40/60M, footprints support SMT and maybe wind your own, starting values taken from RS-HFIQ

RL7 default off: pass through

RL7 on: LPF for 20/30M: footprints support only SMT, starting values taken from RS-HFIQ

RL8 default off: LPF for 10/12M: footprints support only SMT, starting values taken from RS-HFIQ

RL8 on: LPF for 15/17M: footprints support only SMT, starting values taken from RS-HFIQ

For operation on 160M to 20M, the 10/12M LPF will also be inline. This is similar to other designs, like the filters used with the Hermes or KX-3, which always have a 6M LPF filter inline.

For operation on 160M, there is no HPF inline. For people at QTHs like yours and mine where we can increase the LNA to reasonable levels without a HPF, this is a decent compromise. 160M will be difficult for people at QTHs like Graeme's.

For operation on 80M-10M, an appropriate HPF may be inserted inline. As you point out, there may be some tweaking necessary so that these filters can be cascaded, but you are already considering a 3.4 MHz HPF inline so it should not be too problematic. Also, given your last e-mail, we may be able to save a relay and reduce area and use only one or two HPFs at 3.4 MHz and maybe 2 MHz.

The starting points for many of the filters are taken from the RS-HFIQ. We can tweak these values to other standard inductor or capacitor values if someone optimizes to reduce return loss as you point out. But I feel these values and topology are a good starting point. Since they are designed for use with a class A PA, suppression should be more than adequate for the HL2 PA.

I am optimistic that these filters can fit in a small space based on layout work I did last year and shared with the group before abandoning the filters in the first betas of the HL2. You can see in past posts how the relays are staggered. Having some filters entirely SMT will help with area. Also, a NUD3124LT1G local to each relay instead of a single ULN2803 is essential for small area. This filter design maybe be able to fit on the 5x10cm board, but definitely on a 10x10cm companion board.

73,

Steve

KF7O

[James Ahlstrom]

Hello Graeme and Steve,

Thank you for the very detailed papers.  I never felt comfortable with my filter expertise, and I am learning a lot working on these filters and conversing with you.

First, my 3.4 MHz high pass filter has an attenuation of 40 dB at 1.5 MHz, the top of the USA AM band.  I could not get adequate attenuation with a lower cutoff frequency.  The attenuation of my 5-pole filter doesn't become significant until half the cutoff, so be sure to check if the attenuation is worthwhile if you design a filter with a lower cutoff frequency.  My filter is a Chebyshev design and has good return loss just above 3.4 MHz in the 80 meter band.  This reduces interaction with the 80 meter filter.  Ideally this filter would only be in the Rx path, but I am trying to avoid a T/R relay on the filter board.  Since I am using SMD inductors with poor Q, leaving this filter in-line is a compromise to reduce the number of relays even though it adds to filter losses.

Steve's design also leaves the 12/10 filter in-line.  I did not do this because my SMD filters can have 1 dB of loss, and if filter losses become 3 dB, we have lost half our power!  But I did discover a higher Q inductor that may be useful.  It is the Coilcraft air spring series 132-xxSM so I will look at this again.  The Q is 90 instead of 30 and it can handle power.

I have included space for a 3-pole low pass filter with a cutoff of about 45 MHz that is always in-line.  I have found that PCB design is critical, and above 25 MHz or so energy can leak around PCB filters and ruin the attenuation at VHF.  Unfortunately, adding this filter ruined the return loss of my filter set, so I may have to omit it.  Maybe my PCB layout is good enough not to need it.  Graeme, I did not include a roofing low pass filter for Rx because the HL2 hardware already has a 30 MHz LPF on board in the Rx path.

Regarding Graeme's discussion on skimming, I planned to use the 10 meter filter for skimming so I can skim 3.5 to 30 MHz.  The trouble with suddenly wanting to transmit on 30 meters, and therefore switch in the 30 meter LPF is that I have no T/R data.  Even if I did, I have no logic to select a different filter configuration for Tx versus Rx.  I understand you have a microcontroller that can do this.  However, this is not a problem if you are using Quisk.  Each relay is individually controlled by its own bit, so Quisk can change the bits if it wants, and implement different filters for Tx and Rx.  But this won't work for someone using Power SDR or other software.  I want to maintain complete compatibility with all the non-Quisk software I can.

I do not support 160 meters because I would need two more relays to switch out the 3.4 MHz HPF and switch in a 160 meter LPF.  But I am using five relays mounted end to end, and I am out of room for relays.  I assume that omitting 160 is not a problem because the filter board is only relevant for QRP operation, and I don't think 160 meters is a QRP band; although maybe I am wrong.  For "normal" ham radio use, the HL2 drives a 100 watt amp, and the filter board is not needed.  I might have room for more relays if I used smaller relays.  I am using the same relay as the HL2, namely the EC2-3NU, because they are low cost and we will have them available.  But I could use the smaller IM or G6K series.  I especially like the IM and have often used them.  But they are higher cost.

A fault with my current design is that I can't bypass all the filters.  The best I can do is select 10 meters.  I may have to give up a band to provide this if it is important.  But for "normal" 100 watt use, the filter board is omitted anyway.  Do people think a bypass is required?

Steve, I have already optimized all the filters.  I will publish the values in another post so you can compare them with the RS-HFIQ filters.

Jim

N2ADR

[Graeme Jury]

Hello Jim, Steve and group,

Like yourself Jim I am learning hugely from this discussion and also from the work that John W9JSW and Glenn VK3PE have done. I have attached a picture of my PCB to date which has a full Tx and Rx set of filters which look likely to be able to fit on the 100mm x 100mm PCB but there are still more components to go. I think you will have little problems Steve with relay capacitance affecting the filter values and just a small amount of tweaking on the higher frequency filters will be needed. In my own case with the diode switches there is a magnitude more capacity and I was able to cope with that on my test board but of course the final higher density PCB may be another story.

Regarding the roofing and floor filters. Yes I did take into account that the HL has the 30 MHz LP filter on board (and it works brilliantly with my huge FM signals) but due to the configuration of my TX and RX filter switching it was easier to just leave it in on RX. I am paying an 0.3 dB penalty for this and it has little effect on RX as the noise goes down with this too. On TX the total filter loss (Band cascaded with Roofing) is 1.2 dB and at least 50% of this is diode switching loss and the chokes feeding the switching current to them. I am still working on better chokes and may gain a bit there.

My out of band isolation is around 42 dB going down to 58 dB at 40M band or lower. I expect with relays it would be a lot better and I recall measuring the QRP Labs filters and getting a pleasant surprise but I forget where I posted the result. I have provided a bypass for the filters which is 0.6 dB on Rx and 0.3 dB on Tx which again is inferior to what relays could provide. I am not sure what the physical size of your relays are Jim but the HK-4100 relays John Williams used were small and cheap but not as small as the relays in the QRP Labs filters..

With the skimming I intended to have extra buttons to provide a skim 1, 2, 3 etc. output or any other GPIO functions and let the smart filter board make the filter decision on transmit based on the band selected. John Melton already provides output to GPIO pins on the RaspberryPi so my writing in some buttons as a widget on Quisk would not deviate too much.

73, Graeme zl2apv

[Takashi K]

Hi Graeme-san and all,

I made an experimental 100mm x 100mm filter PCB for my testing the HL v2 beta3. I don't intend to disturb Graeme's making new filter board for HL v2. So, just for your informantion.
I attached the schematic and photos. The circuit configuration is based on the Pre-V2 amplifier's LPF, John's FR-Sense board and Graeme designed HPF circuit.
I have not assembled and tested it yet. But It should be able to directly connect with HLv2 by pin-header and pin-socket. I chose toroidal coil for LPF  in order to minimize filter loss because I want to make a standalone tranceiver without post linear amplifier. As toroidal coils need around 10mm height, I decided to use the same chinese cheap relay that is on hand as Pre-V2 amp instead of diode switch. I'm thinking two MCP23008 are used for Tx and Rx filter switch and chose TPL7407 as a relay driver because it is inexpensive and has small package; TSSOP-16.
The optional tsv filter circuit is for 2m or 6m transverter interface but I don't have the detail plan now. I'm thinking vaguely that it can be realized by low power output from RF1 and local frequency from CL2.

73, Taka  ji1udd

[f6itu]

Hi group

FYI

I used Taka’s same 10x10cm format but with a different approach

-          Absolutely NO “on board” logic, to accommodate any kind of switching command set : original J16 Hermes SPI protocol, I2C, bcd, decimal etc. Decoding will be located on another board to remain compatible with any kind of rig control

-          Separate lpf and hpf board to fit any RF power in the TX / lpf path (50 W or 100W max ? not yet decided. So far, everything has been sized for a 20 W amp). Each filter, lpf and hpf, are located on different boards using same dimensions. Theses boards are mounted “piggy back way” to offer minimal crossband coupling

-          T50 Toroids at least and 2 amps relays are used to limit losses on higher bands

In other words, a kind of Alexiares-like filter with a set of different control board to accommodate any kind of transceiver or any future evolution of the H.L.

I’ve not yet decided what kind of topology to use. So far, the M derived gives me the best impedance and phase and a nice frequency rejection on F2 and F3, but less overall rejection compared to a classical elliptic filter.

It’s a heavier and space consuming approach compared to an H.L. dedicated filter.  But it’s the simplest way to stay compatible with the whole “hermes” family (H.L., Red Pitaya, Hermes/Angelia/Orion mk1..) or any other SDR, even an old "softrock/mobo" combination

the first "3D" brd is the lpf, the next is a simple hermes SPI decoder handling all the filter/antenna TX/RX and swr security switching. 

 

 I hope the final design will be tested before end of August. 

73' Marc f6itu

 

[John Williams]

Taka-san,

Well done! I was thinking of using some of my prior work as a basis for a similar layout. Alas, I have been too busy lately to do much more than follow the progress of this filter work. This looks excellent!

I will be anxious to see how this performs operationally.

John W9JSW

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

[James Ahlstrom]

Hello Graeme and Steve,

Here are the values of my filter components for a 5 watt 5x10 cm board for HL2.  They are calculated without the effects of board strays, but should be a good starting point.  The minimum attenuation at the second harmonic is 20 or 25 dB and is based on measurements by Claudio.  I will build these filters and test them starting next week.

Starting from the HL2 board, the first high pass filter is a 820pF series capacitor, a parallel 1.8 uH inductor, a series 470pF, a parallel 1.8uH, and a series 820pF.  Then one of these filters consisting of a parallel C1, series L1, parallel C2, series L2 and parallel C3.

Band         C1             L1              C2              L2              C3

80          1200pF     1800nH      2200pF      1800nH      1200pF

17/15       220           330             470            330            220

12/10       180           220             390            220            180

I have values for 60/40 and 30/20 but the return loss is only 12 dB.  An elliptic design works better.  The RS-HFIQ also uses elliptic for these bands.

60/40        390pF     1200nF  || 56pF     680pF    820nH || 220pF     270pF

30/20        180           680      || 22         330         470     || 100         150

Jim

N2ADR

[Steve Haynal]

Hi Jim,

SMD filters can have high losses, but do you expect 1 dB of loss across the whole passband? I was expecting the losses would be more in the range of 0.3 to 0.5 dB once you are sufficiently far away in frequency from the -3dB cutoff frequency. So 3 filters at 3.4MHz HPF, 16MHz LPF and 32MHz LPF cascaded should not introduce 3dB loss for 20M operation. I see the lower losses when modeling with Elsie and using inductor Q of 30, or from this CoilCraft paper on real implementations or the CoilCraft filter design program which I believe includes Q in the modeling.

Are you using a 2 layer or 4 layer PCB? Given the low price of 4 layer from Elecrow and the benefits of a nice uniform ground plane, I'd go with at least 4 layer for filter boards.

73,

Steve

KF7O

[Steve Haynal]

Hi Marc, Taka, Graeme, Jim and John,

Thanks for all the filter board work! It looks like there will be several good options for the Hermes-Lite2. I want to make sure people can find and use this work. Please let me know if there is a link I can add to the main hermeslite.com web page. Also, once your filter boards are done, I can add a .zip package (gerber production files, design files, dom, instructions) to the main github site if you like so that others can fabricate your boards. Also, it would be great if your can provide or sell boards to others. We've been using www.elecrow.com for small PCB batches with good results. It is easy to order a batch of 5, 10 or 20 boards and then sell or distribute the remainder to others. I have also used www.tindie.com to sell bare boards. I recommend this site as it automates much of the payment hassle. All you need to do is package the board and send to the provided address.

73,

Steve

KF7O

[Graeme Jury]

Hello Jim,

If you want to improve the VSWR you could try these values. 310p 1.31538u || 47p 600p 894.922n || 220p 220p
The usual tradeoff of bandstop attenuation has had to be made but given the figures posted by Claudio (thanks Claudio) the performance would still be ok.

73, Graeme

[Graeme Jury]

Hi Steve,

Yes it is good to see a range of filter boards as I don't feel that one board will fulfil all needs and also people just like to do their own ideas. As far as I am concerned everything I am doing is in the public domain and I am 100% happy to share around my surplus boards at cost and will give consideration to capacitors that I bulk bought if there is any demand. The design has to be proved to work first :-) My work is on github.

73, Graeme zl2apv

[Steve Haynal]

Hi Graeme,

I suspect Jim has to compromise and is picking standard values available from manufacturers he likes. Did you fit your values to those commonly available and still see VSWR improvement?

73,

Steve

KF7O

[Graeme Jury]

Yes agreed. Often my filter choices have been around what capacitors are in the junk box. The 310 capacitor was made from 270+39 pF = 309 but I sent the calculated value as he may have had something to exactly make up 310 pF. Interestingly this input capacitor has the greatest influence on VSWR and I tweak it for best result. The centre capacitor has the next greatest effect but I have never needed to tweak that one if I get the input capacitance right. The output capacitor seems to affect the shape rather than VSWR. At 60/40 M probably tweaking won't be necessary as the necessary as the strays represent a small percentage of the input capacitor.

Great news on the boards shipment and your update to RTL.

73, Graeme

[James Ahlstrom]

Hello Graeme and Steve,

On Saturday, July 29, 2017 at 7:14:46 PM UTC-4, Steve Haynal wrote:

I suspect Jim has to compromise and is picking standard values available from manufacturers he likes. Did you fit your values to those commonly available and still see VSWR improvement

Yes, I am using only standard values that are readily available.  I could get more capacitor values by using parallel standard values, but that requires two pads.  I am not piggybacking capacitors because a board house will not manufacture that.  The current plan is that the board is manufactured and is available assembled and ready to go.  Or maybe only the through hole relays need be added.

Jim

N2ADR

[Takashi K]

Hi Steve,

> Please let me know if there is a link I can add to the main hermeslite.com web page.

OK, I will let you know after confirming that my board works well.
In my case, since the new part is a control circuit, I will check its operation first and consider the value of each part of the filter later.

BTW, Does anyone know the reason why alex LPF selection bit is irregular order  in openHPSDR protocol.  

Is it to avoid cross coupling between filters on PCB?

73, Taka  ji1udd

[James Ahlstrom]

Hello Steve,

On Saturday, July 29, 2017 at 3:33:53 PM UTC-4, Steve Haynal wrote:

SMD filters can have high losses, but do you expect 1 dB of loss across the whole passband?

Maybe.  Take a look at the 80 meter RS-HFIQ filter which is identical to my optimized filter.  The Elsie modeled loss is  1.68 dB at 3.5 mHz and 1.95 dB at 4.0 MHz.  My measured values are 0.88 dB and 1.22 dB.  Some of this is reflected energy, and the rest is inductor losses.  A first guess is that the ohmic inductor loss is the same anywhere in the pass band because the inductors are still in series with the signal.  Things are complicated because the Q varies with frequency and the passband is not flat.  Only measurements are adequate to guarantee performance.  But I have modeled filters in series, and have seen that the losses are less than the sum, as you have pointed out.  So I am still thinking about leaving 12/10 in line without a relay.  There are pads on my new board so I can try this and measure the result.

Are you using a 2 layer or 4 layer PCB? Given the low price of 4 layer from Elecrow and the benefits of a nice uniform ground plane, I'd go with at least 4 layer for filter boards.

I am buying boards from OSHPark, and they are two layer boards.  I am taking pains to make the bottom copper continuous, and I don't think there will be an advantage to four layer.  Actually, I sometimes wonder if I should remove copper under the filters to reduce stray capacitance to ground.

Jim

N2ADR 

[James Ahlstrom]

Hello Steve and Group,

On Saturday, July 29, 2017 at 3:41:49 PM UTC-4, Steve Haynal wrote:

Thanks for all the filter board work! It looks like there will be several good options for the Hermes-Lite2. I want to make sure people can find and use this work.

If my filter board works I will be happy to make a link to board files, BOM, etc.  But I don't want to be involved with manufacturing and distributing completed boards.  I was hoping someone else would do that.

Jim

N2ADR

[James Ahlstrom]

Hello Group,

On Saturday, July 29, 2017 at 8:52:15 AM UTC-4, James Ahlstrom wrote:

Starting from the HL2 board, the first high pass filter is a 820pF series capacitor, a parallel 1.8 uH inductor, a series 470pF, a parallel 1.8uH, and a series 820pF.  Then one of these filters consisting of a parallel C1, series L1, parallel C2, series L2 and parallel C3.

The high pass filter values are incorrect.  The correct values are  a 1200pF series capacitor, a parallel 1.8 uH inductor, a series 560pF, a parallel 1.8uH, and a series 1200pF.  Sorry about that.

Jim

N2ADR

[f6itu]

Hi Steve & all

I'm still working on the filter topology (M-derived vs Cauer... it's not an important question)

As soon as I've finished and tested a full functionnal prototype with "real life" measurements, I'll send you the kicad files. They will also be stored on my github

I'll do my best to lauch a small batch of pcb (20 or 30 for the first run...) 

73'

Marc f6itu

[James Ahlstrom]

Hello Group,

I am still working on a 5x10cm filter board with SMD inductors, and I have a bit of progress to report.

I started out with mesh-coupled filters because I thought they had been used successfully.  I like this topology, but it is unsuitable for HL2.  Since they are bandpass filters, it is not possible to combine bands, for example, a single filter for 17 and 21 meters.  That means more filters and more relays.  And they require larger inductance values, which forces us to use ferrite inductors with lower current capability and larger losses.

I now feel comfortable with cascading multiple filters and adjusting the filter part values to compensate.  I have a design with a 3.4 MHz high pass filter, followed by a 17/15 meter filter, followed by a 12/10 filter that is always in-line.  But I still need to measure losses to see if this is practical.

I have a working 5-relay design with a 3.4 MHz high pass filter and all bands 80 to 10 meters.  But I need a sixth relay to switch out the HPF so we can receive 160 meters and below.  I am not sure I have room on the PCB.  Also, the transmission at 4.0 MHz is -1.5 dB, so we need 7 watts in to get 5 watts out.  Can HL2 produce 7 watts?

I see that PowerSDR has separate Tx and Rx filter settings, and that I will need to add this to Quisk.

I am looking at Steve's design which puts the filters in series instead of parallel, but this routes the RF through all the relays.  Does anyone have experience with this approach?  What about losses and feed-through around the filters?

So I feel I am getting close and learning a lot, but I still have no finished design.

Jim

N2ADR

[Steve Haynal]

Hi Jim,

At 4.0 MHz, the beta3 is producing >=7W. It tapers off on 12M and 10M.

Regarding the series filters, see the G11 multiband board schematic in this post:

https://groups.google.com/d/msg/hermes-lite/0P18xh-KaXQ/NNVL26LSAQAJ

for an existing design. The designer YU1LM is know for his homebrew work and filter design. See http://yu1lm.qrpradio.com/

This gave me some confidence in this series filter approach.

73,

Steve

KF7O

[James Ahlstrom]

Hello Steve and Group,

I am making progress on a 5x10 cm filter board with SMD inductors.  I built a board based on Steve's design from July 2017.  See below.  I was worried about relay losses and bleed through around the filters, but I now believe this design can be made to work.  I am using the same relay as the HL2 T/R relay because they are available and inexpensive.  I really like the IM series relays, and they are smaller, but they cost more.  There are six relays configured in series as follows:

RL1 default off:  pass through

RL1 on:  Low pass filter for 12/10 meters

RL2 default off:  pass through

RL2 on:  Low pass filter for 17/15 meters

RL3 default off:  pass through

RL3 on:  Low pass filter for 30/20 meters

RL4 default off:  pass through

RL4 on:  Low pass filter for 60/40 meters

RL5 default off:  pass through

RL5 on:  Low pass filter for 75/80 meters

RL6 default off:  High pass filter 3.4 MHz

RL6 on:  pass through

With all relays unpowered, only the HPF is in line, and this configuration can be used for wide band receive.  For 160 meters and below, only RL6 is powered, no filters are in line, and an external filter can be used.  For normal QRP ham radio operation one of the RL1 to RL5 is powered on both Rx and Tx.  The filters can be designed with the HPF assumed to remain in line, and then there is no need to switch any relays on T/R.  Or different filters can be designed on the assumption that the HPF is powered and switched out on Tx.

There are some remaining issues with this design, and I will make a separate post.

1) Filter losses on 60/40 are 1.72 dB, and driving the HL2 to 7.4 watts to get 5 watts out will increase power dissipation and distortion.

2) The HL2 has a 35 MHz low pass filter on board for Rx, and this may interact badly with the 12/10 filter on Rx.

3) How to get a T/R signal to switch relays if required.

Jim

N2ADR

[Steve Haynal]

Hi Jim,

This sounds great! Thanks for all your work. For number 3, I was thinking the software would send a different set of relay selects to the I2C bus expander on TX and RX. Do you see a problem with that? We may be able to move that to FPGA firmware so the software only has to send the RX and TX filter band select settings when the user changes them or changes bands. I expect the I2C latency to be around 100ns from value to bus expander so could appear pretty much instantaneous if synchronized with the PTT in the FPGA firmware.

The pin compatible 3V DPDT relays I have in my database are: EC2-3NU and NA-3W-K. They cost about a dollar a piece in quantity from aliexpress.com or ebay.com.

73,

Steve

KF7O

[James Ahlstrom]

Hello Steve and Group,

On Friday, September 1, 2017 at 12:00:59 AM UTC-4, Steve Haynal wrote:

This sounds great! Thanks for all your work. For number 3, I was thinking the software would send a different set of relay selects to the I2C bus expander on TX and RX. Do you see a problem with that?

 

Yes.  See below.

We may be able to move that to FPGA firmware so the software only has to send the RX and TX filter band select settings when the user changes them or changes bands.

 

I believe the protocol does not support two band settings, and we would lose compatibility with PowerSDR etc.

The pin compatible 3V DPDT relays I have in my database are: EC2-3NU and NA-3W-K. They cost about a dollar a piece in quantity from aliexpress.com or ebay.com.

I am using EC2-3NU.

My filter losses are quite high, and I am thinking about switching out the high pass filter on Tx.  Other filter designers may need a T/R signal too.  I planned to add separate Tx and Rx filter selections to Quisk, but I no longer think this will work for CW.  And CW is the most likely use of a 5 watt HL2.  The CW signal is generated in the FPGA from the key input.  The T/R signal is then sent to the PC in the UDP packets, and the PC will then change the filter selection and send the new filters back to the hardware in subsequent UDP packets.  Then the firmware will write the new filters to the I2C bus.  Involving the PC can produce arbitrary delays, and the result can be hot switching the filter board relays and making high speed CW choppy.  For non-CW operation I think the problem still exists.  And there is a reliability problem.  If someone makes a filter board with small parts in the Rx filters, and something goes wrong, the Rx parts will burn out if the relays do not switch in time.

My filter board connects to the HL2 main board by a ribbon cable to CN7.  The T/R signal is on CN11 and CN12.  I think CN12 is more useful, since it is directly connected to the HL2 on-board T/R relay coil, and is fail safe.  There are several solutions.

1)  Do nothing.  Users will run a second ribbon cable to CN11 and/or CN12.

2)  Wire CN12 pin 1 to CN7 pin 1.  CN7 currently has ground pins 1 and 8.  The best solution IMHO.

3)  Move  CN12 to line up with the pins of CN7 to make a 2x5 connector instead of a 2x4.  Move CN11 to the center of the space.

The ribbon cable connectors I purchased (Mouser 517-89108-0101) have extra width due to the side latches.  This may make space problems with CN7, CN11, CN12 and RF1.  Purchased cables are narrower, but I don't think CN11 and CN12 can both take separate ribbon cables, and will need a single 1x4 ribbon cable.  Or soldered wires.  We should probably review the other pin header connectors with reference to ribbon cable connector width.

Jim

N2ADR

[Graeme Jury]

Hello Jim,

Thanks for this message which clears up some things I did not properly understand, particularly the action of keying sending the keypress to the PC via UDP and the PC initiating a filter change between Rx and Tx via the J16 output and I2C.

My expectation was that when a band button was clicked the TX filter value was set as was the Rx filter value from the filter table associated with the button on the PC by placing them on the output pins plus sending via I2C to latches on the filter board and would not need to be repeated until another band button click. The receipt of T/R either via I2C or the appropriate output pins would enable the matching filters from the latches associated with Tx or associated with Rx followed a few mSec later by the RF so we would only be looking at the latency from the fpga's Tx/Rx signal to the PC and back to the filter board plus the filter board's switching time of around 10 mSec which would be typical of high speed break-in keying. The latency of RF production after a keying signal is something I have no idea of its timing and of course if it beats the relay then the sloped leading edge would be lost leading to key clicks and the hot switch potential disasters you alluded to.

I envisioned band buttons being able to be set for cross band operation as the Tx and Rx frequencies would be independent of each other. Also maybe two buttons could be assigned to a single band say 80M(a) with 80M for Tx and 80M for Rx to allow narrow single band operation from one button and 80M(b) with 80M for Tx and 40M for Rx so skimming can occur on both bands while still being able to Tx on 80M. I understand with your setup which is sharing filters you would not use it quite in this way.

I can see I was a bit out of touch with reality and had not done my homework well. I am not boxed in by this as my filter is microprocessor controlled and can simply be reprogrammed. I have a switching time of less than a millisecond with the pseudo PIN diode switches (if everything works out) so I will be OK with the latency from a PC initiated filter switch but relays would be a real problem. We can take steps to overcome this but need to keep in mind that we are trying to stay Hermes compatible although our hardware can deviate if we accept that we won't be using devices like the Alex filters etc. from the Hermes stable.

It would be very helpful if we could develop a detailed I2C protocol and some of the things which would be needed are ...

The expected I2C address's of the attached devices
The values which would be sent
(a) for switching filters
(b) the order of signals if that determines how the filters are set. Maybe the Tx value comes before the Rx value
(c) the Tx/Rx identifier (or address if different for filters) e.g 1 for Tx 0 for Rx etc.
(d) identifiers for external devices like swr, temperature, PA output
Does the HL operate as Master only or as master slave?

Probably people can get this from the Hermes protocol but it would be useful in our own wiki protocol.

I have got the boards back for my filter and have started building it up. Too early for results yet but going well so far with through losses via the 30 MHz roofing filter of .3 dB. I have some revelations coming up I hope about Cauer filters and why they don't always have the second notch.

73, Graeme

[Steve Haynal]

Hi Jim and Graeme,

The intention of my last post was to describe how *not* to require the PC to be in the loop for RX/TX filter change. The old Hermes protocol already has command and control for multiple Alex filter banks that we can use for PowerSDR compatibility. See C3 (Alex HPF) and C4 (Alex LPF) when C0 ix 0001001x. We can repurpose the HPF settings to be filters engaged during RX, and the LPF to be filters engaged during TX. PowerSDR users may not have the full 8-bits for RX and TX, but will have enough bits, 6 for RX and 7 for TX. These values only need to be passed to the HL2 on value change. There will be a copy of both in the firmware. When PTT is engaged, the firmware will change the filters with the ~100ns latency by sending the value over I2C. When a CW key is engaged, it can trigger the same change although I don't think relays will be useful for fast CW. For fast CW, the user will want to set the RX and TX filters the same, or we can add some disengage TX relay delay when we enhance CW operation, or they can use PIN diode switching in the filters for true QSK between TX and RX. It is true we are already paying a penalty for any software-originated TR switching but this filter switching solution does not add further overhead as the values are stored in the FPGA. 

I think with the above it is not necessary to have PTT on CN7, but I can see how it may be useful. I've added Jim's number 2 to the github issues for inclusion in the next revision.

Regarding Graeme's questions, the expected I2C address is on the schematic. The schematic lists both MCP23008 and MCP23017 but I'd like to standardize on the MCP23008. The HL2 will always be master. There is no distinction over the I2C between TX and RX. The HL2 manages what 8-bit value to send for TX filter selection and for RX filter selection, and those are the only values ever sent over I2C. From the slave's perspective, it just selects the correct filters based on the 8-bit value it receives. It is up to the filter board designer to define what these values mean. The software is rich enough that any 8-bit value can be set for TX or RX. The protocol used is as defined in the MCP23008 datasheet. If you want a microcontroller to listen, then it only needs to respond to what the MCP23008 reponds to. The bit ordering will match the byte sent by the software, so bit 7 of the byte sent will be GP7 on the MCP23008 and bit 0 of the byte sent will be GP0 on the MCP23008.

Although you are using a ribbon cable, will it also be possible to abutt the filter board with the HL2 so that a 15cm x 10cm board is created? This was the original plan and will fit in the 150mm long commonly available enclosure. This is also why I am thinking of requiring the end user to install SMA and other back side connectors. This gives them the opportunity abutt the board and just wire it in place. This also assumes that routing for low power RF, alternate RX RF, power, CN12 and CN11 may cross the filter board. A good reason for a 4 layer board here.

The width of the ribbon connectors are designed to be wide enough to use with connectors from Mouser and Digi-Key. Please check other part numbers. I will try to dig up what I had in mind when doing the design.

73,

Steve

KF7O

[Takashi K]

Hi Steve,

I have already controlled my filter board through HLv2 using Alex LFP/HPF bits.

And I found a problem that Alex(for LPF/HPF selection) and Apollo (for tuner/filter bit reuse) could not be selected at the same time on Harware Config tab of PowerSDR.

I think Alex and Apollo cannot be used at the same time. maybe this is OpenHPSDR specification.

73, Taka  ji1udd

[Steve Haynal]

Hi Taka and Group,

Yes, I remember that Alex/Apollo selection in PowerSDR, but from the perspective of the protocol they are not mutually exclusive. The firmware can respond to selections in both modes. In Apollo mode, only the TX filter bank may be set. In Alex mode we may have to repurpose some other controls for tuner/filter bit reuse. The firmware doesn't need to know what mode it is in. It just responds to commands for both Alex or Apollo. Since the software will be set to one mode, there will be no conflicting commands sent by the software. This allows us to have more filter bank selection yet maintain enough compatibility with PowerSDR.

It bothers me that Jim has found it necessary to remove the HPF for TX to reduce filter losses. This indicates that the HPF is in the wrong place and we should consider putting it only in the RX chain. I like that Jim and others have found that just one (or maybe 2) HPFs can significantly increase dynamic range headroom, especially for active times when currently clipping may be common for some. One or two HPFs is much more attractive to me given the lower cost and support of multiband skimming. Also, this measurement by Claudio supports that not much more filtering is necessary or even beneficial.

Jim, can you provide measurements for filter losses on all amateur radio bands 80M to 10M with and without the HPF? I'd like to understand better the losses you see, and if they only affect the lower frequency bands. Also, can you provide a pointer to git or attach a .zip of your latest KiCad work?

73,

Steve

KF7O

[Graeme Jury]

Hello Steve and Group,

I am starting to come to the conclusion that for the Hermes-Lite at 5 watts out , less filtering than I am doing is needed however my somewhat Alex filter is for general use in my shack and will be pressed into service in other areas as well. I have constructed the filter as far as the 30 MHz roofing filter and all the switching including the pass through switch and antenna changeover all with M7 diodes in pseudo PIN mode. The roofing filter was less than .15 dB insertion loss at any frequency below 30 MHz when measured on its own and better than that below 28 MHz. I have included sweeps of the setup with the roofing filter in series with the pass through switch and the Rx/Tx changeover switch so you can see the total loss of the diode switched system. BTW I have built another 30 MHz roofing filter with better return loss and around the same pass performance but it is not in the PCB yet only on my test bed. I also feel that it may be better to place the roofing filter in the leg from the PA out to the switched filters so it is only in circuit on TX as there is already a roofing filter in the RX which works very well even in my huge RF environment from FM broadcasting.

73, Graeme zl2apv

[Graeme Jury]

Hi Steve,

Thanks for clearing up the points I had missed. You said that the filter switch values would be the only ones sent over I2C but I am wondering if Tx/Rx would be sent also? I can understand that from a noise perspective that you don't want continuous traffic on the I2C line and monitoring swr etc. would not be a good idea until we know if and how much would be generated. I have also included input pins so that J16 signals and Tx/Rx can be received from HL1 boards to keep the filter universal. This also allows me to use the filter with my HiQSDR radio as well.

You and the others are doing a fantastic job.

73, Graeme zl2apv

[James Ahlstrom]

Hello Steve,

On Saturday, September 2, 2017 at 2:31:03 PM UTC-4, Steve Haynal wrote:

It bothers me that Jim has found it necessary to remove the HPF for TX to reduce filter losses.

I am not yet sure about removing the HPF.  But I know my filter losses are too high.  The loss is 1.55 dB on 80 meters, and 1.72 dB on 40 meters.  The transmission through the six relays on the board with no filters selected is -0.25 dB.  Adding the HPF changes this to -0.45 dB at higher frequencies, and -1.09 dB on 80 meters.  The HPF is reactive at 80 meters, but adding the 80 meter LPF is supposed to tune this out.  Anyway, the difference the HPF makes is -0.2 dB, so it really should be possible to leave in line, as was my original intention.

This indicates that the HPF is in the wrong place and we should consider putting it only in the RX chain.

That would mean adding a T/R relay to the filter board, and that would be a tight squeeze.  See photo.  I think switching the HPF in parallel with the HL2 on-board T/R relay is really OK, and is better than adding a T/R relay to the filter board.  The relays are the same, and there should be no timing or reliability problems.  And it allows for both (1) removing the HPF on Tx and leaving it in line on Rx, and (2) removing the HPF on both Rx and Tx for use at lower frequencies or for a subsequent power amp.  This is more flexible than just a T/R relay.

 

Jim, can you provide measurements for filter losses on all amateur radio bands 80M to 10M with and without the HPF?

I am still working on that.  My measured filter losses do not agree with the predicted values.  Unfortunately, in my experience, that is most often the case.  The losses my be due to poor filter design.  I plan to redesign the filters and make the best filter I can with and without the HPF to see what the difference really is. 

Jim

N2ADR

[Takashi K]

Hi Steve and all,

> from the perspective of the protocol they are not mutually exclusive.

I also believed so.

Here is my investigation result, I cannot find Apollo specification.

PowerSDR does not control Alex HPF / LPF bits at all if Apollo mode is selected.

Apollo's MCU selects a suitable band filter according to operating frequency (firmware mode).

I think that by realizing this with HLv2 firmware ( or MCU on Graeme's filter board), compatibility with PowerSDR can be maintained.

If Alex mode is selected with PowerSDR, Apollo tuner/filter bit control becomes incomplete.

Even though tuner bit was enabled, the PA might turn off.

In Alex mode, firmware mode is selected by default, so operators need to select Manual mode.

If  operators forget to select Manual mode, an incorrect band filter is selected and PA might be damaged.

I think it seems difficult to support firmware mode because FPGA resource is not enough, so we need to consider another countermeasure.

73, Taka  ji1udd

[John Marvin]

There seems to be an assumption that Doug wouldn't be willing to make any changes to PowerSDR to directly support HL2. He might not be willing to make major changes, but small changes, especially if someone else does the development, might be acceptable. Has anyone asked him if he would be willing to accept minor changes to support HL2?

I'm not willing to maintain a fork of PowerSDR for HL2, but I'd be willing to make small changes to PowerSDR to support HL2 if Doug was willing to accept those changes into the PowerSDR code base. I might even be willing to continue support/testing in the cases where Doug makes a change to PowerSDR that breaks HL2, since I suspect he also might not want to include HL2 in his release testing.

Regards,

John
AC0ZG

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

[Steve Haynal]

Hi Graeme,

By TX/RX, I assume yo mean the PTT signal that is active during TX? If so, no it will not be sent over I2C. If you need PTT, then you can connect to the signal to be added to CN7 per Jim's request or to CN11 or CN12.

I think we already have a good idea on the noise. The slow ADC is sampling continuously over I2C and no one has been complaining. I've looked for noise and haven't see it. Maybe Claudio will point something out...

73,

Steve

KF7O

[Steve Haynal]

Hi Taka,

These type of firmware changes are not very resource heavy, and I have some room in mind after optimizing other code. I think we can support Alex in firmware mode and based on the frequency ranges. We can repurpose extra Alex bits for any Apollo PA differences.

73,

Steve

KF7O

[Steve Haynal]

Hi John,

Thanks for the offer! Agreed that even a few minor changes to PowerSDR could make it a whole lot easier and intuitive to work with the HL2. I am not a PowerSDR user and have only run it a handful of times in the past 2 years to do some quick tests, but there are others who are interested in PowerSDR. Do we have other PowerSDR users on the list willing to work with John and Doug? I'm willing to make some changes in the firmware/supported protocol to facilitate this.

73,

Steve

KF7O

[Steve Haynal]

Hi Jim and Group,

I've been thinking about filters today and wanted to bounce an idea off you and the group. I don't like the idea of having the HPF in the main TX/RX signal chain as it isn't useful for TX, requires a relay and is complicating the design with various filter interactions. So, I am proposing this:

* Convert the current permanent LPF in the RX chain on the HL2 into two filters, selected by PE4259 devices. One selection will be a ~3MHz HPF, either the one you designed or the one Graeme designed and Taka tested. The other selection will be either pass through or the existing 35 MHz LPF, haven't decided yet. These filters can use smaller components than what you must use in TX. I have the room and FPGA line available to implement this.

* Your filter board would then have only 5 or 6 low pass filters:

**10/12M filter always in place, no relay. This would be the reconstruction filter for RX and would have to be good through VHF. The KX2 schematic has such a filter always inline, so I find it hard to believe it would contribute excessive loss.

** 17/15M filters. RL1 default passthrough.

** 20/30M filter. RL2 default passthrough.

** 40/60M filter. RL3 default passthrough.

** 75/80M filter RL4 default passthrough.

** 160M optional filter? RL5 default passthrough.

This would require only 4-5 relays so there would be room on the board for higer quality low loss 10/12M filter. People interested in 160M would use the RX passthrough/HPF selection and either a 160M on your board or an inline filter if it won't fit.

If the 10/12M flter interacts badly with the 15/17M filter, put the 10/12m filter on the default passthrough side of relay RL1. Then for 15/17M TX only the 15/17M filter will be in line.

73,

Steve

KF7O

[Takashi K]

Hi Steve,

I checked the behavior of PiHPSDR.
PiHPSDR never controlled Alex LPF/HPF bits. In other words, PiHPSDR seems to support only firmware mode.

And in Apollo mode, Apollo filter and tuner bits seem always enabled.

PiHPSDR has another function that OC can be set independently for Tx and Rx, and it works as intended.

73, Taka  ji1udd

[Steve Haynal]

Hi Graeme,

With what I propose, you can still have one bit via the I2C to indicate TX if you like. In general, I'd like software including PowerSDR if we can make a few mods, to allow the user to specify what the 8-bit value output of the MCP23008 is on a per band (or frequency range) basis for both TX and RX. You can then tell users of your filter board to allocate a specific bit for TX by making that bit always 1 in the TX fields and always 0 in the RX fields for all bands. Then that bit will naturally be 1 only for TX whatever the selected band and you have 7 bits left for other purposes. 

This is an example of abstract versus concrete in programming, and I tend to like to stay in the abstract for as long as possible. :)

[James Ahlstrom]

Hello Steve,

On Saturday, September 2, 2017 at 7:24:51 PM UTC-4, Steve Haynal wrote:

I've been thinking about filters today and wanted to bounce an idea off you and the group. I don't like the idea of having the HPF in the main TX/RX signal chain as it isn't useful for TX, requires a relay and is complicating the design with various filter interactions.

I don't think having a switched HPF on the filter board is much of a problem.  Switching it out removes the filter interaction problem, and the relay coil can easily be switched in tandem with the HL2 T/R relay.  But having said that, your proposal is a superior solution.  I am a bit surprised and happy that you can fit the extra filter and PE4259 devices.  Perhaps it would help to change the T2 footprint to the commercial transformer and skip the homebrew device.

* Convert the current permanent LPF in the RX chain on the HL2 into two filters, selected by PE4259 devices. One selection will be a ~3MHz HPF, either the one you designed or the one Graeme designed and Taka tested. The other selection will be either pass through or the existing 35 MHz LPF, haven't decided yet. These filters can use smaller components than what you must use in TX. I have the room and FPGA line available to implement this.

Very nice if space allows.  The 3 MHz HPF must be switchable in/out.  I am not sure about the need to switch the 35 MHz LPF in/out.  If it doesn't interact with the 12/10 filter, it can remain in line.  Otherwise we would need to switch the 12/10 filter on T/R.  It would be nice if no T/R switching were needed on the filter board if only to reduce relay clatter.

I don't think you are proposing removing the 35 MHz LPF because that would require that an external filter always be present.

 

**10/12M filter always in place, no relay. This would be the reconstruction filter for RX and would have to be good through VHF. The KX2 schematic has such a filter always inline, so I find it hard to believe it would contribute excessive loss.

I think the reason the KX2 and other designs have a LPF which is always in line is to avoid the bleed through around the relays that would reduce attenuation at VHF/UHF.  They need this because they cover 6 meters and the third harmonic is at 150 MHz.  Our highest third harmonic is at 90 MHz.  I measured the attenuation of my Rev D board with only the HPF and 12/10 filter in line and got the following:

MHz             30    40    50    60    80    100    160

Atten dB    01.4  -16   -31   -47   -44    -40     -36

This board is not final, but so far it looks like attenuation is sufficient at VHF, and that we do not need a permanent 12/10 filter.  If we do need it, we would have filter interactions with the lower bands again.

 

This would require only 4-5 relays so there would be room on the board for higer quality low loss 10/12M filter.

Yes, we could use the Coilcraft spring coils that have triple the Q of the ASIC parts.  But maybe the ASIC parts are OK anyway if the 12/10 filter is not always in line.

So I am fine if you want to make this change, and I am fine if you decide not to.  What do others think?

Jim

N2ADR 

[Graeme Jury]

Hello Steve and group,

Sorry I did not get back to you yesterday but it was Fathers Day in ZL and all the kids and grandkids arrived so radio stopped for the day. Thanks for the hint on abstract programming :-) and I had already been using this to distinguish between a Tx and Rx filter command but I guess that will become redundant now.

I'm sorry to go on about this but I am still unclear on how the I2C data will be sent. I'm fine with the addressing etc. but it is the data and its order that still eludes me. In Alex the data is on SPI but that is not important but what is, is the fact that the filter word being sent is chosen as Rx or Tx filter by a Tx or Rx strobe line. I guess that for HL we can use the ptt as the strobe line so it is possible to know if the data byte being sent is for the HPF Rx bank or the LPF Tx bank by reading the ptt state (which means it must be stable first). In the case of shared filters for TX and RX they will simply receive the word that tells them to stay on the same setting as we change from TX to RX and vice versa.

The issue of startup needs to be clarified for me too. I am assuming that on boot up HL will send The filter values and probably in the case of TX could raise the ptt without applying any RF followed by the Rx filter value in conjunction with lowered ptt. There is also the possibility of using byte order so that the TX filter is sent first followed by the RX filter and ptt is don't care. For shared TX/RX filters they would simply get their value twice and there would be a glitchless latch.

Once a PC radio has discovered and connected to HL the filter switching would be under control of the radio but HL would need to know if the radio was sending single filter commands or HPF/LPF filter commands and translate them to a consistent output format on I2C. I gather from your recent comments Steve that any band change, frequency excursion beyond a filter edge, CW, external ptt or MOX will cause the ptt line and filter values to be sent. I'm a little unclear if both Tx and Rx (LPF and HPF) will be sent or just the appropriate filter to the ptt state plus the ptt value.

This may have been dealt with previously but due to the sheer volume of information which has been disseminated it is getting harder to wade through it all.

73, Graeme ZL2APV

[Steve Haynal]

Hi Graeme,

Glad you enjoyed Fathers Day! What can be done with the MCP23008 is very simple, it just holds the last 8-bit value sent to it. Below is a use example that may help. We can discuss your questions in the context of this example, but hopefully everything is clear from the example.

A filter designer designs a board with 3 filters: Filter A should be used for TX and RX 0-15MHz, filter B should be used for TX >15MHz and filter C should be used for RX >15 MHz. The MCP23008 drives a single 8-bit value that is held until another value is received. In his design, he has used bit 0 of this byte to enable filter A, bit 1 to enable filter B and bit 2 to enable filter C. The bytes are ordered msb down to lsb, binary b76543210 as in the openhpsdr protocol.

The HL2 is powered on. There is no filter selected as software is not connected so the MCP23008 outputs remain in the reset state, b00000000. Designers should consider this the no engaged filter state.

In the software he is using (this may be PowerSDR J16/Alex, etc, or Quisk, or SparkSDR) there is a configuration screen where he specifies the output value that is sent given the condition of RX or TX and the tuned frequency. So he enters:

b00000001 for TX <= 15MHz (or all bands less than 15MHz)

b00000001 for RX <= 15MHz

b00000010 for TX >15MHz

b00000100 for RX >15MHz

Now the software connects to the HL2. In the protocol from the PC, the HL2 receives b00000001 for RX and b00000001 for TX since the radio powers up receiving on 40M. Since this is different from the reset state of b00000000, the HL2 sends this value to the MCP23008. Note that software may or may not send this filter setting continuously, but the HL2 will only update the MCP23008 on change. Once the MCP23008 has received this value, it is held on the 8-bit outputs for as long as the MCP23008 is powered up and another command is not received. This value drives the intended relays or PIN diode switches.

Next, the user decides to transmit on 40M. The software may send a filter setting update. The HL2 has remembered the current RX and TX filter settings. Since TX was enabled, the HL2 compares the TX filter setting with the last setting sent to the MCP23008. They do not differ, so the HL2 sends no update over I2C. This is as intended as the filter settings were designed to be the same for RX and TX <=15MHz.

Now the user tunes above 15MHz via band change or other mechanism in the software. The software knows this so sends the updated RX and TX filter settings of b00000100 and b00000010 respectively. Again, this may or may not be sent continuously but is sent by the software at least once. The HL2 remembers these as the current RX and TX filter settings. Since it is in RX mode, the HL2 compares the last filter setting sent over I2C with b00000100. They differ, so the HL2 sends the new RX filter setting over I2C to the MCP23008.  Now the MCP23008 is driving bit 2, the intended setting for RX >15MHz.

Next the user decides to transmit on 21.076 MHz. This TX may come from pressing the CW key or from the software. In either case, the HL2 has already been told the current filter settings. The HL2 compares the current TX filter setting of b00000010 with the last sent, sees that they differ so sends b00000010 to the MCP23008 over I2C. This does not require the PC in the loop. The HL2 sequences and delays the actual PA bias turn on so that there is some time for relays to stabilize before full power is applied.

The users releases the CW key or goes back to RX via another mechanism. The HL2 first turns of the PA and then shortly after sees that the current RX filter setting does not match the last value sent, so sends the RX filter setting of b00000100 to the MCP23008.

Next, the user tunes back to 40M. The HL2 only remembers the current RX and TX filter settings. On the band/frequency change, software sends the new current RX and TX filter settings to the HL2. As before, the HL2 is continuously comparing the current values against what was last sent, and if there is a change will send the new value over the I2C. Unlike traditional code, the FPGA consists of many machines or programs running in parallel. There is dedicated logic in the FPGA for these compares so the send over I2C always occurs ASAP. 

Finally, the user disconnects the software. The current RX and TX states go to the reset state of b00000000. This differs from the last value sent to the MCP23008, so the HL2 updates the MCP23008 to b00000000.

At some later point, the filter designer decides he needs to know if the HL2 is in TX or RX mode. He updates the encoding used with his filter board to:

b10000001 for TX <= 15MHz (or all bands less than 15MHz)

b00000001 for RX <= 15MHz

b10000010 for TX >15MHz

b00000100 for RX >15MHz

Now bit 7 will always be set if in TX mode. No changes need to be made to the software or HL2 firmware. Since the TX and RX filter setting values differ, the HL2 will send updates whenever a TX to RX or RX to TX occurs. 

73,

Steve

KF7O

[Graeme Jury]

Hi Steve,

Many thanks for the very detailed explanation which you sure went to a lot of trouble to do and I am very grateful. It has also enabled me to see what I have not been making clear to you so here goes again.

I am working on a filter which provides a subset of the Alex filter for hpsdr. In Alex fashion it consists of a bank of LPF's and a bank of HPF's which work in series with each other on receive and just the LPF only on TX. A band select for say 80M would send the value for the 4 MHz LPF and the 3 MHz HPF to form the bandpass. The HPF and LPF combination can be any filters from the set although you would obviously not use an LPF of lower frequency than its HPF partner.

Taking numbers from your example we turn on HL2 and default to 0b00000000 which operates the nominated default HPF and LPF which would be 160M HPF and 10M LPF in my case. We bring the PC software up and select the 20M band which is < 15 MHz so the correct LPF is set and we can decode that we are in RX mode with a Tx filter still at 30 MHz (the default which has not been changed yet) We then Tx and the 30 MHz LPF switches to the 15 MHz LPF and all is well with the receiver having its bandpass with the correct filters and the Tx operating with the correct LPF. Going between TX and Rx won't change any filters, only the series connection on Rx and the LPF only on Tx.
Now we change to 21 Mhz on Rx. A new receive value is sent from HL2 and the > 15 MHz HPF is switched in but the < 15 MHz TX LPF is unchanged and in series with the > 15 MHz HPF so no signal gets to the RX until we transmit and change that LPF.

The other thing that the filter set was going to offer was a band button assignment for skimming. Say we set a band button called SKIM1 for skimming 40, 30 and 20M and assigned the LPF at 14.35 MHz and the HPF at 6.5 MHz them clicking on that bandbutton would set the HPF but we would need to TX to set the LPF and would have to QSY out of RX HPF band to get to the band for the TX LPF.

I really can't see how we can avoid sending both filter values on a band change to make this filter or any other Alex look alike work. After that everything will work exactly as you described and for non cascaded filters sending the Tx filter first on bandchange immediately followed by the Rx filter would give such a tiny blip of High bit ptt that the relays wouldn't even twitch.

73, Graeme ZL2APV

[Steve Haynal]

Hi Graeme,

When I say the HL2 will use Alex fields, I do not mean full support for all of Alex, but a possible repurposing of the bits Alex was using for HPF and LPF. The filter interface on the HL2 is intended to be very basic, just an 8-bit bus expansion via the MCP23008. Still, I think what you want is possible. If I understand you correctly, you need both a HPF setting and a LPF setting included with each RX and TX setting. You can use the upper 4 bits to encode a LPF setting, and the lower 4 bits to encode a HPF setting. This allows you to select 1 of 16 filters for both HPF and LPF. This may be more then you need and 3 bits (8 LPF filters and 8 HPF filters) may be sufficient allowing for 2 extra bits to encode other information. So for your example the 20M encoding might be,

RX = 0b0000_0010

TX = 0b0011_0010

So that RX always selects the 10M LPF (0000) and maybe 40M HPF 0010 for skimming during RX, but TX always selects the 20M LPF (0011) and again maybe 40M HPF during TX. Again, the encodings are entered in the software to setup your particular filter board. They would be different for another filter board design.

[Steve Haynal]

Hi Graeme,

Another way to send both HPF and LPF selections to the filter board with more bits would be to use the MCP23017. That is also listed on the schematic. I had that in mind if more bits were ever needed. I will support the MCP23008 first, but don't mind adding support for the MCP23017 later. The HL2 firmware will already have both the TX and RX filter setting bytes (or HPF and LPF bytes if you reinterpret their meaning) so it is a minor change when talking to the I2C IP whether to send 1 byte or 2 bytes. The firmware will not be autodetect, but we can repurpose a configuration bit to indicate if there is a MCP23008 or MCP23017 connected. A user would still have to "program" the software with all the correct band encodings for your filter board, but your board would receive both bytes on any change.

73,

Steve

KF7O

[James Ahlstrom]

Hello Graeme,

I only just now understood the problem you were trying to explain.  Steve gave one solution.  Another is to ignore the separate Rx filter settings and send only the Tx settings.  These will give the band or frequency, not the real filter settings.  As a crazy example, filterTx = FreqMHz / 0.25 MHz will code the frequency 0 to 30 MHz as a number from 0 to 120.  Then your microcontroller will chose the filters from the frequency.  For special cases, the numbers 121 to 127 (for 7 bits) are still available.  If you need the T/R status, it will be on CN7 pin 1.  PowerSDR allows arbitrary 7-bit "filter settings" per band as does Quisk, so you can code the band in use to any number you want.

Jim

N2ADR

[Steve Haynal]

Hi Jim and Group,

Thanks for the feedback. You are right that some users, such as RBN, will need the 35 MHz reconstruction filter and can't rely on an external filter board. I will try to accommodate that with any redesign.

My current plans are to quickly get in all the essential beta3 changes into a beta4 release. I actually will not build and test this version as it will be so similar to my beta3 plus modifications, but will make the files available for PCB production and even a small group buy if someone else wants to organize that. The beta4 version will have the same filtering as the beta3, and remove the U18 opamp. This should happen in the next week or two and is mainly there to satisfy some who have been asking for current board files.

After that, I will work on HL2.1beta1. This version will have 3 larger changes:

* The HPF filter changes discussed in this thread

* Filters derived from you work included on a single 15x10 cm board. (This has always been my end goal for a radio...)

* Details worked out on a new 2-input op amp selection and FDW/REV power.

The intended PCB layout will be such that the extra filter board in the larger layout can be easily removed so that only the 10x10 cm board remains abd can be produced in the future too. HL2.0x and HL2.1x will be firmware compatible.

73,

Steve

KF7O

[James Ahlstrom]

Hello Steve,

On Monday, September 4, 2017 at 1:08:01 PM UTC-4, Steve Haynal wrote:

* Filters derived from you work included on a single 15x10 cm board. (This has always been my end goal for a radio...)

 

Of course you are welcome to my 5x10 board.  But to finalize the design I need to know if these changes are what you want:

1)  The 3 MHz HPF will be on the main HL2 receive path with suitable switching.

2)  The diodes are removed from U18 or U18 is removed, and the filter board must be able to drive U13 directly.  See very recent post.

3)  The 35 MHz reconstruction filter on HL2 is switched and won't interact with the 12/10 filter.

The above is not required, I just need to know if I have it right.

Jim

N2ADR

[Graeme Jury]

Hello Steve,

Excellent solutions :-) Yes if you can pack the Tx filter into bits 6..4 and Rx filter into bits 3..0 leaving bit 7 for ptt and bit 4 for any other use it would solve my problem perfectly. For those wanting a single byte of 8 bits they would be able to put the lower order in the RX field 0b0000nnnn and the upper bits in the TX field as 0bnnnn0000 and your software would concatenate them bearing in mind that bit 7 is reserved for ptt info and is duplicated on CN7 pin 1. If they wish to expand separate filters in hardware a pair of 3 of 8 decoders on the appropriate MCP23008 pins would do the trick.

mni tnx 73, Graeme zl2apv

[Steve Haynal]

Hi Graeme,

Just to be clear, I am not doing anything extra or defining any meaning to the bits. It is still the original solution I had in mind. It would be you and your filter board users who attach meaning to specific bits and "program" the software by setting/encdoging the fields appropriately to work with your filter board. You encode PTT into the byte by reserving 1 bit and then setting the fields in the software to be always 1 for TX and always 0 for RX. You create the proper concatenation of the HPF and LPF bits when you set the full byte in the software. There is no concatenation happening in the firmware. In your case, if you divide the 8 bits into some bits for HPF and LPF, you may have to redundantly specify the same byte for both HPF and LPF as the HL2 is not interpreting the Alex settings in the original manner. 

* Software defines 8-bits for RX and 8-bits for TX filter settings. Software is responsible for informing the HL2 at least when one of these change. Both bytes are always sent to the HL2 at least on change.

* The HL2 remembers the current RX byte, TX byte and the last byte sent to the MCP23008. Depending on the mode of the HL2 (RX or TX) the HL2 continuously compares the current filter byte with the one last sent to the MCP23008. If it is different, it sends the byte to the MCP23008.

* The I2C endpoint (MCP23008) simply generates and holds the 8-bits of data from the HL2. There is no predefined meaning or reserved bits in this byte.

73,

Steve

KF7O

[Sebastien F4GRX]

Hello

Do you plan to make an official HL2 release (not beta) before working on
the HL 2.1 beta 1?

Personnaly I have zero interest in a single big board with on board
filters. I want to roll my own (or, precisely, the ones from Marc F6ITU).

Moreover, the more we wait, the less FPGAs are available. At one time,
it will be too late.

I think that all of this filter design is taking all of you a lot of
time, despite filters being external, modular and replaceable, and
meanwhile, the HL2 project does not move forward.

Am I the only one waiting for a project release?

Thanks,

73's

Sebastien de F4GRX

> <http://www.elecraft.com/manual/E740324%20KX2%20Schematic%20Files%20RevA.pdf> has

> such a filter always inline, so I find it hard to believe it
> would contribute excessive loss.
>
>
> I think the reason the KX2 and other designs have a LPF which is
> always in line is to avoid the bleed through around the relays that
> would reduce attenuation at VHF/UHF. They need this because they
> cover 6 meters and the third harmonic is at 150 MHz. Our highest
> third harmonic is at 90 MHz. I measured the attenuation of my Rev D
> board with only the HPF and 12/10 filter in line and got the following:
>
> MHz 30 40 50 60 80 100 160
> Atten dB 01.4 -16 -31 -47 -44 -40 -36
>
> This board is not final, but so far it looks like attenuation is
> sufficient at VHF, and that we do not need a permanent 12/10 filter.
> If we do need it, we would have filter interactions with the lower
> bands again.
>
>
> This would require only 4-5 relays so there would be room on the
> board for higer quality low loss 10/12M filter.
>
>
> Yes, we could use the Coilcraft spring coils

> <http://www.mouser.com/ProductDetail/Coilcraft/132-14SMGLB/?qs=sGAEpiMZZMv126LJFLh8y87RAMOD9eCRrsUiolEKNRg%3d> that

> have triple the Q of the ASIC parts. But maybe the ASIC parts are
> OK anyway if the 12/10 filter is not always in line.
>
> So I am fine if you want to make this change, and I am fine if you
> decide not to. What do others think?
>
> Jim
> N2ADR
>

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

[Graeme Jury]

Hello Steve,

Yes I got the information 100% and it will work well for me and just as a
cross check here is how I would set up 2 filters for a band.

assuming my 40M LPF is TX filter 3 and my 40M HPF is RX filter 2 the
settings would be as follows for 40M band button

TX = 0b10110010 RX = 0b00110010

On receipt of an I2C byte my decoding software would look at bit 7 to see
if in TX or RX mode and mask off the lower 4 bits for RX filter and the
upper 4 bits for TX filter dropping bit 4 in each case to control up to 8
RX and 8 TX filters which will more than match the Alex board which
switches 6 filters and 1 through pass for both transmit and receive. As you
are doing I will be storing TX filter, RX filter and ptt in a struct and
will only switch on a change. The I2C is on a high priority interrupt.

73, Graeme zl2apv

[Graeme Jury]

Hello Sebastien,

I am one of the ones working on a filter board amongst several others. I don't have the skills to work on fpga firmware so my time is best deployed on peripherals to free Guys like Steve and other developers to get on with HL2. However at some point the protocol to interact with peripherals needs to be established so we can all get on with our tasks. The time on this is 1 off and won't need any more time from Steve as I will document this and add it to the wiki and leave him alone to get on with the HL2. You are being catered for as the filter board is an option and the information on how you can interface the filter of your choice will appear in the documentation. Don't forget this is a hobby and is done for free. Its not like a commercial development with project management and target dates.

73, Graeme zl2apv

> <mailto:hermes-lite+unsub...@googlegroups.com>.