https://revspace.nl/wiki/api.php?action=feedcontributions&feedformat=atom&user=Bertrik+SikkenRevSpace - User contributions [en-gb]2026-05-13T14:51:08ZUser contributionsMediaWiki 1.43.6https://revspace.nl/wiki/index.php?title=Karaburan&diff=35229Karaburan2026-05-11T12:13:17Z<p>Bertrik Sikken: /* BT785 */</p>
<hr />
<div>{{Project<br />
|Name=Karaburan<br />
|Picture=karaburan.png<br />
|Omschrijving=Monitoring water quality<br />
|Status=In progress<br />
|Contact=bertrik<br />
}}<br />
<br />
== Next steps ==<br />
* <s>engage with PX4 community on getting a feel if this is useful to use and if so, how to get started</s><br />
* <s>figure out how to duplicate an MQTT stream</s> don't bother<br />
* write python scripts<br />
** <s>arduino turbidity</s> don't bother<br />
** <s>turbidity-to-mqtt</s> maybe make this ROS module<br />
** <s>HID-to-mqtt</s> maybe make this ROS module<br />
** position/velocity listener script: latitude, longitude, altitude, heading/bearing/track/whatever, velocity<br />
* hook things into systemd / udev<br />
* analoog in op de pi:<br />
** https://elektronicavoorjou.nl/product/adc-pi/<br />
** https://www.123materialen.com/products/zeer-nauwkeurige-ads1256-dac8552-ad-da-board-voor-raspberry-pi_1676153<br />
** FreeJoy project<br />
* UPS voor pi: https://elektronicavoorjou.nl/product/raspberry-pi-ups-hat/<br />
* 1-wire stuff:<br />
** 1-wire adapter emulation on an stm32: https://github.com/alitekin2fx/stm32_ds2480_emu<br />
** owfs.org for easy interfacing with multiple 1-wire devices in a hierarchical way on linux<br />
* Figure out the udev/hotplug mess, we probably need this because many of our peripherals use a serial port:<br />
** in how many places can we store the udev renaming logic (config files)<br />
** can we automate this, make it user friendlier, e.g. some kind of "insert device X now" script<br />
<br />
Check:<br />
* https://www.rtvnoord.nl/natuur/1215705/vuilrobot-maakt-jachthaven-winschoten-schoon-beter-dan-met-een-schepnet<br />
<br />
=== USB HID as analog input ===<br />
An stm32 based bluepill board can be flashed with firmware to allow its analog inputs to be exposed as USB HID sliders.<br />
<br />
Flashing the bluepill with openocd to the freejoy firmware:<br />
* install openocd<br />
sudo apt install openocd<br />
* connect an stlinkv2 to an stm32 bluepill, connect the stlinkv2 to USB<br />
* flash the freejoy firmware as follows:<br />
** download the firmware from https://github.com/FreeJoy-Team/FreeJoy<br />
** create a symlink to the hex file called firmware.hex<br />
** flash the firmware from the command line<br />
openocd -s /usr/share/openocd/scripts -f interface/stlink.cfg -f target/stm32f1x.cfg -c init -c "program firmware.hex verify reset exit"<br />
* watch the kernel logs<br />
sudo dmesg -w<br />
* connect the stm32 using a USB cable<br />
* download the freejoy configurator from https://github.com/FreeJoy-Team/FreeJoyConfiguratorQt<br />
* start the configurator and load the karaburan.cfg setting<br />
* Write config to device -> it should reboot now and come up with the new settings<br />
<br />
Verify that it works:<br />
* install the evtest package<br />
* run<br />
evtest /dev/input/by-id/usb-FreeJoy_FreeJoy_v1.7.1-event-if00<br />
<br />
See also https://github.com/vostrenkov/EazyJoy<br />
<br />
=== influxdb ===<br />
See https://hub.docker.com/_/influxdb<br />
<br />
See https://github.com/bertrik/karaburan/tree/master/influxdb<br />
<br />
=== ROS ===<br />
Investigation:<br />
* Use ROS 2, not the old ROS 1<br />
* Cannot work comfortably with debian, works best with ubuntu<br />
* Using gpsd:<br />
** install ros-jazzy-desktop<br />
** ros2 launch gpsd_client gpsd_client-launch.py<br />
<br />
== Introduction ==<br />
Topics:<br />
* air quality sensors<br />
** ammonia<br />
** NOx<br />
* water chemical analysis<br />
** nitrates<br />
** ammonia<br />
** dissolved oxygen<br />
** sulfide/sulfate<br />
** phosphates?<br />
** salinity (chlorides?)<br />
* water physical analysis<br />
** temperature<br />
** clarity/turbidity -> investigate standard ways of measuring/expressing this<br />
** conductivity/total dissolved solids<br />
** water properties by light reflection, hyperspectral/polarity<br />
** depth?<br />
* boat control<br />
** trajectory -> steering<br />
** idea: interface with the remote control, not with the boat<br />
** idea: find a boat with easily hackable remote control protocol<br />
** idea: can we get sensor data over this link too, e.g. GPS?<br />
* camera control<br />
* post-processing<br />
** data presentation<br />
*** video/photo stitching<br />
*** time lapse view<br />
*** map view of properties<br />
* use cases<br />
** verify with domain experts, how to engage?<br />
** slootview, under/above water<br />
** minimum viable prototype<br />
** high-res measurement by location, by time<br />
* materials<br />
** boat selection<br />
** processing platform selection<br />
** communication platform selection<br />
<br />
== Investigate RTK GPS ==<br />
Goal: figure out if it is practically possible to achieve cm resolution with a 200-euro GPS and a free correction service: YES<br />
<br />
* https://www.nsgi.nl/referentiepunten-en-gnss-data/gnss-data/real-time-streams public correction data service<br />
* https://www.ardusimple.nl/rtk-in-5-minutes/<br />
* RTK in action https://www.youtube.com/watch?v=Oc1LBFDj2MA<br />
* Use with Linux / gpsd: https://stackoverflow.com/questions/77314115/drotek-gpsd-and-ntrip-correction-data-for-precise-positioning ?<br />
* Chipsets<br />
** Quectel LC29H (default: 115200 bps)<br />
*** review: see https://rtklibexplorer.wordpress.com/2024/04/28/dual-frequency-rtk-for-less-than-60-with-the-quectel-lc29hea/<br />
*** configuration: https://rtklibexplorer.wordpress.com/2024/05/06/configuring-the-quectel-lc29hea-receiver-for-real-time-rtk-solutions/<br />
** uBLOX ZED-F9P<br />
* Boards<br />
** UM980 / UM982<br />
<br />
Edit /etc/default/gpsd, set GPSD_OPTIONS:<br />
GPSD_OPTIONS="-Gn ntrip://user:pass@ntrip.kadaster.nl:2101/CBW100NLD0"<br />
Option -G exposes the control socket on all network interfaces, option -n keeps the GPS active if there is no one currently connected.<br />
<br />
Plotting live location on a map:<br />
* Configure gpsd to expose its socket to the outside world: last section of https://gpsd.gitlab.io/gpsd/troubleshooting.html<br />
* In QGIS, press ctrl+0 to show the GPS information tab, enter the name of the remote gpsd (port 2947)<br />
<br />
Station at Stolwijk (close to Gouda): https://gnss1.tudelft.nl/dpga/station/Stolwijk.html#STWK ?<br />
<br />
Starting from the command line:<br />
* stop gpsd.socket<br />
sudo systemctl stop gpsd.socket<br />
* run from command line<br />
sudo /usr/sbin/gpsd -Gn -D 1 -N /dev/ttyUSB0 .... (not sure yet)<br />
<br />
=== Validation ===<br />
How to show that RTK GPS is actually accurate?<br />
<br />
* Relative positioning: with an "fix RTK" solution, place the antenna at 4 points 25cm apart, each point for 20 seconds or so -> you see 4 distinct clusters of points<br />
* Positioning over short time: put it in a fixed location, make sure that it has "fix RTK" solution, take 100 measurements or so -> determine the radius of the circle that contains 90% of the points<br />
* Positioning over longer time: do this for (say) an hour<br />
* Absolute positioning: look up a national reference point, for example "RD-punt 389346", located on the Sluisdijk between Gouda and Moordrecht. Technical data: https://www.nsgi.nl/iv-api/rdinfo/rdpoint/389346<br />
** see https://www.nsgi.nl/referentiepunten-en-gnss-data/informatie-referentiepunten/rdinfo and enter 389346<br />
** latitude: 51° 59' 49,64048" , longitude: 4° 41' 19,90765", or 51.99712236/4.68886324<br />
<br />
==== Comparison with reference coordinate ====<br />
On october 4th 2024, we took the RTK GPS to a kernnet reference point at 51.99712236/4.68886324, results below:<br />
<br />
From https://www.nsgi.nl/iv-api/rdinfo/rdpoint/389346:<br />
* Year 2021: "51 59 49,64004", "4 41 19,90584", 48.039. In decimal degrees that is <br />
<br />
Differences between the reference point and the measurements are calculated to easting ('X') and northing ('Y'), unit meter. To calculate distance in meters, we use a linear approximation:<br />
* For dy: 40075km/360 = 111,319 m/deg<br />
* For dx: dy * cos(latitude) = 68,549 m/deg<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|+ Measurements + deviations<br />
|-<br />
! Name !! Latitude !! Longitude !! dx (m) !! dy (m) !! absolute (m) !! Remark<br />
|-<br />
| Reference 2012 || 51.99712236 || 4.68886324 || - || - || 0 || by definition<br />
|-<br />
| Reference 2021 || 51.99712223 || 4.68886273 || - || - || 0 || by definition<br />
|-<br />
| Screenshot 1 || 51.99712217 || 4.68886567 || 0.167 || -0.021 || 0.168 || - <br />
|-<br />
| Screenshot 2 || 51.99712200 || 4.68886533 || 0.143 || -0.040 || 0.149 || -<br />
|-<br />
| Meting 1 || 51.9971220 || 4.6888663 || 0.210 || -0.040 || 0.214 || -<br />
|-<br />
| Meting 2 || 51.9971222 || 4.6888660 || 0.189 || -0.018 || 0.190 || -<br />
|-<br />
| Average || - || - || 0.177 || -0.030 || 0.180 || -<br />
|}<br />
<br />
According to [https://www.unavco.org/software/geodetic-utilities/plate-motion-calculator/plate-motion-calculator.html this page], the rate of movement is about<br />
15.75mm/year to the north and 17.45 mm/year to the east (ITRF2020 model).<br />
Over 12 years, that amounts to 0.189m north and 0.209m east.<br />
<br />
== Air quality sensors ==<br />
<br />
=== Nitrogen compounds in air ===<br />
According to https://www.rivm.nl/stikstof/monitoren-advies-onderzoek/overzicht-stikstofmetingen/metingen-stikstof-in-de-lucht average (typical?) values of<br />
* Ammonia (NH3): 6.7 ug/m3 (9.6 ppb)<br />
* NOx: 27.3 ug/m3<br />
* NO2: 18.6 ug/m3 (9.9 ppb)<br />
<br />
(ppb-conversion using https://www.breeze-technologies.de/blog/air-pollution-how-to-convert-between-mgm3-%C2%B5gm3-ppm-ppb/ )<br />
<br />
RIVM report on inexpensive nitrogen-in-air sensors: https://www.samenmeten.nl/sensoren-voor-no2<br />
Conclusion: most sensors are not sensitive enough to be used in typical outdoor conditions, with perhaps one exception: alphasense NO2-B43F<br />
<br />
== Sonar sensors ==<br />
Investigate this because it allows us to measure depth.<br />
<br />
AliExpress has several types of affordable sonar sensors, focused at detecting fish, but also able to measure depth.<br />
<br />
I ordered this one: https://nl.aliexpress.com/item/1005006388343879.html<br />
* 125 kHz main frequency, range up to 200 ft deep (about 60m)<br />
* bluetooth low-power interface (basically serial-over-BLE)<br />
* built-in battery, powers on automatically when submerged<br />
* reports 120-element array with raw sonar return intensity-vs-depth<br />
* measures water temperature<br />
* about 45 euro<br />
<br />
Fish helper pro application for android https://apkpure.com/fish-helper-pro/com.fishfinderpro.xdx<br />
<br />
=== Debug tool ===<br />
I wrote a python script to connect to it from a linux computer: https://github.com/bertrik/wireless-sonar-sensor<br />
<br />
It's connects to a "Fish Helper Pro" wireless sonar sensor over bluetooth low-energy, reports depth and temperature<br />
<br />
=== ROS2 integration ===<br />
The most appropriate message for a simple range would be: https://docs.ros2.org/foxy/api/sensor_msgs/msg/Range.html<br />
<br />
There are other messages to perhaps report the raw echo return array.<br />
<br />
== Water physical analysis ==<br />
=== Turbidity / clarity ===<br />
See https://en.wikipedia.org/wiki/Turbidity<br />
<br />
Aliexpress sensor '''TS-300B''': https://nl.aliexpress.com/item/1005006732956937.html<br />
Has a range 0 ~ 1000 ± 30 NTU<br />
<br />
Order of magnitude for turbidity:<br />
* Drinking water upper limit: '''4 NTU''' (European turbidity standard for drinking water)<br />
* Ambient water: 10-150 NTU. The US state of Washington use a "background" value of '''50 NTU''' as reference.<br />
<br />
(see https://en.wikipedia.org/wiki/Turbidity#Standards_and_test_methods )<br />
<br />
So the Aliexpress sensor is suited only for "dirty" water.<br />
<br />
=== Water measurement probes ===<br />
* https://nl.aliexpress.com/item/1005003784454381.html BLE-9908 Inexpensie "Yieryi" PH/EC/Temp probe with bluetooth and app, about E25,- (Uses 3x LR44 coin cell batteries)<br />
* Several different models: https://nl.aliexpress.com/item/1005007810989801.html<br />
** EZ9901: TDS/pH/temp<br />
** EZ9902: EC/pH/temp<br />
** EZ9908: EC/TDS/pH/temp<br />
** EZ9909: TDS/EC/pH/salt/temp<br />
* The bluetooth versions are probably as above, with numbers like BLE9902 and BLE9908<br />
* Yiery BLE9902: https://shop.yieryimeters.com/products/yieryi-ble-9902-3-in-1-digital-ph-meter-with-bluetooth-ec-and-temperature-measurement-ideal-for-water-quality-testing-in-pools-fish-tanks-hydroponics-more<br />
* BLE-EC01 is a bluetooth EC meter, can find it here https://www.amazon.com/BLE-EC01-Smart4-TDS-Temp-Meter/dp/B0DPZZC7BV, not on AliExpress?<br />
<br />
Note:<br />
* Some probes indicate EC (electrical conductivity), other indicate TDS (total dissolved liquids). TDS is derived from EC (knowing the liquid type). EC is the more universal/fundamental property!<br />
* EC is typically expressed in uS/cm or mS/cm (micro or milli siemens per centimeter), say 500 uS/cm for outdoor water.<br />
* EC is temperature dependent, typically you need the value extrapolated to 25 degrees Celcius. Temperature-EC correlation rule of thumb: about 2% more conductive per K.<br />
* pH sensors are almost by definition fragile and last only a limited time, so probably don't bother trying to use one at all. The pH of outdoor water might not be that interesting to measure.<br />
* I expect the non-TuYa meters to use an easier to handle bluetooth protocol, avoiding the need for complicated encryption with a key that can only be fetched for a limited time using a tuya developer account.<br />
<br />
==== BT785 ====<br />
I bought this one: Tuya compatible BT785 EC meter: https://nl.aliexpress.com/i/1005007462079781.html inexpensive, focused on EC, runs on 4x LR44.<br />
Speaks the TuYa protocol (requires a secret key that you can fetch through the developer console).<br />
This is quite cumbersome: you have to register as a developer, fetch the key before time runs out and developer access is limited.<br />
<br />
Does NOT speak the universal serialport access protocol as described here:<br />
https://developer.tuya.com/en/docs/iot/tuya-cloud-universal-serial-port-access-protocol?id=K9hhi0xxtn9cb<br />
<br />
More information on this wiki: https://revspace.nl/BT785<br />
Code: https://github.com/bertrik/bt785<br />
<br />
==== Cheap non-bluetooth EC/TDS ====<br />
I got this one: https://nl.aliexpress.com/item/1005007267608479.html<br />
<br />
Tear-down on hackaday: https://hackaday.io/project/184764-ectds-temp-meter-teardown<br />
<br />
== Boat control ==<br />
Typically the wireless link looks like this:<br />
* 2.4 GHz working frequency<br />
* 500m range<br />
<br />
Interesting links:<br />
* Flytec-2011 remote control https://nl.aliexpress.com/item/1005002984723718.html<br />
* Replacement board for various boats with "18" in their type number: https://nl.aliexpress.com/item/1005006115484716.html<br />
* DIY Multi-protocol module: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module<br />
<br />
=== remote control ===<br />
Image of remote control RF chip:<br />
[...]<br />
<br />
Parts:<br />
* 12.000 MHz crystal/oscillator<br />
* 16-pin control chip: 20_CL6L071<br />
* 6-pin RF chip: 1110 / VKA3, could be an rx/tx switch, amplifier or filter circuit<br />
<br />
See also: https://www.open-tx.org/<br />
<br />
Next steps:<br />
* map out the connections between the mainboard and the rf board, expected: VCC, GND, spi ?<br />
<br />
== Use cases ==<br />
material:<br />
* https://www.youtube.com/watch?v=cMk0bGvIU1E<br />
* https://iplo.nl/thema/water/oppervlaktewater/kaderrichtlijn-water<br />
* kaartje: https://krw-nutrend.netlify.app/ -> 2 meetpunten op de reeuwijkse plassen, tijdresolutie is 1 jaar?<br />
<br />
Useful distinction, typically used in documents/guidelines:<br />
* chemical quality, what substances are present in the water?<br />
* biological / ecology quality, what kind of living organisms live in the water?<br />
<br />
=== Reeuwijkse plassen ===<br />
See<br />
* https://www.rijnland.net/wat-doet-rijnland/in-uw-buurt/reeuwijkse-plassen/ their stated goal: CLEAR WATER<br />
* https://www.rijnland.net/regels-op-een-rij/subsidies-en-andere-financi%C3%ABle-bijdragen/<br />
<br />
potential applications:<br />
* inspect water sides (oever) over time<br />
* underwater camera: detect invasive cray fish<br />
* sample water properties at high spatial resolution, high time resolution<br />
* early detection of indicators for cyanobacteria: temperature and nutrients<br />
<br />
=== Detect/find pollution source ===<br />
* ...<br />
<br />
== Implementation ==<br />
<br />
=== udev handling of serial ports ===<br />
Many peripheral devices are connected through serial.<br />
The plan is to have an udev config file with renaming rules, so each peripheral gets a stable name in /dev .<br />
The plan is also to create the udev config using some python: insert device X now -> write line to udev config.<br />
<br />
The udev config file is:<br />
/etc/udev/rules.d/99-usb-serial.rules<br />
<br />
<pre><br />
# LIDAR serial converter<br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="ttyLIDAR", MODE="0660", GROUP="dialout"<br />
# quectel GPS<br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", SYMLINK+="ttyGPS", MODE="0660", GROUP="dialout"<br />
# ublox GPS<br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="ttyGPS", MODE="0660", GROUP="dialout"<br />
</pre><br />
<br />
An USB-nano also appears to have a USB vendor/product id of 1a86/7523 ("USB2.0-Serial") ... same as the quectel GPS?<br />
<br />
Same for "AI thinker" USB-serial: vendor/product id of 1a86/7523 (product: "USB2.0-Serial")<br />
<br />
To (re)load the properties:<br />
<pre><br />
sudo udevadm control --reload-rules<br />
</pre><br />
<br />
=== reading temperature sensor ===<br />
The idea is to to use a DB18B20 temperature sensor, read it using an arduino nano board acting as a 1-wire adapter.<br />
Use openwire-fs as user-side openwire software http://owfs.org<br />
<br />
Preparation:<br />
* Add the regular user to the 'dialout' group, so it can access serial ports<br />
sudo adduser <name> dialout<br />
<br />
Setting up the hardware:<br />
* connect the DS18B20 to the connector board with the pull-ups<br />
* wire the connector board to the arduino nano, see ...<br />
* plug the arduino nano in the pi<br />
<br />
Setting up the software:<br />
* Install openwire fs<br />
sudo apt install owfs<br />
* Create the openwire fs mountpoint<br />
sudo mkdir /mnt/1wire<br />
* Configure owfs, edit /etc/owfs.conf<br />
server: device = /dev/ttyUSB0<br />
mountpoint = /mnt/1wire<br />
allow_other<br />
(comment out the line with the FAKE devices)<br />
* Configure systemd services<br />
sudo systemctl enable owserver owhttpd<br />
sudo systemctl disable owftpd<br />
* Start the systemd service<br />
sudo systemctl start owserver owhttpd<br />
* Check the logs<br />
sudo journalctl -xeu owserver -f<br />
* Open a browser to view the web interface<br />
http://localhost:2121 or<br />
http://raspberrypi.local:2121</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Karaburan&diff=35228Karaburan2026-05-11T12:12:36Z<p>Bertrik Sikken: /* BT785 */</p>
<hr />
<div>{{Project<br />
|Name=Karaburan<br />
|Picture=karaburan.png<br />
|Omschrijving=Monitoring water quality<br />
|Status=In progress<br />
|Contact=bertrik<br />
}}<br />
<br />
== Next steps ==<br />
* <s>engage with PX4 community on getting a feel if this is useful to use and if so, how to get started</s><br />
* <s>figure out how to duplicate an MQTT stream</s> don't bother<br />
* write python scripts<br />
** <s>arduino turbidity</s> don't bother<br />
** <s>turbidity-to-mqtt</s> maybe make this ROS module<br />
** <s>HID-to-mqtt</s> maybe make this ROS module<br />
** position/velocity listener script: latitude, longitude, altitude, heading/bearing/track/whatever, velocity<br />
* hook things into systemd / udev<br />
* analoog in op de pi:<br />
** https://elektronicavoorjou.nl/product/adc-pi/<br />
** https://www.123materialen.com/products/zeer-nauwkeurige-ads1256-dac8552-ad-da-board-voor-raspberry-pi_1676153<br />
** FreeJoy project<br />
* UPS voor pi: https://elektronicavoorjou.nl/product/raspberry-pi-ups-hat/<br />
* 1-wire stuff:<br />
** 1-wire adapter emulation on an stm32: https://github.com/alitekin2fx/stm32_ds2480_emu<br />
** owfs.org for easy interfacing with multiple 1-wire devices in a hierarchical way on linux<br />
* Figure out the udev/hotplug mess, we probably need this because many of our peripherals use a serial port:<br />
** in how many places can we store the udev renaming logic (config files)<br />
** can we automate this, make it user friendlier, e.g. some kind of "insert device X now" script<br />
<br />
Check:<br />
* https://www.rtvnoord.nl/natuur/1215705/vuilrobot-maakt-jachthaven-winschoten-schoon-beter-dan-met-een-schepnet<br />
<br />
=== USB HID as analog input ===<br />
An stm32 based bluepill board can be flashed with firmware to allow its analog inputs to be exposed as USB HID sliders.<br />
<br />
Flashing the bluepill with openocd to the freejoy firmware:<br />
* install openocd<br />
sudo apt install openocd<br />
* connect an stlinkv2 to an stm32 bluepill, connect the stlinkv2 to USB<br />
* flash the freejoy firmware as follows:<br />
** download the firmware from https://github.com/FreeJoy-Team/FreeJoy<br />
** create a symlink to the hex file called firmware.hex<br />
** flash the firmware from the command line<br />
openocd -s /usr/share/openocd/scripts -f interface/stlink.cfg -f target/stm32f1x.cfg -c init -c "program firmware.hex verify reset exit"<br />
* watch the kernel logs<br />
sudo dmesg -w<br />
* connect the stm32 using a USB cable<br />
* download the freejoy configurator from https://github.com/FreeJoy-Team/FreeJoyConfiguratorQt<br />
* start the configurator and load the karaburan.cfg setting<br />
* Write config to device -> it should reboot now and come up with the new settings<br />
<br />
Verify that it works:<br />
* install the evtest package<br />
* run<br />
evtest /dev/input/by-id/usb-FreeJoy_FreeJoy_v1.7.1-event-if00<br />
<br />
See also https://github.com/vostrenkov/EazyJoy<br />
<br />
=== influxdb ===<br />
See https://hub.docker.com/_/influxdb<br />
<br />
See https://github.com/bertrik/karaburan/tree/master/influxdb<br />
<br />
=== ROS ===<br />
Investigation:<br />
* Use ROS 2, not the old ROS 1<br />
* Cannot work comfortably with debian, works best with ubuntu<br />
* Using gpsd:<br />
** install ros-jazzy-desktop<br />
** ros2 launch gpsd_client gpsd_client-launch.py<br />
<br />
== Introduction ==<br />
Topics:<br />
* air quality sensors<br />
** ammonia<br />
** NOx<br />
* water chemical analysis<br />
** nitrates<br />
** ammonia<br />
** dissolved oxygen<br />
** sulfide/sulfate<br />
** phosphates?<br />
** salinity (chlorides?)<br />
* water physical analysis<br />
** temperature<br />
** clarity/turbidity -> investigate standard ways of measuring/expressing this<br />
** conductivity/total dissolved solids<br />
** water properties by light reflection, hyperspectral/polarity<br />
** depth?<br />
* boat control<br />
** trajectory -> steering<br />
** idea: interface with the remote control, not with the boat<br />
** idea: find a boat with easily hackable remote control protocol<br />
** idea: can we get sensor data over this link too, e.g. GPS?<br />
* camera control<br />
* post-processing<br />
** data presentation<br />
*** video/photo stitching<br />
*** time lapse view<br />
*** map view of properties<br />
* use cases<br />
** verify with domain experts, how to engage?<br />
** slootview, under/above water<br />
** minimum viable prototype<br />
** high-res measurement by location, by time<br />
* materials<br />
** boat selection<br />
** processing platform selection<br />
** communication platform selection<br />
<br />
== Investigate RTK GPS ==<br />
Goal: figure out if it is practically possible to achieve cm resolution with a 200-euro GPS and a free correction service: YES<br />
<br />
* https://www.nsgi.nl/referentiepunten-en-gnss-data/gnss-data/real-time-streams public correction data service<br />
* https://www.ardusimple.nl/rtk-in-5-minutes/<br />
* RTK in action https://www.youtube.com/watch?v=Oc1LBFDj2MA<br />
* Use with Linux / gpsd: https://stackoverflow.com/questions/77314115/drotek-gpsd-and-ntrip-correction-data-for-precise-positioning ?<br />
* Chipsets<br />
** Quectel LC29H (default: 115200 bps)<br />
*** review: see https://rtklibexplorer.wordpress.com/2024/04/28/dual-frequency-rtk-for-less-than-60-with-the-quectel-lc29hea/<br />
*** configuration: https://rtklibexplorer.wordpress.com/2024/05/06/configuring-the-quectel-lc29hea-receiver-for-real-time-rtk-solutions/<br />
** uBLOX ZED-F9P<br />
* Boards<br />
** UM980 / UM982<br />
<br />
Edit /etc/default/gpsd, set GPSD_OPTIONS:<br />
GPSD_OPTIONS="-Gn ntrip://user:pass@ntrip.kadaster.nl:2101/CBW100NLD0"<br />
Option -G exposes the control socket on all network interfaces, option -n keeps the GPS active if there is no one currently connected.<br />
<br />
Plotting live location on a map:<br />
* Configure gpsd to expose its socket to the outside world: last section of https://gpsd.gitlab.io/gpsd/troubleshooting.html<br />
* In QGIS, press ctrl+0 to show the GPS information tab, enter the name of the remote gpsd (port 2947)<br />
<br />
Station at Stolwijk (close to Gouda): https://gnss1.tudelft.nl/dpga/station/Stolwijk.html#STWK ?<br />
<br />
Starting from the command line:<br />
* stop gpsd.socket<br />
sudo systemctl stop gpsd.socket<br />
* run from command line<br />
sudo /usr/sbin/gpsd -Gn -D 1 -N /dev/ttyUSB0 .... (not sure yet)<br />
<br />
=== Validation ===<br />
How to show that RTK GPS is actually accurate?<br />
<br />
* Relative positioning: with an "fix RTK" solution, place the antenna at 4 points 25cm apart, each point for 20 seconds or so -> you see 4 distinct clusters of points<br />
* Positioning over short time: put it in a fixed location, make sure that it has "fix RTK" solution, take 100 measurements or so -> determine the radius of the circle that contains 90% of the points<br />
* Positioning over longer time: do this for (say) an hour<br />
* Absolute positioning: look up a national reference point, for example "RD-punt 389346", located on the Sluisdijk between Gouda and Moordrecht. Technical data: https://www.nsgi.nl/iv-api/rdinfo/rdpoint/389346<br />
** see https://www.nsgi.nl/referentiepunten-en-gnss-data/informatie-referentiepunten/rdinfo and enter 389346<br />
** latitude: 51° 59' 49,64048" , longitude: 4° 41' 19,90765", or 51.99712236/4.68886324<br />
<br />
==== Comparison with reference coordinate ====<br />
On october 4th 2024, we took the RTK GPS to a kernnet reference point at 51.99712236/4.68886324, results below:<br />
<br />
From https://www.nsgi.nl/iv-api/rdinfo/rdpoint/389346:<br />
* Year 2021: "51 59 49,64004", "4 41 19,90584", 48.039. In decimal degrees that is <br />
<br />
Differences between the reference point and the measurements are calculated to easting ('X') and northing ('Y'), unit meter. To calculate distance in meters, we use a linear approximation:<br />
* For dy: 40075km/360 = 111,319 m/deg<br />
* For dx: dy * cos(latitude) = 68,549 m/deg<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|+ Measurements + deviations<br />
|-<br />
! Name !! Latitude !! Longitude !! dx (m) !! dy (m) !! absolute (m) !! Remark<br />
|-<br />
| Reference 2012 || 51.99712236 || 4.68886324 || - || - || 0 || by definition<br />
|-<br />
| Reference 2021 || 51.99712223 || 4.68886273 || - || - || 0 || by definition<br />
|-<br />
| Screenshot 1 || 51.99712217 || 4.68886567 || 0.167 || -0.021 || 0.168 || - <br />
|-<br />
| Screenshot 2 || 51.99712200 || 4.68886533 || 0.143 || -0.040 || 0.149 || -<br />
|-<br />
| Meting 1 || 51.9971220 || 4.6888663 || 0.210 || -0.040 || 0.214 || -<br />
|-<br />
| Meting 2 || 51.9971222 || 4.6888660 || 0.189 || -0.018 || 0.190 || -<br />
|-<br />
| Average || - || - || 0.177 || -0.030 || 0.180 || -<br />
|}<br />
<br />
According to [https://www.unavco.org/software/geodetic-utilities/plate-motion-calculator/plate-motion-calculator.html this page], the rate of movement is about<br />
15.75mm/year to the north and 17.45 mm/year to the east (ITRF2020 model).<br />
Over 12 years, that amounts to 0.189m north and 0.209m east.<br />
<br />
== Air quality sensors ==<br />
<br />
=== Nitrogen compounds in air ===<br />
According to https://www.rivm.nl/stikstof/monitoren-advies-onderzoek/overzicht-stikstofmetingen/metingen-stikstof-in-de-lucht average (typical?) values of<br />
* Ammonia (NH3): 6.7 ug/m3 (9.6 ppb)<br />
* NOx: 27.3 ug/m3<br />
* NO2: 18.6 ug/m3 (9.9 ppb)<br />
<br />
(ppb-conversion using https://www.breeze-technologies.de/blog/air-pollution-how-to-convert-between-mgm3-%C2%B5gm3-ppm-ppb/ )<br />
<br />
RIVM report on inexpensive nitrogen-in-air sensors: https://www.samenmeten.nl/sensoren-voor-no2<br />
Conclusion: most sensors are not sensitive enough to be used in typical outdoor conditions, with perhaps one exception: alphasense NO2-B43F<br />
<br />
== Sonar sensors ==<br />
Investigate this because it allows us to measure depth.<br />
<br />
AliExpress has several types of affordable sonar sensors, focused at detecting fish, but also able to measure depth.<br />
<br />
I ordered this one: https://nl.aliexpress.com/item/1005006388343879.html<br />
* 125 kHz main frequency, range up to 200 ft deep (about 60m)<br />
* bluetooth low-power interface (basically serial-over-BLE)<br />
* built-in battery, powers on automatically when submerged<br />
* reports 120-element array with raw sonar return intensity-vs-depth<br />
* measures water temperature<br />
* about 45 euro<br />
<br />
Fish helper pro application for android https://apkpure.com/fish-helper-pro/com.fishfinderpro.xdx<br />
<br />
=== Debug tool ===<br />
I wrote a python script to connect to it from a linux computer: https://github.com/bertrik/wireless-sonar-sensor<br />
<br />
It's connects to a "Fish Helper Pro" wireless sonar sensor over bluetooth low-energy, reports depth and temperature<br />
<br />
=== ROS2 integration ===<br />
The most appropriate message for a simple range would be: https://docs.ros2.org/foxy/api/sensor_msgs/msg/Range.html<br />
<br />
There are other messages to perhaps report the raw echo return array.<br />
<br />
== Water physical analysis ==<br />
=== Turbidity / clarity ===<br />
See https://en.wikipedia.org/wiki/Turbidity<br />
<br />
Aliexpress sensor '''TS-300B''': https://nl.aliexpress.com/item/1005006732956937.html<br />
Has a range 0 ~ 1000 ± 30 NTU<br />
<br />
Order of magnitude for turbidity:<br />
* Drinking water upper limit: '''4 NTU''' (European turbidity standard for drinking water)<br />
* Ambient water: 10-150 NTU. The US state of Washington use a "background" value of '''50 NTU''' as reference.<br />
<br />
(see https://en.wikipedia.org/wiki/Turbidity#Standards_and_test_methods )<br />
<br />
So the Aliexpress sensor is suited only for "dirty" water.<br />
<br />
=== Water measurement probes ===<br />
* https://nl.aliexpress.com/item/1005003784454381.html BLE-9908 Inexpensie "Yieryi" PH/EC/Temp probe with bluetooth and app, about E25,- (Uses 3x LR44 coin cell batteries)<br />
* Several different models: https://nl.aliexpress.com/item/1005007810989801.html<br />
** EZ9901: TDS/pH/temp<br />
** EZ9902: EC/pH/temp<br />
** EZ9908: EC/TDS/pH/temp<br />
** EZ9909: TDS/EC/pH/salt/temp<br />
* The bluetooth versions are probably as above, with numbers like BLE9902 and BLE9908<br />
* Yiery BLE9902: https://shop.yieryimeters.com/products/yieryi-ble-9902-3-in-1-digital-ph-meter-with-bluetooth-ec-and-temperature-measurement-ideal-for-water-quality-testing-in-pools-fish-tanks-hydroponics-more<br />
* BLE-EC01 is a bluetooth EC meter, can find it here https://www.amazon.com/BLE-EC01-Smart4-TDS-Temp-Meter/dp/B0DPZZC7BV, not on AliExpress?<br />
<br />
Note:<br />
* Some probes indicate EC (electrical conductivity), other indicate TDS (total dissolved liquids). TDS is derived from EC (knowing the liquid type). EC is the more universal/fundamental property!<br />
* EC is typically expressed in uS/cm or mS/cm (micro or milli siemens per centimeter), say 500 uS/cm for outdoor water.<br />
* EC is temperature dependent, typically you need the value extrapolated to 25 degrees Celcius. Temperature-EC correlation rule of thumb: about 2% more conductive per K.<br />
* pH sensors are almost by definition fragile and last only a limited time, so probably don't bother trying to use one at all. The pH of outdoor water might not be that interesting to measure.<br />
* I expect the non-TuYa meters to use an easier to handle bluetooth protocol, avoiding the need for complicated encryption with a key that can only be fetched for a limited time using a tuya developer account.<br />
<br />
==== BT785 ====<br />
I bought this one: Tuya compatible BT785 EC meter: https://nl.aliexpress.com/i/1005007462079781.html inexpensive, focused on EC, runs on 4x LR44.<br />
Speaks the TuYa protocol (requires a secret key that you can fetch through the developer console).<br />
This is quite cumbersome: you have to register as a developer, fetch the key before time runs out and developer access is limited.<br />
<br />
Does NOT speak the universal serialport access protocol as described here:<br />
https://developer.tuya.com/en/docs/iot/tuya-cloud-universal-serial-port-access-protocol?id=K9hhi0xxtn9cb<br />
<br />
Code: https://github.com/bertrik/bt785<br />
<br />
==== Cheap non-bluetooth EC/TDS ====<br />
I got this one: https://nl.aliexpress.com/item/1005007267608479.html<br />
<br />
Tear-down on hackaday: https://hackaday.io/project/184764-ectds-temp-meter-teardown<br />
<br />
== Boat control ==<br />
Typically the wireless link looks like this:<br />
* 2.4 GHz working frequency<br />
* 500m range<br />
<br />
Interesting links:<br />
* Flytec-2011 remote control https://nl.aliexpress.com/item/1005002984723718.html<br />
* Replacement board for various boats with "18" in their type number: https://nl.aliexpress.com/item/1005006115484716.html<br />
* DIY Multi-protocol module: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module<br />
<br />
=== remote control ===<br />
Image of remote control RF chip:<br />
[...]<br />
<br />
Parts:<br />
* 12.000 MHz crystal/oscillator<br />
* 16-pin control chip: 20_CL6L071<br />
* 6-pin RF chip: 1110 / VKA3, could be an rx/tx switch, amplifier or filter circuit<br />
<br />
See also: https://www.open-tx.org/<br />
<br />
Next steps:<br />
* map out the connections between the mainboard and the rf board, expected: VCC, GND, spi ?<br />
<br />
== Use cases ==<br />
material:<br />
* https://www.youtube.com/watch?v=cMk0bGvIU1E<br />
* https://iplo.nl/thema/water/oppervlaktewater/kaderrichtlijn-water<br />
* kaartje: https://krw-nutrend.netlify.app/ -> 2 meetpunten op de reeuwijkse plassen, tijdresolutie is 1 jaar?<br />
<br />
Useful distinction, typically used in documents/guidelines:<br />
* chemical quality, what substances are present in the water?<br />
* biological / ecology quality, what kind of living organisms live in the water?<br />
<br />
=== Reeuwijkse plassen ===<br />
See<br />
* https://www.rijnland.net/wat-doet-rijnland/in-uw-buurt/reeuwijkse-plassen/ their stated goal: CLEAR WATER<br />
* https://www.rijnland.net/regels-op-een-rij/subsidies-en-andere-financi%C3%ABle-bijdragen/<br />
<br />
potential applications:<br />
* inspect water sides (oever) over time<br />
* underwater camera: detect invasive cray fish<br />
* sample water properties at high spatial resolution, high time resolution<br />
* early detection of indicators for cyanobacteria: temperature and nutrients<br />
<br />
=== Detect/find pollution source ===<br />
* ...<br />
<br />
== Implementation ==<br />
<br />
=== udev handling of serial ports ===<br />
Many peripheral devices are connected through serial.<br />
The plan is to have an udev config file with renaming rules, so each peripheral gets a stable name in /dev .<br />
The plan is also to create the udev config using some python: insert device X now -> write line to udev config.<br />
<br />
The udev config file is:<br />
/etc/udev/rules.d/99-usb-serial.rules<br />
<br />
<pre><br />
# LIDAR serial converter<br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="ttyLIDAR", MODE="0660", GROUP="dialout"<br />
# quectel GPS<br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", SYMLINK+="ttyGPS", MODE="0660", GROUP="dialout"<br />
# ublox GPS<br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="ttyGPS", MODE="0660", GROUP="dialout"<br />
</pre><br />
<br />
An USB-nano also appears to have a USB vendor/product id of 1a86/7523 ("USB2.0-Serial") ... same as the quectel GPS?<br />
<br />
Same for "AI thinker" USB-serial: vendor/product id of 1a86/7523 (product: "USB2.0-Serial")<br />
<br />
To (re)load the properties:<br />
<pre><br />
sudo udevadm control --reload-rules<br />
</pre><br />
<br />
=== reading temperature sensor ===<br />
The idea is to to use a DB18B20 temperature sensor, read it using an arduino nano board acting as a 1-wire adapter.<br />
Use openwire-fs as user-side openwire software http://owfs.org<br />
<br />
Preparation:<br />
* Add the regular user to the 'dialout' group, so it can access serial ports<br />
sudo adduser <name> dialout<br />
<br />
Setting up the hardware:<br />
* connect the DS18B20 to the connector board with the pull-ups<br />
* wire the connector board to the arduino nano, see ...<br />
* plug the arduino nano in the pi<br />
<br />
Setting up the software:<br />
* Install openwire fs<br />
sudo apt install owfs<br />
* Create the openwire fs mountpoint<br />
sudo mkdir /mnt/1wire<br />
* Configure owfs, edit /etc/owfs.conf<br />
server: device = /dev/ttyUSB0<br />
mountpoint = /mnt/1wire<br />
allow_other<br />
(comment out the line with the FAKE devices)<br />
* Configure systemd services<br />
sudo systemctl enable owserver owhttpd<br />
sudo systemctl disable owftpd<br />
* Start the systemd service<br />
sudo systemctl start owserver owhttpd<br />
* Check the logs<br />
sudo journalctl -xeu owserver -f<br />
* Open a browser to view the web interface<br />
http://localhost:2121 or<br />
http://raspberrypi.local:2121</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Karaburan&diff=35227Karaburan2026-05-11T12:11:30Z<p>Bertrik Sikken: </p>
<hr />
<div>{{Project<br />
|Name=Karaburan<br />
|Picture=karaburan.png<br />
|Omschrijving=Monitoring water quality<br />
|Status=In progress<br />
|Contact=bertrik<br />
}}<br />
<br />
== Next steps ==<br />
* <s>engage with PX4 community on getting a feel if this is useful to use and if so, how to get started</s><br />
* <s>figure out how to duplicate an MQTT stream</s> don't bother<br />
* write python scripts<br />
** <s>arduino turbidity</s> don't bother<br />
** <s>turbidity-to-mqtt</s> maybe make this ROS module<br />
** <s>HID-to-mqtt</s> maybe make this ROS module<br />
** position/velocity listener script: latitude, longitude, altitude, heading/bearing/track/whatever, velocity<br />
* hook things into systemd / udev<br />
* analoog in op de pi:<br />
** https://elektronicavoorjou.nl/product/adc-pi/<br />
** https://www.123materialen.com/products/zeer-nauwkeurige-ads1256-dac8552-ad-da-board-voor-raspberry-pi_1676153<br />
** FreeJoy project<br />
* UPS voor pi: https://elektronicavoorjou.nl/product/raspberry-pi-ups-hat/<br />
* 1-wire stuff:<br />
** 1-wire adapter emulation on an stm32: https://github.com/alitekin2fx/stm32_ds2480_emu<br />
** owfs.org for easy interfacing with multiple 1-wire devices in a hierarchical way on linux<br />
* Figure out the udev/hotplug mess, we probably need this because many of our peripherals use a serial port:<br />
** in how many places can we store the udev renaming logic (config files)<br />
** can we automate this, make it user friendlier, e.g. some kind of "insert device X now" script<br />
<br />
Check:<br />
* https://www.rtvnoord.nl/natuur/1215705/vuilrobot-maakt-jachthaven-winschoten-schoon-beter-dan-met-een-schepnet<br />
<br />
=== USB HID as analog input ===<br />
An stm32 based bluepill board can be flashed with firmware to allow its analog inputs to be exposed as USB HID sliders.<br />
<br />
Flashing the bluepill with openocd to the freejoy firmware:<br />
* install openocd<br />
sudo apt install openocd<br />
* connect an stlinkv2 to an stm32 bluepill, connect the stlinkv2 to USB<br />
* flash the freejoy firmware as follows:<br />
** download the firmware from https://github.com/FreeJoy-Team/FreeJoy<br />
** create a symlink to the hex file called firmware.hex<br />
** flash the firmware from the command line<br />
openocd -s /usr/share/openocd/scripts -f interface/stlink.cfg -f target/stm32f1x.cfg -c init -c "program firmware.hex verify reset exit"<br />
* watch the kernel logs<br />
sudo dmesg -w<br />
* connect the stm32 using a USB cable<br />
* download the freejoy configurator from https://github.com/FreeJoy-Team/FreeJoyConfiguratorQt<br />
* start the configurator and load the karaburan.cfg setting<br />
* Write config to device -> it should reboot now and come up with the new settings<br />
<br />
Verify that it works:<br />
* install the evtest package<br />
* run<br />
evtest /dev/input/by-id/usb-FreeJoy_FreeJoy_v1.7.1-event-if00<br />
<br />
See also https://github.com/vostrenkov/EazyJoy<br />
<br />
=== influxdb ===<br />
See https://hub.docker.com/_/influxdb<br />
<br />
See https://github.com/bertrik/karaburan/tree/master/influxdb<br />
<br />
=== ROS ===<br />
Investigation:<br />
* Use ROS 2, not the old ROS 1<br />
* Cannot work comfortably with debian, works best with ubuntu<br />
* Using gpsd:<br />
** install ros-jazzy-desktop<br />
** ros2 launch gpsd_client gpsd_client-launch.py<br />
<br />
== Introduction ==<br />
Topics:<br />
* air quality sensors<br />
** ammonia<br />
** NOx<br />
* water chemical analysis<br />
** nitrates<br />
** ammonia<br />
** dissolved oxygen<br />
** sulfide/sulfate<br />
** phosphates?<br />
** salinity (chlorides?)<br />
* water physical analysis<br />
** temperature<br />
** clarity/turbidity -> investigate standard ways of measuring/expressing this<br />
** conductivity/total dissolved solids<br />
** water properties by light reflection, hyperspectral/polarity<br />
** depth?<br />
* boat control<br />
** trajectory -> steering<br />
** idea: interface with the remote control, not with the boat<br />
** idea: find a boat with easily hackable remote control protocol<br />
** idea: can we get sensor data over this link too, e.g. GPS?<br />
* camera control<br />
* post-processing<br />
** data presentation<br />
*** video/photo stitching<br />
*** time lapse view<br />
*** map view of properties<br />
* use cases<br />
** verify with domain experts, how to engage?<br />
** slootview, under/above water<br />
** minimum viable prototype<br />
** high-res measurement by location, by time<br />
* materials<br />
** boat selection<br />
** processing platform selection<br />
** communication platform selection<br />
<br />
== Investigate RTK GPS ==<br />
Goal: figure out if it is practically possible to achieve cm resolution with a 200-euro GPS and a free correction service: YES<br />
<br />
* https://www.nsgi.nl/referentiepunten-en-gnss-data/gnss-data/real-time-streams public correction data service<br />
* https://www.ardusimple.nl/rtk-in-5-minutes/<br />
* RTK in action https://www.youtube.com/watch?v=Oc1LBFDj2MA<br />
* Use with Linux / gpsd: https://stackoverflow.com/questions/77314115/drotek-gpsd-and-ntrip-correction-data-for-precise-positioning ?<br />
* Chipsets<br />
** Quectel LC29H (default: 115200 bps)<br />
*** review: see https://rtklibexplorer.wordpress.com/2024/04/28/dual-frequency-rtk-for-less-than-60-with-the-quectel-lc29hea/<br />
*** configuration: https://rtklibexplorer.wordpress.com/2024/05/06/configuring-the-quectel-lc29hea-receiver-for-real-time-rtk-solutions/<br />
** uBLOX ZED-F9P<br />
* Boards<br />
** UM980 / UM982<br />
<br />
Edit /etc/default/gpsd, set GPSD_OPTIONS:<br />
GPSD_OPTIONS="-Gn ntrip://user:pass@ntrip.kadaster.nl:2101/CBW100NLD0"<br />
Option -G exposes the control socket on all network interfaces, option -n keeps the GPS active if there is no one currently connected.<br />
<br />
Plotting live location on a map:<br />
* Configure gpsd to expose its socket to the outside world: last section of https://gpsd.gitlab.io/gpsd/troubleshooting.html<br />
* In QGIS, press ctrl+0 to show the GPS information tab, enter the name of the remote gpsd (port 2947)<br />
<br />
Station at Stolwijk (close to Gouda): https://gnss1.tudelft.nl/dpga/station/Stolwijk.html#STWK ?<br />
<br />
Starting from the command line:<br />
* stop gpsd.socket<br />
sudo systemctl stop gpsd.socket<br />
* run from command line<br />
sudo /usr/sbin/gpsd -Gn -D 1 -N /dev/ttyUSB0 .... (not sure yet)<br />
<br />
=== Validation ===<br />
How to show that RTK GPS is actually accurate?<br />
<br />
* Relative positioning: with an "fix RTK" solution, place the antenna at 4 points 25cm apart, each point for 20 seconds or so -> you see 4 distinct clusters of points<br />
* Positioning over short time: put it in a fixed location, make sure that it has "fix RTK" solution, take 100 measurements or so -> determine the radius of the circle that contains 90% of the points<br />
* Positioning over longer time: do this for (say) an hour<br />
* Absolute positioning: look up a national reference point, for example "RD-punt 389346", located on the Sluisdijk between Gouda and Moordrecht. Technical data: https://www.nsgi.nl/iv-api/rdinfo/rdpoint/389346<br />
** see https://www.nsgi.nl/referentiepunten-en-gnss-data/informatie-referentiepunten/rdinfo and enter 389346<br />
** latitude: 51° 59' 49,64048" , longitude: 4° 41' 19,90765", or 51.99712236/4.68886324<br />
<br />
==== Comparison with reference coordinate ====<br />
On october 4th 2024, we took the RTK GPS to a kernnet reference point at 51.99712236/4.68886324, results below:<br />
<br />
From https://www.nsgi.nl/iv-api/rdinfo/rdpoint/389346:<br />
* Year 2021: "51 59 49,64004", "4 41 19,90584", 48.039. In decimal degrees that is <br />
<br />
Differences between the reference point and the measurements are calculated to easting ('X') and northing ('Y'), unit meter. To calculate distance in meters, we use a linear approximation:<br />
* For dy: 40075km/360 = 111,319 m/deg<br />
* For dx: dy * cos(latitude) = 68,549 m/deg<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|+ Measurements + deviations<br />
|-<br />
! Name !! Latitude !! Longitude !! dx (m) !! dy (m) !! absolute (m) !! Remark<br />
|-<br />
| Reference 2012 || 51.99712236 || 4.68886324 || - || - || 0 || by definition<br />
|-<br />
| Reference 2021 || 51.99712223 || 4.68886273 || - || - || 0 || by definition<br />
|-<br />
| Screenshot 1 || 51.99712217 || 4.68886567 || 0.167 || -0.021 || 0.168 || - <br />
|-<br />
| Screenshot 2 || 51.99712200 || 4.68886533 || 0.143 || -0.040 || 0.149 || -<br />
|-<br />
| Meting 1 || 51.9971220 || 4.6888663 || 0.210 || -0.040 || 0.214 || -<br />
|-<br />
| Meting 2 || 51.9971222 || 4.6888660 || 0.189 || -0.018 || 0.190 || -<br />
|-<br />
| Average || - || - || 0.177 || -0.030 || 0.180 || -<br />
|}<br />
<br />
According to [https://www.unavco.org/software/geodetic-utilities/plate-motion-calculator/plate-motion-calculator.html this page], the rate of movement is about<br />
15.75mm/year to the north and 17.45 mm/year to the east (ITRF2020 model).<br />
Over 12 years, that amounts to 0.189m north and 0.209m east.<br />
<br />
== Air quality sensors ==<br />
<br />
=== Nitrogen compounds in air ===<br />
According to https://www.rivm.nl/stikstof/monitoren-advies-onderzoek/overzicht-stikstofmetingen/metingen-stikstof-in-de-lucht average (typical?) values of<br />
* Ammonia (NH3): 6.7 ug/m3 (9.6 ppb)<br />
* NOx: 27.3 ug/m3<br />
* NO2: 18.6 ug/m3 (9.9 ppb)<br />
<br />
(ppb-conversion using https://www.breeze-technologies.de/blog/air-pollution-how-to-convert-between-mgm3-%C2%B5gm3-ppm-ppb/ )<br />
<br />
RIVM report on inexpensive nitrogen-in-air sensors: https://www.samenmeten.nl/sensoren-voor-no2<br />
Conclusion: most sensors are not sensitive enough to be used in typical outdoor conditions, with perhaps one exception: alphasense NO2-B43F<br />
<br />
== Sonar sensors ==<br />
Investigate this because it allows us to measure depth.<br />
<br />
AliExpress has several types of affordable sonar sensors, focused at detecting fish, but also able to measure depth.<br />
<br />
I ordered this one: https://nl.aliexpress.com/item/1005006388343879.html<br />
* 125 kHz main frequency, range up to 200 ft deep (about 60m)<br />
* bluetooth low-power interface (basically serial-over-BLE)<br />
* built-in battery, powers on automatically when submerged<br />
* reports 120-element array with raw sonar return intensity-vs-depth<br />
* measures water temperature<br />
* about 45 euro<br />
<br />
Fish helper pro application for android https://apkpure.com/fish-helper-pro/com.fishfinderpro.xdx<br />
<br />
=== Debug tool ===<br />
I wrote a python script to connect to it from a linux computer: https://github.com/bertrik/wireless-sonar-sensor<br />
<br />
It's connects to a "Fish Helper Pro" wireless sonar sensor over bluetooth low-energy, reports depth and temperature<br />
<br />
=== ROS2 integration ===<br />
The most appropriate message for a simple range would be: https://docs.ros2.org/foxy/api/sensor_msgs/msg/Range.html<br />
<br />
There are other messages to perhaps report the raw echo return array.<br />
<br />
== Water physical analysis ==<br />
=== Turbidity / clarity ===<br />
See https://en.wikipedia.org/wiki/Turbidity<br />
<br />
Aliexpress sensor '''TS-300B''': https://nl.aliexpress.com/item/1005006732956937.html<br />
Has a range 0 ~ 1000 ± 30 NTU<br />
<br />
Order of magnitude for turbidity:<br />
* Drinking water upper limit: '''4 NTU''' (European turbidity standard for drinking water)<br />
* Ambient water: 10-150 NTU. The US state of Washington use a "background" value of '''50 NTU''' as reference.<br />
<br />
(see https://en.wikipedia.org/wiki/Turbidity#Standards_and_test_methods )<br />
<br />
So the Aliexpress sensor is suited only for "dirty" water.<br />
<br />
=== Water measurement probes ===<br />
* https://nl.aliexpress.com/item/1005003784454381.html BLE-9908 Inexpensie "Yieryi" PH/EC/Temp probe with bluetooth and app, about E25,- (Uses 3x LR44 coin cell batteries)<br />
* Several different models: https://nl.aliexpress.com/item/1005007810989801.html<br />
** EZ9901: TDS/pH/temp<br />
** EZ9902: EC/pH/temp<br />
** EZ9908: EC/TDS/pH/temp<br />
** EZ9909: TDS/EC/pH/salt/temp<br />
* The bluetooth versions are probably as above, with numbers like BLE9902 and BLE9908<br />
* Yiery BLE9902: https://shop.yieryimeters.com/products/yieryi-ble-9902-3-in-1-digital-ph-meter-with-bluetooth-ec-and-temperature-measurement-ideal-for-water-quality-testing-in-pools-fish-tanks-hydroponics-more<br />
* BLE-EC01 is a bluetooth EC meter, can find it here https://www.amazon.com/BLE-EC01-Smart4-TDS-Temp-Meter/dp/B0DPZZC7BV, not on AliExpress?<br />
<br />
Note:<br />
* Some probes indicate EC (electrical conductivity), other indicate TDS (total dissolved liquids). TDS is derived from EC (knowing the liquid type). EC is the more universal/fundamental property!<br />
* EC is typically expressed in uS/cm or mS/cm (micro or milli siemens per centimeter), say 500 uS/cm for outdoor water.<br />
* EC is temperature dependent, typically you need the value extrapolated to 25 degrees Celcius. Temperature-EC correlation rule of thumb: about 2% more conductive per K.<br />
* pH sensors are almost by definition fragile and last only a limited time, so probably don't bother trying to use one at all. The pH of outdoor water might not be that interesting to measure.<br />
* I expect the non-TuYa meters to use an easier to handle bluetooth protocol, avoiding the need for complicated encryption with a key that can only be fetched for a limited time using a tuya developer account.<br />
<br />
==== BT785 ====<br />
I bought this one: Tuya compatible BT785 EC meter: https://nl.aliexpress.com/i/1005007462079781.html inexpensive, focused on EC, runs on 4x LR44.<br />
Speaks the TuYa protocol (requires a secret key that you can fetch through the developer console).<br />
This is quite cumbersome: you have to register as a developer, fetch the key before time runs out and developer access is limited.<br />
<br />
Does NOT speak the universal serialport access protocol as described here:<br />
https://developer.tuya.com/en/docs/iot/tuya-cloud-universal-serial-port-access-protocol?id=K9hhi0xxtn9cb<br />
<br />
==== Cheap non-bluetooth EC/TDS ====<br />
I got this one: https://nl.aliexpress.com/item/1005007267608479.html<br />
<br />
Tear-down on hackaday: https://hackaday.io/project/184764-ectds-temp-meter-teardown<br />
<br />
== Boat control ==<br />
Typically the wireless link looks like this:<br />
* 2.4 GHz working frequency<br />
* 500m range<br />
<br />
Interesting links:<br />
* Flytec-2011 remote control https://nl.aliexpress.com/item/1005002984723718.html<br />
* Replacement board for various boats with "18" in their type number: https://nl.aliexpress.com/item/1005006115484716.html<br />
* DIY Multi-protocol module: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module<br />
<br />
=== remote control ===<br />
Image of remote control RF chip:<br />
[...]<br />
<br />
Parts:<br />
* 12.000 MHz crystal/oscillator<br />
* 16-pin control chip: 20_CL6L071<br />
* 6-pin RF chip: 1110 / VKA3, could be an rx/tx switch, amplifier or filter circuit<br />
<br />
See also: https://www.open-tx.org/<br />
<br />
Next steps:<br />
* map out the connections between the mainboard and the rf board, expected: VCC, GND, spi ?<br />
<br />
== Use cases ==<br />
material:<br />
* https://www.youtube.com/watch?v=cMk0bGvIU1E<br />
* https://iplo.nl/thema/water/oppervlaktewater/kaderrichtlijn-water<br />
* kaartje: https://krw-nutrend.netlify.app/ -> 2 meetpunten op de reeuwijkse plassen, tijdresolutie is 1 jaar?<br />
<br />
Useful distinction, typically used in documents/guidelines:<br />
* chemical quality, what substances are present in the water?<br />
* biological / ecology quality, what kind of living organisms live in the water?<br />
<br />
=== Reeuwijkse plassen ===<br />
See<br />
* https://www.rijnland.net/wat-doet-rijnland/in-uw-buurt/reeuwijkse-plassen/ their stated goal: CLEAR WATER<br />
* https://www.rijnland.net/regels-op-een-rij/subsidies-en-andere-financi%C3%ABle-bijdragen/<br />
<br />
potential applications:<br />
* inspect water sides (oever) over time<br />
* underwater camera: detect invasive cray fish<br />
* sample water properties at high spatial resolution, high time resolution<br />
* early detection of indicators for cyanobacteria: temperature and nutrients<br />
<br />
=== Detect/find pollution source ===<br />
* ...<br />
<br />
== Implementation ==<br />
<br />
=== udev handling of serial ports ===<br />
Many peripheral devices are connected through serial.<br />
The plan is to have an udev config file with renaming rules, so each peripheral gets a stable name in /dev .<br />
The plan is also to create the udev config using some python: insert device X now -> write line to udev config.<br />
<br />
The udev config file is:<br />
/etc/udev/rules.d/99-usb-serial.rules<br />
<br />
<pre><br />
# LIDAR serial converter<br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="ttyLIDAR", MODE="0660", GROUP="dialout"<br />
# quectel GPS<br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", SYMLINK+="ttyGPS", MODE="0660", GROUP="dialout"<br />
# ublox GPS<br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="ttyGPS", MODE="0660", GROUP="dialout"<br />
</pre><br />
<br />
An USB-nano also appears to have a USB vendor/product id of 1a86/7523 ("USB2.0-Serial") ... same as the quectel GPS?<br />
<br />
Same for "AI thinker" USB-serial: vendor/product id of 1a86/7523 (product: "USB2.0-Serial")<br />
<br />
To (re)load the properties:<br />
<pre><br />
sudo udevadm control --reload-rules<br />
</pre><br />
<br />
=== reading temperature sensor ===<br />
The idea is to to use a DB18B20 temperature sensor, read it using an arduino nano board acting as a 1-wire adapter.<br />
Use openwire-fs as user-side openwire software http://owfs.org<br />
<br />
Preparation:<br />
* Add the regular user to the 'dialout' group, so it can access serial ports<br />
sudo adduser <name> dialout<br />
<br />
Setting up the hardware:<br />
* connect the DS18B20 to the connector board with the pull-ups<br />
* wire the connector board to the arduino nano, see ...<br />
* plug the arduino nano in the pi<br />
<br />
Setting up the software:<br />
* Install openwire fs<br />
sudo apt install owfs<br />
* Create the openwire fs mountpoint<br />
sudo mkdir /mnt/1wire<br />
* Configure owfs, edit /etc/owfs.conf<br />
server: device = /dev/ttyUSB0<br />
mountpoint = /mnt/1wire<br />
allow_other<br />
(comment out the line with the FAKE devices)<br />
* Configure systemd services<br />
sudo systemctl enable owserver owhttpd<br />
sudo systemctl disable owftpd<br />
* Start the systemd service<br />
sudo systemctl start owserver owhttpd<br />
* Check the logs<br />
sudo journalctl -xeu owserver -f<br />
* Open a browser to view the web interface<br />
http://localhost:2121 or<br />
http://raspberrypi.local:2121</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=User:Bertrik_Sikken&diff=35224User:Bertrik Sikken2026-05-07T12:01:44Z<p>Bertrik Sikken: /* Project ideas */</p>
<hr />
<div>{{Smoel<br />
|Name=Bertrik Sikken<br />
|Nick=bertrik<br />
|Tagline=heb ik niet<br />
}}<br />
<br />
You can reach me at [mailto:bertrik@sikken.nl bertrik@sikken.nl] or [mailto:bertrik@gmail.com bertrik@gmail.com].<br />
<br />
Studied Electrical Engineering at Twente University.<br />
<br />
<br />
Main interests:<br />
* reverse-engineering things (USB stuff, mp3 players), worked on http://rockbox.org (sansa clip players)<br />
* studying bats and making electronics for recording/listening to bat sounds<br />
* radio stuff, in particular software-defined radio, LoRa networks<br />
* citizen science and open data (particulate matter measurement, noise, water quality)<br />
* energy-related stuff, visualisation<br />
<br />
Projects I work(ed) on ([https://revspace.nl/index.php?title=User:Bertrik_Sikken&action=purge refresh]):<br />
{{#ask:[[Category:Project]][[Project Contact::bertrik]]<br />
|?Project Status<br />
|headers=show<br />
|link=all<br />
|order=ASC,ASC<br />
|sort=Project Status,Project Name<br />
}}<br />
<br />
<br />
== Project ideas ==<br />
[[File:always10oclock.jpg|right]]<br />
[[File:idea.jpg|right]]<br />
<br />
This is a list of ideas I'm thinking about, but have not fully developed into an actual project yet.<br />
<br />
https://pine64.com/product/128mb-ox64-sbc-available-on-december-2-2022/<br />
=== LilyGo T-Radar ===<br />
https://developer.acconeer.com/home/a121-docs-software/a121-esp32<br />
<br />
=== Action 32x32 display ===<br />
Action sells [https://www.action.com/nl-nl/p/3217439/led-pixelbord/ this ACT1026 display]. You control it over BLE.<br />
<br />
* https://github.com/Pupariaa/Bk-Light-AppBypass works to control it<br />
* software for a similar led display: https://github.com/derkalle4/python3-idotmatrix-client<br />
<br />
=== investigate thread/matter ===<br />
Matter/thread is the new IKEA standard for home automation thins apparently. <br />
Thread is the wireless protocol, matter is a home automation protocol running on top of thread.<br />
<br />
I have a couple of nrf52840, these are good in doing thread.<br />
<br />
Next steps:<br />
* check out openthread<br />
<pre><br />
git clone https://github.com/openthread/openthread.git<br />
cd openthread<br />
git submodule update --init --recursive<br />
</pre><br />
* Prepare development environment:<br />
scripts/bootstrap<br />
* Build it:<br />
./script/build nrf52840 UART_trans -DOT_LOG_LEVEL=OT_LOG_LEVEL_INFO<br />
<br />
Thread on ESP32:<br />
* on ESP32 C6 https://gist.github.com/gtxaspec/d26198daadfb0a8b0a0edeae2d3fd58f<br />
* https://github.com/espressif/esp-thread-br<br />
* https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_rcp<br />
<br />
=== action lsc stekker ===<br />
https://keetsupport.nl/2024/03/20/how-to-flash-lsc-power-plug-with-esphome/<br />
<br />
https://community.home-assistant.io/t/detailed-guide-on-how-to-flash-the-new-tuya-beken-chips-with-openbk7231t/437276<br />
<br />
=== sipeed maix dock ===<br />
Bought this a couple of years ago. Get familiar with this board.<br />
Can I run a chess program on this, for example?<br />
<br />
* https://wiki.sipeed.com/soft/maixpy/en/develop_kit_board/maix_dock.html<br />
<br />
=== rfid keyfob ===<br />
* aliexpress page: https://nl.aliexpress.com/item/1005009569496736.html<br />
* firmware github: <br />
** https://github.com/RfidResearchGroup/ChameleonUltra<br />
** https://github.com/GameTec-live/ChameleonUltraGUI<br />
<br />
=== advanced lidars for bat detection ===<br />
livox:<br />
* github page https://github.com/Livox-SDK/Livox-SDK/tree/master<br />
* web page: https://www.livoxtech.com/<br />
<br />
=== cubecell meshtastic motion detector ===<br />
I have a cubecell AB01 board.<br />
This board is focused on low power, has a connection to attach a solar panel and has a lora radio.<br />
Relatively small amount of RAM, barely enough to run a LoRaWAN stack but probably plenty to run meshtastic<br />
<br />
The plan is to build a simple motion detector from this (using a PIR).<br />
The PIR can wake up the board from low-power, or a timer can wake it periodically.<br />
<br />
See also: https://github.com/HelTecAutomation/CubeCell-Arduino/tree/master/libraries/Basics/examples/LowPower<br />
<br />
=== configure multitech outdoor gateway ===<br />
https://www.multitech.net/developer/products/multiconnect-conduit-platform/basestation/<br />
<br />
https://multitech.com/product/multitech-conduit-mtcdt-246a-868-eu-gb/<br />
<br />
emergency procedure:<br />
https://www.multitech.net/developer/software/mlinux/using-mlinux/flashing-mlinux-firmware-for-conduit/<br />
<br />
=== esp32 wtf ===<br />
* https://forum.arduino.cc/t/ttgo-lilygo-lora-esp32-26mhz-problem/1353750<br />
* "26 MHz crystal has been deprecated" https://github.com/espressif/arduino-esp32/issues/10117<br />
<br />
=== kakofonie counter ===<br />
Sample room audio, use neural network to distinguish voices to estimate number of people talking in the past 30 seconds or so.<br />
Show this number on some kind of display, publish it to MQTT, make a nice graph of it.<br />
<br />
Stuff to figure out:<br />
* this is called 'speaker diarization'<br />
* can it run on an ESP32?<br />
* make a prototype<br />
<br />
=== hypno toad ===<br />
Put these LEDS https://nl.aliexpress.com/item/1005007583528891.html into https://www.action.com/nl-nl/p/2560347/solar-tuinbeeldje/<br />
<br />
Turns out that the default circuit is really basic and output a rough step-up waveform to the LED.<br />
The self-fading LEDs don't work very well with that.<br />
<br />
Also, putting some IPA on hotglue makes it release really easy.<br />
<br />
=== wasbeer / kat classifier ===<br />
ESP32 with resnet50 neural net to distinguish house cats from other animals, see also:<br />
* https://ieeexplore.ieee.org/document/10556848/<br />
<br />
=== Nespresso brew counter ===<br />
Several hacker spaces have one of these Nespresso cup coffee makers, but there's no obvious easy way to monitor usage (monitor ALL the things!).<br />
Inspired by https://hackaday.com/2021/04/25/arduino-mkr-makes-nespresso-monitoring-easy/ this idea is making an even simpler nespresso monitor,<br />
using an inexpensive WiFi enabled ESP8266 with an ubiquitous I2S microphone such as the INMP441. <br />
<br />
Use this sound monitoring project:<br />
https://github.com/aleiei/ESP8266-BUG-I2S-MIC<br />
and turn it into a WiFi connected brew counter.<br />
<br />
Software for getting microphone data from an ESP8266/I2S mic into Linux https://github.com/bertrik/EspMicServer<br />
Nespresso sound is typically 50 Hz with overtones.<br />
In a recording with the ESP8266, it appears that oddly the 17th harmonic (around 850 Hz) is quite strong.<br />
<br />
The plan in the short term is this:<br />
* apply a gentle IIR filter to subtract any DC bias from the microphone signal<br />
* calculate autocovariance at offsets 0 and 20 ms (inverse of 50 Hz), representing the total energy and the energy at 50 Hz respectively<br />
* compare amplitudes to decide about presence of 50 Hz signal, e.g. calculate ratio in dB<br />
* use this to count the length of time that a 50 Hz signal is heard (increments of 100 ms or so)<br />
* decide about none / espresso / lungo based on time<br />
<br />
Might even integrate with esphome / home assistant later.<br />
<br />
=== Remote bat box monitor ===<br />
Idea:<br />
* goal: check if remote bat boxes are occupied and identify the species<br />
* challenges:<br />
** connectivity: need to transport images/videos (no LoRaWAN), possibly out of range of mobile data networks<br />
** autonomy: cannot reach the bat box once installed<br />
** power: no fixed power connection, so probably needs a battery + solar panel<br />
* design<br />
** wake up every hour, take a picture, go to sleep, upload photos/videos once per day<br />
** run from batteries, recharge by solar, rules of thumb<br />
*** batteries should last for about 10 days<br />
*** battery should be able to charge in 1 day<br />
*** consider only 10% of peak solar power<br />
** KPN "4G-op-zee" somewhat confusing article: https://www.kpn.com/zakelijk/mobiel/roaming/noordzee<br />
* hardware<br />
** main processor: raspberry pi zero<br />
*** raspberry pi power consumption overview: https://www.pidramble.com/wiki/benchmarks/power-consumption<br />
** this hat to wake up the main CPU: https://www.waveshare.com/wiki/Power_Management_HAT_(B) sold at https://www.kiwi-electronics.com/en/power-management-hat-for-raspberry-pi-with-rtc-and-rp2040-mcu-11373<br />
<br />
=== KNMI API ===<br />
Get familiar with https://developer.dataplatform.knmi.nl/open-data-api<br />
<br />
=== Grid frequency measurer with web page ===<br />
See https://github.com/bertrik/GridFrequency<br />
SSE source is gridfrequency.local/events<br />
<br />
=== WeAct CH55x board ===<br />
Cheap little boards, using a similar chip as used in USB-serial converters.<br />
<br />
The hardware<br />
https://github.com/WeActStudio/WeActStudio.CH552CoreBoard<br />
<br />
Flashing it:<br />
https://hackaday.io/page/137447-flashing-the-ch552-dev-board-from-the-command-line<br />
<br />
See also:<br />
* https://hackaday.io/project/198238-more-weact-ch5xx<br />
* https://community.platformio.org/t/manually-adding-support-for-ch55x-controller-by-adding-existing-ardunio-core/41138<br />
<br />
=== Zigbee device with esp32 ===<br />
See https://github.com/P-R-O-C-H-Y/arduino-esp32/blob/8169a434c3e46e1bb7711ebcc04f27267db2093c/libraries/ESP32/examples/Zigbee/Zigbee_Light_Bulb/Zigbee_Light_Bulb.ino<br />
<br />
See https://github.com/espressif/arduino-esp32/tree/master/libraries/ESP32/examples/Zigbee<br />
<br />
Espressif32 arduino platform git: https://github.com/platformio/platform-espressif32<br />
<br />
=== Cameratoezicht in Gouda ===<br />
Gemeente Gouda publiceert een lijst van camera's in Gouda, zie<br />
https://gis.gouda.nl/nl/app/Basisviewer_open#!eAGT8uRiNBRy4ZIRYFKSyKkssjJwdzFxNDMz8TKKsLC0cnb0dQ1y5FIByirgkg3xd43ydPYIAQBXGBFm<br />
<br />
Aanmelden (semi-automatisch) bij bijvoorbeeld [https://mapcomplete.org/surveillance Surveillance-under-surveillance] ?<br />
<br />
=== SolarEdge ===<br />
Interact with the solar edge api for PV installations.<br />
<br />
https://developers.solaredge.com/<br />
<br />
See https://github.com/bertrik/solaredge-api<br />
<br />
=== Stookalert ===<br />
Idee: gekleurd lampje dat aangeeft of er op dit moment een stookalert actief is<br />
<br />
Implementatie:<br />
* kijk m.b.v. WiFi locatieservice in welke provincie je je bevindt<br />
* haal JSON op bij https://www.lml.rivm.nl/stookalert/stookalert.json<br />
* toon de bijbehorende kleur op het lampje<br />
<br />
Resources:<br />
* Officiele pagina: https://www.atlasleefomgeving.nl/stookwijzer<br />
* Achterliggende JSON met toestand per provincie: https://www.lml.rivm.nl/stookalert/stookalert.json<br />
* Er moet ook nog ergens een API zijn die fijnmaziger aangeeft wat de toestand is ...<br />
<br />
=== Display of current electricity usage ===<br />
I have a [https://www.zuidwijk.com/product/slimmelezer-plus/ slimme lezer] connected to the P1 port of my smart electricity meter.<br />
The default firmware exposes meter readings using an event stream (SSE) at http://slimmelezer.local/events<br />
<br />
So for example, you can read this with curl:<br />
curl http://slimmelezer.local/events<br />
With result:<br />
event: state<br />
data: {"id":"sensor-power_consumed_phase_1","value":0.046,"state":"0.046 kW"}<br />
<br />
Specification of SSE: https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream<br />
<br />
What I would like to do is to read these events and control a simple display to display the current usage number.<br />
<br />
=== Participating in ultrasonic sound project ===<br />
https://bat-migration-europe.netlify.app/project/<br />
<br />
Use an audiomoth for this.<br />
<br />
=== ESP32 C3 ===<br />
* [https://www.espressif.com/en/products/socs/esp32-c3 processor page]<br />
* [https://wiki.luatos.com/chips/esp32c3/index.html luatos basic esp32 c3 board]<br />
<br />
=== Flexible LED ticker ===<br />
Ordered a flexible 32x8 RGB LED display:<br />
https://nl.aliexpress.com/item/4001296811800.html<br />
<br />
Matching diffuser to be 3D printed:<br />
https://www.thingiverse.com/thing:1903744<br />
<br />
=== Washing machine API ===<br />
https://tratt.net/laurie/blog/2023/displaying_my_washing_machines_remaining_time_with_curl_jq_pizauth.html<br />
<br />
=== TinyML ===<br />
Investigate TinyML, see https://www.tinyml.org/<br />
Apparently can run on a RP2040 (raspi pi pico).<br />
<br />
https://www.hackster.io/mjrobot/esp32-cam-tinyml-image-classification-fruits-vs-veggies-4ab970<br />
<br />
=== Bat box busy signal ===<br />
My brother built little pyramid 'blinkies': solar cell + Lithium-supercapacitor + harvesting circuit + LED encased in clear expoxy.<br />
<br />
Can we add a low-power PIR sensor to this, and make a blinky that blinks if movement was detected by the PIR in the past hour?<br />
<br />
=== Super tiny RFID ===<br />
See https://www.sparkfun.com/products/16464 an almost sand grain size RFID chip, 1.25mmx1.25mmx0.55mm<br />
<br />
The accompanying reader "M6E Nano" is still quite expensive at $235.95 : https://www.sparkfun.com/products/14066<br />
<br />
Uses the MuRata LXMSJZNCMF-198:<br />
"This product can be used as an ultra small tag and this can be<br />
fit on any metal objects, non-metal objects, as well as<br />
embedding into any objects by glue or adhesive and so on."<br />
<br />
See also: ISO18000-63 and EPC global Gen2(v2)<br />
<br />
Specification:<br />
* https://www.gs1.org/standards/rfid/uhf-air-interface-protocol<br />
<br />
=== TheThingsNetwork-Sondehub bridge ===<br />
Uploads balloon telemetry to sondehub.<br />
<br />
See https://github.com/bertrik/ttnhabbridge/issues/6<br />
<br />
=== Actually smart boiler ===<br />
The boiler for hot water is about half of my electricity bill.<br />
The idea is to use/build a smart switch that switches it on at time when electricity prices are lowest.<br />
<br />
Currently have a "Slimme boiler module" from Eneco, which is *not* actually smart,<br />
since it allows me no control whatsoever when it switches on (besides cutting the power in the meterkast).<br />
For example, it will switch on mid-day when my price is high and eneco's price is low, perhaps good for Eneco, not for me. <br />
Apparently, they even received a [https://nieuws.eneco.nl/slim-apparaatje-bij-boiler-vangt-pieken-wind--en-zonnestroom-op/ subsidy] for this.<br />
<br />
A boiler is a pretty big load, about 3 kW, but it is not inductive.<br />
<br />
Alternatives:<br />
* https://www.shelly.cloud/en-nl/products/product-overview/shelly-plus-1-pm-2-pack/shelly-plus-1-pm<br />
* https://www.solyxenergy.nl/solar-iboost/ to store excess solar energy in hot water, might also be useful for just controlling a boiler to use cheaper rates<br />
* tuya smartplug, like https://www.wifilampkoning.nl/merken-slimme-verlichting/tuya/tuya-enkele-smartplug-met-energiemeting ?<br />
* tuya 20A smart plug: https://nl.aliexpress.com/item/1005003347568206.html<br />
<br />
=== Receiving gas meters ===<br />
Apparently gas meters send gas consumption data to the slimme meter using a wireless link in the 868 MHz band.<br />
Probably just FSK at 38.4, as mentioned here: https://a35.veron.nl/nieuwe-elektra-en-gasmeters/<br />
<br />
Interesting leads:<br />
* https://github.com/stef/smeter<br />
* https://www.rtl-sdr.com/reading-household-wireless-utility-meters-with-an-rtl-sdr-and-plotting-the-data-in-home-automation-software/<br />
* https://github.com/bemasher/rtlamr<br />
<br />
=== Multi-network wifi manager ===<br />
Figure out or create software so that ESP8266/ESP32 wifi manager can use multiple networks to connect (not just one),<br />
so it allowing storing credentials for more than one network. For example, the network at home, the hacker space, at work.<br />
Instead of reconfiguring the wifi manager for each network, you just *add* your credentials (and the existing credentials<br />
are not replaced).<br />
<br />
See https://github.com/folkertvanheusden/M.A.X.X<br />
<br />
Interesting candidates:<br />
* https://registry.platformio.org/libraries/martinverges/ESP32%20Wifi%20Manager wifi manager for ESP32, has a REST API for managing wifi network, but is incomplete in the sense that you need to write your own code (e.g. javascript) to actually *use* its API<br />
* https://github.com/arduino-libraries/Arduino_MultiWiFi is the arduino multi wifi library, to allow connecting to multiple different WiFi networks, but it is not a wifi manager, that starts a captive portal, etc<br />
<br />
=== Automated bat counting ===<br />
Can we automatically count the number of bats from the image of a webcam mounted in a bat colony?<br />
Perhaps using some kind of AI or machine learning algorithm?<br />
<br />
The image in question:<br />
https://stofradar.nl/coenecoop/<br />
<br />
=== Use TheThingsIndoorGateway as Helium/ThingSix hotspot ===<br />
I have a spare TTIG that could perhaps be used as a Helium gateway, investigate what is possible.<br />
<br />
One possiblity is to capture the gateway traffic from the TTN gateway events API, convert uplink data to a format that the Helium network understands and forward it.<br />
I don't really care about the Helium crypto tokens, this is just for fun and science.<br />
<br />
What I definitely can do:<br />
* Capture data from the TTN gateway events API, convert it back to Semtech UP format and forward it somewhere to Helium (just not sure where!)<br />
* See also my https://github.com/bertrik/ttn-gateway-collector project which contains an initial implementation of TTN-to-UDP conversion<br />
<br />
Showstoppers:<br />
* If you want to be a gateway on the Helium network, you have to *pay Helium*! Obviously I don't want that, I just want to share data to improve *their* network. <br />
<br />
Open work:<br />
* Investigate if Helium has an open uplink API for their hotspots, if so study it etc, without paying the gateway fee<br />
* Investigate if Thingsix has an open uplink API for their hotspots, if so study it etc, without paying any gateway fee<br />
* Investigate if Thingsix is just another Helium, with weird crypto money<br />
<br />
Interesting stuff:<br />
* https://docs.helium.com/use-the-network/setup-a-packet-forwarder unfortunately the link to setting up the 'light hotspot client' does not work!<br />
* https://docs.helium.com/mine-hnt/light-hotspots/<br />
* https://thingsix.com/<br />
<br />
=== Adding BLE GATT interface to sensors ===<br />
The GATT specification allows measurement properties to be defined and transferred continuously over Bluetooth low-energy.<br />
<br />
With GATT you can define a collection of properties (e.g. measurement items like temperature/humidity/particulate matter/noise, etc)<br />
organised in a simple structure of a BLE service.<br />
The 'notification' method allows you to basically push the data continuously to a connected host, e.g. a smart phone.<br />
<br />
Services collects characteristic, a characteristic has values with units.<br />
Each of these (service, characteristic, unit) have their own unique "UUID".<br />
This is described in the so-called [https://btprodspecificationrefs.blob.core.windows.net/assigned-values/16-bit%20UUID%20Numbers%20Document.pdf 16-bit UUID numbers document]<br />
<br />
Interesting stuff in GATT:<br />
* See GATT_Specification_Supplement_v5 paragraph 3.151, it has a noise characteristic with 1 dB resolution.<br />
* 0x27C3 is the GATT *unit* for sound pressure<br />
* 0x181A is the GATT environmental sensing *service*, document name "ESP_V1.0.0.pdf"<br />
* 0x2A6E is the GATT Characteristic and Object Type for temperature<br />
* 0x2A6F is the GATT Characteristic and Object Type for humidity<br />
* 0x2BD5 is the GATT Characteristic and Object Type for Particulate Matter - PM1 Concentration<br />
* 0x2BD6 is the GATT Characteristic and Object Type for Particulate Matter - PM2.5 Concentration<br />
* 0x2BD7 is the GATT Characteristic and Object Type for Particulate Matter - PM10 Concentration<br />
* Unfortunately I cannot find a characteristic for carbon-dioxide (CO2) in the BLE GATT unit document<br />
<br />
See also https://programmaticponderings.com/2020/08/04/getting-started-with-bluetooth-low-energy-ble-and-generic-attribute-profile-gatt-specification-for-iot/<br />
<br />
=== Reverse engineering XS-8217 bluetooth air quality meter ===<br />
This is a thing that measures CO2, humidity, temperature, TVOC and formaldehyde.<br />
<br />
See also https://wiki.liutyi.info/display/CO2/ZN-2CO3+Inside<br />
<br />
This teardown looks a lot like my sensor: https://www.youtube.com/watch?v=APnjhMrJChI<br />
Mine contains a "TPM-300A" sensor for measuring VOC.<br />
<br />
It has a bluetooth interface, device name is XS-8217.<br />
It has a BLE GATT profile, with the following services<br />
* service 0xC760<br />
** characteristic 0xC762 (WRITE)<br />
** characteristic 0xC761 (NOTIFY)<br />
*** example data: 0x23 0x06 0x10 0x04 0xF1 0x00 0x23 0x65<br />
*** example data: 0x23 0x08 0x10 0x04 0x01 0x9A 0x00 0x0A 0x00 0x03 0x0E<br />
*** data shown on screen was approximately: CO2=418ppm, HCHO=0.003mg/m3, TVOC=0.013mg/m3, temp=24degC, humi=35%<br />
<br />
So data in the characteristic 0xC761 seems to have a 4 byte constant header:<br />
* 0x23<br />
* length byte<br />
<br />
Then we have for the first message: 0x10 0x04 0xF1 0x00 0x23 0x65<br />
* 0x10 0x04 fixed header<br />
* 0xF1 is temperature in 0.1 degree Celcius most likely (24.1)<br />
* 0x00 is ...<br />
* 0x23 is humidity most likely (35)<br />
* 0x65 is ... checksum perhaps<br />
<br />
And for the second message: 0x10 0x04 0x01 0x9A 0x00 0x0A 0x00 0x03 0x0E<br />
* 0x10 0x04 fixed header<br />
* 0x01 0x9A is the CO2 concentration (410)<br />
* 0x00 0x0A is TVOC most likely (10)<br />
* 0x00 0x03 is HCHO most likely (3)<br />
* 0x0E is ... checksum perhaps<br />
<br />
=== ribbon tweeter for bat audio ===<br />
Someone gave me this idea:<br />
Use a ribbon tweeter like this for playing back bat audio:<br />
<s>https://nl.aliexpress.com/item/4000973201791.html</s><br />
<s>https://nl.aliexpress.com/item/1005002565880660.html</s><br />
https://nl.aliexpress.com/item/1005002635086050.html<br />
<br />
The frequency spectrum shows no sign of dropping off at 20 kHz.<br />
<br />
=== 3d glasses ===<br />
I got some 2nd hand 3d glasses, they look exactly like these ones:<br />
* GH-15 https://www.dhgate.com/product/g15-dlp-3d-active-shutter-glasses-96-144hz/213983026.html<br />
* Sintron https://www.amazon.de/Sintron-Kompatibel-TDG-BT500A-TDG-BT400A-Deutschland/dp/B015PCWMZ8<br />
The common name appears to be "G15-DLP".<br />
<br />
A tear-down here:<br />
* https://blog.danman.eu/3d-shutter-glasses-teardown/<br />
<br />
Interesting documents:<br />
* http://cmst.curtin.edu.au/wp-content/uploads/sites/4/2016/05/2012-28-woods-helliwell-cross-compatibility_of_shutter_glasses.pdf<br />
* http://cmst.curtin.edu.au/local/docs/pubs/2011-17-woods-helliwell-3D-Sync-IR.pdf<br />
<br />
Someone claims he got something to work with some hacks:<br />
https://www.avsforum.com/threads/how-i-got-cheap-dlp-link-glasses-to-work-great.1887145/<br />
<br />
=== Waterniveaumeter ===<br />
Op verschillende plekken in Gouda staat er water in de kruipruimte van huizen van bewoners.<br />
Kunnen we dat meten en inzichtelijk maken, voor bewoners, op een kaart bijvoorbeeld?<br />
<br />
Idee:<br />
* in de kruipruimte plaats je een module die waterhoogte kan meten<br />
* de module bestaat uit een microcontroller en een afstandsmeter, die de waterhoogte bepaalt<br />
* de gegevens worden via WiFi doorgestuurd naar een centraal punt, waar de data wordt verwerkt en gevisualiseerd<br />
* op een webpagina kan je een overzicht zien van alle meters die online zijn<br />
* de meting wordt gedaan door bijv. een laser-afstandsmeter of een ultrasoon-afstandsmeter<br />
* voeding? lastig, hoe krijg je 5v naar een potentieel natte plek?<br />
* kosten? verwachting < E 40,-<br />
<br />
In Gouda wordt op veel verschillende plekken de grondwaterstand gemeten, zie https://opendata.munisense.net/portal/wareco-water2/group/581/Gouda-KJ38A , maar:<br />
* geen visualisatie op de kaart, je ziet alleen de meetlokaties d.m.v. een icoontje!<br />
* geen meetpunten in Gouda noord!<br />
<br />
=== Online bat detector ===<br />
Idea: use an ultrasonic microphone, connect it to a WebSDR, so people can tune into bat sounds remotely.<br />
<br />
=== Raspberry pi airplane tracking ===<br />
Apparently now you can also participate in MLAT tracking of planes that don't transmit GPS coordinates themselves.<br />
<br />
=== APRS gateway ===<br />
http://qso365.co.uk/2017/02/a-guide-to-setting-up-an-aprs-receive-only-igate-using-a-raspberry-pi-and-an-rtl-sdr-dongle/<br />
<br />
=== JQ6500 ===<br />
Small inexpensive modules that play mp3 from an internal flash. Could be nice for a custom door bell for example.<br />
<br />
More info at: <br />
* https://www.elecfreaks.com/wiki/index.php?title=JQ6500_Mini_MP3_Module<br />
* https://sparks.gogo.co.nz/jq6500/index.html<br />
<br />
=== FPGA ===<br />
Cheap FPGA boards and nice applications:<br />
* https://bitbucket.org/appanp/artificial-neural-networks/wiki/Home/FPGAsAndNeuralNets.md#!sbcs-and-iot-boards <br />
* [http://nl.aliexpress.com/item/Altera-fpga-cycloneii-ep2c5t144-learning-board-development-board/872520721.html inexpensive ep2c5t144 board] <br />
* http://land-boards.com/blwiki/index.php?title=Cyclone_II_EP2C5_Mini_Dev_Board<br />
<br />
=== Neural networks on low-end hardware ===<br />
Investigate if you can run a powerful neural network on relatively low-end/cheap/low-power hardware. For example a Raspberry pi.<br />
A RPI runs Linux, run python, just like some common neural frameworks.<br />
Do we need hardware acceleration from the GPU and does the RPI GPU support that?<br />
<br />
Read list:<br />
* https://www.zdnet.com/pictures/raspberry-pi-meets-ai-the-projects-that-put-machine-learning-on-the-35-board/<br />
* https://www.pyimagesearch.com/2017/12/18/keras-deep-learning-raspberry-pi/<br />
* https://www.indiegogo.com/projects/sipeed-maix-the-world-first-risc-v-64-ai-module#/<br />
* https://ai.intel.com/intel-neural-compute-stick-2-smarter-faster-plug-and-play-ai-at-the-edge/<br />
<br />
Bought a MaixPy:<br />
* see https://maixpy.sipeed.com/en/<br />
* see https://www.youtube.com/watch?v=KResVuAIMb4<br />
* see http://educ8s.tv/sipeed-m1-dock-review/<br />
* interesting? https://www.instructables.com/id/Transfer-Learning-With-Sipeed-MaiX-and-Arduino-IDE/<br />
<br />
=== mini word clock in dutch ===<br />
Basically an monochrome 8x8 word clock, in Dutch, showing local time in the Netherlands.<br />
<br />
[https://github.com/bertrik/miniwordclock This git repo] has the current code.<br />
<br />
See [https://plus.google.com/103276078656203197145/posts/7ki7rpJzk3a here for a demo] running on an arduino nano.<br />
<br />
The plan is to run this from an ESP8266 instead of an arduino nano, so it can get the time from the internet using NTP.<br />
Andreas Spiess demonstrated on youtube how existing libraries on the ESP8266 can be used to do the local time (including summer-time) calculations.<br />
<br />
=== Cypress PSOC5 ===<br />
Play with the Cypress PSOC5 platform, which combines a ARM Cortex-m3 processor with configurable analog blocks. I'm thinking of combining it with a 24 GHz doppler radar sensor, to process the signal and present it as a USB audio device (stereo signal contains I and Q parts). See [[RadarOnAStick]].<br />
<br />
=== Simple Doppler motion sensors ===<br />
You can find basic doppler microwave motion sensors based on a single transistor, with some weird traces on the PCB very cheaply, for example<br />
* https://www.aliexpress.com/item/RCWL-0516-microwave-radar-sensor-module-Human-body-induction-switch-module-Intelligent-sensor/32708877914.html<br />
<br />
Typically the microwave part of these consists of a single transistor with a rectangular area on one leg and a meandering trace (with lots of vias to the other side) on the other leg.<br />
The output of this circuit seems to go into a chip very much like the ones used in PIR sensors.<br />
<br />
See also https://github.com/jdesbonnet/RCWL-0516 for a reverse engineering effort of these doppler radar modules.<br />
<br />
=== Bare-bones Arduino bat detector ===<br />
This is an idea for a very basic heterodyne bat detector, doing signal processing on an Arduino, requiring minimal external components.<br />
<br />
The basic principle of a heterodyne detector is that it just mixes (multiplies) the audio signal with a square wave, low-pass filters the result and puts it on a speaker.<br />
<br />
Multiplying with a square wave can also be considered to be just alternatively inverting and not-inverting the signal.<br />
So if you sample an ultrasonic signal at twice the rate you want to multiply, you can just subtract odd samples from even samples and low-pass filter that.<br />
<br />
How this can be done in an AVR Arduino:<br />
* sample the audio signal at twice the detection frequency, say 84 kHz. An AVR should just be able to do that.<br />
* apply a 1-pole IIR high-pass filter to remove DC bias, this takes one shift instruction and one addition.<br />
* multiply by the detection frequency, this means just inverting the odd samples.<br />
* low-pass filter the signal, this can be done using a moving average filter, say 16 samples long (first null at 5.25 kHz). Theoretically, averaging 16 samples should result in two bits extra accuracy. This operation takes some storage, an addition and a subtraction.<br />
* output the filtered signal using PWM, possibly at the same rate that we are sampling the input audio.<br />
<br />
The microphone can be a 40 kHz piezo transducer, to keep it cheap (but also limited to 40 kHz).<br />
The pre-amplifier can be a single transistor with some resistors around it, providing about 40x gain.<br />
The arduino does the signal processing (mixing, low-pass filter) to shift the bat audio to human range.<br />
The speaker amplifier can just be a simple two transistor push-pull circuit, since the output from the Arduino is digital/PWM.<br />
<br />
==== AVR Arduino sample rate ====<br />
As far as I understand, the ADC clock can be set to 1 MHz.<br />
Conversion takes 13 cycles, so this can be a problem to reach a sample rate above 80 kHz.<br />
<br />
=== Indoor radar speed sign ===<br />
This idea about placing a simple IQ-output radar sensor indoors in the hacker space, do some basic signal processing on the IQ doppler signal and determine movement speed and direction, then display this on a LED display.<br />
This is of no immediate practical use other than fun, but helps me to gain a bit more experience with microwave radar sensors and eventually build a more effective setup for detecting/counting bats flying in and out of a roost.<br />
<br />
Implement this on a PSOC5 platform or on the STM32 using Arduino.</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=User:Bertrik_Sikken&diff=35214User:Bertrik Sikken2026-04-25T10:47:53Z<p>Bertrik Sikken: /* Action 32x32 display */</p>
<hr />
<div>{{Smoel<br />
|Name=Bertrik Sikken<br />
|Nick=bertrik<br />
|Tagline=heb ik niet<br />
}}<br />
<br />
You can reach me at [mailto:bertrik@sikken.nl bertrik@sikken.nl] or [mailto:bertrik@gmail.com bertrik@gmail.com].<br />
<br />
Studied Electrical Engineering at Twente University.<br />
<br />
<br />
Main interests:<br />
* reverse-engineering things (USB stuff, mp3 players), worked on http://rockbox.org (sansa clip players)<br />
* studying bats and making electronics for recording/listening to bat sounds<br />
* radio stuff, in particular software-defined radio, LoRa networks<br />
* citizen science and open data (particulate matter measurement, noise, water quality)<br />
* energy-related stuff, visualisation<br />
<br />
Projects I work(ed) on ([https://revspace.nl/index.php?title=User:Bertrik_Sikken&action=purge refresh]):<br />
{{#ask:[[Category:Project]][[Project Contact::bertrik]]<br />
|?Project Status<br />
|headers=show<br />
|link=all<br />
|order=ASC,ASC<br />
|sort=Project Status,Project Name<br />
}}<br />
<br />
<br />
== Project ideas ==<br />
[[File:always10oclock.jpg|right]]<br />
[[File:idea.jpg|right]]<br />
<br />
This is a list of ideas I'm thinking about, but have not fully developed into an actual project yet.<br />
<br />
https://pine64.com/product/128mb-ox64-sbc-available-on-december-2-2022/<br />
<br />
=== Action 32x32 display ===<br />
Action sells [https://www.action.com/nl-nl/p/3217439/led-pixelbord/ this ACT1026 display]. You control it over BLE.<br />
<br />
* https://github.com/Pupariaa/Bk-Light-AppBypass works to control it<br />
* software for a similar led display: https://github.com/derkalle4/python3-idotmatrix-client<br />
<br />
=== investigate thread/matter ===<br />
Matter/thread is the new IKEA standard for home automation thins apparently. <br />
Thread is the wireless protocol, matter is a home automation protocol running on top of thread.<br />
<br />
I have a couple of nrf52840, these are good in doing thread.<br />
<br />
Next steps:<br />
* check out openthread<br />
<pre><br />
git clone https://github.com/openthread/openthread.git<br />
cd openthread<br />
git submodule update --init --recursive<br />
</pre><br />
* Prepare development environment:<br />
scripts/bootstrap<br />
* Build it:<br />
./script/build nrf52840 UART_trans -DOT_LOG_LEVEL=OT_LOG_LEVEL_INFO<br />
<br />
Thread on ESP32:<br />
* on ESP32 C6 https://gist.github.com/gtxaspec/d26198daadfb0a8b0a0edeae2d3fd58f<br />
* https://github.com/espressif/esp-thread-br<br />
* https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_rcp<br />
<br />
=== action lsc stekker ===<br />
https://keetsupport.nl/2024/03/20/how-to-flash-lsc-power-plug-with-esphome/<br />
<br />
https://community.home-assistant.io/t/detailed-guide-on-how-to-flash-the-new-tuya-beken-chips-with-openbk7231t/437276<br />
<br />
=== sipeed maix dock ===<br />
Bought this a couple of years ago. Get familiar with this board.<br />
Can I run a chess program on this, for example?<br />
<br />
* https://wiki.sipeed.com/soft/maixpy/en/develop_kit_board/maix_dock.html<br />
<br />
=== rfid keyfob ===<br />
* aliexpress page: https://nl.aliexpress.com/item/1005009569496736.html<br />
* firmware github: <br />
** https://github.com/RfidResearchGroup/ChameleonUltra<br />
** https://github.com/GameTec-live/ChameleonUltraGUI<br />
<br />
=== advanced lidars for bat detection ===<br />
livox:<br />
* github page https://github.com/Livox-SDK/Livox-SDK/tree/master<br />
* web page: https://www.livoxtech.com/<br />
<br />
=== cubecell meshtastic motion detector ===<br />
I have a cubecell AB01 board.<br />
This board is focused on low power, has a connection to attach a solar panel and has a lora radio.<br />
Relatively small amount of RAM, barely enough to run a LoRaWAN stack but probably plenty to run meshtastic<br />
<br />
The plan is to build a simple motion detector from this (using a PIR).<br />
The PIR can wake up the board from low-power, or a timer can wake it periodically.<br />
<br />
See also: https://github.com/HelTecAutomation/CubeCell-Arduino/tree/master/libraries/Basics/examples/LowPower<br />
<br />
=== configure multitech outdoor gateway ===<br />
https://www.multitech.net/developer/products/multiconnect-conduit-platform/basestation/<br />
<br />
https://multitech.com/product/multitech-conduit-mtcdt-246a-868-eu-gb/<br />
<br />
emergency procedure:<br />
https://www.multitech.net/developer/software/mlinux/using-mlinux/flashing-mlinux-firmware-for-conduit/<br />
<br />
=== esp32 wtf ===<br />
* https://forum.arduino.cc/t/ttgo-lilygo-lora-esp32-26mhz-problem/1353750<br />
* "26 MHz crystal has been deprecated" https://github.com/espressif/arduino-esp32/issues/10117<br />
<br />
=== kakofonie counter ===<br />
Sample room audio, use neural network to distinguish voices to estimate number of people talking in the past 30 seconds or so.<br />
Show this number on some kind of display, publish it to MQTT, make a nice graph of it.<br />
<br />
Stuff to figure out:<br />
* this is called 'speaker diarization'<br />
* can it run on an ESP32?<br />
* make a prototype<br />
<br />
=== hypno toad ===<br />
Put these LEDS https://nl.aliexpress.com/item/1005007583528891.html into https://www.action.com/nl-nl/p/2560347/solar-tuinbeeldje/<br />
<br />
Turns out that the default circuit is really basic and output a rough step-up waveform to the LED.<br />
The self-fading LEDs don't work very well with that.<br />
<br />
Also, putting some IPA on hotglue makes it release really easy.<br />
<br />
=== wasbeer / kat classifier ===<br />
ESP32 with resnet50 neural net to distinguish house cats from other animals, see also:<br />
* https://ieeexplore.ieee.org/document/10556848/<br />
<br />
=== Nespresso brew counter ===<br />
Several hacker spaces have one of these Nespresso cup coffee makers, but there's no obvious easy way to monitor usage (monitor ALL the things!).<br />
Inspired by https://hackaday.com/2021/04/25/arduino-mkr-makes-nespresso-monitoring-easy/ this idea is making an even simpler nespresso monitor,<br />
using an inexpensive WiFi enabled ESP8266 with an ubiquitous I2S microphone such as the INMP441. <br />
<br />
Use this sound monitoring project:<br />
https://github.com/aleiei/ESP8266-BUG-I2S-MIC<br />
and turn it into a WiFi connected brew counter.<br />
<br />
Software for getting microphone data from an ESP8266/I2S mic into Linux https://github.com/bertrik/EspMicServer<br />
Nespresso sound is typically 50 Hz with overtones.<br />
In a recording with the ESP8266, it appears that oddly the 17th harmonic (around 850 Hz) is quite strong.<br />
<br />
The plan in the short term is this:<br />
* apply a gentle IIR filter to subtract any DC bias from the microphone signal<br />
* calculate autocovariance at offsets 0 and 20 ms (inverse of 50 Hz), representing the total energy and the energy at 50 Hz respectively<br />
* compare amplitudes to decide about presence of 50 Hz signal, e.g. calculate ratio in dB<br />
* use this to count the length of time that a 50 Hz signal is heard (increments of 100 ms or so)<br />
* decide about none / espresso / lungo based on time<br />
<br />
Might even integrate with esphome / home assistant later.<br />
<br />
=== Remote bat box monitor ===<br />
Idea:<br />
* goal: check if remote bat boxes are occupied and identify the species<br />
* challenges:<br />
** connectivity: need to transport images/videos (no LoRaWAN), possibly out of range of mobile data networks<br />
** autonomy: cannot reach the bat box once installed<br />
** power: no fixed power connection, so probably needs a battery + solar panel<br />
* design<br />
** wake up every hour, take a picture, go to sleep, upload photos/videos once per day<br />
** run from batteries, recharge by solar, rules of thumb<br />
*** batteries should last for about 10 days<br />
*** battery should be able to charge in 1 day<br />
*** consider only 10% of peak solar power<br />
** KPN "4G-op-zee" somewhat confusing article: https://www.kpn.com/zakelijk/mobiel/roaming/noordzee<br />
* hardware<br />
** main processor: raspberry pi zero<br />
*** raspberry pi power consumption overview: https://www.pidramble.com/wiki/benchmarks/power-consumption<br />
** this hat to wake up the main CPU: https://www.waveshare.com/wiki/Power_Management_HAT_(B) sold at https://www.kiwi-electronics.com/en/power-management-hat-for-raspberry-pi-with-rtc-and-rp2040-mcu-11373<br />
<br />
=== KNMI API ===<br />
Get familiar with https://developer.dataplatform.knmi.nl/open-data-api<br />
<br />
=== Grid frequency measurer with web page ===<br />
See https://github.com/bertrik/GridFrequency<br />
SSE source is gridfrequency.local/events<br />
<br />
=== WeAct CH55x board ===<br />
Cheap little boards, using a similar chip as used in USB-serial converters.<br />
<br />
The hardware<br />
https://github.com/WeActStudio/WeActStudio.CH552CoreBoard<br />
<br />
Flashing it:<br />
https://hackaday.io/page/137447-flashing-the-ch552-dev-board-from-the-command-line<br />
<br />
See also:<br />
* https://hackaday.io/project/198238-more-weact-ch5xx<br />
* https://community.platformio.org/t/manually-adding-support-for-ch55x-controller-by-adding-existing-ardunio-core/41138<br />
<br />
=== Zigbee device with esp32 ===<br />
See https://github.com/P-R-O-C-H-Y/arduino-esp32/blob/8169a434c3e46e1bb7711ebcc04f27267db2093c/libraries/ESP32/examples/Zigbee/Zigbee_Light_Bulb/Zigbee_Light_Bulb.ino<br />
<br />
See https://github.com/espressif/arduino-esp32/tree/master/libraries/ESP32/examples/Zigbee<br />
<br />
Espressif32 arduino platform git: https://github.com/platformio/platform-espressif32<br />
<br />
=== Cameratoezicht in Gouda ===<br />
Gemeente Gouda publiceert een lijst van camera's in Gouda, zie<br />
https://gis.gouda.nl/nl/app/Basisviewer_open#!eAGT8uRiNBRy4ZIRYFKSyKkssjJwdzFxNDMz8TKKsLC0cnb0dQ1y5FIByirgkg3xd43ydPYIAQBXGBFm<br />
<br />
Aanmelden (semi-automatisch) bij bijvoorbeeld [https://mapcomplete.org/surveillance Surveillance-under-surveillance] ?<br />
<br />
=== SolarEdge ===<br />
Interact with the solar edge api for PV installations.<br />
<br />
https://developers.solaredge.com/<br />
<br />
See https://github.com/bertrik/solaredge-api<br />
<br />
=== Stookalert ===<br />
Idee: gekleurd lampje dat aangeeft of er op dit moment een stookalert actief is<br />
<br />
Implementatie:<br />
* kijk m.b.v. WiFi locatieservice in welke provincie je je bevindt<br />
* haal JSON op bij https://www.lml.rivm.nl/stookalert/stookalert.json<br />
* toon de bijbehorende kleur op het lampje<br />
<br />
Resources:<br />
* Officiele pagina: https://www.atlasleefomgeving.nl/stookwijzer<br />
* Achterliggende JSON met toestand per provincie: https://www.lml.rivm.nl/stookalert/stookalert.json<br />
* Er moet ook nog ergens een API zijn die fijnmaziger aangeeft wat de toestand is ...<br />
<br />
=== Display of current electricity usage ===<br />
I have a [https://www.zuidwijk.com/product/slimmelezer-plus/ slimme lezer] connected to the P1 port of my smart electricity meter.<br />
The default firmware exposes meter readings using an event stream (SSE) at http://slimmelezer.local/events<br />
<br />
So for example, you can read this with curl:<br />
curl http://slimmelezer.local/events<br />
With result:<br />
event: state<br />
data: {"id":"sensor-power_consumed_phase_1","value":0.046,"state":"0.046 kW"}<br />
<br />
Specification of SSE: https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream<br />
<br />
What I would like to do is to read these events and control a simple display to display the current usage number.<br />
<br />
=== Participating in ultrasonic sound project ===<br />
https://bat-migration-europe.netlify.app/project/<br />
<br />
Use an audiomoth for this.<br />
<br />
=== ESP32 C3 ===<br />
* [https://www.espressif.com/en/products/socs/esp32-c3 processor page]<br />
* [https://wiki.luatos.com/chips/esp32c3/index.html luatos basic esp32 c3 board]<br />
<br />
=== Flexible LED ticker ===<br />
Ordered a flexible 32x8 RGB LED display:<br />
https://nl.aliexpress.com/item/4001296811800.html<br />
<br />
Matching diffuser to be 3D printed:<br />
https://www.thingiverse.com/thing:1903744<br />
<br />
=== Washing machine API ===<br />
https://tratt.net/laurie/blog/2023/displaying_my_washing_machines_remaining_time_with_curl_jq_pizauth.html<br />
<br />
=== TinyML ===<br />
Investigate TinyML, see https://www.tinyml.org/<br />
Apparently can run on a RP2040 (raspi pi pico).<br />
<br />
https://www.hackster.io/mjrobot/esp32-cam-tinyml-image-classification-fruits-vs-veggies-4ab970<br />
<br />
=== Bat box busy signal ===<br />
My brother built little pyramid 'blinkies': solar cell + Lithium-supercapacitor + harvesting circuit + LED encased in clear expoxy.<br />
<br />
Can we add a low-power PIR sensor to this, and make a blinky that blinks if movement was detected by the PIR in the past hour?<br />
<br />
=== Super tiny RFID ===<br />
See https://www.sparkfun.com/products/16464 an almost sand grain size RFID chip, 1.25mmx1.25mmx0.55mm<br />
<br />
The accompanying reader "M6E Nano" is still quite expensive at $235.95 : https://www.sparkfun.com/products/14066<br />
<br />
Uses the MuRata LXMSJZNCMF-198:<br />
"This product can be used as an ultra small tag and this can be<br />
fit on any metal objects, non-metal objects, as well as<br />
embedding into any objects by glue or adhesive and so on."<br />
<br />
See also: ISO18000-63 and EPC global Gen2(v2)<br />
<br />
Specification:<br />
* https://www.gs1.org/standards/rfid/uhf-air-interface-protocol<br />
<br />
=== TheThingsNetwork-Sondehub bridge ===<br />
Uploads balloon telemetry to sondehub.<br />
<br />
See https://github.com/bertrik/ttnhabbridge/issues/6<br />
<br />
=== Actually smart boiler ===<br />
The boiler for hot water is about half of my electricity bill.<br />
The idea is to use/build a smart switch that switches it on at time when electricity prices are lowest.<br />
<br />
Currently have a "Slimme boiler module" from Eneco, which is *not* actually smart,<br />
since it allows me no control whatsoever when it switches on (besides cutting the power in the meterkast).<br />
For example, it will switch on mid-day when my price is high and eneco's price is low, perhaps good for Eneco, not for me. <br />
Apparently, they even received a [https://nieuws.eneco.nl/slim-apparaatje-bij-boiler-vangt-pieken-wind--en-zonnestroom-op/ subsidy] for this.<br />
<br />
A boiler is a pretty big load, about 3 kW, but it is not inductive.<br />
<br />
Alternatives:<br />
* https://www.shelly.cloud/en-nl/products/product-overview/shelly-plus-1-pm-2-pack/shelly-plus-1-pm<br />
* https://www.solyxenergy.nl/solar-iboost/ to store excess solar energy in hot water, might also be useful for just controlling a boiler to use cheaper rates<br />
* tuya smartplug, like https://www.wifilampkoning.nl/merken-slimme-verlichting/tuya/tuya-enkele-smartplug-met-energiemeting ?<br />
* tuya 20A smart plug: https://nl.aliexpress.com/item/1005003347568206.html<br />
<br />
=== Receiving gas meters ===<br />
Apparently gas meters send gas consumption data to the slimme meter using a wireless link in the 868 MHz band.<br />
Probably just FSK at 38.4, as mentioned here: https://a35.veron.nl/nieuwe-elektra-en-gasmeters/<br />
<br />
Interesting leads:<br />
* https://github.com/stef/smeter<br />
* https://www.rtl-sdr.com/reading-household-wireless-utility-meters-with-an-rtl-sdr-and-plotting-the-data-in-home-automation-software/<br />
* https://github.com/bemasher/rtlamr<br />
<br />
=== Multi-network wifi manager ===<br />
Figure out or create software so that ESP8266/ESP32 wifi manager can use multiple networks to connect (not just one),<br />
so it allowing storing credentials for more than one network. For example, the network at home, the hacker space, at work.<br />
Instead of reconfiguring the wifi manager for each network, you just *add* your credentials (and the existing credentials<br />
are not replaced).<br />
<br />
See https://github.com/folkertvanheusden/M.A.X.X<br />
<br />
Interesting candidates:<br />
* https://registry.platformio.org/libraries/martinverges/ESP32%20Wifi%20Manager wifi manager for ESP32, has a REST API for managing wifi network, but is incomplete in the sense that you need to write your own code (e.g. javascript) to actually *use* its API<br />
* https://github.com/arduino-libraries/Arduino_MultiWiFi is the arduino multi wifi library, to allow connecting to multiple different WiFi networks, but it is not a wifi manager, that starts a captive portal, etc<br />
<br />
=== Automated bat counting ===<br />
Can we automatically count the number of bats from the image of a webcam mounted in a bat colony?<br />
Perhaps using some kind of AI or machine learning algorithm?<br />
<br />
The image in question:<br />
https://stofradar.nl/coenecoop/<br />
<br />
=== Use TheThingsIndoorGateway as Helium/ThingSix hotspot ===<br />
I have a spare TTIG that could perhaps be used as a Helium gateway, investigate what is possible.<br />
<br />
One possiblity is to capture the gateway traffic from the TTN gateway events API, convert uplink data to a format that the Helium network understands and forward it.<br />
I don't really care about the Helium crypto tokens, this is just for fun and science.<br />
<br />
What I definitely can do:<br />
* Capture data from the TTN gateway events API, convert it back to Semtech UP format and forward it somewhere to Helium (just not sure where!)<br />
* See also my https://github.com/bertrik/ttn-gateway-collector project which contains an initial implementation of TTN-to-UDP conversion<br />
<br />
Showstoppers:<br />
* If you want to be a gateway on the Helium network, you have to *pay Helium*! Obviously I don't want that, I just want to share data to improve *their* network. <br />
<br />
Open work:<br />
* Investigate if Helium has an open uplink API for their hotspots, if so study it etc, without paying the gateway fee<br />
* Investigate if Thingsix has an open uplink API for their hotspots, if so study it etc, without paying any gateway fee<br />
* Investigate if Thingsix is just another Helium, with weird crypto money<br />
<br />
Interesting stuff:<br />
* https://docs.helium.com/use-the-network/setup-a-packet-forwarder unfortunately the link to setting up the 'light hotspot client' does not work!<br />
* https://docs.helium.com/mine-hnt/light-hotspots/<br />
* https://thingsix.com/<br />
<br />
=== Adding BLE GATT interface to sensors ===<br />
The GATT specification allows measurement properties to be defined and transferred continuously over Bluetooth low-energy.<br />
<br />
With GATT you can define a collection of properties (e.g. measurement items like temperature/humidity/particulate matter/noise, etc)<br />
organised in a simple structure of a BLE service.<br />
The 'notification' method allows you to basically push the data continuously to a connected host, e.g. a smart phone.<br />
<br />
Services collects characteristic, a characteristic has values with units.<br />
Each of these (service, characteristic, unit) have their own unique "UUID".<br />
This is described in the so-called [https://btprodspecificationrefs.blob.core.windows.net/assigned-values/16-bit%20UUID%20Numbers%20Document.pdf 16-bit UUID numbers document]<br />
<br />
Interesting stuff in GATT:<br />
* See GATT_Specification_Supplement_v5 paragraph 3.151, it has a noise characteristic with 1 dB resolution.<br />
* 0x27C3 is the GATT *unit* for sound pressure<br />
* 0x181A is the GATT environmental sensing *service*, document name "ESP_V1.0.0.pdf"<br />
* 0x2A6E is the GATT Characteristic and Object Type for temperature<br />
* 0x2A6F is the GATT Characteristic and Object Type for humidity<br />
* 0x2BD5 is the GATT Characteristic and Object Type for Particulate Matter - PM1 Concentration<br />
* 0x2BD6 is the GATT Characteristic and Object Type for Particulate Matter - PM2.5 Concentration<br />
* 0x2BD7 is the GATT Characteristic and Object Type for Particulate Matter - PM10 Concentration<br />
* Unfortunately I cannot find a characteristic for carbon-dioxide (CO2) in the BLE GATT unit document<br />
<br />
See also https://programmaticponderings.com/2020/08/04/getting-started-with-bluetooth-low-energy-ble-and-generic-attribute-profile-gatt-specification-for-iot/<br />
<br />
=== Reverse engineering XS-8217 bluetooth air quality meter ===<br />
This is a thing that measures CO2, humidity, temperature, TVOC and formaldehyde.<br />
<br />
See also https://wiki.liutyi.info/display/CO2/ZN-2CO3+Inside<br />
<br />
This teardown looks a lot like my sensor: https://www.youtube.com/watch?v=APnjhMrJChI<br />
Mine contains a "TPM-300A" sensor for measuring VOC.<br />
<br />
It has a bluetooth interface, device name is XS-8217.<br />
It has a BLE GATT profile, with the following services<br />
* service 0xC760<br />
** characteristic 0xC762 (WRITE)<br />
** characteristic 0xC761 (NOTIFY)<br />
*** example data: 0x23 0x06 0x10 0x04 0xF1 0x00 0x23 0x65<br />
*** example data: 0x23 0x08 0x10 0x04 0x01 0x9A 0x00 0x0A 0x00 0x03 0x0E<br />
*** data shown on screen was approximately: CO2=418ppm, HCHO=0.003mg/m3, TVOC=0.013mg/m3, temp=24degC, humi=35%<br />
<br />
So data in the characteristic 0xC761 seems to have a 4 byte constant header:<br />
* 0x23<br />
* length byte<br />
<br />
Then we have for the first message: 0x10 0x04 0xF1 0x00 0x23 0x65<br />
* 0x10 0x04 fixed header<br />
* 0xF1 is temperature in 0.1 degree Celcius most likely (24.1)<br />
* 0x00 is ...<br />
* 0x23 is humidity most likely (35)<br />
* 0x65 is ... checksum perhaps<br />
<br />
And for the second message: 0x10 0x04 0x01 0x9A 0x00 0x0A 0x00 0x03 0x0E<br />
* 0x10 0x04 fixed header<br />
* 0x01 0x9A is the CO2 concentration (410)<br />
* 0x00 0x0A is TVOC most likely (10)<br />
* 0x00 0x03 is HCHO most likely (3)<br />
* 0x0E is ... checksum perhaps<br />
<br />
=== ribbon tweeter for bat audio ===<br />
Someone gave me this idea:<br />
Use a ribbon tweeter like this for playing back bat audio:<br />
<s>https://nl.aliexpress.com/item/4000973201791.html</s><br />
<s>https://nl.aliexpress.com/item/1005002565880660.html</s><br />
https://nl.aliexpress.com/item/1005002635086050.html<br />
<br />
The frequency spectrum shows no sign of dropping off at 20 kHz.<br />
<br />
=== 3d glasses ===<br />
I got some 2nd hand 3d glasses, they look exactly like these ones:<br />
* GH-15 https://www.dhgate.com/product/g15-dlp-3d-active-shutter-glasses-96-144hz/213983026.html<br />
* Sintron https://www.amazon.de/Sintron-Kompatibel-TDG-BT500A-TDG-BT400A-Deutschland/dp/B015PCWMZ8<br />
The common name appears to be "G15-DLP".<br />
<br />
A tear-down here:<br />
* https://blog.danman.eu/3d-shutter-glasses-teardown/<br />
<br />
Interesting documents:<br />
* http://cmst.curtin.edu.au/wp-content/uploads/sites/4/2016/05/2012-28-woods-helliwell-cross-compatibility_of_shutter_glasses.pdf<br />
* http://cmst.curtin.edu.au/local/docs/pubs/2011-17-woods-helliwell-3D-Sync-IR.pdf<br />
<br />
Someone claims he got something to work with some hacks:<br />
https://www.avsforum.com/threads/how-i-got-cheap-dlp-link-glasses-to-work-great.1887145/<br />
<br />
=== Waterniveaumeter ===<br />
Op verschillende plekken in Gouda staat er water in de kruipruimte van huizen van bewoners.<br />
Kunnen we dat meten en inzichtelijk maken, voor bewoners, op een kaart bijvoorbeeld?<br />
<br />
Idee:<br />
* in de kruipruimte plaats je een module die waterhoogte kan meten<br />
* de module bestaat uit een microcontroller en een afstandsmeter, die de waterhoogte bepaalt<br />
* de gegevens worden via WiFi doorgestuurd naar een centraal punt, waar de data wordt verwerkt en gevisualiseerd<br />
* op een webpagina kan je een overzicht zien van alle meters die online zijn<br />
* de meting wordt gedaan door bijv. een laser-afstandsmeter of een ultrasoon-afstandsmeter<br />
* voeding? lastig, hoe krijg je 5v naar een potentieel natte plek?<br />
* kosten? verwachting < E 40,-<br />
<br />
In Gouda wordt op veel verschillende plekken de grondwaterstand gemeten, zie https://opendata.munisense.net/portal/wareco-water2/group/581/Gouda-KJ38A , maar:<br />
* geen visualisatie op de kaart, je ziet alleen de meetlokaties d.m.v. een icoontje!<br />
* geen meetpunten in Gouda noord!<br />
<br />
=== Online bat detector ===<br />
Idea: use an ultrasonic microphone, connect it to a WebSDR, so people can tune into bat sounds remotely.<br />
<br />
=== Raspberry pi airplane tracking ===<br />
Apparently now you can also participate in MLAT tracking of planes that don't transmit GPS coordinates themselves.<br />
<br />
=== APRS gateway ===<br />
http://qso365.co.uk/2017/02/a-guide-to-setting-up-an-aprs-receive-only-igate-using-a-raspberry-pi-and-an-rtl-sdr-dongle/<br />
<br />
=== JQ6500 ===<br />
Small inexpensive modules that play mp3 from an internal flash. Could be nice for a custom door bell for example.<br />
<br />
More info at: <br />
* https://www.elecfreaks.com/wiki/index.php?title=JQ6500_Mini_MP3_Module<br />
* https://sparks.gogo.co.nz/jq6500/index.html<br />
<br />
=== FPGA ===<br />
Cheap FPGA boards and nice applications:<br />
* https://bitbucket.org/appanp/artificial-neural-networks/wiki/Home/FPGAsAndNeuralNets.md#!sbcs-and-iot-boards <br />
* [http://nl.aliexpress.com/item/Altera-fpga-cycloneii-ep2c5t144-learning-board-development-board/872520721.html inexpensive ep2c5t144 board] <br />
* http://land-boards.com/blwiki/index.php?title=Cyclone_II_EP2C5_Mini_Dev_Board<br />
<br />
=== Neural networks on low-end hardware ===<br />
Investigate if you can run a powerful neural network on relatively low-end/cheap/low-power hardware. For example a Raspberry pi.<br />
A RPI runs Linux, run python, just like some common neural frameworks.<br />
Do we need hardware acceleration from the GPU and does the RPI GPU support that?<br />
<br />
Read list:<br />
* https://www.zdnet.com/pictures/raspberry-pi-meets-ai-the-projects-that-put-machine-learning-on-the-35-board/<br />
* https://www.pyimagesearch.com/2017/12/18/keras-deep-learning-raspberry-pi/<br />
* https://www.indiegogo.com/projects/sipeed-maix-the-world-first-risc-v-64-ai-module#/<br />
* https://ai.intel.com/intel-neural-compute-stick-2-smarter-faster-plug-and-play-ai-at-the-edge/<br />
<br />
Bought a MaixPy:<br />
* see https://maixpy.sipeed.com/en/<br />
* see https://www.youtube.com/watch?v=KResVuAIMb4<br />
* see http://educ8s.tv/sipeed-m1-dock-review/<br />
* interesting? https://www.instructables.com/id/Transfer-Learning-With-Sipeed-MaiX-and-Arduino-IDE/<br />
<br />
=== mini word clock in dutch ===<br />
Basically an monochrome 8x8 word clock, in Dutch, showing local time in the Netherlands.<br />
<br />
[https://github.com/bertrik/miniwordclock This git repo] has the current code.<br />
<br />
See [https://plus.google.com/103276078656203197145/posts/7ki7rpJzk3a here for a demo] running on an arduino nano.<br />
<br />
The plan is to run this from an ESP8266 instead of an arduino nano, so it can get the time from the internet using NTP.<br />
Andreas Spiess demonstrated on youtube how existing libraries on the ESP8266 can be used to do the local time (including summer-time) calculations.<br />
<br />
=== Cypress PSOC5 ===<br />
Play with the Cypress PSOC5 platform, which combines a ARM Cortex-m3 processor with configurable analog blocks. I'm thinking of combining it with a 24 GHz doppler radar sensor, to process the signal and present it as a USB audio device (stereo signal contains I and Q parts). See [[RadarOnAStick]].<br />
<br />
=== Simple Doppler motion sensors ===<br />
You can find basic doppler microwave motion sensors based on a single transistor, with some weird traces on the PCB very cheaply, for example<br />
* https://www.aliexpress.com/item/RCWL-0516-microwave-radar-sensor-module-Human-body-induction-switch-module-Intelligent-sensor/32708877914.html<br />
<br />
Typically the microwave part of these consists of a single transistor with a rectangular area on one leg and a meandering trace (with lots of vias to the other side) on the other leg.<br />
The output of this circuit seems to go into a chip very much like the ones used in PIR sensors.<br />
<br />
See also https://github.com/jdesbonnet/RCWL-0516 for a reverse engineering effort of these doppler radar modules.<br />
<br />
=== Bare-bones Arduino bat detector ===<br />
This is an idea for a very basic heterodyne bat detector, doing signal processing on an Arduino, requiring minimal external components.<br />
<br />
The basic principle of a heterodyne detector is that it just mixes (multiplies) the audio signal with a square wave, low-pass filters the result and puts it on a speaker.<br />
<br />
Multiplying with a square wave can also be considered to be just alternatively inverting and not-inverting the signal.<br />
So if you sample an ultrasonic signal at twice the rate you want to multiply, you can just subtract odd samples from even samples and low-pass filter that.<br />
<br />
How this can be done in an AVR Arduino:<br />
* sample the audio signal at twice the detection frequency, say 84 kHz. An AVR should just be able to do that.<br />
* apply a 1-pole IIR high-pass filter to remove DC bias, this takes one shift instruction and one addition.<br />
* multiply by the detection frequency, this means just inverting the odd samples.<br />
* low-pass filter the signal, this can be done using a moving average filter, say 16 samples long (first null at 5.25 kHz). Theoretically, averaging 16 samples should result in two bits extra accuracy. This operation takes some storage, an addition and a subtraction.<br />
* output the filtered signal using PWM, possibly at the same rate that we are sampling the input audio.<br />
<br />
The microphone can be a 40 kHz piezo transducer, to keep it cheap (but also limited to 40 kHz).<br />
The pre-amplifier can be a single transistor with some resistors around it, providing about 40x gain.<br />
The arduino does the signal processing (mixing, low-pass filter) to shift the bat audio to human range.<br />
The speaker amplifier can just be a simple two transistor push-pull circuit, since the output from the Arduino is digital/PWM.<br />
<br />
==== AVR Arduino sample rate ====<br />
As far as I understand, the ADC clock can be set to 1 MHz.<br />
Conversion takes 13 cycles, so this can be a problem to reach a sample rate above 80 kHz.<br />
<br />
=== Indoor radar speed sign ===<br />
This idea about placing a simple IQ-output radar sensor indoors in the hacker space, do some basic signal processing on the IQ doppler signal and determine movement speed and direction, then display this on a LED display.<br />
This is of no immediate practical use other than fun, but helps me to gain a bit more experience with microwave radar sensors and eventually build a more effective setup for detecting/counting bats flying in and out of a roost.<br />
<br />
Implement this on a PSOC5 platform or on the STM32 using Arduino.</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=User:Bertrik_Sikken&diff=35213User:Bertrik Sikken2026-04-18T11:13:18Z<p>Bertrik Sikken: /* Action 32x32 display */</p>
<hr />
<div>{{Smoel<br />
|Name=Bertrik Sikken<br />
|Nick=bertrik<br />
|Tagline=heb ik niet<br />
}}<br />
<br />
You can reach me at [mailto:bertrik@sikken.nl bertrik@sikken.nl] or [mailto:bertrik@gmail.com bertrik@gmail.com].<br />
<br />
Studied Electrical Engineering at Twente University.<br />
<br />
<br />
Main interests:<br />
* reverse-engineering things (USB stuff, mp3 players), worked on http://rockbox.org (sansa clip players)<br />
* studying bats and making electronics for recording/listening to bat sounds<br />
* radio stuff, in particular software-defined radio, LoRa networks<br />
* citizen science and open data (particulate matter measurement, noise, water quality)<br />
* energy-related stuff, visualisation<br />
<br />
Projects I work(ed) on ([https://revspace.nl/index.php?title=User:Bertrik_Sikken&action=purge refresh]):<br />
{{#ask:[[Category:Project]][[Project Contact::bertrik]]<br />
|?Project Status<br />
|headers=show<br />
|link=all<br />
|order=ASC,ASC<br />
|sort=Project Status,Project Name<br />
}}<br />
<br />
<br />
== Project ideas ==<br />
[[File:always10oclock.jpg|right]]<br />
[[File:idea.jpg|right]]<br />
<br />
This is a list of ideas I'm thinking about, but have not fully developed into an actual project yet.<br />
<br />
https://pine64.com/product/128mb-ox64-sbc-available-on-december-2-2022/<br />
<br />
=== Action 32x32 display ===<br />
Action sells an ACT1026 display. You control it over BLE.<br />
<br />
* https://github.com/Pupariaa/Bk-Light-AppBypass works to control it<br />
* software for a similar led display: https://github.com/derkalle4/python3-idotmatrix-client<br />
<br />
=== investigate thread/matter ===<br />
Matter/thread is the new IKEA standard for home automation thins apparently. <br />
Thread is the wireless protocol, matter is a home automation protocol running on top of thread.<br />
<br />
I have a couple of nrf52840, these are good in doing thread.<br />
<br />
Next steps:<br />
* check out openthread<br />
<pre><br />
git clone https://github.com/openthread/openthread.git<br />
cd openthread<br />
git submodule update --init --recursive<br />
</pre><br />
* Prepare development environment:<br />
scripts/bootstrap<br />
* Build it:<br />
./script/build nrf52840 UART_trans -DOT_LOG_LEVEL=OT_LOG_LEVEL_INFO<br />
<br />
Thread on ESP32:<br />
* on ESP32 C6 https://gist.github.com/gtxaspec/d26198daadfb0a8b0a0edeae2d3fd58f<br />
* https://github.com/espressif/esp-thread-br<br />
* https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_rcp<br />
<br />
=== action lsc stekker ===<br />
https://keetsupport.nl/2024/03/20/how-to-flash-lsc-power-plug-with-esphome/<br />
<br />
https://community.home-assistant.io/t/detailed-guide-on-how-to-flash-the-new-tuya-beken-chips-with-openbk7231t/437276<br />
<br />
=== sipeed maix dock ===<br />
Bought this a couple of years ago. Get familiar with this board.<br />
Can I run a chess program on this, for example?<br />
<br />
* https://wiki.sipeed.com/soft/maixpy/en/develop_kit_board/maix_dock.html<br />
<br />
=== rfid keyfob ===<br />
* aliexpress page: https://nl.aliexpress.com/item/1005009569496736.html<br />
* firmware github: <br />
** https://github.com/RfidResearchGroup/ChameleonUltra<br />
** https://github.com/GameTec-live/ChameleonUltraGUI<br />
<br />
=== advanced lidars for bat detection ===<br />
livox:<br />
* github page https://github.com/Livox-SDK/Livox-SDK/tree/master<br />
* web page: https://www.livoxtech.com/<br />
<br />
=== cubecell meshtastic motion detector ===<br />
I have a cubecell AB01 board.<br />
This board is focused on low power, has a connection to attach a solar panel and has a lora radio.<br />
Relatively small amount of RAM, barely enough to run a LoRaWAN stack but probably plenty to run meshtastic<br />
<br />
The plan is to build a simple motion detector from this (using a PIR).<br />
The PIR can wake up the board from low-power, or a timer can wake it periodically.<br />
<br />
See also: https://github.com/HelTecAutomation/CubeCell-Arduino/tree/master/libraries/Basics/examples/LowPower<br />
<br />
=== configure multitech outdoor gateway ===<br />
https://www.multitech.net/developer/products/multiconnect-conduit-platform/basestation/<br />
<br />
https://multitech.com/product/multitech-conduit-mtcdt-246a-868-eu-gb/<br />
<br />
emergency procedure:<br />
https://www.multitech.net/developer/software/mlinux/using-mlinux/flashing-mlinux-firmware-for-conduit/<br />
<br />
=== esp32 wtf ===<br />
* https://forum.arduino.cc/t/ttgo-lilygo-lora-esp32-26mhz-problem/1353750<br />
* "26 MHz crystal has been deprecated" https://github.com/espressif/arduino-esp32/issues/10117<br />
<br />
=== kakofonie counter ===<br />
Sample room audio, use neural network to distinguish voices to estimate number of people talking in the past 30 seconds or so.<br />
Show this number on some kind of display, publish it to MQTT, make a nice graph of it.<br />
<br />
Stuff to figure out:<br />
* this is called 'speaker diarization'<br />
* can it run on an ESP32?<br />
* make a prototype<br />
<br />
=== hypno toad ===<br />
Put these LEDS https://nl.aliexpress.com/item/1005007583528891.html into https://www.action.com/nl-nl/p/2560347/solar-tuinbeeldje/<br />
<br />
Turns out that the default circuit is really basic and output a rough step-up waveform to the LED.<br />
The self-fading LEDs don't work very well with that.<br />
<br />
Also, putting some IPA on hotglue makes it release really easy.<br />
<br />
=== wasbeer / kat classifier ===<br />
ESP32 with resnet50 neural net to distinguish house cats from other animals, see also:<br />
* https://ieeexplore.ieee.org/document/10556848/<br />
<br />
=== Nespresso brew counter ===<br />
Several hacker spaces have one of these Nespresso cup coffee makers, but there's no obvious easy way to monitor usage (monitor ALL the things!).<br />
Inspired by https://hackaday.com/2021/04/25/arduino-mkr-makes-nespresso-monitoring-easy/ this idea is making an even simpler nespresso monitor,<br />
using an inexpensive WiFi enabled ESP8266 with an ubiquitous I2S microphone such as the INMP441. <br />
<br />
Use this sound monitoring project:<br />
https://github.com/aleiei/ESP8266-BUG-I2S-MIC<br />
and turn it into a WiFi connected brew counter.<br />
<br />
Software for getting microphone data from an ESP8266/I2S mic into Linux https://github.com/bertrik/EspMicServer<br />
Nespresso sound is typically 50 Hz with overtones.<br />
In a recording with the ESP8266, it appears that oddly the 17th harmonic (around 850 Hz) is quite strong.<br />
<br />
The plan in the short term is this:<br />
* apply a gentle IIR filter to subtract any DC bias from the microphone signal<br />
* calculate autocovariance at offsets 0 and 20 ms (inverse of 50 Hz), representing the total energy and the energy at 50 Hz respectively<br />
* compare amplitudes to decide about presence of 50 Hz signal, e.g. calculate ratio in dB<br />
* use this to count the length of time that a 50 Hz signal is heard (increments of 100 ms or so)<br />
* decide about none / espresso / lungo based on time<br />
<br />
Might even integrate with esphome / home assistant later.<br />
<br />
=== Remote bat box monitor ===<br />
Idea:<br />
* goal: check if remote bat boxes are occupied and identify the species<br />
* challenges:<br />
** connectivity: need to transport images/videos (no LoRaWAN), possibly out of range of mobile data networks<br />
** autonomy: cannot reach the bat box once installed<br />
** power: no fixed power connection, so probably needs a battery + solar panel<br />
* design<br />
** wake up every hour, take a picture, go to sleep, upload photos/videos once per day<br />
** run from batteries, recharge by solar, rules of thumb<br />
*** batteries should last for about 10 days<br />
*** battery should be able to charge in 1 day<br />
*** consider only 10% of peak solar power<br />
** KPN "4G-op-zee" somewhat confusing article: https://www.kpn.com/zakelijk/mobiel/roaming/noordzee<br />
* hardware<br />
** main processor: raspberry pi zero<br />
*** raspberry pi power consumption overview: https://www.pidramble.com/wiki/benchmarks/power-consumption<br />
** this hat to wake up the main CPU: https://www.waveshare.com/wiki/Power_Management_HAT_(B) sold at https://www.kiwi-electronics.com/en/power-management-hat-for-raspberry-pi-with-rtc-and-rp2040-mcu-11373<br />
<br />
=== KNMI API ===<br />
Get familiar with https://developer.dataplatform.knmi.nl/open-data-api<br />
<br />
=== Grid frequency measurer with web page ===<br />
See https://github.com/bertrik/GridFrequency<br />
SSE source is gridfrequency.local/events<br />
<br />
=== WeAct CH55x board ===<br />
Cheap little boards, using a similar chip as used in USB-serial converters.<br />
<br />
The hardware<br />
https://github.com/WeActStudio/WeActStudio.CH552CoreBoard<br />
<br />
Flashing it:<br />
https://hackaday.io/page/137447-flashing-the-ch552-dev-board-from-the-command-line<br />
<br />
See also:<br />
* https://hackaday.io/project/198238-more-weact-ch5xx<br />
* https://community.platformio.org/t/manually-adding-support-for-ch55x-controller-by-adding-existing-ardunio-core/41138<br />
<br />
=== Zigbee device with esp32 ===<br />
See https://github.com/P-R-O-C-H-Y/arduino-esp32/blob/8169a434c3e46e1bb7711ebcc04f27267db2093c/libraries/ESP32/examples/Zigbee/Zigbee_Light_Bulb/Zigbee_Light_Bulb.ino<br />
<br />
See https://github.com/espressif/arduino-esp32/tree/master/libraries/ESP32/examples/Zigbee<br />
<br />
Espressif32 arduino platform git: https://github.com/platformio/platform-espressif32<br />
<br />
=== Cameratoezicht in Gouda ===<br />
Gemeente Gouda publiceert een lijst van camera's in Gouda, zie<br />
https://gis.gouda.nl/nl/app/Basisviewer_open#!eAGT8uRiNBRy4ZIRYFKSyKkssjJwdzFxNDMz8TKKsLC0cnb0dQ1y5FIByirgkg3xd43ydPYIAQBXGBFm<br />
<br />
Aanmelden (semi-automatisch) bij bijvoorbeeld [https://mapcomplete.org/surveillance Surveillance-under-surveillance] ?<br />
<br />
=== SolarEdge ===<br />
Interact with the solar edge api for PV installations.<br />
<br />
https://developers.solaredge.com/<br />
<br />
See https://github.com/bertrik/solaredge-api<br />
<br />
=== Stookalert ===<br />
Idee: gekleurd lampje dat aangeeft of er op dit moment een stookalert actief is<br />
<br />
Implementatie:<br />
* kijk m.b.v. WiFi locatieservice in welke provincie je je bevindt<br />
* haal JSON op bij https://www.lml.rivm.nl/stookalert/stookalert.json<br />
* toon de bijbehorende kleur op het lampje<br />
<br />
Resources:<br />
* Officiele pagina: https://www.atlasleefomgeving.nl/stookwijzer<br />
* Achterliggende JSON met toestand per provincie: https://www.lml.rivm.nl/stookalert/stookalert.json<br />
* Er moet ook nog ergens een API zijn die fijnmaziger aangeeft wat de toestand is ...<br />
<br />
=== Display of current electricity usage ===<br />
I have a [https://www.zuidwijk.com/product/slimmelezer-plus/ slimme lezer] connected to the P1 port of my smart electricity meter.<br />
The default firmware exposes meter readings using an event stream (SSE) at http://slimmelezer.local/events<br />
<br />
So for example, you can read this with curl:<br />
curl http://slimmelezer.local/events<br />
With result:<br />
event: state<br />
data: {"id":"sensor-power_consumed_phase_1","value":0.046,"state":"0.046 kW"}<br />
<br />
Specification of SSE: https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream<br />
<br />
What I would like to do is to read these events and control a simple display to display the current usage number.<br />
<br />
=== Participating in ultrasonic sound project ===<br />
https://bat-migration-europe.netlify.app/project/<br />
<br />
Use an audiomoth for this.<br />
<br />
=== ESP32 C3 ===<br />
* [https://www.espressif.com/en/products/socs/esp32-c3 processor page]<br />
* [https://wiki.luatos.com/chips/esp32c3/index.html luatos basic esp32 c3 board]<br />
<br />
=== Flexible LED ticker ===<br />
Ordered a flexible 32x8 RGB LED display:<br />
https://nl.aliexpress.com/item/4001296811800.html<br />
<br />
Matching diffuser to be 3D printed:<br />
https://www.thingiverse.com/thing:1903744<br />
<br />
=== Washing machine API ===<br />
https://tratt.net/laurie/blog/2023/displaying_my_washing_machines_remaining_time_with_curl_jq_pizauth.html<br />
<br />
=== TinyML ===<br />
Investigate TinyML, see https://www.tinyml.org/<br />
Apparently can run on a RP2040 (raspi pi pico).<br />
<br />
https://www.hackster.io/mjrobot/esp32-cam-tinyml-image-classification-fruits-vs-veggies-4ab970<br />
<br />
=== Bat box busy signal ===<br />
My brother built little pyramid 'blinkies': solar cell + Lithium-supercapacitor + harvesting circuit + LED encased in clear expoxy.<br />
<br />
Can we add a low-power PIR sensor to this, and make a blinky that blinks if movement was detected by the PIR in the past hour?<br />
<br />
=== Super tiny RFID ===<br />
See https://www.sparkfun.com/products/16464 an almost sand grain size RFID chip, 1.25mmx1.25mmx0.55mm<br />
<br />
The accompanying reader "M6E Nano" is still quite expensive at $235.95 : https://www.sparkfun.com/products/14066<br />
<br />
Uses the MuRata LXMSJZNCMF-198:<br />
"This product can be used as an ultra small tag and this can be<br />
fit on any metal objects, non-metal objects, as well as<br />
embedding into any objects by glue or adhesive and so on."<br />
<br />
See also: ISO18000-63 and EPC global Gen2(v2)<br />
<br />
Specification:<br />
* https://www.gs1.org/standards/rfid/uhf-air-interface-protocol<br />
<br />
=== TheThingsNetwork-Sondehub bridge ===<br />
Uploads balloon telemetry to sondehub.<br />
<br />
See https://github.com/bertrik/ttnhabbridge/issues/6<br />
<br />
=== Actually smart boiler ===<br />
The boiler for hot water is about half of my electricity bill.<br />
The idea is to use/build a smart switch that switches it on at time when electricity prices are lowest.<br />
<br />
Currently have a "Slimme boiler module" from Eneco, which is *not* actually smart,<br />
since it allows me no control whatsoever when it switches on (besides cutting the power in the meterkast).<br />
For example, it will switch on mid-day when my price is high and eneco's price is low, perhaps good for Eneco, not for me. <br />
Apparently, they even received a [https://nieuws.eneco.nl/slim-apparaatje-bij-boiler-vangt-pieken-wind--en-zonnestroom-op/ subsidy] for this.<br />
<br />
A boiler is a pretty big load, about 3 kW, but it is not inductive.<br />
<br />
Alternatives:<br />
* https://www.shelly.cloud/en-nl/products/product-overview/shelly-plus-1-pm-2-pack/shelly-plus-1-pm<br />
* https://www.solyxenergy.nl/solar-iboost/ to store excess solar energy in hot water, might also be useful for just controlling a boiler to use cheaper rates<br />
* tuya smartplug, like https://www.wifilampkoning.nl/merken-slimme-verlichting/tuya/tuya-enkele-smartplug-met-energiemeting ?<br />
* tuya 20A smart plug: https://nl.aliexpress.com/item/1005003347568206.html<br />
<br />
=== Receiving gas meters ===<br />
Apparently gas meters send gas consumption data to the slimme meter using a wireless link in the 868 MHz band.<br />
Probably just FSK at 38.4, as mentioned here: https://a35.veron.nl/nieuwe-elektra-en-gasmeters/<br />
<br />
Interesting leads:<br />
* https://github.com/stef/smeter<br />
* https://www.rtl-sdr.com/reading-household-wireless-utility-meters-with-an-rtl-sdr-and-plotting-the-data-in-home-automation-software/<br />
* https://github.com/bemasher/rtlamr<br />
<br />
=== Multi-network wifi manager ===<br />
Figure out or create software so that ESP8266/ESP32 wifi manager can use multiple networks to connect (not just one),<br />
so it allowing storing credentials for more than one network. For example, the network at home, the hacker space, at work.<br />
Instead of reconfiguring the wifi manager for each network, you just *add* your credentials (and the existing credentials<br />
are not replaced).<br />
<br />
See https://github.com/folkertvanheusden/M.A.X.X<br />
<br />
Interesting candidates:<br />
* https://registry.platformio.org/libraries/martinverges/ESP32%20Wifi%20Manager wifi manager for ESP32, has a REST API for managing wifi network, but is incomplete in the sense that you need to write your own code (e.g. javascript) to actually *use* its API<br />
* https://github.com/arduino-libraries/Arduino_MultiWiFi is the arduino multi wifi library, to allow connecting to multiple different WiFi networks, but it is not a wifi manager, that starts a captive portal, etc<br />
<br />
=== Automated bat counting ===<br />
Can we automatically count the number of bats from the image of a webcam mounted in a bat colony?<br />
Perhaps using some kind of AI or machine learning algorithm?<br />
<br />
The image in question:<br />
https://stofradar.nl/coenecoop/<br />
<br />
=== Use TheThingsIndoorGateway as Helium/ThingSix hotspot ===<br />
I have a spare TTIG that could perhaps be used as a Helium gateway, investigate what is possible.<br />
<br />
One possiblity is to capture the gateway traffic from the TTN gateway events API, convert uplink data to a format that the Helium network understands and forward it.<br />
I don't really care about the Helium crypto tokens, this is just for fun and science.<br />
<br />
What I definitely can do:<br />
* Capture data from the TTN gateway events API, convert it back to Semtech UP format and forward it somewhere to Helium (just not sure where!)<br />
* See also my https://github.com/bertrik/ttn-gateway-collector project which contains an initial implementation of TTN-to-UDP conversion<br />
<br />
Showstoppers:<br />
* If you want to be a gateway on the Helium network, you have to *pay Helium*! Obviously I don't want that, I just want to share data to improve *their* network. <br />
<br />
Open work:<br />
* Investigate if Helium has an open uplink API for their hotspots, if so study it etc, without paying the gateway fee<br />
* Investigate if Thingsix has an open uplink API for their hotspots, if so study it etc, without paying any gateway fee<br />
* Investigate if Thingsix is just another Helium, with weird crypto money<br />
<br />
Interesting stuff:<br />
* https://docs.helium.com/use-the-network/setup-a-packet-forwarder unfortunately the link to setting up the 'light hotspot client' does not work!<br />
* https://docs.helium.com/mine-hnt/light-hotspots/<br />
* https://thingsix.com/<br />
<br />
=== Adding BLE GATT interface to sensors ===<br />
The GATT specification allows measurement properties to be defined and transferred continuously over Bluetooth low-energy.<br />
<br />
With GATT you can define a collection of properties (e.g. measurement items like temperature/humidity/particulate matter/noise, etc)<br />
organised in a simple structure of a BLE service.<br />
The 'notification' method allows you to basically push the data continuously to a connected host, e.g. a smart phone.<br />
<br />
Services collects characteristic, a characteristic has values with units.<br />
Each of these (service, characteristic, unit) have their own unique "UUID".<br />
This is described in the so-called [https://btprodspecificationrefs.blob.core.windows.net/assigned-values/16-bit%20UUID%20Numbers%20Document.pdf 16-bit UUID numbers document]<br />
<br />
Interesting stuff in GATT:<br />
* See GATT_Specification_Supplement_v5 paragraph 3.151, it has a noise characteristic with 1 dB resolution.<br />
* 0x27C3 is the GATT *unit* for sound pressure<br />
* 0x181A is the GATT environmental sensing *service*, document name "ESP_V1.0.0.pdf"<br />
* 0x2A6E is the GATT Characteristic and Object Type for temperature<br />
* 0x2A6F is the GATT Characteristic and Object Type for humidity<br />
* 0x2BD5 is the GATT Characteristic and Object Type for Particulate Matter - PM1 Concentration<br />
* 0x2BD6 is the GATT Characteristic and Object Type for Particulate Matter - PM2.5 Concentration<br />
* 0x2BD7 is the GATT Characteristic and Object Type for Particulate Matter - PM10 Concentration<br />
* Unfortunately I cannot find a characteristic for carbon-dioxide (CO2) in the BLE GATT unit document<br />
<br />
See also https://programmaticponderings.com/2020/08/04/getting-started-with-bluetooth-low-energy-ble-and-generic-attribute-profile-gatt-specification-for-iot/<br />
<br />
=== Reverse engineering XS-8217 bluetooth air quality meter ===<br />
This is a thing that measures CO2, humidity, temperature, TVOC and formaldehyde.<br />
<br />
See also https://wiki.liutyi.info/display/CO2/ZN-2CO3+Inside<br />
<br />
This teardown looks a lot like my sensor: https://www.youtube.com/watch?v=APnjhMrJChI<br />
Mine contains a "TPM-300A" sensor for measuring VOC.<br />
<br />
It has a bluetooth interface, device name is XS-8217.<br />
It has a BLE GATT profile, with the following services<br />
* service 0xC760<br />
** characteristic 0xC762 (WRITE)<br />
** characteristic 0xC761 (NOTIFY)<br />
*** example data: 0x23 0x06 0x10 0x04 0xF1 0x00 0x23 0x65<br />
*** example data: 0x23 0x08 0x10 0x04 0x01 0x9A 0x00 0x0A 0x00 0x03 0x0E<br />
*** data shown on screen was approximately: CO2=418ppm, HCHO=0.003mg/m3, TVOC=0.013mg/m3, temp=24degC, humi=35%<br />
<br />
So data in the characteristic 0xC761 seems to have a 4 byte constant header:<br />
* 0x23<br />
* length byte<br />
<br />
Then we have for the first message: 0x10 0x04 0xF1 0x00 0x23 0x65<br />
* 0x10 0x04 fixed header<br />
* 0xF1 is temperature in 0.1 degree Celcius most likely (24.1)<br />
* 0x00 is ...<br />
* 0x23 is humidity most likely (35)<br />
* 0x65 is ... checksum perhaps<br />
<br />
And for the second message: 0x10 0x04 0x01 0x9A 0x00 0x0A 0x00 0x03 0x0E<br />
* 0x10 0x04 fixed header<br />
* 0x01 0x9A is the CO2 concentration (410)<br />
* 0x00 0x0A is TVOC most likely (10)<br />
* 0x00 0x03 is HCHO most likely (3)<br />
* 0x0E is ... checksum perhaps<br />
<br />
=== ribbon tweeter for bat audio ===<br />
Someone gave me this idea:<br />
Use a ribbon tweeter like this for playing back bat audio:<br />
<s>https://nl.aliexpress.com/item/4000973201791.html</s><br />
<s>https://nl.aliexpress.com/item/1005002565880660.html</s><br />
https://nl.aliexpress.com/item/1005002635086050.html<br />
<br />
The frequency spectrum shows no sign of dropping off at 20 kHz.<br />
<br />
=== 3d glasses ===<br />
I got some 2nd hand 3d glasses, they look exactly like these ones:<br />
* GH-15 https://www.dhgate.com/product/g15-dlp-3d-active-shutter-glasses-96-144hz/213983026.html<br />
* Sintron https://www.amazon.de/Sintron-Kompatibel-TDG-BT500A-TDG-BT400A-Deutschland/dp/B015PCWMZ8<br />
The common name appears to be "G15-DLP".<br />
<br />
A tear-down here:<br />
* https://blog.danman.eu/3d-shutter-glasses-teardown/<br />
<br />
Interesting documents:<br />
* http://cmst.curtin.edu.au/wp-content/uploads/sites/4/2016/05/2012-28-woods-helliwell-cross-compatibility_of_shutter_glasses.pdf<br />
* http://cmst.curtin.edu.au/local/docs/pubs/2011-17-woods-helliwell-3D-Sync-IR.pdf<br />
<br />
Someone claims he got something to work with some hacks:<br />
https://www.avsforum.com/threads/how-i-got-cheap-dlp-link-glasses-to-work-great.1887145/<br />
<br />
=== Waterniveaumeter ===<br />
Op verschillende plekken in Gouda staat er water in de kruipruimte van huizen van bewoners.<br />
Kunnen we dat meten en inzichtelijk maken, voor bewoners, op een kaart bijvoorbeeld?<br />
<br />
Idee:<br />
* in de kruipruimte plaats je een module die waterhoogte kan meten<br />
* de module bestaat uit een microcontroller en een afstandsmeter, die de waterhoogte bepaalt<br />
* de gegevens worden via WiFi doorgestuurd naar een centraal punt, waar de data wordt verwerkt en gevisualiseerd<br />
* op een webpagina kan je een overzicht zien van alle meters die online zijn<br />
* de meting wordt gedaan door bijv. een laser-afstandsmeter of een ultrasoon-afstandsmeter<br />
* voeding? lastig, hoe krijg je 5v naar een potentieel natte plek?<br />
* kosten? verwachting < E 40,-<br />
<br />
In Gouda wordt op veel verschillende plekken de grondwaterstand gemeten, zie https://opendata.munisense.net/portal/wareco-water2/group/581/Gouda-KJ38A , maar:<br />
* geen visualisatie op de kaart, je ziet alleen de meetlokaties d.m.v. een icoontje!<br />
* geen meetpunten in Gouda noord!<br />
<br />
=== Online bat detector ===<br />
Idea: use an ultrasonic microphone, connect it to a WebSDR, so people can tune into bat sounds remotely.<br />
<br />
=== Raspberry pi airplane tracking ===<br />
Apparently now you can also participate in MLAT tracking of planes that don't transmit GPS coordinates themselves.<br />
<br />
=== APRS gateway ===<br />
http://qso365.co.uk/2017/02/a-guide-to-setting-up-an-aprs-receive-only-igate-using-a-raspberry-pi-and-an-rtl-sdr-dongle/<br />
<br />
=== JQ6500 ===<br />
Small inexpensive modules that play mp3 from an internal flash. Could be nice for a custom door bell for example.<br />
<br />
More info at: <br />
* https://www.elecfreaks.com/wiki/index.php?title=JQ6500_Mini_MP3_Module<br />
* https://sparks.gogo.co.nz/jq6500/index.html<br />
<br />
=== FPGA ===<br />
Cheap FPGA boards and nice applications:<br />
* https://bitbucket.org/appanp/artificial-neural-networks/wiki/Home/FPGAsAndNeuralNets.md#!sbcs-and-iot-boards <br />
* [http://nl.aliexpress.com/item/Altera-fpga-cycloneii-ep2c5t144-learning-board-development-board/872520721.html inexpensive ep2c5t144 board] <br />
* http://land-boards.com/blwiki/index.php?title=Cyclone_II_EP2C5_Mini_Dev_Board<br />
<br />
=== Neural networks on low-end hardware ===<br />
Investigate if you can run a powerful neural network on relatively low-end/cheap/low-power hardware. For example a Raspberry pi.<br />
A RPI runs Linux, run python, just like some common neural frameworks.<br />
Do we need hardware acceleration from the GPU and does the RPI GPU support that?<br />
<br />
Read list:<br />
* https://www.zdnet.com/pictures/raspberry-pi-meets-ai-the-projects-that-put-machine-learning-on-the-35-board/<br />
* https://www.pyimagesearch.com/2017/12/18/keras-deep-learning-raspberry-pi/<br />
* https://www.indiegogo.com/projects/sipeed-maix-the-world-first-risc-v-64-ai-module#/<br />
* https://ai.intel.com/intel-neural-compute-stick-2-smarter-faster-plug-and-play-ai-at-the-edge/<br />
<br />
Bought a MaixPy:<br />
* see https://maixpy.sipeed.com/en/<br />
* see https://www.youtube.com/watch?v=KResVuAIMb4<br />
* see http://educ8s.tv/sipeed-m1-dock-review/<br />
* interesting? https://www.instructables.com/id/Transfer-Learning-With-Sipeed-MaiX-and-Arduino-IDE/<br />
<br />
=== mini word clock in dutch ===<br />
Basically an monochrome 8x8 word clock, in Dutch, showing local time in the Netherlands.<br />
<br />
[https://github.com/bertrik/miniwordclock This git repo] has the current code.<br />
<br />
See [https://plus.google.com/103276078656203197145/posts/7ki7rpJzk3a here for a demo] running on an arduino nano.<br />
<br />
The plan is to run this from an ESP8266 instead of an arduino nano, so it can get the time from the internet using NTP.<br />
Andreas Spiess demonstrated on youtube how existing libraries on the ESP8266 can be used to do the local time (including summer-time) calculations.<br />
<br />
=== Cypress PSOC5 ===<br />
Play with the Cypress PSOC5 platform, which combines a ARM Cortex-m3 processor with configurable analog blocks. I'm thinking of combining it with a 24 GHz doppler radar sensor, to process the signal and present it as a USB audio device (stereo signal contains I and Q parts). See [[RadarOnAStick]].<br />
<br />
=== Simple Doppler motion sensors ===<br />
You can find basic doppler microwave motion sensors based on a single transistor, with some weird traces on the PCB very cheaply, for example<br />
* https://www.aliexpress.com/item/RCWL-0516-microwave-radar-sensor-module-Human-body-induction-switch-module-Intelligent-sensor/32708877914.html<br />
<br />
Typically the microwave part of these consists of a single transistor with a rectangular area on one leg and a meandering trace (with lots of vias to the other side) on the other leg.<br />
The output of this circuit seems to go into a chip very much like the ones used in PIR sensors.<br />
<br />
See also https://github.com/jdesbonnet/RCWL-0516 for a reverse engineering effort of these doppler radar modules.<br />
<br />
=== Bare-bones Arduino bat detector ===<br />
This is an idea for a very basic heterodyne bat detector, doing signal processing on an Arduino, requiring minimal external components.<br />
<br />
The basic principle of a heterodyne detector is that it just mixes (multiplies) the audio signal with a square wave, low-pass filters the result and puts it on a speaker.<br />
<br />
Multiplying with a square wave can also be considered to be just alternatively inverting and not-inverting the signal.<br />
So if you sample an ultrasonic signal at twice the rate you want to multiply, you can just subtract odd samples from even samples and low-pass filter that.<br />
<br />
How this can be done in an AVR Arduino:<br />
* sample the audio signal at twice the detection frequency, say 84 kHz. An AVR should just be able to do that.<br />
* apply a 1-pole IIR high-pass filter to remove DC bias, this takes one shift instruction and one addition.<br />
* multiply by the detection frequency, this means just inverting the odd samples.<br />
* low-pass filter the signal, this can be done using a moving average filter, say 16 samples long (first null at 5.25 kHz). Theoretically, averaging 16 samples should result in two bits extra accuracy. This operation takes some storage, an addition and a subtraction.<br />
* output the filtered signal using PWM, possibly at the same rate that we are sampling the input audio.<br />
<br />
The microphone can be a 40 kHz piezo transducer, to keep it cheap (but also limited to 40 kHz).<br />
The pre-amplifier can be a single transistor with some resistors around it, providing about 40x gain.<br />
The arduino does the signal processing (mixing, low-pass filter) to shift the bat audio to human range.<br />
The speaker amplifier can just be a simple two transistor push-pull circuit, since the output from the Arduino is digital/PWM.<br />
<br />
==== AVR Arduino sample rate ====<br />
As far as I understand, the ADC clock can be set to 1 MHz.<br />
Conversion takes 13 cycles, so this can be a problem to reach a sample rate above 80 kHz.<br />
<br />
=== Indoor radar speed sign ===<br />
This idea about placing a simple IQ-output radar sensor indoors in the hacker space, do some basic signal processing on the IQ doppler signal and determine movement speed and direction, then display this on a LED display.<br />
This is of no immediate practical use other than fun, but helps me to gain a bit more experience with microwave radar sensors and eventually build a more effective setup for detecting/counting bats flying in and out of a roost.<br />
<br />
Implement this on a PSOC5 platform or on the STM32 using Arduino.</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=User:Bertrik_Sikken&diff=35212User:Bertrik Sikken2026-04-18T11:08:46Z<p>Bertrik Sikken: /* Project ideas */</p>
<hr />
<div>{{Smoel<br />
|Name=Bertrik Sikken<br />
|Nick=bertrik<br />
|Tagline=heb ik niet<br />
}}<br />
<br />
You can reach me at [mailto:bertrik@sikken.nl bertrik@sikken.nl] or [mailto:bertrik@gmail.com bertrik@gmail.com].<br />
<br />
Studied Electrical Engineering at Twente University.<br />
<br />
<br />
Main interests:<br />
* reverse-engineering things (USB stuff, mp3 players), worked on http://rockbox.org (sansa clip players)<br />
* studying bats and making electronics for recording/listening to bat sounds<br />
* radio stuff, in particular software-defined radio, LoRa networks<br />
* citizen science and open data (particulate matter measurement, noise, water quality)<br />
* energy-related stuff, visualisation<br />
<br />
Projects I work(ed) on ([https://revspace.nl/index.php?title=User:Bertrik_Sikken&action=purge refresh]):<br />
{{#ask:[[Category:Project]][[Project Contact::bertrik]]<br />
|?Project Status<br />
|headers=show<br />
|link=all<br />
|order=ASC,ASC<br />
|sort=Project Status,Project Name<br />
}}<br />
<br />
<br />
== Project ideas ==<br />
[[File:always10oclock.jpg|right]]<br />
[[File:idea.jpg|right]]<br />
<br />
This is a list of ideas I'm thinking about, but have not fully developed into an actual project yet.<br />
<br />
https://pine64.com/product/128mb-ox64-sbc-available-on-december-2-2022/<br />
<br />
=== Action 32x32 display ===<br />
Action sells an ACT1026 display. You control it over BLE.<br />
<br />
* https://github.com/Pupariaa/Bk-Light-AppBypass works to control it<br />
<br />
=== investigate thread/matter ===<br />
Matter/thread is the new IKEA standard for home automation thins apparently. <br />
Thread is the wireless protocol, matter is a home automation protocol running on top of thread.<br />
<br />
I have a couple of nrf52840, these are good in doing thread.<br />
<br />
Next steps:<br />
* check out openthread<br />
<pre><br />
git clone https://github.com/openthread/openthread.git<br />
cd openthread<br />
git submodule update --init --recursive<br />
</pre><br />
* Prepare development environment:<br />
scripts/bootstrap<br />
* Build it:<br />
./script/build nrf52840 UART_trans -DOT_LOG_LEVEL=OT_LOG_LEVEL_INFO<br />
<br />
Thread on ESP32:<br />
* on ESP32 C6 https://gist.github.com/gtxaspec/d26198daadfb0a8b0a0edeae2d3fd58f<br />
* https://github.com/espressif/esp-thread-br<br />
* https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_rcp<br />
<br />
=== action lsc stekker ===<br />
https://keetsupport.nl/2024/03/20/how-to-flash-lsc-power-plug-with-esphome/<br />
<br />
https://community.home-assistant.io/t/detailed-guide-on-how-to-flash-the-new-tuya-beken-chips-with-openbk7231t/437276<br />
<br />
=== sipeed maix dock ===<br />
Bought this a couple of years ago. Get familiar with this board.<br />
Can I run a chess program on this, for example?<br />
<br />
* https://wiki.sipeed.com/soft/maixpy/en/develop_kit_board/maix_dock.html<br />
<br />
=== rfid keyfob ===<br />
* aliexpress page: https://nl.aliexpress.com/item/1005009569496736.html<br />
* firmware github: <br />
** https://github.com/RfidResearchGroup/ChameleonUltra<br />
** https://github.com/GameTec-live/ChameleonUltraGUI<br />
<br />
=== advanced lidars for bat detection ===<br />
livox:<br />
* github page https://github.com/Livox-SDK/Livox-SDK/tree/master<br />
* web page: https://www.livoxtech.com/<br />
<br />
=== cubecell meshtastic motion detector ===<br />
I have a cubecell AB01 board.<br />
This board is focused on low power, has a connection to attach a solar panel and has a lora radio.<br />
Relatively small amount of RAM, barely enough to run a LoRaWAN stack but probably plenty to run meshtastic<br />
<br />
The plan is to build a simple motion detector from this (using a PIR).<br />
The PIR can wake up the board from low-power, or a timer can wake it periodically.<br />
<br />
See also: https://github.com/HelTecAutomation/CubeCell-Arduino/tree/master/libraries/Basics/examples/LowPower<br />
<br />
=== configure multitech outdoor gateway ===<br />
https://www.multitech.net/developer/products/multiconnect-conduit-platform/basestation/<br />
<br />
https://multitech.com/product/multitech-conduit-mtcdt-246a-868-eu-gb/<br />
<br />
emergency procedure:<br />
https://www.multitech.net/developer/software/mlinux/using-mlinux/flashing-mlinux-firmware-for-conduit/<br />
<br />
=== esp32 wtf ===<br />
* https://forum.arduino.cc/t/ttgo-lilygo-lora-esp32-26mhz-problem/1353750<br />
* "26 MHz crystal has been deprecated" https://github.com/espressif/arduino-esp32/issues/10117<br />
<br />
=== kakofonie counter ===<br />
Sample room audio, use neural network to distinguish voices to estimate number of people talking in the past 30 seconds or so.<br />
Show this number on some kind of display, publish it to MQTT, make a nice graph of it.<br />
<br />
Stuff to figure out:<br />
* this is called 'speaker diarization'<br />
* can it run on an ESP32?<br />
* make a prototype<br />
<br />
=== hypno toad ===<br />
Put these LEDS https://nl.aliexpress.com/item/1005007583528891.html into https://www.action.com/nl-nl/p/2560347/solar-tuinbeeldje/<br />
<br />
Turns out that the default circuit is really basic and output a rough step-up waveform to the LED.<br />
The self-fading LEDs don't work very well with that.<br />
<br />
Also, putting some IPA on hotglue makes it release really easy.<br />
<br />
=== wasbeer / kat classifier ===<br />
ESP32 with resnet50 neural net to distinguish house cats from other animals, see also:<br />
* https://ieeexplore.ieee.org/document/10556848/<br />
<br />
=== Nespresso brew counter ===<br />
Several hacker spaces have one of these Nespresso cup coffee makers, but there's no obvious easy way to monitor usage (monitor ALL the things!).<br />
Inspired by https://hackaday.com/2021/04/25/arduino-mkr-makes-nespresso-monitoring-easy/ this idea is making an even simpler nespresso monitor,<br />
using an inexpensive WiFi enabled ESP8266 with an ubiquitous I2S microphone such as the INMP441. <br />
<br />
Use this sound monitoring project:<br />
https://github.com/aleiei/ESP8266-BUG-I2S-MIC<br />
and turn it into a WiFi connected brew counter.<br />
<br />
Software for getting microphone data from an ESP8266/I2S mic into Linux https://github.com/bertrik/EspMicServer<br />
Nespresso sound is typically 50 Hz with overtones.<br />
In a recording with the ESP8266, it appears that oddly the 17th harmonic (around 850 Hz) is quite strong.<br />
<br />
The plan in the short term is this:<br />
* apply a gentle IIR filter to subtract any DC bias from the microphone signal<br />
* calculate autocovariance at offsets 0 and 20 ms (inverse of 50 Hz), representing the total energy and the energy at 50 Hz respectively<br />
* compare amplitudes to decide about presence of 50 Hz signal, e.g. calculate ratio in dB<br />
* use this to count the length of time that a 50 Hz signal is heard (increments of 100 ms or so)<br />
* decide about none / espresso / lungo based on time<br />
<br />
Might even integrate with esphome / home assistant later.<br />
<br />
=== Remote bat box monitor ===<br />
Idea:<br />
* goal: check if remote bat boxes are occupied and identify the species<br />
* challenges:<br />
** connectivity: need to transport images/videos (no LoRaWAN), possibly out of range of mobile data networks<br />
** autonomy: cannot reach the bat box once installed<br />
** power: no fixed power connection, so probably needs a battery + solar panel<br />
* design<br />
** wake up every hour, take a picture, go to sleep, upload photos/videos once per day<br />
** run from batteries, recharge by solar, rules of thumb<br />
*** batteries should last for about 10 days<br />
*** battery should be able to charge in 1 day<br />
*** consider only 10% of peak solar power<br />
** KPN "4G-op-zee" somewhat confusing article: https://www.kpn.com/zakelijk/mobiel/roaming/noordzee<br />
* hardware<br />
** main processor: raspberry pi zero<br />
*** raspberry pi power consumption overview: https://www.pidramble.com/wiki/benchmarks/power-consumption<br />
** this hat to wake up the main CPU: https://www.waveshare.com/wiki/Power_Management_HAT_(B) sold at https://www.kiwi-electronics.com/en/power-management-hat-for-raspberry-pi-with-rtc-and-rp2040-mcu-11373<br />
<br />
=== KNMI API ===<br />
Get familiar with https://developer.dataplatform.knmi.nl/open-data-api<br />
<br />
=== Grid frequency measurer with web page ===<br />
See https://github.com/bertrik/GridFrequency<br />
SSE source is gridfrequency.local/events<br />
<br />
=== WeAct CH55x board ===<br />
Cheap little boards, using a similar chip as used in USB-serial converters.<br />
<br />
The hardware<br />
https://github.com/WeActStudio/WeActStudio.CH552CoreBoard<br />
<br />
Flashing it:<br />
https://hackaday.io/page/137447-flashing-the-ch552-dev-board-from-the-command-line<br />
<br />
See also:<br />
* https://hackaday.io/project/198238-more-weact-ch5xx<br />
* https://community.platformio.org/t/manually-adding-support-for-ch55x-controller-by-adding-existing-ardunio-core/41138<br />
<br />
=== Zigbee device with esp32 ===<br />
See https://github.com/P-R-O-C-H-Y/arduino-esp32/blob/8169a434c3e46e1bb7711ebcc04f27267db2093c/libraries/ESP32/examples/Zigbee/Zigbee_Light_Bulb/Zigbee_Light_Bulb.ino<br />
<br />
See https://github.com/espressif/arduino-esp32/tree/master/libraries/ESP32/examples/Zigbee<br />
<br />
Espressif32 arduino platform git: https://github.com/platformio/platform-espressif32<br />
<br />
=== Cameratoezicht in Gouda ===<br />
Gemeente Gouda publiceert een lijst van camera's in Gouda, zie<br />
https://gis.gouda.nl/nl/app/Basisviewer_open#!eAGT8uRiNBRy4ZIRYFKSyKkssjJwdzFxNDMz8TKKsLC0cnb0dQ1y5FIByirgkg3xd43ydPYIAQBXGBFm<br />
<br />
Aanmelden (semi-automatisch) bij bijvoorbeeld [https://mapcomplete.org/surveillance Surveillance-under-surveillance] ?<br />
<br />
=== SolarEdge ===<br />
Interact with the solar edge api for PV installations.<br />
<br />
https://developers.solaredge.com/<br />
<br />
See https://github.com/bertrik/solaredge-api<br />
<br />
=== Stookalert ===<br />
Idee: gekleurd lampje dat aangeeft of er op dit moment een stookalert actief is<br />
<br />
Implementatie:<br />
* kijk m.b.v. WiFi locatieservice in welke provincie je je bevindt<br />
* haal JSON op bij https://www.lml.rivm.nl/stookalert/stookalert.json<br />
* toon de bijbehorende kleur op het lampje<br />
<br />
Resources:<br />
* Officiele pagina: https://www.atlasleefomgeving.nl/stookwijzer<br />
* Achterliggende JSON met toestand per provincie: https://www.lml.rivm.nl/stookalert/stookalert.json<br />
* Er moet ook nog ergens een API zijn die fijnmaziger aangeeft wat de toestand is ...<br />
<br />
=== Display of current electricity usage ===<br />
I have a [https://www.zuidwijk.com/product/slimmelezer-plus/ slimme lezer] connected to the P1 port of my smart electricity meter.<br />
The default firmware exposes meter readings using an event stream (SSE) at http://slimmelezer.local/events<br />
<br />
So for example, you can read this with curl:<br />
curl http://slimmelezer.local/events<br />
With result:<br />
event: state<br />
data: {"id":"sensor-power_consumed_phase_1","value":0.046,"state":"0.046 kW"}<br />
<br />
Specification of SSE: https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream<br />
<br />
What I would like to do is to read these events and control a simple display to display the current usage number.<br />
<br />
=== Participating in ultrasonic sound project ===<br />
https://bat-migration-europe.netlify.app/project/<br />
<br />
Use an audiomoth for this.<br />
<br />
=== ESP32 C3 ===<br />
* [https://www.espressif.com/en/products/socs/esp32-c3 processor page]<br />
* [https://wiki.luatos.com/chips/esp32c3/index.html luatos basic esp32 c3 board]<br />
<br />
=== Flexible LED ticker ===<br />
Ordered a flexible 32x8 RGB LED display:<br />
https://nl.aliexpress.com/item/4001296811800.html<br />
<br />
Matching diffuser to be 3D printed:<br />
https://www.thingiverse.com/thing:1903744<br />
<br />
=== Washing machine API ===<br />
https://tratt.net/laurie/blog/2023/displaying_my_washing_machines_remaining_time_with_curl_jq_pizauth.html<br />
<br />
=== TinyML ===<br />
Investigate TinyML, see https://www.tinyml.org/<br />
Apparently can run on a RP2040 (raspi pi pico).<br />
<br />
https://www.hackster.io/mjrobot/esp32-cam-tinyml-image-classification-fruits-vs-veggies-4ab970<br />
<br />
=== Bat box busy signal ===<br />
My brother built little pyramid 'blinkies': solar cell + Lithium-supercapacitor + harvesting circuit + LED encased in clear expoxy.<br />
<br />
Can we add a low-power PIR sensor to this, and make a blinky that blinks if movement was detected by the PIR in the past hour?<br />
<br />
=== Super tiny RFID ===<br />
See https://www.sparkfun.com/products/16464 an almost sand grain size RFID chip, 1.25mmx1.25mmx0.55mm<br />
<br />
The accompanying reader "M6E Nano" is still quite expensive at $235.95 : https://www.sparkfun.com/products/14066<br />
<br />
Uses the MuRata LXMSJZNCMF-198:<br />
"This product can be used as an ultra small tag and this can be<br />
fit on any metal objects, non-metal objects, as well as<br />
embedding into any objects by glue or adhesive and so on."<br />
<br />
See also: ISO18000-63 and EPC global Gen2(v2)<br />
<br />
Specification:<br />
* https://www.gs1.org/standards/rfid/uhf-air-interface-protocol<br />
<br />
=== TheThingsNetwork-Sondehub bridge ===<br />
Uploads balloon telemetry to sondehub.<br />
<br />
See https://github.com/bertrik/ttnhabbridge/issues/6<br />
<br />
=== Actually smart boiler ===<br />
The boiler for hot water is about half of my electricity bill.<br />
The idea is to use/build a smart switch that switches it on at time when electricity prices are lowest.<br />
<br />
Currently have a "Slimme boiler module" from Eneco, which is *not* actually smart,<br />
since it allows me no control whatsoever when it switches on (besides cutting the power in the meterkast).<br />
For example, it will switch on mid-day when my price is high and eneco's price is low, perhaps good for Eneco, not for me. <br />
Apparently, they even received a [https://nieuws.eneco.nl/slim-apparaatje-bij-boiler-vangt-pieken-wind--en-zonnestroom-op/ subsidy] for this.<br />
<br />
A boiler is a pretty big load, about 3 kW, but it is not inductive.<br />
<br />
Alternatives:<br />
* https://www.shelly.cloud/en-nl/products/product-overview/shelly-plus-1-pm-2-pack/shelly-plus-1-pm<br />
* https://www.solyxenergy.nl/solar-iboost/ to store excess solar energy in hot water, might also be useful for just controlling a boiler to use cheaper rates<br />
* tuya smartplug, like https://www.wifilampkoning.nl/merken-slimme-verlichting/tuya/tuya-enkele-smartplug-met-energiemeting ?<br />
* tuya 20A smart plug: https://nl.aliexpress.com/item/1005003347568206.html<br />
<br />
=== Receiving gas meters ===<br />
Apparently gas meters send gas consumption data to the slimme meter using a wireless link in the 868 MHz band.<br />
Probably just FSK at 38.4, as mentioned here: https://a35.veron.nl/nieuwe-elektra-en-gasmeters/<br />
<br />
Interesting leads:<br />
* https://github.com/stef/smeter<br />
* https://www.rtl-sdr.com/reading-household-wireless-utility-meters-with-an-rtl-sdr-and-plotting-the-data-in-home-automation-software/<br />
* https://github.com/bemasher/rtlamr<br />
<br />
=== Multi-network wifi manager ===<br />
Figure out or create software so that ESP8266/ESP32 wifi manager can use multiple networks to connect (not just one),<br />
so it allowing storing credentials for more than one network. For example, the network at home, the hacker space, at work.<br />
Instead of reconfiguring the wifi manager for each network, you just *add* your credentials (and the existing credentials<br />
are not replaced).<br />
<br />
See https://github.com/folkertvanheusden/M.A.X.X<br />
<br />
Interesting candidates:<br />
* https://registry.platformio.org/libraries/martinverges/ESP32%20Wifi%20Manager wifi manager for ESP32, has a REST API for managing wifi network, but is incomplete in the sense that you need to write your own code (e.g. javascript) to actually *use* its API<br />
* https://github.com/arduino-libraries/Arduino_MultiWiFi is the arduino multi wifi library, to allow connecting to multiple different WiFi networks, but it is not a wifi manager, that starts a captive portal, etc<br />
<br />
=== Automated bat counting ===<br />
Can we automatically count the number of bats from the image of a webcam mounted in a bat colony?<br />
Perhaps using some kind of AI or machine learning algorithm?<br />
<br />
The image in question:<br />
https://stofradar.nl/coenecoop/<br />
<br />
=== Use TheThingsIndoorGateway as Helium/ThingSix hotspot ===<br />
I have a spare TTIG that could perhaps be used as a Helium gateway, investigate what is possible.<br />
<br />
One possiblity is to capture the gateway traffic from the TTN gateway events API, convert uplink data to a format that the Helium network understands and forward it.<br />
I don't really care about the Helium crypto tokens, this is just for fun and science.<br />
<br />
What I definitely can do:<br />
* Capture data from the TTN gateway events API, convert it back to Semtech UP format and forward it somewhere to Helium (just not sure where!)<br />
* See also my https://github.com/bertrik/ttn-gateway-collector project which contains an initial implementation of TTN-to-UDP conversion<br />
<br />
Showstoppers:<br />
* If you want to be a gateway on the Helium network, you have to *pay Helium*! Obviously I don't want that, I just want to share data to improve *their* network. <br />
<br />
Open work:<br />
* Investigate if Helium has an open uplink API for their hotspots, if so study it etc, without paying the gateway fee<br />
* Investigate if Thingsix has an open uplink API for their hotspots, if so study it etc, without paying any gateway fee<br />
* Investigate if Thingsix is just another Helium, with weird crypto money<br />
<br />
Interesting stuff:<br />
* https://docs.helium.com/use-the-network/setup-a-packet-forwarder unfortunately the link to setting up the 'light hotspot client' does not work!<br />
* https://docs.helium.com/mine-hnt/light-hotspots/<br />
* https://thingsix.com/<br />
<br />
=== Adding BLE GATT interface to sensors ===<br />
The GATT specification allows measurement properties to be defined and transferred continuously over Bluetooth low-energy.<br />
<br />
With GATT you can define a collection of properties (e.g. measurement items like temperature/humidity/particulate matter/noise, etc)<br />
organised in a simple structure of a BLE service.<br />
The 'notification' method allows you to basically push the data continuously to a connected host, e.g. a smart phone.<br />
<br />
Services collects characteristic, a characteristic has values with units.<br />
Each of these (service, characteristic, unit) have their own unique "UUID".<br />
This is described in the so-called [https://btprodspecificationrefs.blob.core.windows.net/assigned-values/16-bit%20UUID%20Numbers%20Document.pdf 16-bit UUID numbers document]<br />
<br />
Interesting stuff in GATT:<br />
* See GATT_Specification_Supplement_v5 paragraph 3.151, it has a noise characteristic with 1 dB resolution.<br />
* 0x27C3 is the GATT *unit* for sound pressure<br />
* 0x181A is the GATT environmental sensing *service*, document name "ESP_V1.0.0.pdf"<br />
* 0x2A6E is the GATT Characteristic and Object Type for temperature<br />
* 0x2A6F is the GATT Characteristic and Object Type for humidity<br />
* 0x2BD5 is the GATT Characteristic and Object Type for Particulate Matter - PM1 Concentration<br />
* 0x2BD6 is the GATT Characteristic and Object Type for Particulate Matter - PM2.5 Concentration<br />
* 0x2BD7 is the GATT Characteristic and Object Type for Particulate Matter - PM10 Concentration<br />
* Unfortunately I cannot find a characteristic for carbon-dioxide (CO2) in the BLE GATT unit document<br />
<br />
See also https://programmaticponderings.com/2020/08/04/getting-started-with-bluetooth-low-energy-ble-and-generic-attribute-profile-gatt-specification-for-iot/<br />
<br />
=== Reverse engineering XS-8217 bluetooth air quality meter ===<br />
This is a thing that measures CO2, humidity, temperature, TVOC and formaldehyde.<br />
<br />
See also https://wiki.liutyi.info/display/CO2/ZN-2CO3+Inside<br />
<br />
This teardown looks a lot like my sensor: https://www.youtube.com/watch?v=APnjhMrJChI<br />
Mine contains a "TPM-300A" sensor for measuring VOC.<br />
<br />
It has a bluetooth interface, device name is XS-8217.<br />
It has a BLE GATT profile, with the following services<br />
* service 0xC760<br />
** characteristic 0xC762 (WRITE)<br />
** characteristic 0xC761 (NOTIFY)<br />
*** example data: 0x23 0x06 0x10 0x04 0xF1 0x00 0x23 0x65<br />
*** example data: 0x23 0x08 0x10 0x04 0x01 0x9A 0x00 0x0A 0x00 0x03 0x0E<br />
*** data shown on screen was approximately: CO2=418ppm, HCHO=0.003mg/m3, TVOC=0.013mg/m3, temp=24degC, humi=35%<br />
<br />
So data in the characteristic 0xC761 seems to have a 4 byte constant header:<br />
* 0x23<br />
* length byte<br />
<br />
Then we have for the first message: 0x10 0x04 0xF1 0x00 0x23 0x65<br />
* 0x10 0x04 fixed header<br />
* 0xF1 is temperature in 0.1 degree Celcius most likely (24.1)<br />
* 0x00 is ...<br />
* 0x23 is humidity most likely (35)<br />
* 0x65 is ... checksum perhaps<br />
<br />
And for the second message: 0x10 0x04 0x01 0x9A 0x00 0x0A 0x00 0x03 0x0E<br />
* 0x10 0x04 fixed header<br />
* 0x01 0x9A is the CO2 concentration (410)<br />
* 0x00 0x0A is TVOC most likely (10)<br />
* 0x00 0x03 is HCHO most likely (3)<br />
* 0x0E is ... checksum perhaps<br />
<br />
=== ribbon tweeter for bat audio ===<br />
Someone gave me this idea:<br />
Use a ribbon tweeter like this for playing back bat audio:<br />
<s>https://nl.aliexpress.com/item/4000973201791.html</s><br />
<s>https://nl.aliexpress.com/item/1005002565880660.html</s><br />
https://nl.aliexpress.com/item/1005002635086050.html<br />
<br />
The frequency spectrum shows no sign of dropping off at 20 kHz.<br />
<br />
=== 3d glasses ===<br />
I got some 2nd hand 3d glasses, they look exactly like these ones:<br />
* GH-15 https://www.dhgate.com/product/g15-dlp-3d-active-shutter-glasses-96-144hz/213983026.html<br />
* Sintron https://www.amazon.de/Sintron-Kompatibel-TDG-BT500A-TDG-BT400A-Deutschland/dp/B015PCWMZ8<br />
The common name appears to be "G15-DLP".<br />
<br />
A tear-down here:<br />
* https://blog.danman.eu/3d-shutter-glasses-teardown/<br />
<br />
Interesting documents:<br />
* http://cmst.curtin.edu.au/wp-content/uploads/sites/4/2016/05/2012-28-woods-helliwell-cross-compatibility_of_shutter_glasses.pdf<br />
* http://cmst.curtin.edu.au/local/docs/pubs/2011-17-woods-helliwell-3D-Sync-IR.pdf<br />
<br />
Someone claims he got something to work with some hacks:<br />
https://www.avsforum.com/threads/how-i-got-cheap-dlp-link-glasses-to-work-great.1887145/<br />
<br />
=== Waterniveaumeter ===<br />
Op verschillende plekken in Gouda staat er water in de kruipruimte van huizen van bewoners.<br />
Kunnen we dat meten en inzichtelijk maken, voor bewoners, op een kaart bijvoorbeeld?<br />
<br />
Idee:<br />
* in de kruipruimte plaats je een module die waterhoogte kan meten<br />
* de module bestaat uit een microcontroller en een afstandsmeter, die de waterhoogte bepaalt<br />
* de gegevens worden via WiFi doorgestuurd naar een centraal punt, waar de data wordt verwerkt en gevisualiseerd<br />
* op een webpagina kan je een overzicht zien van alle meters die online zijn<br />
* de meting wordt gedaan door bijv. een laser-afstandsmeter of een ultrasoon-afstandsmeter<br />
* voeding? lastig, hoe krijg je 5v naar een potentieel natte plek?<br />
* kosten? verwachting < E 40,-<br />
<br />
In Gouda wordt op veel verschillende plekken de grondwaterstand gemeten, zie https://opendata.munisense.net/portal/wareco-water2/group/581/Gouda-KJ38A , maar:<br />
* geen visualisatie op de kaart, je ziet alleen de meetlokaties d.m.v. een icoontje!<br />
* geen meetpunten in Gouda noord!<br />
<br />
=== Online bat detector ===<br />
Idea: use an ultrasonic microphone, connect it to a WebSDR, so people can tune into bat sounds remotely.<br />
<br />
=== Raspberry pi airplane tracking ===<br />
Apparently now you can also participate in MLAT tracking of planes that don't transmit GPS coordinates themselves.<br />
<br />
=== APRS gateway ===<br />
http://qso365.co.uk/2017/02/a-guide-to-setting-up-an-aprs-receive-only-igate-using-a-raspberry-pi-and-an-rtl-sdr-dongle/<br />
<br />
=== JQ6500 ===<br />
Small inexpensive modules that play mp3 from an internal flash. Could be nice for a custom door bell for example.<br />
<br />
More info at: <br />
* https://www.elecfreaks.com/wiki/index.php?title=JQ6500_Mini_MP3_Module<br />
* https://sparks.gogo.co.nz/jq6500/index.html<br />
<br />
=== FPGA ===<br />
Cheap FPGA boards and nice applications:<br />
* https://bitbucket.org/appanp/artificial-neural-networks/wiki/Home/FPGAsAndNeuralNets.md#!sbcs-and-iot-boards <br />
* [http://nl.aliexpress.com/item/Altera-fpga-cycloneii-ep2c5t144-learning-board-development-board/872520721.html inexpensive ep2c5t144 board] <br />
* http://land-boards.com/blwiki/index.php?title=Cyclone_II_EP2C5_Mini_Dev_Board<br />
<br />
=== Neural networks on low-end hardware ===<br />
Investigate if you can run a powerful neural network on relatively low-end/cheap/low-power hardware. For example a Raspberry pi.<br />
A RPI runs Linux, run python, just like some common neural frameworks.<br />
Do we need hardware acceleration from the GPU and does the RPI GPU support that?<br />
<br />
Read list:<br />
* https://www.zdnet.com/pictures/raspberry-pi-meets-ai-the-projects-that-put-machine-learning-on-the-35-board/<br />
* https://www.pyimagesearch.com/2017/12/18/keras-deep-learning-raspberry-pi/<br />
* https://www.indiegogo.com/projects/sipeed-maix-the-world-first-risc-v-64-ai-module#/<br />
* https://ai.intel.com/intel-neural-compute-stick-2-smarter-faster-plug-and-play-ai-at-the-edge/<br />
<br />
Bought a MaixPy:<br />
* see https://maixpy.sipeed.com/en/<br />
* see https://www.youtube.com/watch?v=KResVuAIMb4<br />
* see http://educ8s.tv/sipeed-m1-dock-review/<br />
* interesting? https://www.instructables.com/id/Transfer-Learning-With-Sipeed-MaiX-and-Arduino-IDE/<br />
<br />
=== mini word clock in dutch ===<br />
Basically an monochrome 8x8 word clock, in Dutch, showing local time in the Netherlands.<br />
<br />
[https://github.com/bertrik/miniwordclock This git repo] has the current code.<br />
<br />
See [https://plus.google.com/103276078656203197145/posts/7ki7rpJzk3a here for a demo] running on an arduino nano.<br />
<br />
The plan is to run this from an ESP8266 instead of an arduino nano, so it can get the time from the internet using NTP.<br />
Andreas Spiess demonstrated on youtube how existing libraries on the ESP8266 can be used to do the local time (including summer-time) calculations.<br />
<br />
=== Cypress PSOC5 ===<br />
Play with the Cypress PSOC5 platform, which combines a ARM Cortex-m3 processor with configurable analog blocks. I'm thinking of combining it with a 24 GHz doppler radar sensor, to process the signal and present it as a USB audio device (stereo signal contains I and Q parts). See [[RadarOnAStick]].<br />
<br />
=== Simple Doppler motion sensors ===<br />
You can find basic doppler microwave motion sensors based on a single transistor, with some weird traces on the PCB very cheaply, for example<br />
* https://www.aliexpress.com/item/RCWL-0516-microwave-radar-sensor-module-Human-body-induction-switch-module-Intelligent-sensor/32708877914.html<br />
<br />
Typically the microwave part of these consists of a single transistor with a rectangular area on one leg and a meandering trace (with lots of vias to the other side) on the other leg.<br />
The output of this circuit seems to go into a chip very much like the ones used in PIR sensors.<br />
<br />
See also https://github.com/jdesbonnet/RCWL-0516 for a reverse engineering effort of these doppler radar modules.<br />
<br />
=== Bare-bones Arduino bat detector ===<br />
This is an idea for a very basic heterodyne bat detector, doing signal processing on an Arduino, requiring minimal external components.<br />
<br />
The basic principle of a heterodyne detector is that it just mixes (multiplies) the audio signal with a square wave, low-pass filters the result and puts it on a speaker.<br />
<br />
Multiplying with a square wave can also be considered to be just alternatively inverting and not-inverting the signal.<br />
So if you sample an ultrasonic signal at twice the rate you want to multiply, you can just subtract odd samples from even samples and low-pass filter that.<br />
<br />
How this can be done in an AVR Arduino:<br />
* sample the audio signal at twice the detection frequency, say 84 kHz. An AVR should just be able to do that.<br />
* apply a 1-pole IIR high-pass filter to remove DC bias, this takes one shift instruction and one addition.<br />
* multiply by the detection frequency, this means just inverting the odd samples.<br />
* low-pass filter the signal, this can be done using a moving average filter, say 16 samples long (first null at 5.25 kHz). Theoretically, averaging 16 samples should result in two bits extra accuracy. This operation takes some storage, an addition and a subtraction.<br />
* output the filtered signal using PWM, possibly at the same rate that we are sampling the input audio.<br />
<br />
The microphone can be a 40 kHz piezo transducer, to keep it cheap (but also limited to 40 kHz).<br />
The pre-amplifier can be a single transistor with some resistors around it, providing about 40x gain.<br />
The arduino does the signal processing (mixing, low-pass filter) to shift the bat audio to human range.<br />
The speaker amplifier can just be a simple two transistor push-pull circuit, since the output from the Arduino is digital/PWM.<br />
<br />
==== AVR Arduino sample rate ====<br />
As far as I understand, the ADC clock can be set to 1 MHz.<br />
Conversion takes 13 cycles, so this can be a problem to reach a sample rate above 80 kHz.<br />
<br />
=== Indoor radar speed sign ===<br />
This idea about placing a simple IQ-output radar sensor indoors in the hacker space, do some basic signal processing on the IQ doppler signal and determine movement speed and direction, then display this on a LED display.<br />
This is of no immediate practical use other than fun, but helps me to gain a bit more experience with microwave radar sensors and eventually build a more effective setup for detecting/counting bats flying in and out of a roost.<br />
<br />
Implement this on a PSOC5 platform or on the STM32 using Arduino.</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35177Meshcore-sensor-net2026-03-25T12:07:14Z<p>Bertrik Sikken: /* Progress */</p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=In progress<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used for meshcore almost universally in the Netherlands now is the EU/UK setting:<br />
* 869.618 / SF8 / BW62.5 / CR8<br />
* explicit header, CRC enabled<br />
* sync word 0x12<br />
<br />
Description of the on-the-air message:<br />
* General description: https://gist.github.com/recrof/ca7ccff28c43d1b6bf7e55ce5159100b<br />
* Dissection code: https://github.com/folkertvanheusden/meshcore-store/blob/master/utils/dissect.py<br />
* Meshcore source: https://github.com/meshcore-dev/MeshCore/tree/main/src<br />
* https://jacksbrain.com/2026/01/a-hitchhiker-s-guide-to-meshcore-cryptography/<br />
<br />
Meshcore repeaters are relatively "dumb", they just forward anything that resembles a packet (they dont't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Progress ==<br />
Done so far:<br />
* I understand the meshcore packet structure<br />
* Using an stm32wle5 board (has an sx1262-like built in), we can send a valid group-data packet which is understood by repeaters and repeated<br />
* Initial Arduino gateway code for an esp32-s3 seeed board<br />
<br />
Todo:<br />
* Write the backend part: listen to MQTT and respond with a valid packet<br />
* Process the backend packet on the sensor node<br />
<br />
== Investigation ==<br />
<br />
=== Meshcore security ===<br />
<br />
The 16-byte channel key is derived from the channel name, as follows:<br />
key = hashlib.sha256(name.encode('utf-8')).digest()[0:16]<br />
where 'name' is the channel name, including the '#'<br />
<br />
The 1-byte channel hash is derived from the channel key, as follows:<br />
hash = hashlib.sha256(key).digest()[0]<br />
where 'key' is the byte array containing the key<br />
<br />
Encryption of the payload is done using the key:<br />
* Payload is padded with 0 to multiple of 16<br />
* Encrypted using AES-128 ECB (!) mode, initialised with the key<br />
<br />
The 2-byte MAC is calculated over the *encrypted* payload, using the key:<br />
mac = sha256-hmac(payload)[0:2]<br />
<br />
== Design ==<br />
<br />
=== Communication scheme ===<br />
The sensor sends measurements.<br />
The backend returns ACKs, with preferred path information to reach a gateway.<br />
Not every measurement is ACKed, to keep traffic down (like LoRaWAN does), but only every x messages (say 16).<br />
<br />
Escalation ladder when the sensor misses ACKs (or when the path to the gateway is lost):<br />
* When expecting ACKs, just send couple more (re)tries along the last known path, e.g. enable a kind of 'ACK wanted' flag<br />
* On start-up, try a quick-start with a zero-hop direct message, to probe if the gateway is perhaps within range of the sensor<br />
* On start-up, if the quick-start did not work, send a flood message (with larger network impact)<br />
To be worked out further.<br />
<br />
=== Packet structure ===<br />
The plan is to use payload type "PAYLOAD_TYPE_GRP_DATA".<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type PAYLOAD_TYPE_GRP_DATA + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* Channel hash: 1 byte<br />
* MAC: 2 bytes, according to PAYLOAD_TYPE_GRP_DATA format<br />
* Encrypted payload: citizen science payload structure, encrypted with key derived from "channel name" (e.g. '#sensornet')<br />
<br />
Citizen science payload structure (big endian):<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The PAYLOAD_TYPE_GRP_DATA payload follows the meshcore structure: 2-byte MAC + encrypted payload<br />
* The citizen science data is not secret, it is encrypted with a key derived from the channel name (e.g. '#sensornet'), but we do add a cryptographic checksum to recognize authentic messages belonging to a specific application and device<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Blake2s hash with key (32-bytes)<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash to use as the MAC<br />
* The hash key itself calculated, as follows:<br />
** Blake2s hash with key, where key = application secret<br />
** Fields included in hash: application name, deviceid (big endian)<br />
* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). Only the generated hash key is written to non-volatile storage of the sensor.<br />
<br />
In short:<br />
* Citizen science data is extended with a blake2s 4-byte MAC, based on the deviceid and a counter, calculated using a application/device-specific key<br />
* Citizen science data is encrypted on the meshcore level using AES128 (CBC mode) with a key based on the meshcore channel name<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35176Meshcore-sensor-net2026-03-25T12:06:15Z<p>Bertrik Sikken: /* Introduction */</p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=In progress<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used for meshcore almost universally in the Netherlands now is the EU/UK setting:<br />
* 869.618 / SF8 / BW62.5 / CR8<br />
* explicit header, CRC enabled<br />
* sync word 0x12<br />
<br />
Description of the on-the-air message:<br />
* General description: https://gist.github.com/recrof/ca7ccff28c43d1b6bf7e55ce5159100b<br />
* Dissection code: https://github.com/folkertvanheusden/meshcore-store/blob/master/utils/dissect.py<br />
* Meshcore source: https://github.com/meshcore-dev/MeshCore/tree/main/src<br />
* https://jacksbrain.com/2026/01/a-hitchhiker-s-guide-to-meshcore-cryptography/<br />
<br />
Meshcore repeaters are relatively "dumb", they just forward anything that resembles a packet (they dont't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Progress ==<br />
Done so far:<br />
* I understand the meshcore packet structure<br />
* Using an stm32wle5 board (has an sx1262-like built in), we can send a valid group-data packet which is understood by repeaters and repeated<br />
<br />
Todo:<br />
* Implement the gateway part, the plan is to use a S3/SX1262 seeed board.<br />
* Write the backend part: listen to MQTT and respond with a valid packet<br />
* Process the backend packet on the sensor node<br />
<br />
== Investigation ==<br />
<br />
=== Meshcore security ===<br />
<br />
The 16-byte channel key is derived from the channel name, as follows:<br />
key = hashlib.sha256(name.encode('utf-8')).digest()[0:16]<br />
where 'name' is the channel name, including the '#'<br />
<br />
The 1-byte channel hash is derived from the channel key, as follows:<br />
hash = hashlib.sha256(key).digest()[0]<br />
where 'key' is the byte array containing the key<br />
<br />
Encryption of the payload is done using the key:<br />
* Payload is padded with 0 to multiple of 16<br />
* Encrypted using AES-128 ECB (!) mode, initialised with the key<br />
<br />
The 2-byte MAC is calculated over the *encrypted* payload, using the key:<br />
mac = sha256-hmac(payload)[0:2]<br />
<br />
== Design ==<br />
<br />
=== Communication scheme ===<br />
The sensor sends measurements.<br />
The backend returns ACKs, with preferred path information to reach a gateway.<br />
Not every measurement is ACKed, to keep traffic down (like LoRaWAN does), but only every x messages (say 16).<br />
<br />
Escalation ladder when the sensor misses ACKs (or when the path to the gateway is lost):<br />
* When expecting ACKs, just send couple more (re)tries along the last known path, e.g. enable a kind of 'ACK wanted' flag<br />
* On start-up, try a quick-start with a zero-hop direct message, to probe if the gateway is perhaps within range of the sensor<br />
* On start-up, if the quick-start did not work, send a flood message (with larger network impact)<br />
To be worked out further.<br />
<br />
=== Packet structure ===<br />
The plan is to use payload type "PAYLOAD_TYPE_GRP_DATA".<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type PAYLOAD_TYPE_GRP_DATA + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* Channel hash: 1 byte<br />
* MAC: 2 bytes, according to PAYLOAD_TYPE_GRP_DATA format<br />
* Encrypted payload: citizen science payload structure, encrypted with key derived from "channel name" (e.g. '#sensornet')<br />
<br />
Citizen science payload structure (big endian):<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The PAYLOAD_TYPE_GRP_DATA payload follows the meshcore structure: 2-byte MAC + encrypted payload<br />
* The citizen science data is not secret, it is encrypted with a key derived from the channel name (e.g. '#sensornet'), but we do add a cryptographic checksum to recognize authentic messages belonging to a specific application and device<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Blake2s hash with key (32-bytes)<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash to use as the MAC<br />
* The hash key itself calculated, as follows:<br />
** Blake2s hash with key, where key = application secret<br />
** Fields included in hash: application name, deviceid (big endian)<br />
* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). Only the generated hash key is written to non-volatile storage of the sensor.<br />
<br />
In short:<br />
* Citizen science data is extended with a blake2s 4-byte MAC, based on the deviceid and a counter, calculated using a application/device-specific key<br />
* Citizen science data is encrypted on the meshcore level using AES128 (CBC mode) with a key based on the meshcore channel name<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35175Meshcore-sensor-net2026-03-23T12:08:22Z<p>Bertrik Sikken: /* Packet structure */</p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=In progress<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used for meshcore almost universally in the Netherlands now is the EU/UK setting:<br />
* 869.618 / SF8 / BW62.5 / CR8<br />
* explicit header, CRC enabled<br />
* sync word 0x12<br />
<br />
Description of the on-the-air message:<br />
* General description: https://gist.github.com/recrof/ca7ccff28c43d1b6bf7e55ce5159100b<br />
* Dissection code: https://github.com/folkertvanheusden/meshcore-store/blob/master/utils/dissect.py<br />
* Meshcore source: https://github.com/meshcore-dev/MeshCore/tree/main/src<br />
* https://jacksbrain.com/2026/01/a-hitchhiker-s-guide-to-meshcore-cryptography/<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Progress ==<br />
Done so far:<br />
* I understand the meshcore packet structure<br />
* Using an stm32wle5 board (has an sx1262-like built in), we can send a valid group-data packet which is understood by repeaters and repeated<br />
<br />
Todo:<br />
* Implement the gateway part, the plan is to use a S3/SX1262 seeed board.<br />
* Write the backend part: listen to MQTT and respond with a valid packet<br />
* Process the backend packet on the sensor node<br />
<br />
== Investigation ==<br />
<br />
=== Meshcore security ===<br />
<br />
The 16-byte channel key is derived from the channel name, as follows:<br />
key = hashlib.sha256(name.encode('utf-8')).digest()[0:16]<br />
where 'name' is the channel name, including the '#'<br />
<br />
The 1-byte channel hash is derived from the channel key, as follows:<br />
hash = hashlib.sha256(key).digest()[0]<br />
where 'key' is the byte array containing the key<br />
<br />
Encryption of the payload is done using the key:<br />
* Payload is padded with 0 to multiple of 16<br />
* Encrypted using AES-128 ECB (!) mode, initialised with the key<br />
<br />
The 2-byte MAC is calculated over the *encrypted* payload, using the key:<br />
mac = sha256-hmac(payload)[0:2]<br />
<br />
== Design ==<br />
<br />
=== Communication scheme ===<br />
The sensor sends measurements.<br />
The backend returns ACKs, with preferred path information to reach a gateway.<br />
Not every measurement is ACKed, to keep traffic down (like LoRaWAN does), but only every x messages (say 16).<br />
<br />
Escalation ladder when the sensor misses ACKs (or when the path to the gateway is lost):<br />
* When expecting ACKs, just send couple more (re)tries along the last known path, e.g. enable a kind of 'ACK wanted' flag<br />
* On start-up, try a quick-start with a zero-hop direct message, to probe if the gateway is perhaps within range of the sensor<br />
* On start-up, if the quick-start did not work, send a flood message (with larger network impact)<br />
To be worked out further.<br />
<br />
=== Packet structure ===<br />
The plan is to use payload type "PAYLOAD_TYPE_GRP_DATA".<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type PAYLOAD_TYPE_GRP_DATA + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* Channel hash: 1 byte<br />
* MAC: 2 bytes, according to PAYLOAD_TYPE_GRP_DATA format<br />
* Encrypted payload: citizen science payload structure, encrypted with key derived from "channel name" (e.g. '#sensornet')<br />
<br />
Citizen science payload structure (big endian):<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The PAYLOAD_TYPE_GRP_DATA payload follows the meshcore structure: 2-byte MAC + encrypted payload<br />
* The citizen science data is not secret, it is encrypted with a key derived from the channel name (e.g. '#sensornet'), but we do add a cryptographic checksum to recognize authentic messages belonging to a specific application and device<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Blake2s hash with key (32-bytes)<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash to use as the MAC<br />
* The hash key itself calculated, as follows:<br />
** Blake2s hash with key, where key = application secret<br />
** Fields included in hash: application name, deviceid (big endian)<br />
* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). Only the generated hash key is written to non-volatile storage of the sensor.<br />
<br />
In short:<br />
* Citizen science data is extended with a blake2s 4-byte MAC, based on the deviceid and a counter, calculated using a application/device-specific key<br />
* Citizen science data is encrypted on the meshcore level using AES128 (CBC mode) with a key based on the meshcore channel name<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35173Meshcore-sensor-net2026-03-19T12:23:31Z<p>Bertrik Sikken: </p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=In progress<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used for meshcore almost universally in the Netherlands now is the EU/UK setting:<br />
* 869.618 / SF8 / BW62.5 / CR8<br />
* explicit header, CRC enabled<br />
* sync word 0x12<br />
<br />
Description of the on-the-air message:<br />
* General description: https://gist.github.com/recrof/ca7ccff28c43d1b6bf7e55ce5159100b<br />
* Dissection code: https://github.com/folkertvanheusden/meshcore-store/blob/master/utils/dissect.py<br />
* Meshcore source: https://github.com/meshcore-dev/MeshCore/tree/main/src<br />
* https://jacksbrain.com/2026/01/a-hitchhiker-s-guide-to-meshcore-cryptography/<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Progress ==<br />
Done so far:<br />
* I understand the meshcore packet structure<br />
* Using an stm32wle5 board (has an sx1262-like built in), we can send a valid group-data packet which is understood by repeaters and repeated<br />
<br />
Todo:<br />
* Implement the gateway part, the plan is to use a S3/SX1262 seeed board.<br />
* Write the backend part: listen to MQTT and respond with a valid packet<br />
* Process the backend packet on the sensor node<br />
<br />
== Investigation ==<br />
<br />
=== Meshcore security ===<br />
<br />
The 16-byte channel key is derived from the channel name, as follows:<br />
key = hashlib.sha256(name.encode('utf-8')).digest()[0:16]<br />
where 'name' is the channel name, including the '#'<br />
<br />
The 1-byte channel hash is derived from the channel key, as follows:<br />
hash = hashlib.sha256(key).digest()[0]<br />
where 'key' is the byte array containing the key<br />
<br />
Encryption of the payload is done using the key:<br />
* Payload is padded with 0 to multiple of 16<br />
* Encrypted using AES-128 ECB (!) mode, initialised with the key<br />
<br />
The 2-byte MAC is calculated over the *encrypted* payload, using the key:<br />
mac = sha256-hmac(payload)[0:2]<br />
<br />
== Design ==<br />
<br />
=== Communication scheme ===<br />
The sensor sends measurements.<br />
The backend returns ACKs, with preferred path information to reach a gateway.<br />
Not every measurement is ACKed, to keep traffic down (like LoRaWAN does), but only every x messages (say 16).<br />
<br />
Escalation ladder when the sensor misses ACKs (or when the path to the gateway is lost):<br />
* When expecting ACKs, just send couple more (re)tries along the last known path, e.g. enable a kind of 'ACK wanted' flag<br />
* On start-up, try a quick-start with a zero-hop direct message, to probe if the gateway is perhaps within range of the sensor<br />
* On start-up, if the quick-start did not work, send a flood message (with larger network impact)<br />
To be worked out further.<br />
<br />
=== Packet structure ===<br />
The plan is to use payload type "PAYLOAD_TYPE_GRP_DATA".<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type PAYLOAD_TYPE_GRP_DATA + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* Channel hash: 1 byte<br />
* MAC: 2 bytes, according to PAYLOAD_TYPE_GRP_DATA format<br />
* Encrypted payload: citizen science payload structure, encrypted with key derived from "channel name" (e.g. '#sensornet')<br />
<br />
Citizen science payload structure (big endian):<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The PAYLOAD_TYPE_GRP_DATA payload follows the meshcore structure: 2-byte MAC + encrypted payload<br />
* The citizen science data is not secret, it is encrypted with a key derived from the channel name (e.g. '#sensornet'), but we do add a cryptographic checksum to recognize authentic messages belonging to a specific application and device<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Blake2s hash with key (32-bytes)<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash to use as the MAC<br />
* The hash key itself calculated, as follows:<br />
** Blake2s hash with key, where key = application secret<br />
** Fields included in hash: application name, deviceid (big endian)<br />
* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). Only the generated hash key is written to non-volatile storage of the sensor.<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35172Meshcore-sensor-net2026-03-16T12:15:41Z<p>Bertrik Sikken: /* Packet structure */</p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=In progress<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used for meshcore almost universally in the Netherlands now is the EU/UK setting:<br />
* 869.618 / SF8 / BW62.5 / CR8<br />
* explicit header, CRC enabled<br />
* sync word 0x12<br />
<br />
Description of the on-the-air message:<br />
* General description: https://gist.github.com/recrof/ca7ccff28c43d1b6bf7e55ce5159100b<br />
* Dissection code: https://github.com/folkertvanheusden/meshcore-store/blob/master/utils/dissect.py<br />
* Meshcore source: https://github.com/meshcore-dev/MeshCore/tree/main/src<br />
* https://jacksbrain.com/2026/01/a-hitchhiker-s-guide-to-meshcore-cryptography/<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Investigation ==<br />
<br />
=== Meshcore security ===<br />
<br />
The 16-byte channel key is derived from the channel name, as follows:<br />
key = hashlib.sha256(name.encode('utf-8')).digest()[0:16]<br />
where 'name' is the channel name, including the '#'<br />
<br />
The 1-byte channel hash is derived from the channel key, as follows:<br />
hash = hashlib.sha256(key).digest()[0]<br />
where 'key' is the byte array containing the key<br />
<br />
Encryption of the payload is done using the key:<br />
* Payload is padded with 0 to multiple of 16<br />
* Encrypted using AES-128 ECB (!) mode, initialised with the key<br />
<br />
The 2-byte MAC is calculated over the *encrypted* payload, using the key:<br />
mac = sha256-hmac(payload)[0:2]<br />
<br />
== Design ==<br />
<br />
=== Communication scheme ===<br />
The sensor sends measurements.<br />
The backend returns ACKs, with preferred path information to reach a gateway.<br />
Not every measurement is ACKed, to keep traffic down (like LoRaWAN does), but only every x messages (say 16).<br />
<br />
Escalation ladder when the sensor misses ACKs (or when the path to the gateway is lost):<br />
* When expecting ACKs, just send couple more (re)tries along the last known path, e.g. enable a kind of 'ACK wanted' flag<br />
* On start-up, try a quick-start with a zero-hop direct message, to probe if the gateway is perhaps within range of the sensor<br />
* On start-up, if the quick-start did not work, send a flood message (with larger network impact)<br />
To be worked out further.<br />
<br />
=== Packet structure ===<br />
The plan is to use payload type "PAYLOAD_TYPE_GRP_DATA".<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type PAYLOAD_TYPE_GRP_DATA + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* Channel hash: 1 byte<br />
* MAC: 2 bytes, according to PAYLOAD_TYPE_GRP_DATA format<br />
* Encrypted payload: citizen science payload structure, encrypted with key derived from "channel name" (e.g. '#sensornet')<br />
<br />
Citizen science payload structure (big endian):<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The PAYLOAD_TYPE_GRP_DATA payload follows the meshcore structure: 2-byte MAC + encrypted payload<br />
* The citizen science data is not secret, it is encrypted with a key derived from the channel name (e.g. '#sensornet'), but we do add a cryptographic checksum to recognize authentic messages belonging to a specific application and device<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Blake2s hash with key (32-bytes)<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash to use as the MAC<br />
* The hash key itself calculated, as follows:<br />
** Blake2s hash with key, where key = application secret<br />
** Fields included in hash: application name, deviceid (big endian)<br />
* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). Only the generated hash key is written to non-volatile storage of the sensor.<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35171Meshcore-sensor-net2026-03-16T12:14:37Z<p>Bertrik Sikken: /* Packet structure */</p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=In progress<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used for meshcore almost universally in the Netherlands now is the EU/UK setting:<br />
* 869.618 / SF8 / BW62.5 / CR8<br />
* explicit header, CRC enabled<br />
* sync word 0x12<br />
<br />
Description of the on-the-air message:<br />
* General description: https://gist.github.com/recrof/ca7ccff28c43d1b6bf7e55ce5159100b<br />
* Dissection code: https://github.com/folkertvanheusden/meshcore-store/blob/master/utils/dissect.py<br />
* Meshcore source: https://github.com/meshcore-dev/MeshCore/tree/main/src<br />
* https://jacksbrain.com/2026/01/a-hitchhiker-s-guide-to-meshcore-cryptography/<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Investigation ==<br />
<br />
=== Meshcore security ===<br />
<br />
The 16-byte channel key is derived from the channel name, as follows:<br />
key = hashlib.sha256(name.encode('utf-8')).digest()[0:16]<br />
where 'name' is the channel name, including the '#'<br />
<br />
The 1-byte channel hash is derived from the channel key, as follows:<br />
hash = hashlib.sha256(key).digest()[0]<br />
where 'key' is the byte array containing the key<br />
<br />
Encryption of the payload is done using the key:<br />
* Payload is padded with 0 to multiple of 16<br />
* Encrypted using AES-128 ECB (!) mode, initialised with the key<br />
<br />
The 2-byte MAC is calculated over the *encrypted* payload, using the key:<br />
mac = sha256-hmac(payload)[0:2]<br />
<br />
== Design ==<br />
<br />
=== Communication scheme ===<br />
The sensor sends measurements.<br />
The backend returns ACKs, with preferred path information to reach a gateway.<br />
Not every measurement is ACKed, to keep traffic down (like LoRaWAN does), but only every x messages (say 16).<br />
<br />
Escalation ladder when the sensor misses ACKs (or when the path to the gateway is lost):<br />
* When expecting ACKs, just send couple more (re)tries along the last known path, e.g. enable a kind of 'ACK wanted' flag<br />
* On start-up, try a quick-start with a zero-hop direct message, to probe if the gateway is perhaps within range of the sensor<br />
* On start-up, if the quick-start did not work, send a flood message (with larger network impact)<br />
To be worked out further.<br />
<br />
=== Packet structure ===<br />
The plan is to use payload type "PAYLOAD_TYPE_GRP_DATA".<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type PAYLOAD_TYPE_GRP_DATA + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* Channel hash: 1 byte<br />
* MAC: 2 bytes, according to PAYLOAD_TYPE_GRP_DATA format<br />
* Encrypted payload: citizen science payload structure, encrypted with key derived from "channel name" (e.g. '#sensornet')<br />
<br />
Citizen science payload structure (big endian):<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The PAYLOAD_TYPE_GRP_DATA payload follows the meshcore structure: 2-byte MAC + encrypted payload<br />
* The citizen science data is not secret, it is encrypted with a key derived from the channel name (e.g. '#sensornet'), but we do add a cryptographic checksum to recognize authentic messages belonging to a specific application and device<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Blake2s hash with key (32-bytes)<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash to use as the MAC<br />
* The hash key itself calculated, as follows:<br />
** Blake2s hash with key, where key = application secret<br />
** Fields included in hash: application name, deviceid (big endian)<br />
* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). The resulting key is written to non-volatile storage of the sensor.<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35119Meshcore-sensor-net2026-03-06T16:56:02Z<p>Bertrik Sikken: /* Introduction */</p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=In progress<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used for meshcore almost universally in the Netherlands now is the EU/UK setting:<br />
* 869.618 / SF8 / BW62.5 / CR8<br />
* explicit header, CRC enabled<br />
* sync word 0x12<br />
<br />
Description of the on-the-air message:<br />
* General description: https://gist.github.com/recrof/ca7ccff28c43d1b6bf7e55ce5159100b<br />
* Dissection code: https://github.com/folkertvanheusden/meshcore-store/blob/master/utils/dissect.py<br />
* Meshcore source: https://github.com/meshcore-dev/MeshCore/tree/main/src<br />
* https://jacksbrain.com/2026/01/a-hitchhiker-s-guide-to-meshcore-cryptography/<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Investigation ==<br />
<br />
=== Meshcore security ===<br />
<br />
The 16-byte channel key is derived from the channel name, as follows:<br />
key = hashlib.sha256(name.encode('utf-8')).digest()[0:16]<br />
where 'name' is the channel name, including the '#'<br />
<br />
The 1-byte channel hash is derived from the channel key, as follows:<br />
hash = hashlib.sha256(key).digest()[0]<br />
where 'key' is the byte array containing the key<br />
<br />
Encryption of the payload is done using the key:<br />
* Payload is padded with 0 to multiple of 16<br />
* Encrypted using AES-128 ECB (!) mode, initialised with the key<br />
<br />
The 2-byte MAC is calculated over the *encrypted* payload, using the key:<br />
mac = sha256-hmac(payload)[0:2]<br />
<br />
== Design ==<br />
<br />
=== Communication scheme ===<br />
The sensor sends measurements.<br />
The backend returns ACKs, with preferred path information to reach a gateway.<br />
Not every measurement is ACKed, to keep traffic down (like LoRaWAN does), but only every x messages (say 16).<br />
<br />
Escalation ladder when the sensor misses ACKs (or when the path to the gateway is lost):<br />
* When expecting ACKs, just send couple more (re)tries along the last known path, e.g. enable a kind of 'ACK wanted' flag<br />
* On start-up, try a quick-start with a zero-hop direct message, to probe if the gateway is perhaps within range of the sensor<br />
* On start-up, if the quick-start did not work, send a flood message (with larger network impact)<br />
To be worked out further.<br />
<br />
=== Packet structure ===<br />
The plan is to use payload type "PAYLOAD_TYPE_GRP_DATA".<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type PAYLOAD_TYPE_GRP_DATA + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* Channel hash: 1 byte<br />
* MAC: 2 bytes, according to PAYLOAD_TYPE_GRP_DATA format<br />
* Encrypted payload: citizen science payload structure, encrypted with key derived from "channel name" (e.g. '#meshcore-sensor-net')<br />
<br />
Citizen science payload structure (big endian):<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The PAYLOAD_TYPE_GRP_DATA payload follows the meshcore structure: 2-byte MAC + encrypted payload<br />
* The citizen science data is not secret, it is encrypted with a key derived from the channel name (e.g. '#sensornet'), but we do add a cryptographic checksum to recognize authentic messages belonging to a specific application and device<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Blake2s hash with key (32-bytes)<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash to use as the MAC<br />
* The hash key itself calculated, as follows:<br />
** Blake2s hash with key, where key = application secret<br />
** Fields included in hash: application name, deviceid (big endian)<br />
* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). The resulting key is written to non-volatile storage of the sensor.<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35117Meshcore-sensor-net2026-03-05T11:45:45Z<p>Bertrik Sikken: /* Design */</p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=In progress<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used for meshcore almost universally in the Netherlands now is the EU/UK setting:<br />
* 869.618 / SF8 / BW62.5 / CR8<br />
* explicit header, CRC enabled<br />
* sync word 0x12<br />
<br />
Description of the on-the-air message:<br />
* General description: https://gist.github.com/recrof/ca7ccff28c43d1b6bf7e55ce5159100b<br />
* Dissection code: https://github.com/folkertvanheusden/meshcore-store/blob/master/utils/dissect.py<br />
* Meshcore source: https://github.com/meshcore-dev/MeshCore/tree/main/src<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Investigation ==<br />
<br />
=== Meshcore security ===<br />
<br />
The 16-byte channel key is derived from the channel name, as follows:<br />
key = hashlib.sha256(name.encode('utf-8')).digest()[0:16]<br />
where 'name' is the channel name, including the '#'<br />
<br />
The 1-byte channel hash is derived from the channel key, as follows:<br />
hash = hashlib.sha256(key).digest()[0]<br />
where 'key' is the byte array containing the key<br />
<br />
Encryption of the payload is done using the key:<br />
* Payload is padded with 0 to multiple of 16<br />
* Encrypted using AES-128 ECB (!) mode, initialised with the key<br />
<br />
The 2-byte MAC is calculated over the *encrypted* payload, using the key:<br />
mac = sha256-hmac(payload)[0:2]<br />
<br />
== Design ==<br />
<br />
=== Communication scheme ===<br />
The sensor sends measurements.<br />
The backend returns ACKs, with preferred path information to reach a gateway.<br />
Not every measurement is ACKed, to keep traffic down (like LoRaWAN does), but only every x messages (say 16).<br />
<br />
Escalation ladder when the sensor misses ACKs (or when the path to the gateway is lost):<br />
* When expecting ACKs, just send couple more (re)tries along the last known path, e.g. enable a kind of 'ACK wanted' flag<br />
* On start-up, try a quick-start with a zero-hop direct message, to probe if the gateway is perhaps within range of the sensor<br />
* On start-up, if the quick-start did not work, send a flood message (with larger network impact)<br />
To be worked out further.<br />
<br />
=== Packet structure ===<br />
The plan is to use payload type "PAYLOAD_TYPE_GRP_DATA".<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type PAYLOAD_TYPE_GRP_DATA + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* Channel hash: 1 byte<br />
* MAC: 2 bytes, according to PAYLOAD_TYPE_GRP_DATA format<br />
* Encrypted payload: citizen science payload structure, encrypted with key derived from "channel name" (e.g. '#meshcore-sensor-net')<br />
<br />
Citizen science payload structure (big endian):<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The PAYLOAD_TYPE_GRP_DATA payload follows the meshcore structure: 2-byte MAC + encrypted payload<br />
* The citizen science data is not secret, it is encrypted with a key derived from the channel name (e.g. '#sensornet'), but we do add a cryptographic checksum to recognize authentic messages belonging to a specific application and device<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Blake2s hash with key (32-bytes)<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash to use as the MAC<br />
* The hash key itself calculated, as follows:<br />
** Blake2s hash with key, where key = application secret<br />
** Fields included in hash: application name, deviceid (big endian)<br />
* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). The resulting key is written to non-volatile storage of the sensor.<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35112Meshcore-sensor-net2026-03-02T23:21:32Z<p>Bertrik Sikken: /* Meshcore security */</p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=In progress<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used for meshcore almost universally in the Netherlands now is the EU/UK setting:<br />
* 869.618 / SF8 / BW62.5 / CR8<br />
* explicit header, CRC enabled<br />
* sync word 0x12<br />
<br />
Description of the on-the-air message:<br />
* General description: https://gist.github.com/recrof/ca7ccff28c43d1b6bf7e55ce5159100b<br />
* Dissection code: https://github.com/folkertvanheusden/meshcore-store/blob/master/utils/dissect.py<br />
* Meshcore source: https://github.com/meshcore-dev/MeshCore/tree/main/src<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Investigation ==<br />
<br />
=== Meshcore security ===<br />
<br />
The 16-byte channel key is derived from the channel name, as follows:<br />
key = hashlib.sha256(name.encode('utf-8')).digest()[0:16]<br />
where 'name' is the channel name, including the '#'<br />
<br />
The 1-byte channel hash is derived from the channel key, as follows:<br />
hash = hashlib.sha256(key).digest()[0]<br />
where 'key' is the byte array containing the key<br />
<br />
Encryption of the payload is done using the key:<br />
* Payload is padded with 0 to multiple of 16<br />
* Encrypted using AES-128 ECB (!) mode, initialised with the key<br />
<br />
The 2-byte MAC is calculated over the *encrypted* payload, using the key:<br />
mac = sha256-hmac(payload)[0:2]<br />
<br />
== Design ==<br />
The plan is to use payload type "PAYLOAD_TYPE_GRP_DATA".<br />
Initially flood mode, normally direct mode.<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type PAYLOAD_TYPE_GRP_DATA + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* Channel hash: 1 byte<br />
* MAC: 2 bytes, according to PAYLOAD_TYPE_GRP_DATA format<br />
* Encrypted payload: citizen science payload structure, encrypted with key derived from "channel name" (e.g. '#meshcore-sensor-net')<br />
<br />
Citizen science payload structure:<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The PAYLOAD_TYPE_GRP_DATA payload follows the meshcore structure: 2-byte MAC + encrypted payload<br />
* The citizen science data is not secret, it is encrypted with a key derived from the channel name ('#meshcore-sensor-net'), but we do add a cryptographic checksum to recognize authentic messages belonging to a specific application and device<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Blake2s hash with key (32-bytes)<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash<br />
* The hash key itself also calculated as follows:<br />
** Blake2s hash with key, where key = application secret<br />
** Fields included in hash: application name, deviceid<br />
* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). The resulting key is written to non-volatile storage of the sensor.<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35111Meshcore-sensor-net2026-03-02T20:31:06Z<p>Bertrik Sikken: /* Meshcore security */</p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=In progress<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used for meshcore almost universally in the Netherlands now is the EU/UK setting:<br />
* 869.618 / SF8 / BW62.5 / CR8<br />
* explicit header, CRC enabled<br />
* sync word 0x12<br />
<br />
Description of the on-the-air message:<br />
* General description: https://gist.github.com/recrof/ca7ccff28c43d1b6bf7e55ce5159100b<br />
* Dissection code: https://github.com/folkertvanheusden/meshcore-store/blob/master/utils/dissect.py<br />
* Meshcore source: https://github.com/meshcore-dev/MeshCore/tree/main/src<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Investigation ==<br />
<br />
=== Meshcore security ===<br />
<br />
The 16-byte channel key is derived from the channel name, as follows:<br />
key = hashlib.sha256(name.encode('utf-8')).digest()[0:16]<br />
where 'name' is the channel name, including the '#'<br />
<br />
The 1-byte channel hash is derived from the channel key, as follows:<br />
hash = hashlib.sha256(key).digest()[0]<br />
where 'key' is the byte array containing the key<br />
<br />
Encryption of the payload is done using the key:<br />
* Payload is padded with 0 to multiple of 16<br />
* Encrypted using AES ECB mode, initialised with the key<br />
<br />
The 2-byte MAC is calculated over the *encrypted* payload, using the key:<br />
mac = sha256-hmac(payload)[0:2]<br />
<br />
== Design ==<br />
The plan is to use payload type "PAYLOAD_TYPE_GRP_DATA".<br />
Initially flood mode, normally direct mode.<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type PAYLOAD_TYPE_GRP_DATA + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* Channel hash: 1 byte<br />
* MAC: 2 bytes, according to PAYLOAD_TYPE_GRP_DATA format<br />
* Encrypted payload: citizen science payload structure, encrypted with key derived from "channel name" (e.g. '#meshcore-sensor-net')<br />
<br />
Citizen science payload structure:<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The PAYLOAD_TYPE_GRP_DATA payload follows the meshcore structure: 2-byte MAC + encrypted payload<br />
* The citizen science data is not secret, it is encrypted with a key derived from the channel name ('#meshcore-sensor-net'), but we do add a cryptographic checksum to recognize authentic messages belonging to a specific application and device<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Blake2s hash with key (32-bytes)<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash<br />
* The hash key itself also calculated as follows:<br />
** Blake2s hash with key, where key = application secret<br />
** Fields included in hash: application name, deviceid<br />
* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). The resulting key is written to non-volatile storage of the sensor.<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35110Meshcore-sensor-net2026-03-02T20:03:45Z<p>Bertrik Sikken: /* Investigation */</p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=In progress<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used for meshcore almost universally in the Netherlands now is the EU/UK setting:<br />
* 869.618 / SF8 / BW62.5 / CR8<br />
* explicit header, CRC enabled<br />
* sync word 0x12<br />
<br />
Description of the on-the-air message:<br />
* General description: https://gist.github.com/recrof/ca7ccff28c43d1b6bf7e55ce5159100b<br />
* Dissection code: https://github.com/folkertvanheusden/meshcore-store/blob/master/utils/dissect.py<br />
* Meshcore source: https://github.com/meshcore-dev/MeshCore/tree/main/src<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Investigation ==<br />
<br />
=== Meshcore security ===<br />
<br />
The 16-byte channel key is derived from the channel name, as follows (python code)<br />
key = hashlib.sha256(name.encode('utf-8')).digest()[0:16]<br />
where 'name' is the channel name, including the '#'<br />
<br />
The 1-byte channel hash is derived from the channel key, as follows<br />
hash = hashlib.sha256(key).digest()[0]<br />
where 'key' is the byte array containing the key<br />
<br />
== Design ==<br />
The plan is to use payload type "PAYLOAD_TYPE_GRP_DATA".<br />
Initially flood mode, normally direct mode.<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type PAYLOAD_TYPE_GRP_DATA + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* Channel hash: 1 byte<br />
* MAC: 2 bytes, according to PAYLOAD_TYPE_GRP_DATA format<br />
* Encrypted payload: citizen science payload structure, encrypted with key derived from "channel name" (e.g. '#meshcore-sensor-net')<br />
<br />
Citizen science payload structure:<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The PAYLOAD_TYPE_GRP_DATA payload follows the meshcore structure: 2-byte MAC + encrypted payload<br />
* The citizen science data is not secret, it is encrypted with a key derived from the channel name ('#meshcore-sensor-net'), but we do add a cryptographic checksum to recognize authentic messages belonging to a specific application and device<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Blake2s hash with key (32-bytes)<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash<br />
* The hash key itself also calculated as follows:<br />
** Blake2s hash with key, where key = application secret<br />
** Fields included in hash: application name, deviceid<br />
* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). The resulting key is written to non-volatile storage of the sensor.<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35109Meshcore-sensor-net2026-03-02T17:01:17Z<p>Bertrik Sikken: /* Design */</p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=In progress<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used for meshcore almost universally in the Netherlands now is the EU/UK setting:<br />
* 869.618 / SF8 / BW62.5 / CR8<br />
* explicit header, CRC enabled<br />
* sync word 0x12<br />
<br />
Description of the on-the-air message:<br />
* General description: https://gist.github.com/recrof/ca7ccff28c43d1b6bf7e55ce5159100b<br />
* Dissection code: https://github.com/folkertvanheusden/meshcore-store/blob/master/utils/dissect.py<br />
* Meshcore source: https://github.com/meshcore-dev/MeshCore/tree/main/src<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Investigation ==<br />
<br />
== Design ==<br />
The plan is to use payload type "PAYLOAD_TYPE_GRP_DATA".<br />
Initially flood mode, normally direct mode.<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type PAYLOAD_TYPE_GRP_DATA + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* Channel hash: 1 byte<br />
* MAC: 2 bytes, according to PAYLOAD_TYPE_GRP_DATA format<br />
* Encrypted payload: citizen science payload structure, encrypted with key derived from "channel name" (e.g. '#meshcore-sensor-net')<br />
<br />
Citizen science payload structure:<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The PAYLOAD_TYPE_GRP_DATA payload follows the meshcore structure: 2-byte MAC + encrypted payload<br />
* The citizen science data is not secret, it is encrypted with a key derived from the channel name ('#meshcore-sensor-net'), but we do add a cryptographic checksum to recognize authentic messages belonging to a specific application and device<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Blake2s hash with key (32-bytes)<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash<br />
* The hash key itself also calculated as follows:<br />
** Blake2s hash with key, where key = application secret<br />
** Fields included in hash: application name, deviceid<br />
* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). The resulting key is written to non-volatile storage of the sensor.<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35108Meshcore-sensor-net2026-03-02T16:59:43Z<p>Bertrik Sikken: /* Introduction */</p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=In progress<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used for meshcore almost universally in the Netherlands now is the EU/UK setting:<br />
* 869.618 / SF8 / BW62.5 / CR8<br />
* explicit header, CRC enabled<br />
* sync word 0x12<br />
<br />
Description of the on-the-air message:<br />
* General description: https://gist.github.com/recrof/ca7ccff28c43d1b6bf7e55ce5159100b<br />
* Dissection code: https://github.com/folkertvanheusden/meshcore-store/blob/master/utils/dissect.py<br />
* Meshcore source: https://github.com/meshcore-dev/MeshCore/tree/main/src<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Investigation ==<br />
<br />
== Design ==<br />
The plan is to use payload type "PAYLOAD_TYPE_GRP_DATA".<br />
Initially flood mode, normally direct mode.<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type PAYLOAD_TYPE_GRP_DATA + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* MAC: 2 bytes, according to PAYLOAD_TYPE_GRP_DATA format<br />
* Encrypted payload: citizen science payload structure, encrypted with key derived from "channel name" (e.g. '#meshcore-sensor-net')<br />
<br />
Citizen science payload structure:<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The PAYLOAD_TYPE_GRP_DATA payload follows the meshcore structure: 2-byte MAC + encrypted payload<br />
* The citizen science data is not secret, it is encrypted with a key derived from the channel name ('#meshcore-sensor-net'), but we do add a cryptographic checksum to recognize authentic messages belonging to a specific application and device<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Blake2s hash with key (32-bytes)<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash<br />
* The hash key itself also calculated as follows:<br />
** Blake2s hash with key, where key = application secret<br />
** Fields included in hash: application name, deviceid<br />
* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). The resulting key is written to non-volatile storage of the sensor.<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35107Meshcore-sensor-net2026-03-02T14:27:25Z<p>Bertrik Sikken: /* Design */</p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=In progress<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used for meshcore almost universally in the Netherlands now is the EU/UK setting:<br />
* 869.618 / SF8 / BW62.5 / CR8<br />
* explicit header, CRC enabled<br />
* sync word 0x12<br />
<br />
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<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Investigation ==<br />
<br />
== Design ==<br />
The plan is to use payload type "PAYLOAD_TYPE_GRP_DATA".<br />
Initially flood mode, normally direct mode.<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type PAYLOAD_TYPE_GRP_DATA + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* MAC: 2 bytes, according to PAYLOAD_TYPE_GRP_DATA format<br />
* Encrypted payload: citizen science payload structure, encrypted with key derived from "channel name" (e.g. '#meshcore-sensor-net')<br />
<br />
Citizen science payload structure:<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The PAYLOAD_TYPE_GRP_DATA payload follows the meshcore structure: 2-byte MAC + encrypted payload<br />
* The citizen science data is not secret, it is encrypted with a key derived from the channel name ('#meshcore-sensor-net'), but we do add a cryptographic checksum to recognize authentic messages belonging to a specific application and device<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Blake2s hash with key (32-bytes)<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash<br />
* The hash key itself also calculated as follows:<br />
** Blake2s hash with key, where key = application secret<br />
** Fields included in hash: application name, deviceid<br />
* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). The resulting key is written to non-volatile storage of the sensor.<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35106Meshcore-sensor-net2026-03-02T12:33:21Z<p>Bertrik Sikken: /* Design */</p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=In progress<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used for meshcore almost universally in the Netherlands now is the EU/UK setting:<br />
* 869.618 / SF8 / BW62.5 / CR8<br />
* explicit header, CRC enabled<br />
* sync word 0x12<br />
<br />
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<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Investigation ==<br />
<br />
== Design ==<br />
The plan is to use payload type "PAYLOAD_TYPE_GRP_DATA".<br />
Initially flood mode, normally direct mode.<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type PAYLOAD_TYPE_GRP_DATA + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* MAC: 2 bytes, according to PAYLOAD_TYPE_GRP_DATA format<br />
* Encrypted payload: citizen science payload structure, encrypted with key derived from "channel name" (e.g. '#meshcore-sensor-net')<br />
<br />
Citizen science payload structure:<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The PAYLOAD_TYPE_GRP_DATA payload follows the meshcore structure: 2-byte MAC + encrypted payload<br />
* The citizen science data is not secret, it is encrypted with a key derived from the channel name ('#meshcore-sensor-net'),<br />
but we do add a cryptographic checksum to recognize authentic messages belonging to a specific application<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Blake2s hash with key (32-bytes)<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash<br />
* The hash key itself also calculated as follows:<br />
** Blake2s hash with key, where key = application secret<br />
** Fields included in hash: application name, deviceid<br />
* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). The resulting key is written to non-volatile storage of the sensor.<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35105Meshcore-sensor-net2026-03-02T08:36:58Z<p>Bertrik Sikken: /* Introduction */</p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=In progress<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used for meshcore almost universally in the Netherlands now is the EU/UK setting:<br />
* 869.618 / SF8 / BW62.5 / CR8<br />
* explicit header, CRC enabled<br />
* sync word 0x12<br />
<br />
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<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Investigation ==<br />
<br />
== Design ==<br />
The plan is to use payload type "PAYLOAD_TYPE_GRP_DATA".<br />
Initially flood mode, normally direct mode.<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type PAYLOAD_TYPE_GRP_DATA + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* MAC: 2 bytes, according to PAYLOAD_TYPE_GRP_DATA format<br />
* Encrypted payload: citizen science payload structure, encrypted with key derived from "channel name" (e.g. '#meshcore-sensor-net')<br />
<br />
Citizen science payload structure:<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The PAYLOAD_TYPE_GRP_DATA payload follows the meshcore structure: 2-byte MAC + encrypted payload<br />
* The citizen science data is not secret, but we do add a cryptographic checksum to recognize authentic messages<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Blake2s hash with key (32-bytes)<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash<br />
* The hash key itself also calculated as follows:<br />
** Blake2s hash with key, where key = application secret<br />
** Fields included in hash: application name, deviceid<br />
* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). The resulting key is written to non-volatile storage of the sensor.<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35104Meshcore-sensor-net2026-03-02T08:35:30Z<p>Bertrik Sikken: </p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=In progress<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used almost universally in the Netherlands now is the EU/UK setting:<br />
<br />
869.618 / SF8 / BW62.5 / CR8<br />
header enabled<br />
sync word XXXX<br />
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<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Investigation ==<br />
<br />
== Design ==<br />
The plan is to use payload type "PAYLOAD_TYPE_GRP_DATA".<br />
Initially flood mode, normally direct mode.<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type PAYLOAD_TYPE_GRP_DATA + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* MAC: 2 bytes, according to PAYLOAD_TYPE_GRP_DATA format<br />
* Encrypted payload: citizen science payload structure, encrypted with key derived from "channel name" (e.g. '#meshcore-sensor-net')<br />
<br />
Citizen science payload structure:<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The PAYLOAD_TYPE_GRP_DATA payload follows the meshcore structure: 2-byte MAC + encrypted payload<br />
* The citizen science data is not secret, but we do add a cryptographic checksum to recognize authentic messages<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Blake2s hash with key (32-bytes)<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash<br />
* The hash key itself also calculated as follows:<br />
** Blake2s hash with key, where key = application secret<br />
** Fields included in hash: application name, deviceid<br />
* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). The resulting key is written to non-volatile storage of the sensor.<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35103Meshcore-sensor-net2026-03-02T08:34:52Z<p>Bertrik Sikken: </p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=Initializing<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used almost universally in the Netherlands now is the EU/UK setting:<br />
<br />
869.618 / SF8 / BW62.5 / CR8<br />
header enabled<br />
sync word XXXX<br />
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<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Investigation ==<br />
<br />
== Design ==<br />
The plan is to use payload type "PAYLOAD_TYPE_GRP_DATA".<br />
Initially flood mode, normally direct mode.<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type PAYLOAD_TYPE_GRP_DATA + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* MAC: 2 bytes, according to PAYLOAD_TYPE_GRP_DATA format<br />
* Encrypted payload: citizen science payload structure, encrypted with key derived from "channel name" (e.g. '#meshcore-sensor-net')<br />
<br />
Citizen science payload structure:<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The PAYLOAD_TYPE_GRP_DATA payload follows the meshcore structure: 2-byte MAC + encrypted payload<br />
* The citizen science data is not secret, but we do add a cryptographic checksum to recognize authentic messages<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Blake2s hash with key (32-bytes)<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash<br />
* The hash key itself also calculated as follows:<br />
** Blake2s hash with key, where key = application secret<br />
** Fields included in hash: application name, deviceid<br />
* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). The resulting key is written to non-volatile storage of the sensor.<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35078Meshcore-sensor-net2026-02-25T14:02:18Z<p>Bertrik Sikken: /* Design */</p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=Initializing<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used almost universally in the Netherlands now is the EU/UK setting:<br />
<br />
869.618 / SF8 / BW62.5 / CR8<br />
header enabled<br />
sync word XXXX<br />
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<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Investigation ==<br />
<br />
== Design ==<br />
The plan is to use payload type "RawCustom".<br />
Initially flood mode, normally direct mode.<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type RawCustom + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* Payload: citizen science payload structure<br />
<br />
Citizen science payload structure:<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The citizen science data is not secret, so it is not encrypted, but we do add a cryptographic checksum to recognize authentic messages<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Blake2s hash with key (32-bytes)<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash<br />
* The hash key itself also calculated as follows:<br />
** Blake2s hash with key, where key = application secret<br />
** Fields included in hash: application name, deviceid<br />
* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). The resulting key is written to non-volatile storage of the sensor.<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35077Meshcore-sensor-net2026-02-25T13:51:07Z<p>Bertrik Sikken: /* Design */</p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=Initializing<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used almost universally in the Netherlands now is the EU/UK setting:<br />
<br />
869.618 / SF8 / BW62.5 / CR8<br />
header enabled<br />
sync word XXXX<br />
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<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Investigation ==<br />
<br />
== Design ==<br />
The plan is to use payload type "RawCustom".<br />
Initially flood mode, normally direct mode.<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type RawCustom + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* Payload: citizen science payload structure<br />
<br />
Citizen science payload structure:<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The citizen science data is not secret, so it is not encrypted, but we do add a cryptographic checksum to recognize authentic messages<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Blake2s hash with key (32-bytes)<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash<br />
* The hash key itself is also calculated using blake2s:<br />
** key = blake2s(data = application name || deviceid, key = application secret)<br />
* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). The resulting key is written to non-volatile storage of the sensor.<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35076Meshcore-sensor-net2026-02-23T22:13:42Z<p>Bertrik Sikken: /* Design */</p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=Initializing<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used almost universally in the Netherlands now is the EU/UK setting:<br />
<br />
869.618 / SF8 / BW62.5 / CR8<br />
header enabled<br />
sync word XXXX<br />
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<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Investigation ==<br />
<br />
== Design ==<br />
The plan is to use payload type "RawCustom".<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type RawCustom + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* Payload: citizen science payload structure<br />
<br />
Citizen science payload structure:<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The citizen science data is not secret, so it is not encrypted, but we do add a cryptographic checksum to recognize authentic messages<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Keyed hash mode with a 32-byte key, calculated using blake2s<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash<br />
* The hash key itself is also calculated using blake2s:<br />
** key = blake2s(data = application name || deviceid, key = application secret)<br />
* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). The resulting key is written to non-volatile storage.<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35074Meshcore-sensor-net2026-02-23T17:33:01Z<p>Bertrik Sikken: /* Design */</p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=Initializing<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used almost universally in the Netherlands now is the EU/UK setting:<br />
<br />
869.618 / SF8 / BW62.5 / CR8<br />
header enabled<br />
sync word XXXX<br />
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<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Investigation ==<br />
<br />
== Design ==<br />
The plan is to use payload type "RawCustom".<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type RawCustom + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* Payload: citizen science payload structure<br />
<br />
Citizen science payload structure:<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The citizen science data is not secret, so it is not encrypted, but we do add a cryptographic checksum to recognize authentic messages<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Keyed hash mode with a 32-byte key, calculated using blake2s HMAC<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash<br />
* The secret hash key is itself calculated using blake2s:<br />
** Initial step: calculate key as blake2s(salt || deviceid || passphrase)<br />
** Repeat this 10000 times: calculate key as blake2s(salt || deviceid || key)<br />
* The salt used is actually the "application name", and the passphrase is the "application secret"<br />
* The application name is part of the program image, the deviceid is derived from a unique hardware id, the application secret is entered only during key generation (never stored on device). The resulting key is written to non-volatile storage.<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35072Meshcore-sensor-net2026-02-22T22:57:44Z<p>Bertrik Sikken: /* Design */</p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=Initializing<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used almost universally in the Netherlands now is the EU/UK setting:<br />
<br />
869.618 / SF8 / BW62.5 / CR8<br />
header enabled<br />
sync word XXXX<br />
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<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Investigation ==<br />
<br />
== Design ==<br />
The plan is to use payload type "RawCustom".<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type RawCustom + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* Payload: citizen science payload structure<br />
<br />
Citizen science payload structure:<br />
* 4 bytes deviceid<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The citizen science data is not secret, so it is not encrypted, but we do add a cryptographic checksum to prove authenticity<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Keyed hash mode with a 32-byte key, calculated using blake2s HMAC<br />
** Fields included in hash: deviceid, counter, citizen science data<br />
** We retain 4 bytes of the hash<br />
* The secret hash key is itself calculated using blake2s:<br />
** Initial step: calculate key as blake2s(salt || deviceid || passphrase)<br />
** Repeat this 10000 times: calculate key as blake2s(salt || deviceid || key)<br />
* The salt used is actually the "application name", and the passphrase is the "application secret"<br />
* The application name is part of the program image, the deviceid is read from some unique hardware id, the application secret is entered only during key generation (never stored on device). The resulting key is written to non-volatile storage.<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35071Meshcore-sensor-net2026-02-22T22:51:38Z<p>Bertrik Sikken: </p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=Initializing<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used almost universally in the Netherlands now is the EU/UK setting:<br />
<br />
869.618 / SF8 / BW62.5 / CR8<br />
header enabled<br />
sync word XXXX<br />
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<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Investigation ==<br />
<br />
== Design ==<br />
The plan is to use payload type "RawCustom".<br />
<br />
Meshcore packet structure from sensor:<br />
* Header: 1 byte = payload type RawCustom + (flood or direct)<br />
* Path: length + path bytes (0 in case of flood)<br />
* Payload: citizen science payload structure<br />
<br />
Citizen science payload structure:<br />
* 4 bytes device address<br />
* 4 bytes counter<br />
* x bytes citizen science data<br />
* 4 bytes MAC<br />
<br />
Security:<br />
* The citizen science payload is not secret, so it is not encrypted, but we do add a cryptographic checksum to prove authenticity<br />
* The checksum is calculated using the blake2s algorithm, calculated as follows:<br />
** Keyed hash mode with a 32-byte key<br />
** Source device, 4-bytes<br />
** Message counter, 4 bytes<br />
** Message payload, x bytes<br />
** Retain 4 bytes of the hash<br />
* The secret hash key is also calculated using blake2s:<br />
** Initial step: calculate key as blake2s(salt || deviceid || passphrase)<br />
** Repeat this 10000 times: calculate key as blake2s(salt || deviceid || key)<br />
* The salt used is actually the "application name", and the passphrase is the "application secret"<br />
* The application name is part of the program image, the deviceid is read from some unique hardware id, the application secret is entered only during key generation (never stored on device). The resulting key is written to non-volatile storage.<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=User:Bertrik_Sikken&diff=35070User:Bertrik Sikken2026-02-22T19:00:36Z<p>Bertrik Sikken: /* Project ideas */</p>
<hr />
<div>{{Smoel<br />
|Name=Bertrik Sikken<br />
|Nick=bertrik<br />
|Tagline=heb ik niet<br />
}}<br />
<br />
You can reach me at [mailto:bertrik@sikken.nl bertrik@sikken.nl] or [mailto:bertrik@gmail.com bertrik@gmail.com].<br />
<br />
Studied Electrical Engineering at Twente University.<br />
<br />
<br />
Main interests:<br />
* reverse-engineering things (USB stuff, mp3 players), worked on http://rockbox.org (sansa clip players)<br />
* studying bats and making electronics for recording/listening to bat sounds<br />
* radio stuff, in particular software-defined radio, LoRa networks<br />
* citizen science and open data (particulate matter measurement, noise, water quality)<br />
* energy-related stuff, visualisation<br />
<br />
Projects I work(ed) on ([https://revspace.nl/index.php?title=User:Bertrik_Sikken&action=purge refresh]):<br />
{{#ask:[[Category:Project]][[Project Contact::bertrik]]<br />
|?Project Status<br />
|headers=show<br />
|link=all<br />
|order=ASC,ASC<br />
|sort=Project Status,Project Name<br />
}}<br />
<br />
<br />
== Project ideas ==<br />
[[File:always10oclock.jpg|right]]<br />
[[File:idea.jpg|right]]<br />
<br />
This is a list of ideas I'm thinking about, but have not fully developed into an actual project yet.<br />
<br />
https://pine64.com/product/128mb-ox64-sbc-available-on-december-2-2022/<br />
<br />
=== investigate thread/matter ===<br />
Matter/thread is the new IKEA standard for home automation thins apparently. <br />
Thread is the wireless protocol, matter is a home automation protocol running on top of thread.<br />
<br />
I have a couple of nrf52840, these are good in doing thread.<br />
<br />
Next steps:<br />
* check out openthread<br />
<pre><br />
git clone https://github.com/openthread/openthread.git<br />
cd openthread<br />
git submodule update --init --recursive<br />
</pre><br />
* Prepare development environment:<br />
scripts/bootstrap<br />
* Build it:<br />
./script/build nrf52840 UART_trans -DOT_LOG_LEVEL=OT_LOG_LEVEL_INFO<br />
<br />
Thread on ESP32:<br />
* on ESP32 C6 https://gist.github.com/gtxaspec/d26198daadfb0a8b0a0edeae2d3fd58f<br />
* https://github.com/espressif/esp-thread-br<br />
* https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_rcp<br />
<br />
=== action lsc stekker ===<br />
https://keetsupport.nl/2024/03/20/how-to-flash-lsc-power-plug-with-esphome/<br />
<br />
https://community.home-assistant.io/t/detailed-guide-on-how-to-flash-the-new-tuya-beken-chips-with-openbk7231t/437276<br />
<br />
=== sipeed maix dock ===<br />
Bought this a couple of years ago. Get familiar with this board.<br />
Can I run a chess program on this, for example?<br />
<br />
* https://wiki.sipeed.com/soft/maixpy/en/develop_kit_board/maix_dock.html<br />
<br />
=== rfid keyfob ===<br />
* aliexpress page: https://nl.aliexpress.com/item/1005009569496736.html<br />
* firmware github: <br />
** https://github.com/RfidResearchGroup/ChameleonUltra<br />
** https://github.com/GameTec-live/ChameleonUltraGUI<br />
<br />
=== advanced lidars for bat detection ===<br />
livox:<br />
* github page https://github.com/Livox-SDK/Livox-SDK/tree/master<br />
* web page: https://www.livoxtech.com/<br />
<br />
=== cubecell meshtastic motion detector ===<br />
I have a cubecell AB01 board.<br />
This board is focused on low power, has a connection to attach a solar panel and has a lora radio.<br />
Relatively small amount of RAM, barely enough to run a LoRaWAN stack but probably plenty to run meshtastic<br />
<br />
The plan is to build a simple motion detector from this (using a PIR).<br />
The PIR can wake up the board from low-power, or a timer can wake it periodically.<br />
<br />
See also: https://github.com/HelTecAutomation/CubeCell-Arduino/tree/master/libraries/Basics/examples/LowPower<br />
<br />
=== configure multitech outdoor gateway ===<br />
https://www.multitech.net/developer/products/multiconnect-conduit-platform/basestation/<br />
<br />
https://multitech.com/product/multitech-conduit-mtcdt-246a-868-eu-gb/<br />
<br />
emergency procedure:<br />
https://www.multitech.net/developer/software/mlinux/using-mlinux/flashing-mlinux-firmware-for-conduit/<br />
<br />
=== esp32 wtf ===<br />
* https://forum.arduino.cc/t/ttgo-lilygo-lora-esp32-26mhz-problem/1353750<br />
* "26 MHz crystal has been deprecated" https://github.com/espressif/arduino-esp32/issues/10117<br />
<br />
=== kakofonie counter ===<br />
Sample room audio, use neural network to distinguish voices to estimate number of people talking in the past 30 seconds or so.<br />
Show this number on some kind of display, publish it to MQTT, make a nice graph of it.<br />
<br />
Stuff to figure out:<br />
* this is called 'speaker diarization'<br />
* can it run on an ESP32?<br />
* make a prototype<br />
<br />
=== hypno toad ===<br />
Put these LEDS https://nl.aliexpress.com/item/1005007583528891.html into https://www.action.com/nl-nl/p/2560347/solar-tuinbeeldje/<br />
<br />
Turns out that the default circuit is really basic and output a rough step-up waveform to the LED.<br />
The self-fading LEDs don't work very well with that.<br />
<br />
Also, putting some IPA on hotglue makes it release really easy.<br />
<br />
=== wasbeer / kat classifier ===<br />
ESP32 with resnet50 neural net to distinguish house cats from other animals, see also:<br />
* https://ieeexplore.ieee.org/document/10556848/<br />
<br />
=== Nespresso brew counter ===<br />
Several hacker spaces have one of these Nespresso cup coffee makers, but there's no obvious easy way to monitor usage (monitor ALL the things!).<br />
Inspired by https://hackaday.com/2021/04/25/arduino-mkr-makes-nespresso-monitoring-easy/ this idea is making an even simpler nespresso monitor,<br />
using an inexpensive WiFi enabled ESP8266 with an ubiquitous I2S microphone such as the INMP441. <br />
<br />
Use this sound monitoring project:<br />
https://github.com/aleiei/ESP8266-BUG-I2S-MIC<br />
and turn it into a WiFi connected brew counter.<br />
<br />
Software for getting microphone data from an ESP8266/I2S mic into Linux https://github.com/bertrik/EspMicServer<br />
Nespresso sound is typically 50 Hz with overtones.<br />
In a recording with the ESP8266, it appears that oddly the 17th harmonic (around 850 Hz) is quite strong.<br />
<br />
The plan in the short term is this:<br />
* apply a gentle IIR filter to subtract any DC bias from the microphone signal<br />
* calculate autocovariance at offsets 0 and 20 ms (inverse of 50 Hz), representing the total energy and the energy at 50 Hz respectively<br />
* compare amplitudes to decide about presence of 50 Hz signal, e.g. calculate ratio in dB<br />
* use this to count the length of time that a 50 Hz signal is heard (increments of 100 ms or so)<br />
* decide about none / espresso / lungo based on time<br />
<br />
Might even integrate with esphome / home assistant later.<br />
<br />
=== Remote bat box monitor ===<br />
Idea:<br />
* goal: check if remote bat boxes are occupied and identify the species<br />
* challenges:<br />
** connectivity: need to transport images/videos (no LoRaWAN), possibly out of range of mobile data networks<br />
** autonomy: cannot reach the bat box once installed<br />
** power: no fixed power connection, so probably needs a battery + solar panel<br />
* design<br />
** wake up every hour, take a picture, go to sleep, upload photos/videos once per day<br />
** run from batteries, recharge by solar, rules of thumb<br />
*** batteries should last for about 10 days<br />
*** battery should be able to charge in 1 day<br />
*** consider only 10% of peak solar power<br />
** KPN "4G-op-zee" somewhat confusing article: https://www.kpn.com/zakelijk/mobiel/roaming/noordzee<br />
* hardware<br />
** main processor: raspberry pi zero<br />
*** raspberry pi power consumption overview: https://www.pidramble.com/wiki/benchmarks/power-consumption<br />
** this hat to wake up the main CPU: https://www.waveshare.com/wiki/Power_Management_HAT_(B) sold at https://www.kiwi-electronics.com/en/power-management-hat-for-raspberry-pi-with-rtc-and-rp2040-mcu-11373<br />
<br />
=== KNMI API ===<br />
Get familiar with https://developer.dataplatform.knmi.nl/open-data-api<br />
<br />
=== Grid frequency measurer with web page ===<br />
See https://github.com/bertrik/GridFrequency<br />
SSE source is gridfrequency.local/events<br />
<br />
=== WeAct CH55x board ===<br />
Cheap little boards, using a similar chip as used in USB-serial converters.<br />
<br />
The hardware<br />
https://github.com/WeActStudio/WeActStudio.CH552CoreBoard<br />
<br />
Flashing it:<br />
https://hackaday.io/page/137447-flashing-the-ch552-dev-board-from-the-command-line<br />
<br />
See also:<br />
* https://hackaday.io/project/198238-more-weact-ch5xx<br />
* https://community.platformio.org/t/manually-adding-support-for-ch55x-controller-by-adding-existing-ardunio-core/41138<br />
<br />
=== Zigbee device with esp32 ===<br />
See https://github.com/P-R-O-C-H-Y/arduino-esp32/blob/8169a434c3e46e1bb7711ebcc04f27267db2093c/libraries/ESP32/examples/Zigbee/Zigbee_Light_Bulb/Zigbee_Light_Bulb.ino<br />
<br />
See https://github.com/espressif/arduino-esp32/tree/master/libraries/ESP32/examples/Zigbee<br />
<br />
Espressif32 arduino platform git: https://github.com/platformio/platform-espressif32<br />
<br />
=== Cameratoezicht in Gouda ===<br />
Gemeente Gouda publiceert een lijst van camera's in Gouda, zie<br />
https://gis.gouda.nl/nl/app/Basisviewer_open#!eAGT8uRiNBRy4ZIRYFKSyKkssjJwdzFxNDMz8TKKsLC0cnb0dQ1y5FIByirgkg3xd43ydPYIAQBXGBFm<br />
<br />
Aanmelden (semi-automatisch) bij bijvoorbeeld [https://mapcomplete.org/surveillance Surveillance-under-surveillance] ?<br />
<br />
=== SolarEdge ===<br />
Interact with the solar edge api for PV installations.<br />
<br />
https://developers.solaredge.com/<br />
<br />
See https://github.com/bertrik/solaredge-api<br />
<br />
=== Stookalert ===<br />
Idee: gekleurd lampje dat aangeeft of er op dit moment een stookalert actief is<br />
<br />
Implementatie:<br />
* kijk m.b.v. WiFi locatieservice in welke provincie je je bevindt<br />
* haal JSON op bij https://www.lml.rivm.nl/stookalert/stookalert.json<br />
* toon de bijbehorende kleur op het lampje<br />
<br />
Resources:<br />
* Officiele pagina: https://www.atlasleefomgeving.nl/stookwijzer<br />
* Achterliggende JSON met toestand per provincie: https://www.lml.rivm.nl/stookalert/stookalert.json<br />
* Er moet ook nog ergens een API zijn die fijnmaziger aangeeft wat de toestand is ...<br />
<br />
=== Display of current electricity usage ===<br />
I have a [https://www.zuidwijk.com/product/slimmelezer-plus/ slimme lezer] connected to the P1 port of my smart electricity meter.<br />
The default firmware exposes meter readings using an event stream (SSE) at http://slimmelezer.local/events<br />
<br />
So for example, you can read this with curl:<br />
curl http://slimmelezer.local/events<br />
With result:<br />
event: state<br />
data: {"id":"sensor-power_consumed_phase_1","value":0.046,"state":"0.046 kW"}<br />
<br />
Specification of SSE: https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream<br />
<br />
What I would like to do is to read these events and control a simple display to display the current usage number.<br />
<br />
=== Participating in ultrasonic sound project ===<br />
https://bat-migration-europe.netlify.app/project/<br />
<br />
Use an audiomoth for this.<br />
<br />
=== ESP32 C3 ===<br />
* [https://www.espressif.com/en/products/socs/esp32-c3 processor page]<br />
* [https://wiki.luatos.com/chips/esp32c3/index.html luatos basic esp32 c3 board]<br />
<br />
=== Flexible LED ticker ===<br />
Ordered a flexible 32x8 RGB LED display:<br />
https://nl.aliexpress.com/item/4001296811800.html<br />
<br />
Matching diffuser to be 3D printed:<br />
https://www.thingiverse.com/thing:1903744<br />
<br />
=== Washing machine API ===<br />
https://tratt.net/laurie/blog/2023/displaying_my_washing_machines_remaining_time_with_curl_jq_pizauth.html<br />
<br />
=== TinyML ===<br />
Investigate TinyML, see https://www.tinyml.org/<br />
Apparently can run on a RP2040 (raspi pi pico).<br />
<br />
https://www.hackster.io/mjrobot/esp32-cam-tinyml-image-classification-fruits-vs-veggies-4ab970<br />
<br />
=== Bat box busy signal ===<br />
My brother built little pyramid 'blinkies': solar cell + Lithium-supercapacitor + harvesting circuit + LED encased in clear expoxy.<br />
<br />
Can we add a low-power PIR sensor to this, and make a blinky that blinks if movement was detected by the PIR in the past hour?<br />
<br />
=== Super tiny RFID ===<br />
See https://www.sparkfun.com/products/16464 an almost sand grain size RFID chip, 1.25mmx1.25mmx0.55mm<br />
<br />
The accompanying reader "M6E Nano" is still quite expensive at $235.95 : https://www.sparkfun.com/products/14066<br />
<br />
Uses the MuRata LXMSJZNCMF-198:<br />
"This product can be used as an ultra small tag and this can be<br />
fit on any metal objects, non-metal objects, as well as<br />
embedding into any objects by glue or adhesive and so on."<br />
<br />
See also: ISO18000-63 and EPC global Gen2(v2)<br />
<br />
Specification:<br />
* https://www.gs1.org/standards/rfid/uhf-air-interface-protocol<br />
<br />
=== TheThingsNetwork-Sondehub bridge ===<br />
Uploads balloon telemetry to sondehub.<br />
<br />
See https://github.com/bertrik/ttnhabbridge/issues/6<br />
<br />
=== Actually smart boiler ===<br />
The boiler for hot water is about half of my electricity bill.<br />
The idea is to use/build a smart switch that switches it on at time when electricity prices are lowest.<br />
<br />
Currently have a "Slimme boiler module" from Eneco, which is *not* actually smart,<br />
since it allows me no control whatsoever when it switches on (besides cutting the power in the meterkast).<br />
For example, it will switch on mid-day when my price is high and eneco's price is low, perhaps good for Eneco, not for me. <br />
Apparently, they even received a [https://nieuws.eneco.nl/slim-apparaatje-bij-boiler-vangt-pieken-wind--en-zonnestroom-op/ subsidy] for this.<br />
<br />
A boiler is a pretty big load, about 3 kW, but it is not inductive.<br />
<br />
Alternatives:<br />
* https://www.shelly.cloud/en-nl/products/product-overview/shelly-plus-1-pm-2-pack/shelly-plus-1-pm<br />
* https://www.solyxenergy.nl/solar-iboost/ to store excess solar energy in hot water, might also be useful for just controlling a boiler to use cheaper rates<br />
* tuya smartplug, like https://www.wifilampkoning.nl/merken-slimme-verlichting/tuya/tuya-enkele-smartplug-met-energiemeting ?<br />
* tuya 20A smart plug: https://nl.aliexpress.com/item/1005003347568206.html<br />
<br />
=== Receiving gas meters ===<br />
Apparently gas meters send gas consumption data to the slimme meter using a wireless link in the 868 MHz band.<br />
Probably just FSK at 38.4, as mentioned here: https://a35.veron.nl/nieuwe-elektra-en-gasmeters/<br />
<br />
Interesting leads:<br />
* https://github.com/stef/smeter<br />
* https://www.rtl-sdr.com/reading-household-wireless-utility-meters-with-an-rtl-sdr-and-plotting-the-data-in-home-automation-software/<br />
* https://github.com/bemasher/rtlamr<br />
<br />
=== Multi-network wifi manager ===<br />
Figure out or create software so that ESP8266/ESP32 wifi manager can use multiple networks to connect (not just one),<br />
so it allowing storing credentials for more than one network. For example, the network at home, the hacker space, at work.<br />
Instead of reconfiguring the wifi manager for each network, you just *add* your credentials (and the existing credentials<br />
are not replaced).<br />
<br />
See https://github.com/folkertvanheusden/M.A.X.X<br />
<br />
Interesting candidates:<br />
* https://registry.platformio.org/libraries/martinverges/ESP32%20Wifi%20Manager wifi manager for ESP32, has a REST API for managing wifi network, but is incomplete in the sense that you need to write your own code (e.g. javascript) to actually *use* its API<br />
* https://github.com/arduino-libraries/Arduino_MultiWiFi is the arduino multi wifi library, to allow connecting to multiple different WiFi networks, but it is not a wifi manager, that starts a captive portal, etc<br />
<br />
=== Automated bat counting ===<br />
Can we automatically count the number of bats from the image of a webcam mounted in a bat colony?<br />
Perhaps using some kind of AI or machine learning algorithm?<br />
<br />
The image in question:<br />
https://stofradar.nl/coenecoop/<br />
<br />
=== Use TheThingsIndoorGateway as Helium/ThingSix hotspot ===<br />
I have a spare TTIG that could perhaps be used as a Helium gateway, investigate what is possible.<br />
<br />
One possiblity is to capture the gateway traffic from the TTN gateway events API, convert uplink data to a format that the Helium network understands and forward it.<br />
I don't really care about the Helium crypto tokens, this is just for fun and science.<br />
<br />
What I definitely can do:<br />
* Capture data from the TTN gateway events API, convert it back to Semtech UP format and forward it somewhere to Helium (just not sure where!)<br />
* See also my https://github.com/bertrik/ttn-gateway-collector project which contains an initial implementation of TTN-to-UDP conversion<br />
<br />
Showstoppers:<br />
* If you want to be a gateway on the Helium network, you have to *pay Helium*! Obviously I don't want that, I just want to share data to improve *their* network. <br />
<br />
Open work:<br />
* Investigate if Helium has an open uplink API for their hotspots, if so study it etc, without paying the gateway fee<br />
* Investigate if Thingsix has an open uplink API for their hotspots, if so study it etc, without paying any gateway fee<br />
* Investigate if Thingsix is just another Helium, with weird crypto money<br />
<br />
Interesting stuff:<br />
* https://docs.helium.com/use-the-network/setup-a-packet-forwarder unfortunately the link to setting up the 'light hotspot client' does not work!<br />
* https://docs.helium.com/mine-hnt/light-hotspots/<br />
* https://thingsix.com/<br />
<br />
=== Adding BLE GATT interface to sensors ===<br />
The GATT specification allows measurement properties to be defined and transferred continuously over Bluetooth low-energy.<br />
<br />
With GATT you can define a collection of properties (e.g. measurement items like temperature/humidity/particulate matter/noise, etc)<br />
organised in a simple structure of a BLE service.<br />
The 'notification' method allows you to basically push the data continuously to a connected host, e.g. a smart phone.<br />
<br />
Services collects characteristic, a characteristic has values with units.<br />
Each of these (service, characteristic, unit) have their own unique "UUID".<br />
This is described in the so-called [https://btprodspecificationrefs.blob.core.windows.net/assigned-values/16-bit%20UUID%20Numbers%20Document.pdf 16-bit UUID numbers document]<br />
<br />
Interesting stuff in GATT:<br />
* See GATT_Specification_Supplement_v5 paragraph 3.151, it has a noise characteristic with 1 dB resolution.<br />
* 0x27C3 is the GATT *unit* for sound pressure<br />
* 0x181A is the GATT environmental sensing *service*, document name "ESP_V1.0.0.pdf"<br />
* 0x2A6E is the GATT Characteristic and Object Type for temperature<br />
* 0x2A6F is the GATT Characteristic and Object Type for humidity<br />
* 0x2BD5 is the GATT Characteristic and Object Type for Particulate Matter - PM1 Concentration<br />
* 0x2BD6 is the GATT Characteristic and Object Type for Particulate Matter - PM2.5 Concentration<br />
* 0x2BD7 is the GATT Characteristic and Object Type for Particulate Matter - PM10 Concentration<br />
* Unfortunately I cannot find a characteristic for carbon-dioxide (CO2) in the BLE GATT unit document<br />
<br />
See also https://programmaticponderings.com/2020/08/04/getting-started-with-bluetooth-low-energy-ble-and-generic-attribute-profile-gatt-specification-for-iot/<br />
<br />
=== Reverse engineering XS-8217 bluetooth air quality meter ===<br />
This is a thing that measures CO2, humidity, temperature, TVOC and formaldehyde.<br />
<br />
See also https://wiki.liutyi.info/display/CO2/ZN-2CO3+Inside<br />
<br />
This teardown looks a lot like my sensor: https://www.youtube.com/watch?v=APnjhMrJChI<br />
Mine contains a "TPM-300A" sensor for measuring VOC.<br />
<br />
It has a bluetooth interface, device name is XS-8217.<br />
It has a BLE GATT profile, with the following services<br />
* service 0xC760<br />
** characteristic 0xC762 (WRITE)<br />
** characteristic 0xC761 (NOTIFY)<br />
*** example data: 0x23 0x06 0x10 0x04 0xF1 0x00 0x23 0x65<br />
*** example data: 0x23 0x08 0x10 0x04 0x01 0x9A 0x00 0x0A 0x00 0x03 0x0E<br />
*** data shown on screen was approximately: CO2=418ppm, HCHO=0.003mg/m3, TVOC=0.013mg/m3, temp=24degC, humi=35%<br />
<br />
So data in the characteristic 0xC761 seems to have a 4 byte constant header:<br />
* 0x23<br />
* length byte<br />
<br />
Then we have for the first message: 0x10 0x04 0xF1 0x00 0x23 0x65<br />
* 0x10 0x04 fixed header<br />
* 0xF1 is temperature in 0.1 degree Celcius most likely (24.1)<br />
* 0x00 is ...<br />
* 0x23 is humidity most likely (35)<br />
* 0x65 is ... checksum perhaps<br />
<br />
And for the second message: 0x10 0x04 0x01 0x9A 0x00 0x0A 0x00 0x03 0x0E<br />
* 0x10 0x04 fixed header<br />
* 0x01 0x9A is the CO2 concentration (410)<br />
* 0x00 0x0A is TVOC most likely (10)<br />
* 0x00 0x03 is HCHO most likely (3)<br />
* 0x0E is ... checksum perhaps<br />
<br />
=== ribbon tweeter for bat audio ===<br />
Someone gave me this idea:<br />
Use a ribbon tweeter like this for playing back bat audio:<br />
<s>https://nl.aliexpress.com/item/4000973201791.html</s><br />
<s>https://nl.aliexpress.com/item/1005002565880660.html</s><br />
https://nl.aliexpress.com/item/1005002635086050.html<br />
<br />
The frequency spectrum shows no sign of dropping off at 20 kHz.<br />
<br />
=== 3d glasses ===<br />
I got some 2nd hand 3d glasses, they look exactly like these ones:<br />
* GH-15 https://www.dhgate.com/product/g15-dlp-3d-active-shutter-glasses-96-144hz/213983026.html<br />
* Sintron https://www.amazon.de/Sintron-Kompatibel-TDG-BT500A-TDG-BT400A-Deutschland/dp/B015PCWMZ8<br />
The common name appears to be "G15-DLP".<br />
<br />
A tear-down here:<br />
* https://blog.danman.eu/3d-shutter-glasses-teardown/<br />
<br />
Interesting documents:<br />
* http://cmst.curtin.edu.au/wp-content/uploads/sites/4/2016/05/2012-28-woods-helliwell-cross-compatibility_of_shutter_glasses.pdf<br />
* http://cmst.curtin.edu.au/local/docs/pubs/2011-17-woods-helliwell-3D-Sync-IR.pdf<br />
<br />
Someone claims he got something to work with some hacks:<br />
https://www.avsforum.com/threads/how-i-got-cheap-dlp-link-glasses-to-work-great.1887145/<br />
<br />
=== Waterniveaumeter ===<br />
Op verschillende plekken in Gouda staat er water in de kruipruimte van huizen van bewoners.<br />
Kunnen we dat meten en inzichtelijk maken, voor bewoners, op een kaart bijvoorbeeld?<br />
<br />
Idee:<br />
* in de kruipruimte plaats je een module die waterhoogte kan meten<br />
* de module bestaat uit een microcontroller en een afstandsmeter, die de waterhoogte bepaalt<br />
* de gegevens worden via WiFi doorgestuurd naar een centraal punt, waar de data wordt verwerkt en gevisualiseerd<br />
* op een webpagina kan je een overzicht zien van alle meters die online zijn<br />
* de meting wordt gedaan door bijv. een laser-afstandsmeter of een ultrasoon-afstandsmeter<br />
* voeding? lastig, hoe krijg je 5v naar een potentieel natte plek?<br />
* kosten? verwachting < E 40,-<br />
<br />
In Gouda wordt op veel verschillende plekken de grondwaterstand gemeten, zie https://opendata.munisense.net/portal/wareco-water2/group/581/Gouda-KJ38A , maar:<br />
* geen visualisatie op de kaart, je ziet alleen de meetlokaties d.m.v. een icoontje!<br />
* geen meetpunten in Gouda noord!<br />
<br />
=== Online bat detector ===<br />
Idea: use an ultrasonic microphone, connect it to a WebSDR, so people can tune into bat sounds remotely.<br />
<br />
=== Raspberry pi airplane tracking ===<br />
Apparently now you can also participate in MLAT tracking of planes that don't transmit GPS coordinates themselves.<br />
<br />
=== APRS gateway ===<br />
http://qso365.co.uk/2017/02/a-guide-to-setting-up-an-aprs-receive-only-igate-using-a-raspberry-pi-and-an-rtl-sdr-dongle/<br />
<br />
=== JQ6500 ===<br />
Small inexpensive modules that play mp3 from an internal flash. Could be nice for a custom door bell for example.<br />
<br />
More info at: <br />
* https://www.elecfreaks.com/wiki/index.php?title=JQ6500_Mini_MP3_Module<br />
* https://sparks.gogo.co.nz/jq6500/index.html<br />
<br />
=== FPGA ===<br />
Cheap FPGA boards and nice applications:<br />
* https://bitbucket.org/appanp/artificial-neural-networks/wiki/Home/FPGAsAndNeuralNets.md#!sbcs-and-iot-boards <br />
* [http://nl.aliexpress.com/item/Altera-fpga-cycloneii-ep2c5t144-learning-board-development-board/872520721.html inexpensive ep2c5t144 board] <br />
* http://land-boards.com/blwiki/index.php?title=Cyclone_II_EP2C5_Mini_Dev_Board<br />
<br />
=== Neural networks on low-end hardware ===<br />
Investigate if you can run a powerful neural network on relatively low-end/cheap/low-power hardware. For example a Raspberry pi.<br />
A RPI runs Linux, run python, just like some common neural frameworks.<br />
Do we need hardware acceleration from the GPU and does the RPI GPU support that?<br />
<br />
Read list:<br />
* https://www.zdnet.com/pictures/raspberry-pi-meets-ai-the-projects-that-put-machine-learning-on-the-35-board/<br />
* https://www.pyimagesearch.com/2017/12/18/keras-deep-learning-raspberry-pi/<br />
* https://www.indiegogo.com/projects/sipeed-maix-the-world-first-risc-v-64-ai-module#/<br />
* https://ai.intel.com/intel-neural-compute-stick-2-smarter-faster-plug-and-play-ai-at-the-edge/<br />
<br />
Bought a MaixPy:<br />
* see https://maixpy.sipeed.com/en/<br />
* see https://www.youtube.com/watch?v=KResVuAIMb4<br />
* see http://educ8s.tv/sipeed-m1-dock-review/<br />
* interesting? https://www.instructables.com/id/Transfer-Learning-With-Sipeed-MaiX-and-Arduino-IDE/<br />
<br />
=== mini word clock in dutch ===<br />
Basically an monochrome 8x8 word clock, in Dutch, showing local time in the Netherlands.<br />
<br />
[https://github.com/bertrik/miniwordclock This git repo] has the current code.<br />
<br />
See [https://plus.google.com/103276078656203197145/posts/7ki7rpJzk3a here for a demo] running on an arduino nano.<br />
<br />
The plan is to run this from an ESP8266 instead of an arduino nano, so it can get the time from the internet using NTP.<br />
Andreas Spiess demonstrated on youtube how existing libraries on the ESP8266 can be used to do the local time (including summer-time) calculations.<br />
<br />
=== Cypress PSOC5 ===<br />
Play with the Cypress PSOC5 platform, which combines a ARM Cortex-m3 processor with configurable analog blocks. I'm thinking of combining it with a 24 GHz doppler radar sensor, to process the signal and present it as a USB audio device (stereo signal contains I and Q parts). See [[RadarOnAStick]].<br />
<br />
=== Simple Doppler motion sensors ===<br />
You can find basic doppler microwave motion sensors based on a single transistor, with some weird traces on the PCB very cheaply, for example<br />
* https://www.aliexpress.com/item/RCWL-0516-microwave-radar-sensor-module-Human-body-induction-switch-module-Intelligent-sensor/32708877914.html<br />
<br />
Typically the microwave part of these consists of a single transistor with a rectangular area on one leg and a meandering trace (with lots of vias to the other side) on the other leg.<br />
The output of this circuit seems to go into a chip very much like the ones used in PIR sensors.<br />
<br />
See also https://github.com/jdesbonnet/RCWL-0516 for a reverse engineering effort of these doppler radar modules.<br />
<br />
=== Bare-bones Arduino bat detector ===<br />
This is an idea for a very basic heterodyne bat detector, doing signal processing on an Arduino, requiring minimal external components.<br />
<br />
The basic principle of a heterodyne detector is that it just mixes (multiplies) the audio signal with a square wave, low-pass filters the result and puts it on a speaker.<br />
<br />
Multiplying with a square wave can also be considered to be just alternatively inverting and not-inverting the signal.<br />
So if you sample an ultrasonic signal at twice the rate you want to multiply, you can just subtract odd samples from even samples and low-pass filter that.<br />
<br />
How this can be done in an AVR Arduino:<br />
* sample the audio signal at twice the detection frequency, say 84 kHz. An AVR should just be able to do that.<br />
* apply a 1-pole IIR high-pass filter to remove DC bias, this takes one shift instruction and one addition.<br />
* multiply by the detection frequency, this means just inverting the odd samples.<br />
* low-pass filter the signal, this can be done using a moving average filter, say 16 samples long (first null at 5.25 kHz). Theoretically, averaging 16 samples should result in two bits extra accuracy. This operation takes some storage, an addition and a subtraction.<br />
* output the filtered signal using PWM, possibly at the same rate that we are sampling the input audio.<br />
<br />
The microphone can be a 40 kHz piezo transducer, to keep it cheap (but also limited to 40 kHz).<br />
The pre-amplifier can be a single transistor with some resistors around it, providing about 40x gain.<br />
The arduino does the signal processing (mixing, low-pass filter) to shift the bat audio to human range.<br />
The speaker amplifier can just be a simple two transistor push-pull circuit, since the output from the Arduino is digital/PWM.<br />
<br />
==== AVR Arduino sample rate ====<br />
As far as I understand, the ADC clock can be set to 1 MHz.<br />
Conversion takes 13 cycles, so this can be a problem to reach a sample rate above 80 kHz.<br />
<br />
=== Indoor radar speed sign ===<br />
This idea about placing a simple IQ-output radar sensor indoors in the hacker space, do some basic signal processing on the IQ doppler signal and determine movement speed and direction, then display this on a LED display.<br />
This is of no immediate practical use other than fun, but helps me to gain a bit more experience with microwave radar sensors and eventually build a more effective setup for detecting/counting bats flying in and out of a roost.<br />
<br />
Implement this on a PSOC5 platform or on the STM32 using Arduino.</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Meshcore-sensor-net&diff=35069Meshcore-sensor-net2026-02-22T19:00:03Z<p>Bertrik Sikken: Created page with " {{Project |Name=meshcore-sensor-net |Status=Initializing |Picture=yunopicture.png |Contact=bertrik }} == Introduction == This project is an investigation for using meshcore as a transport layer for citizen science data. Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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..."</p>
<hr />
<div> {{Project<br />
|Name=meshcore-sensor-net<br />
|Status=Initializing<br />
|Picture=yunopicture.png<br />
|Contact=bertrik<br />
}}<br />
<br />
== Introduction ==<br />
This project is an investigation for using meshcore as a transport layer for citizen science data.<br />
<br />
Meshcore is basically a network of radio repeaters for lora messages with a specific radio 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.<br />
<br />
The LoRa setting used almost universally in the Netherlands now is the EU/UK setting:<br />
<br />
869.618 / SF8 / BW62.5 / CR8<br />
header enabled<br />
sync word XXXX<br />
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<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
<br />
Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
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.<br />
<br />
== Investigation ==<br />
<br />
== Software ==<br />
<br />
See https://github.com/bertrik/meshcore-sensor-net</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=User:Bertrik_Sikken&diff=35067User:Bertrik Sikken2026-02-21T22:27:10Z<p>Bertrik Sikken: /* Meshcore as citizen science data transport */</p>
<hr />
<div>{{Smoel<br />
|Name=Bertrik Sikken<br />
|Nick=bertrik<br />
|Tagline=heb ik niet<br />
}}<br />
<br />
You can reach me at [mailto:bertrik@sikken.nl bertrik@sikken.nl] or [mailto:bertrik@gmail.com bertrik@gmail.com].<br />
<br />
Studied Electrical Engineering at Twente University.<br />
<br />
<br />
Main interests:<br />
* reverse-engineering things (USB stuff, mp3 players), worked on http://rockbox.org (sansa clip players)<br />
* studying bats and making electronics for recording/listening to bat sounds<br />
* radio stuff, in particular software-defined radio, LoRa networks<br />
* citizen science and open data (particulate matter measurement, noise, water quality)<br />
* energy-related stuff, visualisation<br />
<br />
Projects I work(ed) on ([https://revspace.nl/index.php?title=User:Bertrik_Sikken&action=purge refresh]):<br />
{{#ask:[[Category:Project]][[Project Contact::bertrik]]<br />
|?Project Status<br />
|headers=show<br />
|link=all<br />
|order=ASC,ASC<br />
|sort=Project Status,Project Name<br />
}}<br />
<br />
<br />
== Project ideas ==<br />
[[File:always10oclock.jpg|right]]<br />
[[File:idea.jpg|right]]<br />
<br />
This is a list of ideas I'm thinking about, but have not fully developed into an actual project yet.<br />
<br />
https://pine64.com/product/128mb-ox64-sbc-available-on-december-2-2022/<br />
<br />
=== Meshcore as citizen science data transport ===<br />
See https://github.com/bertrik/meshcore-sensor-net<br />
<br />
Meshcore is basically a network of repeaters for lora messages with a specific setting.<br />
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.<br />
<br />
The LoRa setting used almost universally in the Netherlands now is the EU/UK setting:<br />
* 869.618 / SF8 / BW62.5 / CR8<br />
* header enabled <br />
* sync word XXXX<br />
<br />
Description of the on-the-air message: https://gist.github.com/recrof/ca7ccff28c43d1b6bf7e55ce5159100b<br />
Dissection code: https://github.com/folkertvanheusden/meshcore-store/blob/master/utils/dissect.py<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
* Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
* At some point the discovery packets reaches a special internet-connected gateway that forwards it to the backend software.<br />
* 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.<br />
<br />
=== investigate thread/matter ===<br />
Matter/thread is the new IKEA standard for home automation thins apparently. <br />
Thread is the wireless protocol, matter is a home automation protocol running on top of thread.<br />
<br />
I have a couple of nrf52840, these are good in doing thread.<br />
<br />
Next steps:<br />
* check out openthread<br />
<pre><br />
git clone https://github.com/openthread/openthread.git<br />
cd openthread<br />
git submodule update --init --recursive<br />
</pre><br />
* Prepare development environment:<br />
scripts/bootstrap<br />
* Build it:<br />
./script/build nrf52840 UART_trans -DOT_LOG_LEVEL=OT_LOG_LEVEL_INFO<br />
<br />
Thread on ESP32:<br />
* on ESP32 C6 https://gist.github.com/gtxaspec/d26198daadfb0a8b0a0edeae2d3fd58f<br />
* https://github.com/espressif/esp-thread-br<br />
* https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_rcp<br />
<br />
=== action lsc stekker ===<br />
https://keetsupport.nl/2024/03/20/how-to-flash-lsc-power-plug-with-esphome/<br />
<br />
https://community.home-assistant.io/t/detailed-guide-on-how-to-flash-the-new-tuya-beken-chips-with-openbk7231t/437276<br />
<br />
=== sipeed maix dock ===<br />
Bought this a couple of years ago. Get familiar with this board.<br />
Can I run a chess program on this, for example?<br />
<br />
* https://wiki.sipeed.com/soft/maixpy/en/develop_kit_board/maix_dock.html<br />
<br />
=== rfid keyfob ===<br />
* aliexpress page: https://nl.aliexpress.com/item/1005009569496736.html<br />
* firmware github: <br />
** https://github.com/RfidResearchGroup/ChameleonUltra<br />
** https://github.com/GameTec-live/ChameleonUltraGUI<br />
<br />
=== advanced lidars for bat detection ===<br />
livox:<br />
* github page https://github.com/Livox-SDK/Livox-SDK/tree/master<br />
* web page: https://www.livoxtech.com/<br />
<br />
=== cubecell meshtastic motion detector ===<br />
I have a cubecell AB01 board.<br />
This board is focused on low power, has a connection to attach a solar panel and has a lora radio.<br />
Relatively small amount of RAM, barely enough to run a LoRaWAN stack but probably plenty to run meshtastic<br />
<br />
The plan is to build a simple motion detector from this (using a PIR).<br />
The PIR can wake up the board from low-power, or a timer can wake it periodically.<br />
<br />
See also: https://github.com/HelTecAutomation/CubeCell-Arduino/tree/master/libraries/Basics/examples/LowPower<br />
<br />
=== configure multitech outdoor gateway ===<br />
https://www.multitech.net/developer/products/multiconnect-conduit-platform/basestation/<br />
<br />
https://multitech.com/product/multitech-conduit-mtcdt-246a-868-eu-gb/<br />
<br />
emergency procedure:<br />
https://www.multitech.net/developer/software/mlinux/using-mlinux/flashing-mlinux-firmware-for-conduit/<br />
<br />
=== esp32 wtf ===<br />
* https://forum.arduino.cc/t/ttgo-lilygo-lora-esp32-26mhz-problem/1353750<br />
* "26 MHz crystal has been deprecated" https://github.com/espressif/arduino-esp32/issues/10117<br />
<br />
=== kakofonie counter ===<br />
Sample room audio, use neural network to distinguish voices to estimate number of people talking in the past 30 seconds or so.<br />
Show this number on some kind of display, publish it to MQTT, make a nice graph of it.<br />
<br />
Stuff to figure out:<br />
* this is called 'speaker diarization'<br />
* can it run on an ESP32?<br />
* make a prototype<br />
<br />
=== hypno toad ===<br />
Put these LEDS https://nl.aliexpress.com/item/1005007583528891.html into https://www.action.com/nl-nl/p/2560347/solar-tuinbeeldje/<br />
<br />
Turns out that the default circuit is really basic and output a rough step-up waveform to the LED.<br />
The self-fading LEDs don't work very well with that.<br />
<br />
Also, putting some IPA on hotglue makes it release really easy.<br />
<br />
=== wasbeer / kat classifier ===<br />
ESP32 with resnet50 neural net to distinguish house cats from other animals, see also:<br />
* https://ieeexplore.ieee.org/document/10556848/<br />
<br />
=== Nespresso brew counter ===<br />
Several hacker spaces have one of these Nespresso cup coffee makers, but there's no obvious easy way to monitor usage (monitor ALL the things!).<br />
Inspired by https://hackaday.com/2021/04/25/arduino-mkr-makes-nespresso-monitoring-easy/ this idea is making an even simpler nespresso monitor,<br />
using an inexpensive WiFi enabled ESP8266 with an ubiquitous I2S microphone such as the INMP441. <br />
<br />
Use this sound monitoring project:<br />
https://github.com/aleiei/ESP8266-BUG-I2S-MIC<br />
and turn it into a WiFi connected brew counter.<br />
<br />
Software for getting microphone data from an ESP8266/I2S mic into Linux https://github.com/bertrik/EspMicServer<br />
Nespresso sound is typically 50 Hz with overtones.<br />
In a recording with the ESP8266, it appears that oddly the 17th harmonic (around 850 Hz) is quite strong.<br />
<br />
The plan in the short term is this:<br />
* apply a gentle IIR filter to subtract any DC bias from the microphone signal<br />
* calculate autocovariance at offsets 0 and 20 ms (inverse of 50 Hz), representing the total energy and the energy at 50 Hz respectively<br />
* compare amplitudes to decide about presence of 50 Hz signal, e.g. calculate ratio in dB<br />
* use this to count the length of time that a 50 Hz signal is heard (increments of 100 ms or so)<br />
* decide about none / espresso / lungo based on time<br />
<br />
Might even integrate with esphome / home assistant later.<br />
<br />
=== Remote bat box monitor ===<br />
Idea:<br />
* goal: check if remote bat boxes are occupied and identify the species<br />
* challenges:<br />
** connectivity: need to transport images/videos (no LoRaWAN), possibly out of range of mobile data networks<br />
** autonomy: cannot reach the bat box once installed<br />
** power: no fixed power connection, so probably needs a battery + solar panel<br />
* design<br />
** wake up every hour, take a picture, go to sleep, upload photos/videos once per day<br />
** run from batteries, recharge by solar, rules of thumb<br />
*** batteries should last for about 10 days<br />
*** battery should be able to charge in 1 day<br />
*** consider only 10% of peak solar power<br />
** KPN "4G-op-zee" somewhat confusing article: https://www.kpn.com/zakelijk/mobiel/roaming/noordzee<br />
* hardware<br />
** main processor: raspberry pi zero<br />
*** raspberry pi power consumption overview: https://www.pidramble.com/wiki/benchmarks/power-consumption<br />
** this hat to wake up the main CPU: https://www.waveshare.com/wiki/Power_Management_HAT_(B) sold at https://www.kiwi-electronics.com/en/power-management-hat-for-raspberry-pi-with-rtc-and-rp2040-mcu-11373<br />
<br />
=== KNMI API ===<br />
Get familiar with https://developer.dataplatform.knmi.nl/open-data-api<br />
<br />
=== Grid frequency measurer with web page ===<br />
See https://github.com/bertrik/GridFrequency<br />
SSE source is gridfrequency.local/events<br />
<br />
=== WeAct CH55x board ===<br />
Cheap little boards, using a similar chip as used in USB-serial converters.<br />
<br />
The hardware<br />
https://github.com/WeActStudio/WeActStudio.CH552CoreBoard<br />
<br />
Flashing it:<br />
https://hackaday.io/page/137447-flashing-the-ch552-dev-board-from-the-command-line<br />
<br />
See also:<br />
* https://hackaday.io/project/198238-more-weact-ch5xx<br />
* https://community.platformio.org/t/manually-adding-support-for-ch55x-controller-by-adding-existing-ardunio-core/41138<br />
<br />
=== Zigbee device with esp32 ===<br />
See https://github.com/P-R-O-C-H-Y/arduino-esp32/blob/8169a434c3e46e1bb7711ebcc04f27267db2093c/libraries/ESP32/examples/Zigbee/Zigbee_Light_Bulb/Zigbee_Light_Bulb.ino<br />
<br />
See https://github.com/espressif/arduino-esp32/tree/master/libraries/ESP32/examples/Zigbee<br />
<br />
Espressif32 arduino platform git: https://github.com/platformio/platform-espressif32<br />
<br />
=== Cameratoezicht in Gouda ===<br />
Gemeente Gouda publiceert een lijst van camera's in Gouda, zie<br />
https://gis.gouda.nl/nl/app/Basisviewer_open#!eAGT8uRiNBRy4ZIRYFKSyKkssjJwdzFxNDMz8TKKsLC0cnb0dQ1y5FIByirgkg3xd43ydPYIAQBXGBFm<br />
<br />
Aanmelden (semi-automatisch) bij bijvoorbeeld [https://mapcomplete.org/surveillance Surveillance-under-surveillance] ?<br />
<br />
=== SolarEdge ===<br />
Interact with the solar edge api for PV installations.<br />
<br />
https://developers.solaredge.com/<br />
<br />
See https://github.com/bertrik/solaredge-api<br />
<br />
=== Stookalert ===<br />
Idee: gekleurd lampje dat aangeeft of er op dit moment een stookalert actief is<br />
<br />
Implementatie:<br />
* kijk m.b.v. WiFi locatieservice in welke provincie je je bevindt<br />
* haal JSON op bij https://www.lml.rivm.nl/stookalert/stookalert.json<br />
* toon de bijbehorende kleur op het lampje<br />
<br />
Resources:<br />
* Officiele pagina: https://www.atlasleefomgeving.nl/stookwijzer<br />
* Achterliggende JSON met toestand per provincie: https://www.lml.rivm.nl/stookalert/stookalert.json<br />
* Er moet ook nog ergens een API zijn die fijnmaziger aangeeft wat de toestand is ...<br />
<br />
=== Display of current electricity usage ===<br />
I have a [https://www.zuidwijk.com/product/slimmelezer-plus/ slimme lezer] connected to the P1 port of my smart electricity meter.<br />
The default firmware exposes meter readings using an event stream (SSE) at http://slimmelezer.local/events<br />
<br />
So for example, you can read this with curl:<br />
curl http://slimmelezer.local/events<br />
With result:<br />
event: state<br />
data: {"id":"sensor-power_consumed_phase_1","value":0.046,"state":"0.046 kW"}<br />
<br />
Specification of SSE: https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream<br />
<br />
What I would like to do is to read these events and control a simple display to display the current usage number.<br />
<br />
=== Participating in ultrasonic sound project ===<br />
https://bat-migration-europe.netlify.app/project/<br />
<br />
Use an audiomoth for this.<br />
<br />
=== ESP32 C3 ===<br />
* [https://www.espressif.com/en/products/socs/esp32-c3 processor page]<br />
* [https://wiki.luatos.com/chips/esp32c3/index.html luatos basic esp32 c3 board]<br />
<br />
=== Flexible LED ticker ===<br />
Ordered a flexible 32x8 RGB LED display:<br />
https://nl.aliexpress.com/item/4001296811800.html<br />
<br />
Matching diffuser to be 3D printed:<br />
https://www.thingiverse.com/thing:1903744<br />
<br />
=== Washing machine API ===<br />
https://tratt.net/laurie/blog/2023/displaying_my_washing_machines_remaining_time_with_curl_jq_pizauth.html<br />
<br />
=== TinyML ===<br />
Investigate TinyML, see https://www.tinyml.org/<br />
Apparently can run on a RP2040 (raspi pi pico).<br />
<br />
https://www.hackster.io/mjrobot/esp32-cam-tinyml-image-classification-fruits-vs-veggies-4ab970<br />
<br />
=== Bat box busy signal ===<br />
My brother built little pyramid 'blinkies': solar cell + Lithium-supercapacitor + harvesting circuit + LED encased in clear expoxy.<br />
<br />
Can we add a low-power PIR sensor to this, and make a blinky that blinks if movement was detected by the PIR in the past hour?<br />
<br />
=== Super tiny RFID ===<br />
See https://www.sparkfun.com/products/16464 an almost sand grain size RFID chip, 1.25mmx1.25mmx0.55mm<br />
<br />
The accompanying reader "M6E Nano" is still quite expensive at $235.95 : https://www.sparkfun.com/products/14066<br />
<br />
Uses the MuRata LXMSJZNCMF-198:<br />
"This product can be used as an ultra small tag and this can be<br />
fit on any metal objects, non-metal objects, as well as<br />
embedding into any objects by glue or adhesive and so on."<br />
<br />
See also: ISO18000-63 and EPC global Gen2(v2)<br />
<br />
Specification:<br />
* https://www.gs1.org/standards/rfid/uhf-air-interface-protocol<br />
<br />
=== TheThingsNetwork-Sondehub bridge ===<br />
Uploads balloon telemetry to sondehub.<br />
<br />
See https://github.com/bertrik/ttnhabbridge/issues/6<br />
<br />
=== Actually smart boiler ===<br />
The boiler for hot water is about half of my electricity bill.<br />
The idea is to use/build a smart switch that switches it on at time when electricity prices are lowest.<br />
<br />
Currently have a "Slimme boiler module" from Eneco, which is *not* actually smart,<br />
since it allows me no control whatsoever when it switches on (besides cutting the power in the meterkast).<br />
For example, it will switch on mid-day when my price is high and eneco's price is low, perhaps good for Eneco, not for me. <br />
Apparently, they even received a [https://nieuws.eneco.nl/slim-apparaatje-bij-boiler-vangt-pieken-wind--en-zonnestroom-op/ subsidy] for this.<br />
<br />
A boiler is a pretty big load, about 3 kW, but it is not inductive.<br />
<br />
Alternatives:<br />
* https://www.shelly.cloud/en-nl/products/product-overview/shelly-plus-1-pm-2-pack/shelly-plus-1-pm<br />
* https://www.solyxenergy.nl/solar-iboost/ to store excess solar energy in hot water, might also be useful for just controlling a boiler to use cheaper rates<br />
* tuya smartplug, like https://www.wifilampkoning.nl/merken-slimme-verlichting/tuya/tuya-enkele-smartplug-met-energiemeting ?<br />
* tuya 20A smart plug: https://nl.aliexpress.com/item/1005003347568206.html<br />
<br />
=== Receiving gas meters ===<br />
Apparently gas meters send gas consumption data to the slimme meter using a wireless link in the 868 MHz band.<br />
Probably just FSK at 38.4, as mentioned here: https://a35.veron.nl/nieuwe-elektra-en-gasmeters/<br />
<br />
Interesting leads:<br />
* https://github.com/stef/smeter<br />
* https://www.rtl-sdr.com/reading-household-wireless-utility-meters-with-an-rtl-sdr-and-plotting-the-data-in-home-automation-software/<br />
* https://github.com/bemasher/rtlamr<br />
<br />
=== Multi-network wifi manager ===<br />
Figure out or create software so that ESP8266/ESP32 wifi manager can use multiple networks to connect (not just one),<br />
so it allowing storing credentials for more than one network. For example, the network at home, the hacker space, at work.<br />
Instead of reconfiguring the wifi manager for each network, you just *add* your credentials (and the existing credentials<br />
are not replaced).<br />
<br />
See https://github.com/folkertvanheusden/M.A.X.X<br />
<br />
Interesting candidates:<br />
* https://registry.platformio.org/libraries/martinverges/ESP32%20Wifi%20Manager wifi manager for ESP32, has a REST API for managing wifi network, but is incomplete in the sense that you need to write your own code (e.g. javascript) to actually *use* its API<br />
* https://github.com/arduino-libraries/Arduino_MultiWiFi is the arduino multi wifi library, to allow connecting to multiple different WiFi networks, but it is not a wifi manager, that starts a captive portal, etc<br />
<br />
=== Automated bat counting ===<br />
Can we automatically count the number of bats from the image of a webcam mounted in a bat colony?<br />
Perhaps using some kind of AI or machine learning algorithm?<br />
<br />
The image in question:<br />
https://stofradar.nl/coenecoop/<br />
<br />
=== Use TheThingsIndoorGateway as Helium/ThingSix hotspot ===<br />
I have a spare TTIG that could perhaps be used as a Helium gateway, investigate what is possible.<br />
<br />
One possiblity is to capture the gateway traffic from the TTN gateway events API, convert uplink data to a format that the Helium network understands and forward it.<br />
I don't really care about the Helium crypto tokens, this is just for fun and science.<br />
<br />
What I definitely can do:<br />
* Capture data from the TTN gateway events API, convert it back to Semtech UP format and forward it somewhere to Helium (just not sure where!)<br />
* See also my https://github.com/bertrik/ttn-gateway-collector project which contains an initial implementation of TTN-to-UDP conversion<br />
<br />
Showstoppers:<br />
* If you want to be a gateway on the Helium network, you have to *pay Helium*! Obviously I don't want that, I just want to share data to improve *their* network. <br />
<br />
Open work:<br />
* Investigate if Helium has an open uplink API for their hotspots, if so study it etc, without paying the gateway fee<br />
* Investigate if Thingsix has an open uplink API for their hotspots, if so study it etc, without paying any gateway fee<br />
* Investigate if Thingsix is just another Helium, with weird crypto money<br />
<br />
Interesting stuff:<br />
* https://docs.helium.com/use-the-network/setup-a-packet-forwarder unfortunately the link to setting up the 'light hotspot client' does not work!<br />
* https://docs.helium.com/mine-hnt/light-hotspots/<br />
* https://thingsix.com/<br />
<br />
=== Adding BLE GATT interface to sensors ===<br />
The GATT specification allows measurement properties to be defined and transferred continuously over Bluetooth low-energy.<br />
<br />
With GATT you can define a collection of properties (e.g. measurement items like temperature/humidity/particulate matter/noise, etc)<br />
organised in a simple structure of a BLE service.<br />
The 'notification' method allows you to basically push the data continuously to a connected host, e.g. a smart phone.<br />
<br />
Services collects characteristic, a characteristic has values with units.<br />
Each of these (service, characteristic, unit) have their own unique "UUID".<br />
This is described in the so-called [https://btprodspecificationrefs.blob.core.windows.net/assigned-values/16-bit%20UUID%20Numbers%20Document.pdf 16-bit UUID numbers document]<br />
<br />
Interesting stuff in GATT:<br />
* See GATT_Specification_Supplement_v5 paragraph 3.151, it has a noise characteristic with 1 dB resolution.<br />
* 0x27C3 is the GATT *unit* for sound pressure<br />
* 0x181A is the GATT environmental sensing *service*, document name "ESP_V1.0.0.pdf"<br />
* 0x2A6E is the GATT Characteristic and Object Type for temperature<br />
* 0x2A6F is the GATT Characteristic and Object Type for humidity<br />
* 0x2BD5 is the GATT Characteristic and Object Type for Particulate Matter - PM1 Concentration<br />
* 0x2BD6 is the GATT Characteristic and Object Type for Particulate Matter - PM2.5 Concentration<br />
* 0x2BD7 is the GATT Characteristic and Object Type for Particulate Matter - PM10 Concentration<br />
* Unfortunately I cannot find a characteristic for carbon-dioxide (CO2) in the BLE GATT unit document<br />
<br />
See also https://programmaticponderings.com/2020/08/04/getting-started-with-bluetooth-low-energy-ble-and-generic-attribute-profile-gatt-specification-for-iot/<br />
<br />
=== Reverse engineering XS-8217 bluetooth air quality meter ===<br />
This is a thing that measures CO2, humidity, temperature, TVOC and formaldehyde.<br />
<br />
See also https://wiki.liutyi.info/display/CO2/ZN-2CO3+Inside<br />
<br />
This teardown looks a lot like my sensor: https://www.youtube.com/watch?v=APnjhMrJChI<br />
Mine contains a "TPM-300A" sensor for measuring VOC.<br />
<br />
It has a bluetooth interface, device name is XS-8217.<br />
It has a BLE GATT profile, with the following services<br />
* service 0xC760<br />
** characteristic 0xC762 (WRITE)<br />
** characteristic 0xC761 (NOTIFY)<br />
*** example data: 0x23 0x06 0x10 0x04 0xF1 0x00 0x23 0x65<br />
*** example data: 0x23 0x08 0x10 0x04 0x01 0x9A 0x00 0x0A 0x00 0x03 0x0E<br />
*** data shown on screen was approximately: CO2=418ppm, HCHO=0.003mg/m3, TVOC=0.013mg/m3, temp=24degC, humi=35%<br />
<br />
So data in the characteristic 0xC761 seems to have a 4 byte constant header:<br />
* 0x23<br />
* length byte<br />
<br />
Then we have for the first message: 0x10 0x04 0xF1 0x00 0x23 0x65<br />
* 0x10 0x04 fixed header<br />
* 0xF1 is temperature in 0.1 degree Celcius most likely (24.1)<br />
* 0x00 is ...<br />
* 0x23 is humidity most likely (35)<br />
* 0x65 is ... checksum perhaps<br />
<br />
And for the second message: 0x10 0x04 0x01 0x9A 0x00 0x0A 0x00 0x03 0x0E<br />
* 0x10 0x04 fixed header<br />
* 0x01 0x9A is the CO2 concentration (410)<br />
* 0x00 0x0A is TVOC most likely (10)<br />
* 0x00 0x03 is HCHO most likely (3)<br />
* 0x0E is ... checksum perhaps<br />
<br />
=== ribbon tweeter for bat audio ===<br />
Someone gave me this idea:<br />
Use a ribbon tweeter like this for playing back bat audio:<br />
<s>https://nl.aliexpress.com/item/4000973201791.html</s><br />
<s>https://nl.aliexpress.com/item/1005002565880660.html</s><br />
https://nl.aliexpress.com/item/1005002635086050.html<br />
<br />
The frequency spectrum shows no sign of dropping off at 20 kHz.<br />
<br />
=== 3d glasses ===<br />
I got some 2nd hand 3d glasses, they look exactly like these ones:<br />
* GH-15 https://www.dhgate.com/product/g15-dlp-3d-active-shutter-glasses-96-144hz/213983026.html<br />
* Sintron https://www.amazon.de/Sintron-Kompatibel-TDG-BT500A-TDG-BT400A-Deutschland/dp/B015PCWMZ8<br />
The common name appears to be "G15-DLP".<br />
<br />
A tear-down here:<br />
* https://blog.danman.eu/3d-shutter-glasses-teardown/<br />
<br />
Interesting documents:<br />
* http://cmst.curtin.edu.au/wp-content/uploads/sites/4/2016/05/2012-28-woods-helliwell-cross-compatibility_of_shutter_glasses.pdf<br />
* http://cmst.curtin.edu.au/local/docs/pubs/2011-17-woods-helliwell-3D-Sync-IR.pdf<br />
<br />
Someone claims he got something to work with some hacks:<br />
https://www.avsforum.com/threads/how-i-got-cheap-dlp-link-glasses-to-work-great.1887145/<br />
<br />
=== Waterniveaumeter ===<br />
Op verschillende plekken in Gouda staat er water in de kruipruimte van huizen van bewoners.<br />
Kunnen we dat meten en inzichtelijk maken, voor bewoners, op een kaart bijvoorbeeld?<br />
<br />
Idee:<br />
* in de kruipruimte plaats je een module die waterhoogte kan meten<br />
* de module bestaat uit een microcontroller en een afstandsmeter, die de waterhoogte bepaalt<br />
* de gegevens worden via WiFi doorgestuurd naar een centraal punt, waar de data wordt verwerkt en gevisualiseerd<br />
* op een webpagina kan je een overzicht zien van alle meters die online zijn<br />
* de meting wordt gedaan door bijv. een laser-afstandsmeter of een ultrasoon-afstandsmeter<br />
* voeding? lastig, hoe krijg je 5v naar een potentieel natte plek?<br />
* kosten? verwachting < E 40,-<br />
<br />
In Gouda wordt op veel verschillende plekken de grondwaterstand gemeten, zie https://opendata.munisense.net/portal/wareco-water2/group/581/Gouda-KJ38A , maar:<br />
* geen visualisatie op de kaart, je ziet alleen de meetlokaties d.m.v. een icoontje!<br />
* geen meetpunten in Gouda noord!<br />
<br />
=== Online bat detector ===<br />
Idea: use an ultrasonic microphone, connect it to a WebSDR, so people can tune into bat sounds remotely.<br />
<br />
=== Raspberry pi airplane tracking ===<br />
Apparently now you can also participate in MLAT tracking of planes that don't transmit GPS coordinates themselves.<br />
<br />
=== APRS gateway ===<br />
http://qso365.co.uk/2017/02/a-guide-to-setting-up-an-aprs-receive-only-igate-using-a-raspberry-pi-and-an-rtl-sdr-dongle/<br />
<br />
=== JQ6500 ===<br />
Small inexpensive modules that play mp3 from an internal flash. Could be nice for a custom door bell for example.<br />
<br />
More info at: <br />
* https://www.elecfreaks.com/wiki/index.php?title=JQ6500_Mini_MP3_Module<br />
* https://sparks.gogo.co.nz/jq6500/index.html<br />
<br />
=== FPGA ===<br />
Cheap FPGA boards and nice applications:<br />
* https://bitbucket.org/appanp/artificial-neural-networks/wiki/Home/FPGAsAndNeuralNets.md#!sbcs-and-iot-boards <br />
* [http://nl.aliexpress.com/item/Altera-fpga-cycloneii-ep2c5t144-learning-board-development-board/872520721.html inexpensive ep2c5t144 board] <br />
* http://land-boards.com/blwiki/index.php?title=Cyclone_II_EP2C5_Mini_Dev_Board<br />
<br />
=== Neural networks on low-end hardware ===<br />
Investigate if you can run a powerful neural network on relatively low-end/cheap/low-power hardware. For example a Raspberry pi.<br />
A RPI runs Linux, run python, just like some common neural frameworks.<br />
Do we need hardware acceleration from the GPU and does the RPI GPU support that?<br />
<br />
Read list:<br />
* https://www.zdnet.com/pictures/raspberry-pi-meets-ai-the-projects-that-put-machine-learning-on-the-35-board/<br />
* https://www.pyimagesearch.com/2017/12/18/keras-deep-learning-raspberry-pi/<br />
* https://www.indiegogo.com/projects/sipeed-maix-the-world-first-risc-v-64-ai-module#/<br />
* https://ai.intel.com/intel-neural-compute-stick-2-smarter-faster-plug-and-play-ai-at-the-edge/<br />
<br />
Bought a MaixPy:<br />
* see https://maixpy.sipeed.com/en/<br />
* see https://www.youtube.com/watch?v=KResVuAIMb4<br />
* see http://educ8s.tv/sipeed-m1-dock-review/<br />
* interesting? https://www.instructables.com/id/Transfer-Learning-With-Sipeed-MaiX-and-Arduino-IDE/<br />
<br />
=== mini word clock in dutch ===<br />
Basically an monochrome 8x8 word clock, in Dutch, showing local time in the Netherlands.<br />
<br />
[https://github.com/bertrik/miniwordclock This git repo] has the current code.<br />
<br />
See [https://plus.google.com/103276078656203197145/posts/7ki7rpJzk3a here for a demo] running on an arduino nano.<br />
<br />
The plan is to run this from an ESP8266 instead of an arduino nano, so it can get the time from the internet using NTP.<br />
Andreas Spiess demonstrated on youtube how existing libraries on the ESP8266 can be used to do the local time (including summer-time) calculations.<br />
<br />
=== Cypress PSOC5 ===<br />
Play with the Cypress PSOC5 platform, which combines a ARM Cortex-m3 processor with configurable analog blocks. I'm thinking of combining it with a 24 GHz doppler radar sensor, to process the signal and present it as a USB audio device (stereo signal contains I and Q parts). See [[RadarOnAStick]].<br />
<br />
=== Simple Doppler motion sensors ===<br />
You can find basic doppler microwave motion sensors based on a single transistor, with some weird traces on the PCB very cheaply, for example<br />
* https://www.aliexpress.com/item/RCWL-0516-microwave-radar-sensor-module-Human-body-induction-switch-module-Intelligent-sensor/32708877914.html<br />
<br />
Typically the microwave part of these consists of a single transistor with a rectangular area on one leg and a meandering trace (with lots of vias to the other side) on the other leg.<br />
The output of this circuit seems to go into a chip very much like the ones used in PIR sensors.<br />
<br />
See also https://github.com/jdesbonnet/RCWL-0516 for a reverse engineering effort of these doppler radar modules.<br />
<br />
=== Bare-bones Arduino bat detector ===<br />
This is an idea for a very basic heterodyne bat detector, doing signal processing on an Arduino, requiring minimal external components.<br />
<br />
The basic principle of a heterodyne detector is that it just mixes (multiplies) the audio signal with a square wave, low-pass filters the result and puts it on a speaker.<br />
<br />
Multiplying with a square wave can also be considered to be just alternatively inverting and not-inverting the signal.<br />
So if you sample an ultrasonic signal at twice the rate you want to multiply, you can just subtract odd samples from even samples and low-pass filter that.<br />
<br />
How this can be done in an AVR Arduino:<br />
* sample the audio signal at twice the detection frequency, say 84 kHz. An AVR should just be able to do that.<br />
* apply a 1-pole IIR high-pass filter to remove DC bias, this takes one shift instruction and one addition.<br />
* multiply by the detection frequency, this means just inverting the odd samples.<br />
* low-pass filter the signal, this can be done using a moving average filter, say 16 samples long (first null at 5.25 kHz). Theoretically, averaging 16 samples should result in two bits extra accuracy. This operation takes some storage, an addition and a subtraction.<br />
* output the filtered signal using PWM, possibly at the same rate that we are sampling the input audio.<br />
<br />
The microphone can be a 40 kHz piezo transducer, to keep it cheap (but also limited to 40 kHz).<br />
The pre-amplifier can be a single transistor with some resistors around it, providing about 40x gain.<br />
The arduino does the signal processing (mixing, low-pass filter) to shift the bat audio to human range.<br />
The speaker amplifier can just be a simple two transistor push-pull circuit, since the output from the Arduino is digital/PWM.<br />
<br />
==== AVR Arduino sample rate ====<br />
As far as I understand, the ADC clock can be set to 1 MHz.<br />
Conversion takes 13 cycles, so this can be a problem to reach a sample rate above 80 kHz.<br />
<br />
=== Indoor radar speed sign ===<br />
This idea about placing a simple IQ-output radar sensor indoors in the hacker space, do some basic signal processing on the IQ doppler signal and determine movement speed and direction, then display this on a LED display.<br />
This is of no immediate practical use other than fun, but helps me to gain a bit more experience with microwave radar sensors and eventually build a more effective setup for detecting/counting bats flying in and out of a roost.<br />
<br />
Implement this on a PSOC5 platform or on the STM32 using Arduino.</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Karaburan&diff=35046Karaburan2026-02-07T21:47:40Z<p>Bertrik Sikken: /* Water measurement probes */</p>
<hr />
<div>{{Project<br />
|Name=Karaburan<br />
|Picture=karaburan.png<br />
|Omschrijving=Monitoring water quality<br />
|Status=In progress<br />
|Contact=bertrik<br />
}}<br />
<br />
== Next steps ==<br />
* <s>engage with PX4 community on getting a feel if this is useful to use and if so, how to get started</s><br />
* <s>figure out how to duplicate an MQTT stream</s> don't bother<br />
* write python scripts<br />
** <s>arduino turbidity</s> don't bother<br />
** <s>turbidity-to-mqtt</s> maybe make this ROS module<br />
** <s>HID-to-mqtt</s> maybe make this ROS module<br />
** position/velocity listener script: latitude, longitude, altitude, heading/bearing/track/whatever, velocity<br />
* hook things into systemd / udev<br />
* analoog in op de pi:<br />
** https://elektronicavoorjou.nl/product/adc-pi/<br />
** https://www.123materialen.com/products/zeer-nauwkeurige-ads1256-dac8552-ad-da-board-voor-raspberry-pi_1676153<br />
** FreeJoy project<br />
* UPS voor pi: https://elektronicavoorjou.nl/product/raspberry-pi-ups-hat/<br />
* 1-wire stuff:<br />
** 1-wire adapter emulation on an stm32: https://github.com/alitekin2fx/stm32_ds2480_emu<br />
** owfs.org for easy interfacing with multiple 1-wire devices in a hierarchical way on linux<br />
* Figure out the udev/hotplug mess, we probably need this because many of our peripherals use a serial port:<br />
** in how many places can we store the udev renaming logic (config files)<br />
** can we automate this, make it user friendlier, e.g. some kind of "insert device X now" script<br />
<br />
Check:<br />
* https://www.rtvnoord.nl/natuur/1215705/vuilrobot-maakt-jachthaven-winschoten-schoon-beter-dan-met-een-schepnet<br />
<br />
=== USB HID as analog input ===<br />
An stm32 based bluepill board can be flashed with firmware to allow its analog inputs to be exposed as USB HID sliders.<br />
<br />
Flashing the bluepill with openocd to the freejoy firmware:<br />
* install openocd<br />
sudo apt install openocd<br />
* connect an stlinkv2 to an stm32 bluepill, connect the stlinkv2 to USB<br />
* flash the freejoy firmware as follows:<br />
** download the firmware from https://github.com/FreeJoy-Team/FreeJoy<br />
** create a symlink to the hex file called firmware.hex<br />
** flash the firmware from the command line<br />
openocd -s /usr/share/openocd/scripts -f interface/stlink.cfg -f target/stm32f1x.cfg -c init -c "program firmware.hex verify reset exit"<br />
* watch the kernel logs<br />
sudo dmesg -w<br />
* connect the stm32 using a USB cable<br />
* download the freejoy configurator from https://github.com/FreeJoy-Team/FreeJoyConfiguratorQt<br />
* start the configurator and load the karaburan.cfg setting<br />
* Write config to device -> it should reboot now and come up with the new settings<br />
<br />
Verify that it works:<br />
* install the evtest package<br />
* run<br />
evtest /dev/input/by-id/usb-FreeJoy_FreeJoy_v1.7.1-event-if00<br />
<br />
See also https://github.com/vostrenkov/EazyJoy<br />
<br />
=== influxdb ===<br />
See https://hub.docker.com/_/influxdb<br />
<br />
See https://github.com/bertrik/karaburan/tree/master/influxdb<br />
<br />
=== ROS ===<br />
Investigation:<br />
* Use ROS 2, not the old ROS 1<br />
* Cannot work comfortably with debian, works best with ubuntu<br />
* Using gpsd:<br />
** install ros-jazzy-desktop<br />
** ros2 launch gpsd_client gpsd_client-launch.py<br />
<br />
== Introduction ==<br />
Topics:<br />
* air quality sensors<br />
** ammonia<br />
** NOx<br />
* water chemical analysis<br />
** nitrates<br />
** ammonia<br />
** dissolved oxygen<br />
** sulfide/sulfate<br />
** phosphates?<br />
** salinity (chlorides?)<br />
* water physical analysis<br />
** temperature<br />
** clarity/turbidity -> investigate standard ways of measuring/expressing this<br />
** conductivity/total dissolved solids<br />
** water properties by light reflection, hyperspectral/polarity<br />
** depth?<br />
* boat control<br />
** trajectory -> steering<br />
** idea: interface with the remote control, not with the boat<br />
** idea: find a boat with easily hackable remote control protocol<br />
** idea: can we get sensor data over this link too, e.g. GPS?<br />
* camera control<br />
* post-processing<br />
** data presentation<br />
*** video/photo stitching<br />
*** time lapse view<br />
*** map view of properties<br />
* use cases<br />
** verify with domain experts, how to engage?<br />
** slootview, under/above water<br />
** minimum viable prototype<br />
** high-res measurement by location, by time<br />
* materials<br />
** boat selection<br />
** processing platform selection<br />
** communication platform selection<br />
<br />
== Investigate RTK GPS ==<br />
Goal: figure out if it is practically possible to achieve cm resolution with a 200-euro GPS and a free correction service: YES<br />
<br />
* https://www.nsgi.nl/referentiepunten-en-gnss-data/gnss-data/real-time-streams public correction data service<br />
* https://www.ardusimple.nl/rtk-in-5-minutes/<br />
* RTK in action https://www.youtube.com/watch?v=Oc1LBFDj2MA<br />
* Use with Linux / gpsd: https://stackoverflow.com/questions/77314115/drotek-gpsd-and-ntrip-correction-data-for-precise-positioning ?<br />
* Chipsets<br />
** Quectel LC29H (default: 115200 bps)<br />
*** review: see https://rtklibexplorer.wordpress.com/2024/04/28/dual-frequency-rtk-for-less-than-60-with-the-quectel-lc29hea/<br />
*** configuration: https://rtklibexplorer.wordpress.com/2024/05/06/configuring-the-quectel-lc29hea-receiver-for-real-time-rtk-solutions/<br />
** uBLOX ZED-F9P<br />
* Boards<br />
** UM980 / UM982<br />
<br />
Edit /etc/default/gpsd, set GPSD_OPTIONS:<br />
GPSD_OPTIONS="-Gn ntrip://user:pass@ntrip.kadaster.nl:2101/CBW100NLD0"<br />
Option -G exposes the control socket on all network interfaces, option -n keeps the GPS active if there is no one currently connected.<br />
<br />
Plotting live location on a map:<br />
* Configure gpsd to expose its socket to the outside world: last section of https://gpsd.gitlab.io/gpsd/troubleshooting.html<br />
* In QGIS, press ctrl+0 to show the GPS information tab, enter the name of the remote gpsd (port 2947)<br />
<br />
Station at Stolwijk (close to Gouda): https://gnss1.tudelft.nl/dpga/station/Stolwijk.html#STWK ?<br />
<br />
Starting from the command line:<br />
* stop gpsd.socket<br />
sudo systemctl stop gpsd.socket<br />
* run from command line<br />
sudo /usr/sbin/gpsd -Gn -D 1 -N /dev/ttyUSB0 .... (not sure yet)<br />
<br />
=== Validation ===<br />
How to show that RTK GPS is actually accurate?<br />
<br />
* Relative positioning: with an "fix RTK" solution, place the antenna at 4 points 25cm apart, each point for 20 seconds or so -> you see 4 distinct clusters of points<br />
* Positioning over short time: put it in a fixed location, make sure that it has "fix RTK" solution, take 100 measurements or so -> determine the radius of the circle that contains 90% of the points<br />
* Positioning over longer time: do this for (say) an hour<br />
* Absolute positioning: look up a national reference point, for example "RD-punt 389346", located on the Sluisdijk between Gouda and Moordrecht. Technical data: https://www.nsgi.nl/iv-api/rdinfo/rdpoint/389346<br />
** see https://www.nsgi.nl/referentiepunten-en-gnss-data/informatie-referentiepunten/rdinfo and enter 389346<br />
** latitude: 51° 59' 49,64048" , longitude: 4° 41' 19,90765", or 51.99712236/4.68886324<br />
<br />
==== Comparison with reference coordinate ====<br />
On october 4th 2024, we took the RTK GPS to a kernnet reference point at 51.99712236/4.68886324, results below:<br />
<br />
From https://www.nsgi.nl/iv-api/rdinfo/rdpoint/389346:<br />
* Year 2021: "51 59 49,64004", "4 41 19,90584", 48.039. In decimal degrees that is <br />
<br />
Differences between the reference point and the measurements are calculated to easting ('X') and northing ('Y'), unit meter. To calculate distance in meters, we use a linear approximation:<br />
* For dy: 40075km/360 = 111,319 m/deg<br />
* For dx: dy * cos(latitude) = 68,549 m/deg<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|+ Measurements + deviations<br />
|-<br />
! Name !! Latitude !! Longitude !! dx (m) !! dy (m) !! absolute (m) !! Remark<br />
|-<br />
| Reference 2012 || 51.99712236 || 4.68886324 || - || - || 0 || by definition<br />
|-<br />
| Reference 2021 || 51.99712223 || 4.68886273 || - || - || 0 || by definition<br />
|-<br />
| Screenshot 1 || 51.99712217 || 4.68886567 || 0.167 || -0.021 || 0.168 || - <br />
|-<br />
| Screenshot 2 || 51.99712200 || 4.68886533 || 0.143 || -0.040 || 0.149 || -<br />
|-<br />
| Meting 1 || 51.9971220 || 4.6888663 || 0.210 || -0.040 || 0.214 || -<br />
|-<br />
| Meting 2 || 51.9971222 || 4.6888660 || 0.189 || -0.018 || 0.190 || -<br />
|-<br />
| Average || - || - || 0.177 || -0.030 || 0.180 || -<br />
|}<br />
<br />
According to [https://www.unavco.org/software/geodetic-utilities/plate-motion-calculator/plate-motion-calculator.html this page], the rate of movement is about<br />
15.75mm/year to the north and 17.45 mm/year to the east (ITRF2020 model).<br />
Over 12 years, that amounts to 0.189m north and 0.209m east.<br />
<br />
== Air quality sensors ==<br />
<br />
=== Nitrogen compounds in air ===<br />
According to https://www.rivm.nl/stikstof/monitoren-advies-onderzoek/overzicht-stikstofmetingen/metingen-stikstof-in-de-lucht average (typical?) values of<br />
* Ammonia (NH3): 6.7 ug/m3 (9.6 ppb)<br />
* NOx: 27.3 ug/m3<br />
* NO2: 18.6 ug/m3 (9.9 ppb)<br />
<br />
(ppb-conversion using https://www.breeze-technologies.de/blog/air-pollution-how-to-convert-between-mgm3-%C2%B5gm3-ppm-ppb/ )<br />
<br />
RIVM report on inexpensive nitrogen-in-air sensors: https://www.samenmeten.nl/sensoren-voor-no2<br />
Conclusion: most sensors are not sensitive enough to be used in typical outdoor conditions, with perhaps one exception: alphasense NO2-B43F<br />
<br />
== Sonar sensors ==<br />
Investigate this because it allows us to measure depth.<br />
<br />
AliExpress has several types of affordable sonar sensors, focused at detecting fish, but also able to measure depth.<br />
<br />
I ordered this one: https://nl.aliexpress.com/item/1005006388343879.html<br />
* 125 kHz main frequency, range up to 200 ft deep (about 60m)<br />
* bluetooth low-power interface (basically serial-over-BLE)<br />
* built-in battery, powers on automatically when submerged<br />
* reports 120-element array with raw sonar return intensity-vs-depth<br />
* measures water temperature<br />
* about 45 euro<br />
<br />
Fish helper pro application for android https://apkpure.com/fish-helper-pro/com.fishfinderpro.xdx<br />
<br />
=== Debug tool ===<br />
I wrote a python script to connect to it from a linux computer: https://github.com/bertrik/wireless-sonar-sensor<br />
<br />
It's connects to a "Fish Helper Pro" wireless sonar sensor over bluetooth low-energy, reports depth and temperature<br />
<br />
=== ROS2 integration ===<br />
The most appropriate message for a simple range would be: https://docs.ros2.org/foxy/api/sensor_msgs/msg/Range.html<br />
<br />
There are other messages to perhaps report the raw echo return array.<br />
<br />
== Water physical analysis ==<br />
=== Turbidity / clarity ===<br />
See https://en.wikipedia.org/wiki/Turbidity<br />
<br />
Aliexpress sensor '''TS-300B''': https://nl.aliexpress.com/item/1005006732956937.html<br />
Has a range 0 ~ 1000 ± 30 NTU<br />
<br />
Order of magnitude for turbidity:<br />
* Drinking water upper limit: '''4 NTU''' (European turbidity standard for drinking water)<br />
* Ambient water: 10-150 NTU. The US state of Washington use a "background" value of '''50 NTU''' as reference.<br />
<br />
(see https://en.wikipedia.org/wiki/Turbidity#Standards_and_test_methods )<br />
<br />
So the Aliexpress sensor is suited only for "dirty" water.<br />
<br />
=== Water measurement probes ===<br />
I bought this one: Tuya compatible BT785 EC meter: https://nl.aliexpress.com/i/1005007462079781.html inexpensive, focused on EC, runs on 4x LR44.<br />
Speaks the TuYa protocol (requires a secret key that you can fetch through the developer console).<br />
This is quite cumbersome: you have to register as a developer, fetch the key before time runs out and developer access is limited.<br />
<br />
Does NOT speak the universal serialport access protocol as described here:<br />
https://developer.tuya.com/en/docs/iot/tuya-cloud-universal-serial-port-access-protocol?id=K9hhi0xxtn9cb<br />
<br />
* https://nl.aliexpress.com/item/1005003784454381.html BLE-9908 Inexpensie "Yieryi" PH/EC/Temp probe with bluetooth and app, about E25,- (Uses 3x LR44 coin cell batteries)<br />
* Several different models: https://nl.aliexpress.com/item/1005007810989801.html<br />
** EZ9901: TDS/pH/temp<br />
** EZ9902: EC/pH/temp<br />
** EZ9908: EC/TDS/pH/temp<br />
** EZ9909: TDS/EC/pH/salt/temp<br />
* The bluetooth versions are probably as above, with numbers like BLE9902 and BLE9908<br />
* Yiery BLE9902: https://shop.yieryimeters.com/products/yieryi-ble-9902-3-in-1-digital-ph-meter-with-bluetooth-ec-and-temperature-measurement-ideal-for-water-quality-testing-in-pools-fish-tanks-hydroponics-more<br />
* BLE-EC01 is a bluetooth EC meter, can find it here https://www.amazon.com/BLE-EC01-Smart4-TDS-Temp-Meter/dp/B0DPZZC7BV, not on AliExpress?<br />
<br />
Note:<br />
* Some probes indicate EC (electrical conductivity), other indicate TDS (total dissolved liquids). TDS is derived from EC (knowing the liquid type). EC is the more universal/fundamental property!<br />
* EC is typically expressed in uS/cm or mS/cm (micro or milli siemens per centimeter), say 500 uS/cm for outdoor water.<br />
* EC is temperature dependent, typically you need the value extrapolated to 25 degrees Celcius. Temperature-EC correlation rule of thumb: about 2% more conductive per K.<br />
* pH sensors are almost by definition fragile and last only a limited time, so probably don't bother trying to use one at all. The pH of outdoor water might not be that interesting to measure.<br />
* I expect the non-TuYa meters to use an easier to handle bluetooth protocol, avoiding the need for complicated encryption with a key that can only be fetched for a limited time using a tuya developer account.<br />
<br />
== Boat control ==<br />
Typically the wireless link looks like this:<br />
* 2.4 GHz working frequency<br />
* 500m range<br />
<br />
Interesting links:<br />
* Flytec-2011 remote control https://nl.aliexpress.com/item/1005002984723718.html<br />
* Replacement board for various boats with "18" in their type number: https://nl.aliexpress.com/item/1005006115484716.html<br />
* DIY Multi-protocol module: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module<br />
<br />
=== remote control ===<br />
Image of remote control RF chip:<br />
[...]<br />
<br />
Parts:<br />
* 12.000 MHz crystal/oscillator<br />
* 16-pin control chip: 20_CL6L071<br />
* 6-pin RF chip: 1110 / VKA3, could be an rx/tx switch, amplifier or filter circuit<br />
<br />
See also: https://www.open-tx.org/<br />
<br />
Next steps:<br />
* map out the connections between the mainboard and the rf board, expected: VCC, GND, spi ?<br />
<br />
== Use cases ==<br />
material:<br />
* https://www.youtube.com/watch?v=cMk0bGvIU1E<br />
* https://iplo.nl/thema/water/oppervlaktewater/kaderrichtlijn-water<br />
* kaartje: https://krw-nutrend.netlify.app/ -> 2 meetpunten op de reeuwijkse plassen, tijdresolutie is 1 jaar?<br />
<br />
Useful distinction, typically used in documents/guidelines:<br />
* chemical quality, what substances are present in the water?<br />
* biological / ecology quality, what kind of living organisms live in the water?<br />
<br />
=== Reeuwijkse plassen ===<br />
See<br />
* https://www.rijnland.net/wat-doet-rijnland/in-uw-buurt/reeuwijkse-plassen/ their stated goal: CLEAR WATER<br />
* https://www.rijnland.net/regels-op-een-rij/subsidies-en-andere-financi%C3%ABle-bijdragen/<br />
<br />
potential applications:<br />
* inspect water sides (oever) over time<br />
* underwater camera: detect invasive cray fish<br />
* sample water properties at high spatial resolution, high time resolution<br />
* early detection of indicators for cyanobacteria: temperature and nutrients<br />
<br />
=== Detect/find pollution source ===<br />
* ...<br />
<br />
== Implementation ==<br />
<br />
=== udev handling of serial ports ===<br />
Many peripheral devices are connected through serial.<br />
The plan is to have an udev config file with renaming rules, so each peripheral gets a stable name in /dev .<br />
The plan is also to create the udev config using some python: insert device X now -> write line to udev config.<br />
<br />
The udev config file is:<br />
/etc/udev/rules.d/99-usb-serial.rules<br />
<br />
<pre><br />
# LIDAR serial converter<br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="ttyLIDAR", MODE="0660", GROUP="dialout"<br />
# quectel GPS<br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", SYMLINK+="ttyGPS", MODE="0660", GROUP="dialout"<br />
# ublox GPS<br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="ttyGPS", MODE="0660", GROUP="dialout"<br />
</pre><br />
<br />
An USB-nano also appears to have a USB vendor/product id of 1a86/7523 ("USB2.0-Serial") ... same as the quectel GPS?<br />
<br />
Same for "AI thinker" USB-serial: vendor/product id of 1a86/7523 (product: "USB2.0-Serial")<br />
<br />
To (re)load the properties:<br />
<pre><br />
sudo udevadm control --reload-rules<br />
</pre><br />
<br />
=== reading temperature sensor ===<br />
The idea is to to use a DB18B20 temperature sensor, read it using an arduino nano board acting as a 1-wire adapter.<br />
Use openwire-fs as user-side openwire software http://owfs.org<br />
<br />
Preparation:<br />
* Add the regular user to the 'dialout' group, so it can access serial ports<br />
sudo adduser <name> dialout<br />
<br />
Setting up the hardware:<br />
* connect the DS18B20 to the connector board with the pull-ups<br />
* wire the connector board to the arduino nano, see ...<br />
* plug the arduino nano in the pi<br />
<br />
Setting up the software:<br />
* Install openwire fs<br />
sudo apt install owfs<br />
* Create the openwire fs mountpoint<br />
sudo mkdir /mnt/1wire<br />
* Configure owfs, edit /etc/owfs.conf<br />
server: device = /dev/ttyUSB0<br />
mountpoint = /mnt/1wire<br />
allow_other<br />
(comment out the line with the FAKE devices)<br />
* Configure systemd services<br />
sudo systemctl enable owserver owhttpd<br />
sudo systemctl disable owftpd<br />
* Start the systemd service<br />
sudo systemctl start owserver owhttpd<br />
* Check the logs<br />
sudo journalctl -xeu owserver -f<br />
* Open a browser to view the web interface<br />
http://localhost:2121 or<br />
http://raspberrypi.local:2121</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Karaburan&diff=35045Karaburan2026-02-07T21:00:39Z<p>Bertrik Sikken: /* Water measurement probes */</p>
<hr />
<div>{{Project<br />
|Name=Karaburan<br />
|Picture=karaburan.png<br />
|Omschrijving=Monitoring water quality<br />
|Status=In progress<br />
|Contact=bertrik<br />
}}<br />
<br />
== Next steps ==<br />
* <s>engage with PX4 community on getting a feel if this is useful to use and if so, how to get started</s><br />
* <s>figure out how to duplicate an MQTT stream</s> don't bother<br />
* write python scripts<br />
** <s>arduino turbidity</s> don't bother<br />
** <s>turbidity-to-mqtt</s> maybe make this ROS module<br />
** <s>HID-to-mqtt</s> maybe make this ROS module<br />
** position/velocity listener script: latitude, longitude, altitude, heading/bearing/track/whatever, velocity<br />
* hook things into systemd / udev<br />
* analoog in op de pi:<br />
** https://elektronicavoorjou.nl/product/adc-pi/<br />
** https://www.123materialen.com/products/zeer-nauwkeurige-ads1256-dac8552-ad-da-board-voor-raspberry-pi_1676153<br />
** FreeJoy project<br />
* UPS voor pi: https://elektronicavoorjou.nl/product/raspberry-pi-ups-hat/<br />
* 1-wire stuff:<br />
** 1-wire adapter emulation on an stm32: https://github.com/alitekin2fx/stm32_ds2480_emu<br />
** owfs.org for easy interfacing with multiple 1-wire devices in a hierarchical way on linux<br />
* Figure out the udev/hotplug mess, we probably need this because many of our peripherals use a serial port:<br />
** in how many places can we store the udev renaming logic (config files)<br />
** can we automate this, make it user friendlier, e.g. some kind of "insert device X now" script<br />
<br />
Check:<br />
* https://www.rtvnoord.nl/natuur/1215705/vuilrobot-maakt-jachthaven-winschoten-schoon-beter-dan-met-een-schepnet<br />
<br />
=== USB HID as analog input ===<br />
An stm32 based bluepill board can be flashed with firmware to allow its analog inputs to be exposed as USB HID sliders.<br />
<br />
Flashing the bluepill with openocd to the freejoy firmware:<br />
* install openocd<br />
sudo apt install openocd<br />
* connect an stlinkv2 to an stm32 bluepill, connect the stlinkv2 to USB<br />
* flash the freejoy firmware as follows:<br />
** download the firmware from https://github.com/FreeJoy-Team/FreeJoy<br />
** create a symlink to the hex file called firmware.hex<br />
** flash the firmware from the command line<br />
openocd -s /usr/share/openocd/scripts -f interface/stlink.cfg -f target/stm32f1x.cfg -c init -c "program firmware.hex verify reset exit"<br />
* watch the kernel logs<br />
sudo dmesg -w<br />
* connect the stm32 using a USB cable<br />
* download the freejoy configurator from https://github.com/FreeJoy-Team/FreeJoyConfiguratorQt<br />
* start the configurator and load the karaburan.cfg setting<br />
* Write config to device -> it should reboot now and come up with the new settings<br />
<br />
Verify that it works:<br />
* install the evtest package<br />
* run<br />
evtest /dev/input/by-id/usb-FreeJoy_FreeJoy_v1.7.1-event-if00<br />
<br />
See also https://github.com/vostrenkov/EazyJoy<br />
<br />
=== influxdb ===<br />
See https://hub.docker.com/_/influxdb<br />
<br />
See https://github.com/bertrik/karaburan/tree/master/influxdb<br />
<br />
=== ROS ===<br />
Investigation:<br />
* Use ROS 2, not the old ROS 1<br />
* Cannot work comfortably with debian, works best with ubuntu<br />
* Using gpsd:<br />
** install ros-jazzy-desktop<br />
** ros2 launch gpsd_client gpsd_client-launch.py<br />
<br />
== Introduction ==<br />
Topics:<br />
* air quality sensors<br />
** ammonia<br />
** NOx<br />
* water chemical analysis<br />
** nitrates<br />
** ammonia<br />
** dissolved oxygen<br />
** sulfide/sulfate<br />
** phosphates?<br />
** salinity (chlorides?)<br />
* water physical analysis<br />
** temperature<br />
** clarity/turbidity -> investigate standard ways of measuring/expressing this<br />
** conductivity/total dissolved solids<br />
** water properties by light reflection, hyperspectral/polarity<br />
** depth?<br />
* boat control<br />
** trajectory -> steering<br />
** idea: interface with the remote control, not with the boat<br />
** idea: find a boat with easily hackable remote control protocol<br />
** idea: can we get sensor data over this link too, e.g. GPS?<br />
* camera control<br />
* post-processing<br />
** data presentation<br />
*** video/photo stitching<br />
*** time lapse view<br />
*** map view of properties<br />
* use cases<br />
** verify with domain experts, how to engage?<br />
** slootview, under/above water<br />
** minimum viable prototype<br />
** high-res measurement by location, by time<br />
* materials<br />
** boat selection<br />
** processing platform selection<br />
** communication platform selection<br />
<br />
== Investigate RTK GPS ==<br />
Goal: figure out if it is practically possible to achieve cm resolution with a 200-euro GPS and a free correction service: YES<br />
<br />
* https://www.nsgi.nl/referentiepunten-en-gnss-data/gnss-data/real-time-streams public correction data service<br />
* https://www.ardusimple.nl/rtk-in-5-minutes/<br />
* RTK in action https://www.youtube.com/watch?v=Oc1LBFDj2MA<br />
* Use with Linux / gpsd: https://stackoverflow.com/questions/77314115/drotek-gpsd-and-ntrip-correction-data-for-precise-positioning ?<br />
* Chipsets<br />
** Quectel LC29H (default: 115200 bps)<br />
*** review: see https://rtklibexplorer.wordpress.com/2024/04/28/dual-frequency-rtk-for-less-than-60-with-the-quectel-lc29hea/<br />
*** configuration: https://rtklibexplorer.wordpress.com/2024/05/06/configuring-the-quectel-lc29hea-receiver-for-real-time-rtk-solutions/<br />
** uBLOX ZED-F9P<br />
* Boards<br />
** UM980 / UM982<br />
<br />
Edit /etc/default/gpsd, set GPSD_OPTIONS:<br />
GPSD_OPTIONS="-Gn ntrip://user:pass@ntrip.kadaster.nl:2101/CBW100NLD0"<br />
Option -G exposes the control socket on all network interfaces, option -n keeps the GPS active if there is no one currently connected.<br />
<br />
Plotting live location on a map:<br />
* Configure gpsd to expose its socket to the outside world: last section of https://gpsd.gitlab.io/gpsd/troubleshooting.html<br />
* In QGIS, press ctrl+0 to show the GPS information tab, enter the name of the remote gpsd (port 2947)<br />
<br />
Station at Stolwijk (close to Gouda): https://gnss1.tudelft.nl/dpga/station/Stolwijk.html#STWK ?<br />
<br />
Starting from the command line:<br />
* stop gpsd.socket<br />
sudo systemctl stop gpsd.socket<br />
* run from command line<br />
sudo /usr/sbin/gpsd -Gn -D 1 -N /dev/ttyUSB0 .... (not sure yet)<br />
<br />
=== Validation ===<br />
How to show that RTK GPS is actually accurate?<br />
<br />
* Relative positioning: with an "fix RTK" solution, place the antenna at 4 points 25cm apart, each point for 20 seconds or so -> you see 4 distinct clusters of points<br />
* Positioning over short time: put it in a fixed location, make sure that it has "fix RTK" solution, take 100 measurements or so -> determine the radius of the circle that contains 90% of the points<br />
* Positioning over longer time: do this for (say) an hour<br />
* Absolute positioning: look up a national reference point, for example "RD-punt 389346", located on the Sluisdijk between Gouda and Moordrecht. Technical data: https://www.nsgi.nl/iv-api/rdinfo/rdpoint/389346<br />
** see https://www.nsgi.nl/referentiepunten-en-gnss-data/informatie-referentiepunten/rdinfo and enter 389346<br />
** latitude: 51° 59' 49,64048" , longitude: 4° 41' 19,90765", or 51.99712236/4.68886324<br />
<br />
==== Comparison with reference coordinate ====<br />
On october 4th 2024, we took the RTK GPS to a kernnet reference point at 51.99712236/4.68886324, results below:<br />
<br />
From https://www.nsgi.nl/iv-api/rdinfo/rdpoint/389346:<br />
* Year 2021: "51 59 49,64004", "4 41 19,90584", 48.039. In decimal degrees that is <br />
<br />
Differences between the reference point and the measurements are calculated to easting ('X') and northing ('Y'), unit meter. To calculate distance in meters, we use a linear approximation:<br />
* For dy: 40075km/360 = 111,319 m/deg<br />
* For dx: dy * cos(latitude) = 68,549 m/deg<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|+ Measurements + deviations<br />
|-<br />
! Name !! Latitude !! Longitude !! dx (m) !! dy (m) !! absolute (m) !! Remark<br />
|-<br />
| Reference 2012 || 51.99712236 || 4.68886324 || - || - || 0 || by definition<br />
|-<br />
| Reference 2021 || 51.99712223 || 4.68886273 || - || - || 0 || by definition<br />
|-<br />
| Screenshot 1 || 51.99712217 || 4.68886567 || 0.167 || -0.021 || 0.168 || - <br />
|-<br />
| Screenshot 2 || 51.99712200 || 4.68886533 || 0.143 || -0.040 || 0.149 || -<br />
|-<br />
| Meting 1 || 51.9971220 || 4.6888663 || 0.210 || -0.040 || 0.214 || -<br />
|-<br />
| Meting 2 || 51.9971222 || 4.6888660 || 0.189 || -0.018 || 0.190 || -<br />
|-<br />
| Average || - || - || 0.177 || -0.030 || 0.180 || -<br />
|}<br />
<br />
According to [https://www.unavco.org/software/geodetic-utilities/plate-motion-calculator/plate-motion-calculator.html this page], the rate of movement is about<br />
15.75mm/year to the north and 17.45 mm/year to the east (ITRF2020 model).<br />
Over 12 years, that amounts to 0.189m north and 0.209m east.<br />
<br />
== Air quality sensors ==<br />
<br />
=== Nitrogen compounds in air ===<br />
According to https://www.rivm.nl/stikstof/monitoren-advies-onderzoek/overzicht-stikstofmetingen/metingen-stikstof-in-de-lucht average (typical?) values of<br />
* Ammonia (NH3): 6.7 ug/m3 (9.6 ppb)<br />
* NOx: 27.3 ug/m3<br />
* NO2: 18.6 ug/m3 (9.9 ppb)<br />
<br />
(ppb-conversion using https://www.breeze-technologies.de/blog/air-pollution-how-to-convert-between-mgm3-%C2%B5gm3-ppm-ppb/ )<br />
<br />
RIVM report on inexpensive nitrogen-in-air sensors: https://www.samenmeten.nl/sensoren-voor-no2<br />
Conclusion: most sensors are not sensitive enough to be used in typical outdoor conditions, with perhaps one exception: alphasense NO2-B43F<br />
<br />
== Sonar sensors ==<br />
Investigate this because it allows us to measure depth.<br />
<br />
AliExpress has several types of affordable sonar sensors, focused at detecting fish, but also able to measure depth.<br />
<br />
I ordered this one: https://nl.aliexpress.com/item/1005006388343879.html<br />
* 125 kHz main frequency, range up to 200 ft deep (about 60m)<br />
* bluetooth low-power interface (basically serial-over-BLE)<br />
* built-in battery, powers on automatically when submerged<br />
* reports 120-element array with raw sonar return intensity-vs-depth<br />
* measures water temperature<br />
* about 45 euro<br />
<br />
Fish helper pro application for android https://apkpure.com/fish-helper-pro/com.fishfinderpro.xdx<br />
<br />
=== Debug tool ===<br />
I wrote a python script to connect to it from a linux computer: https://github.com/bertrik/wireless-sonar-sensor<br />
<br />
It's connects to a "Fish Helper Pro" wireless sonar sensor over bluetooth low-energy, reports depth and temperature<br />
<br />
=== ROS2 integration ===<br />
The most appropriate message for a simple range would be: https://docs.ros2.org/foxy/api/sensor_msgs/msg/Range.html<br />
<br />
There are other messages to perhaps report the raw echo return array.<br />
<br />
== Water physical analysis ==<br />
=== Turbidity / clarity ===<br />
See https://en.wikipedia.org/wiki/Turbidity<br />
<br />
Aliexpress sensor '''TS-300B''': https://nl.aliexpress.com/item/1005006732956937.html<br />
Has a range 0 ~ 1000 ± 30 NTU<br />
<br />
Order of magnitude for turbidity:<br />
* Drinking water upper limit: '''4 NTU''' (European turbidity standard for drinking water)<br />
* Ambient water: 10-150 NTU. The US state of Washington use a "background" value of '''50 NTU''' as reference.<br />
<br />
(see https://en.wikipedia.org/wiki/Turbidity#Standards_and_test_methods )<br />
<br />
So the Aliexpress sensor is suited only for "dirty" water.<br />
<br />
=== Water measurement probes ===<br />
I bought this one: Tuya compatible BT785 EC meter: https://nl.aliexpress.com/i/1005007462079781.html inexpensive, focused on EC, runs on 4x LR44.<br />
Speaks the TuYa protocol (requires a secret key that you can fetch through the developer console).<br />
This is quite cumbersome: you have to register as a developer, fetch the key before time runs out and developer access is limited.<br />
<br />
Does NOT speak the universal serialport access protocol as described here:<br />
https://developer.tuya.com/en/docs/iot/tuya-cloud-universal-serial-port-access-protocol?id=K9hhi0xxtn9cb<br />
<br />
* https://nl.aliexpress.com/item/1005003784454381.html BLE-9908 Inexpensie "Yieryi" PH/EC/Temp probe with bluetooth and app, about E25,- (Uses 3x LR44 coin cell batteries)<br />
* Several different models: https://nl.aliexpress.com/item/1005007810989801.html<br />
** EZ9901: TDS/pH/temp<br />
** EZ9902: EC/pH/temp<br />
** EZ9908: EC/TDS/pH/temp<br />
** EZ9909: TDS/EC/pH/salt/temp<br />
* The bluetooth versions are probably as above, with numbers like BLE9902 and BLE9908<br />
* Yiery BLE9902: https://shop.yieryimeters.com/products/yieryi-ble-9902-3-in-1-digital-ph-meter-with-bluetooth-ec-and-temperature-measurement-ideal-for-water-quality-testing-in-pools-fish-tanks-hydroponics-more<br />
* BLE-EC01 is a bluetooth EC meter, can find it here https://www.amazon.com/BLE-EC01-Smart4-TDS-Temp-Meter/dp/B0DPZZC7BV, not on AliExpress?<br />
<br />
Note:<br />
* Some probes indicate EC (electrical conductivity), other indicate TDS (total dissolved liquids). TDS is derived from EC (knowing the liquid type). EC is the more universal/fundamental property!<br />
* EC is typically expressed in uS/cm or mS/cm (micro or milli siemens per centimeter), say 500 uS/cm for outdoor water.<br />
* EC is temperature dependent, typically you need the value extrapolated to 25 degrees Celcius. Temperature-EC correlation rule of thumb: about 2% more conductive per K.<br />
* pH sensors are almost by definition fragile and last only a limited time, so probably don't bother trying to use one at all. The pH of outdoor water might not be that interesting to measure.<br />
<br />
== Boat control ==<br />
Typically the wireless link looks like this:<br />
* 2.4 GHz working frequency<br />
* 500m range<br />
<br />
Interesting links:<br />
* Flytec-2011 remote control https://nl.aliexpress.com/item/1005002984723718.html<br />
* Replacement board for various boats with "18" in their type number: https://nl.aliexpress.com/item/1005006115484716.html<br />
* DIY Multi-protocol module: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module<br />
<br />
=== remote control ===<br />
Image of remote control RF chip:<br />
[...]<br />
<br />
Parts:<br />
* 12.000 MHz crystal/oscillator<br />
* 16-pin control chip: 20_CL6L071<br />
* 6-pin RF chip: 1110 / VKA3, could be an rx/tx switch, amplifier or filter circuit<br />
<br />
See also: https://www.open-tx.org/<br />
<br />
Next steps:<br />
* map out the connections between the mainboard and the rf board, expected: VCC, GND, spi ?<br />
<br />
== Use cases ==<br />
material:<br />
* https://www.youtube.com/watch?v=cMk0bGvIU1E<br />
* https://iplo.nl/thema/water/oppervlaktewater/kaderrichtlijn-water<br />
* kaartje: https://krw-nutrend.netlify.app/ -> 2 meetpunten op de reeuwijkse plassen, tijdresolutie is 1 jaar?<br />
<br />
Useful distinction, typically used in documents/guidelines:<br />
* chemical quality, what substances are present in the water?<br />
* biological / ecology quality, what kind of living organisms live in the water?<br />
<br />
=== Reeuwijkse plassen ===<br />
See<br />
* https://www.rijnland.net/wat-doet-rijnland/in-uw-buurt/reeuwijkse-plassen/ their stated goal: CLEAR WATER<br />
* https://www.rijnland.net/regels-op-een-rij/subsidies-en-andere-financi%C3%ABle-bijdragen/<br />
<br />
potential applications:<br />
* inspect water sides (oever) over time<br />
* underwater camera: detect invasive cray fish<br />
* sample water properties at high spatial resolution, high time resolution<br />
* early detection of indicators for cyanobacteria: temperature and nutrients<br />
<br />
=== Detect/find pollution source ===<br />
* ...<br />
<br />
== Implementation ==<br />
<br />
=== udev handling of serial ports ===<br />
Many peripheral devices are connected through serial.<br />
The plan is to have an udev config file with renaming rules, so each peripheral gets a stable name in /dev .<br />
The plan is also to create the udev config using some python: insert device X now -> write line to udev config.<br />
<br />
The udev config file is:<br />
/etc/udev/rules.d/99-usb-serial.rules<br />
<br />
<pre><br />
# LIDAR serial converter<br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="ttyLIDAR", MODE="0660", GROUP="dialout"<br />
# quectel GPS<br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", SYMLINK+="ttyGPS", MODE="0660", GROUP="dialout"<br />
# ublox GPS<br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="ttyGPS", MODE="0660", GROUP="dialout"<br />
</pre><br />
<br />
An USB-nano also appears to have a USB vendor/product id of 1a86/7523 ("USB2.0-Serial") ... same as the quectel GPS?<br />
<br />
Same for "AI thinker" USB-serial: vendor/product id of 1a86/7523 (product: "USB2.0-Serial")<br />
<br />
To (re)load the properties:<br />
<pre><br />
sudo udevadm control --reload-rules<br />
</pre><br />
<br />
=== reading temperature sensor ===<br />
The idea is to to use a DB18B20 temperature sensor, read it using an arduino nano board acting as a 1-wire adapter.<br />
Use openwire-fs as user-side openwire software http://owfs.org<br />
<br />
Preparation:<br />
* Add the regular user to the 'dialout' group, so it can access serial ports<br />
sudo adduser <name> dialout<br />
<br />
Setting up the hardware:<br />
* connect the DS18B20 to the connector board with the pull-ups<br />
* wire the connector board to the arduino nano, see ...<br />
* plug the arduino nano in the pi<br />
<br />
Setting up the software:<br />
* Install openwire fs<br />
sudo apt install owfs<br />
* Create the openwire fs mountpoint<br />
sudo mkdir /mnt/1wire<br />
* Configure owfs, edit /etc/owfs.conf<br />
server: device = /dev/ttyUSB0<br />
mountpoint = /mnt/1wire<br />
allow_other<br />
(comment out the line with the FAKE devices)<br />
* Configure systemd services<br />
sudo systemctl enable owserver owhttpd<br />
sudo systemctl disable owftpd<br />
* Start the systemd service<br />
sudo systemctl start owserver owhttpd<br />
* Check the logs<br />
sudo journalctl -xeu owserver -f<br />
* Open a browser to view the web interface<br />
http://localhost:2121 or<br />
http://raspberrypi.local:2121</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=Karaburan&diff=35044Karaburan2026-02-07T20:59:17Z<p>Bertrik Sikken: /* Water measurement probes */</p>
<hr />
<div>{{Project<br />
|Name=Karaburan<br />
|Picture=karaburan.png<br />
|Omschrijving=Monitoring water quality<br />
|Status=In progress<br />
|Contact=bertrik<br />
}}<br />
<br />
== Next steps ==<br />
* <s>engage with PX4 community on getting a feel if this is useful to use and if so, how to get started</s><br />
* <s>figure out how to duplicate an MQTT stream</s> don't bother<br />
* write python scripts<br />
** <s>arduino turbidity</s> don't bother<br />
** <s>turbidity-to-mqtt</s> maybe make this ROS module<br />
** <s>HID-to-mqtt</s> maybe make this ROS module<br />
** position/velocity listener script: latitude, longitude, altitude, heading/bearing/track/whatever, velocity<br />
* hook things into systemd / udev<br />
* analoog in op de pi:<br />
** https://elektronicavoorjou.nl/product/adc-pi/<br />
** https://www.123materialen.com/products/zeer-nauwkeurige-ads1256-dac8552-ad-da-board-voor-raspberry-pi_1676153<br />
** FreeJoy project<br />
* UPS voor pi: https://elektronicavoorjou.nl/product/raspberry-pi-ups-hat/<br />
* 1-wire stuff:<br />
** 1-wire adapter emulation on an stm32: https://github.com/alitekin2fx/stm32_ds2480_emu<br />
** owfs.org for easy interfacing with multiple 1-wire devices in a hierarchical way on linux<br />
* Figure out the udev/hotplug mess, we probably need this because many of our peripherals use a serial port:<br />
** in how many places can we store the udev renaming logic (config files)<br />
** can we automate this, make it user friendlier, e.g. some kind of "insert device X now" script<br />
<br />
Check:<br />
* https://www.rtvnoord.nl/natuur/1215705/vuilrobot-maakt-jachthaven-winschoten-schoon-beter-dan-met-een-schepnet<br />
<br />
=== USB HID as analog input ===<br />
An stm32 based bluepill board can be flashed with firmware to allow its analog inputs to be exposed as USB HID sliders.<br />
<br />
Flashing the bluepill with openocd to the freejoy firmware:<br />
* install openocd<br />
sudo apt install openocd<br />
* connect an stlinkv2 to an stm32 bluepill, connect the stlinkv2 to USB<br />
* flash the freejoy firmware as follows:<br />
** download the firmware from https://github.com/FreeJoy-Team/FreeJoy<br />
** create a symlink to the hex file called firmware.hex<br />
** flash the firmware from the command line<br />
openocd -s /usr/share/openocd/scripts -f interface/stlink.cfg -f target/stm32f1x.cfg -c init -c "program firmware.hex verify reset exit"<br />
* watch the kernel logs<br />
sudo dmesg -w<br />
* connect the stm32 using a USB cable<br />
* download the freejoy configurator from https://github.com/FreeJoy-Team/FreeJoyConfiguratorQt<br />
* start the configurator and load the karaburan.cfg setting<br />
* Write config to device -> it should reboot now and come up with the new settings<br />
<br />
Verify that it works:<br />
* install the evtest package<br />
* run<br />
evtest /dev/input/by-id/usb-FreeJoy_FreeJoy_v1.7.1-event-if00<br />
<br />
See also https://github.com/vostrenkov/EazyJoy<br />
<br />
=== influxdb ===<br />
See https://hub.docker.com/_/influxdb<br />
<br />
See https://github.com/bertrik/karaburan/tree/master/influxdb<br />
<br />
=== ROS ===<br />
Investigation:<br />
* Use ROS 2, not the old ROS 1<br />
* Cannot work comfortably with debian, works best with ubuntu<br />
* Using gpsd:<br />
** install ros-jazzy-desktop<br />
** ros2 launch gpsd_client gpsd_client-launch.py<br />
<br />
== Introduction ==<br />
Topics:<br />
* air quality sensors<br />
** ammonia<br />
** NOx<br />
* water chemical analysis<br />
** nitrates<br />
** ammonia<br />
** dissolved oxygen<br />
** sulfide/sulfate<br />
** phosphates?<br />
** salinity (chlorides?)<br />
* water physical analysis<br />
** temperature<br />
** clarity/turbidity -> investigate standard ways of measuring/expressing this<br />
** conductivity/total dissolved solids<br />
** water properties by light reflection, hyperspectral/polarity<br />
** depth?<br />
* boat control<br />
** trajectory -> steering<br />
** idea: interface with the remote control, not with the boat<br />
** idea: find a boat with easily hackable remote control protocol<br />
** idea: can we get sensor data over this link too, e.g. GPS?<br />
* camera control<br />
* post-processing<br />
** data presentation<br />
*** video/photo stitching<br />
*** time lapse view<br />
*** map view of properties<br />
* use cases<br />
** verify with domain experts, how to engage?<br />
** slootview, under/above water<br />
** minimum viable prototype<br />
** high-res measurement by location, by time<br />
* materials<br />
** boat selection<br />
** processing platform selection<br />
** communication platform selection<br />
<br />
== Investigate RTK GPS ==<br />
Goal: figure out if it is practically possible to achieve cm resolution with a 200-euro GPS and a free correction service: YES<br />
<br />
* https://www.nsgi.nl/referentiepunten-en-gnss-data/gnss-data/real-time-streams public correction data service<br />
* https://www.ardusimple.nl/rtk-in-5-minutes/<br />
* RTK in action https://www.youtube.com/watch?v=Oc1LBFDj2MA<br />
* Use with Linux / gpsd: https://stackoverflow.com/questions/77314115/drotek-gpsd-and-ntrip-correction-data-for-precise-positioning ?<br />
* Chipsets<br />
** Quectel LC29H (default: 115200 bps)<br />
*** review: see https://rtklibexplorer.wordpress.com/2024/04/28/dual-frequency-rtk-for-less-than-60-with-the-quectel-lc29hea/<br />
*** configuration: https://rtklibexplorer.wordpress.com/2024/05/06/configuring-the-quectel-lc29hea-receiver-for-real-time-rtk-solutions/<br />
** uBLOX ZED-F9P<br />
* Boards<br />
** UM980 / UM982<br />
<br />
Edit /etc/default/gpsd, set GPSD_OPTIONS:<br />
GPSD_OPTIONS="-Gn ntrip://user:pass@ntrip.kadaster.nl:2101/CBW100NLD0"<br />
Option -G exposes the control socket on all network interfaces, option -n keeps the GPS active if there is no one currently connected.<br />
<br />
Plotting live location on a map:<br />
* Configure gpsd to expose its socket to the outside world: last section of https://gpsd.gitlab.io/gpsd/troubleshooting.html<br />
* In QGIS, press ctrl+0 to show the GPS information tab, enter the name of the remote gpsd (port 2947)<br />
<br />
Station at Stolwijk (close to Gouda): https://gnss1.tudelft.nl/dpga/station/Stolwijk.html#STWK ?<br />
<br />
Starting from the command line:<br />
* stop gpsd.socket<br />
sudo systemctl stop gpsd.socket<br />
* run from command line<br />
sudo /usr/sbin/gpsd -Gn -D 1 -N /dev/ttyUSB0 .... (not sure yet)<br />
<br />
=== Validation ===<br />
How to show that RTK GPS is actually accurate?<br />
<br />
* Relative positioning: with an "fix RTK" solution, place the antenna at 4 points 25cm apart, each point for 20 seconds or so -> you see 4 distinct clusters of points<br />
* Positioning over short time: put it in a fixed location, make sure that it has "fix RTK" solution, take 100 measurements or so -> determine the radius of the circle that contains 90% of the points<br />
* Positioning over longer time: do this for (say) an hour<br />
* Absolute positioning: look up a national reference point, for example "RD-punt 389346", located on the Sluisdijk between Gouda and Moordrecht. Technical data: https://www.nsgi.nl/iv-api/rdinfo/rdpoint/389346<br />
** see https://www.nsgi.nl/referentiepunten-en-gnss-data/informatie-referentiepunten/rdinfo and enter 389346<br />
** latitude: 51° 59' 49,64048" , longitude: 4° 41' 19,90765", or 51.99712236/4.68886324<br />
<br />
==== Comparison with reference coordinate ====<br />
On october 4th 2024, we took the RTK GPS to a kernnet reference point at 51.99712236/4.68886324, results below:<br />
<br />
From https://www.nsgi.nl/iv-api/rdinfo/rdpoint/389346:<br />
* Year 2021: "51 59 49,64004", "4 41 19,90584", 48.039. In decimal degrees that is <br />
<br />
Differences between the reference point and the measurements are calculated to easting ('X') and northing ('Y'), unit meter. To calculate distance in meters, we use a linear approximation:<br />
* For dy: 40075km/360 = 111,319 m/deg<br />
* For dx: dy * cos(latitude) = 68,549 m/deg<br />
<br />
{| class="wikitable" style="margin:auto"<br />
|+ Measurements + deviations<br />
|-<br />
! Name !! Latitude !! Longitude !! dx (m) !! dy (m) !! absolute (m) !! Remark<br />
|-<br />
| Reference 2012 || 51.99712236 || 4.68886324 || - || - || 0 || by definition<br />
|-<br />
| Reference 2021 || 51.99712223 || 4.68886273 || - || - || 0 || by definition<br />
|-<br />
| Screenshot 1 || 51.99712217 || 4.68886567 || 0.167 || -0.021 || 0.168 || - <br />
|-<br />
| Screenshot 2 || 51.99712200 || 4.68886533 || 0.143 || -0.040 || 0.149 || -<br />
|-<br />
| Meting 1 || 51.9971220 || 4.6888663 || 0.210 || -0.040 || 0.214 || -<br />
|-<br />
| Meting 2 || 51.9971222 || 4.6888660 || 0.189 || -0.018 || 0.190 || -<br />
|-<br />
| Average || - || - || 0.177 || -0.030 || 0.180 || -<br />
|}<br />
<br />
According to [https://www.unavco.org/software/geodetic-utilities/plate-motion-calculator/plate-motion-calculator.html this page], the rate of movement is about<br />
15.75mm/year to the north and 17.45 mm/year to the east (ITRF2020 model).<br />
Over 12 years, that amounts to 0.189m north and 0.209m east.<br />
<br />
== Air quality sensors ==<br />
<br />
=== Nitrogen compounds in air ===<br />
According to https://www.rivm.nl/stikstof/monitoren-advies-onderzoek/overzicht-stikstofmetingen/metingen-stikstof-in-de-lucht average (typical?) values of<br />
* Ammonia (NH3): 6.7 ug/m3 (9.6 ppb)<br />
* NOx: 27.3 ug/m3<br />
* NO2: 18.6 ug/m3 (9.9 ppb)<br />
<br />
(ppb-conversion using https://www.breeze-technologies.de/blog/air-pollution-how-to-convert-between-mgm3-%C2%B5gm3-ppm-ppb/ )<br />
<br />
RIVM report on inexpensive nitrogen-in-air sensors: https://www.samenmeten.nl/sensoren-voor-no2<br />
Conclusion: most sensors are not sensitive enough to be used in typical outdoor conditions, with perhaps one exception: alphasense NO2-B43F<br />
<br />
== Sonar sensors ==<br />
Investigate this because it allows us to measure depth.<br />
<br />
AliExpress has several types of affordable sonar sensors, focused at detecting fish, but also able to measure depth.<br />
<br />
I ordered this one: https://nl.aliexpress.com/item/1005006388343879.html<br />
* 125 kHz main frequency, range up to 200 ft deep (about 60m)<br />
* bluetooth low-power interface (basically serial-over-BLE)<br />
* built-in battery, powers on automatically when submerged<br />
* reports 120-element array with raw sonar return intensity-vs-depth<br />
* measures water temperature<br />
* about 45 euro<br />
<br />
Fish helper pro application for android https://apkpure.com/fish-helper-pro/com.fishfinderpro.xdx<br />
<br />
=== Debug tool ===<br />
I wrote a python script to connect to it from a linux computer: https://github.com/bertrik/wireless-sonar-sensor<br />
<br />
It's connects to a "Fish Helper Pro" wireless sonar sensor over bluetooth low-energy, reports depth and temperature<br />
<br />
=== ROS2 integration ===<br />
The most appropriate message for a simple range would be: https://docs.ros2.org/foxy/api/sensor_msgs/msg/Range.html<br />
<br />
There are other messages to perhaps report the raw echo return array.<br />
<br />
== Water physical analysis ==<br />
=== Turbidity / clarity ===<br />
See https://en.wikipedia.org/wiki/Turbidity<br />
<br />
Aliexpress sensor '''TS-300B''': https://nl.aliexpress.com/item/1005006732956937.html<br />
Has a range 0 ~ 1000 ± 30 NTU<br />
<br />
Order of magnitude for turbidity:<br />
* Drinking water upper limit: '''4 NTU''' (European turbidity standard for drinking water)<br />
* Ambient water: 10-150 NTU. The US state of Washington use a "background" value of '''50 NTU''' as reference.<br />
<br />
(see https://en.wikipedia.org/wiki/Turbidity#Standards_and_test_methods )<br />
<br />
So the Aliexpress sensor is suited only for "dirty" water.<br />
<br />
=== Water measurement probes ===<br />
I bought this one: Tuya compatible BT785 EC meter: https://nl.aliexpress.com/i/1005007462079781.html inexpensive, focused on EC, runs on 4x LR44<br />
<br />
Speaks the TuYa protocol (requires a secret key that you can fetch through the developer console).<br />
<br />
Does NOT speak the universal serialport access protocol as described here:<br />
https://developer.tuya.com/en/docs/iot/tuya-cloud-universal-serial-port-access-protocol?id=K9hhi0xxtn9cb<br />
<br />
* https://nl.aliexpress.com/item/1005003784454381.html BLE-9908 Inexpensie "Yieryi" PH/EC/Temp probe with bluetooth and app, about E25,- (Uses 3x LR44 coin cell batteries)<br />
* Several different models: https://nl.aliexpress.com/item/1005007810989801.html<br />
** EZ9901: TDS/pH/temp<br />
** EZ9902: EC/pH/temp<br />
** EZ9908: EC/TDS/pH/temp<br />
** EZ9909: TDS/EC/pH/salt/temp<br />
* The bluetooth versions are probably as above, with numbers like BLE9902 and BLE9908<br />
* Yiery BLE9902: https://shop.yieryimeters.com/products/yieryi-ble-9902-3-in-1-digital-ph-meter-with-bluetooth-ec-and-temperature-measurement-ideal-for-water-quality-testing-in-pools-fish-tanks-hydroponics-more<br />
* BLE-EC01 is a bluetooth EC meter, can find it here https://www.amazon.com/BLE-EC01-Smart4-TDS-Temp-Meter/dp/B0DPZZC7BV, not on AliExpress?<br />
<br />
Note:<br />
* Some probes indicate EC (electrical conductivity), other indicate TDS (total dissolved liquids). TDS is derived from EC (knowing the liquid type). EC is the more universal/fundamental property!<br />
* EC is typically expressed in uS/cm or mS/cm (micro or milli siemens per centimeter), say 500 uS/cm for outdoor water.<br />
* EC is temperature dependent, typically you need the value extrapolated to 25 degrees Celcius. Temperature-EC correlation rule of thumb: about 2% more conductive per K.<br />
* pH sensors are almost by definition fragile and last only a limited time, so probably don't bother trying to use one at all. The pH of outdoor water might not be that interesting to measure.<br />
<br />
== Boat control ==<br />
Typically the wireless link looks like this:<br />
* 2.4 GHz working frequency<br />
* 500m range<br />
<br />
Interesting links:<br />
* Flytec-2011 remote control https://nl.aliexpress.com/item/1005002984723718.html<br />
* Replacement board for various boats with "18" in their type number: https://nl.aliexpress.com/item/1005006115484716.html<br />
* DIY Multi-protocol module: https://github.com/pascallanger/DIY-Multiprotocol-TX-Module<br />
<br />
=== remote control ===<br />
Image of remote control RF chip:<br />
[...]<br />
<br />
Parts:<br />
* 12.000 MHz crystal/oscillator<br />
* 16-pin control chip: 20_CL6L071<br />
* 6-pin RF chip: 1110 / VKA3, could be an rx/tx switch, amplifier or filter circuit<br />
<br />
See also: https://www.open-tx.org/<br />
<br />
Next steps:<br />
* map out the connections between the mainboard and the rf board, expected: VCC, GND, spi ?<br />
<br />
== Use cases ==<br />
material:<br />
* https://www.youtube.com/watch?v=cMk0bGvIU1E<br />
* https://iplo.nl/thema/water/oppervlaktewater/kaderrichtlijn-water<br />
* kaartje: https://krw-nutrend.netlify.app/ -> 2 meetpunten op de reeuwijkse plassen, tijdresolutie is 1 jaar?<br />
<br />
Useful distinction, typically used in documents/guidelines:<br />
* chemical quality, what substances are present in the water?<br />
* biological / ecology quality, what kind of living organisms live in the water?<br />
<br />
=== Reeuwijkse plassen ===<br />
See<br />
* https://www.rijnland.net/wat-doet-rijnland/in-uw-buurt/reeuwijkse-plassen/ their stated goal: CLEAR WATER<br />
* https://www.rijnland.net/regels-op-een-rij/subsidies-en-andere-financi%C3%ABle-bijdragen/<br />
<br />
potential applications:<br />
* inspect water sides (oever) over time<br />
* underwater camera: detect invasive cray fish<br />
* sample water properties at high spatial resolution, high time resolution<br />
* early detection of indicators for cyanobacteria: temperature and nutrients<br />
<br />
=== Detect/find pollution source ===<br />
* ...<br />
<br />
== Implementation ==<br />
<br />
=== udev handling of serial ports ===<br />
Many peripheral devices are connected through serial.<br />
The plan is to have an udev config file with renaming rules, so each peripheral gets a stable name in /dev .<br />
The plan is also to create the udev config using some python: insert device X now -> write line to udev config.<br />
<br />
The udev config file is:<br />
/etc/udev/rules.d/99-usb-serial.rules<br />
<br />
<pre><br />
# LIDAR serial converter<br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="10c4", ATTRS{idProduct}=="ea60", SYMLINK+="ttyLIDAR", MODE="0660", GROUP="dialout"<br />
# quectel GPS<br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="1a86", ATTRS{idProduct}=="7523", SYMLINK+="ttyGPS", MODE="0660", GROUP="dialout"<br />
# ublox GPS<br />
SUBSYSTEM=="tty", ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", SYMLINK+="ttyGPS", MODE="0660", GROUP="dialout"<br />
</pre><br />
<br />
An USB-nano also appears to have a USB vendor/product id of 1a86/7523 ("USB2.0-Serial") ... same as the quectel GPS?<br />
<br />
Same for "AI thinker" USB-serial: vendor/product id of 1a86/7523 (product: "USB2.0-Serial")<br />
<br />
To (re)load the properties:<br />
<pre><br />
sudo udevadm control --reload-rules<br />
</pre><br />
<br />
=== reading temperature sensor ===<br />
The idea is to to use a DB18B20 temperature sensor, read it using an arduino nano board acting as a 1-wire adapter.<br />
Use openwire-fs as user-side openwire software http://owfs.org<br />
<br />
Preparation:<br />
* Add the regular user to the 'dialout' group, so it can access serial ports<br />
sudo adduser <name> dialout<br />
<br />
Setting up the hardware:<br />
* connect the DS18B20 to the connector board with the pull-ups<br />
* wire the connector board to the arduino nano, see ...<br />
* plug the arduino nano in the pi<br />
<br />
Setting up the software:<br />
* Install openwire fs<br />
sudo apt install owfs<br />
* Create the openwire fs mountpoint<br />
sudo mkdir /mnt/1wire<br />
* Configure owfs, edit /etc/owfs.conf<br />
server: device = /dev/ttyUSB0<br />
mountpoint = /mnt/1wire<br />
allow_other<br />
(comment out the line with the FAKE devices)<br />
* Configure systemd services<br />
sudo systemctl enable owserver owhttpd<br />
sudo systemctl disable owftpd<br />
* Start the systemd service<br />
sudo systemctl start owserver owhttpd<br />
* Check the logs<br />
sudo journalctl -xeu owserver -f<br />
* Open a browser to view the web interface<br />
http://localhost:2121 or<br />
http://raspberrypi.local:2121</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=NRF52840&diff=35042NRF528402026-02-01T16:26:09Z<p>Bertrik Sikken: /* Hardware */</p>
<hr />
<div> {{Project<br />
|Name=NRF52840<br />
|Picture=nrf52840-supermini.png<br />
|Omschrijving=Running Arduino with platformio on NRF52840<br />
|Status=In progress<br />
|Contact=bertrik<br />
}}<br />
<br />
== Intro ==<br />
This page is about getting inexpensive NRF52840 boards to work with Arduino and platformio.<br />
<br />
NRF52840 is a nice platform:<br />
* low-power<br />
* inexpensive<br />
* decent amount of flash (1024k), RAM (256k) and CPU cycles (64 MHz)<br />
* support various radio protocols like zigbee, ble, thread, enhanced shockburst<br />
* built-in support for quadrature counting<br />
* can run arduino too<br />
<br />
However the eco-system of inexpensive boards is a complicated landscape:<br />
* AliExpress sellers offer "promicro" and "supermini" board with unclear characteristics<br />
* LEDs are sometimes swapped (blue = hardware charge, red = software led?)<br />
* Various firmware upload interface options (which one to use?):<br />
** Using nrfutil, sends a .zip file containing various parts, over USB-serial<br />
** Mass storage UF2, activated using the double-reset<br />
** SWD debug interface (requires soldering!)<br />
* Confusing situation regarding bootloaders:<br />
** Most boards seem to come with a modified version of a bootloader meant for another type of board<br />
** Type of bootloader depends on type of firmware you want to run, "ZMK", Arduino using Arduino IDE, Arduino using platformio<br />
** Risk of accidentally overwriting the bootloader, with UF2 flash offsets sometimes being absolute, sometimes being relative<br />
<br />
== Hardware ==<br />
[[File:nrf52840-supermini-pinout.png|right|350px| thumb stopped working :(]]<br />
<br />
The boards I have are the "promicro" and "supermini".<br />
These boards look basically identical hardware-wise.<br />
<br />
There is a 4-pad connector to program it using SWD (VDD/SWD/SDC/GND).<br />
This can be used to write the bootloader for example.<br />
The pads have a spacing of 1.5mm.<br />
<br />
The blue LED appears to flash independently of software, this is probably the charge circuit behaving randomly without a battery present.<br />
The red LED appears to be under software control.<br />
<br />
Pinout/schematic: https://nicekeyboards.com/docs/nice-nano/pinout-schematic<br />
<br />
=== bootloader ===<br />
The INFO_UF2.TXT says (after double-tap reset):<br />
UF2 Bootloader 0.6.0 lib/nrfx (v2.0.0) lib/tinyusb (0.10.1-41-gdf0cda2d) lib/uf2 (remotes/origin/configupdate-9-gadbb8c7)<br />
Model: nice!nano<br />
Board-ID: nRF52840-nicenano<br />
SoftDevice: S140 version 6.1.1<br />
Date: Jun 19 2021<br />
<br />
The CURRENT.UF2 file is 1.4 MB<br />
<br />
Kernel log says:<br />
<pre><br />
[509372.005339] usb 1-2.3: new full-speed USB device number 96 using xhci_hcd<br />
[509372.132351] usb 1-2.3: New USB device found, idVendor=239a, idProduct=00b3, bcdDevice= 1.00<br />
[509372.132361] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3<br />
[509372.132364] usb 1-2.3: Product: nice!nano<br />
[509372.132366] usb 1-2.3: Manufacturer: Nice Keyboards<br />
[509372.132368] usb 1-2.3: SerialNumber: 98D93A272A6CCC7D<br />
[509372.187474] cdc_acm 1-2.3:1.0: ttyACM0: USB ACM device<br />
[509372.190177] usb-storage 1-2.3:1.2: USB Mass Storage device detected<br />
[509372.190467] scsi host3: usb-storage 1-2.3:1.2<br />
[509373.200470] scsi host3: scsi scan: INQUIRY result too short (5), using 36<br />
[509373.200481] scsi 3:0:0:0: Direct-Access Adafruit nRF UF2 1.0 PQ: 0 ANSI: 2<br />
[509373.200825] sd 3:0:0:0: Attached scsi generic sg0 type 0<br />
[509373.202317] sd 3:0:0:0: [sdb] 65801 512-byte logical blocks: (33.7 MB/32.1 MiB)<br />
[509373.202556] sd 3:0:0:0: [sdb] Write Protect is off<br />
[509373.202559] sd 3:0:0:0: [sdb] Mode Sense: 03 00 00 00<br />
[509373.202782] sd 3:0:0:0: [sdb] No Caching mode page found<br />
[509373.202784] sd 3:0:0:0: [sdb] Assuming drive cache: write through<br />
[509373.296933] sdb:<br />
[509373.297002] sd 3:0:0:0: [sdb] Attached SCSI removable disk<br />
</pre><br />
<br />
== Software ==<br />
Working platformio example project for the nice!nano and supermini/promicro nrf52840 clones:<br />
https://github.com/bertrik/nicenano-example <br />
<br />
Links:<br />
* Nordic technical documentation: https://docs.nordicsemi.com/category/nrf52840-category<br />
* Here is a wiki full of useful information on specific boards: https://github.com/joric/nrfmicro/wiki<br />
** Specifically the supermini https://github.com/joric/nrfmicro/wiki/Alternatives#supermini-nrf52840<br />
* nRFMicro Arduino Core:<br />
** Meant for integration with Arduino IDE, not platformio!<br />
** See https://github.com/pdcook/nRFMicro-Arduino-Core<br />
** Uses https://github.com/NordicSemiconductor/nrfx for NRF52840 specific drivers<br />
* Platformio support for supermini:<br />
** Focused on platformio<br />
** https://github.com/ICantMakeThings/Nicenano-NRF52-Supermini-PlatformIO-Support<br />
** Bit awkward installation (copy/overwrite files inside existing platformio folder)<br />
* https://docs.nordicsemi.com/bundle/ncs-3.1.0/page/zephyr/boards/others/promicro_nrf52840/doc/index.html pro-micro information from Nordic Semi<br />
<br />
Getting 'circuitpython' to work:<br />
* Here's a page on making it work on nicenano: https://circuitpython.org/board/nice_nano/<br />
* HOWEVER, it also says "On nRF boards, CircuitPython 8.2.0 and later require UF2 bootloader version 0.6.1 or later. Older bootloaders cannot load the firmware. See Update UF2 Bootloader below.". Guess what bootloader came with my board ... 0.6.0<br />
* They point you to https://github.com/adafruit/Adafruit_nRF52_Bootloader/releases/tag/0.9.2 but now what!?!!!</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=NRF52840&diff=35041NRF528402026-02-01T16:25:53Z<p>Bertrik Sikken: try 'frame'</p>
<hr />
<div> {{Project<br />
|Name=NRF52840<br />
|Picture=nrf52840-supermini.png<br />
|Omschrijving=Running Arduino with platformio on NRF52840<br />
|Status=In progress<br />
|Contact=bertrik<br />
}}<br />
<br />
== Intro ==<br />
This page is about getting inexpensive NRF52840 boards to work with Arduino and platformio.<br />
<br />
NRF52840 is a nice platform:<br />
* low-power<br />
* inexpensive<br />
* decent amount of flash (1024k), RAM (256k) and CPU cycles (64 MHz)<br />
* support various radio protocols like zigbee, ble, thread, enhanced shockburst<br />
* built-in support for quadrature counting<br />
* can run arduino too<br />
<br />
However the eco-system of inexpensive boards is a complicated landscape:<br />
* AliExpress sellers offer "promicro" and "supermini" board with unclear characteristics<br />
* LEDs are sometimes swapped (blue = hardware charge, red = software led?)<br />
* Various firmware upload interface options (which one to use?):<br />
** Using nrfutil, sends a .zip file containing various parts, over USB-serial<br />
** Mass storage UF2, activated using the double-reset<br />
** SWD debug interface (requires soldering!)<br />
* Confusing situation regarding bootloaders:<br />
** Most boards seem to come with a modified version of a bootloader meant for another type of board<br />
** Type of bootloader depends on type of firmware you want to run, "ZMK", Arduino using Arduino IDE, Arduino using platformio<br />
** Risk of accidentally overwriting the bootloader, with UF2 flash offsets sometimes being absolute, sometimes being relative<br />
<br />
== Hardware ==<br />
[[File:nrf52840-supermini-pinout.png|right|350px thumb stopped working :(]]<br />
<br />
The boards I have are the "promicro" and "supermini".<br />
These boards look basically identical hardware-wise.<br />
<br />
There is a 4-pad connector to program it using SWD (VDD/SWD/SDC/GND).<br />
This can be used to write the bootloader for example.<br />
The pads have a spacing of 1.5mm.<br />
<br />
The blue LED appears to flash independently of software, this is probably the charge circuit behaving randomly without a battery present.<br />
The red LED appears to be under software control.<br />
<br />
Pinout/schematic: https://nicekeyboards.com/docs/nice-nano/pinout-schematic<br />
<br />
=== bootloader ===<br />
The INFO_UF2.TXT says (after double-tap reset):<br />
UF2 Bootloader 0.6.0 lib/nrfx (v2.0.0) lib/tinyusb (0.10.1-41-gdf0cda2d) lib/uf2 (remotes/origin/configupdate-9-gadbb8c7)<br />
Model: nice!nano<br />
Board-ID: nRF52840-nicenano<br />
SoftDevice: S140 version 6.1.1<br />
Date: Jun 19 2021<br />
<br />
The CURRENT.UF2 file is 1.4 MB<br />
<br />
Kernel log says:<br />
<pre><br />
[509372.005339] usb 1-2.3: new full-speed USB device number 96 using xhci_hcd<br />
[509372.132351] usb 1-2.3: New USB device found, idVendor=239a, idProduct=00b3, bcdDevice= 1.00<br />
[509372.132361] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3<br />
[509372.132364] usb 1-2.3: Product: nice!nano<br />
[509372.132366] usb 1-2.3: Manufacturer: Nice Keyboards<br />
[509372.132368] usb 1-2.3: SerialNumber: 98D93A272A6CCC7D<br />
[509372.187474] cdc_acm 1-2.3:1.0: ttyACM0: USB ACM device<br />
[509372.190177] usb-storage 1-2.3:1.2: USB Mass Storage device detected<br />
[509372.190467] scsi host3: usb-storage 1-2.3:1.2<br />
[509373.200470] scsi host3: scsi scan: INQUIRY result too short (5), using 36<br />
[509373.200481] scsi 3:0:0:0: Direct-Access Adafruit nRF UF2 1.0 PQ: 0 ANSI: 2<br />
[509373.200825] sd 3:0:0:0: Attached scsi generic sg0 type 0<br />
[509373.202317] sd 3:0:0:0: [sdb] 65801 512-byte logical blocks: (33.7 MB/32.1 MiB)<br />
[509373.202556] sd 3:0:0:0: [sdb] Write Protect is off<br />
[509373.202559] sd 3:0:0:0: [sdb] Mode Sense: 03 00 00 00<br />
[509373.202782] sd 3:0:0:0: [sdb] No Caching mode page found<br />
[509373.202784] sd 3:0:0:0: [sdb] Assuming drive cache: write through<br />
[509373.296933] sdb:<br />
[509373.297002] sd 3:0:0:0: [sdb] Attached SCSI removable disk<br />
</pre><br />
<br />
== Software ==<br />
Working platformio example project for the nice!nano and supermini/promicro nrf52840 clones:<br />
https://github.com/bertrik/nicenano-example <br />
<br />
Links:<br />
* Nordic technical documentation: https://docs.nordicsemi.com/category/nrf52840-category<br />
* Here is a wiki full of useful information on specific boards: https://github.com/joric/nrfmicro/wiki<br />
** Specifically the supermini https://github.com/joric/nrfmicro/wiki/Alternatives#supermini-nrf52840<br />
* nRFMicro Arduino Core:<br />
** Meant for integration with Arduino IDE, not platformio!<br />
** See https://github.com/pdcook/nRFMicro-Arduino-Core<br />
** Uses https://github.com/NordicSemiconductor/nrfx for NRF52840 specific drivers<br />
* Platformio support for supermini:<br />
** Focused on platformio<br />
** https://github.com/ICantMakeThings/Nicenano-NRF52-Supermini-PlatformIO-Support<br />
** Bit awkward installation (copy/overwrite files inside existing platformio folder)<br />
* https://docs.nordicsemi.com/bundle/ncs-3.1.0/page/zephyr/boards/others/promicro_nrf52840/doc/index.html pro-micro information from Nordic Semi<br />
<br />
Getting 'circuitpython' to work:<br />
* Here's a page on making it work on nicenano: https://circuitpython.org/board/nice_nano/<br />
* HOWEVER, it also says "On nRF boards, CircuitPython 8.2.0 and later require UF2 bootloader version 0.6.1 or later. Older bootloaders cannot load the firmware. See Update UF2 Bootloader below.". Guess what bootloader came with my board ... 0.6.0<br />
* They point you to https://github.com/adafruit/Adafruit_nRF52_Bootloader/releases/tag/0.9.2 but now what!?!!!</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=NRF52840&diff=35040NRF528402026-02-01T16:24:08Z<p>Bertrik Sikken: try 'frame'</p>
<hr />
<div> {{Project<br />
|Name=NRF52840<br />
|Picture=nrf52840-supermini.png<br />
|Omschrijving=Running Arduino with platformio on NRF52840<br />
|Status=In progress<br />
|Contact=bertrik<br />
}}<br />
<br />
== Intro ==<br />
This page is about getting inexpensive NRF52840 boards to work with Arduino and platformio.<br />
<br />
NRF52840 is a nice platform:<br />
* low-power<br />
* inexpensive<br />
* decent amount of flash (1024k), RAM (256k) and CPU cycles (64 MHz)<br />
* support various radio protocols like zigbee, ble, thread, enhanced shockburst<br />
* built-in support for quadrature counting<br />
* can run arduino too<br />
<br />
However the eco-system of inexpensive boards is a complicated landscape:<br />
* AliExpress sellers offer "promicro" and "supermini" board with unclear characteristics<br />
* LEDs are sometimes swapped (blue = hardware charge, red = software led?)<br />
* Various firmware upload interface options (which one to use?):<br />
** Using nrfutil, sends a .zip file containing various parts, over USB-serial<br />
** Mass storage UF2, activated using the double-reset<br />
** SWD debug interface (requires soldering!)<br />
* Confusing situation regarding bootloaders:<br />
** Most boards seem to come with a modified version of a bootloader meant for another type of board<br />
** Type of bootloader depends on type of firmware you want to run, "ZMK", Arduino using Arduino IDE, Arduino using platformio<br />
** Risk of accidentally overwriting the bootloader, with UF2 flash offsets sometimes being absolute, sometimes being relative<br />
<br />
== Hardware ==<br />
[[File:nrf52840-supermini-pinout.png|frame|right|350px|pinout]]<br />
<br />
The boards I have are the "promicro" and "supermini".<br />
These boards look basically identical hardware-wise.<br />
<br />
There is a 4-pad connector to program it using SWD (VDD/SWD/SDC/GND).<br />
This can be used to write the bootloader for example.<br />
The pads have a spacing of 1.5mm.<br />
<br />
The blue LED appears to flash independently of software, this is probably the charge circuit behaving randomly without a battery present.<br />
The red LED appears to be under software control.<br />
<br />
Pinout/schematic: https://nicekeyboards.com/docs/nice-nano/pinout-schematic<br />
<br />
=== bootloader ===<br />
The INFO_UF2.TXT says (after double-tap reset):<br />
UF2 Bootloader 0.6.0 lib/nrfx (v2.0.0) lib/tinyusb (0.10.1-41-gdf0cda2d) lib/uf2 (remotes/origin/configupdate-9-gadbb8c7)<br />
Model: nice!nano<br />
Board-ID: nRF52840-nicenano<br />
SoftDevice: S140 version 6.1.1<br />
Date: Jun 19 2021<br />
<br />
The CURRENT.UF2 file is 1.4 MB<br />
<br />
Kernel log says:<br />
<pre><br />
[509372.005339] usb 1-2.3: new full-speed USB device number 96 using xhci_hcd<br />
[509372.132351] usb 1-2.3: New USB device found, idVendor=239a, idProduct=00b3, bcdDevice= 1.00<br />
[509372.132361] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3<br />
[509372.132364] usb 1-2.3: Product: nice!nano<br />
[509372.132366] usb 1-2.3: Manufacturer: Nice Keyboards<br />
[509372.132368] usb 1-2.3: SerialNumber: 98D93A272A6CCC7D<br />
[509372.187474] cdc_acm 1-2.3:1.0: ttyACM0: USB ACM device<br />
[509372.190177] usb-storage 1-2.3:1.2: USB Mass Storage device detected<br />
[509372.190467] scsi host3: usb-storage 1-2.3:1.2<br />
[509373.200470] scsi host3: scsi scan: INQUIRY result too short (5), using 36<br />
[509373.200481] scsi 3:0:0:0: Direct-Access Adafruit nRF UF2 1.0 PQ: 0 ANSI: 2<br />
[509373.200825] sd 3:0:0:0: Attached scsi generic sg0 type 0<br />
[509373.202317] sd 3:0:0:0: [sdb] 65801 512-byte logical blocks: (33.7 MB/32.1 MiB)<br />
[509373.202556] sd 3:0:0:0: [sdb] Write Protect is off<br />
[509373.202559] sd 3:0:0:0: [sdb] Mode Sense: 03 00 00 00<br />
[509373.202782] sd 3:0:0:0: [sdb] No Caching mode page found<br />
[509373.202784] sd 3:0:0:0: [sdb] Assuming drive cache: write through<br />
[509373.296933] sdb:<br />
[509373.297002] sd 3:0:0:0: [sdb] Attached SCSI removable disk<br />
</pre><br />
<br />
== Software ==<br />
Working platformio example project for the nice!nano and supermini/promicro nrf52840 clones:<br />
https://github.com/bertrik/nicenano-example <br />
<br />
Links:<br />
* Nordic technical documentation: https://docs.nordicsemi.com/category/nrf52840-category<br />
* Here is a wiki full of useful information on specific boards: https://github.com/joric/nrfmicro/wiki<br />
** Specifically the supermini https://github.com/joric/nrfmicro/wiki/Alternatives#supermini-nrf52840<br />
* nRFMicro Arduino Core:<br />
** Meant for integration with Arduino IDE, not platformio!<br />
** See https://github.com/pdcook/nRFMicro-Arduino-Core<br />
** Uses https://github.com/NordicSemiconductor/nrfx for NRF52840 specific drivers<br />
* Platformio support for supermini:<br />
** Focused on platformio<br />
** https://github.com/ICantMakeThings/Nicenano-NRF52-Supermini-PlatformIO-Support<br />
** Bit awkward installation (copy/overwrite files inside existing platformio folder)<br />
* https://docs.nordicsemi.com/bundle/ncs-3.1.0/page/zephyr/boards/others/promicro_nrf52840/doc/index.html pro-micro information from Nordic Semi<br />
<br />
Getting 'circuitpython' to work:<br />
* Here's a page on making it work on nicenano: https://circuitpython.org/board/nice_nano/<br />
* HOWEVER, it also says "On nRF boards, CircuitPython 8.2.0 and later require UF2 bootloader version 0.6.1 or later. Older bootloaders cannot load the firmware. See Update UF2 Bootloader below.". Guess what bootloader came with my board ... 0.6.0<br />
* They point you to https://github.com/adafruit/Adafruit_nRF52_Bootloader/releases/tag/0.9.2 but now what!?!!!</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=NRF52840&diff=35039NRF528402026-02-01T16:23:19Z<p>Bertrik Sikken: more experimentation</p>
<hr />
<div> {{Project<br />
|Name=NRF52840<br />
|Picture=nrf52840-supermini.png<br />
|Omschrijving=Running Arduino with platformio on NRF52840<br />
|Status=In progress<br />
|Contact=bertrik<br />
}}<br />
<br />
== Intro ==<br />
This page is about getting inexpensive NRF52840 boards to work with Arduino and platformio.<br />
<br />
NRF52840 is a nice platform:<br />
* low-power<br />
* inexpensive<br />
* decent amount of flash (1024k), RAM (256k) and CPU cycles (64 MHz)<br />
* support various radio protocols like zigbee, ble, thread, enhanced shockburst<br />
* built-in support for quadrature counting<br />
* can run arduino too<br />
<br />
However the eco-system of inexpensive boards is a complicated landscape:<br />
* AliExpress sellers offer "promicro" and "supermini" board with unclear characteristics<br />
* LEDs are sometimes swapped (blue = hardware charge, red = software led?)<br />
* Various firmware upload interface options (which one to use?):<br />
** Using nrfutil, sends a .zip file containing various parts, over USB-serial<br />
** Mass storage UF2, activated using the double-reset<br />
** SWD debug interface (requires soldering!)<br />
* Confusing situation regarding bootloaders:<br />
** Most boards seem to come with a modified version of a bootloader meant for another type of board<br />
** Type of bootloader depends on type of firmware you want to run, "ZMK", Arduino using Arduino IDE, Arduino using platformio<br />
** Risk of accidentally overwriting the bootloader, with UF2 flash offsets sometimes being absolute, sometimes being relative<br />
<br />
== Hardware ==<br />
[[File:nrf52840-supermini-pinout.png|right|350px|pinout]]<br />
<br />
The boards I have are the "promicro" and "supermini".<br />
These boards look basically identical hardware-wise.<br />
<br />
There is a 4-pad connector to program it using SWD (VDD/SWD/SDC/GND).<br />
This can be used to write the bootloader for example.<br />
The pads have a spacing of 1.5mm.<br />
<br />
The blue LED appears to flash independently of software, this is probably the charge circuit behaving randomly without a battery present.<br />
The red LED appears to be under software control.<br />
<br />
Pinout/schematic: https://nicekeyboards.com/docs/nice-nano/pinout-schematic<br />
<br />
=== bootloader ===<br />
The INFO_UF2.TXT says (after double-tap reset):<br />
UF2 Bootloader 0.6.0 lib/nrfx (v2.0.0) lib/tinyusb (0.10.1-41-gdf0cda2d) lib/uf2 (remotes/origin/configupdate-9-gadbb8c7)<br />
Model: nice!nano<br />
Board-ID: nRF52840-nicenano<br />
SoftDevice: S140 version 6.1.1<br />
Date: Jun 19 2021<br />
<br />
The CURRENT.UF2 file is 1.4 MB<br />
<br />
Kernel log says:<br />
<pre><br />
[509372.005339] usb 1-2.3: new full-speed USB device number 96 using xhci_hcd<br />
[509372.132351] usb 1-2.3: New USB device found, idVendor=239a, idProduct=00b3, bcdDevice= 1.00<br />
[509372.132361] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3<br />
[509372.132364] usb 1-2.3: Product: nice!nano<br />
[509372.132366] usb 1-2.3: Manufacturer: Nice Keyboards<br />
[509372.132368] usb 1-2.3: SerialNumber: 98D93A272A6CCC7D<br />
[509372.187474] cdc_acm 1-2.3:1.0: ttyACM0: USB ACM device<br />
[509372.190177] usb-storage 1-2.3:1.2: USB Mass Storage device detected<br />
[509372.190467] scsi host3: usb-storage 1-2.3:1.2<br />
[509373.200470] scsi host3: scsi scan: INQUIRY result too short (5), using 36<br />
[509373.200481] scsi 3:0:0:0: Direct-Access Adafruit nRF UF2 1.0 PQ: 0 ANSI: 2<br />
[509373.200825] sd 3:0:0:0: Attached scsi generic sg0 type 0<br />
[509373.202317] sd 3:0:0:0: [sdb] 65801 512-byte logical blocks: (33.7 MB/32.1 MiB)<br />
[509373.202556] sd 3:0:0:0: [sdb] Write Protect is off<br />
[509373.202559] sd 3:0:0:0: [sdb] Mode Sense: 03 00 00 00<br />
[509373.202782] sd 3:0:0:0: [sdb] No Caching mode page found<br />
[509373.202784] sd 3:0:0:0: [sdb] Assuming drive cache: write through<br />
[509373.296933] sdb:<br />
[509373.297002] sd 3:0:0:0: [sdb] Attached SCSI removable disk<br />
</pre><br />
<br />
== Software ==<br />
Working platformio example project for the nice!nano and supermini/promicro nrf52840 clones:<br />
https://github.com/bertrik/nicenano-example <br />
<br />
Links:<br />
* Nordic technical documentation: https://docs.nordicsemi.com/category/nrf52840-category<br />
* Here is a wiki full of useful information on specific boards: https://github.com/joric/nrfmicro/wiki<br />
** Specifically the supermini https://github.com/joric/nrfmicro/wiki/Alternatives#supermini-nrf52840<br />
* nRFMicro Arduino Core:<br />
** Meant for integration with Arduino IDE, not platformio!<br />
** See https://github.com/pdcook/nRFMicro-Arduino-Core<br />
** Uses https://github.com/NordicSemiconductor/nrfx for NRF52840 specific drivers<br />
* Platformio support for supermini:<br />
** Focused on platformio<br />
** https://github.com/ICantMakeThings/Nicenano-NRF52-Supermini-PlatformIO-Support<br />
** Bit awkward installation (copy/overwrite files inside existing platformio folder)<br />
* https://docs.nordicsemi.com/bundle/ncs-3.1.0/page/zephyr/boards/others/promicro_nrf52840/doc/index.html pro-micro information from Nordic Semi<br />
<br />
Getting 'circuitpython' to work:<br />
* Here's a page on making it work on nicenano: https://circuitpython.org/board/nice_nano/<br />
* HOWEVER, it also says "On nRF boards, CircuitPython 8.2.0 and later require UF2 bootloader version 0.6.1 or later. Older bootloaders cannot load the firmware. See Update UF2 Bootloader below.". Guess what bootloader came with my board ... 0.6.0<br />
* They point you to https://github.com/adafruit/Adafruit_nRF52_Bootloader/releases/tag/0.9.2 but now what!?!!!</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=NRF52840&diff=35038NRF528402026-02-01T16:20:37Z<p>Bertrik Sikken: mediawiki fix attempt</p>
<hr />
<div> {{Project<br />
|Name=NRF52840<br />
|Picture=nrf52840-supermini.png<br />
|Omschrijving=Running Arduino with platformio on NRF52840<br />
|Status=In progress<br />
|Contact=bertrik<br />
}}<br />
<br />
== Intro ==<br />
This page is about getting inexpensive NRF52840 boards to work with Arduino and platformio.<br />
<br />
NRF52840 is a nice platform:<br />
* low-power<br />
* inexpensive<br />
* decent amount of flash (1024k), RAM (256k) and CPU cycles (64 MHz)<br />
* support various radio protocols like zigbee, ble, thread, enhanced shockburst<br />
* built-in support for quadrature counting<br />
* can run arduino too<br />
<br />
However the eco-system of inexpensive boards is a complicated landscape:<br />
* AliExpress sellers offer "promicro" and "supermini" board with unclear characteristics<br />
* LEDs are sometimes swapped (blue = hardware charge, red = software led?)<br />
* Various firmware upload interface options (which one to use?):<br />
** Using nrfutil, sends a .zip file containing various parts, over USB-serial<br />
** Mass storage UF2, activated using the double-reset<br />
** SWD debug interface (requires soldering!)<br />
* Confusing situation regarding bootloaders:<br />
** Most boards seem to come with a modified version of a bootloader meant for another type of board<br />
** Type of bootloader depends on type of firmware you want to run, "ZMK", Arduino using Arduino IDE, Arduino using platformio<br />
** Risk of accidentally overwriting the bootloader, with UF2 flash offsets sometimes being absolute, sometimes being relative<br />
<br />
== Hardware ==<br />
[[File:nrf52840-supermini-pinout.png|right|thumb|350px|pinout]]<br />
<br />
The boards I have are the "promicro" and "supermini".<br />
These boards look basically identical hardware-wise.<br />
<br />
There is a 4-pad connector to program it using SWD (VDD/SWD/SDC/GND).<br />
This can be used to write the bootloader for example.<br />
The pads have a spacing of 1.5mm.<br />
<br />
The blue LED appears to flash independently of software, this is probably the charge circuit behaving randomly without a battery present.<br />
The red LED appears to be under software control.<br />
<br />
Pinout/schematic: https://nicekeyboards.com/docs/nice-nano/pinout-schematic<br />
<br />
=== bootloader ===<br />
The INFO_UF2.TXT says (after double-tap reset):<br />
UF2 Bootloader 0.6.0 lib/nrfx (v2.0.0) lib/tinyusb (0.10.1-41-gdf0cda2d) lib/uf2 (remotes/origin/configupdate-9-gadbb8c7)<br />
Model: nice!nano<br />
Board-ID: nRF52840-nicenano<br />
SoftDevice: S140 version 6.1.1<br />
Date: Jun 19 2021<br />
<br />
The CURRENT.UF2 file is 1.4 MB<br />
<br />
Kernel log says:<br />
<pre><br />
[509372.005339] usb 1-2.3: new full-speed USB device number 96 using xhci_hcd<br />
[509372.132351] usb 1-2.3: New USB device found, idVendor=239a, idProduct=00b3, bcdDevice= 1.00<br />
[509372.132361] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3<br />
[509372.132364] usb 1-2.3: Product: nice!nano<br />
[509372.132366] usb 1-2.3: Manufacturer: Nice Keyboards<br />
[509372.132368] usb 1-2.3: SerialNumber: 98D93A272A6CCC7D<br />
[509372.187474] cdc_acm 1-2.3:1.0: ttyACM0: USB ACM device<br />
[509372.190177] usb-storage 1-2.3:1.2: USB Mass Storage device detected<br />
[509372.190467] scsi host3: usb-storage 1-2.3:1.2<br />
[509373.200470] scsi host3: scsi scan: INQUIRY result too short (5), using 36<br />
[509373.200481] scsi 3:0:0:0: Direct-Access Adafruit nRF UF2 1.0 PQ: 0 ANSI: 2<br />
[509373.200825] sd 3:0:0:0: Attached scsi generic sg0 type 0<br />
[509373.202317] sd 3:0:0:0: [sdb] 65801 512-byte logical blocks: (33.7 MB/32.1 MiB)<br />
[509373.202556] sd 3:0:0:0: [sdb] Write Protect is off<br />
[509373.202559] sd 3:0:0:0: [sdb] Mode Sense: 03 00 00 00<br />
[509373.202782] sd 3:0:0:0: [sdb] No Caching mode page found<br />
[509373.202784] sd 3:0:0:0: [sdb] Assuming drive cache: write through<br />
[509373.296933] sdb:<br />
[509373.297002] sd 3:0:0:0: [sdb] Attached SCSI removable disk<br />
</pre><br />
<br />
== Software ==<br />
Working platformio example project for the nice!nano and supermini/promicro nrf52840 clones:<br />
https://github.com/bertrik/nicenano-example <br />
<br />
Links:<br />
* Nordic technical documentation: https://docs.nordicsemi.com/category/nrf52840-category<br />
* Here is a wiki full of useful information on specific boards: https://github.com/joric/nrfmicro/wiki<br />
** Specifically the supermini https://github.com/joric/nrfmicro/wiki/Alternatives#supermini-nrf52840<br />
* nRFMicro Arduino Core:<br />
** Meant for integration with Arduino IDE, not platformio!<br />
** See https://github.com/pdcook/nRFMicro-Arduino-Core<br />
** Uses https://github.com/NordicSemiconductor/nrfx for NRF52840 specific drivers<br />
* Platformio support for supermini:<br />
** Focused on platformio<br />
** https://github.com/ICantMakeThings/Nicenano-NRF52-Supermini-PlatformIO-Support<br />
** Bit awkward installation (copy/overwrite files inside existing platformio folder)<br />
* https://docs.nordicsemi.com/bundle/ncs-3.1.0/page/zephyr/boards/others/promicro_nrf52840/doc/index.html pro-micro information from Nordic Semi<br />
<br />
Getting 'circuitpython' to work:<br />
* Here's a page on making it work on nicenano: https://circuitpython.org/board/nice_nano/<br />
* HOWEVER, it also says "On nRF boards, CircuitPython 8.2.0 and later require UF2 bootloader version 0.6.1 or later. Older bootloaders cannot load the firmware. See Update UF2 Bootloader below.". Guess what bootloader came with my board ... 0.6.0<br />
* They point you to https://github.com/adafruit/Adafruit_nRF52_Bootloader/releases/tag/0.9.2 but now what!?!!!</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=User:Bertrik_Sikken&diff=35037User:Bertrik Sikken2026-01-27T19:24:36Z<p>Bertrik Sikken: /* Meshcore as citizen science data transport */</p>
<hr />
<div>{{Smoel<br />
|Name=Bertrik Sikken<br />
|Nick=bertrik<br />
|Tagline=heb ik niet<br />
}}<br />
<br />
You can reach me at [mailto:bertrik@sikken.nl bertrik@sikken.nl] or [mailto:bertrik@gmail.com bertrik@gmail.com].<br />
<br />
Studied Electrical Engineering at Twente University.<br />
<br />
<br />
Main interests:<br />
* reverse-engineering things (USB stuff, mp3 players), worked on http://rockbox.org (sansa clip players)<br />
* studying bats and making electronics for recording/listening to bat sounds<br />
* radio stuff, in particular software-defined radio, LoRa networks<br />
* citizen science and open data (particulate matter measurement, noise, water quality)<br />
* energy-related stuff, visualisation<br />
<br />
Projects I work(ed) on ([https://revspace.nl/index.php?title=User:Bertrik_Sikken&action=purge refresh]):<br />
{{#ask:[[Category:Project]][[Project Contact::bertrik]]<br />
|?Project Status<br />
|headers=show<br />
|link=all<br />
|order=ASC,ASC<br />
|sort=Project Status,Project Name<br />
}}<br />
<br />
<br />
== Project ideas ==<br />
[[File:always10oclock.jpg|right]]<br />
[[File:idea.jpg|right]]<br />
<br />
This is a list of ideas I'm thinking about, but have not fully developed into an actual project yet.<br />
<br />
https://pine64.com/product/128mb-ox64-sbc-available-on-december-2-2022/<br />
<br />
=== Meshcore as citizen science data transport ===<br />
Meshcore is basically a network of repeaters for lora messages with a specific setting.<br />
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.<br />
<br />
The LoRa setting used almost universally in the Netherlands now is the EU/UK setting:<br />
* 869.618 / SF8 / BW62.5 / CR8<br />
* header enabled <br />
* sync word XXXX<br />
<br />
Description of the on-the-air message: https://gist.github.com/recrof/ca7ccff28c43d1b6bf7e55ce5159100b<br />
Dissection code: https://github.com/folkertvanheusden/meshcore-store/blob/master/utils/dissect.py<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
* Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
* 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.<br />
<br />
=== investigate thread/matter ===<br />
Matter/thread is the new IKEA standard for home automation thins apparently. <br />
Thread is the wireless protocol, matter is a home automation protocol running on top of thread.<br />
<br />
I have a couple of nrf52840, these are good in doing thread.<br />
<br />
Next steps:<br />
* check out openthread<br />
<pre><br />
git clone https://github.com/openthread/openthread.git<br />
cd openthread<br />
git submodule update --init --recursive<br />
</pre><br />
* Prepare development environment:<br />
scripts/bootstrap<br />
* Build it:<br />
./script/build nrf52840 UART_trans -DOT_LOG_LEVEL=OT_LOG_LEVEL_INFO<br />
<br />
Thread on ESP32:<br />
* on ESP32 C6 https://gist.github.com/gtxaspec/d26198daadfb0a8b0a0edeae2d3fd58f<br />
* https://github.com/espressif/esp-thread-br<br />
* https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_rcp<br />
<br />
=== action lsc stekker ===<br />
https://keetsupport.nl/2024/03/20/how-to-flash-lsc-power-plug-with-esphome/<br />
<br />
https://community.home-assistant.io/t/detailed-guide-on-how-to-flash-the-new-tuya-beken-chips-with-openbk7231t/437276<br />
<br />
=== sipeed maix dock ===<br />
Bought this a couple of years ago. Get familiar with this board.<br />
Can I run a chess program on this, for example?<br />
<br />
* https://wiki.sipeed.com/soft/maixpy/en/develop_kit_board/maix_dock.html<br />
<br />
=== rfid keyfob ===<br />
* aliexpress page: https://nl.aliexpress.com/item/1005009569496736.html<br />
* firmware github: <br />
** https://github.com/RfidResearchGroup/ChameleonUltra<br />
** https://github.com/GameTec-live/ChameleonUltraGUI<br />
<br />
=== advanced lidars for bat detection ===<br />
livox:<br />
* github page https://github.com/Livox-SDK/Livox-SDK/tree/master<br />
* web page: https://www.livoxtech.com/<br />
<br />
=== cubecell meshtastic motion detector ===<br />
I have a cubecell AB01 board.<br />
This board is focused on low power, has a connection to attach a solar panel and has a lora radio.<br />
Relatively small amount of RAM, barely enough to run a LoRaWAN stack but probably plenty to run meshtastic<br />
<br />
The plan is to build a simple motion detector from this (using a PIR).<br />
The PIR can wake up the board from low-power, or a timer can wake it periodically.<br />
<br />
See also: https://github.com/HelTecAutomation/CubeCell-Arduino/tree/master/libraries/Basics/examples/LowPower<br />
<br />
=== configure multitech outdoor gateway ===<br />
https://www.multitech.net/developer/products/multiconnect-conduit-platform/basestation/<br />
<br />
https://multitech.com/product/multitech-conduit-mtcdt-246a-868-eu-gb/<br />
<br />
emergency procedure:<br />
https://www.multitech.net/developer/software/mlinux/using-mlinux/flashing-mlinux-firmware-for-conduit/<br />
<br />
=== esp32 wtf ===<br />
* https://forum.arduino.cc/t/ttgo-lilygo-lora-esp32-26mhz-problem/1353750<br />
* "26 MHz crystal has been deprecated" https://github.com/espressif/arduino-esp32/issues/10117<br />
<br />
=== kakofonie counter ===<br />
Sample room audio, use neural network to distinguish voices to estimate number of people talking in the past 30 seconds or so.<br />
Show this number on some kind of display, publish it to MQTT, make a nice graph of it.<br />
<br />
Stuff to figure out:<br />
* this is called 'speaker diarization'<br />
* can it run on an ESP32?<br />
* make a prototype<br />
<br />
=== hypno toad ===<br />
Put these LEDS https://nl.aliexpress.com/item/1005007583528891.html into https://www.action.com/nl-nl/p/2560347/solar-tuinbeeldje/<br />
<br />
Turns out that the default circuit is really basic and output a rough step-up waveform to the LED.<br />
The self-fading LEDs don't work very well with that.<br />
<br />
Also, putting some IPA on hotglue makes it release really easy.<br />
<br />
=== wasbeer / kat classifier ===<br />
ESP32 with resnet50 neural net to distinguish house cats from other animals, see also:<br />
* https://ieeexplore.ieee.org/document/10556848/<br />
<br />
=== Nespresso brew counter ===<br />
Several hacker spaces have one of these Nespresso cup coffee makers, but there's no obvious easy way to monitor usage (monitor ALL the things!).<br />
Inspired by https://hackaday.com/2021/04/25/arduino-mkr-makes-nespresso-monitoring-easy/ this idea is making an even simpler nespresso monitor,<br />
using an inexpensive WiFi enabled ESP8266 with an ubiquitous I2S microphone such as the INMP441. <br />
<br />
Use this sound monitoring project:<br />
https://github.com/aleiei/ESP8266-BUG-I2S-MIC<br />
and turn it into a WiFi connected brew counter.<br />
<br />
Software for getting microphone data from an ESP8266/I2S mic into Linux https://github.com/bertrik/EspMicServer<br />
Nespresso sound is typically 50 Hz with overtones.<br />
In a recording with the ESP8266, it appears that oddly the 17th harmonic (around 850 Hz) is quite strong.<br />
<br />
The plan in the short term is this:<br />
* apply a gentle IIR filter to subtract any DC bias from the microphone signal<br />
* calculate autocovariance at offsets 0 and 20 ms (inverse of 50 Hz), representing the total energy and the energy at 50 Hz respectively<br />
* compare amplitudes to decide about presence of 50 Hz signal, e.g. calculate ratio in dB<br />
* use this to count the length of time that a 50 Hz signal is heard (increments of 100 ms or so)<br />
* decide about none / espresso / lungo based on time<br />
<br />
Might even integrate with esphome / home assistant later.<br />
<br />
=== Remote bat box monitor ===<br />
Idea:<br />
* goal: check if remote bat boxes are occupied and identify the species<br />
* challenges:<br />
** connectivity: need to transport images/videos (no LoRaWAN), possibly out of range of mobile data networks<br />
** autonomy: cannot reach the bat box once installed<br />
** power: no fixed power connection, so probably needs a battery + solar panel<br />
* design<br />
** wake up every hour, take a picture, go to sleep, upload photos/videos once per day<br />
** run from batteries, recharge by solar, rules of thumb<br />
*** batteries should last for about 10 days<br />
*** battery should be able to charge in 1 day<br />
*** consider only 10% of peak solar power<br />
** KPN "4G-op-zee" somewhat confusing article: https://www.kpn.com/zakelijk/mobiel/roaming/noordzee<br />
* hardware<br />
** main processor: raspberry pi zero<br />
*** raspberry pi power consumption overview: https://www.pidramble.com/wiki/benchmarks/power-consumption<br />
** this hat to wake up the main CPU: https://www.waveshare.com/wiki/Power_Management_HAT_(B) sold at https://www.kiwi-electronics.com/en/power-management-hat-for-raspberry-pi-with-rtc-and-rp2040-mcu-11373<br />
<br />
=== KNMI API ===<br />
Get familiar with https://developer.dataplatform.knmi.nl/open-data-api<br />
<br />
=== Grid frequency measurer with web page ===<br />
See https://github.com/bertrik/GridFrequency<br />
SSE source is gridfrequency.local/events<br />
<br />
=== WeAct CH55x board ===<br />
Cheap little boards, using a similar chip as used in USB-serial converters.<br />
<br />
The hardware<br />
https://github.com/WeActStudio/WeActStudio.CH552CoreBoard<br />
<br />
Flashing it:<br />
https://hackaday.io/page/137447-flashing-the-ch552-dev-board-from-the-command-line<br />
<br />
See also:<br />
* https://hackaday.io/project/198238-more-weact-ch5xx<br />
* https://community.platformio.org/t/manually-adding-support-for-ch55x-controller-by-adding-existing-ardunio-core/41138<br />
<br />
=== Zigbee device with esp32 ===<br />
See https://github.com/P-R-O-C-H-Y/arduino-esp32/blob/8169a434c3e46e1bb7711ebcc04f27267db2093c/libraries/ESP32/examples/Zigbee/Zigbee_Light_Bulb/Zigbee_Light_Bulb.ino<br />
<br />
See https://github.com/espressif/arduino-esp32/tree/master/libraries/ESP32/examples/Zigbee<br />
<br />
Espressif32 arduino platform git: https://github.com/platformio/platform-espressif32<br />
<br />
=== Cameratoezicht in Gouda ===<br />
Gemeente Gouda publiceert een lijst van camera's in Gouda, zie<br />
https://gis.gouda.nl/nl/app/Basisviewer_open#!eAGT8uRiNBRy4ZIRYFKSyKkssjJwdzFxNDMz8TKKsLC0cnb0dQ1y5FIByirgkg3xd43ydPYIAQBXGBFm<br />
<br />
Aanmelden (semi-automatisch) bij bijvoorbeeld [https://mapcomplete.org/surveillance Surveillance-under-surveillance] ?<br />
<br />
=== SolarEdge ===<br />
Interact with the solar edge api for PV installations.<br />
<br />
https://developers.solaredge.com/<br />
<br />
See https://github.com/bertrik/solaredge-api<br />
<br />
=== Stookalert ===<br />
Idee: gekleurd lampje dat aangeeft of er op dit moment een stookalert actief is<br />
<br />
Implementatie:<br />
* kijk m.b.v. WiFi locatieservice in welke provincie je je bevindt<br />
* haal JSON op bij https://www.lml.rivm.nl/stookalert/stookalert.json<br />
* toon de bijbehorende kleur op het lampje<br />
<br />
Resources:<br />
* Officiele pagina: https://www.atlasleefomgeving.nl/stookwijzer<br />
* Achterliggende JSON met toestand per provincie: https://www.lml.rivm.nl/stookalert/stookalert.json<br />
* Er moet ook nog ergens een API zijn die fijnmaziger aangeeft wat de toestand is ...<br />
<br />
=== Display of current electricity usage ===<br />
I have a [https://www.zuidwijk.com/product/slimmelezer-plus/ slimme lezer] connected to the P1 port of my smart electricity meter.<br />
The default firmware exposes meter readings using an event stream (SSE) at http://slimmelezer.local/events<br />
<br />
So for example, you can read this with curl:<br />
curl http://slimmelezer.local/events<br />
With result:<br />
event: state<br />
data: {"id":"sensor-power_consumed_phase_1","value":0.046,"state":"0.046 kW"}<br />
<br />
Specification of SSE: https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream<br />
<br />
What I would like to do is to read these events and control a simple display to display the current usage number.<br />
<br />
=== Participating in ultrasonic sound project ===<br />
https://bat-migration-europe.netlify.app/project/<br />
<br />
Use an audiomoth for this.<br />
<br />
=== ESP32 C3 ===<br />
* [https://www.espressif.com/en/products/socs/esp32-c3 processor page]<br />
* [https://wiki.luatos.com/chips/esp32c3/index.html luatos basic esp32 c3 board]<br />
<br />
=== Flexible LED ticker ===<br />
Ordered a flexible 32x8 RGB LED display:<br />
https://nl.aliexpress.com/item/4001296811800.html<br />
<br />
Matching diffuser to be 3D printed:<br />
https://www.thingiverse.com/thing:1903744<br />
<br />
=== Washing machine API ===<br />
https://tratt.net/laurie/blog/2023/displaying_my_washing_machines_remaining_time_with_curl_jq_pizauth.html<br />
<br />
=== TinyML ===<br />
Investigate TinyML, see https://www.tinyml.org/<br />
Apparently can run on a RP2040 (raspi pi pico).<br />
<br />
https://www.hackster.io/mjrobot/esp32-cam-tinyml-image-classification-fruits-vs-veggies-4ab970<br />
<br />
=== Bat box busy signal ===<br />
My brother built little pyramid 'blinkies': solar cell + Lithium-supercapacitor + harvesting circuit + LED encased in clear expoxy.<br />
<br />
Can we add a low-power PIR sensor to this, and make a blinky that blinks if movement was detected by the PIR in the past hour?<br />
<br />
=== Super tiny RFID ===<br />
See https://www.sparkfun.com/products/16464 an almost sand grain size RFID chip, 1.25mmx1.25mmx0.55mm<br />
<br />
The accompanying reader "M6E Nano" is still quite expensive at $235.95 : https://www.sparkfun.com/products/14066<br />
<br />
Uses the MuRata LXMSJZNCMF-198:<br />
"This product can be used as an ultra small tag and this can be<br />
fit on any metal objects, non-metal objects, as well as<br />
embedding into any objects by glue or adhesive and so on."<br />
<br />
See also: ISO18000-63 and EPC global Gen2(v2)<br />
<br />
Specification:<br />
* https://www.gs1.org/standards/rfid/uhf-air-interface-protocol<br />
<br />
=== TheThingsNetwork-Sondehub bridge ===<br />
Uploads balloon telemetry to sondehub.<br />
<br />
See https://github.com/bertrik/ttnhabbridge/issues/6<br />
<br />
=== Actually smart boiler ===<br />
The boiler for hot water is about half of my electricity bill.<br />
The idea is to use/build a smart switch that switches it on at time when electricity prices are lowest.<br />
<br />
Currently have a "Slimme boiler module" from Eneco, which is *not* actually smart,<br />
since it allows me no control whatsoever when it switches on (besides cutting the power in the meterkast).<br />
For example, it will switch on mid-day when my price is high and eneco's price is low, perhaps good for Eneco, not for me. <br />
Apparently, they even received a [https://nieuws.eneco.nl/slim-apparaatje-bij-boiler-vangt-pieken-wind--en-zonnestroom-op/ subsidy] for this.<br />
<br />
A boiler is a pretty big load, about 3 kW, but it is not inductive.<br />
<br />
Alternatives:<br />
* https://www.shelly.cloud/en-nl/products/product-overview/shelly-plus-1-pm-2-pack/shelly-plus-1-pm<br />
* https://www.solyxenergy.nl/solar-iboost/ to store excess solar energy in hot water, might also be useful for just controlling a boiler to use cheaper rates<br />
* tuya smartplug, like https://www.wifilampkoning.nl/merken-slimme-verlichting/tuya/tuya-enkele-smartplug-met-energiemeting ?<br />
* tuya 20A smart plug: https://nl.aliexpress.com/item/1005003347568206.html<br />
<br />
=== Receiving gas meters ===<br />
Apparently gas meters send gas consumption data to the slimme meter using a wireless link in the 868 MHz band.<br />
Probably just FSK at 38.4, as mentioned here: https://a35.veron.nl/nieuwe-elektra-en-gasmeters/<br />
<br />
Interesting leads:<br />
* https://github.com/stef/smeter<br />
* https://www.rtl-sdr.com/reading-household-wireless-utility-meters-with-an-rtl-sdr-and-plotting-the-data-in-home-automation-software/<br />
* https://github.com/bemasher/rtlamr<br />
<br />
=== Multi-network wifi manager ===<br />
Figure out or create software so that ESP8266/ESP32 wifi manager can use multiple networks to connect (not just one),<br />
so it allowing storing credentials for more than one network. For example, the network at home, the hacker space, at work.<br />
Instead of reconfiguring the wifi manager for each network, you just *add* your credentials (and the existing credentials<br />
are not replaced).<br />
<br />
See https://github.com/folkertvanheusden/M.A.X.X<br />
<br />
Interesting candidates:<br />
* https://registry.platformio.org/libraries/martinverges/ESP32%20Wifi%20Manager wifi manager for ESP32, has a REST API for managing wifi network, but is incomplete in the sense that you need to write your own code (e.g. javascript) to actually *use* its API<br />
* https://github.com/arduino-libraries/Arduino_MultiWiFi is the arduino multi wifi library, to allow connecting to multiple different WiFi networks, but it is not a wifi manager, that starts a captive portal, etc<br />
<br />
=== Automated bat counting ===<br />
Can we automatically count the number of bats from the image of a webcam mounted in a bat colony?<br />
Perhaps using some kind of AI or machine learning algorithm?<br />
<br />
The image in question:<br />
https://stofradar.nl/coenecoop/<br />
<br />
=== Use TheThingsIndoorGateway as Helium/ThingSix hotspot ===<br />
I have a spare TTIG that could perhaps be used as a Helium gateway, investigate what is possible.<br />
<br />
One possiblity is to capture the gateway traffic from the TTN gateway events API, convert uplink data to a format that the Helium network understands and forward it.<br />
I don't really care about the Helium crypto tokens, this is just for fun and science.<br />
<br />
What I definitely can do:<br />
* Capture data from the TTN gateway events API, convert it back to Semtech UP format and forward it somewhere to Helium (just not sure where!)<br />
* See also my https://github.com/bertrik/ttn-gateway-collector project which contains an initial implementation of TTN-to-UDP conversion<br />
<br />
Showstoppers:<br />
* If you want to be a gateway on the Helium network, you have to *pay Helium*! Obviously I don't want that, I just want to share data to improve *their* network. <br />
<br />
Open work:<br />
* Investigate if Helium has an open uplink API for their hotspots, if so study it etc, without paying the gateway fee<br />
* Investigate if Thingsix has an open uplink API for their hotspots, if so study it etc, without paying any gateway fee<br />
* Investigate if Thingsix is just another Helium, with weird crypto money<br />
<br />
Interesting stuff:<br />
* https://docs.helium.com/use-the-network/setup-a-packet-forwarder unfortunately the link to setting up the 'light hotspot client' does not work!<br />
* https://docs.helium.com/mine-hnt/light-hotspots/<br />
* https://thingsix.com/<br />
<br />
=== Adding BLE GATT interface to sensors ===<br />
The GATT specification allows measurement properties to be defined and transferred continuously over Bluetooth low-energy.<br />
<br />
With GATT you can define a collection of properties (e.g. measurement items like temperature/humidity/particulate matter/noise, etc)<br />
organised in a simple structure of a BLE service.<br />
The 'notification' method allows you to basically push the data continuously to a connected host, e.g. a smart phone.<br />
<br />
Services collects characteristic, a characteristic has values with units.<br />
Each of these (service, characteristic, unit) have their own unique "UUID".<br />
This is described in the so-called [https://btprodspecificationrefs.blob.core.windows.net/assigned-values/16-bit%20UUID%20Numbers%20Document.pdf 16-bit UUID numbers document]<br />
<br />
Interesting stuff in GATT:<br />
* See GATT_Specification_Supplement_v5 paragraph 3.151, it has a noise characteristic with 1 dB resolution.<br />
* 0x27C3 is the GATT *unit* for sound pressure<br />
* 0x181A is the GATT environmental sensing *service*, document name "ESP_V1.0.0.pdf"<br />
* 0x2A6E is the GATT Characteristic and Object Type for temperature<br />
* 0x2A6F is the GATT Characteristic and Object Type for humidity<br />
* 0x2BD5 is the GATT Characteristic and Object Type for Particulate Matter - PM1 Concentration<br />
* 0x2BD6 is the GATT Characteristic and Object Type for Particulate Matter - PM2.5 Concentration<br />
* 0x2BD7 is the GATT Characteristic and Object Type for Particulate Matter - PM10 Concentration<br />
* Unfortunately I cannot find a characteristic for carbon-dioxide (CO2) in the BLE GATT unit document<br />
<br />
See also https://programmaticponderings.com/2020/08/04/getting-started-with-bluetooth-low-energy-ble-and-generic-attribute-profile-gatt-specification-for-iot/<br />
<br />
=== Reverse engineering XS-8217 bluetooth air quality meter ===<br />
This is a thing that measures CO2, humidity, temperature, TVOC and formaldehyde.<br />
<br />
See also https://wiki.liutyi.info/display/CO2/ZN-2CO3+Inside<br />
<br />
This teardown looks a lot like my sensor: https://www.youtube.com/watch?v=APnjhMrJChI<br />
Mine contains a "TPM-300A" sensor for measuring VOC.<br />
<br />
It has a bluetooth interface, device name is XS-8217.<br />
It has a BLE GATT profile, with the following services<br />
* service 0xC760<br />
** characteristic 0xC762 (WRITE)<br />
** characteristic 0xC761 (NOTIFY)<br />
*** example data: 0x23 0x06 0x10 0x04 0xF1 0x00 0x23 0x65<br />
*** example data: 0x23 0x08 0x10 0x04 0x01 0x9A 0x00 0x0A 0x00 0x03 0x0E<br />
*** data shown on screen was approximately: CO2=418ppm, HCHO=0.003mg/m3, TVOC=0.013mg/m3, temp=24degC, humi=35%<br />
<br />
So data in the characteristic 0xC761 seems to have a 4 byte constant header:<br />
* 0x23<br />
* length byte<br />
<br />
Then we have for the first message: 0x10 0x04 0xF1 0x00 0x23 0x65<br />
* 0x10 0x04 fixed header<br />
* 0xF1 is temperature in 0.1 degree Celcius most likely (24.1)<br />
* 0x00 is ...<br />
* 0x23 is humidity most likely (35)<br />
* 0x65 is ... checksum perhaps<br />
<br />
And for the second message: 0x10 0x04 0x01 0x9A 0x00 0x0A 0x00 0x03 0x0E<br />
* 0x10 0x04 fixed header<br />
* 0x01 0x9A is the CO2 concentration (410)<br />
* 0x00 0x0A is TVOC most likely (10)<br />
* 0x00 0x03 is HCHO most likely (3)<br />
* 0x0E is ... checksum perhaps<br />
<br />
=== ribbon tweeter for bat audio ===<br />
Someone gave me this idea:<br />
Use a ribbon tweeter like this for playing back bat audio:<br />
<s>https://nl.aliexpress.com/item/4000973201791.html</s><br />
<s>https://nl.aliexpress.com/item/1005002565880660.html</s><br />
https://nl.aliexpress.com/item/1005002635086050.html<br />
<br />
The frequency spectrum shows no sign of dropping off at 20 kHz.<br />
<br />
=== 3d glasses ===<br />
I got some 2nd hand 3d glasses, they look exactly like these ones:<br />
* GH-15 https://www.dhgate.com/product/g15-dlp-3d-active-shutter-glasses-96-144hz/213983026.html<br />
* Sintron https://www.amazon.de/Sintron-Kompatibel-TDG-BT500A-TDG-BT400A-Deutschland/dp/B015PCWMZ8<br />
The common name appears to be "G15-DLP".<br />
<br />
A tear-down here:<br />
* https://blog.danman.eu/3d-shutter-glasses-teardown/<br />
<br />
Interesting documents:<br />
* http://cmst.curtin.edu.au/wp-content/uploads/sites/4/2016/05/2012-28-woods-helliwell-cross-compatibility_of_shutter_glasses.pdf<br />
* http://cmst.curtin.edu.au/local/docs/pubs/2011-17-woods-helliwell-3D-Sync-IR.pdf<br />
<br />
Someone claims he got something to work with some hacks:<br />
https://www.avsforum.com/threads/how-i-got-cheap-dlp-link-glasses-to-work-great.1887145/<br />
<br />
=== Waterniveaumeter ===<br />
Op verschillende plekken in Gouda staat er water in de kruipruimte van huizen van bewoners.<br />
Kunnen we dat meten en inzichtelijk maken, voor bewoners, op een kaart bijvoorbeeld?<br />
<br />
Idee:<br />
* in de kruipruimte plaats je een module die waterhoogte kan meten<br />
* de module bestaat uit een microcontroller en een afstandsmeter, die de waterhoogte bepaalt<br />
* de gegevens worden via WiFi doorgestuurd naar een centraal punt, waar de data wordt verwerkt en gevisualiseerd<br />
* op een webpagina kan je een overzicht zien van alle meters die online zijn<br />
* de meting wordt gedaan door bijv. een laser-afstandsmeter of een ultrasoon-afstandsmeter<br />
* voeding? lastig, hoe krijg je 5v naar een potentieel natte plek?<br />
* kosten? verwachting < E 40,-<br />
<br />
In Gouda wordt op veel verschillende plekken de grondwaterstand gemeten, zie https://opendata.munisense.net/portal/wareco-water2/group/581/Gouda-KJ38A , maar:<br />
* geen visualisatie op de kaart, je ziet alleen de meetlokaties d.m.v. een icoontje!<br />
* geen meetpunten in Gouda noord!<br />
<br />
=== Online bat detector ===<br />
Idea: use an ultrasonic microphone, connect it to a WebSDR, so people can tune into bat sounds remotely.<br />
<br />
=== Raspberry pi airplane tracking ===<br />
Apparently now you can also participate in MLAT tracking of planes that don't transmit GPS coordinates themselves.<br />
<br />
=== APRS gateway ===<br />
http://qso365.co.uk/2017/02/a-guide-to-setting-up-an-aprs-receive-only-igate-using-a-raspberry-pi-and-an-rtl-sdr-dongle/<br />
<br />
=== JQ6500 ===<br />
Small inexpensive modules that play mp3 from an internal flash. Could be nice for a custom door bell for example.<br />
<br />
More info at: <br />
* https://www.elecfreaks.com/wiki/index.php?title=JQ6500_Mini_MP3_Module<br />
* https://sparks.gogo.co.nz/jq6500/index.html<br />
<br />
=== FPGA ===<br />
Cheap FPGA boards and nice applications:<br />
* https://bitbucket.org/appanp/artificial-neural-networks/wiki/Home/FPGAsAndNeuralNets.md#!sbcs-and-iot-boards <br />
* [http://nl.aliexpress.com/item/Altera-fpga-cycloneii-ep2c5t144-learning-board-development-board/872520721.html inexpensive ep2c5t144 board] <br />
* http://land-boards.com/blwiki/index.php?title=Cyclone_II_EP2C5_Mini_Dev_Board<br />
<br />
=== Neural networks on low-end hardware ===<br />
Investigate if you can run a powerful neural network on relatively low-end/cheap/low-power hardware. For example a Raspberry pi.<br />
A RPI runs Linux, run python, just like some common neural frameworks.<br />
Do we need hardware acceleration from the GPU and does the RPI GPU support that?<br />
<br />
Read list:<br />
* https://www.zdnet.com/pictures/raspberry-pi-meets-ai-the-projects-that-put-machine-learning-on-the-35-board/<br />
* https://www.pyimagesearch.com/2017/12/18/keras-deep-learning-raspberry-pi/<br />
* https://www.indiegogo.com/projects/sipeed-maix-the-world-first-risc-v-64-ai-module#/<br />
* https://ai.intel.com/intel-neural-compute-stick-2-smarter-faster-plug-and-play-ai-at-the-edge/<br />
<br />
Bought a MaixPy:<br />
* see https://maixpy.sipeed.com/en/<br />
* see https://www.youtube.com/watch?v=KResVuAIMb4<br />
* see http://educ8s.tv/sipeed-m1-dock-review/<br />
* interesting? https://www.instructables.com/id/Transfer-Learning-With-Sipeed-MaiX-and-Arduino-IDE/<br />
<br />
=== mini word clock in dutch ===<br />
Basically an monochrome 8x8 word clock, in Dutch, showing local time in the Netherlands.<br />
<br />
[https://github.com/bertrik/miniwordclock This git repo] has the current code.<br />
<br />
See [https://plus.google.com/103276078656203197145/posts/7ki7rpJzk3a here for a demo] running on an arduino nano.<br />
<br />
The plan is to run this from an ESP8266 instead of an arduino nano, so it can get the time from the internet using NTP.<br />
Andreas Spiess demonstrated on youtube how existing libraries on the ESP8266 can be used to do the local time (including summer-time) calculations.<br />
<br />
=== Cypress PSOC5 ===<br />
Play with the Cypress PSOC5 platform, which combines a ARM Cortex-m3 processor with configurable analog blocks. I'm thinking of combining it with a 24 GHz doppler radar sensor, to process the signal and present it as a USB audio device (stereo signal contains I and Q parts). See [[RadarOnAStick]].<br />
<br />
=== Simple Doppler motion sensors ===<br />
You can find basic doppler microwave motion sensors based on a single transistor, with some weird traces on the PCB very cheaply, for example<br />
* https://www.aliexpress.com/item/RCWL-0516-microwave-radar-sensor-module-Human-body-induction-switch-module-Intelligent-sensor/32708877914.html<br />
<br />
Typically the microwave part of these consists of a single transistor with a rectangular area on one leg and a meandering trace (with lots of vias to the other side) on the other leg.<br />
The output of this circuit seems to go into a chip very much like the ones used in PIR sensors.<br />
<br />
See also https://github.com/jdesbonnet/RCWL-0516 for a reverse engineering effort of these doppler radar modules.<br />
<br />
=== Bare-bones Arduino bat detector ===<br />
This is an idea for a very basic heterodyne bat detector, doing signal processing on an Arduino, requiring minimal external components.<br />
<br />
The basic principle of a heterodyne detector is that it just mixes (multiplies) the audio signal with a square wave, low-pass filters the result and puts it on a speaker.<br />
<br />
Multiplying with a square wave can also be considered to be just alternatively inverting and not-inverting the signal.<br />
So if you sample an ultrasonic signal at twice the rate you want to multiply, you can just subtract odd samples from even samples and low-pass filter that.<br />
<br />
How this can be done in an AVR Arduino:<br />
* sample the audio signal at twice the detection frequency, say 84 kHz. An AVR should just be able to do that.<br />
* apply a 1-pole IIR high-pass filter to remove DC bias, this takes one shift instruction and one addition.<br />
* multiply by the detection frequency, this means just inverting the odd samples.<br />
* low-pass filter the signal, this can be done using a moving average filter, say 16 samples long (first null at 5.25 kHz). Theoretically, averaging 16 samples should result in two bits extra accuracy. This operation takes some storage, an addition and a subtraction.<br />
* output the filtered signal using PWM, possibly at the same rate that we are sampling the input audio.<br />
<br />
The microphone can be a 40 kHz piezo transducer, to keep it cheap (but also limited to 40 kHz).<br />
The pre-amplifier can be a single transistor with some resistors around it, providing about 40x gain.<br />
The arduino does the signal processing (mixing, low-pass filter) to shift the bat audio to human range.<br />
The speaker amplifier can just be a simple two transistor push-pull circuit, since the output from the Arduino is digital/PWM.<br />
<br />
==== AVR Arduino sample rate ====<br />
As far as I understand, the ADC clock can be set to 1 MHz.<br />
Conversion takes 13 cycles, so this can be a problem to reach a sample rate above 80 kHz.<br />
<br />
=== Indoor radar speed sign ===<br />
This idea about placing a simple IQ-output radar sensor indoors in the hacker space, do some basic signal processing on the IQ doppler signal and determine movement speed and direction, then display this on a LED display.<br />
This is of no immediate practical use other than fun, but helps me to gain a bit more experience with microwave radar sensors and eventually build a more effective setup for detecting/counting bats flying in and out of a roost.<br />
<br />
Implement this on a PSOC5 platform or on the STM32 using Arduino.</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=User:Bertrik_Sikken&diff=35035User:Bertrik Sikken2026-01-25T13:15:09Z<p>Bertrik Sikken: /* Project ideas */</p>
<hr />
<div>{{Smoel<br />
|Name=Bertrik Sikken<br />
|Nick=bertrik<br />
|Tagline=heb ik niet<br />
}}<br />
<br />
You can reach me at [mailto:bertrik@sikken.nl bertrik@sikken.nl] or [mailto:bertrik@gmail.com bertrik@gmail.com].<br />
<br />
Studied Electrical Engineering at Twente University.<br />
<br />
<br />
Main interests:<br />
* reverse-engineering things (USB stuff, mp3 players), worked on http://rockbox.org (sansa clip players)<br />
* studying bats and making electronics for recording/listening to bat sounds<br />
* radio stuff, in particular software-defined radio, LoRa networks<br />
* citizen science and open data (particulate matter measurement, noise, water quality)<br />
* energy-related stuff, visualisation<br />
<br />
Projects I work(ed) on ([https://revspace.nl/index.php?title=User:Bertrik_Sikken&action=purge refresh]):<br />
{{#ask:[[Category:Project]][[Project Contact::bertrik]]<br />
|?Project Status<br />
|headers=show<br />
|link=all<br />
|order=ASC,ASC<br />
|sort=Project Status,Project Name<br />
}}<br />
<br />
<br />
== Project ideas ==<br />
[[File:always10oclock.jpg|right]]<br />
[[File:idea.jpg|right]]<br />
<br />
This is a list of ideas I'm thinking about, but have not fully developed into an actual project yet.<br />
<br />
https://pine64.com/product/128mb-ox64-sbc-available-on-december-2-2022/<br />
<br />
=== Meshcore as citizen science data transport ===<br />
Meshcore is basically a network of repeaters for lora messages with a specific setting.<br />
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.<br />
<br />
The LoRa setting used almost universally in the Netherlands now is the EU/UK setting:<br />
* 869.618 / SF8 / BW62.5 / CR8<br />
* header enabled <br />
* sync word XXXX<br />
<br />
Description of the on-the-air message: https://gist.github.com/recrof/ca7ccff28c43d1b6bf7e55ce5159100b<br />
<br />
Meshcore repeaters a relatively "dumb", they just forward anything that resembles a packet (they can't inspect the encrypted part).<br />
<br />
The idea is basically:<br />
* Sensor first starts up, sends a kind of discovery packet in "flood" mode. This kind of packet is flooded over the entire network.<br />
* 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.<br />
<br />
=== investigate thread/matter ===<br />
Matter/thread is the new IKEA standard for home automation thins apparently. <br />
Thread is the wireless protocol, matter is a home automation protocol running on top of thread.<br />
<br />
I have a couple of nrf52840, these are good in doing thread.<br />
<br />
Next steps:<br />
* check out openthread<br />
<pre><br />
git clone https://github.com/openthread/openthread.git<br />
cd openthread<br />
git submodule update --init --recursive<br />
</pre><br />
* Prepare development environment:<br />
scripts/bootstrap<br />
* Build it:<br />
./script/build nrf52840 UART_trans -DOT_LOG_LEVEL=OT_LOG_LEVEL_INFO<br />
<br />
Thread on ESP32:<br />
* on ESP32 C6 https://gist.github.com/gtxaspec/d26198daadfb0a8b0a0edeae2d3fd58f<br />
* https://github.com/espressif/esp-thread-br<br />
* https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_rcp<br />
<br />
=== action lsc stekker ===<br />
https://keetsupport.nl/2024/03/20/how-to-flash-lsc-power-plug-with-esphome/<br />
<br />
https://community.home-assistant.io/t/detailed-guide-on-how-to-flash-the-new-tuya-beken-chips-with-openbk7231t/437276<br />
<br />
=== sipeed maix dock ===<br />
Bought this a couple of years ago. Get familiar with this board.<br />
Can I run a chess program on this, for example?<br />
<br />
* https://wiki.sipeed.com/soft/maixpy/en/develop_kit_board/maix_dock.html<br />
<br />
=== rfid keyfob ===<br />
* aliexpress page: https://nl.aliexpress.com/item/1005009569496736.html<br />
* firmware github: <br />
** https://github.com/RfidResearchGroup/ChameleonUltra<br />
** https://github.com/GameTec-live/ChameleonUltraGUI<br />
<br />
=== advanced lidars for bat detection ===<br />
livox:<br />
* github page https://github.com/Livox-SDK/Livox-SDK/tree/master<br />
* web page: https://www.livoxtech.com/<br />
<br />
=== cubecell meshtastic motion detector ===<br />
I have a cubecell AB01 board.<br />
This board is focused on low power, has a connection to attach a solar panel and has a lora radio.<br />
Relatively small amount of RAM, barely enough to run a LoRaWAN stack but probably plenty to run meshtastic<br />
<br />
The plan is to build a simple motion detector from this (using a PIR).<br />
The PIR can wake up the board from low-power, or a timer can wake it periodically.<br />
<br />
See also: https://github.com/HelTecAutomation/CubeCell-Arduino/tree/master/libraries/Basics/examples/LowPower<br />
<br />
=== configure multitech outdoor gateway ===<br />
https://www.multitech.net/developer/products/multiconnect-conduit-platform/basestation/<br />
<br />
https://multitech.com/product/multitech-conduit-mtcdt-246a-868-eu-gb/<br />
<br />
emergency procedure:<br />
https://www.multitech.net/developer/software/mlinux/using-mlinux/flashing-mlinux-firmware-for-conduit/<br />
<br />
=== esp32 wtf ===<br />
* https://forum.arduino.cc/t/ttgo-lilygo-lora-esp32-26mhz-problem/1353750<br />
* "26 MHz crystal has been deprecated" https://github.com/espressif/arduino-esp32/issues/10117<br />
<br />
=== kakofonie counter ===<br />
Sample room audio, use neural network to distinguish voices to estimate number of people talking in the past 30 seconds or so.<br />
Show this number on some kind of display, publish it to MQTT, make a nice graph of it.<br />
<br />
Stuff to figure out:<br />
* this is called 'speaker diarization'<br />
* can it run on an ESP32?<br />
* make a prototype<br />
<br />
=== hypno toad ===<br />
Put these LEDS https://nl.aliexpress.com/item/1005007583528891.html into https://www.action.com/nl-nl/p/2560347/solar-tuinbeeldje/<br />
<br />
Turns out that the default circuit is really basic and output a rough step-up waveform to the LED.<br />
The self-fading LEDs don't work very well with that.<br />
<br />
Also, putting some IPA on hotglue makes it release really easy.<br />
<br />
=== wasbeer / kat classifier ===<br />
ESP32 with resnet50 neural net to distinguish house cats from other animals, see also:<br />
* https://ieeexplore.ieee.org/document/10556848/<br />
<br />
=== Nespresso brew counter ===<br />
Several hacker spaces have one of these Nespresso cup coffee makers, but there's no obvious easy way to monitor usage (monitor ALL the things!).<br />
Inspired by https://hackaday.com/2021/04/25/arduino-mkr-makes-nespresso-monitoring-easy/ this idea is making an even simpler nespresso monitor,<br />
using an inexpensive WiFi enabled ESP8266 with an ubiquitous I2S microphone such as the INMP441. <br />
<br />
Use this sound monitoring project:<br />
https://github.com/aleiei/ESP8266-BUG-I2S-MIC<br />
and turn it into a WiFi connected brew counter.<br />
<br />
Software for getting microphone data from an ESP8266/I2S mic into Linux https://github.com/bertrik/EspMicServer<br />
Nespresso sound is typically 50 Hz with overtones.<br />
In a recording with the ESP8266, it appears that oddly the 17th harmonic (around 850 Hz) is quite strong.<br />
<br />
The plan in the short term is this:<br />
* apply a gentle IIR filter to subtract any DC bias from the microphone signal<br />
* calculate autocovariance at offsets 0 and 20 ms (inverse of 50 Hz), representing the total energy and the energy at 50 Hz respectively<br />
* compare amplitudes to decide about presence of 50 Hz signal, e.g. calculate ratio in dB<br />
* use this to count the length of time that a 50 Hz signal is heard (increments of 100 ms or so)<br />
* decide about none / espresso / lungo based on time<br />
<br />
Might even integrate with esphome / home assistant later.<br />
<br />
=== Remote bat box monitor ===<br />
Idea:<br />
* goal: check if remote bat boxes are occupied and identify the species<br />
* challenges:<br />
** connectivity: need to transport images/videos (no LoRaWAN), possibly out of range of mobile data networks<br />
** autonomy: cannot reach the bat box once installed<br />
** power: no fixed power connection, so probably needs a battery + solar panel<br />
* design<br />
** wake up every hour, take a picture, go to sleep, upload photos/videos once per day<br />
** run from batteries, recharge by solar, rules of thumb<br />
*** batteries should last for about 10 days<br />
*** battery should be able to charge in 1 day<br />
*** consider only 10% of peak solar power<br />
** KPN "4G-op-zee" somewhat confusing article: https://www.kpn.com/zakelijk/mobiel/roaming/noordzee<br />
* hardware<br />
** main processor: raspberry pi zero<br />
*** raspberry pi power consumption overview: https://www.pidramble.com/wiki/benchmarks/power-consumption<br />
** this hat to wake up the main CPU: https://www.waveshare.com/wiki/Power_Management_HAT_(B) sold at https://www.kiwi-electronics.com/en/power-management-hat-for-raspberry-pi-with-rtc-and-rp2040-mcu-11373<br />
<br />
=== KNMI API ===<br />
Get familiar with https://developer.dataplatform.knmi.nl/open-data-api<br />
<br />
=== Grid frequency measurer with web page ===<br />
See https://github.com/bertrik/GridFrequency<br />
SSE source is gridfrequency.local/events<br />
<br />
=== WeAct CH55x board ===<br />
Cheap little boards, using a similar chip as used in USB-serial converters.<br />
<br />
The hardware<br />
https://github.com/WeActStudio/WeActStudio.CH552CoreBoard<br />
<br />
Flashing it:<br />
https://hackaday.io/page/137447-flashing-the-ch552-dev-board-from-the-command-line<br />
<br />
See also:<br />
* https://hackaday.io/project/198238-more-weact-ch5xx<br />
* https://community.platformio.org/t/manually-adding-support-for-ch55x-controller-by-adding-existing-ardunio-core/41138<br />
<br />
=== Zigbee device with esp32 ===<br />
See https://github.com/P-R-O-C-H-Y/arduino-esp32/blob/8169a434c3e46e1bb7711ebcc04f27267db2093c/libraries/ESP32/examples/Zigbee/Zigbee_Light_Bulb/Zigbee_Light_Bulb.ino<br />
<br />
See https://github.com/espressif/arduino-esp32/tree/master/libraries/ESP32/examples/Zigbee<br />
<br />
Espressif32 arduino platform git: https://github.com/platformio/platform-espressif32<br />
<br />
=== Cameratoezicht in Gouda ===<br />
Gemeente Gouda publiceert een lijst van camera's in Gouda, zie<br />
https://gis.gouda.nl/nl/app/Basisviewer_open#!eAGT8uRiNBRy4ZIRYFKSyKkssjJwdzFxNDMz8TKKsLC0cnb0dQ1y5FIByirgkg3xd43ydPYIAQBXGBFm<br />
<br />
Aanmelden (semi-automatisch) bij bijvoorbeeld [https://mapcomplete.org/surveillance Surveillance-under-surveillance] ?<br />
<br />
=== SolarEdge ===<br />
Interact with the solar edge api for PV installations.<br />
<br />
https://developers.solaredge.com/<br />
<br />
See https://github.com/bertrik/solaredge-api<br />
<br />
=== Stookalert ===<br />
Idee: gekleurd lampje dat aangeeft of er op dit moment een stookalert actief is<br />
<br />
Implementatie:<br />
* kijk m.b.v. WiFi locatieservice in welke provincie je je bevindt<br />
* haal JSON op bij https://www.lml.rivm.nl/stookalert/stookalert.json<br />
* toon de bijbehorende kleur op het lampje<br />
<br />
Resources:<br />
* Officiele pagina: https://www.atlasleefomgeving.nl/stookwijzer<br />
* Achterliggende JSON met toestand per provincie: https://www.lml.rivm.nl/stookalert/stookalert.json<br />
* Er moet ook nog ergens een API zijn die fijnmaziger aangeeft wat de toestand is ...<br />
<br />
=== Display of current electricity usage ===<br />
I have a [https://www.zuidwijk.com/product/slimmelezer-plus/ slimme lezer] connected to the P1 port of my smart electricity meter.<br />
The default firmware exposes meter readings using an event stream (SSE) at http://slimmelezer.local/events<br />
<br />
So for example, you can read this with curl:<br />
curl http://slimmelezer.local/events<br />
With result:<br />
event: state<br />
data: {"id":"sensor-power_consumed_phase_1","value":0.046,"state":"0.046 kW"}<br />
<br />
Specification of SSE: https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream<br />
<br />
What I would like to do is to read these events and control a simple display to display the current usage number.<br />
<br />
=== Participating in ultrasonic sound project ===<br />
https://bat-migration-europe.netlify.app/project/<br />
<br />
Use an audiomoth for this.<br />
<br />
=== ESP32 C3 ===<br />
* [https://www.espressif.com/en/products/socs/esp32-c3 processor page]<br />
* [https://wiki.luatos.com/chips/esp32c3/index.html luatos basic esp32 c3 board]<br />
<br />
=== Flexible LED ticker ===<br />
Ordered a flexible 32x8 RGB LED display:<br />
https://nl.aliexpress.com/item/4001296811800.html<br />
<br />
Matching diffuser to be 3D printed:<br />
https://www.thingiverse.com/thing:1903744<br />
<br />
=== Washing machine API ===<br />
https://tratt.net/laurie/blog/2023/displaying_my_washing_machines_remaining_time_with_curl_jq_pizauth.html<br />
<br />
=== TinyML ===<br />
Investigate TinyML, see https://www.tinyml.org/<br />
Apparently can run on a RP2040 (raspi pi pico).<br />
<br />
https://www.hackster.io/mjrobot/esp32-cam-tinyml-image-classification-fruits-vs-veggies-4ab970<br />
<br />
=== Bat box busy signal ===<br />
My brother built little pyramid 'blinkies': solar cell + Lithium-supercapacitor + harvesting circuit + LED encased in clear expoxy.<br />
<br />
Can we add a low-power PIR sensor to this, and make a blinky that blinks if movement was detected by the PIR in the past hour?<br />
<br />
=== Super tiny RFID ===<br />
See https://www.sparkfun.com/products/16464 an almost sand grain size RFID chip, 1.25mmx1.25mmx0.55mm<br />
<br />
The accompanying reader "M6E Nano" is still quite expensive at $235.95 : https://www.sparkfun.com/products/14066<br />
<br />
Uses the MuRata LXMSJZNCMF-198:<br />
"This product can be used as an ultra small tag and this can be<br />
fit on any metal objects, non-metal objects, as well as<br />
embedding into any objects by glue or adhesive and so on."<br />
<br />
See also: ISO18000-63 and EPC global Gen2(v2)<br />
<br />
Specification:<br />
* https://www.gs1.org/standards/rfid/uhf-air-interface-protocol<br />
<br />
=== TheThingsNetwork-Sondehub bridge ===<br />
Uploads balloon telemetry to sondehub.<br />
<br />
See https://github.com/bertrik/ttnhabbridge/issues/6<br />
<br />
=== Actually smart boiler ===<br />
The boiler for hot water is about half of my electricity bill.<br />
The idea is to use/build a smart switch that switches it on at time when electricity prices are lowest.<br />
<br />
Currently have a "Slimme boiler module" from Eneco, which is *not* actually smart,<br />
since it allows me no control whatsoever when it switches on (besides cutting the power in the meterkast).<br />
For example, it will switch on mid-day when my price is high and eneco's price is low, perhaps good for Eneco, not for me. <br />
Apparently, they even received a [https://nieuws.eneco.nl/slim-apparaatje-bij-boiler-vangt-pieken-wind--en-zonnestroom-op/ subsidy] for this.<br />
<br />
A boiler is a pretty big load, about 3 kW, but it is not inductive.<br />
<br />
Alternatives:<br />
* https://www.shelly.cloud/en-nl/products/product-overview/shelly-plus-1-pm-2-pack/shelly-plus-1-pm<br />
* https://www.solyxenergy.nl/solar-iboost/ to store excess solar energy in hot water, might also be useful for just controlling a boiler to use cheaper rates<br />
* tuya smartplug, like https://www.wifilampkoning.nl/merken-slimme-verlichting/tuya/tuya-enkele-smartplug-met-energiemeting ?<br />
* tuya 20A smart plug: https://nl.aliexpress.com/item/1005003347568206.html<br />
<br />
=== Receiving gas meters ===<br />
Apparently gas meters send gas consumption data to the slimme meter using a wireless link in the 868 MHz band.<br />
Probably just FSK at 38.4, as mentioned here: https://a35.veron.nl/nieuwe-elektra-en-gasmeters/<br />
<br />
Interesting leads:<br />
* https://github.com/stef/smeter<br />
* https://www.rtl-sdr.com/reading-household-wireless-utility-meters-with-an-rtl-sdr-and-plotting-the-data-in-home-automation-software/<br />
* https://github.com/bemasher/rtlamr<br />
<br />
=== Multi-network wifi manager ===<br />
Figure out or create software so that ESP8266/ESP32 wifi manager can use multiple networks to connect (not just one),<br />
so it allowing storing credentials for more than one network. For example, the network at home, the hacker space, at work.<br />
Instead of reconfiguring the wifi manager for each network, you just *add* your credentials (and the existing credentials<br />
are not replaced).<br />
<br />
See https://github.com/folkertvanheusden/M.A.X.X<br />
<br />
Interesting candidates:<br />
* https://registry.platformio.org/libraries/martinverges/ESP32%20Wifi%20Manager wifi manager for ESP32, has a REST API for managing wifi network, but is incomplete in the sense that you need to write your own code (e.g. javascript) to actually *use* its API<br />
* https://github.com/arduino-libraries/Arduino_MultiWiFi is the arduino multi wifi library, to allow connecting to multiple different WiFi networks, but it is not a wifi manager, that starts a captive portal, etc<br />
<br />
=== Automated bat counting ===<br />
Can we automatically count the number of bats from the image of a webcam mounted in a bat colony?<br />
Perhaps using some kind of AI or machine learning algorithm?<br />
<br />
The image in question:<br />
https://stofradar.nl/coenecoop/<br />
<br />
=== Use TheThingsIndoorGateway as Helium/ThingSix hotspot ===<br />
I have a spare TTIG that could perhaps be used as a Helium gateway, investigate what is possible.<br />
<br />
One possiblity is to capture the gateway traffic from the TTN gateway events API, convert uplink data to a format that the Helium network understands and forward it.<br />
I don't really care about the Helium crypto tokens, this is just for fun and science.<br />
<br />
What I definitely can do:<br />
* Capture data from the TTN gateway events API, convert it back to Semtech UP format and forward it somewhere to Helium (just not sure where!)<br />
* See also my https://github.com/bertrik/ttn-gateway-collector project which contains an initial implementation of TTN-to-UDP conversion<br />
<br />
Showstoppers:<br />
* If you want to be a gateway on the Helium network, you have to *pay Helium*! Obviously I don't want that, I just want to share data to improve *their* network. <br />
<br />
Open work:<br />
* Investigate if Helium has an open uplink API for their hotspots, if so study it etc, without paying the gateway fee<br />
* Investigate if Thingsix has an open uplink API for their hotspots, if so study it etc, without paying any gateway fee<br />
* Investigate if Thingsix is just another Helium, with weird crypto money<br />
<br />
Interesting stuff:<br />
* https://docs.helium.com/use-the-network/setup-a-packet-forwarder unfortunately the link to setting up the 'light hotspot client' does not work!<br />
* https://docs.helium.com/mine-hnt/light-hotspots/<br />
* https://thingsix.com/<br />
<br />
=== Adding BLE GATT interface to sensors ===<br />
The GATT specification allows measurement properties to be defined and transferred continuously over Bluetooth low-energy.<br />
<br />
With GATT you can define a collection of properties (e.g. measurement items like temperature/humidity/particulate matter/noise, etc)<br />
organised in a simple structure of a BLE service.<br />
The 'notification' method allows you to basically push the data continuously to a connected host, e.g. a smart phone.<br />
<br />
Services collects characteristic, a characteristic has values with units.<br />
Each of these (service, characteristic, unit) have their own unique "UUID".<br />
This is described in the so-called [https://btprodspecificationrefs.blob.core.windows.net/assigned-values/16-bit%20UUID%20Numbers%20Document.pdf 16-bit UUID numbers document]<br />
<br />
Interesting stuff in GATT:<br />
* See GATT_Specification_Supplement_v5 paragraph 3.151, it has a noise characteristic with 1 dB resolution.<br />
* 0x27C3 is the GATT *unit* for sound pressure<br />
* 0x181A is the GATT environmental sensing *service*, document name "ESP_V1.0.0.pdf"<br />
* 0x2A6E is the GATT Characteristic and Object Type for temperature<br />
* 0x2A6F is the GATT Characteristic and Object Type for humidity<br />
* 0x2BD5 is the GATT Characteristic and Object Type for Particulate Matter - PM1 Concentration<br />
* 0x2BD6 is the GATT Characteristic and Object Type for Particulate Matter - PM2.5 Concentration<br />
* 0x2BD7 is the GATT Characteristic and Object Type for Particulate Matter - PM10 Concentration<br />
* Unfortunately I cannot find a characteristic for carbon-dioxide (CO2) in the BLE GATT unit document<br />
<br />
See also https://programmaticponderings.com/2020/08/04/getting-started-with-bluetooth-low-energy-ble-and-generic-attribute-profile-gatt-specification-for-iot/<br />
<br />
=== Reverse engineering XS-8217 bluetooth air quality meter ===<br />
This is a thing that measures CO2, humidity, temperature, TVOC and formaldehyde.<br />
<br />
See also https://wiki.liutyi.info/display/CO2/ZN-2CO3+Inside<br />
<br />
This teardown looks a lot like my sensor: https://www.youtube.com/watch?v=APnjhMrJChI<br />
Mine contains a "TPM-300A" sensor for measuring VOC.<br />
<br />
It has a bluetooth interface, device name is XS-8217.<br />
It has a BLE GATT profile, with the following services<br />
* service 0xC760<br />
** characteristic 0xC762 (WRITE)<br />
** characteristic 0xC761 (NOTIFY)<br />
*** example data: 0x23 0x06 0x10 0x04 0xF1 0x00 0x23 0x65<br />
*** example data: 0x23 0x08 0x10 0x04 0x01 0x9A 0x00 0x0A 0x00 0x03 0x0E<br />
*** data shown on screen was approximately: CO2=418ppm, HCHO=0.003mg/m3, TVOC=0.013mg/m3, temp=24degC, humi=35%<br />
<br />
So data in the characteristic 0xC761 seems to have a 4 byte constant header:<br />
* 0x23<br />
* length byte<br />
<br />
Then we have for the first message: 0x10 0x04 0xF1 0x00 0x23 0x65<br />
* 0x10 0x04 fixed header<br />
* 0xF1 is temperature in 0.1 degree Celcius most likely (24.1)<br />
* 0x00 is ...<br />
* 0x23 is humidity most likely (35)<br />
* 0x65 is ... checksum perhaps<br />
<br />
And for the second message: 0x10 0x04 0x01 0x9A 0x00 0x0A 0x00 0x03 0x0E<br />
* 0x10 0x04 fixed header<br />
* 0x01 0x9A is the CO2 concentration (410)<br />
* 0x00 0x0A is TVOC most likely (10)<br />
* 0x00 0x03 is HCHO most likely (3)<br />
* 0x0E is ... checksum perhaps<br />
<br />
=== ribbon tweeter for bat audio ===<br />
Someone gave me this idea:<br />
Use a ribbon tweeter like this for playing back bat audio:<br />
<s>https://nl.aliexpress.com/item/4000973201791.html</s><br />
<s>https://nl.aliexpress.com/item/1005002565880660.html</s><br />
https://nl.aliexpress.com/item/1005002635086050.html<br />
<br />
The frequency spectrum shows no sign of dropping off at 20 kHz.<br />
<br />
=== 3d glasses ===<br />
I got some 2nd hand 3d glasses, they look exactly like these ones:<br />
* GH-15 https://www.dhgate.com/product/g15-dlp-3d-active-shutter-glasses-96-144hz/213983026.html<br />
* Sintron https://www.amazon.de/Sintron-Kompatibel-TDG-BT500A-TDG-BT400A-Deutschland/dp/B015PCWMZ8<br />
The common name appears to be "G15-DLP".<br />
<br />
A tear-down here:<br />
* https://blog.danman.eu/3d-shutter-glasses-teardown/<br />
<br />
Interesting documents:<br />
* http://cmst.curtin.edu.au/wp-content/uploads/sites/4/2016/05/2012-28-woods-helliwell-cross-compatibility_of_shutter_glasses.pdf<br />
* http://cmst.curtin.edu.au/local/docs/pubs/2011-17-woods-helliwell-3D-Sync-IR.pdf<br />
<br />
Someone claims he got something to work with some hacks:<br />
https://www.avsforum.com/threads/how-i-got-cheap-dlp-link-glasses-to-work-great.1887145/<br />
<br />
=== Waterniveaumeter ===<br />
Op verschillende plekken in Gouda staat er water in de kruipruimte van huizen van bewoners.<br />
Kunnen we dat meten en inzichtelijk maken, voor bewoners, op een kaart bijvoorbeeld?<br />
<br />
Idee:<br />
* in de kruipruimte plaats je een module die waterhoogte kan meten<br />
* de module bestaat uit een microcontroller en een afstandsmeter, die de waterhoogte bepaalt<br />
* de gegevens worden via WiFi doorgestuurd naar een centraal punt, waar de data wordt verwerkt en gevisualiseerd<br />
* op een webpagina kan je een overzicht zien van alle meters die online zijn<br />
* de meting wordt gedaan door bijv. een laser-afstandsmeter of een ultrasoon-afstandsmeter<br />
* voeding? lastig, hoe krijg je 5v naar een potentieel natte plek?<br />
* kosten? verwachting < E 40,-<br />
<br />
In Gouda wordt op veel verschillende plekken de grondwaterstand gemeten, zie https://opendata.munisense.net/portal/wareco-water2/group/581/Gouda-KJ38A , maar:<br />
* geen visualisatie op de kaart, je ziet alleen de meetlokaties d.m.v. een icoontje!<br />
* geen meetpunten in Gouda noord!<br />
<br />
=== Online bat detector ===<br />
Idea: use an ultrasonic microphone, connect it to a WebSDR, so people can tune into bat sounds remotely.<br />
<br />
=== Raspberry pi airplane tracking ===<br />
Apparently now you can also participate in MLAT tracking of planes that don't transmit GPS coordinates themselves.<br />
<br />
=== APRS gateway ===<br />
http://qso365.co.uk/2017/02/a-guide-to-setting-up-an-aprs-receive-only-igate-using-a-raspberry-pi-and-an-rtl-sdr-dongle/<br />
<br />
=== JQ6500 ===<br />
Small inexpensive modules that play mp3 from an internal flash. Could be nice for a custom door bell for example.<br />
<br />
More info at: <br />
* https://www.elecfreaks.com/wiki/index.php?title=JQ6500_Mini_MP3_Module<br />
* https://sparks.gogo.co.nz/jq6500/index.html<br />
<br />
=== FPGA ===<br />
Cheap FPGA boards and nice applications:<br />
* https://bitbucket.org/appanp/artificial-neural-networks/wiki/Home/FPGAsAndNeuralNets.md#!sbcs-and-iot-boards <br />
* [http://nl.aliexpress.com/item/Altera-fpga-cycloneii-ep2c5t144-learning-board-development-board/872520721.html inexpensive ep2c5t144 board] <br />
* http://land-boards.com/blwiki/index.php?title=Cyclone_II_EP2C5_Mini_Dev_Board<br />
<br />
=== Neural networks on low-end hardware ===<br />
Investigate if you can run a powerful neural network on relatively low-end/cheap/low-power hardware. For example a Raspberry pi.<br />
A RPI runs Linux, run python, just like some common neural frameworks.<br />
Do we need hardware acceleration from the GPU and does the RPI GPU support that?<br />
<br />
Read list:<br />
* https://www.zdnet.com/pictures/raspberry-pi-meets-ai-the-projects-that-put-machine-learning-on-the-35-board/<br />
* https://www.pyimagesearch.com/2017/12/18/keras-deep-learning-raspberry-pi/<br />
* https://www.indiegogo.com/projects/sipeed-maix-the-world-first-risc-v-64-ai-module#/<br />
* https://ai.intel.com/intel-neural-compute-stick-2-smarter-faster-plug-and-play-ai-at-the-edge/<br />
<br />
Bought a MaixPy:<br />
* see https://maixpy.sipeed.com/en/<br />
* see https://www.youtube.com/watch?v=KResVuAIMb4<br />
* see http://educ8s.tv/sipeed-m1-dock-review/<br />
* interesting? https://www.instructables.com/id/Transfer-Learning-With-Sipeed-MaiX-and-Arduino-IDE/<br />
<br />
=== mini word clock in dutch ===<br />
Basically an monochrome 8x8 word clock, in Dutch, showing local time in the Netherlands.<br />
<br />
[https://github.com/bertrik/miniwordclock This git repo] has the current code.<br />
<br />
See [https://plus.google.com/103276078656203197145/posts/7ki7rpJzk3a here for a demo] running on an arduino nano.<br />
<br />
The plan is to run this from an ESP8266 instead of an arduino nano, so it can get the time from the internet using NTP.<br />
Andreas Spiess demonstrated on youtube how existing libraries on the ESP8266 can be used to do the local time (including summer-time) calculations.<br />
<br />
=== Cypress PSOC5 ===<br />
Play with the Cypress PSOC5 platform, which combines a ARM Cortex-m3 processor with configurable analog blocks. I'm thinking of combining it with a 24 GHz doppler radar sensor, to process the signal and present it as a USB audio device (stereo signal contains I and Q parts). See [[RadarOnAStick]].<br />
<br />
=== Simple Doppler motion sensors ===<br />
You can find basic doppler microwave motion sensors based on a single transistor, with some weird traces on the PCB very cheaply, for example<br />
* https://www.aliexpress.com/item/RCWL-0516-microwave-radar-sensor-module-Human-body-induction-switch-module-Intelligent-sensor/32708877914.html<br />
<br />
Typically the microwave part of these consists of a single transistor with a rectangular area on one leg and a meandering trace (with lots of vias to the other side) on the other leg.<br />
The output of this circuit seems to go into a chip very much like the ones used in PIR sensors.<br />
<br />
See also https://github.com/jdesbonnet/RCWL-0516 for a reverse engineering effort of these doppler radar modules.<br />
<br />
=== Bare-bones Arduino bat detector ===<br />
This is an idea for a very basic heterodyne bat detector, doing signal processing on an Arduino, requiring minimal external components.<br />
<br />
The basic principle of a heterodyne detector is that it just mixes (multiplies) the audio signal with a square wave, low-pass filters the result and puts it on a speaker.<br />
<br />
Multiplying with a square wave can also be considered to be just alternatively inverting and not-inverting the signal.<br />
So if you sample an ultrasonic signal at twice the rate you want to multiply, you can just subtract odd samples from even samples and low-pass filter that.<br />
<br />
How this can be done in an AVR Arduino:<br />
* sample the audio signal at twice the detection frequency, say 84 kHz. An AVR should just be able to do that.<br />
* apply a 1-pole IIR high-pass filter to remove DC bias, this takes one shift instruction and one addition.<br />
* multiply by the detection frequency, this means just inverting the odd samples.<br />
* low-pass filter the signal, this can be done using a moving average filter, say 16 samples long (first null at 5.25 kHz). Theoretically, averaging 16 samples should result in two bits extra accuracy. This operation takes some storage, an addition and a subtraction.<br />
* output the filtered signal using PWM, possibly at the same rate that we are sampling the input audio.<br />
<br />
The microphone can be a 40 kHz piezo transducer, to keep it cheap (but also limited to 40 kHz).<br />
The pre-amplifier can be a single transistor with some resistors around it, providing about 40x gain.<br />
The arduino does the signal processing (mixing, low-pass filter) to shift the bat audio to human range.<br />
The speaker amplifier can just be a simple two transistor push-pull circuit, since the output from the Arduino is digital/PWM.<br />
<br />
==== AVR Arduino sample rate ====<br />
As far as I understand, the ADC clock can be set to 1 MHz.<br />
Conversion takes 13 cycles, so this can be a problem to reach a sample rate above 80 kHz.<br />
<br />
=== Indoor radar speed sign ===<br />
This idea about placing a simple IQ-output radar sensor indoors in the hacker space, do some basic signal processing on the IQ doppler signal and determine movement speed and direction, then display this on a LED display.<br />
This is of no immediate practical use other than fun, but helps me to gain a bit more experience with microwave radar sensors and eventually build a more effective setup for detecting/counting bats flying in and out of a roost.<br />
<br />
Implement this on a PSOC5 platform or on the STM32 using Arduino.</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=User:Bertrik_Sikken&diff=35034User:Bertrik Sikken2026-01-25T11:52:01Z<p>Bertrik Sikken: </p>
<hr />
<div>{{Smoel<br />
|Name=Bertrik Sikken<br />
|Nick=bertrik<br />
|Tagline=heb ik niet<br />
}}<br />
<br />
You can reach me at [mailto:bertrik@sikken.nl bertrik@sikken.nl] or [mailto:bertrik@gmail.com bertrik@gmail.com].<br />
<br />
Studied Electrical Engineering at Twente University.<br />
<br />
<br />
Main interests:<br />
* reverse-engineering things (USB stuff, mp3 players), worked on http://rockbox.org (sansa clip players)<br />
* studying bats and making electronics for recording/listening to bat sounds<br />
* radio stuff, in particular software-defined radio, LoRa networks<br />
* citizen science and open data (particulate matter measurement, noise, water quality)<br />
* energy-related stuff, visualisation<br />
<br />
Projects I work(ed) on ([https://revspace.nl/index.php?title=User:Bertrik_Sikken&action=purge refresh]):<br />
{{#ask:[[Category:Project]][[Project Contact::bertrik]]<br />
|?Project Status<br />
|headers=show<br />
|link=all<br />
|order=ASC,ASC<br />
|sort=Project Status,Project Name<br />
}}<br />
<br />
<br />
== Project ideas ==<br />
[[File:always10oclock.jpg|right]]<br />
[[File:idea.jpg|right]]<br />
<br />
This is a list of ideas I'm thinking about, but have not fully developed into an actual project yet.<br />
<br />
https://pine64.com/product/128mb-ox64-sbc-available-on-december-2-2022/<br />
<br />
=== investigate thread/matter ===<br />
Matter/thread is the new IKEA standard for home automation thins apparently. <br />
Thread is the wireless protocol, matter is a home automation protocol running on top of thread.<br />
<br />
I have a couple of nrf52840, these are good in doing thread.<br />
<br />
Next steps:<br />
* check out openthread<br />
<pre><br />
git clone https://github.com/openthread/openthread.git<br />
cd openthread<br />
git submodule update --init --recursive<br />
</pre><br />
* Prepare development environment:<br />
scripts/bootstrap<br />
* Build it:<br />
./script/build nrf52840 UART_trans -DOT_LOG_LEVEL=OT_LOG_LEVEL_INFO<br />
<br />
Thread on ESP32:<br />
* on ESP32 C6 https://gist.github.com/gtxaspec/d26198daadfb0a8b0a0edeae2d3fd58f<br />
* https://github.com/espressif/esp-thread-br<br />
* https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_rcp<br />
<br />
=== action lsc stekker ===<br />
https://keetsupport.nl/2024/03/20/how-to-flash-lsc-power-plug-with-esphome/<br />
<br />
https://community.home-assistant.io/t/detailed-guide-on-how-to-flash-the-new-tuya-beken-chips-with-openbk7231t/437276<br />
<br />
=== sipeed maix dock ===<br />
Bought this a couple of years ago. Get familiar with this board.<br />
Can I run a chess program on this, for example?<br />
<br />
* https://wiki.sipeed.com/soft/maixpy/en/develop_kit_board/maix_dock.html<br />
<br />
=== rfid keyfob ===<br />
* aliexpress page: https://nl.aliexpress.com/item/1005009569496736.html<br />
* firmware github: <br />
** https://github.com/RfidResearchGroup/ChameleonUltra<br />
** https://github.com/GameTec-live/ChameleonUltraGUI<br />
<br />
=== advanced lidars for bat detection ===<br />
livox:<br />
* github page https://github.com/Livox-SDK/Livox-SDK/tree/master<br />
* web page: https://www.livoxtech.com/<br />
<br />
=== cubecell meshtastic motion detector ===<br />
I have a cubecell AB01 board.<br />
This board is focused on low power, has a connection to attach a solar panel and has a lora radio.<br />
Relatively small amount of RAM, barely enough to run a LoRaWAN stack but probably plenty to run meshtastic<br />
<br />
The plan is to build a simple motion detector from this (using a PIR).<br />
The PIR can wake up the board from low-power, or a timer can wake it periodically.<br />
<br />
See also: https://github.com/HelTecAutomation/CubeCell-Arduino/tree/master/libraries/Basics/examples/LowPower<br />
<br />
=== configure multitech outdoor gateway ===<br />
https://www.multitech.net/developer/products/multiconnect-conduit-platform/basestation/<br />
<br />
https://multitech.com/product/multitech-conduit-mtcdt-246a-868-eu-gb/<br />
<br />
emergency procedure:<br />
https://www.multitech.net/developer/software/mlinux/using-mlinux/flashing-mlinux-firmware-for-conduit/<br />
<br />
=== esp32 wtf ===<br />
* https://forum.arduino.cc/t/ttgo-lilygo-lora-esp32-26mhz-problem/1353750<br />
* "26 MHz crystal has been deprecated" https://github.com/espressif/arduino-esp32/issues/10117<br />
<br />
=== kakofonie counter ===<br />
Sample room audio, use neural network to distinguish voices to estimate number of people talking in the past 30 seconds or so.<br />
Show this number on some kind of display, publish it to MQTT, make a nice graph of it.<br />
<br />
Stuff to figure out:<br />
* this is called 'speaker diarization'<br />
* can it run on an ESP32?<br />
* make a prototype<br />
<br />
=== hypno toad ===<br />
Put these LEDS https://nl.aliexpress.com/item/1005007583528891.html into https://www.action.com/nl-nl/p/2560347/solar-tuinbeeldje/<br />
<br />
Turns out that the default circuit is really basic and output a rough step-up waveform to the LED.<br />
The self-fading LEDs don't work very well with that.<br />
<br />
Also, putting some IPA on hotglue makes it release really easy.<br />
<br />
=== wasbeer / kat classifier ===<br />
ESP32 with resnet50 neural net to distinguish house cats from other animals, see also:<br />
* https://ieeexplore.ieee.org/document/10556848/<br />
<br />
=== Nespresso brew counter ===<br />
Several hacker spaces have one of these Nespresso cup coffee makers, but there's no obvious easy way to monitor usage (monitor ALL the things!).<br />
Inspired by https://hackaday.com/2021/04/25/arduino-mkr-makes-nespresso-monitoring-easy/ this idea is making an even simpler nespresso monitor,<br />
using an inexpensive WiFi enabled ESP8266 with an ubiquitous I2S microphone such as the INMP441. <br />
<br />
Use this sound monitoring project:<br />
https://github.com/aleiei/ESP8266-BUG-I2S-MIC<br />
and turn it into a WiFi connected brew counter.<br />
<br />
Software for getting microphone data from an ESP8266/I2S mic into Linux https://github.com/bertrik/EspMicServer<br />
Nespresso sound is typically 50 Hz with overtones.<br />
In a recording with the ESP8266, it appears that oddly the 17th harmonic (around 850 Hz) is quite strong.<br />
<br />
The plan in the short term is this:<br />
* apply a gentle IIR filter to subtract any DC bias from the microphone signal<br />
* calculate autocovariance at offsets 0 and 20 ms (inverse of 50 Hz), representing the total energy and the energy at 50 Hz respectively<br />
* compare amplitudes to decide about presence of 50 Hz signal, e.g. calculate ratio in dB<br />
* use this to count the length of time that a 50 Hz signal is heard (increments of 100 ms or so)<br />
* decide about none / espresso / lungo based on time<br />
<br />
Might even integrate with esphome / home assistant later.<br />
<br />
=== Remote bat box monitor ===<br />
Idea:<br />
* goal: check if remote bat boxes are occupied and identify the species<br />
* challenges:<br />
** connectivity: need to transport images/videos (no LoRaWAN), possibly out of range of mobile data networks<br />
** autonomy: cannot reach the bat box once installed<br />
** power: no fixed power connection, so probably needs a battery + solar panel<br />
* design<br />
** wake up every hour, take a picture, go to sleep, upload photos/videos once per day<br />
** run from batteries, recharge by solar, rules of thumb<br />
*** batteries should last for about 10 days<br />
*** battery should be able to charge in 1 day<br />
*** consider only 10% of peak solar power<br />
** KPN "4G-op-zee" somewhat confusing article: https://www.kpn.com/zakelijk/mobiel/roaming/noordzee<br />
* hardware<br />
** main processor: raspberry pi zero<br />
*** raspberry pi power consumption overview: https://www.pidramble.com/wiki/benchmarks/power-consumption<br />
** this hat to wake up the main CPU: https://www.waveshare.com/wiki/Power_Management_HAT_(B) sold at https://www.kiwi-electronics.com/en/power-management-hat-for-raspberry-pi-with-rtc-and-rp2040-mcu-11373<br />
<br />
=== KNMI API ===<br />
Get familiar with https://developer.dataplatform.knmi.nl/open-data-api<br />
<br />
=== Grid frequency measurer with web page ===<br />
See https://github.com/bertrik/GridFrequency<br />
SSE source is gridfrequency.local/events<br />
<br />
=== WeAct CH55x board ===<br />
Cheap little boards, using a similar chip as used in USB-serial converters.<br />
<br />
The hardware<br />
https://github.com/WeActStudio/WeActStudio.CH552CoreBoard<br />
<br />
Flashing it:<br />
https://hackaday.io/page/137447-flashing-the-ch552-dev-board-from-the-command-line<br />
<br />
See also:<br />
* https://hackaday.io/project/198238-more-weact-ch5xx<br />
* https://community.platformio.org/t/manually-adding-support-for-ch55x-controller-by-adding-existing-ardunio-core/41138<br />
<br />
=== Zigbee device with esp32 ===<br />
See https://github.com/P-R-O-C-H-Y/arduino-esp32/blob/8169a434c3e46e1bb7711ebcc04f27267db2093c/libraries/ESP32/examples/Zigbee/Zigbee_Light_Bulb/Zigbee_Light_Bulb.ino<br />
<br />
See https://github.com/espressif/arduino-esp32/tree/master/libraries/ESP32/examples/Zigbee<br />
<br />
Espressif32 arduino platform git: https://github.com/platformio/platform-espressif32<br />
<br />
=== Cameratoezicht in Gouda ===<br />
Gemeente Gouda publiceert een lijst van camera's in Gouda, zie<br />
https://gis.gouda.nl/nl/app/Basisviewer_open#!eAGT8uRiNBRy4ZIRYFKSyKkssjJwdzFxNDMz8TKKsLC0cnb0dQ1y5FIByirgkg3xd43ydPYIAQBXGBFm<br />
<br />
Aanmelden (semi-automatisch) bij bijvoorbeeld [https://mapcomplete.org/surveillance Surveillance-under-surveillance] ?<br />
<br />
=== SolarEdge ===<br />
Interact with the solar edge api for PV installations.<br />
<br />
https://developers.solaredge.com/<br />
<br />
See https://github.com/bertrik/solaredge-api<br />
<br />
=== Stookalert ===<br />
Idee: gekleurd lampje dat aangeeft of er op dit moment een stookalert actief is<br />
<br />
Implementatie:<br />
* kijk m.b.v. WiFi locatieservice in welke provincie je je bevindt<br />
* haal JSON op bij https://www.lml.rivm.nl/stookalert/stookalert.json<br />
* toon de bijbehorende kleur op het lampje<br />
<br />
Resources:<br />
* Officiele pagina: https://www.atlasleefomgeving.nl/stookwijzer<br />
* Achterliggende JSON met toestand per provincie: https://www.lml.rivm.nl/stookalert/stookalert.json<br />
* Er moet ook nog ergens een API zijn die fijnmaziger aangeeft wat de toestand is ...<br />
<br />
=== Display of current electricity usage ===<br />
I have a [https://www.zuidwijk.com/product/slimmelezer-plus/ slimme lezer] connected to the P1 port of my smart electricity meter.<br />
The default firmware exposes meter readings using an event stream (SSE) at http://slimmelezer.local/events<br />
<br />
So for example, you can read this with curl:<br />
curl http://slimmelezer.local/events<br />
With result:<br />
event: state<br />
data: {"id":"sensor-power_consumed_phase_1","value":0.046,"state":"0.046 kW"}<br />
<br />
Specification of SSE: https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream<br />
<br />
What I would like to do is to read these events and control a simple display to display the current usage number.<br />
<br />
=== Participating in ultrasonic sound project ===<br />
https://bat-migration-europe.netlify.app/project/<br />
<br />
Use an audiomoth for this.<br />
<br />
=== ESP32 C3 ===<br />
* [https://www.espressif.com/en/products/socs/esp32-c3 processor page]<br />
* [https://wiki.luatos.com/chips/esp32c3/index.html luatos basic esp32 c3 board]<br />
<br />
=== Flexible LED ticker ===<br />
Ordered a flexible 32x8 RGB LED display:<br />
https://nl.aliexpress.com/item/4001296811800.html<br />
<br />
Matching diffuser to be 3D printed:<br />
https://www.thingiverse.com/thing:1903744<br />
<br />
=== Washing machine API ===<br />
https://tratt.net/laurie/blog/2023/displaying_my_washing_machines_remaining_time_with_curl_jq_pizauth.html<br />
<br />
=== TinyML ===<br />
Investigate TinyML, see https://www.tinyml.org/<br />
Apparently can run on a RP2040 (raspi pi pico).<br />
<br />
https://www.hackster.io/mjrobot/esp32-cam-tinyml-image-classification-fruits-vs-veggies-4ab970<br />
<br />
=== Bat box busy signal ===<br />
My brother built little pyramid 'blinkies': solar cell + Lithium-supercapacitor + harvesting circuit + LED encased in clear expoxy.<br />
<br />
Can we add a low-power PIR sensor to this, and make a blinky that blinks if movement was detected by the PIR in the past hour?<br />
<br />
=== Super tiny RFID ===<br />
See https://www.sparkfun.com/products/16464 an almost sand grain size RFID chip, 1.25mmx1.25mmx0.55mm<br />
<br />
The accompanying reader "M6E Nano" is still quite expensive at $235.95 : https://www.sparkfun.com/products/14066<br />
<br />
Uses the MuRata LXMSJZNCMF-198:<br />
"This product can be used as an ultra small tag and this can be<br />
fit on any metal objects, non-metal objects, as well as<br />
embedding into any objects by glue or adhesive and so on."<br />
<br />
See also: ISO18000-63 and EPC global Gen2(v2)<br />
<br />
Specification:<br />
* https://www.gs1.org/standards/rfid/uhf-air-interface-protocol<br />
<br />
=== TheThingsNetwork-Sondehub bridge ===<br />
Uploads balloon telemetry to sondehub.<br />
<br />
See https://github.com/bertrik/ttnhabbridge/issues/6<br />
<br />
=== Actually smart boiler ===<br />
The boiler for hot water is about half of my electricity bill.<br />
The idea is to use/build a smart switch that switches it on at time when electricity prices are lowest.<br />
<br />
Currently have a "Slimme boiler module" from Eneco, which is *not* actually smart,<br />
since it allows me no control whatsoever when it switches on (besides cutting the power in the meterkast).<br />
For example, it will switch on mid-day when my price is high and eneco's price is low, perhaps good for Eneco, not for me. <br />
Apparently, they even received a [https://nieuws.eneco.nl/slim-apparaatje-bij-boiler-vangt-pieken-wind--en-zonnestroom-op/ subsidy] for this.<br />
<br />
A boiler is a pretty big load, about 3 kW, but it is not inductive.<br />
<br />
Alternatives:<br />
* https://www.shelly.cloud/en-nl/products/product-overview/shelly-plus-1-pm-2-pack/shelly-plus-1-pm<br />
* https://www.solyxenergy.nl/solar-iboost/ to store excess solar energy in hot water, might also be useful for just controlling a boiler to use cheaper rates<br />
* tuya smartplug, like https://www.wifilampkoning.nl/merken-slimme-verlichting/tuya/tuya-enkele-smartplug-met-energiemeting ?<br />
* tuya 20A smart plug: https://nl.aliexpress.com/item/1005003347568206.html<br />
<br />
=== Receiving gas meters ===<br />
Apparently gas meters send gas consumption data to the slimme meter using a wireless link in the 868 MHz band.<br />
Probably just FSK at 38.4, as mentioned here: https://a35.veron.nl/nieuwe-elektra-en-gasmeters/<br />
<br />
Interesting leads:<br />
* https://github.com/stef/smeter<br />
* https://www.rtl-sdr.com/reading-household-wireless-utility-meters-with-an-rtl-sdr-and-plotting-the-data-in-home-automation-software/<br />
* https://github.com/bemasher/rtlamr<br />
<br />
=== Multi-network wifi manager ===<br />
Figure out or create software so that ESP8266/ESP32 wifi manager can use multiple networks to connect (not just one),<br />
so it allowing storing credentials for more than one network. For example, the network at home, the hacker space, at work.<br />
Instead of reconfiguring the wifi manager for each network, you just *add* your credentials (and the existing credentials<br />
are not replaced).<br />
<br />
See https://github.com/folkertvanheusden/M.A.X.X<br />
<br />
Interesting candidates:<br />
* https://registry.platformio.org/libraries/martinverges/ESP32%20Wifi%20Manager wifi manager for ESP32, has a REST API for managing wifi network, but is incomplete in the sense that you need to write your own code (e.g. javascript) to actually *use* its API<br />
* https://github.com/arduino-libraries/Arduino_MultiWiFi is the arduino multi wifi library, to allow connecting to multiple different WiFi networks, but it is not a wifi manager, that starts a captive portal, etc<br />
<br />
=== Automated bat counting ===<br />
Can we automatically count the number of bats from the image of a webcam mounted in a bat colony?<br />
Perhaps using some kind of AI or machine learning algorithm?<br />
<br />
The image in question:<br />
https://stofradar.nl/coenecoop/<br />
<br />
=== Use TheThingsIndoorGateway as Helium/ThingSix hotspot ===<br />
I have a spare TTIG that could perhaps be used as a Helium gateway, investigate what is possible.<br />
<br />
One possiblity is to capture the gateway traffic from the TTN gateway events API, convert uplink data to a format that the Helium network understands and forward it.<br />
I don't really care about the Helium crypto tokens, this is just for fun and science.<br />
<br />
What I definitely can do:<br />
* Capture data from the TTN gateway events API, convert it back to Semtech UP format and forward it somewhere to Helium (just not sure where!)<br />
* See also my https://github.com/bertrik/ttn-gateway-collector project which contains an initial implementation of TTN-to-UDP conversion<br />
<br />
Showstoppers:<br />
* If you want to be a gateway on the Helium network, you have to *pay Helium*! Obviously I don't want that, I just want to share data to improve *their* network. <br />
<br />
Open work:<br />
* Investigate if Helium has an open uplink API for their hotspots, if so study it etc, without paying the gateway fee<br />
* Investigate if Thingsix has an open uplink API for their hotspots, if so study it etc, without paying any gateway fee<br />
* Investigate if Thingsix is just another Helium, with weird crypto money<br />
<br />
Interesting stuff:<br />
* https://docs.helium.com/use-the-network/setup-a-packet-forwarder unfortunately the link to setting up the 'light hotspot client' does not work!<br />
* https://docs.helium.com/mine-hnt/light-hotspots/<br />
* https://thingsix.com/<br />
<br />
=== Adding BLE GATT interface to sensors ===<br />
The GATT specification allows measurement properties to be defined and transferred continuously over Bluetooth low-energy.<br />
<br />
With GATT you can define a collection of properties (e.g. measurement items like temperature/humidity/particulate matter/noise, etc)<br />
organised in a simple structure of a BLE service.<br />
The 'notification' method allows you to basically push the data continuously to a connected host, e.g. a smart phone.<br />
<br />
Services collects characteristic, a characteristic has values with units.<br />
Each of these (service, characteristic, unit) have their own unique "UUID".<br />
This is described in the so-called [https://btprodspecificationrefs.blob.core.windows.net/assigned-values/16-bit%20UUID%20Numbers%20Document.pdf 16-bit UUID numbers document]<br />
<br />
Interesting stuff in GATT:<br />
* See GATT_Specification_Supplement_v5 paragraph 3.151, it has a noise characteristic with 1 dB resolution.<br />
* 0x27C3 is the GATT *unit* for sound pressure<br />
* 0x181A is the GATT environmental sensing *service*, document name "ESP_V1.0.0.pdf"<br />
* 0x2A6E is the GATT Characteristic and Object Type for temperature<br />
* 0x2A6F is the GATT Characteristic and Object Type for humidity<br />
* 0x2BD5 is the GATT Characteristic and Object Type for Particulate Matter - PM1 Concentration<br />
* 0x2BD6 is the GATT Characteristic and Object Type for Particulate Matter - PM2.5 Concentration<br />
* 0x2BD7 is the GATT Characteristic and Object Type for Particulate Matter - PM10 Concentration<br />
* Unfortunately I cannot find a characteristic for carbon-dioxide (CO2) in the BLE GATT unit document<br />
<br />
See also https://programmaticponderings.com/2020/08/04/getting-started-with-bluetooth-low-energy-ble-and-generic-attribute-profile-gatt-specification-for-iot/<br />
<br />
=== Reverse engineering XS-8217 bluetooth air quality meter ===<br />
This is a thing that measures CO2, humidity, temperature, TVOC and formaldehyde.<br />
<br />
See also https://wiki.liutyi.info/display/CO2/ZN-2CO3+Inside<br />
<br />
This teardown looks a lot like my sensor: https://www.youtube.com/watch?v=APnjhMrJChI<br />
Mine contains a "TPM-300A" sensor for measuring VOC.<br />
<br />
It has a bluetooth interface, device name is XS-8217.<br />
It has a BLE GATT profile, with the following services<br />
* service 0xC760<br />
** characteristic 0xC762 (WRITE)<br />
** characteristic 0xC761 (NOTIFY)<br />
*** example data: 0x23 0x06 0x10 0x04 0xF1 0x00 0x23 0x65<br />
*** example data: 0x23 0x08 0x10 0x04 0x01 0x9A 0x00 0x0A 0x00 0x03 0x0E<br />
*** data shown on screen was approximately: CO2=418ppm, HCHO=0.003mg/m3, TVOC=0.013mg/m3, temp=24degC, humi=35%<br />
<br />
So data in the characteristic 0xC761 seems to have a 4 byte constant header:<br />
* 0x23<br />
* length byte<br />
<br />
Then we have for the first message: 0x10 0x04 0xF1 0x00 0x23 0x65<br />
* 0x10 0x04 fixed header<br />
* 0xF1 is temperature in 0.1 degree Celcius most likely (24.1)<br />
* 0x00 is ...<br />
* 0x23 is humidity most likely (35)<br />
* 0x65 is ... checksum perhaps<br />
<br />
And for the second message: 0x10 0x04 0x01 0x9A 0x00 0x0A 0x00 0x03 0x0E<br />
* 0x10 0x04 fixed header<br />
* 0x01 0x9A is the CO2 concentration (410)<br />
* 0x00 0x0A is TVOC most likely (10)<br />
* 0x00 0x03 is HCHO most likely (3)<br />
* 0x0E is ... checksum perhaps<br />
<br />
=== ribbon tweeter for bat audio ===<br />
Someone gave me this idea:<br />
Use a ribbon tweeter like this for playing back bat audio:<br />
<s>https://nl.aliexpress.com/item/4000973201791.html</s><br />
<s>https://nl.aliexpress.com/item/1005002565880660.html</s><br />
https://nl.aliexpress.com/item/1005002635086050.html<br />
<br />
The frequency spectrum shows no sign of dropping off at 20 kHz.<br />
<br />
=== 3d glasses ===<br />
I got some 2nd hand 3d glasses, they look exactly like these ones:<br />
* GH-15 https://www.dhgate.com/product/g15-dlp-3d-active-shutter-glasses-96-144hz/213983026.html<br />
* Sintron https://www.amazon.de/Sintron-Kompatibel-TDG-BT500A-TDG-BT400A-Deutschland/dp/B015PCWMZ8<br />
The common name appears to be "G15-DLP".<br />
<br />
A tear-down here:<br />
* https://blog.danman.eu/3d-shutter-glasses-teardown/<br />
<br />
Interesting documents:<br />
* http://cmst.curtin.edu.au/wp-content/uploads/sites/4/2016/05/2012-28-woods-helliwell-cross-compatibility_of_shutter_glasses.pdf<br />
* http://cmst.curtin.edu.au/local/docs/pubs/2011-17-woods-helliwell-3D-Sync-IR.pdf<br />
<br />
Someone claims he got something to work with some hacks:<br />
https://www.avsforum.com/threads/how-i-got-cheap-dlp-link-glasses-to-work-great.1887145/<br />
<br />
=== Waterniveaumeter ===<br />
Op verschillende plekken in Gouda staat er water in de kruipruimte van huizen van bewoners.<br />
Kunnen we dat meten en inzichtelijk maken, voor bewoners, op een kaart bijvoorbeeld?<br />
<br />
Idee:<br />
* in de kruipruimte plaats je een module die waterhoogte kan meten<br />
* de module bestaat uit een microcontroller en een afstandsmeter, die de waterhoogte bepaalt<br />
* de gegevens worden via WiFi doorgestuurd naar een centraal punt, waar de data wordt verwerkt en gevisualiseerd<br />
* op een webpagina kan je een overzicht zien van alle meters die online zijn<br />
* de meting wordt gedaan door bijv. een laser-afstandsmeter of een ultrasoon-afstandsmeter<br />
* voeding? lastig, hoe krijg je 5v naar een potentieel natte plek?<br />
* kosten? verwachting < E 40,-<br />
<br />
In Gouda wordt op veel verschillende plekken de grondwaterstand gemeten, zie https://opendata.munisense.net/portal/wareco-water2/group/581/Gouda-KJ38A , maar:<br />
* geen visualisatie op de kaart, je ziet alleen de meetlokaties d.m.v. een icoontje!<br />
* geen meetpunten in Gouda noord!<br />
<br />
=== Online bat detector ===<br />
Idea: use an ultrasonic microphone, connect it to a WebSDR, so people can tune into bat sounds remotely.<br />
<br />
=== Raspberry pi airplane tracking ===<br />
Apparently now you can also participate in MLAT tracking of planes that don't transmit GPS coordinates themselves.<br />
<br />
=== APRS gateway ===<br />
http://qso365.co.uk/2017/02/a-guide-to-setting-up-an-aprs-receive-only-igate-using-a-raspberry-pi-and-an-rtl-sdr-dongle/<br />
<br />
=== JQ6500 ===<br />
Small inexpensive modules that play mp3 from an internal flash. Could be nice for a custom door bell for example.<br />
<br />
More info at: <br />
* https://www.elecfreaks.com/wiki/index.php?title=JQ6500_Mini_MP3_Module<br />
* https://sparks.gogo.co.nz/jq6500/index.html<br />
<br />
=== FPGA ===<br />
Cheap FPGA boards and nice applications:<br />
* https://bitbucket.org/appanp/artificial-neural-networks/wiki/Home/FPGAsAndNeuralNets.md#!sbcs-and-iot-boards <br />
* [http://nl.aliexpress.com/item/Altera-fpga-cycloneii-ep2c5t144-learning-board-development-board/872520721.html inexpensive ep2c5t144 board] <br />
* http://land-boards.com/blwiki/index.php?title=Cyclone_II_EP2C5_Mini_Dev_Board<br />
<br />
=== Neural networks on low-end hardware ===<br />
Investigate if you can run a powerful neural network on relatively low-end/cheap/low-power hardware. For example a Raspberry pi.<br />
A RPI runs Linux, run python, just like some common neural frameworks.<br />
Do we need hardware acceleration from the GPU and does the RPI GPU support that?<br />
<br />
Read list:<br />
* https://www.zdnet.com/pictures/raspberry-pi-meets-ai-the-projects-that-put-machine-learning-on-the-35-board/<br />
* https://www.pyimagesearch.com/2017/12/18/keras-deep-learning-raspberry-pi/<br />
* https://www.indiegogo.com/projects/sipeed-maix-the-world-first-risc-v-64-ai-module#/<br />
* https://ai.intel.com/intel-neural-compute-stick-2-smarter-faster-plug-and-play-ai-at-the-edge/<br />
<br />
Bought a MaixPy:<br />
* see https://maixpy.sipeed.com/en/<br />
* see https://www.youtube.com/watch?v=KResVuAIMb4<br />
* see http://educ8s.tv/sipeed-m1-dock-review/<br />
* interesting? https://www.instructables.com/id/Transfer-Learning-With-Sipeed-MaiX-and-Arduino-IDE/<br />
<br />
=== mini word clock in dutch ===<br />
Basically an monochrome 8x8 word clock, in Dutch, showing local time in the Netherlands.<br />
<br />
[https://github.com/bertrik/miniwordclock This git repo] has the current code.<br />
<br />
See [https://plus.google.com/103276078656203197145/posts/7ki7rpJzk3a here for a demo] running on an arduino nano.<br />
<br />
The plan is to run this from an ESP8266 instead of an arduino nano, so it can get the time from the internet using NTP.<br />
Andreas Spiess demonstrated on youtube how existing libraries on the ESP8266 can be used to do the local time (including summer-time) calculations.<br />
<br />
=== Cypress PSOC5 ===<br />
Play with the Cypress PSOC5 platform, which combines a ARM Cortex-m3 processor with configurable analog blocks. I'm thinking of combining it with a 24 GHz doppler radar sensor, to process the signal and present it as a USB audio device (stereo signal contains I and Q parts). See [[RadarOnAStick]].<br />
<br />
=== Simple Doppler motion sensors ===<br />
You can find basic doppler microwave motion sensors based on a single transistor, with some weird traces on the PCB very cheaply, for example<br />
* https://www.aliexpress.com/item/RCWL-0516-microwave-radar-sensor-module-Human-body-induction-switch-module-Intelligent-sensor/32708877914.html<br />
<br />
Typically the microwave part of these consists of a single transistor with a rectangular area on one leg and a meandering trace (with lots of vias to the other side) on the other leg.<br />
The output of this circuit seems to go into a chip very much like the ones used in PIR sensors.<br />
<br />
See also https://github.com/jdesbonnet/RCWL-0516 for a reverse engineering effort of these doppler radar modules.<br />
<br />
=== Bare-bones Arduino bat detector ===<br />
This is an idea for a very basic heterodyne bat detector, doing signal processing on an Arduino, requiring minimal external components.<br />
<br />
The basic principle of a heterodyne detector is that it just mixes (multiplies) the audio signal with a square wave, low-pass filters the result and puts it on a speaker.<br />
<br />
Multiplying with a square wave can also be considered to be just alternatively inverting and not-inverting the signal.<br />
So if you sample an ultrasonic signal at twice the rate you want to multiply, you can just subtract odd samples from even samples and low-pass filter that.<br />
<br />
How this can be done in an AVR Arduino:<br />
* sample the audio signal at twice the detection frequency, say 84 kHz. An AVR should just be able to do that.<br />
* apply a 1-pole IIR high-pass filter to remove DC bias, this takes one shift instruction and one addition.<br />
* multiply by the detection frequency, this means just inverting the odd samples.<br />
* low-pass filter the signal, this can be done using a moving average filter, say 16 samples long (first null at 5.25 kHz). Theoretically, averaging 16 samples should result in two bits extra accuracy. This operation takes some storage, an addition and a subtraction.<br />
* output the filtered signal using PWM, possibly at the same rate that we are sampling the input audio.<br />
<br />
The microphone can be a 40 kHz piezo transducer, to keep it cheap (but also limited to 40 kHz).<br />
The pre-amplifier can be a single transistor with some resistors around it, providing about 40x gain.<br />
The arduino does the signal processing (mixing, low-pass filter) to shift the bat audio to human range.<br />
The speaker amplifier can just be a simple two transistor push-pull circuit, since the output from the Arduino is digital/PWM.<br />
<br />
==== AVR Arduino sample rate ====<br />
As far as I understand, the ADC clock can be set to 1 MHz.<br />
Conversion takes 13 cycles, so this can be a problem to reach a sample rate above 80 kHz.<br />
<br />
=== Indoor radar speed sign ===<br />
This idea about placing a simple IQ-output radar sensor indoors in the hacker space, do some basic signal processing on the IQ doppler signal and determine movement speed and direction, then display this on a LED display.<br />
This is of no immediate practical use other than fun, but helps me to gain a bit more experience with microwave radar sensors and eventually build a more effective setup for detecting/counting bats flying in and out of a roost.<br />
<br />
Implement this on a PSOC5 platform or on the STM32 using Arduino.</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=User:Bertrik_Sikken&diff=34992User:Bertrik Sikken2026-01-17T11:50:09Z<p>Bertrik Sikken: /* investigate thread/matter */</p>
<hr />
<div>{{Smoel<br />
|Name=Bertrik Sikken<br />
|Nick=bertrik<br />
|Tagline=heb ik niet<br />
}}<br />
<br />
You can reach me at [mailto:bertrik@sikken.nl bertrik@sikken.nl] or [mailto:bertrik@gmail.com bertrik@gmail.com].<br />
<br />
Studied Electrical Engineering at Twente University.<br />
<br />
<br />
Main interests:<br />
* reverse-engineering things (USB stuff, mp3 players), worked on http://rockbox.org (sansa clip players)<br />
* studying bats and making electronics for recording/listening to bat sounds<br />
* radio stuff, in particular software-defined radio<br />
* energy-related stuff, visualisation<br />
* citizen science, particulate matter measurement, noise<br />
<br />
Projects I work(ed) on ([https://revspace.nl/index.php?title=User:Bertrik_Sikken&action=purge refresh]):<br />
{{#ask:[[Category:Project]][[Project Contact::bertrik]]<br />
|?Project Status<br />
|headers=show<br />
|link=all<br />
|order=ASC,ASC<br />
|sort=Project Status,Project Name<br />
}}<br />
<br />
<br />
== Project ideas ==<br />
[[File:always10oclock.jpg|right]]<br />
[[File:idea.jpg|right]]<br />
<br />
This is a list of ideas I'm thinking about, but have not fully developed into an actual project yet.<br />
<br />
https://pine64.com/product/128mb-ox64-sbc-available-on-december-2-2022/<br />
<br />
=== investigate thread/matter ===<br />
Matter/thread is the new IKEA standard for home automation thins apparently. <br />
Thread is the wireless protocol, matter is a home automation protocol running on top of thread.<br />
<br />
I have a couple of nrf52840, these are good in doing thread.<br />
<br />
Next steps:<br />
* check out openthread<br />
<pre><br />
git clone https://github.com/openthread/openthread.git<br />
cd openthread<br />
git submodule update --init --recursive<br />
</pre><br />
* Prepare development environment:<br />
scripts/bootstrap<br />
* Build it:<br />
./script/build nrf52840 UART_trans -DOT_LOG_LEVEL=OT_LOG_LEVEL_INFO<br />
<br />
Thread on ESP32:<br />
* on ESP32 C6 https://gist.github.com/gtxaspec/d26198daadfb0a8b0a0edeae2d3fd58f<br />
* https://github.com/espressif/esp-thread-br<br />
* https://github.com/espressif/esp-idf/tree/master/examples/openthread/ot_rcp<br />
<br />
=== action lsc stekker ===<br />
https://keetsupport.nl/2024/03/20/how-to-flash-lsc-power-plug-with-esphome/<br />
<br />
https://community.home-assistant.io/t/detailed-guide-on-how-to-flash-the-new-tuya-beken-chips-with-openbk7231t/437276<br />
<br />
=== sipeed maix dock ===<br />
Bought this a couple of years ago. Get familiar with this board.<br />
Can I run a chess program on this, for example?<br />
<br />
* https://wiki.sipeed.com/soft/maixpy/en/develop_kit_board/maix_dock.html<br />
<br />
=== rfid keyfob ===<br />
* aliexpress page: https://nl.aliexpress.com/item/1005009569496736.html<br />
* firmware github: <br />
** https://github.com/RfidResearchGroup/ChameleonUltra<br />
** https://github.com/GameTec-live/ChameleonUltraGUI<br />
<br />
=== advanced lidars for bat detection ===<br />
livox:<br />
* github page https://github.com/Livox-SDK/Livox-SDK/tree/master<br />
* web page: https://www.livoxtech.com/<br />
<br />
=== cubecell meshtastic motion detector ===<br />
I have a cubecell AB01 board.<br />
This board is focused on low power, has a connection to attach a solar panel and has a lora radio.<br />
Relatively small amount of RAM, barely enough to run a LoRaWAN stack but probably plenty to run meshtastic<br />
<br />
The plan is to build a simple motion detector from this (using a PIR).<br />
The PIR can wake up the board from low-power, or a timer can wake it periodically.<br />
<br />
See also: https://github.com/HelTecAutomation/CubeCell-Arduino/tree/master/libraries/Basics/examples/LowPower<br />
<br />
=== configure multitech outdoor gateway ===<br />
https://www.multitech.net/developer/products/multiconnect-conduit-platform/basestation/<br />
<br />
https://multitech.com/product/multitech-conduit-mtcdt-246a-868-eu-gb/<br />
<br />
emergency procedure:<br />
https://www.multitech.net/developer/software/mlinux/using-mlinux/flashing-mlinux-firmware-for-conduit/<br />
<br />
=== esp32 wtf ===<br />
* https://forum.arduino.cc/t/ttgo-lilygo-lora-esp32-26mhz-problem/1353750<br />
* "26 MHz crystal has been deprecated" https://github.com/espressif/arduino-esp32/issues/10117<br />
<br />
=== kakofonie counter ===<br />
Sample room audio, use neural network to distinguish voices to estimate number of people talking in the past 30 seconds or so.<br />
Show this number on some kind of display, publish it to MQTT, make a nice graph of it.<br />
<br />
Stuff to figure out:<br />
* this is called 'speaker diarization'<br />
* can it run on an ESP32?<br />
* make a prototype<br />
<br />
=== hypno toad ===<br />
Put these LEDS https://nl.aliexpress.com/item/1005007583528891.html into https://www.action.com/nl-nl/p/2560347/solar-tuinbeeldje/<br />
<br />
Turns out that the default circuit is really basic and output a rough step-up waveform to the LED.<br />
The self-fading LEDs don't work very well with that.<br />
<br />
Also, putting some IPA on hotglue makes it release really easy.<br />
<br />
=== wasbeer / kat classifier ===<br />
ESP32 with resnet50 neural net to distinguish house cats from other animals, see also:<br />
* https://ieeexplore.ieee.org/document/10556848/<br />
<br />
=== Nespresso brew counter ===<br />
Several hacker spaces have one of these Nespresso cup coffee makers, but there's no obvious easy way to monitor usage (monitor ALL the things!).<br />
Inspired by https://hackaday.com/2021/04/25/arduino-mkr-makes-nespresso-monitoring-easy/ this idea is making an even simpler nespresso monitor,<br />
using an inexpensive WiFi enabled ESP8266 with an ubiquitous I2S microphone such as the INMP441. <br />
<br />
Use this sound monitoring project:<br />
https://github.com/aleiei/ESP8266-BUG-I2S-MIC<br />
and turn it into a WiFi connected brew counter.<br />
<br />
Software for getting microphone data from an ESP8266/I2S mic into Linux https://github.com/bertrik/EspMicServer<br />
Nespresso sound is typically 50 Hz with overtones.<br />
In a recording with the ESP8266, it appears that oddly the 17th harmonic (around 850 Hz) is quite strong.<br />
<br />
The plan in the short term is this:<br />
* apply a gentle IIR filter to subtract any DC bias from the microphone signal<br />
* calculate autocovariance at offsets 0 and 20 ms (inverse of 50 Hz), representing the total energy and the energy at 50 Hz respectively<br />
* compare amplitudes to decide about presence of 50 Hz signal, e.g. calculate ratio in dB<br />
* use this to count the length of time that a 50 Hz signal is heard (increments of 100 ms or so)<br />
* decide about none / espresso / lungo based on time<br />
<br />
Might even integrate with esphome / home assistant later.<br />
<br />
=== Remote bat box monitor ===<br />
Idea:<br />
* goal: check if remote bat boxes are occupied and identify the species<br />
* challenges:<br />
** connectivity: need to transport images/videos (no LoRaWAN), possibly out of range of mobile data networks<br />
** autonomy: cannot reach the bat box once installed<br />
** power: no fixed power connection, so probably needs a battery + solar panel<br />
* design<br />
** wake up every hour, take a picture, go to sleep, upload photos/videos once per day<br />
** run from batteries, recharge by solar, rules of thumb<br />
*** batteries should last for about 10 days<br />
*** battery should be able to charge in 1 day<br />
*** consider only 10% of peak solar power<br />
** KPN "4G-op-zee" somewhat confusing article: https://www.kpn.com/zakelijk/mobiel/roaming/noordzee<br />
* hardware<br />
** main processor: raspberry pi zero<br />
*** raspberry pi power consumption overview: https://www.pidramble.com/wiki/benchmarks/power-consumption<br />
** this hat to wake up the main CPU: https://www.waveshare.com/wiki/Power_Management_HAT_(B) sold at https://www.kiwi-electronics.com/en/power-management-hat-for-raspberry-pi-with-rtc-and-rp2040-mcu-11373<br />
<br />
=== KNMI API ===<br />
Get familiar with https://developer.dataplatform.knmi.nl/open-data-api<br />
<br />
=== Grid frequency measurer with web page ===<br />
See https://github.com/bertrik/GridFrequency<br />
SSE source is gridfrequency.local/events<br />
<br />
=== WeAct CH55x board ===<br />
Cheap little boards, using a similar chip as used in USB-serial converters.<br />
<br />
The hardware<br />
https://github.com/WeActStudio/WeActStudio.CH552CoreBoard<br />
<br />
Flashing it:<br />
https://hackaday.io/page/137447-flashing-the-ch552-dev-board-from-the-command-line<br />
<br />
See also:<br />
* https://hackaday.io/project/198238-more-weact-ch5xx<br />
* https://community.platformio.org/t/manually-adding-support-for-ch55x-controller-by-adding-existing-ardunio-core/41138<br />
<br />
=== Zigbee device with esp32 ===<br />
See https://github.com/P-R-O-C-H-Y/arduino-esp32/blob/8169a434c3e46e1bb7711ebcc04f27267db2093c/libraries/ESP32/examples/Zigbee/Zigbee_Light_Bulb/Zigbee_Light_Bulb.ino<br />
<br />
See https://github.com/espressif/arduino-esp32/tree/master/libraries/ESP32/examples/Zigbee<br />
<br />
Espressif32 arduino platform git: https://github.com/platformio/platform-espressif32<br />
<br />
=== Cameratoezicht in Gouda ===<br />
Gemeente Gouda publiceert een lijst van camera's in Gouda, zie<br />
https://gis.gouda.nl/nl/app/Basisviewer_open#!eAGT8uRiNBRy4ZIRYFKSyKkssjJwdzFxNDMz8TKKsLC0cnb0dQ1y5FIByirgkg3xd43ydPYIAQBXGBFm<br />
<br />
Aanmelden (semi-automatisch) bij bijvoorbeeld [https://mapcomplete.org/surveillance Surveillance-under-surveillance] ?<br />
<br />
=== SolarEdge ===<br />
Interact with the solar edge api for PV installations.<br />
<br />
https://developers.solaredge.com/<br />
<br />
See https://github.com/bertrik/solaredge-api<br />
<br />
=== Stookalert ===<br />
Idee: gekleurd lampje dat aangeeft of er op dit moment een stookalert actief is<br />
<br />
Implementatie:<br />
* kijk m.b.v. WiFi locatieservice in welke provincie je je bevindt<br />
* haal JSON op bij https://www.lml.rivm.nl/stookalert/stookalert.json<br />
* toon de bijbehorende kleur op het lampje<br />
<br />
Resources:<br />
* Officiele pagina: https://www.atlasleefomgeving.nl/stookwijzer<br />
* Achterliggende JSON met toestand per provincie: https://www.lml.rivm.nl/stookalert/stookalert.json<br />
* Er moet ook nog ergens een API zijn die fijnmaziger aangeeft wat de toestand is ...<br />
<br />
=== Display of current electricity usage ===<br />
I have a [https://www.zuidwijk.com/product/slimmelezer-plus/ slimme lezer] connected to the P1 port of my smart electricity meter.<br />
The default firmware exposes meter readings using an event stream (SSE) at http://slimmelezer.local/events<br />
<br />
So for example, you can read this with curl:<br />
curl http://slimmelezer.local/events<br />
With result:<br />
event: state<br />
data: {"id":"sensor-power_consumed_phase_1","value":0.046,"state":"0.046 kW"}<br />
<br />
Specification of SSE: https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream<br />
<br />
What I would like to do is to read these events and control a simple display to display the current usage number.<br />
<br />
=== Participating in ultrasonic sound project ===<br />
https://bat-migration-europe.netlify.app/project/<br />
<br />
Use an audiomoth for this.<br />
<br />
=== ESP32 C3 ===<br />
* [https://www.espressif.com/en/products/socs/esp32-c3 processor page]<br />
* [https://wiki.luatos.com/chips/esp32c3/index.html luatos basic esp32 c3 board]<br />
<br />
=== Flexible LED ticker ===<br />
Ordered a flexible 32x8 RGB LED display:<br />
https://nl.aliexpress.com/item/4001296811800.html<br />
<br />
Matching diffuser to be 3D printed:<br />
https://www.thingiverse.com/thing:1903744<br />
<br />
=== Washing machine API ===<br />
https://tratt.net/laurie/blog/2023/displaying_my_washing_machines_remaining_time_with_curl_jq_pizauth.html<br />
<br />
=== TinyML ===<br />
Investigate TinyML, see https://www.tinyml.org/<br />
Apparently can run on a RP2040 (raspi pi pico).<br />
<br />
https://www.hackster.io/mjrobot/esp32-cam-tinyml-image-classification-fruits-vs-veggies-4ab970<br />
<br />
=== Bat box busy signal ===<br />
My brother built little pyramid 'blinkies': solar cell + Lithium-supercapacitor + harvesting circuit + LED encased in clear expoxy.<br />
<br />
Can we add a low-power PIR sensor to this, and make a blinky that blinks if movement was detected by the PIR in the past hour?<br />
<br />
=== Super tiny RFID ===<br />
See https://www.sparkfun.com/products/16464 an almost sand grain size RFID chip, 1.25mmx1.25mmx0.55mm<br />
<br />
The accompanying reader "M6E Nano" is still quite expensive at $235.95 : https://www.sparkfun.com/products/14066<br />
<br />
Uses the MuRata LXMSJZNCMF-198:<br />
"This product can be used as an ultra small tag and this can be<br />
fit on any metal objects, non-metal objects, as well as<br />
embedding into any objects by glue or adhesive and so on."<br />
<br />
See also: ISO18000-63 and EPC global Gen2(v2)<br />
<br />
Specification:<br />
* https://www.gs1.org/standards/rfid/uhf-air-interface-protocol<br />
<br />
=== TheThingsNetwork-Sondehub bridge ===<br />
Uploads balloon telemetry to sondehub.<br />
<br />
See https://github.com/bertrik/ttnhabbridge/issues/6<br />
<br />
=== Actually smart boiler ===<br />
The boiler for hot water is about half of my electricity bill.<br />
The idea is to use/build a smart switch that switches it on at time when electricity prices are lowest.<br />
<br />
Currently have a "Slimme boiler module" from Eneco, which is *not* actually smart,<br />
since it allows me no control whatsoever when it switches on (besides cutting the power in the meterkast).<br />
For example, it will switch on mid-day when my price is high and eneco's price is low, perhaps good for Eneco, not for me. <br />
Apparently, they even received a [https://nieuws.eneco.nl/slim-apparaatje-bij-boiler-vangt-pieken-wind--en-zonnestroom-op/ subsidy] for this.<br />
<br />
A boiler is a pretty big load, about 3 kW, but it is not inductive.<br />
<br />
Alternatives:<br />
* https://www.shelly.cloud/en-nl/products/product-overview/shelly-plus-1-pm-2-pack/shelly-plus-1-pm<br />
* https://www.solyxenergy.nl/solar-iboost/ to store excess solar energy in hot water, might also be useful for just controlling a boiler to use cheaper rates<br />
* tuya smartplug, like https://www.wifilampkoning.nl/merken-slimme-verlichting/tuya/tuya-enkele-smartplug-met-energiemeting ?<br />
* tuya 20A smart plug: https://nl.aliexpress.com/item/1005003347568206.html<br />
<br />
=== Receiving gas meters ===<br />
Apparently gas meters send gas consumption data to the slimme meter using a wireless link in the 868 MHz band.<br />
Probably just FSK at 38.4, as mentioned here: https://a35.veron.nl/nieuwe-elektra-en-gasmeters/<br />
<br />
Interesting leads:<br />
* https://github.com/stef/smeter<br />
* https://www.rtl-sdr.com/reading-household-wireless-utility-meters-with-an-rtl-sdr-and-plotting-the-data-in-home-automation-software/<br />
* https://github.com/bemasher/rtlamr<br />
<br />
=== Multi-network wifi manager ===<br />
Figure out or create software so that ESP8266/ESP32 wifi manager can use multiple networks to connect (not just one),<br />
so it allowing storing credentials for more than one network. For example, the network at home, the hacker space, at work.<br />
Instead of reconfiguring the wifi manager for each network, you just *add* your credentials (and the existing credentials<br />
are not replaced).<br />
<br />
See https://github.com/folkertvanheusden/M.A.X.X<br />
<br />
Interesting candidates:<br />
* https://registry.platformio.org/libraries/martinverges/ESP32%20Wifi%20Manager wifi manager for ESP32, has a REST API for managing wifi network, but is incomplete in the sense that you need to write your own code (e.g. javascript) to actually *use* its API<br />
* https://github.com/arduino-libraries/Arduino_MultiWiFi is the arduino multi wifi library, to allow connecting to multiple different WiFi networks, but it is not a wifi manager, that starts a captive portal, etc<br />
<br />
=== Automated bat counting ===<br />
Can we automatically count the number of bats from the image of a webcam mounted in a bat colony?<br />
Perhaps using some kind of AI or machine learning algorithm?<br />
<br />
The image in question:<br />
https://stofradar.nl/coenecoop/<br />
<br />
=== Use TheThingsIndoorGateway as Helium/ThingSix hotspot ===<br />
I have a spare TTIG that could perhaps be used as a Helium gateway, investigate what is possible.<br />
<br />
One possiblity is to capture the gateway traffic from the TTN gateway events API, convert uplink data to a format that the Helium network understands and forward it.<br />
I don't really care about the Helium crypto tokens, this is just for fun and science.<br />
<br />
What I definitely can do:<br />
* Capture data from the TTN gateway events API, convert it back to Semtech UP format and forward it somewhere to Helium (just not sure where!)<br />
* See also my https://github.com/bertrik/ttn-gateway-collector project which contains an initial implementation of TTN-to-UDP conversion<br />
<br />
Showstoppers:<br />
* If you want to be a gateway on the Helium network, you have to *pay Helium*! Obviously I don't want that, I just want to share data to improve *their* network. <br />
<br />
Open work:<br />
* Investigate if Helium has an open uplink API for their hotspots, if so study it etc, without paying the gateway fee<br />
* Investigate if Thingsix has an open uplink API for their hotspots, if so study it etc, without paying any gateway fee<br />
* Investigate if Thingsix is just another Helium, with weird crypto money<br />
<br />
Interesting stuff:<br />
* https://docs.helium.com/use-the-network/setup-a-packet-forwarder unfortunately the link to setting up the 'light hotspot client' does not work!<br />
* https://docs.helium.com/mine-hnt/light-hotspots/<br />
* https://thingsix.com/<br />
<br />
=== Adding BLE GATT interface to sensors ===<br />
The GATT specification allows measurement properties to be defined and transferred continuously over Bluetooth low-energy.<br />
<br />
With GATT you can define a collection of properties (e.g. measurement items like temperature/humidity/particulate matter/noise, etc)<br />
organised in a simple structure of a BLE service.<br />
The 'notification' method allows you to basically push the data continuously to a connected host, e.g. a smart phone.<br />
<br />
Services collects characteristic, a characteristic has values with units.<br />
Each of these (service, characteristic, unit) have their own unique "UUID".<br />
This is described in the so-called [https://btprodspecificationrefs.blob.core.windows.net/assigned-values/16-bit%20UUID%20Numbers%20Document.pdf 16-bit UUID numbers document]<br />
<br />
Interesting stuff in GATT:<br />
* See GATT_Specification_Supplement_v5 paragraph 3.151, it has a noise characteristic with 1 dB resolution.<br />
* 0x27C3 is the GATT *unit* for sound pressure<br />
* 0x181A is the GATT environmental sensing *service*, document name "ESP_V1.0.0.pdf"<br />
* 0x2A6E is the GATT Characteristic and Object Type for temperature<br />
* 0x2A6F is the GATT Characteristic and Object Type for humidity<br />
* 0x2BD5 is the GATT Characteristic and Object Type for Particulate Matter - PM1 Concentration<br />
* 0x2BD6 is the GATT Characteristic and Object Type for Particulate Matter - PM2.5 Concentration<br />
* 0x2BD7 is the GATT Characteristic and Object Type for Particulate Matter - PM10 Concentration<br />
* Unfortunately I cannot find a characteristic for carbon-dioxide (CO2) in the BLE GATT unit document<br />
<br />
See also https://programmaticponderings.com/2020/08/04/getting-started-with-bluetooth-low-energy-ble-and-generic-attribute-profile-gatt-specification-for-iot/<br />
<br />
=== Reverse engineering XS-8217 bluetooth air quality meter ===<br />
This is a thing that measures CO2, humidity, temperature, TVOC and formaldehyde.<br />
<br />
See also https://wiki.liutyi.info/display/CO2/ZN-2CO3+Inside<br />
<br />
This teardown looks a lot like my sensor: https://www.youtube.com/watch?v=APnjhMrJChI<br />
Mine contains a "TPM-300A" sensor for measuring VOC.<br />
<br />
It has a bluetooth interface, device name is XS-8217.<br />
It has a BLE GATT profile, with the following services<br />
* service 0xC760<br />
** characteristic 0xC762 (WRITE)<br />
** characteristic 0xC761 (NOTIFY)<br />
*** example data: 0x23 0x06 0x10 0x04 0xF1 0x00 0x23 0x65<br />
*** example data: 0x23 0x08 0x10 0x04 0x01 0x9A 0x00 0x0A 0x00 0x03 0x0E<br />
*** data shown on screen was approximately: CO2=418ppm, HCHO=0.003mg/m3, TVOC=0.013mg/m3, temp=24degC, humi=35%<br />
<br />
So data in the characteristic 0xC761 seems to have a 4 byte constant header:<br />
* 0x23<br />
* length byte<br />
<br />
Then we have for the first message: 0x10 0x04 0xF1 0x00 0x23 0x65<br />
* 0x10 0x04 fixed header<br />
* 0xF1 is temperature in 0.1 degree Celcius most likely (24.1)<br />
* 0x00 is ...<br />
* 0x23 is humidity most likely (35)<br />
* 0x65 is ... checksum perhaps<br />
<br />
And for the second message: 0x10 0x04 0x01 0x9A 0x00 0x0A 0x00 0x03 0x0E<br />
* 0x10 0x04 fixed header<br />
* 0x01 0x9A is the CO2 concentration (410)<br />
* 0x00 0x0A is TVOC most likely (10)<br />
* 0x00 0x03 is HCHO most likely (3)<br />
* 0x0E is ... checksum perhaps<br />
<br />
=== ribbon tweeter for bat audio ===<br />
Someone gave me this idea:<br />
Use a ribbon tweeter like this for playing back bat audio:<br />
<s>https://nl.aliexpress.com/item/4000973201791.html</s><br />
<s>https://nl.aliexpress.com/item/1005002565880660.html</s><br />
https://nl.aliexpress.com/item/1005002635086050.html<br />
<br />
The frequency spectrum shows no sign of dropping off at 20 kHz.<br />
<br />
=== 3d glasses ===<br />
I got some 2nd hand 3d glasses, they look exactly like these ones:<br />
* GH-15 https://www.dhgate.com/product/g15-dlp-3d-active-shutter-glasses-96-144hz/213983026.html<br />
* Sintron https://www.amazon.de/Sintron-Kompatibel-TDG-BT500A-TDG-BT400A-Deutschland/dp/B015PCWMZ8<br />
The common name appears to be "G15-DLP".<br />
<br />
A tear-down here:<br />
* https://blog.danman.eu/3d-shutter-glasses-teardown/<br />
<br />
Interesting documents:<br />
* http://cmst.curtin.edu.au/wp-content/uploads/sites/4/2016/05/2012-28-woods-helliwell-cross-compatibility_of_shutter_glasses.pdf<br />
* http://cmst.curtin.edu.au/local/docs/pubs/2011-17-woods-helliwell-3D-Sync-IR.pdf<br />
<br />
Someone claims he got something to work with some hacks:<br />
https://www.avsforum.com/threads/how-i-got-cheap-dlp-link-glasses-to-work-great.1887145/<br />
<br />
=== Waterniveaumeter ===<br />
Op verschillende plekken in Gouda staat er water in de kruipruimte van huizen van bewoners.<br />
Kunnen we dat meten en inzichtelijk maken, voor bewoners, op een kaart bijvoorbeeld?<br />
<br />
Idee:<br />
* in de kruipruimte plaats je een module die waterhoogte kan meten<br />
* de module bestaat uit een microcontroller en een afstandsmeter, die de waterhoogte bepaalt<br />
* de gegevens worden via WiFi doorgestuurd naar een centraal punt, waar de data wordt verwerkt en gevisualiseerd<br />
* op een webpagina kan je een overzicht zien van alle meters die online zijn<br />
* de meting wordt gedaan door bijv. een laser-afstandsmeter of een ultrasoon-afstandsmeter<br />
* voeding? lastig, hoe krijg je 5v naar een potentieel natte plek?<br />
* kosten? verwachting < E 40,-<br />
<br />
In Gouda wordt op veel verschillende plekken de grondwaterstand gemeten, zie https://opendata.munisense.net/portal/wareco-water2/group/581/Gouda-KJ38A , maar:<br />
* geen visualisatie op de kaart, je ziet alleen de meetlokaties d.m.v. een icoontje!<br />
* geen meetpunten in Gouda noord!<br />
<br />
=== Online bat detector ===<br />
Idea: use an ultrasonic microphone, connect it to a WebSDR, so people can tune into bat sounds remotely.<br />
<br />
=== Raspberry pi airplane tracking ===<br />
Apparently now you can also participate in MLAT tracking of planes that don't transmit GPS coordinates themselves.<br />
<br />
=== APRS gateway ===<br />
http://qso365.co.uk/2017/02/a-guide-to-setting-up-an-aprs-receive-only-igate-using-a-raspberry-pi-and-an-rtl-sdr-dongle/<br />
<br />
=== JQ6500 ===<br />
Small inexpensive modules that play mp3 from an internal flash. Could be nice for a custom door bell for example.<br />
<br />
More info at: <br />
* https://www.elecfreaks.com/wiki/index.php?title=JQ6500_Mini_MP3_Module<br />
* https://sparks.gogo.co.nz/jq6500/index.html<br />
<br />
=== FPGA ===<br />
Cheap FPGA boards and nice applications:<br />
* https://bitbucket.org/appanp/artificial-neural-networks/wiki/Home/FPGAsAndNeuralNets.md#!sbcs-and-iot-boards <br />
* [http://nl.aliexpress.com/item/Altera-fpga-cycloneii-ep2c5t144-learning-board-development-board/872520721.html inexpensive ep2c5t144 board] <br />
* http://land-boards.com/blwiki/index.php?title=Cyclone_II_EP2C5_Mini_Dev_Board<br />
<br />
=== Neural networks on low-end hardware ===<br />
Investigate if you can run a powerful neural network on relatively low-end/cheap/low-power hardware. For example a Raspberry pi.<br />
A RPI runs Linux, run python, just like some common neural frameworks.<br />
Do we need hardware acceleration from the GPU and does the RPI GPU support that?<br />
<br />
Read list:<br />
* https://www.zdnet.com/pictures/raspberry-pi-meets-ai-the-projects-that-put-machine-learning-on-the-35-board/<br />
* https://www.pyimagesearch.com/2017/12/18/keras-deep-learning-raspberry-pi/<br />
* https://www.indiegogo.com/projects/sipeed-maix-the-world-first-risc-v-64-ai-module#/<br />
* https://ai.intel.com/intel-neural-compute-stick-2-smarter-faster-plug-and-play-ai-at-the-edge/<br />
<br />
Bought a MaixPy:<br />
* see https://maixpy.sipeed.com/en/<br />
* see https://www.youtube.com/watch?v=KResVuAIMb4<br />
* see http://educ8s.tv/sipeed-m1-dock-review/<br />
* interesting? https://www.instructables.com/id/Transfer-Learning-With-Sipeed-MaiX-and-Arduino-IDE/<br />
<br />
=== mini word clock in dutch ===<br />
Basically an monochrome 8x8 word clock, in Dutch, showing local time in the Netherlands.<br />
<br />
[https://github.com/bertrik/miniwordclock This git repo] has the current code.<br />
<br />
See [https://plus.google.com/103276078656203197145/posts/7ki7rpJzk3a here for a demo] running on an arduino nano.<br />
<br />
The plan is to run this from an ESP8266 instead of an arduino nano, so it can get the time from the internet using NTP.<br />
Andreas Spiess demonstrated on youtube how existing libraries on the ESP8266 can be used to do the local time (including summer-time) calculations.<br />
<br />
=== Cypress PSOC5 ===<br />
Play with the Cypress PSOC5 platform, which combines a ARM Cortex-m3 processor with configurable analog blocks. I'm thinking of combining it with a 24 GHz doppler radar sensor, to process the signal and present it as a USB audio device (stereo signal contains I and Q parts). See [[RadarOnAStick]].<br />
<br />
=== Simple Doppler motion sensors ===<br />
You can find basic doppler microwave motion sensors based on a single transistor, with some weird traces on the PCB very cheaply, for example<br />
* https://www.aliexpress.com/item/RCWL-0516-microwave-radar-sensor-module-Human-body-induction-switch-module-Intelligent-sensor/32708877914.html<br />
<br />
Typically the microwave part of these consists of a single transistor with a rectangular area on one leg and a meandering trace (with lots of vias to the other side) on the other leg.<br />
The output of this circuit seems to go into a chip very much like the ones used in PIR sensors.<br />
<br />
See also https://github.com/jdesbonnet/RCWL-0516 for a reverse engineering effort of these doppler radar modules.<br />
<br />
=== Bare-bones Arduino bat detector ===<br />
This is an idea for a very basic heterodyne bat detector, doing signal processing on an Arduino, requiring minimal external components.<br />
<br />
The basic principle of a heterodyne detector is that it just mixes (multiplies) the audio signal with a square wave, low-pass filters the result and puts it on a speaker.<br />
<br />
Multiplying with a square wave can also be considered to be just alternatively inverting and not-inverting the signal.<br />
So if you sample an ultrasonic signal at twice the rate you want to multiply, you can just subtract odd samples from even samples and low-pass filter that.<br />
<br />
How this can be done in an AVR Arduino:<br />
* sample the audio signal at twice the detection frequency, say 84 kHz. An AVR should just be able to do that.<br />
* apply a 1-pole IIR high-pass filter to remove DC bias, this takes one shift instruction and one addition.<br />
* multiply by the detection frequency, this means just inverting the odd samples.<br />
* low-pass filter the signal, this can be done using a moving average filter, say 16 samples long (first null at 5.25 kHz). Theoretically, averaging 16 samples should result in two bits extra accuracy. This operation takes some storage, an addition and a subtraction.<br />
* output the filtered signal using PWM, possibly at the same rate that we are sampling the input audio.<br />
<br />
The microphone can be a 40 kHz piezo transducer, to keep it cheap (but also limited to 40 kHz).<br />
The pre-amplifier can be a single transistor with some resistors around it, providing about 40x gain.<br />
The arduino does the signal processing (mixing, low-pass filter) to shift the bat audio to human range.<br />
The speaker amplifier can just be a simple two transistor push-pull circuit, since the output from the Arduino is digital/PWM.<br />
<br />
==== AVR Arduino sample rate ====<br />
As far as I understand, the ADC clock can be set to 1 MHz.<br />
Conversion takes 13 cycles, so this can be a problem to reach a sample rate above 80 kHz.<br />
<br />
=== Indoor radar speed sign ===<br />
This idea about placing a simple IQ-output radar sensor indoors in the hacker space, do some basic signal processing on the IQ doppler signal and determine movement speed and direction, then display this on a LED display.<br />
This is of no immediate practical use other than fun, but helps me to gain a bit more experience with microwave radar sensors and eventually build a more effective setup for detecting/counting bats flying in and out of a roost.<br />
<br />
Implement this on a PSOC5 platform or on the STM32 using Arduino.</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=User:Bertrik_Sikken&diff=34991User:Bertrik Sikken2026-01-17T11:48:40Z<p>Bertrik Sikken: /* investigate thread/matter */</p>
<hr />
<div>{{Smoel<br />
|Name=Bertrik Sikken<br />
|Nick=bertrik<br />
|Tagline=heb ik niet<br />
}}<br />
<br />
You can reach me at [mailto:bertrik@sikken.nl bertrik@sikken.nl] or [mailto:bertrik@gmail.com bertrik@gmail.com].<br />
<br />
Studied Electrical Engineering at Twente University.<br />
<br />
<br />
Main interests:<br />
* reverse-engineering things (USB stuff, mp3 players), worked on http://rockbox.org (sansa clip players)<br />
* studying bats and making electronics for recording/listening to bat sounds<br />
* radio stuff, in particular software-defined radio<br />
* energy-related stuff, visualisation<br />
* citizen science, particulate matter measurement, noise<br />
<br />
Projects I work(ed) on ([https://revspace.nl/index.php?title=User:Bertrik_Sikken&action=purge refresh]):<br />
{{#ask:[[Category:Project]][[Project Contact::bertrik]]<br />
|?Project Status<br />
|headers=show<br />
|link=all<br />
|order=ASC,ASC<br />
|sort=Project Status,Project Name<br />
}}<br />
<br />
<br />
== Project ideas ==<br />
[[File:always10oclock.jpg|right]]<br />
[[File:idea.jpg|right]]<br />
<br />
This is a list of ideas I'm thinking about, but have not fully developed into an actual project yet.<br />
<br />
https://pine64.com/product/128mb-ox64-sbc-available-on-december-2-2022/<br />
<br />
=== investigate thread/matter ===<br />
Matter/thread is the new IKEA standard for home automation thins apparently. <br />
Thread is the wireless protocol, matter is a home automation protocol running on top of thread.<br />
<br />
I have a couple of nrf52840, these are good in doing thread.<br />
<br />
Next steps:<br />
* check out openthread<br />
<pre><br />
git clone https://github.com/openthread/openthread.git<br />
cd openthread<br />
git submodule update --init --recursive<br />
</pre><br />
* Prepare development environment:<br />
scripts/bootstrap<br />
* Build it:<br />
./script/build nrf52840 UART_trans -DOT_LOG_LEVEL=OT_LOG_LEVEL_INFO<br />
<br />
Thread on ESP32-C6: https://gist.github.com/gtxaspec/d26198daadfb0a8b0a0edeae2d3fd58f<br />
<br />
=== action lsc stekker ===<br />
https://keetsupport.nl/2024/03/20/how-to-flash-lsc-power-plug-with-esphome/<br />
<br />
https://community.home-assistant.io/t/detailed-guide-on-how-to-flash-the-new-tuya-beken-chips-with-openbk7231t/437276<br />
<br />
=== sipeed maix dock ===<br />
Bought this a couple of years ago. Get familiar with this board.<br />
Can I run a chess program on this, for example?<br />
<br />
* https://wiki.sipeed.com/soft/maixpy/en/develop_kit_board/maix_dock.html<br />
<br />
=== rfid keyfob ===<br />
* aliexpress page: https://nl.aliexpress.com/item/1005009569496736.html<br />
* firmware github: <br />
** https://github.com/RfidResearchGroup/ChameleonUltra<br />
** https://github.com/GameTec-live/ChameleonUltraGUI<br />
<br />
=== advanced lidars for bat detection ===<br />
livox:<br />
* github page https://github.com/Livox-SDK/Livox-SDK/tree/master<br />
* web page: https://www.livoxtech.com/<br />
<br />
=== cubecell meshtastic motion detector ===<br />
I have a cubecell AB01 board.<br />
This board is focused on low power, has a connection to attach a solar panel and has a lora radio.<br />
Relatively small amount of RAM, barely enough to run a LoRaWAN stack but probably plenty to run meshtastic<br />
<br />
The plan is to build a simple motion detector from this (using a PIR).<br />
The PIR can wake up the board from low-power, or a timer can wake it periodically.<br />
<br />
See also: https://github.com/HelTecAutomation/CubeCell-Arduino/tree/master/libraries/Basics/examples/LowPower<br />
<br />
=== configure multitech outdoor gateway ===<br />
https://www.multitech.net/developer/products/multiconnect-conduit-platform/basestation/<br />
<br />
https://multitech.com/product/multitech-conduit-mtcdt-246a-868-eu-gb/<br />
<br />
emergency procedure:<br />
https://www.multitech.net/developer/software/mlinux/using-mlinux/flashing-mlinux-firmware-for-conduit/<br />
<br />
=== esp32 wtf ===<br />
* https://forum.arduino.cc/t/ttgo-lilygo-lora-esp32-26mhz-problem/1353750<br />
* "26 MHz crystal has been deprecated" https://github.com/espressif/arduino-esp32/issues/10117<br />
<br />
=== kakofonie counter ===<br />
Sample room audio, use neural network to distinguish voices to estimate number of people talking in the past 30 seconds or so.<br />
Show this number on some kind of display, publish it to MQTT, make a nice graph of it.<br />
<br />
Stuff to figure out:<br />
* this is called 'speaker diarization'<br />
* can it run on an ESP32?<br />
* make a prototype<br />
<br />
=== hypno toad ===<br />
Put these LEDS https://nl.aliexpress.com/item/1005007583528891.html into https://www.action.com/nl-nl/p/2560347/solar-tuinbeeldje/<br />
<br />
Turns out that the default circuit is really basic and output a rough step-up waveform to the LED.<br />
The self-fading LEDs don't work very well with that.<br />
<br />
Also, putting some IPA on hotglue makes it release really easy.<br />
<br />
=== wasbeer / kat classifier ===<br />
ESP32 with resnet50 neural net to distinguish house cats from other animals, see also:<br />
* https://ieeexplore.ieee.org/document/10556848/<br />
<br />
=== Nespresso brew counter ===<br />
Several hacker spaces have one of these Nespresso cup coffee makers, but there's no obvious easy way to monitor usage (monitor ALL the things!).<br />
Inspired by https://hackaday.com/2021/04/25/arduino-mkr-makes-nespresso-monitoring-easy/ this idea is making an even simpler nespresso monitor,<br />
using an inexpensive WiFi enabled ESP8266 with an ubiquitous I2S microphone such as the INMP441. <br />
<br />
Use this sound monitoring project:<br />
https://github.com/aleiei/ESP8266-BUG-I2S-MIC<br />
and turn it into a WiFi connected brew counter.<br />
<br />
Software for getting microphone data from an ESP8266/I2S mic into Linux https://github.com/bertrik/EspMicServer<br />
Nespresso sound is typically 50 Hz with overtones.<br />
In a recording with the ESP8266, it appears that oddly the 17th harmonic (around 850 Hz) is quite strong.<br />
<br />
The plan in the short term is this:<br />
* apply a gentle IIR filter to subtract any DC bias from the microphone signal<br />
* calculate autocovariance at offsets 0 and 20 ms (inverse of 50 Hz), representing the total energy and the energy at 50 Hz respectively<br />
* compare amplitudes to decide about presence of 50 Hz signal, e.g. calculate ratio in dB<br />
* use this to count the length of time that a 50 Hz signal is heard (increments of 100 ms or so)<br />
* decide about none / espresso / lungo based on time<br />
<br />
Might even integrate with esphome / home assistant later.<br />
<br />
=== Remote bat box monitor ===<br />
Idea:<br />
* goal: check if remote bat boxes are occupied and identify the species<br />
* challenges:<br />
** connectivity: need to transport images/videos (no LoRaWAN), possibly out of range of mobile data networks<br />
** autonomy: cannot reach the bat box once installed<br />
** power: no fixed power connection, so probably needs a battery + solar panel<br />
* design<br />
** wake up every hour, take a picture, go to sleep, upload photos/videos once per day<br />
** run from batteries, recharge by solar, rules of thumb<br />
*** batteries should last for about 10 days<br />
*** battery should be able to charge in 1 day<br />
*** consider only 10% of peak solar power<br />
** KPN "4G-op-zee" somewhat confusing article: https://www.kpn.com/zakelijk/mobiel/roaming/noordzee<br />
* hardware<br />
** main processor: raspberry pi zero<br />
*** raspberry pi power consumption overview: https://www.pidramble.com/wiki/benchmarks/power-consumption<br />
** this hat to wake up the main CPU: https://www.waveshare.com/wiki/Power_Management_HAT_(B) sold at https://www.kiwi-electronics.com/en/power-management-hat-for-raspberry-pi-with-rtc-and-rp2040-mcu-11373<br />
<br />
=== KNMI API ===<br />
Get familiar with https://developer.dataplatform.knmi.nl/open-data-api<br />
<br />
=== Grid frequency measurer with web page ===<br />
See https://github.com/bertrik/GridFrequency<br />
SSE source is gridfrequency.local/events<br />
<br />
=== WeAct CH55x board ===<br />
Cheap little boards, using a similar chip as used in USB-serial converters.<br />
<br />
The hardware<br />
https://github.com/WeActStudio/WeActStudio.CH552CoreBoard<br />
<br />
Flashing it:<br />
https://hackaday.io/page/137447-flashing-the-ch552-dev-board-from-the-command-line<br />
<br />
See also:<br />
* https://hackaday.io/project/198238-more-weact-ch5xx<br />
* https://community.platformio.org/t/manually-adding-support-for-ch55x-controller-by-adding-existing-ardunio-core/41138<br />
<br />
=== Zigbee device with esp32 ===<br />
See https://github.com/P-R-O-C-H-Y/arduino-esp32/blob/8169a434c3e46e1bb7711ebcc04f27267db2093c/libraries/ESP32/examples/Zigbee/Zigbee_Light_Bulb/Zigbee_Light_Bulb.ino<br />
<br />
See https://github.com/espressif/arduino-esp32/tree/master/libraries/ESP32/examples/Zigbee<br />
<br />
Espressif32 arduino platform git: https://github.com/platformio/platform-espressif32<br />
<br />
=== Cameratoezicht in Gouda ===<br />
Gemeente Gouda publiceert een lijst van camera's in Gouda, zie<br />
https://gis.gouda.nl/nl/app/Basisviewer_open#!eAGT8uRiNBRy4ZIRYFKSyKkssjJwdzFxNDMz8TKKsLC0cnb0dQ1y5FIByirgkg3xd43ydPYIAQBXGBFm<br />
<br />
Aanmelden (semi-automatisch) bij bijvoorbeeld [https://mapcomplete.org/surveillance Surveillance-under-surveillance] ?<br />
<br />
=== SolarEdge ===<br />
Interact with the solar edge api for PV installations.<br />
<br />
https://developers.solaredge.com/<br />
<br />
See https://github.com/bertrik/solaredge-api<br />
<br />
=== Stookalert ===<br />
Idee: gekleurd lampje dat aangeeft of er op dit moment een stookalert actief is<br />
<br />
Implementatie:<br />
* kijk m.b.v. WiFi locatieservice in welke provincie je je bevindt<br />
* haal JSON op bij https://www.lml.rivm.nl/stookalert/stookalert.json<br />
* toon de bijbehorende kleur op het lampje<br />
<br />
Resources:<br />
* Officiele pagina: https://www.atlasleefomgeving.nl/stookwijzer<br />
* Achterliggende JSON met toestand per provincie: https://www.lml.rivm.nl/stookalert/stookalert.json<br />
* Er moet ook nog ergens een API zijn die fijnmaziger aangeeft wat de toestand is ...<br />
<br />
=== Display of current electricity usage ===<br />
I have a [https://www.zuidwijk.com/product/slimmelezer-plus/ slimme lezer] connected to the P1 port of my smart electricity meter.<br />
The default firmware exposes meter readings using an event stream (SSE) at http://slimmelezer.local/events<br />
<br />
So for example, you can read this with curl:<br />
curl http://slimmelezer.local/events<br />
With result:<br />
event: state<br />
data: {"id":"sensor-power_consumed_phase_1","value":0.046,"state":"0.046 kW"}<br />
<br />
Specification of SSE: https://html.spec.whatwg.org/multipage/server-sent-events.html#parsing-an-event-stream<br />
<br />
What I would like to do is to read these events and control a simple display to display the current usage number.<br />
<br />
=== Participating in ultrasonic sound project ===<br />
https://bat-migration-europe.netlify.app/project/<br />
<br />
Use an audiomoth for this.<br />
<br />
=== ESP32 C3 ===<br />
* [https://www.espressif.com/en/products/socs/esp32-c3 processor page]<br />
* [https://wiki.luatos.com/chips/esp32c3/index.html luatos basic esp32 c3 board]<br />
<br />
=== Flexible LED ticker ===<br />
Ordered a flexible 32x8 RGB LED display:<br />
https://nl.aliexpress.com/item/4001296811800.html<br />
<br />
Matching diffuser to be 3D printed:<br />
https://www.thingiverse.com/thing:1903744<br />
<br />
=== Washing machine API ===<br />
https://tratt.net/laurie/blog/2023/displaying_my_washing_machines_remaining_time_with_curl_jq_pizauth.html<br />
<br />
=== TinyML ===<br />
Investigate TinyML, see https://www.tinyml.org/<br />
Apparently can run on a RP2040 (raspi pi pico).<br />
<br />
https://www.hackster.io/mjrobot/esp32-cam-tinyml-image-classification-fruits-vs-veggies-4ab970<br />
<br />
=== Bat box busy signal ===<br />
My brother built little pyramid 'blinkies': solar cell + Lithium-supercapacitor + harvesting circuit + LED encased in clear expoxy.<br />
<br />
Can we add a low-power PIR sensor to this, and make a blinky that blinks if movement was detected by the PIR in the past hour?<br />
<br />
=== Super tiny RFID ===<br />
See https://www.sparkfun.com/products/16464 an almost sand grain size RFID chip, 1.25mmx1.25mmx0.55mm<br />
<br />
The accompanying reader "M6E Nano" is still quite expensive at $235.95 : https://www.sparkfun.com/products/14066<br />
<br />
Uses the MuRata LXMSJZNCMF-198:<br />
"This product can be used as an ultra small tag and this can be<br />
fit on any metal objects, non-metal objects, as well as<br />
embedding into any objects by glue or adhesive and so on."<br />
<br />
See also: ISO18000-63 and EPC global Gen2(v2)<br />
<br />
Specification:<br />
* https://www.gs1.org/standards/rfid/uhf-air-interface-protocol<br />
<br />
=== TheThingsNetwork-Sondehub bridge ===<br />
Uploads balloon telemetry to sondehub.<br />
<br />
See https://github.com/bertrik/ttnhabbridge/issues/6<br />
<br />
=== Actually smart boiler ===<br />
The boiler for hot water is about half of my electricity bill.<br />
The idea is to use/build a smart switch that switches it on at time when electricity prices are lowest.<br />
<br />
Currently have a "Slimme boiler module" from Eneco, which is *not* actually smart,<br />
since it allows me no control whatsoever when it switches on (besides cutting the power in the meterkast).<br />
For example, it will switch on mid-day when my price is high and eneco's price is low, perhaps good for Eneco, not for me. <br />
Apparently, they even received a [https://nieuws.eneco.nl/slim-apparaatje-bij-boiler-vangt-pieken-wind--en-zonnestroom-op/ subsidy] for this.<br />
<br />
A boiler is a pretty big load, about 3 kW, but it is not inductive.<br />
<br />
Alternatives:<br />
* https://www.shelly.cloud/en-nl/products/product-overview/shelly-plus-1-pm-2-pack/shelly-plus-1-pm<br />
* https://www.solyxenergy.nl/solar-iboost/ to store excess solar energy in hot water, might also be useful for just controlling a boiler to use cheaper rates<br />
* tuya smartplug, like https://www.wifilampkoning.nl/merken-slimme-verlichting/tuya/tuya-enkele-smartplug-met-energiemeting ?<br />
* tuya 20A smart plug: https://nl.aliexpress.com/item/1005003347568206.html<br />
<br />
=== Receiving gas meters ===<br />
Apparently gas meters send gas consumption data to the slimme meter using a wireless link in the 868 MHz band.<br />
Probably just FSK at 38.4, as mentioned here: https://a35.veron.nl/nieuwe-elektra-en-gasmeters/<br />
<br />
Interesting leads:<br />
* https://github.com/stef/smeter<br />
* https://www.rtl-sdr.com/reading-household-wireless-utility-meters-with-an-rtl-sdr-and-plotting-the-data-in-home-automation-software/<br />
* https://github.com/bemasher/rtlamr<br />
<br />
=== Multi-network wifi manager ===<br />
Figure out or create software so that ESP8266/ESP32 wifi manager can use multiple networks to connect (not just one),<br />
so it allowing storing credentials for more than one network. For example, the network at home, the hacker space, at work.<br />
Instead of reconfiguring the wifi manager for each network, you just *add* your credentials (and the existing credentials<br />
are not replaced).<br />
<br />
See https://github.com/folkertvanheusden/M.A.X.X<br />
<br />
Interesting candidates:<br />
* https://registry.platformio.org/libraries/martinverges/ESP32%20Wifi%20Manager wifi manager for ESP32, has a REST API for managing wifi network, but is incomplete in the sense that you need to write your own code (e.g. javascript) to actually *use* its API<br />
* https://github.com/arduino-libraries/Arduino_MultiWiFi is the arduino multi wifi library, to allow connecting to multiple different WiFi networks, but it is not a wifi manager, that starts a captive portal, etc<br />
<br />
=== Automated bat counting ===<br />
Can we automatically count the number of bats from the image of a webcam mounted in a bat colony?<br />
Perhaps using some kind of AI or machine learning algorithm?<br />
<br />
The image in question:<br />
https://stofradar.nl/coenecoop/<br />
<br />
=== Use TheThingsIndoorGateway as Helium/ThingSix hotspot ===<br />
I have a spare TTIG that could perhaps be used as a Helium gateway, investigate what is possible.<br />
<br />
One possiblity is to capture the gateway traffic from the TTN gateway events API, convert uplink data to a format that the Helium network understands and forward it.<br />
I don't really care about the Helium crypto tokens, this is just for fun and science.<br />
<br />
What I definitely can do:<br />
* Capture data from the TTN gateway events API, convert it back to Semtech UP format and forward it somewhere to Helium (just not sure where!)<br />
* See also my https://github.com/bertrik/ttn-gateway-collector project which contains an initial implementation of TTN-to-UDP conversion<br />
<br />
Showstoppers:<br />
* If you want to be a gateway on the Helium network, you have to *pay Helium*! Obviously I don't want that, I just want to share data to improve *their* network. <br />
<br />
Open work:<br />
* Investigate if Helium has an open uplink API for their hotspots, if so study it etc, without paying the gateway fee<br />
* Investigate if Thingsix has an open uplink API for their hotspots, if so study it etc, without paying any gateway fee<br />
* Investigate if Thingsix is just another Helium, with weird crypto money<br />
<br />
Interesting stuff:<br />
* https://docs.helium.com/use-the-network/setup-a-packet-forwarder unfortunately the link to setting up the 'light hotspot client' does not work!<br />
* https://docs.helium.com/mine-hnt/light-hotspots/<br />
* https://thingsix.com/<br />
<br />
=== Adding BLE GATT interface to sensors ===<br />
The GATT specification allows measurement properties to be defined and transferred continuously over Bluetooth low-energy.<br />
<br />
With GATT you can define a collection of properties (e.g. measurement items like temperature/humidity/particulate matter/noise, etc)<br />
organised in a simple structure of a BLE service.<br />
The 'notification' method allows you to basically push the data continuously to a connected host, e.g. a smart phone.<br />
<br />
Services collects characteristic, a characteristic has values with units.<br />
Each of these (service, characteristic, unit) have their own unique "UUID".<br />
This is described in the so-called [https://btprodspecificationrefs.blob.core.windows.net/assigned-values/16-bit%20UUID%20Numbers%20Document.pdf 16-bit UUID numbers document]<br />
<br />
Interesting stuff in GATT:<br />
* See GATT_Specification_Supplement_v5 paragraph 3.151, it has a noise characteristic with 1 dB resolution.<br />
* 0x27C3 is the GATT *unit* for sound pressure<br />
* 0x181A is the GATT environmental sensing *service*, document name "ESP_V1.0.0.pdf"<br />
* 0x2A6E is the GATT Characteristic and Object Type for temperature<br />
* 0x2A6F is the GATT Characteristic and Object Type for humidity<br />
* 0x2BD5 is the GATT Characteristic and Object Type for Particulate Matter - PM1 Concentration<br />
* 0x2BD6 is the GATT Characteristic and Object Type for Particulate Matter - PM2.5 Concentration<br />
* 0x2BD7 is the GATT Characteristic and Object Type for Particulate Matter - PM10 Concentration<br />
* Unfortunately I cannot find a characteristic for carbon-dioxide (CO2) in the BLE GATT unit document<br />
<br />
See also https://programmaticponderings.com/2020/08/04/getting-started-with-bluetooth-low-energy-ble-and-generic-attribute-profile-gatt-specification-for-iot/<br />
<br />
=== Reverse engineering XS-8217 bluetooth air quality meter ===<br />
This is a thing that measures CO2, humidity, temperature, TVOC and formaldehyde.<br />
<br />
See also https://wiki.liutyi.info/display/CO2/ZN-2CO3+Inside<br />
<br />
This teardown looks a lot like my sensor: https://www.youtube.com/watch?v=APnjhMrJChI<br />
Mine contains a "TPM-300A" sensor for measuring VOC.<br />
<br />
It has a bluetooth interface, device name is XS-8217.<br />
It has a BLE GATT profile, with the following services<br />
* service 0xC760<br />
** characteristic 0xC762 (WRITE)<br />
** characteristic 0xC761 (NOTIFY)<br />
*** example data: 0x23 0x06 0x10 0x04 0xF1 0x00 0x23 0x65<br />
*** example data: 0x23 0x08 0x10 0x04 0x01 0x9A 0x00 0x0A 0x00 0x03 0x0E<br />
*** data shown on screen was approximately: CO2=418ppm, HCHO=0.003mg/m3, TVOC=0.013mg/m3, temp=24degC, humi=35%<br />
<br />
So data in the characteristic 0xC761 seems to have a 4 byte constant header:<br />
* 0x23<br />
* length byte<br />
<br />
Then we have for the first message: 0x10 0x04 0xF1 0x00 0x23 0x65<br />
* 0x10 0x04 fixed header<br />
* 0xF1 is temperature in 0.1 degree Celcius most likely (24.1)<br />
* 0x00 is ...<br />
* 0x23 is humidity most likely (35)<br />
* 0x65 is ... checksum perhaps<br />
<br />
And for the second message: 0x10 0x04 0x01 0x9A 0x00 0x0A 0x00 0x03 0x0E<br />
* 0x10 0x04 fixed header<br />
* 0x01 0x9A is the CO2 concentration (410)<br />
* 0x00 0x0A is TVOC most likely (10)<br />
* 0x00 0x03 is HCHO most likely (3)<br />
* 0x0E is ... checksum perhaps<br />
<br />
=== ribbon tweeter for bat audio ===<br />
Someone gave me this idea:<br />
Use a ribbon tweeter like this for playing back bat audio:<br />
<s>https://nl.aliexpress.com/item/4000973201791.html</s><br />
<s>https://nl.aliexpress.com/item/1005002565880660.html</s><br />
https://nl.aliexpress.com/item/1005002635086050.html<br />
<br />
The frequency spectrum shows no sign of dropping off at 20 kHz.<br />
<br />
=== 3d glasses ===<br />
I got some 2nd hand 3d glasses, they look exactly like these ones:<br />
* GH-15 https://www.dhgate.com/product/g15-dlp-3d-active-shutter-glasses-96-144hz/213983026.html<br />
* Sintron https://www.amazon.de/Sintron-Kompatibel-TDG-BT500A-TDG-BT400A-Deutschland/dp/B015PCWMZ8<br />
The common name appears to be "G15-DLP".<br />
<br />
A tear-down here:<br />
* https://blog.danman.eu/3d-shutter-glasses-teardown/<br />
<br />
Interesting documents:<br />
* http://cmst.curtin.edu.au/wp-content/uploads/sites/4/2016/05/2012-28-woods-helliwell-cross-compatibility_of_shutter_glasses.pdf<br />
* http://cmst.curtin.edu.au/local/docs/pubs/2011-17-woods-helliwell-3D-Sync-IR.pdf<br />
<br />
Someone claims he got something to work with some hacks:<br />
https://www.avsforum.com/threads/how-i-got-cheap-dlp-link-glasses-to-work-great.1887145/<br />
<br />
=== Waterniveaumeter ===<br />
Op verschillende plekken in Gouda staat er water in de kruipruimte van huizen van bewoners.<br />
Kunnen we dat meten en inzichtelijk maken, voor bewoners, op een kaart bijvoorbeeld?<br />
<br />
Idee:<br />
* in de kruipruimte plaats je een module die waterhoogte kan meten<br />
* de module bestaat uit een microcontroller en een afstandsmeter, die de waterhoogte bepaalt<br />
* de gegevens worden via WiFi doorgestuurd naar een centraal punt, waar de data wordt verwerkt en gevisualiseerd<br />
* op een webpagina kan je een overzicht zien van alle meters die online zijn<br />
* de meting wordt gedaan door bijv. een laser-afstandsmeter of een ultrasoon-afstandsmeter<br />
* voeding? lastig, hoe krijg je 5v naar een potentieel natte plek?<br />
* kosten? verwachting < E 40,-<br />
<br />
In Gouda wordt op veel verschillende plekken de grondwaterstand gemeten, zie https://opendata.munisense.net/portal/wareco-water2/group/581/Gouda-KJ38A , maar:<br />
* geen visualisatie op de kaart, je ziet alleen de meetlokaties d.m.v. een icoontje!<br />
* geen meetpunten in Gouda noord!<br />
<br />
=== Online bat detector ===<br />
Idea: use an ultrasonic microphone, connect it to a WebSDR, so people can tune into bat sounds remotely.<br />
<br />
=== Raspberry pi airplane tracking ===<br />
Apparently now you can also participate in MLAT tracking of planes that don't transmit GPS coordinates themselves.<br />
<br />
=== APRS gateway ===<br />
http://qso365.co.uk/2017/02/a-guide-to-setting-up-an-aprs-receive-only-igate-using-a-raspberry-pi-and-an-rtl-sdr-dongle/<br />
<br />
=== JQ6500 ===<br />
Small inexpensive modules that play mp3 from an internal flash. Could be nice for a custom door bell for example.<br />
<br />
More info at: <br />
* https://www.elecfreaks.com/wiki/index.php?title=JQ6500_Mini_MP3_Module<br />
* https://sparks.gogo.co.nz/jq6500/index.html<br />
<br />
=== FPGA ===<br />
Cheap FPGA boards and nice applications:<br />
* https://bitbucket.org/appanp/artificial-neural-networks/wiki/Home/FPGAsAndNeuralNets.md#!sbcs-and-iot-boards <br />
* [http://nl.aliexpress.com/item/Altera-fpga-cycloneii-ep2c5t144-learning-board-development-board/872520721.html inexpensive ep2c5t144 board] <br />
* http://land-boards.com/blwiki/index.php?title=Cyclone_II_EP2C5_Mini_Dev_Board<br />
<br />
=== Neural networks on low-end hardware ===<br />
Investigate if you can run a powerful neural network on relatively low-end/cheap/low-power hardware. For example a Raspberry pi.<br />
A RPI runs Linux, run python, just like some common neural frameworks.<br />
Do we need hardware acceleration from the GPU and does the RPI GPU support that?<br />
<br />
Read list:<br />
* https://www.zdnet.com/pictures/raspberry-pi-meets-ai-the-projects-that-put-machine-learning-on-the-35-board/<br />
* https://www.pyimagesearch.com/2017/12/18/keras-deep-learning-raspberry-pi/<br />
* https://www.indiegogo.com/projects/sipeed-maix-the-world-first-risc-v-64-ai-module#/<br />
* https://ai.intel.com/intel-neural-compute-stick-2-smarter-faster-plug-and-play-ai-at-the-edge/<br />
<br />
Bought a MaixPy:<br />
* see https://maixpy.sipeed.com/en/<br />
* see https://www.youtube.com/watch?v=KResVuAIMb4<br />
* see http://educ8s.tv/sipeed-m1-dock-review/<br />
* interesting? https://www.instructables.com/id/Transfer-Learning-With-Sipeed-MaiX-and-Arduino-IDE/<br />
<br />
=== mini word clock in dutch ===<br />
Basically an monochrome 8x8 word clock, in Dutch, showing local time in the Netherlands.<br />
<br />
[https://github.com/bertrik/miniwordclock This git repo] has the current code.<br />
<br />
See [https://plus.google.com/103276078656203197145/posts/7ki7rpJzk3a here for a demo] running on an arduino nano.<br />
<br />
The plan is to run this from an ESP8266 instead of an arduino nano, so it can get the time from the internet using NTP.<br />
Andreas Spiess demonstrated on youtube how existing libraries on the ESP8266 can be used to do the local time (including summer-time) calculations.<br />
<br />
=== Cypress PSOC5 ===<br />
Play with the Cypress PSOC5 platform, which combines a ARM Cortex-m3 processor with configurable analog blocks. I'm thinking of combining it with a 24 GHz doppler radar sensor, to process the signal and present it as a USB audio device (stereo signal contains I and Q parts). See [[RadarOnAStick]].<br />
<br />
=== Simple Doppler motion sensors ===<br />
You can find basic doppler microwave motion sensors based on a single transistor, with some weird traces on the PCB very cheaply, for example<br />
* https://www.aliexpress.com/item/RCWL-0516-microwave-radar-sensor-module-Human-body-induction-switch-module-Intelligent-sensor/32708877914.html<br />
<br />
Typically the microwave part of these consists of a single transistor with a rectangular area on one leg and a meandering trace (with lots of vias to the other side) on the other leg.<br />
The output of this circuit seems to go into a chip very much like the ones used in PIR sensors.<br />
<br />
See also https://github.com/jdesbonnet/RCWL-0516 for a reverse engineering effort of these doppler radar modules.<br />
<br />
=== Bare-bones Arduino bat detector ===<br />
This is an idea for a very basic heterodyne bat detector, doing signal processing on an Arduino, requiring minimal external components.<br />
<br />
The basic principle of a heterodyne detector is that it just mixes (multiplies) the audio signal with a square wave, low-pass filters the result and puts it on a speaker.<br />
<br />
Multiplying with a square wave can also be considered to be just alternatively inverting and not-inverting the signal.<br />
So if you sample an ultrasonic signal at twice the rate you want to multiply, you can just subtract odd samples from even samples and low-pass filter that.<br />
<br />
How this can be done in an AVR Arduino:<br />
* sample the audio signal at twice the detection frequency, say 84 kHz. An AVR should just be able to do that.<br />
* apply a 1-pole IIR high-pass filter to remove DC bias, this takes one shift instruction and one addition.<br />
* multiply by the detection frequency, this means just inverting the odd samples.<br />
* low-pass filter the signal, this can be done using a moving average filter, say 16 samples long (first null at 5.25 kHz). Theoretically, averaging 16 samples should result in two bits extra accuracy. This operation takes some storage, an addition and a subtraction.<br />
* output the filtered signal using PWM, possibly at the same rate that we are sampling the input audio.<br />
<br />
The microphone can be a 40 kHz piezo transducer, to keep it cheap (but also limited to 40 kHz).<br />
The pre-amplifier can be a single transistor with some resistors around it, providing about 40x gain.<br />
The arduino does the signal processing (mixing, low-pass filter) to shift the bat audio to human range.<br />
The speaker amplifier can just be a simple two transistor push-pull circuit, since the output from the Arduino is digital/PWM.<br />
<br />
==== AVR Arduino sample rate ====<br />
As far as I understand, the ADC clock can be set to 1 MHz.<br />
Conversion takes 13 cycles, so this can be a problem to reach a sample rate above 80 kHz.<br />
<br />
=== Indoor radar speed sign ===<br />
This idea about placing a simple IQ-output radar sensor indoors in the hacker space, do some basic signal processing on the IQ doppler signal and determine movement speed and direction, then display this on a LED display.<br />
This is of no immediate practical use other than fun, but helps me to gain a bit more experience with microwave radar sensors and eventually build a more effective setup for detecting/counting bats flying in and out of a roost.<br />
<br />
Implement this on a PSOC5 platform or on the STM32 using Arduino.</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=NRF52840&diff=34983NRF528402026-01-12T16:13:48Z<p>Bertrik Sikken: </p>
<hr />
<div> {{Project<br />
|Name=NRF52840<br />
|Picture=nrf52840-supermini.png<br />
|Omschrijving=Running Arduino with platformio on NRF52840<br />
|Status=In progress<br />
|Contact=bertrik<br />
}}<br />
<br />
== Intro ==<br />
This page is about getting inexpensive NRF52840 boards to work with Arduino and platformio.<br />
<br />
NRF52840 is a nice platform:<br />
* low-power<br />
* inexpensive<br />
* decent amount of flash (1024k), RAM (256k) and CPU cycles (64 MHz)<br />
* support various radio protocols like zigbee, ble, thread, enhanced shockburst<br />
* built-in support for quadrature counting<br />
* can run arduino too<br />
<br />
However the eco-system of inexpensive boards is a complicated landscape:<br />
* AliExpress sellers offer "promicro" and "supermini" board with unclear characteristics<br />
* LEDs are sometimes swapped (blue = hardware charge, red = software led?)<br />
* Various firmware upload interface options (which one to use?):<br />
** Using nrfutil, sends a .zip file containing various parts, over USB-serial<br />
** Mass storage UF2, activated using the double-reset<br />
** SWD debug interface (requires soldering!)<br />
* Confusing situation regarding bootloaders:<br />
** Most boards seem to come with a modified version of a bootloader meant for another type of board<br />
** Type of bootloader depends on type of firmware you want to run, "ZMK", Arduino using Arduino IDE, Arduino using platformio<br />
** Risk of accidentally overwriting the bootloader, with UF2 flash offsets sometimes being absolute, sometimes being relative<br />
<br />
== Hardware ==<br />
[[File:nrf52840-supermini-pinout.png|right|thumb|pinout]]<br />
<br />
The boards I have are the "promicro" and "supermini".<br />
These boards look basically identical hardware-wise.<br />
<br />
There is a 4-pad connector to program it using SWD (VDD/SWD/SDC/GND).<br />
This can be used to write the bootloader for example.<br />
The pads have a spacing of 1.5mm.<br />
<br />
The blue LED appears to flash independently of software, this is probably the charge circuit behaving randomly without a battery present.<br />
The red LED appears to be under software control.<br />
<br />
Pinout/schematic: https://nicekeyboards.com/docs/nice-nano/pinout-schematic<br />
<br />
=== bootloader ===<br />
The INFO_UF2.TXT says (after double-tap reset):<br />
UF2 Bootloader 0.6.0 lib/nrfx (v2.0.0) lib/tinyusb (0.10.1-41-gdf0cda2d) lib/uf2 (remotes/origin/configupdate-9-gadbb8c7)<br />
Model: nice!nano<br />
Board-ID: nRF52840-nicenano<br />
SoftDevice: S140 version 6.1.1<br />
Date: Jun 19 2021<br />
<br />
The CURRENT.UF2 file is 1.4 MB<br />
<br />
Kernel log says:<br />
<pre><br />
[509372.005339] usb 1-2.3: new full-speed USB device number 96 using xhci_hcd<br />
[509372.132351] usb 1-2.3: New USB device found, idVendor=239a, idProduct=00b3, bcdDevice= 1.00<br />
[509372.132361] usb 1-2.3: New USB device strings: Mfr=1, Product=2, SerialNumber=3<br />
[509372.132364] usb 1-2.3: Product: nice!nano<br />
[509372.132366] usb 1-2.3: Manufacturer: Nice Keyboards<br />
[509372.132368] usb 1-2.3: SerialNumber: 98D93A272A6CCC7D<br />
[509372.187474] cdc_acm 1-2.3:1.0: ttyACM0: USB ACM device<br />
[509372.190177] usb-storage 1-2.3:1.2: USB Mass Storage device detected<br />
[509372.190467] scsi host3: usb-storage 1-2.3:1.2<br />
[509373.200470] scsi host3: scsi scan: INQUIRY result too short (5), using 36<br />
[509373.200481] scsi 3:0:0:0: Direct-Access Adafruit nRF UF2 1.0 PQ: 0 ANSI: 2<br />
[509373.200825] sd 3:0:0:0: Attached scsi generic sg0 type 0<br />
[509373.202317] sd 3:0:0:0: [sdb] 65801 512-byte logical blocks: (33.7 MB/32.1 MiB)<br />
[509373.202556] sd 3:0:0:0: [sdb] Write Protect is off<br />
[509373.202559] sd 3:0:0:0: [sdb] Mode Sense: 03 00 00 00<br />
[509373.202782] sd 3:0:0:0: [sdb] No Caching mode page found<br />
[509373.202784] sd 3:0:0:0: [sdb] Assuming drive cache: write through<br />
[509373.296933] sdb:<br />
[509373.297002] sd 3:0:0:0: [sdb] Attached SCSI removable disk<br />
</pre><br />
<br />
== Software ==<br />
Working platformio example project for the nice!nano and supermini/promicro nrf52840 clones:<br />
https://github.com/bertrik/nicenano-example <br />
<br />
Links:<br />
* Nordic technical documentation: https://docs.nordicsemi.com/category/nrf52840-category<br />
* Here is a wiki full of useful information on specific boards: https://github.com/joric/nrfmicro/wiki<br />
** Specifically the supermini https://github.com/joric/nrfmicro/wiki/Alternatives#supermini-nrf52840<br />
* nRFMicro Arduino Core:<br />
** Meant for integration with Arduino IDE, not platformio!<br />
** See https://github.com/pdcook/nRFMicro-Arduino-Core<br />
** Uses https://github.com/NordicSemiconductor/nrfx for NRF52840 specific drivers<br />
* Platformio support for supermini:<br />
** Focused on platformio<br />
** https://github.com/ICantMakeThings/Nicenano-NRF52-Supermini-PlatformIO-Support<br />
** Bit awkward installation (copy/overwrite files inside existing platformio folder)<br />
* https://docs.nordicsemi.com/bundle/ncs-3.1.0/page/zephyr/boards/others/promicro_nrf52840/doc/index.html pro-micro information from Nordic Semi<br />
<br />
Getting 'circuitpython' to work:<br />
* Here's a page on making it work on nicenano: https://circuitpython.org/board/nice_nano/<br />
* HOWEVER, it also says "On nRF boards, CircuitPython 8.2.0 and later require UF2 bootloader version 0.6.1 or later. Older bootloaders cannot load the firmware. See Update UF2 Bootloader below.". Guess what bootloader came with my board ... 0.6.0<br />
* They point you to https://github.com/adafruit/Adafruit_nRF52_Bootloader/releases/tag/0.9.2 but now what!?!!!</div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=File:Nrf52840-supermini.png&diff=34982File:Nrf52840-supermini.png2026-01-10T20:48:11Z<p>Bertrik Sikken: Bertrik Sikken uploaded a new version of File:Nrf52840-supermini.png</p>
<hr />
<div></div>Bertrik Sikkenhttps://revspace.nl/wiki/index.php?title=File:Nrf52840-supermini.png&diff=34981File:Nrf52840-supermini.png2026-01-10T20:46:59Z<p>Bertrik Sikken: </p>
<hr />
<div></div>Bertrik Sikken