Raspberry Pi Pico Lorawan connection using RAK4200/RAK4270 Wisduo Breakout Board

Only 4 connections are needed. The 3.3v, GND, TX and RX. I use GP0 and GP1 of the Rasbperry Pi Pico board. Image and simple micropython code below. Perfectly fits on the small breadboard :grinning:

from machine import UART
from machine import Pin
import time

decoded_data = ""
led = Pin(25, Pin.OUT)
uart = UART(0, 115200)  # use RPI PICO GP0 and GP1


## CODE TO SETUP RAK4200 - OTAA, Class, Region, keys##
uart.write('at+set_config=lora:join_mode:0\r\n')
print("set to OTAA")
while(decoded_data != "OK\r\n"):
    data = uart.readline()
    decoded_data = data.decode('utf-8')
print("OTAA done!\r\n")

decoded_data = ""
uart.write('at+set_config=lora:class:0\r\n')
print("set to Class A")
while(decoded_data != "OK\r\n"):
    data = uart.readline()
    decoded_data = data.decode('utf-8')
print("Class A done!\r\n")

decoded_data = ""
uart.write('at+set_config=lora:region:EU868\r\n')
print("set to EU868 reguion")
while(decoded_data != "OK\r\n"):
    data = uart.readline()
    decoded_data = data.decode('utf-8')
print("EU868 done!\r\n")

decoded_data = ""
uart.write('at+set_config=lora:dev_eui:00396E15EFDF4648\r\n')
print("set to DEVEUI")
while(decoded_data != "OK\r\n"):
    data = uart.readline()
    decoded_data = data.decode('utf-8')
print("DEVUI done!\r\n")

decoded_data = ""
uart.write('at+set_config=lora:app_eui:70B3D57ED0038D62\r\n')
print("set to APPEUI")
while(decoded_data != "OK\r\n"):
    data = uart.readline()
    decoded_data = data.decode('utf-8')
print("APPEUI done!\r\n")

decoded_data = ""
uart.write('at+set_config=lora:app_key:7B2BD89FAAF26CBDC694257F7EC92D1B\r\n')
print("set to APPKEY")
while(decoded_data != "OK\r\n"):
    data = uart.readline()
    decoded_data = data.decode('utf-8')
print("APPKEY done!\r\n")
## END OF SETTING UP ##

## TRY TO JOIN THE NETWORK!##
decoded_data = ""
uart.write('at+join\r\n')
print("joining!")
while(decoded_data != "OK Join Success\r\n"):
    data = uart.readline()
    decoded_data = data.decode('utf-8')
print("join success!")

while(1):
    led.value(1)
    uart.write('at+send=lora:2:1234554321\r\n')
    print("LED ON")
    time.sleep(5)
    led.value(0)
    print("LED OFF")
    time.sleep(5)
2 Likes

@carlrowan,

Nice work Carl :wink:
Is it just me or the Region portion of the code is doubled for some reason?

Regards
Vladislav

Oh. Thanks @Hobo
I am so used on copy-pasting. Lol. I’ll correct it :smiley:

I have a board designed for RAK42X0 that I’m about to send off.

I’ll do mine in C, but I can host Python as well.

RP2040 is not really low power. If you plan to run on batteries, my bet is that you might need to cut the power source. Personally, I am very enthusiastic to support Rpi silicon. For sure there will be improvement on their next chips.

Sure, we need to educate them on the low power front - I suspect that there may not have been much in the way of measuring things in the context of LoRaWAN low power and as soon as mine arrives I’ll butcher the Buck/Boost off the board and see what the actual numbers are.

For me, the joy of the Pico/RP2040 is I can take my Arduino customers up a level without them banging their heads against the ST/Microchip eco-system and all the blizzard of info that comes with that.

1 Like

That would be a nice improvement, but it may not happen - its worth remembering the the Pi Foundation sees themselves as being in the computer science education business rather than the embedded systems business, and that Broadcom doesn’t do a lot in battery-powered industry segments.

That’s a software problem, not a hardware problem, so compromising with odd hardware probably isn’t the best way to solve it.

What you need is a good [build and] flash solution for an embedded target. To that end there are the atmel->microchip ARM based Arduinos, and various STM32 based equivalents as well.

Mostly the challenges come down to Windows still having horrible driver paradigms.

I have no personal info inside rpi team. But let’s remember that they have a dedicated RPi Silicon team inside. It is true, Broadcom will not bother with the MCU ventures of RPi.

But I have this feeling that RPi will attempt to dominate the MCU space of makers. I might be wrong of course. But they definitely see a market in which the RPi SBC doesn’t fit. The 4usd price point for the features of RP2040 is telling us “hey Rpi silicon here guys!”

Who knows? Hopefully, someone can share some light :thinking:

That’s the Raspberry Pi Foundation you are thinking of. This is Raspberry Pi Trading which does exceeding well at flogging Compute Modules, Raspberry Pi’s and now 140K Picos - this is what funds the Foundation. Leaving aside the aim of the RP2040 is to provide a coherent platform for those going embedded, which as I understand it, is a reflection of where they hope students will stop doing easy stuff on Pi and learn real world tools with a bit more bite.

The RP2040 was an internal effort unrelated to Broadcom.

Fundamentally, the RP2040 provides a nicely package eco-system to wean people off Arduino. For actual devices they may end up with a pre-prepared STM32 or SAML, but at least they won’t have crashed and burnt on the way.

Odd how so?

Is it not a progression of the same old single core offerings. AI at the edge and independent IO seem like they are showing the way forward, rather than just 100+ variations when there could be 10.

I’m genuinely interested to figure out the motivations or end result of the dual core and PIO. Only having 4 ADC with, and I haven’t looked at the details, some issues getting the full 12 bit results seems to be a deficiency. But the rest looks good.

It’s not designed as a sensible embedded platform at all. Realistically if you want something of that general external-not-internal flash sort, in most cases you’re probably better off with an ESP32 which brings radios that you can use (or not) effectively for free.

But most small embedded applications do better with an internal flash MCU.

I’m genuinely interested to figure out the motivations or end result of the dual core and PIO.

Probably heavyweight managed code languages; also I suspect it’s not truly an original design, but a derivative of something someone had sitting around.

As for the “getting code on an embedded device” problem - that’s a software issue not a hardware one; the sensible solution is to develop a good tool flow for already suitable application hardware.

Generally they don’t attempt to dominate in the marketing sense - they concentrate on what’s “right”, even if it’s not exactly “right”. They have no shareholders so they are at liberty to do things differently - they try to hit the sweet spot between commercial and useful to fulfil the aims of the Foundation.

Again, not really, look at the Pi Zero, £4.80 in the UK. They just price it at the lowest possible price point without killing themselves. And if there was any tech business apart from Apple in the world that didn’t need to flag wave to get attention, it’s Raspberry Pi.

Something for me to learn about. As I understand it, the die is tiny as it’s not got flash on it so it gets them 20K yield per wafer, and you can then choose the flash you need externally, you get XIP and can run from RAM. I don’t know how much caching the XIP gets or if you can pick & choose sections of flash to run from RAM. But they do get huge economies of scale for this first release. Four years development need some pay back - later on down the line a single core with a decent amount of RAM / flash to get us the ATmega328P of the RPi silicon line may well transpire.

How much slower is external flash with XIP?

A lot of traditional embedded applications have little need for speed.

Eg, my LoRaWAN nodes run a Cortex M0 at just over two MHz (when they’re not asleep, as they usually are); the only time I noticed that being a limtiation was when I attempted to for laughs to play variable audio tones by software delay rather than setting up a timer. The chip can be clocked much faster of course, but there’s typically no need to do so.

The one place I could see this maybe fitting would be as an RTOS-based low power gateway in conjunction with an SX1302 that would only ever use a mobile data modem for backhaul; the USB host that the ESP32 doesn’t have might be interesting there to use a commodity modem rather than a UART-interfaced one. This could probably be done with a flash based MCU, too, though the high RAM might be handy.

Though once you start playing with the USB in host mode, I’d guess you have to use SWD for development/debug since you couldn’t plug the USB port into a PC at the same time.

I’m attempting to setup this example with a Pico and a RAK4270 but the code never sets up the OTAA. Any suggestions? Thanks Carl

Hi @RGS welcome to rak forum.

Can you share the serial output? Can you double-check the OTAA parameters (deveui, appeui, appkey)?

I ordered a usb serial adaptor that I should receive this weekend. I’ll see what happens when I connect it directly to my Mac. As far as the OTAA parameters, I’m sure they are correct. I’ll post my serial output as soon as I can. Thanks again.

I have no serial output. I’m wondering if my new RAK4270 is not working.