The sx1262 datasheet shows reference designs using a PE4259 RF switch. Seems to have slightly better specs than the CEL one, but it’s a “reflective switch”. I’m not sure I really understand the tradeoffs there… Uhh, lemme rephrase that: I’m sure I don’t understand the tradeoffs there! Is that so you forsure burn up the PA should you TX into a mistakenly closed switch???
Also, the control input Vhigh is 0.7xVDD and min VDD is 1.8V, so that makes it compatible with running the battery all the way down… Plus it’s not insanely small and it’s in stock at digikey. Choice made.
Something odd I noticed, Semtech puts a 100ns RC filter on the RF switch control line. I wonder what that’s about. Maybe it has to do with the built-in DIO2 switching…
I think I wasn’t clear… In the radio you can set the output power with a 1dBm granularity. If you select RFO-LP then the range is from -17dBm to +14dBm, if you select RFO-HP then it’s from -9dBm to +22 dBm. The way the dBm control is implemented is by varying the voltage output by VR-PA. You can see this in Figure 4-8 of section 4.4.2 of the sx1262 datasheet. For example, for 6dBm power output VR-PA outputs 500mV, for 12dBm it outputs 1V, etc. So with your design you have effectively limited the choices of power output to -17dBm to 14dBm and 22 dBm. Power outputs from 15dBm to 21dBm cannot be accomplished. This can certainly be a valid design choice, but it’s something to be noted. (Caveat: I haven’t actually measured all this, but the datasheet seems pretty unambiguous to me.)
(In the github README you write “cultivating it into the ultimate reference design for low power RF”. I would respectfully argue that limiting low-voltage operation to 2.5V due to the RF switch choice (unless you change to the Infineon ones), and excluding 15dBm to 21dBm output power levels is not really compatible with that goal. )
Despite smaller size and lower cost, the default configuration of the SX1261 E406V03A reference design is powered by DC - DC. The benefit of lower power consumption, along with the deployment of thermal relief, enables the use of a low-cost crystal as reference instead of a TCXO.
That last part sent some gears spinning in my head… In your design I saw that you have two options: with xtal and with tcxo. I assume you made your initial modules with tcxo.
I’m wondering whether the xtal option is realistic. The reason is that, as you know, LoRa transmissions can be many seconds long and at high TX power cause quite some heat dissipation. Given that you’re building a minimal sized module, it seems to me that heating the xtal is unavoidable and that that precludes a significant portion of the radio’s operating regimes.
If the design was on a large board where the xtal could be more than 2mm away from the radio the suggested “deployment of thermal relief” could work. What they do in the reference design is a no-copper barrier on all layers between radio and xtal. Note also that they’re talking about the sx1261, which is limited to 14dBm. They also have an sx1262 design with xtal and the no-copper barrier looks doubled in width…
Edit:
Yet another minor thought… Your module uses PC0, PC1, PC6 to control the RF switch. These pins are not available on the UFQFPN48 package. If you wanted to make a version based on that package in the future you’d create a SW incompatibility.
Edit 2:
I’m going crazy with the RF power stuff… The docs are scattered and not clear, at least not to me. For a design that supports both high-power and low-power RFO the best place to look seems to be the Nucleo board design. It has a total of 3 analog switches:
switch the power going into VDDPA between VDDSMPS (high power) and VFBSMPS (1.55V for low power)
switch the power output from VR_PA to either RFO_HP or RFO_LP
switch the antenna between TX and RX
I wonder whether supporting both HP and LP and wanting a minimal-sized module are compatible goals… I believe that one can make one tiny PCB and using judicious alternate component placements support either HP or LP, but which would be determined at soldering time…
First, there’s the antenna switch. If you use a single TX network, there are some weaknesses with this because changing the design of the TX network can offer quite substantial optimization of power efficiency vs. maximum power output. So I prefer SP3T with one TX path optimized for efficiency (LP path) and one TX path optimized for max power (HP path).
The VR-PA switch will need to be 2x complementary SPST, or similar. There are a few solutions for this, such as FPF1321 (it took me forever to track this down). Alternatively, you can use an external LDO the way I have done, which is OK for the use-case I was targeting.
I tried to deal with the SMPS case by putting its LC-tank off-module, thus you select whether to use it or not in the hardware design.
But I want to thank you for showing me the Infineon antenna switches, because they are small enough that I can get-rid of the external LDO and fit-in the FPF1321 switch to VR-PA. Actually, this will free-up enough space to put an additional footprint for a serial flash where the LDO was, in order to facilitate larger DFU transfers or other use-cases (in particular, I care about storing a big manifest of GNSS satellite orbit predictions).
Yes, it uses the TCXO. There’s no way to do thermal relief in the small module. There are some use-cases where heat dissipation from TX won’t be an issue, though, so I wanted to make sure a standard XO variant could be supported.
I think it is the SX127x that has some info about crystal stability. It seems to only be a problem at low bandwidths, so if you’re running from small batteries you don’t want long transmit times anyway, and definitely not a txco!
Designing with the STM32WLE5 is really challenging 'cause info about power and RF is scattered everywhere: ST docs, ST ref designs, ST nucleo board, Semtech docs, Semtech ref designs. Brrrr.
Hi…I’m truly energized for this LoRa RFSOC, and parts appear to have been fairly accessible as of now at any rate in example… I’ve considered quite recently building up my very own basic PCB to begin, however without the standard consideration regarding their help for it in the STM32CUBE bundle that an authority devboard will bring (and the related bugfixes!) I believe that would be an activity in agony, in view of my past involvement in front line STM32 items.
My methodology right presently is I’m actually blending an ordinary stm32 with the semtech chip, with the possibility that current plans will likely be re-targetable to a solitary chip plan in future without an excessive amount of problem, if necessary.
I believe some STM32cube stuff has become available. For myself, I actually like to program to the metal. Most of the ST code is so bloated I vomit when I read it… But then I also don’t try to write general-purpose code.
For example, my plan with the temperature/humidity node is to only implement stop/2Mhz/16Mhz clock modes, maybe I’ll even skip the 16Mhz one if the AES offload does the crypto in a reasonable time. I know I’ll spend a day or two pulling my hair out 'cause I set some bit in some reg incorrectly, but in the end I prefer that over chasing down endless #ifdefs for days… To each their own folly, I guess
One trick I learned if I have a bug was to pull up the debugger and just write directly into the registers. That saves compiling and downloading etc, a lot faster
When the trouble bit was found revert back to the code and compile
The register files and CMSIS support files are all part of it
It provides a testable reference
It provides reference code
I think it’s nearly useless in terms of being useful as deployable code, though.
I just ordered a bunch of STM32WLE5CCU6 (from Future… one hell of a price break), and some Nucleo-WL55 boards from Newark. My plans for the CCU6 parts are to test a number of front-end configurations. With the WL55, it’s just another option to look-into.
I’m also quite excited about the WLCSP-59 package option. I think that’s the best choice for the module in future revisions.
You know… for hand-soldering I usually prefer WLCSP to BGA. Bigger issue with the WLCSP is that you need to do underfill and epoxy on top for production. But for proto, some black paint will do.
Interesting… I was reading ST’s tech doc on their WLCSP packages… By the way it says “Underfilling is not required for WLCSPs”. Overall, they look virtually identical to BGAs, except perhaps a tad more fragile? The stm32wle datasheet doesn’t have specs on the WLCSP package, but I gather it’s a 8x8 ball footprint instead of a 9x9 for the BGA, so it must be 4.5mm x 4.5mm instead of 5x5? The description of the packaging makes me think one can only buy these in full reels, so I don’t think I’m gonna touch any of them any time soon… What makes them easier to work with for you?
Going down the rabbit hole of STM32WL design. So there is AN5042 on frequency trimming for RF oscillator, which is said to be absolutely necessary for a working and compliant product. The trimming requires either a very precise (0.1 ppm) frequency counter or an equally precise frequency generator. Unfortunately I could find neither on the market, not for a reasonable price at least.
Any ideas/experiences here? Sorry if it was already discussed, couldn’t find anything with a quick search.
I just bought a used, just calibrated 53131A with Option 030 for $500 for verifying crystal accuracy on a BLE design (or well, proving the manufacturer had actually swapped out the crystal I specified…). You could add a GPSDO as an external 10MHz reference to hit 0.1ppm fairly cheaply.
But, are you sure you need this? My understanding is the point of these tuning options is to allow you to use cheaper crystals in mass production by trimming them individually. The other option is to just use an accurate enough crystal. For instance, BLE accuracy requires +/-50ppm total accuracy. I just specify a crystal with +/-10ppm initial, +/-10ppm temperature, and +/-3ppm aging, and then I don’t have to trim them in production. Shouldn’t hit 50ppm until 10 years (10ppm + 10ppm +10*3ppm) at worst case everything.
So, you can do the math and see if it’s worth it. Crystal cost difference * units vs. cost to implement trimming. $0.03 a crystal in savings: @1K units * $0.03 = $30.00 savings, @10K = $300.00, @100K units = $3,000.00, @1M units = $30,000.00… You get it
Anyway, it looks like LoRa’s requirements are not that stringent:
If I were building a LoRa base station, yeah I’d probably use a 0.1ppm TXCO or GPS, etc. But for the clients, based on what I’m reading, I’d just spec a good crystal, verify the design with a frequency counter and spectrum analyzer, and ditch the trimming.
Thanks a lot, that adds a lot of context! My understanding was that it’s more to compensate for parasitics that are dependent on specific PCB design and manufacturing process, but probably I’ll just try to minimize that with a proper layout.
Ah, yes, I do definitely tune the initial layout, and then verify across a large production pilot batch. I burn the default good value into the code, and then if the chip supports a configuration header value that sets the crystal tuning for each board, I leave it unprogrammed. The crystal startup code will check the header and use my default value if no configuration header value is present.
Then, I can implement a future cost reduction if worthwhile by only setting the header tuning value in production, without having to issue a firmware release. Or if I start seeing issues in production… the lazy engineer always plans for an easy fix to potential problems.
For verifying the crystal/layout/etc., a frequency counter works, as does a spectrum analyzer, as long as their oscillators are in spec. You can get the crystal ppm from the frequency error, e.g. for BLE a 150KHz error at 2.45GHz is 150000/2450000000 = 61ppm. There may be sources of error other than the crystal, like PLL jitter, but that is beyond my knowledge and I will defer to others more knowledgeable here in the forum.
Yes. The Datasheets recommend it. If you put it out in the sun you’ll get errors. nail polish lacquer seems to work fine though. This is mainly an issue in the photo phase, obviously
Is that so you forsure burn up the PA should you TX into a mistakenly closed switch???
)
