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