search

sinara-hw / sinara

Sayma AMC/RTM issue tracker
Other
42 stars 7 forks source link

Booster RF PA v1 errata #251

Closed jbqubit closed 6 years ago

jbqubit commented 7 years ago
hartytp commented 6 years ago

@thomasRF

Yes, I ‘ll be able to do the discussed additional test, however, the only RF PA that I’ve made are in your possession. if you want, please send it (RF PA modules) along with the enclosure of the unit, which will be adjusted, and then I’ll carry out additional tests.

Don't worry about it, @cjbe has already done these tests and posted the results on GitHub. So, no need to do that.

At the outset, I would like to point out that during the project I have made changes of the schematics diagrams, but the schematics diagrams at the GitHub diagrams are from a few months ago.

Okay, good to know.

The RF PA amplifiers that I have made, which you have, consists of NPA1003QA transistors in the final stage, and the two preamplifier stages are built based on the MAAM-010373 and MMG3012NT1 transistors respectively. The stages are design to work with NPA1003QA. In the additional option with NPTB00004A instead of NPA1003QA, if the NPTB00004A transistor should be used, is required to change matching circuits in the preamplifier.

I see, so the NPTB00004A version hasn't been tested or built yet.

Well, unless there is a significant improvement from changing the final stage amplifier, let's stick with what we have (no point spending a lot of time testing a new power amplifier stage if the improvement is only marginal). However, if you feel that using the other transistor could offer a significant improvement then please explain what the benefits/trade-offs would be.

Please indicate what to do, what changes should be made (please remember that improving one parameter may worsen the other)

We are happy with the overall performance of the amplifier. If there are easy improvements you can make "for free" then please make them. But, it sounds like you've already done that and are at the point where any improvement in one parameter will make another parameter worse. If that's the case then let's leave the design how it is.

hartytp commented 6 years ago

To be clear: we are very happy with the cross-talk and noise performance. It meets our specification and is okay.

However, if this can be improved easily -- and without increasing the cost of manufacturing these amplifiers in a significant way or significantly increasing the design time -- then we should do it, as less cross-talk/noise is always better.

What I would like you to do is to write your report which has the current design and recommendations for how it could be improved, including reducing the cross-talk. These recommendations should include the cost of any changes you propose to make. If the changes are cheap and quick (e.g. adding a bigger capacitor or a ferrite bead somewhere) then we will implement them. If they are expensive (like using a much higher specification power supply) then we will not.

Our goal here is just to double check that there are no quick, cheap, easy changes we can make to improve the performance (which is already very good!).

jbqubit commented 6 years ago

@thomasRF Great documentation BTW. :)

thomasRF commented 6 years ago

@dhslichter

@thomasRF this looks very nice! I would say that we are definitely interested, based on these initial data. I have a few questions as well:

  • Figure 2 looks more like the 2.5 dB compression point -- at the 1 dB compression point, you should see that the gain is 1dB less than the small-signal gain, right?

The Fig.3 I’ve plotted again in Excel (for the same data – data_Ox1.xlsx), and 1dB compression point is for c.a. -2dBm input power. At the point the gain is decreasing by 1dB in relation to the ideal characteristic.

  • Edit: Fig. 3 looks like Psat is 36.5 dBm, not 37.5 dBm. Is this just amp-to-amp variability?

You're right, the correct value of Psat is 36.8dBm, and may vary slightly for individual RF. The Psat is 37.5dBm for the other operation point of the transistor in last stage.

  • Edit: the gain shown in Fig. 3 looks to have a nontrivial deviation from linearity over a long range (from -20 dBm to -4 dBm input powers, for example). Is this an artifact or real? If real, can it be improved?

This is a real measured characteristic, of course with a certain error. I can try to improve the gain characteristics, so that the variability of gain would be smaller, depending on the input power, however at the expense of impedance matching.

Nowadays, the correction of the characteristics is realize by using a digital pre-distortion technique. If we know how the gain changes as a function of the input power and frequency, it is sufficient to process the input signal (ie in this case its amplitude characteristic), so that we get a signal in the output of the RF amplifier, as though gained by a linear amplifier. If a source of a signal is a generator, it is sufficient to prepare specific source code for the program the generator. The designed RF amplifier module can provide information about the power of the output signal, which can be useful in a given solution.

Other characterizations that would be interesting to have (@hartytp may already have discussed these):

  • Noise figure
  • RF pulse response (in particular any slower time constant behavior e.g. from thermal effects)

@hartytp has written, that the tests, apart from the ones I presented, were made by @cjbe

  • Temperature coefficient of gain

Here I want to point out that in the current version of the RF PA, the option of temperature compensation of the gain is not turned on. Changes are required in the part of Greg (@gkasprow) , and I also need to change the RF layout, due to the change in the position of the temperature sensor. However, measuring blocks of input forward power and output forward and reflected power are implemented, which enable software compensation of gain changes as a function of temperature.

  • Crosstalk as a function of channel distance -- in other words, is crosstalk worse for nearest neighbors in the case and better as you move farther away? Or is it more uniform from any channel to any other channel?

As I've written, in the first place crosstalk limitation is a circuitry issue. The distance between the RF modules is of secondary importance. The presented values of inter-channel crosstalk are for the worst case, i.e. between neighboring channels (RF modules), measurements were made in a configuration as in the photographs presented by Greg (@gkasprow).

Is there data on how the amplifier handles poorly matched loads? How bad a mismatch can the amplifier tolerate on its output, especially at high power?

In the case of mismatch, the RF amplifier behavior is typical, i.e. the output power is reduced by the reflected power, where 50 ohms should be taken as the output impedance of the RF amplifier. If the mismatch is observed in the input of the amplifier, the forward (input) power will be reduced by the power reflected from the input (where Zin = 50 Ohms), there the output power will also be reduced. If you need more details about this effect, please let me know by email.

thomasRF commented 6 years ago

@dhslichter @hartytp

Is there data on how the amplifier handles poorly matched loads? How bad a mismatch can the amplifier tolerate on its output, especially at high power?

In addition, to protect the amplifier from damage, I’ve implemented the following three protection stage:

In addition, the amplifiers are protected against overload by monitoring of the voltage and current of power supply, as well as temperatures of the individual RF PA modules and the FR PA unit.

All comments, suggestions are welcome.

thomasRF commented 6 years ago

@dhslichter

@thomasRF some errata for the schematics:

Preamp protection:

  • Input SMA should appear where it's currently labeled just TP1.
  • Part numbers are invalid/garbled for many ICs. Amps and power detector IC6, IC7, IC8, IC9 all have part numbers that don't seem to correspond to any real parts that Google knows about. What are the actual part numbers for these?
  • CP2 needs a part number Notation should be made about the purpose and connectivity of the signals on J4 and J5, since they are routed to a separate board (PA_Channel_SUP_CTRL). Any critical inductors and capacitors in the amplification chain whose properties are important (particular voltage/current ratings, dielectric material for caps, core material for inductors, etc) should be called out.

Power stage:

  • IC3 part number doesn't correspond to a part Google knows about (MMWX1)?
  • Notations should be made for voltage/current/power ratings of passive components as appropriate. J3 should have a notation as to its purpose since it is connected to another board not in this schematic.

Output protection:

  • CP1 needs a part number
  • IC1, IC2 again have an invalid part number
  • Notations need to be made about the purposes of the signals on J1, since they go to another board.

Thank you for the comments. The schematics diagrams I’ll update, after that we determine the final RF PA parameters, and you accept the test results so that I don’t need to generate subsequent versions of the documentation.

thomasRF commented 6 years ago

@dhslichter @hartytp

If this is the Macom amplifier (NPTB00004A), the datasheet specifies no damage at a 15:1 VSWR, all angles (https://cdn.macom.com/datasheets/NPTB00004A.pdf).

It is correct at the datasheet of NPTB00004A specifies no damage at a 15:1 VSWR, and for NPA1003QA specifies no damage at a 10:1 VSWR, however I suggested to protect the RF PA by limiting acceptable reflected power to 30dBm (1W) CW, regardless VSWR value.

hartytp commented 6 years ago

@thomasRF thank you for the detailed response.s

This is a real measured characteristic, of course with a certain error. I can try to improve the gain characteristics, so that the variability of gain would be smaller, depending on the input power, however at the expense of impedance matching.

I wouldn't want to make the impedance matching significantly worse to improve the linearity. My view is that the current level of linearity is okay for our purposes (it's better than an AOM!).

Nowadays, the correction of the characteristics is realize by using a digital pre-distortion technique. If we know how the gain changes as a function of the input power and frequency, it is sufficient to process the input signal (ie in this case its amplitude characteristic), so that we get a signal in the output of the RF amplifier, as though gained by a linear amplifier. If a source of a signal is a generator, it is sufficient to prepare specific source code for the program the generator. The designed RF amplifier module can provide information about the power of the output signal, which can be useful in a given solution.

Good point. We can implement that later on in software with no hardware changes if we want so let's not worry about it for now. However, FWIW, this may not work so well for most of our use cases because the signal bandwidth is quite high.

stage No 1 (hardware protection) - the input (forward) power is measured, and if the given power is greater than -1.5dBm CW (i.e. 1.5dBm above the maximum expected value of the input power), the RF input power is immediately switched off. The value is fixed in hardware for CW power, I can change it, or set it for a specific signal (eg using a peak value detector), this value cannot be changed by the user.

stage No 2 (hardware protection) - the output power (reflected) is measured, and if the given power is greater than 30dBm (1W) CW (which can be additionally dissipated on the power transistor in the last stage of the RF PA), then the RF input power is immediately switched off, regardless of the of the measured VSWR value. The value is fixed in hardware for CW power, I can change it, or set it for a specific signal (eg using a peak value detector), this value cannot be changed by the user.

In addition, the amplifiers are protected against overload by monitoring of the voltage and current of power supply, as well as temperatures of the individual RF PA modules and the FR PA unit.

That sounds like a very good idea. This ensures that the amplifier itself cannot be damaged from an excessive input power or over temeprature etc! (NB this stage mainly protects the amplifier, not the load).

stage No 3 (software protection) - VSWR is measured at the output of the RF amplifier, based on the forward and reflected power. The protection stage works in the way that the processor can switched off the RF input power for a specific VSWR value. The value at which the RF input power is switched off is determined by the user by defining it through a dedicated application for monitoring and controlling the RF amplifier. Currently, the VSWR is determining on the basis of the measured CW forward and reflected power incident and reflected in the RF PA circuits,. I can adjust that the VSWR measurement should be made for a specific type of signal (eg pulse).

From a hardware perspective, that sounds great. We can discuss the software later on.

FWIW though, I do not think we need to have a software interlock for the VSWR. The amplifier itself is protected from reflected power by the hardware interlock in stage 2 and VSWR will not damage the load. It is useful to be able to monitor the output VSWR via software though, even if it's not interlocked.

AFAICS, the only use for the software interlock is to protect the load from excessive input power, so the software just needs to ensure that the max output power never exceeds a programmable threshold.

hartytp commented 6 years ago

It is correct at the datasheet of NPTB00004A specifies no damage at a 15:1 VSWR, and for NPA1003QA specifies no damage at a 10:1 VSWR, however I suggested to protect the RF PA by limiting acceptable reflected power to 30dBm (1W) CW, regardless VSWR value.

Sounds like a good idea!

hartytp commented 6 years ago

The schematics diagrams I’ll update, after that we determine the final RF PA parameters, and you accept the test results so that I don’t need to generate subsequent versions of the documentation.

We accept the RF PA parameters and test results, so please finish off the documentation! Please make sure to include any recommendations for future improvement (e.g. extra power filters to improve channel-channel isolation).

thomasRF commented 6 years ago

@hartytp

@thomasRF thank you for the detailed response.s

This is a real measured characteristic, of course with a certain error. I can try to improve the gain >>characteristics, so that the variability of gain would be smaller, depending on the input power, however at the expense of impedance matching.

I wouldn't want to make the impedance matching significantly worse to improve the linearity. My view is that the current level of linearity is okay for our purposes (it's better than an AOM!).

Nowadays, the correction of the characteristics is realize by using a digital pre-distortion technique. If we know how the gain changes as a function of the input power and frequency, it is sufficient to process the input signal (ie in this case its amplitude characteristic), so that we get a signal in the output of the RF amplifier, as though gained by a linear amplifier. If a source of a signal is a generator, it is sufficient to prepare specific source code for the program the generator. The designed RF amplifier module can provide information about the power of the output signal, which can be useful in a given solution.

Good point. We can implement that later on in software with no hardware changes if we want so let's >not worry about it for now. However, FWIW, this may not work so well for most of our use cases >because the signal bandwidth is quite high.

stage No 1 (hardware protection) - the input (forward) power is measured, and if the given power is greater than -1.5dBm CW (i.e. 1.5dBm above the maximum expected value of the input power), the RF input power is immediately switched off. The value is fixed in hardware for CW power, I can change it, or set it for a specific signal (eg using a peak value detector), this value cannot be changed by the user.

stage No 2 (hardware protection) - the output power (reflected) is measured, and if the given power is greater than 30dBm (1W) CW (which can be additionally dissipated on the power transistor in the last stage of the RF PA), then the RF input power is immediately switched off, regardless of the of the measured VSWR value. The value is fixed in hardware for CW power, I can change it, or set it for a specific signal (eg using a peak value detector), this value cannot be changed by the user.

In addition, the amplifiers are protected against overload by monitoring of the voltage and current of power supply, as well as temperatures of the individual RF PA modules and the FR PA unit.

That sounds like a very good idea. This ensures that the amplifier itself cannot be damaged from an excessive input power or over temeprature etc! (NB this stage mainly protects the amplifier, not the load).

stage No 3 (software protection) - VSWR is measured at the output of the RF amplifier, based on the forward and reflected power. The protection stage works in the way that the processor can switched off the RF input power for a specific VSWR value. The value at which the RF input power is switched off is determined by the user by defining it through a dedicated application for monitoring and controlling the RF amplifier. Currently, the VSWR is determining on the basis of the measured CW forward and reflected power incident and reflected in the RF PA circuits,. I can adjust that the VSWR measurement should be made for a specific type of signal (eg pulse).

From a hardware perspective, that sounds great. We can discuss the software later on.

FWIW though, I do not think we need to have a software interlock for the VSWR. The amplifier itself is protected from reflected power by the hardware interlock in stage 2 and VSWR will not damage the load. It is useful to be able to monitor the output VSWR via software though, even if it's not interlocked.

AFAICS, the only use for the software interlock is to protect the load from excessive input power, so the software just needs to ensure that the max output power never exceeds a programmable threshold.

All right. The software we will discuss later, however, I have one note:

The RF PA without VSWR hardware-software protection stage is exposed to damage considering the long-term inconvenient working conditions, when hardware implemented interlocks will not activate. The hardware interlock are working for critical events only. Moreover, during the experiment, the VSWR will inform user, what is the power on the load, takin into account forward and reflected power. Each parts of hardware in the RF PA circuits are implemented, there only remains software integration.

thomasRF commented 6 years ago

@hartytp

The schematics diagrams I’ll update, after that we determine the final RF PA parameters, and you accept the test results so that I don’t need to generate subsequent versions of the documentation.

We accept the RF PA parameters and test results, so please finish off the documentation! Please make sure to include any recommendations for future improvement (e.g. extra power filters to improve channel-channel isolation).

ok.

gkasprow commented 6 years ago

@hartytp I found why the amplifier was "singing" while loaded. There were 2 sources - SMPS module and the LDO. The SMPS generates some acoustic noise when not loaded. It was not sufficient power (fans) so I replaced it with much better, resonant one that is quiet. Another issue were 30V LDOs that became not stable with higher load. There was just compensation capacitor that needed modification. Under load it produced 2V pp ripples at 29V rail so that's why you saw low frequency components in the output spectrum.

hartytp commented 6 years ago

Great! Good catches greg

gkasprow commented 6 years ago

Recent photos: 2018-04-10 20 31 21

gkasprow commented 6 years ago

@hartytp do such cutouts in the front panel lip do the job for you? obraz

gkasprow commented 6 years ago

The side effects are:

So I don't like this solution. Is that so important to be able to open the modules when they are assembled?

hartytp commented 6 years ago

So I don't like this solution. Is that so important to be able to open the modules when they are assembled?

I agree. That's not so nice. I also don't like the fact that those cuts would be visible from the exterior of the chassis.

hartytp commented 6 years ago

If the modules are easy to insert and remove (I believe that they will be once we've fixed the other issues we discussed) then it isn't important for the tops to be removable in situ, so let's not bother with this.

hartytp commented 6 years ago

TBH, my original idea was to just move the screws a bit further away from corner of the module so that they aren't covered by the panel. The downside is that the lid won't make such good contact with the rest of the enclosure at that edge, but I'm not sure if that really matters.

gkasprow commented 6 years ago

OK, I will try to move them a little bit.

hartytp commented 6 years ago

Well, don't worry if it's hard/will compromise the design. If there is no easy fix, the current situation is fine.

gkasprow commented 6 years ago

well, the fix is easy, but I can break many things because there are tens of relations in the mechanical design. The screw positions are references for other components so have to be extremely careful modifying it.

hartytp commented 6 years ago

In that case, let's leave it as it is now.

gkasprow commented 6 years ago

@hartytp the module fixing will be done using 2 torx screws. I will use stainless steel ones for best visual effect. obraz

gkasprow commented 6 years ago

entering DFU bootloader will be possible by pressing hidden button with a needle or stick obraz

gkasprow commented 6 years ago

There is also option to enter bootloader mode using software command but this needs to be tested.

hartytp commented 6 years ago

There is also option to enter bootloader mode using software command but this needs to be tested.

That's definitely my preferred way of doing this.

entering DFU bootloader will be possible by pressing hidden button with a needle or stick

But, that's completely acceptable and we have more important things to work on right now.

hartytp commented 6 years ago

@hartytp the module fixing will be done using 2 torx screws. I will use stainless steel ones for best visual effect.

Looks good!

It's hard to tell from your CAD model, but is the idea that the SMA cutouts will be large enough for the SMA nut + star washer to fit through the cutout? That way, the front face of the module can mate directly with the chassis front panel, rather than having the SMA nut+washer between them.

Edit: to be clear, my idea is that the SMA nut tightens against the RF module (not against the chassis FP), but protrudes through the cutout in the chassis FP.

gkasprow commented 6 years ago

At the moment there is no washer between RF module wall and the SMA nut because there were no space to fit it below the panel. If we get rid of the second outer nut, we can make bigger hole in the panel but aesthetics will suffer. Look here obraz With such configuration, the washer will fit easily

hartytp commented 6 years ago

A washer isn't really necessary if there is a proper D-shaped cutout in the RF module enclosure.

However, I think it would be best from a mechanical stand point if the RF modules mate directly with the chassis FP, rather than having a nut in between them. Do you agree?

The mechanics matters more to me than the aesthetics, but anyway, I don't think the aesthetics are too bad if the cutout is large enough for the SMA nut to fit through it.

hartytp commented 6 years ago

Okay, I hadn't realised that you currently have a cutout in the front of the RF modules, so that the nuts are recessed in the RF modules, and the RF modules do currently mate directly with the chassis FP.

In that case, you don't need bigger cutouts in the FP to let the nuts protrude through.

So, do it whichever way you think is better/cheaper to produce/more aesthetic.

gkasprow commented 6 years ago

moving all new issues to new repo