Apologies I see you use 1.8 V everywhere else. 1.6 V seems to work but better to keep everything consistent..

Is it documented somewhere that RadioLib doesn't accept TCXO voltage of 0 any more? I looked at the changelog and the only thing I found referencing TCXO was this commit in 7.5.0, but I think that's adding a fallback to TCXO(0) for when the default begin method is called against chips which don't have TCXO.

The code seems to suggest that setting TCXO voltage to 0 is still the correct way to configure modules without TCXO?

Yes that's true, but as far as I can see both the all-in-one waveshare_rp2040_lora (circuit) and the rpi_picow (circuit) variants do use TCXOs.

I couldn't get the Pico+SX1262 working, eventually adding a ton of debug printing, and the radio init was failing, returning -707. Changing to 1.6 V allowed the radio to start. I think specifying an older version of radiolib also worked.

Since we're not saying SX126x::XTAL=TRUE, this is the only way we're telling radiolib to use the xtal. Radiolib is not just throwing an error as it would if you said 99 V, it's attempting to start the radio oscillator as a crystal and finding a hardware failure.

All of the other SX1262 boards do specify 1.8 V. So I think this comes down to the assumption about the osc on the board.

From SX1262.h:

  \param tcxoVoltage TCXO reference voltage to be set on DIO3. Defaults to 1.6 V.
 If you are seeing -706/-707 error codes, it likely means you are using non-0 value for module with XTAL.
 To use XTAL, either set this value to 0, or set SX126x::XTAL to true.

In SX126x_config.cpp it checks the TCXO voltage is in the allowed list.

If you go forward with this please change it to 1.8 V. A brief search shows no TCXOs specified for 1.6 V, though it may (and does) work there of course. Also please add the schematic link to the rpi_picow platformio.ini file for future reference.

Please change the PR base branch to 'dev'.

OK after some magic I'm not qualified to wield... I think I've fixed everything.
The PR is now to dev and contains just the one line.

Why you thing it is needed to change DIO3 voltage to 1.8V? Correct voltage settings depend on TXCO manufacturer. Different people use different modules, so different TXCOs. Even LoRa module manufacturer can change TXCO supplier during manufacturing. Most correct way is to fine tune TCXO as close as possible to 32 MHz by changing DIO3 voltage. Please read Semtech datasheet how it is working.
For example, I am soldering nodes/repeaters myself with different modules than you are using. So, your setting will be wrong for my hardware. What if some people have LoRA modules without DIO3 voltage settings?

Much better solution is to expose Voltage settings in CLI/web config so user can fine tone himself instead of hardcoding settings in firmware, but this is much more global changes than RP2040 pull request.

This is just to bring one variant, the waveshare_RP2040_Lora, in line with the other SX1262 boards. Current release doesn't work on this board, as seen in #1109, and changing the voltage fixes it. It shouldn't affect other boards.

Some more detail / rambling:

This board has a TCXO (circuit), and for convenience of power switching and voltage regulation, the radio offers DIO3 as a power supply for it.

Specifying 0 V tells Radiolib to tell the radio to expect a passive crystal. On this variant, or any board with a TCXO, the radio fails, returning -707.

Why 1.8V: DIO3 is the Vcc power supply for the TCXO and should be set to a suitable voltage. Waveshare doesn't specify the part number they use but a quick look around shows many TCXOs that work from 1.8-3.6 V but none down to 1.6 (though mine did work there). All other SX1262 implementations specify 1.8 V so it seems to be a safe choice, but more detail would be helpful.

No frequency tuning is possible with DIO3 on this board; it's not a VCTCXO, the TXCO frequency is independent of Vcc, or should be. Nor is it required - the receiver tolerates a static offset of at least 50 ppm, easy for a TCXO.
(The benefit of the TCXO over the crystal is that apparently a crystal drifts too much because the board warms up while transmitting packets longer than 2 seconds. The frequency must be stable to ~10ppb during a single packet.)

Actually... When I soldered my 1st DIY Pico node I used Waveshare shield/had schematics and... Yes, I also set voltage for 1.8V or something similar to get it working, if I remember correctly. Because I don't continue with Waveshare variant, not that important for me. Fine tuning depend on Module used. Later I'll try to figure out details about my surplus SX1262 and TCXO (or VCTCXO) tuning stuff.

Just keep going! You are doing good work and I am just watching you, because I am also interested in Pico based nodes.
Now I am using PicoW as reference and modify according to my needs. PicoW have own problems.

For curiosity, another unrelated problem (probably need to open another issue/pull request for PicoW or other platform). So far this is just for note: I compiled both Companion and Repeater with setting: -D LORA_TX_POWER=1 with the hope that on 1st run I'ļl get minimal power and can adjust power later during setup, but...

No problems with repeater, I can set any output power via CLI/web browser.

Problems start with companions. I can't set max output power Higher that 1 dBm
Reason: File examples/companion_radio/MyMesh.h lines 54-57
-D MAX_LORA_TX_POWER=22 not defines in platformio.ini
solution: add -D MAX_LORA_TX_POWER=22 (or another value) for Pico.

There are a lot of small thing to fix.

Double checked Waveshare Lora schematics. Looks like TCXO without voltage control. So PR looks good. Only question: what voltage need to be set? 1.8V? Or maybe 3.3V? Can't find voltage settings in Waveshare recommended examples.

Yes Waveshare doesn't mention the part number and their code (just the semtec demo code) never specifies the voltage. The Semtec reference design uses the part NT2016SF-32MHz-ENC4263D (sic) which is 1.65V ~ 3.65V.

Breaking out the microscope... the TCXO on my Waveshare (pico hat) board is labelled

BN32.0
⬤𝐃203

which must be the KDS (Daishinku Corp) DSB221SDN or DSB321SDN. These are all specified 1.68 - 3.5 V.

My board did work at 1.6 V, but now as I read more, that might compromise frequency stability. All the other SX1262 boards in meshcore use 1.8 V, including the rp2040_picow which is also Waveshare.

So I think 1.8 V is a very safe choice here.

Can you hook frequency counter and sweep voltage to get some kind of graph frequency dependency on VCC voltage? No need to use super precise equipment just short term stability while measuring. Oscilloscope is enough. Next step: try to supply up to 3.3V (or full VCC), if possible, and measure current to estimate power consumption while idle/listening for packets.

If TCXO works good in whole supply range, than voltage tuning can help to reduce power consumption a little.

I don't think that's necessary - the part should be within specifications at 1.8 V and the current will be lowest there.

A third user has just found #1109 and got it working by recompiling.

As far as I can see in the history, the voltage was just specified wrong in the original creation of the waveshareboard.
The picow variant that it was copied from, always has the 1.8 V. Here are the two variants side by side in a folder, here is a painful diff.

#1109 was opened in Nov 2025, and the user said that previous firmware had worked. I believe this is because RadioLib v7.3.0 - Sept 21, 2025 - added more checks for the correct oscillator startup. I don't know how the board actually performed without power to the TCXO, perhaps the internal oscillator, but that would never have been able to actually communicate.

@jbrazio (if it was you), do you remember why you used 0 V for the waveshare board?

At the time I used 0 as it was the only way for the radio to init. AFAIK Waveshare's board does not have a TXCO.

I am using PicoW with my modifications. Yes, there was problem with DIO3=1.8 Don't remember why I guessed to to add DIO3=1.6 or similar line in my local PicoW repository. By understanding more details it is totally OK, to merge this commit into Meshcore-dev branch. @IoTThinks @liamcottle @ripplebiz or whoever of you can merge this.

Offtopic:
Right now I am working on configuring PicoW in a way that I can use not only SPI1, but also SPI0 (SPI1 and SPI according to arduino naming). All my PicoW modules are DIy soldered and pinout differ from master repository. This is not a problem until "power saving Heltecers" or other wannabies inject crazy platform dependent code into Meshcore /src/

It would be nice if you can add temperature reading to PicoW without altering a lot other code. Also it is nice to remove platform dependent file system stuff from main code and move it into PicoW/Waveshare variants.

I'm trying to get an rp2040-zero hooked up to a HT-RA62 (sx1262) module which has TCXO - can you please clarify what the DI03 voltage setting should be - 1.8v? Also - from a practical wiring perspective, do I actually need to connect the DI03 pin on the HT-RA62 to a GPIO pin and set the pin high (or with a voltage divider to lower to 1.8v)? As you can tell - I'm a little confused about this TCXO 1.8v malarky so any clarification would be very much appreciated.

I actually got a new variant nearly working, based on the existing waveshare-rp2040 and Xiao_rp2040 variants and just changing the pin assignments in platformio.ini - it works perfectly for the first 8-10 seconds, but then just hangs, and I can't figure out why. During the first 8-10 secs it works perfectly - but then hangs.

Pretty sure it's not related to the SX126X_DIO3_TCXO_VOLTAGE=1.8 - but any insight would be greatly appreciated.

@MikesAllotment sorry for the delay.
I haven't looked into the HT-RA62 much but if it has a TCXO almost certainly you should (tell radiolib to) set the DIO3 voltage to 1.8 volts, the same as the other Heltec boards. That will be an internal connection on the board. The SX1262 creates the adjustable voltage with some sort of DAC.
For hanging problems - ask your favourite AI to add tons of debug printing telling you what it's doing. The timing makes it sound like it's related to the first advert packet. Make sure it has a solid power supply, and/or try reducing the power to 1 dBm.

I'm trying to get an rp2040-zero hooked up to a HT-RA62 (sx1262) module which has TCXO - can you please clarify what the DI03 voltage setting should be - 1.8v? Also - from a practical wiring perspective, do I actually need to connect the DI03 pin on the HT-RA62 to a GPIO pin and set the pin high (or with a voltage divider to lower to 1.8v)? As you can tell - I'm a little confused about this TCXO 1.8v malarky so any clarification would be very much appreciated.

I actually got a new variant nearly working, based on the existing waveshare-rp2040 and Xiao_rp2040 variants and just changing the pin assignments in platformio.ini - it works perfectly for the first 8-10 seconds, but then just hangs, and I can't figure out why. During the first 8-10 secs it works perfectly - but then hangs.

Pretty sure it's not related to the SX126X_DIO3_TCXO_VOLTAGE=1.8 - but any insight would be greatly appreciated.

#Placeholder to not loose this PN in noise. I am also messing with Waveshare RP2040 Zero clones and generic SX1262 modules. DIO3 config is also needed in my case. Radio library will read this config and set-up TXCO correctly. No slodering needed, just software config. Also it is recommendec to use correct board name, in my case it is board = waveshare_rp2040_zero instead of simple picow. Why? I am using custom pinout, different SPI periperal (zero instead of one). Because I am using GPIO29 on zero, if you use picow definition you can get confilct, because GPIO29 is used for power management in picow DC/DC conevrter logic. That's why board = waveshare_rp2040_zero at least in my case.

Just commenting to say I would really love to see this change get merged. Maybe in the 1.15 release?

@JDat I know you're also involved in the discussions here regarding the RP2040-zero + HT-RA62 testing...

#2087 (comment)

Interestingly I've got the Room Server and Companion USB running perfectly now with no hangs, however the Repeater still hangs - so I don't think it's power supply related otherwise the RS and Companion would also hang when adverts are generated.

The other big difference between Repeater and RS/Companion is that there is now Power Saving logic in the Repeater which isn't present in either the RS nor Companion code ... so I'm wondering whether the Repeater hangs are being caused by the newly introduced Power Saving logic...

Sorry, went away to another project and following Meshcore is suspended because no time for that. I am more into guess that there are problems with rogue I2C implementation and "random" pin assignment on other platforms and as result code touch LoRA pins in wrong time and place. Probably there are also problems with some GPIO and code.

I really want to do major refactoring and auditing for MeshCore and move ugly platform specific code away from core and examples.

Why repeater and not RS/Companion? Maybe some I2C telemetry sensor problems in code? Or RP2040 specifics regarding DC/DC converter? Can be anything.

So far my Repeaert with V11.0 works more than 1 month. Companion? Well, no time for Meshcore. It is offline now. To be "online" in MeshCore I am using T-Deck for now and checking messages once per day.