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!
1 Like
I just posted where I’m at WRT a low-power focused design: LoRa Temperature/Humidity Sensor by TvE build log
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 
I use bare metal also when possible
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
1 Like
The STM32Cube support is useful in a few ways:
- 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.
No hand soldering of those! 
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.
Where do you find mention of “absolutely necessary for a working and compliant product”?
Is the epoxy/paint due to photonic effects? I don’t think I noticed anything in my past use of WLCSP calling for shielding/coating?
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
For the Lora radio and most other SRDs of the last 15 years, there’s a calibration routine in the PLL startup that trims the oscillator. Certainly post-2012 when the SPIRIT1 shipped, these routines are quite fast, or the order of 60 us or less.
The issue is that heat generated during a long, moderate power transmission (Lora IC is good for 22dBm) will heat the PCB during the transmission and cause a drift. TCXO compensates for this.
Ah, good to know, I wouldn’t have thought of that. Too much time on 0dBm BLE radios these last few years.
I’ve been interested in LoRa for a while, but never had a chance to really work with it. I wonder if Amazon’s sidewalk will change that
Sidewalk was supposed to be more than it appears to have become.
IMO helium offers a better lorawan network.
That is all I will divulge unless you get me drunk 
Are there any technical details about how sidewalk uses LoRa?