User:Bertrik Sikken - Revision history

Bertrik Sikken: /* Action 32x32 display */

2026-04-25T10:47:53Z

Action 32x32 display

← Older revision		Revision as of 10:47, 25 April 2026
Line 36:		Line 36:

	=== Action 32x32 display ===		=== Action 32x32 display ===
	Action sells an ACT1026 display. You control it over BLE.		Action sells [https://www.action.com/nl-nl/p/3217439/led-pixelbord/ this ACT1026 display]. You control it over BLE.

	* https://github.com/Pupariaa/Bk-Light-AppBypass works to control it		* https://github.com/Pupariaa/Bk-Light-AppBypass works to control it

Bertrik Sikken: /* Action 32x32 display */

2026-04-18T11:13:18Z

Action 32x32 display

← Older revision		Revision as of 11:13, 18 April 2026
Line 39:		Line 39:

	* https://github.com/Pupariaa/Bk-Light-AppBypass works to control it		* https://github.com/Pupariaa/Bk-Light-AppBypass works to control it
			* software for a similar led display: https://github.com/derkalle4/python3-idotmatrix-client

	=== investigate thread/matter ===		=== investigate thread/matter ===

Bertrik Sikken: /* Project ideas */

2026-04-18T11:08:46Z

Project ideas

← Older revision		Revision as of 11:08, 18 April 2026
Line 34:		Line 34:

	https://pine64.com/product/128mb-ox64-sbc-available-on-december-2-2022/		https://pine64.com/product/128mb-ox64-sbc-available-on-december-2-2022/

			=== Action 32x32 display ===
			Action sells an ACT1026 display. You control it over BLE.

			* https://github.com/Pupariaa/Bk-Light-AppBypass works to control it

	=== investigate thread/matter ===		=== investigate thread/matter ===

Bertrik Sikken: /* Project ideas */

2026-02-22T19:00:36Z

Project ideas

← Older revision		Revision as of 19:00, 22 February 2026
Line 34:		Line 34:

	https://pine64.com/product/128mb-ox64-sbc-available-on-december-2-2022/		https://pine64.com/product/128mb-ox64-sbc-available-on-december-2-2022/

	~~=== Meshcore as citizen science data transport ===~~
	~~See https://github.com/bertrik/meshcore-sensor-net~~

	~~Meshcore is basically a network of repeaters for lora messages with a specific setting.~~
	The idea is to use a citizen science sensor with a LoRa radio to uplink citizen science data through this repeater network, get the data repeated, then pick it up using a special kind of node is connected to the internet (e.g. MQTT) that forwards the data to a collection server for further processing.

	~~The LoRa setting used almost universally in the Netherlands now is the EU/UK setting:~~
	* 869.618 / SF8 / BW62.5 / CR8
	* header enabled
	* sync word XXXX

	~~Description of the on-the-air message: https://gist.github.com/recrof/ca7ccff28c43d1b6bf7e55ce5159100b~~
	~~Dissection code: https://github.com/folkertvanheusden/meshcore-store/blob/master/utils/dissect.py~~

	~~Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).~~

	~~The idea is basically:~~
	* Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.
	* At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.
	* The backend software processes the data payload and sends back an acknowledgement packet back over the (best) path that it received the message on. When this reaches the sensor node, the sensor node knows the most efficient way to reach the gateway node and uses a "direct" packet. Every now and then it expects a kind of acknowledgement packet back from the server, to know that messages are still coming through. This is actually a bit similar to how LoRaWAN works.

	=== investigate thread/matter ===		=== investigate thread/matter ===

Bertrik Sikken: /* Meshcore as citizen science data transport */

2026-02-21T22:27:10Z

Meshcore as citizen science data transport

← Older revision		Revision as of 22:27, 21 February 2026
Line 36:		Line 36:

	=== Meshcore as citizen science data transport ===		=== Meshcore as citizen science data transport ===
			See https://github.com/bertrik/meshcore-sensor-net

	Meshcore is basically a network of repeaters for lora messages with a specific setting.		Meshcore is basically a network of repeaters for lora messages with a specific setting.
	The idea is to use a citizen science sensor with a LoRa radio to uplink citizen science data through this repeater network, get the data repeated, then pick it up using a special kind of node is connected to the internet (e.g. MQTT) that forwards the data to a collection server for further processing.		The idea is to use a citizen science sensor with a LoRa radio to uplink citizen science data through this repeater network, get the data repeated, then pick it up using a special kind of node is connected to the internet (e.g. MQTT) that forwards the data to a collection server for further processing.
Line 51:		Line 53:
	The idea is basically:		The idea is basically:
	* Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.		* Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.
	* ~~When~~ the discovery ~~packet~~ reaches a special internet-connected gateway, the backend software ~~receives it~~ and ~~returns a kind of~~ acknowledgement packet back over the (best) path that it received the message on. When this reaches the sensor node, the sensor node knows the most efficient way to reach the gateway node and uses a "direct" packet. Every now and then it expects a kind of acknowledgement packet back from the server, to know that messages are still coming through. This is actually a bit similar to how LoRaWAN works.		* At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.
			* The backend software processes the data payload and sends back an acknowledgement packet back over the (best) path that it received the message on. When this reaches the sensor node, the sensor node knows the most efficient way to reach the gateway node and uses a "direct" packet. Every now and then it expects a kind of acknowledgement packet back from the server, to know that messages are still coming through. This is actually a bit similar to how LoRaWAN works.

	=== investigate thread/matter ===		=== investigate thread/matter ===

Bertrik Sikken: /* Meshcore as citizen science data transport */

2026-01-27T19:24:36Z

Meshcore as citizen science data transport

← Older revision		Revision as of 19:24, 27 January 2026
Line 45:		Line 45:

	Description of the on-the-air message: https://gist.github.com/recrof/ca7ccff28c43d1b6bf7e55ce5159100b		Description of the on-the-air message: https://gist.github.com/recrof/ca7ccff28c43d1b6bf7e55ce5159100b
			Dissection code: https://github.com/folkertvanheusden/meshcore-store/blob/master/utils/dissect.py

	Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).		Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).

Bertrik Sikken: /* Project ideas */

2026-01-25T13:15:09Z

Project ideas

← Older revision		Revision as of 13:15, 25 January 2026
Line 34:		Line 34:

	https://pine64.com/product/128mb-ox64-sbc-available-on-december-2-2022/		https://pine64.com/product/128mb-ox64-sbc-available-on-december-2-2022/

			=== Meshcore as citizen science data transport ===
			Meshcore is basically a network of repeaters for lora messages with a specific setting.
			The idea is to use a citizen science sensor with a LoRa radio to uplink citizen science data through this repeater network, get the data repeated, then pick it up using a special kind of node is connected to the internet (e.g. MQTT) that forwards the data to a collection server for further processing.

			The LoRa setting used almost universally in the Netherlands now is the EU/UK setting:
			* 869.618 / SF8 / BW62.5 / CR8
			* header enabled
			* sync word XXXX

			Description of the on-the-air message: https://gist.github.com/recrof/ca7ccff28c43d1b6bf7e55ce5159100b

			Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).

			The idea is basically:
			* Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.
			* When the discovery packet reaches a special internet-connected gateway, the backend software receives it and returns a kind of acknowledgement packet back over the (best) path that it received the message on. When this reaches the sensor node, the sensor node knows the most efficient way to reach the gateway node and uses a "direct" packet. Every now and then it expects a kind of acknowledgement packet back from the server, to know that messages are still coming through. This is actually a bit similar to how LoRaWAN works.

	=== investigate thread/matter ===		=== investigate thread/matter ===

Bertrik Sikken at 11:52, 25 January 2026

2026-01-25T11:52:01Z

← Older revision		Revision as of 11:52, 25 January 2026
Line 13:		Line 13:
	* reverse-engineering things (USB stuff, mp3 players), worked on http://rockbox.org (sansa clip players)		* reverse-engineering things (USB stuff, mp3 players), worked on http://rockbox.org (sansa clip players)
	* studying bats and making electronics for recording/listening to bat sounds		* studying bats and making electronics for recording/listening to bat sounds
	* radio stuff, in particular software-defined radio		* radio stuff, in particular software-defined radio, LoRa networks
			* citizen science and open data (particulate matter measurement, noise, water quality)
	* energy-related stuff, visualisation		* energy-related stuff, visualisation
	* citizen science, particulate matter measurement, noise

	Projects I work(ed) on ([https://revspace.nl/index.php?title=User:Bertrik_Sikken&action=purge refresh]):		Projects I work(ed) on ([https://revspace.nl/index.php?title=User:Bertrik_Sikken&action=purge refresh]):

Bertrik Sikken: /* investigate thread/matter */

2026-01-17T11:50:09Z

investigate thread/matter

← Older revision		Revision as of 11:50, 17 January 2026
Line 53:		Line 53:
	./script/build nrf52840 UART_trans -DOT_LOG_LEVEL=OT_LOG_LEVEL_INFO		./script/build nrf52840 UART_trans -DOT_LOG_LEVEL=OT_LOG_LEVEL_INFO

	Thread on ESP32-C6: https://gist.github.com/gtxaspec/d26198daadfb0a8b0a0edeae2d3fd58f		Thread on ESP32:
			* on ESP32 C6 https://gist.github.com/gtxaspec/d26198daadfb0a8b0a0edeae2d3fd58f
			* https://github.com/espressif/esp-thread-br
			* https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_rcp

	=== action lsc stekker ===		=== action lsc stekker ===

Bertrik Sikken: /* investigate thread/matter */

2026-01-17T11:48:40Z

investigate thread/matter

← Older revision		Revision as of 11:48, 17 January 2026
Line 52:		Line 52:
	* Build it:		* Build it:
	./script/build nrf52840 UART_trans -DOT_LOG_LEVEL=OT_LOG_LEVEL_INFO		./script/build nrf52840 UART_trans -DOT_LOG_LEVEL=OT_LOG_LEVEL_INFO

			Thread on ESP32-C6: https://gist.github.com/gtxaspec/d26198daadfb0a8b0a0edeae2d3fd58f

	=== action lsc stekker ===		=== action lsc stekker ===