Strange output power with lambda62 module

Same result with a l/4 antenna (and with another module, I’ve only used a ceramic antenna):

[2021-09-01 12:49:25.274] TX power : 0 dbm
[2021-09-01 12:49:25.342] tx begin
[2021-09-01 12:49:25.342] ticks=294387 freq=867700000 power=7  bw=125000 sf=8 size=73
[2021-09-01 12:49:25.566] Interrupt TX
[2021-09-01 12:49:25.582] tx complete
[2021-09-01 12:49:25.582] ticks=294641
[2021-09-01 12:49:26.588] rx1 slot
[2021-09-01 12:49:26.588] ticks=295633 timeout=28 lag=5 freq=867700000 bw=125000 sf=8
[2021-09-01 12:49:26.652] Interrupt RX
[2021-09-01 12:49:26.684] downlink: ticks=295739 rssi=-31 snr=10 size=16
[2021-09-01 12:49:26.700] link_check_ans: margin=17 gwCount=1

Base station receives: SNR=7 RSSI=-107

If you use a dipole-antenna (1/2lambda) this has to be connected to pin 1 and GND, if you use a monopole antenna this has to be connected only to pin 1 but with a length of 1/4 lambda.

But now you have the possibility the module is in someway damadged by being operated with an inapproriate antenna.

No, I don’t think. I have the same result with a module that was only used with a ceramic antenna.

Something easy to miss with these is that the Lambda62C - the ones with the shield can DO NOT have the antenna pathway connected to pin 1, but only to the u.fl connector where they hope you’ll attach the exact antenna used in the module cert.

I’m getting drastically better results using the u.fl connector, granted pin 1 is currently going into a breadboard with the others and would have huge capacitance to adjacent ground, so I should try clipping that to solder just an entenna, but it looks like C20 is not installed to enable pin 1.

I also feel like I have the RF switch working correctly via DIO2 to the TX switch and currently software (but eventually an inverter) driving the RX switch high the rest of the time.

Modules I use don’t have UFL connector. Of course, DIO2 is driven and I have verified that TX and RX switch signals have expected values.

Just to be sure: Your module has a green and a blue dot?

Yes. Green and blue dots (and a red on SX1262).

Another idea: what happens if you connect the (monopole) antenna to the small pad that is between the two larger pads (SK2)?

Which one ? The center pad of UFL connector ?

Yes, the center pad.

I have soldered an antenna directly on center pad. Same result. New test: I have soldered an antenna before RF switch. No change on RSSI (-102 dBm, expected value -45 dBm).

RSSI isn’t measured in dBm… really its a relative figure in dB referenced to just about nothing.

But apart from that, your experiences mismatch mine - and I’m still using intentionally low transmit power until the antenna switch situation is permanently solidified.

Perhaps you should get some magnification and see if C20 is installed or not - it’s pretty clearly labeled in the test report photos, and in a no-shield can module where it would allegedly be installed there’s no obstacle to seeing it.

You might also need to validate that your code is correctly setting the transmit power level, and that your power situation can actually support that. Underpowering the chip during transmit would not only not achieve the desired output, it would result in broadband splatter due to compression if not outright clipping.

Well, I did suggest it a while back, but I dont think you will progress much on this until you can measure the actual transmit power …

I have done some measurements. Current is around 45 mA when module emits @ 14 dBm (expected value given in datasheet) and I have directly connected pin 1 on a level meter (peak detection). RSSI given by my base station is the real value in dBm. I will try to do some other tests with a spectrum analyzer.

C20 is installed and don’t forget I have soldered a lambda/4 antenna before RF switch (and before C20).

In my first message, you have a transaction between CPU and SX1262. I have analyzed this transaction (and some others) and I don’t see where I could done a mistake.

It’s really not. RSSI is relative, not referenced to anything absolute, and without any absolute meaning after antenna-to-antenna coupling.

You could try writing a script to do a lot of transmit trials in a situation in a situation a a few meters away where you walk out of the area so that nothing gets bumped. For each transmit power level supported by the hardware, do about a dozen transmissions, but do them in random order. Then collect the uncalibrated gateway RSSI’s and plot them as a point cloud against teach other, commanded power vs receive RSSI (you could put the commanded power in the payload to make correlation easy).

Please have a look at Semtech “Corecell gateway Reference design EU version Performance Report Rev. 1.0” chapter 9.3 ff. Maybe we should tell Semtech that there is something wrong (or is it right??).

I am very sorry, but in the moment I have no clue whats going on with your module. 45mA should be ok for 14dBm but the RF seems to disappear somewhere.

If you have a ‘standard’ LoRa device, with the same antenna, that you can program for 14dBm then a nearby spectrum analyser or even cheap SDR, might give you a comparative result.

Unfortunately measuring the current consumption may not tell you much at all, if the antenna was a 50ohm load for instance, the current used might well be appropriate, but the actual radiated power would be very close to very little.

Nope. RSSI is a convenience metric. It’s NOT test equipment. It’s relative only - the units are at best dB"something example unique" NOT dBm.

And when the coupling is two antenna in a casual experiment, even that is in doubt.

That’s one of the reasons they need to try transmitting at a variety of power levels without even having their body present in the near field, and plot command transmit power over receive level in a large enough number of trials to really see what’s going on.

If after plotting a few hundred data points there’s a sharp and clear falloff in receive level at some increase in transmit power, then investigation can look into things like if the power register is being incorrectly set, if the power supply is incapable of that, etc.

Also steps should be taken to be sure that the receive frequency matches the command transmit frequency, and isn’t being confused by weak bleedover onto a different channel when the RX front end is funadmentally overloaded.

See figures 4-8, 4-9, 4-10 in the data sheet, think about the overcurrent protection register. make sure SetPAConfig is using an appropriate set of values for an SX1262 (vs 1261) and that the fine tuning value in SetTxParams is one for the mode being used, and not for the other mode.