HL2-MRF101

[Matthew]

I have failed to reply to any messages on this group for the past few days. I am trying a new message in case that works.

A note of caution to anyone powering up any HL2-MRF101 PA boards. I blew my MRF101 FET last weekend (current limited supply, low VSWR on the antenna). Mathis also reported blowing a FET. Mathis and myself are the only 2 people I know who have successfully powered up boards and used them on the air.

I have had some dialog with Jim WA2EUJ he has some suggestions for modification to try and reduce this risk. I will report back when I find some time to sit down and try this.

In the mean time, in response to the other thread title, I would still consider this an experiment and not suitable for others if you aren't prepared to buy new FETs if/when you blow them.

73 Matthew M5EVT.

[Jonathan Kelly]

Hi Matthew,

This is my first post on here, after building three of these recently I felt the need to point a few things out.

I'm now reliably getting 100W on all bands with good reports. There are quite a few changes required to get the 

PA system working properly. George M1GEO has been quite busy recently, so I took the time to build and get these working for him.

So a few points, all entirely reproducible on the other boards. I don't want to post definitive values here until 

they reach some kind of approval, they work for me on all three boards. See my twitter @GW2HFR for images. 

1. The bias compensation network overcompensates, this is probably why your MRF101 blew, I have some new values, but the main issue is with the layout in relation to the 

high dissipation components next to the Zener reference diode D4. Its still not perfect, but the values I've used keep it reasonably under control.

2. The input attenuator is too big, I reduced this down to 4dB. On 10m you cannot produce enough drive to the MRF101 according to Jim's original figure of 1.7W input power.

Will need to put this on the spectrum analyser in work to verify if I can get the same linearity numbers as Jim. The design still seems happy with the lower bands requiring slightly less drive,

no need for any input protection.

3. The main problem with 10m is the layout change on the output network across the PC board is that you need to change C66 to 82pF. I swept this with my NanoVNA. Maybe 

a more "perfect" value, its what I had here and it restored the gain at higher frequencies. 

4. The 10m LPF values are not optimal, change to T50-10s 8T and reduce C6 and C31 to ~ 91pF 

5. Software bug with the MCP4561, it peaks / overshoots during its adjustment range. Could be SparkSDR or gateware. It gets there, but there is a bug with the byte handling or something like that. 

6. K11 K13 wrong on BOM, expensive relays this needs to be changed to avoid a copy and paste purchase error ;) 

7. 160m has slightly less OP power due to heating in the dir coupler T2, compromise using 61 material. Its OK for me. 

If you want a sked to hear it on air I can do 80m, send me an email via QRZ address. 

Hope this helps, I'm not advocating this to be the official set of changes, its up to the publisher of the design. 

But it is important that they are fixed, just sharing what i've found to work for me. 

Jonathan GW2HFR 

[Matthew]

Thank you for your notes.

I probably won't have time to properly look at this until the weekend, but from a quick scan, some of your observations triggered memory cells from early 2020.

I have been thinking about an update to the board to allow for fan control and try to reduce the noise on the temperature and current signals. I would be interested to see a suggestion for improving the bias circuit layout - do you have kicad and could you share a suggested layout?

73 Matthew M5EVT.

[Matthew]

Hi Jonathon,

Firstly, thanks for taking the time to share your findings. These are really great observations and contribute to hopefully improving the amplifier for everyone.

Addressing your points in detail:

1 - Could you share your circuit/values for this? In addition, as I said in my previous message, I am thinking about *maybe* up-issuing the PCB design, so it would be good to incorporate any suggestion for improved routing of the bias circuit.

2 - Agree. Mathis reported that he changed his attenuator to 3 dB but this seems to have fallen off being transferred through to the schematics. I think for heat management this could be even less. However, it increases the risk of someone putting too much power into the amp. Additionally, these measurements show lowering the power from the HL2 also increases the IMD. So on balance 3/4 dB seems sensible.

4 - Agree. As an aside, the 30/40m LPF still has some room for improvement to be made for 30m.

5 - For the bias, all the address/data etc. is controlled by the SparkSDR, the HL2 doesn't play too strong a part in this. We would have to get some input from Alan (SparkSDR author) to understand if there is anything odd that could be going on here. Crucially, this same bias adjustment method is used for the bias on the HL2 PA. linHPSDR (linux only) has the option to set the bias and this is what I used. I didn't notice any odd behaviour. Were you able to see this directly through a jump in the bias current?

6 - Agree. In defence it has been in the issues list since December :)

7 - Agree. This is another one that has got lost in the archives. The Alex HPSDR board uses an FT50-43 and is spec'ed for 100 W. I think I may change to this and do some heat tests on the cores to confirm.

3 - I feel like there is an opportunity for me to learn something here. I have setup a simple test bed with the transformer:

- I am connecting my VNA to pin 2 of the transformer. I connect a 12 ohm resistor (per MF101 datasheet we are told the FET presents as a load impedance of 11.3–j6.4) between transformer pin 1 and GND.

- In parallel with this resistor I have swept with an 82p and 220p cap. At 28 MHz with an 82p cap I see |Z| = 98. With a 220p cap I see |Z| = 54.

So with the 220p cap we see a good |Z| approx = 50 from 160m to 10m. As I said, I'm hoping I can learn something here by an explanation of your choice to replace C66 from being 220p (per Jim's design) to 82 pF.

In addition to the above, Jim WA2EUJ suggested the 4.7 uH version of the transformer is a better choice for this design (because 6m is not used). I plan to fit mine at the weekend and hopefully reduced current drain on 160m and 80m.

Once again, thanks for your contribution - this is how open source succeeds. I look forward to your response.

73 Matthew M5EVT.

On Monday, 8 February 2021 at 03:23:56 UTC jonathan....@gmail.com wrote:

[mathis.s...@gmail.com]

Dear Jonathan,

Awesome, thank you very much. It's great to see people using and working on the PA design! :) I'd be more than happy to give you write access to the repository if you want to push something there.

Best 73s,

Mathis, DB9MAT

[Jonathan Kelly]

Hi Both,

Thanks for publishing it Mathis, its a good design including what most of us would want out of a companion PA system for this awesome little radio

To be clear, I'm not a KiCad user, I mainly use Altium through a license that hasn't expired yet for my own use. Its unlikely I'll have the time to make 

another revision of this, but I think its good enough at the moment to be used successfully.

Matthew, thanks for the comments. See below.

1 - Could you share your circuit/values for this? 

I'll read my notes over this weekend, i'll reply with some values that keeps the bias range and reduces the compensation action. The impedance through the digipot means that the current drawn through the bias network isn't the same as Jims original design. Theoretically it should be, but this circuit doesn't behave correctly across three boards. On my 1kW LDMOS amp I use a thermistor strapped across the adjustment pin of a linear regulator, that works really well. 

2 - However, it increases the risk of someone putting too much power into the amp. 

I know traditionally LDMOS devices are venerable to excess gate drive, the MRF101 seems to handle 3W OK if an overdrive event did occur. Zener / TVS network would be nice, but its not really essential. I used 2*430R for the shunt and 47R for the series, giving 4dB attenuation.

 

4 -  some room for improvement to be made for 30m.

Yes, 30m does suffer slightly as does 15m. With limited GPIO expander options the filters have been designed to extend out as much as possible, it works, but it seems an unnecessary compromise just to make it work with existing software. 

3- I am connecting my VNA to pin 2 of the transformer. I connect a 12 ohm resistor (per MF101 datasheet we are told the FET presents as a load impedance of 11.3–j6.4) between transformer pin 1 and GND.

In parallel with this resistor I have swept with an 82p and 220p cap. At 28 MHz with an 82p cap I see |Z| = 98. With a 220p cap I see |Z| = 54.

So with the 220p cap we see a good |Z| approx = 50 from 160m to 10m. As I said, I'm hoping I can learn something here by an explanation of your choice to replace C66 from being 220p (per Jim's design) to 82 pF.

So the figure you have there is optimised for 13.56MHz (11.3–j6.4) wereas the figure of 12.9 – j5.3 is more correct for 29MHz operation (Page 12). But that's only marginally out, yep I agree that all makes sense and computes here too. I need to perform a similar measurement here to find out why lowering the capacitance improved or "restored" the HF gain of the PA. There maybe some small signal / large signal  power dependant variability happening here. As a professional, I will often use the theory to get close and then tweak the circuit values to get the desired performance, that's all I did here. As Jim pointed out earlier, the layout has longer tracks across the PCB, which is also a 4-layer stack up. In short, I don't have an exact answer, but it does work. 

5- Were you able to see this directly through a jump in the bias current?

Yes, it appears to spike using a DMM on the drain as you can see the test probe is pinched into the screw terminal block. Again, does this on all three boards and it happens on the same input numbers through SparkSDR. Not tried any of the Python stuff yet. 

Thanks for the input Matthew, the OP transformer change sounds interesting, although the transformer used now hardly gets warm in use. Just want to make some more QSOs and build the switcher up next, I'll post more as we go. Too many projects during these crazy times we live in. Keeping me focused though.  

Jonathan G2HFR

[Matthew]

Hi Jonathon,

I have been running some tests with a heat gun to (in a controlled way) heat up the PCB area and monitor the bias compensation. I would be interested to experiment with the values you settled on.

73 Matthew M5EVT.

[Matthew]

I have finally found some time to return to this board this weekend.

I have replaced the directional coupler with FT50A-37. 20 turns on each. I spent some time studying the excellent blog post by K6JCA here and re-produced his calculations. I was satisfied that at 100 W 20 turns on the A (or a stack of 2 FT50-37) was sufficient. In addition Owen Duffy has some good material here (supported this this and this). Testing on the bench confirms things match up with the calculations. To support this I swapped R5 and R4 (and on the other side too) so that the 47k and was in series and the 100k to ground). I always have to spent far long thinking about transformer dots than I would like, but Claudio points out here some important comments about this. I wound mine, thought about it, then checked and noted Marc had wound his the same so I think I got my "dots" correct this time :)

I have changed to a 3dB attenuator. Heating is much less. I satisfied myself that IMD from the HL2 PA was ok at reduced power.

I moved the zener D4 to the the drain of Q2. There is a ground via perfectly located nearby to solder the other end to. This is the least heat affected part of this bit of the PCB. I then removed R29 and put D5 from the wiper of the digi pot to ground. Thermal testing shows this is much less aggressive in compensating. If anyone reading this has built one of these boards, I strongly urge to you consider this mod. The MRF101 is not cheap to replace.

I changed the LPF per Jonathon's cap value and swept with the VNA again. I also tweaked the 30/40m LPF and added a 33 pF cap in parallel with C27. A bit of squeezing windings and I get a much better impedance on both bands now.

I've changed to the 4.7 uH version of the output transformer and see less current draw on 160m and 80m now. Additionally, as a result of the 10m LPF tweaks, my problems with power output on 10m have now gone.

While I had the MRF101 FET removed I swept the VNA across C66 with the 10m LPF engaged and terminated into a 50 ohm load. With a C66 = 82 pF, |Z| = 18.5 (12.7 + j13.5), C66 = 220 pF, |Z| = 13.3 (0.3 + j13.3). I didn't have a high voltage 82 pF capacitor to test on tx. I concluded that I will keep the C66 at 220 pF now that I see full 100 W output with reasonable current draw.

[Oliver Kudalski]

hi i would be interested in a pa pcb can i get one?

[Matthew]

Hi,

I don't have any PCBs I'm afraid. You can find the gerbers to order a board here:

https://github.com/mathisschmieder/HL2-MRF101

Most PCB fab houses have a minimum board order, but I'm sure others would be interested in taking some boards from you.

73 Matthew M5EVT.

[Matthew]

I have updated the HL2-MRF101 project to r0.4 to fix a number of issues/improvements commented on in this thread. r0.4 is here. I have issued a PR to DB9MAT to get it into the remote master.

I have concluded that the ADC chip on the HL2 i2c lines is not the best method for this project. I will design a small PCB with a micro-controller to:

- monitor FET drain current;

- switch on/off voltage supply to the FET (and option for PC to send command to do this based on SWR reading);

- monitor FET temperature.

This micro-controller can then talk to the PC (via HL2) on the i2c lines. This places less demand on the HL2 and PC software.

For anyone building one of these PCBs, I suggest don't source components for current monitoring or the ADC and we can address these functions with this breakout board in future.

I'm aware of around 4 of these PCBs being built and used. Does anyone want any advice modifying existing builds to improve/fix thermal tracking for the FET or getting them going?

73 Matthew M5EVT.

[Jonathan Kelly]

Hi Matthew,

I've been using the PA for some months now with good reliability, still on the same MRF101 and I've had good reports. 

Could you elaborate on the choice for an intermediate MCU ? I spoke to George the other night and casually we assumed it was

due to the bus already having a high loading from devices using it on HL2. 

In theory I suppose you could 'gather' samples from the current sense and temp sense using the MCU and then send them to the FPGA in one hit, rather then sporadic gathering from each sensor overloading the i2c bus ? Sounds like a firm approach, but I'd like understand your thinking more. 

In the meantime, I've designed and made a 50V TL494 boost converter specifically for the project. It has additional output ripple filtering and is switched using the PTT line. This means the switcher is inactive on RX. I would like it to be considered as part of the overall project as it compliments it well. 

I'm nearly ready to integrated this into a 3D printed box and PCB front panel, but providing the PCB doesn't change in shape, it would be OK for a respin of the design here.

We could always do a Zoom  or Teams call if you like ?

Regards,

Jonathan GW2HFR

[Alan Hopper]

Hi Jonathan,

I really like the idea of the ptt controlled switcher.

73 Alan M0NNB

[Matthew]

Hi Jonathon,

The boost converter sounds interesting. It would be good if you could share some more details with the group.

A couple of ideas behind the MCU:

• Firstly, no software (as far as I'm aware) apart from my linHPSDR fork is reading the data from the ADC. The gateware has no module to read from the ADC, the i2c reads are all done via the PC software. That means that to encourage a PC software developer to support this, they need to delve in to the depths of the ADC datasheet, initialise registers etc. An MCU can do all this and then the PC software just has to read from a single i2c addr.
• You are correct that lots of requests from a PC to do i2c read/writes starves the normal command and control messages (temp, current, fwd/rev pwr) from the HL2, look at "Base Memory Map when ACK==0" here. As a result of the high noise I observe on the ADC signals, I had to do quite a lot of filtering in software. Such filtering can be done in the MCU, and/or give out peak/average values for Id.
  
• If a (potentially fatal) surge in drain current is measured, the MCU can (optionally) react and shut down the supply (with a high side FET) significantly quicker than doing this to and fro the PC.
• I have separate fans for my MRF101 heat sink and the HL2. The FPGA gateware only turns on the fan when the HL2 temp goes over a certain temperature, this cannot be controlled by software. Therefore, using the fan control on the HL2-MRF101 board for the MRF101 fan will result in sub-optimal thermal profiles.
  

I'm a bit side tracked with a transverter card for the HL2 at the moment, but I hope to prototype a small MCU PCB soon to test these concepts.

73 Matthew M5EVT.

[Matthew]

I have designed, built and tested a small PCB to interface to the HL2 and the MRF101 PCB to report to the PC; temperature and current. There is also fan control, and generic IO control. This is geared towards remote operation.

https://github.com/m5evt/hl2_extpamon

I've modified linHPSDR to work with this, but it also can be used with the port 1025/hermeslite.py method. I am guessing a NodeRed based approach could get data from port 1025 on the HL2?

With the addition of an i2c extender, I don't see why this would not work with a hardrock50 etc., or a homebrew amplifier.

I have 4 spare PCBs. If anyone would like one, please get in touch. Unfortunately, when I was formalising the BoM today, I noticed that even some basic components (e.g. a 1N4148W I ordered recently) are reporting next in stock Q3 2022. However, the design is generic enough that there should be plenty of alternatives.

73 Matthew M5EVT.

On Friday, 9 July 2021 at 14:21:16 UTC+1 jonathan....@gmail.com wrote:

[Steve Haynal]

Hi Matthew,

Sounds great! Please add links to the wiki pages so people can find this work!

73,

Steve

kf7o

[Jonathan Kelly]

Sure Probir,

I have a .STL design for a 3D printed case too (see my twitter)

On holiday at the moment so will share later on the wiki or separate git account. 

Not sure yet, give me some time please, I'm very busy towards the end of the year.

Best regards,

Jonathan G2HFR

On Mon, 1 Nov 2021, 05:00 Probir, <probir....@gmail.com> wrote:

Hi Jonathan,

 

Could you please share DC converter details – the schematics and the gerber files.

 

Best regards,
Probir Debnath

--
You received this message because you are subscribed to the Google Groups "Hermes-Lite" group.
To unsubscribe from this group and stop receiving emails from it, send an email to hermes-lite...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/hermes-lite/30b5e82b-9f7b-41b2-ade0-7f1d8abf5a8an%40googlegroups.com.