Coding the RAK4270 Module

Does anyone have a link to a development guide for putting code onto the RAK4270 module?

Yup, here you go:

Hi @Kevin192291 ,

You can use RUI as suggested by Nick above. I have a simple demo in one of our hands-on with RAKstar sessions here -

You also have the option to use the stm32 inside the RAK4270 via the STM32 SDK but you are on your own on that path. But I can support you on any hardware-related concern you might have.

I take it @carlrowan that we aren’t going to get a late 2020 Christmas present of a working starter for the STM32CubeIDE then?

I’ve been asked about this a number of times now and it’s just totally unexplainable - no requests for your RUI source code, just some confidence that there is a known good starting point. I’ve offered to have a go at it myself but the concern is that there is something hidden inside the module that is proprietary and with the short supply of many modules in the market, no one wants to tempt any form of vendor lock-in.

Currently I am doing all of my work on the Murata cmwx1zzabz-078.
The issue is that these chips are almost impossible to get nowadays. If RAK could allow for easy development, I think the 4270 could be a drop in replacement. Not only would it be a big win for everyone that is stuck because Murata is the only option out there, but it would mean that RAK would possibly gain that market share while Murata is MIA

1 Like

I so agree - I’ve only 6 Murata’s left and RS Components are saying March 2022. I’d get myself in the queue with DigiKey or Mouser but I don’t then want to end up with a gazillion modules on my hands.

Hi @nmcc ,

I can probably work on something for RAK3172 that uses STM32WL SoC when it comes to STM32CubeIDE development with the assistance from the FW team :+1:

Hi @Kevin192291 ,

I understand your situation with Murata. I am not sure how Murata is handling it but I have this impression that the LoRaWAN module is not a project of focus to them. We must always avoid single-sourcing a component for our projects but sometimes we have no choice but just to decide what to use like on LoRaWAN modules case where it really differs from vendor to vendor. Anyway, did I answer your question above? :slight_smile:

Also somewhat MIA and overly fussy - who needs two cores anyway.

The RAK4270 being driven by an ATtiny1614 is a good sweet spot, but when there is only a couple of I2C devices required, why not just go native?

You did, I apologize for not marking the solution earlier.
As for the RAK3172 Would that apply at all to the RAK4270 as well?
I ask because of the certification the 4270 has, and the 3172 does not.

Also if there is anything in terms of coding work that I could assist with I would be more than happy to lend some time as I would love to see this project successful for not only my own purposes but also the LoRaWAN community as a whole.

Certification includes the firmware - so to remain certified it would have to be AT commands only - and no RUI.

1 Like

Nick , Carlos - Good Thread lets hope we can move forward !!!

My thoughts

RAK Wireless generates income by selling RAK Hardware module - They have excellent products
RAK Wireless generates NO income by making RUI the only way of generating firmware for their Lora Modules

I do not understand the business sense in not supporting a more convenience build method

Surely , it would generate more sales


Paul Humphreys

Hi Paul,

I agree that there is no direct income coming from RUI. But RUI is a value add to some of our customers :wink:

I remember before (few years ago) that I used a module that has default AT command just like the RAK WisDuo modules. I want to add more features and use the module itself as stand-alone device but I have no choice but to deal with STM32 SDK.

If there’s something like RUI, I can use that. But of course, RUI is not a perfect solution for everyone. But with enough time invested (lower than learning all STM32 Cube and low level stuff), I can do many niche applications using RUI.

Applications like LoRa button, dry contact sensing, GPIO/ADC and simple I2C devices can be done easily via RUI :slight_smile:

Of course, there’s the disadvantage that the compilation time is longer because you need to zip then upload before you can compile. It is really annoying I know. But we are cooking something that will solve this. We should reveal it in few months time.

This topic was automatically closed 2 days after the last reply. New replies are no longer allowed.