“Cooling” ? For 40-80 mW device … Kidding ?
2 Likes
Covering with heat shrink tube impacts cooling in general, hence the ‘may’ (not knowing all details of the board and its components, e.g. when powered via USB).
Yes, USB C Port would make extremely sense for this device. Best way to break it by leverage and when you want to use it with a raspberry you are happy as well…all your arguments makes no sense to me.
USB Type C Female, that is the one that you connect with a USB C male to USB A male cable.
The USB-C male cable connector is easy to insert and remove and can even be inserted upside down. And when the cable is not inserted the device can be significantly more compact (when preferred).
But of course different people will have different preferences.
Apparently you have different preferences.
With a bluepill board (STM32F103C8T6, 128k) I am unable to get MCCI LMIC library working.
IDE: PlatformIO, board = bluepill_f103c8_128k
LMIC libraries:
- MCCI LoRaWAN LMIC library, version 3.1.0
- LMIC Arduino, version 1.5.0+arduino-3
Sketch: ttn-otaa.ino included with above MCCI LMIC library.
Modifications to sketch:
- Added unhandled events (see issue #550).
(No notification is printed for EV_RXSTART in order not to mess up timing.) - Added conditional compilation to exclude MCCI LMIC specific events/features when using the LMIC-Arduino library.
(Switching between both LMIC libraries can be done simply by specifying the corresponding library dependency in the platformio.ini project configuration file.)
When using the LMIC-Arduino library the example works fine (uplinks and downlinks) and does not even require ClockError to be set.
When using the MCCI LoRaWAN LMIC library evrything appears to hang after the first EV_TXSTART event (while it attempts to join).
After the initial join request no subsequent join (retry) requests are made (not visible on TTN Console). Normally, when the first join request fails (e.g. because of timing related downlink issues) a subsequent join request will be made within minutes. This is however not the case and the node appears to be hanging (waiting indefinitely, or crashed).
And in both cases you use the Arduino Core STM32? I am not too familiar with Arduino, especially on STM32. So I am not of much help at this point. But if I find the time I could have a look into it.
Or did you copy my port of the mcci lmic to CubeMX generated code + LL drivers? In that case there might be some changes necessary from STM32L071 to F103.
Yes
No, I am using the vanilla (unmodified) versions of both libraries.
Okay. When I find the time and manage to attach a debugger while using Arduino, I could have a look into this.
What about that ? :
– it is known to work nicely with LMIC on AC/STM32.
That post is 2 years old.
The Arduino Core STM32 was relatively new then and has since been further developed.
Apparently that previous workaround for LMIC-Arduino is not required anymore.
What exactly do you mean with ‘it’ and ‘AC/STM32’?
Please be clear and use regular (full) names to prevent unnecessary confusion like above.
So what did you mean with ‘it’ in “it works nicely”?
According to this post:
listed couple pages above:
Libraries:
Patches:
So the patch is still required to apply onto MCCI LMIC library.
1 Like
Because the previous issue with Arduino Core STM + LMIC-Arduino appears not exist to anymore (because both uplinks and downlinks are working without the previous workaround) I had not (yet) tested the previous workaround with the MCCI LoRaWAN LMIC library.
So, it is at least remarkable that it now works (and appears to work correctly) with LMIC-Arduino without the workaround but MCCI LoRaWAN LMIC library still requires the workaround.
I am trying to use Bluepill but no success. i am using MCCI CATENA library. which library are you using?
(FYI: @BoRRoZ is not active on the forum lately.)
“Trying to use but no success”. What have you tried? What does work and what does not?
MCCI LoRaWAN LMIC library should work with bluepill if you apply the library patch/workaround that was discussed just above (but instead of the LMIC-Arduino library patch the source of the MCCI LoRaWAN LMIC library).
It is preferred to use the ‘Arduino Core STM32’ Aduino core. This one is actively maintained by STMicroelectronics.
In the Arduino IDE Boards Manager the ‘Arduino Core STM32’ Arduino core is called ‘STM32 Cores’ by STMicroelectronics. (Names of Arduino cores for STM32 are not always used consistently.)
I use the following pin mapping for the bluepill:
(Values between brackets are standard Arduino pin definition names for this board)
SPI/LoRa module GPIO
MOSI <----------> PA7 / 27 (MOSI)
MISO <----------> PA6 / 26 (MISO)
SCK <----------> PA5 / 25 (SCK)
NSS <----------> PA4 / 24 (SS)
RST <----------> PB0 / 28
DIO0 <----------> PA3 / 23
DIO1 <----------> PA2 / 22
DIO2 - Not needed for LoRa.
Serial port GPIO
RX <----------> PA10 / 10 (PIN_SERIAL_RX)
TX <----------> PA9 / 11 (PIN_SERIAL_TX)
The bluepill can be programmed via serial/UART but I use a STLINK v2 programmer for the flashing instead and use a separate USB to Serial connection for the serial monitor.
(Using STLink automatically puts the boarding into firmware upload mode and automatically resets it afterwards and the serial monitor stays working. This saves from having to change a BOOT jumper and do manual resets).
Code:
#define LORA_NSS SS // 24
#define LORA_RST PB0 // 28
#define LORA_DIO0 PA3 // 23
#define LORA_DIO1 PA2 // 22
// Set LoRa module pin mappings.
const lmic_pinmap lmic_pins = {
.nss = LORA_NSS,
.rxtx = LMIC_UNUSED_PIN,
.rst = LORA_RST,
.dio = { LORA_DIO0, LORA_DIO1, LMIC_UNUSED_PIN }
};
Serial port issue:
My experience with Arduino Core STM32 is that anything printed to the Serial port within the first +/- 2 seconds after calling Serial.begin() will get lost (but the length of that period is not always the same).
The common procedure for checking if the serial port is ready:
Serial.begin(115200);
while (!Serial) { /* wait until serial port is ready */ }
Serial.println("Started");
does not help because Serial indicates that it is ready but the first printed output will get lost anyway. As a workaround a +/- 2 second delay can be added after Serial.begin().
Hello All,
This is my first post to TTN forum. i am struggling to send “hello world”. my node just send it only one time sucessfully and then dont send any more data… looks like it got stucked or hanged after sending one message. i am using standard ttn-abp code,
MCU - STM32F103C8T6
LORA - AiThinker RA-01
I will attach the screen shot of my screen with TTN data page, serial output, and code showing the pin connection.
Thank you in Advance
Really? So this was not you:? 
Which LMIC library (and version) are you using?
What gateway are you using?
Have you tried to disable Frame Counter Checks for the device in TTN Console?
Please do not post screen copies of source code.
See: How do I format my forum post? [HowTo]
oh sorry that was my fired i asked him to solve this problem if possible, but even he was not able to solve it.
Basically now i am using this library https://github.com/mcci-catena/arduino-lmic the latest version 3.0.99
and using arduino pro mini 16mhz @3.3v.
have eddited the project configuration header file in the library to this
// project-specific definitions
//#define CFG_eu868 1
//#define CFG_us915 1
//#define CFG_au915 1
//#define CFG_as923 1
// #define LMIC_COUNTRY_CODE LMIC_COUNTRY_CODE_JP /* for as923-JP */
//#define CFG_kr920 1
#define CFG_in866 1
#define CFG_sx1276_radio 1
#define LMIC_USE_INTERRUPTS
please tell me why my node is not able to send data continiously, it get strucked automatically after some time,
the gateway used is dragino
and have also disabled the frame counter checks in the device setting in ttn console.
Thanks in advance