Hi, i wanted to create a system for meshtastic based on these components. My question is if is possible to use the pico firmware directly with this SX1276 instead of using the SX1262 (without changing code). I want to use the precompiled firmware.
Thanks!<3
Also, what is the pinout expected for rp2040 with the SX module?
No, that’s not possible with the precompiled firmware.
You’d have to add #define USE_RF95 to the variant file of the Pico and define the LORA pins according to how you’re wiring the radio module.
1 Like
Thanks, RF95 is the name for sx1276?
Yeah, it’s a wrapper for SX127x modules.
1 Like
I have learned how to build and upload firmware, but the system freezes after exactly 34 seconds without any interaction, or instantly after sending something or using the command --debug in the terminal client. I believe the radio is detected since there are no errors on the screen. What i can be doing bad?
// #define RADIOLIB_CUSTOM_ARDUINO 1
// #define RADIOLIB_TONE_UNSUPPORTED 1
// #define RADIOLIB_SOFTWARE_SERIAL_UNSUPPORTED 1
#define ARDUINO_ARCH_AVR
#define USE_SSD1306
// default I2C pins:
// SDA = 4
// SCL = 5
// Recommended pins for SerialModule:
// txd = 8
// rxd = 9
//#define EXT_NOTIFY_OUT 22
//#define BUTTON_PIN 17
//#define LED_PIN PIN_LED
//#define BATTERY_PIN 26
// ratio of voltage divider = 3.0 (R17=200k, R18=100k)
#define ADC_MULTIPLIER 3.1 // 3.0 + a bit for being optimistic
#define USE_RF95
#undef LORA_SCK
#undef LORA_MISO
#undef LORA_MOSI
#undef LORA_CS
#define LORA_SCK 10
#define LORA_MISO 12
#define LORA_MOSI 11
#define LORA_CS 3
#define LORA_DIO0 RADIOLIB_NC
#define LORA_RESET 15
#define LORA_DIO1 29
#define LORA_DIO2 2
#define LORA_DIO3 RADIOLIB_NC
#ifdef USE_SX1262
#define SX126X_CS LORA_CS
#define SX126X_DIO1 LORA_DIO1
#define SX126X_BUSY LORA_DIO2
#define SX126X_RESET LORA_RESET
#define SX126X_DIO2_AS_RF_SWITCH
#define SX126X_DIO3_TCXO_VOLTAGE 1.8
#endif
(i have commented some pins declaration for trying but doesn`t work…)
All the wiring is well connected and there is no Critical Error 3 or something like that.
Check the serial logs using the CLI command meshtastic --noproto, that might give a clue.
After 34 seconds:
PS C:\Users\vidal\Downloads> .\meshtastic_windows.exe --noproto
WARNING file:mesh_interface.py _sendToRadio line:681 Not sending packet because protocol use is disabled by noProto
Connected to radio
WARNING file:mesh_interface.py _sendPacket line:531 Not sending packet because protocol use is disabled by noProto
DEBUG | ??:??:?? 30 [Screen] LastScreenTransition exceeded 5076ms transitioning to next frame
INFO | ??:??:?? 35 [NodeInfoModule] Sending our nodeinfo to mesh (wantReplies=1)
INFO | ??:??:?? 35 [NodeInfoModule] sending owner !a7604532/Meshtastic_4532/Msht
DEBUG | ??:??:?? 35 [NodeInfoModule] Initial packet id 221932178, numPacketId 4294967295
DEBUG | ??:??:?? 35 [NodeInfoModule] Update DB node 0xa7604532, rx_time=0, channel=0
DEBUG | ??:??:?? 35 [NodeInfoModule] handleReceived(LOCAL) (id=0x0d3a6a94 fr=0x32 to=0xff, WantAck=0, HopLim=3 Ch=0x0 Portnum=4 WANTRESP priority=10)
DEBUG | ??:??:?? 35 [NodeInfoModule] No modules interested in portnum=4, src=LOCAL
DEBUG | ??:??:?? 35 [NodeInfoModule] localSend to channel 0
DEBUG | ??:??:?? 35 [NodeInfoModule] Add packet record (id=0x0d3a6a94 fr=0x32 to=0xff, WantAck=0, HopLim=3 Ch=0x0 Portnum=4 WANTRESP priority=10)
DEBUG | ??:??:?? 35 [NodeInfoModule] Expanding short PSK #1
DEBUG | ??:??:?? 35 [NodeInfoModule] Using AES128 key!
DEBUG | ??:??:?? 35 [NodeInfoModule] Installing AES128 key!
DEBUG | ??:??:?? 35 [NodeInfoModule] enqueuing for send (id=0x0d3a6a94 fr=0x32 to=0xff, WantAck=0, HopLim=3 Ch=0x8 encrypted priority=10)
DEBUG | ??:??:?? 35 [NodeInfoModule] txGood=0,rxGood=0,rxBad=0
Looks that failed when sends…
Might be a power supply issue. Maybe try a normal socket and not a USB port from a laptop.
I have tried with 3 differents power supply ways (PC, Mobile and 5V2A charger) Same result: second 34 the screen freezes.
Yes, it sounds like that’s always when it tries to send the first message (which is scheduled 30 seconds after boot). It really looks like a power supply issue. The Waveshare LoRa hat for the Pico has a separate battery. I observed that I really needed to connect that, otherwise I’ve seen the same behaviour.
How can I solve it then?
Do I put an external 3.3v power supply to the VCC of the module?
I have a TTGO Lora32 and never freezes without battery (only usb connected).
Yes, that might be worth a try.
I also don’t have issues with ESP32 only from USB.
I have tested with this:
And i have the same behaviour… 
The screen is powered by 3.3v regulator of RP2040-zero and the sx1276 with this 3.3v output. GND are common and connected. This regulator should be enough i think…
I’m sorry, then at this point I also don’t know.
There are no errors shown right after boot (when you start the serial monitor immediately after you plug it in)?
Otherwise try a simple example script from here to check if it’s unrelated to Meshtastic: RadioLib/examples/SX127x/SX127x_PingPong/SX127x_PingPong.ino at master · jgromes/RadioLib · GitHub
1 Like
If there is any seg fault or similar the board will reboot? Meshtastic uses any type of Watchdog? How i can see if there is any lib crashing at the send moment?
No, it will likely just crash and then freeze. Meshtastic doesn’t use a watchdog for the RP2040.
I believe it would already print errors if RadioLib detected something wrong, e.g. firmware/src/mesh/RadioLibInterface.cpp at master · meshtastic/firmware · GitHub
You could connect a debugger to check where exactly it fails, but I’m afraid you won’t get a lot information from that.
This board lacks a debugging port. (Normal pico has one)
But there is one thing I can try: GitHub - majbthrd/pico-debug: virtual debug pod for RP2040 "Raspberry Pi Pico" with no added hardware
I have little hope in it but…
I have tested the LoRa module with an ESP32, using the same pinout as the TTGO LoRa32 to leverage the prebuilt firmware. This time, it works well and successfully communicates with my other commercial boards.
Now, I suspect it’s not a LoRa module problem. Perhaps I connected something incorrectly in the hardware (RP)? I don’t think so. It’s more likely a firmware or configuration issue that I can’t identify.
If I open a GitHub issue, could someone test this configuration to determine if the problem is on my end or not?
Thanks for helping me 