Sorry, this entry is only available in German.
Category: Misc
Read LoRaWAN data from TTN server
TTN – The Things Network
https://www.thethingsnetwork.org/
Our LoRaWAN sensors use the service of The Things Network. So our LoRaWAN gateway sends the sensor data to the TTN server. The sensors are registered with an ‘application id’ and a ‘device id’.
https://console.thethingsnetwork.org/
Now I want to receive the data on my PC. The TTN server allows to use MQTT.
https://www.thethingsnetwork.org/docs/applications/mqtt/quick-start.html
Note: Currently only the up-topic is working and get the data in JSON format.
https://status.thethings.network/
mosquitto – https://mosquitto.org/
Please read the base information on
https://www.thethingsnetwork.org/docs/applications/mqtt/quick-start.html
We want to subscribe using TLS. The access schema seems to be a little bit different. In our case only with the option ‘-L’ it was possible to switch to TLS communication:
mosquitto_sub.exe -L mqtts://<AppID>:<AppKey>@<region>.thethings.network:8883/+/devices/+/up –cafile mqtt-ca.pem
We receive
{ "app_id":"stm32_example_usi_expansion_board", "dev_id":"sensor-ro-20200522", "hardware_serial":"E24F43FFFE44C1EF", "port":99,"counter":605, "payload_raw":"AHMnSwFnARYCaFADAGQEAQAFAdc=", "payload_fields":{ "barometric_pressure_0":1005.9, "digital_in_3":100, "digital_out_4":0, "digital_out_5":215, "relative_humidity_2":40, "temperature_1":27.8 }, "metadata":{ "time":"2020-07-03T14:02:59.272943586Z", "frequency":868.1, "modulation":"LORA", "data_rate":"SF9BW125", "airtime":246784000, "coding_rate":"4/5", "gateways":[ { "gtw_id":"eui-3133303735005600", "timestamp":920207212, "time":"", "channel":0, "rssi":-44, "snr":11.75, "rf_chain":0 } ] } }
Python
Our solution is based on the package paho-mqtt.
https://pypi.org/project/paho-mqtt/
At the first you have to install it to your python environment. Possible you have to update your paket manager at the first.
example Win10: (of course python should be installed already)
cd Python37-32 python -m pip install --upgrade pip cd scripts pip install paho-mqtt
Now start the python shell – IDLE (Python 3.7 32-bit)
Load/create the small script mqtt.py. It print the sensor value temperature.
import paho.mqtt.client as mqtt import json # The callback for when the client receives a CONNACK response from the server. def on_connect(client, userdata, flags, rc): print('Connected with result code '+str(rc)) client.subscribe('+/devices/+/up') # The callback for when a PUBLISH message is received from the server. def on_message(client, userdata, msg): ergebnis = json.loads(msg.payload) values = ergebnis['payload_fields'] print(values['temperature_1']) client = mqtt.Client() client.on_connect = on_connect client.on_message = on_message client.tls_set() client.username_pw_set('AppId',password='AppKey') client.connect('eu.thethings.network', 8883, 60) client.loop_forever()
Of course you have to configure your AppId and AppKey.
Output:
Connected with result code 0 27.9 27.9 27.9 27.9 27.8 27.9 27.8 27.8 27.8 27.8 27.8
printf() using ST-Link debug interface (SWD, ITM View)
Intention
ARM provides the possibility to use a printf() like a serial output, using the SWD interface (ITM port 0). This example describes the usage using a Nucleo-64 board, ST-Link v2.1 and the STM32CubeIDE.
Note: The Cortex-M0 doesn’t have the required hardware in the mcu. So it is not possible on it.
switch printf() to the debug interface
Often you find the describtion to overwrite _write(). That’s correct. In case of the STM32CubeIDE generated code it is also possible to overwrite the more low level __io_putchar().
/* USER CODE BEGIN 4 */ int __io_putchar(int ch) { ITM_SendChar(ch); return ch; } /* USER CODE END 4 */
Debug Settings
You have to enable the Serial Wire Viewer (SWV). The most relevant setting is the Core clock. You have to configure the correct clock frequency, that you initialize within your application.

Prepare the Debug view
- Open the SWV ITM Console

printf() uses the SWO connector and the trace port 0.
- Add ITM port 0

- Enable ITM port 0

- Start trace to view the printf() output

That’s all.

Alternative ST-Link Utility

Using UART3 as virtual COM on Nucleo-64 / STM32L476
Intention
By default the UART2 is connected to the virtual COM of the ST-Link. The same UART is possible to connect to the Arduino connector.
So I want to connect the UART3 to the virtual COM connector and use the UART2 for the Arduino connector (CN9 Pin 1 and 2),
The description is for an Nucleo-64 STM32L476, but should be compatible to some more Nucleo-64 boards, too.
Hardware changes
Switch UART2 to the Arduino connector
- open solder bridge SB13 and SB14
- close solder bridge SB62 and SB63

Switch UART3 to the VCOM of the ST-Link
- connect ST-Link connector TX to PC5 (Uart3 RX, CN10 pin 6)
- connect ST-Link connector RX to PC4 (Uart3 TX, CN10 pin 34)

Software changes
- initialize UART3 (e.g. 115200 Baud, 8N1) with PC4 and PC5
- in case you want to use printf
int __io_putchar(int ch) { HAL_UART_Transmit(&huart3, (uint8_t *)&ch, 1, 0xFFFF); //ITM_SendChar(ch); return ch; }
- alternatively overwrite _write()
can4osx – CAN USB device driver for Mac
When it comes to embedded development, the Mac becomes more and more popular. Because of that many semiconductor nowadays provide native Mac support for there Integrated Development Environments. All the Major ones have tools for developing and debugging on Mac machines. But when it comes to embedded development on CAN based system most of us encounter the problem that there is no native support for most of the CAN to USB interfaces. Almost none the CAN interface manufactures provide a proper device driver for Mac.
Because of that a open source project, called can4osx, startet. It’s supposed as a generic CAN interface driver for CAN-USB interfaces of different vendors.
What is can4osx?
can4osx was born as a daughter project of can4linux, a project with the aim to bring CAN interfaces to Linux since several years. can4osx is a CAN-USB device driver, completely running in the User-Space of OSX. It uses OKitLib and IOUSBLib, so it doesn’t have to run in the kernel. The driver can be directly compiled into applications, or run as a library.
How to use it
can4osx comes with an API, which is very close to the API of Kvasers CANLIB. A little example how to use it in a simple application:
void simpleSend(void) { CanHandle hdl; int channel = 0; int bitrate = canBITRATE_125K; canInitializeLibrary(); hdl = canOpenChannel(channel, canOPEN_EXCLUSIVE | canOPEN_REQUIRE_EXTENDED); canBusOff(hdl); canSetBusParams(hdl, bitrate, 10, 5, 1, 1, 0); canBusOn(hdl); canWrite(hdl, 0x123, &quot;can4osx&quot;, 8, 0); canBusOff(hdl); }
Supported interfaces
At the moment only a few interfaces are officially supported. The reason for that is that only a few real hardware interface could be verified. Verified ones are:
- Kvaser Leaf Light V.2
- IXXAT USB-to-CAN FD Automotive
- Kvaser Leaf Pro V.2 (unstable)
But since can4osx is open source every can implement or verify other interfaces.
Where is can4osx used
Besides in some little CAN hobby projects, can4osx is used for example in the Mac Toolchain version of the different CAN Tools of the company emotas embedded communication GmbH.